Unattributed; messages sent from legitimate certified mailboxes, likely compromisedhigh
The mailbox is certified, the invoice inside is not: a campaign riding compromised legal email
Italy's national CSIRT has detected a phishing campaign delivered over PEC, the country's legally binding certified email, with messages sent from mailboxes that were most likely compromised. The message carries a ZIP attachment holding an HTML page themed around "Electronic Invoice", with a download button. The malicious behaviour only triggers after user interaction: the payload address is assembled through JavaScript on mouse movement, and the page behaves differently per operating system, showing an error on macOS and Linux. Clicking leads to the download and execution of PowerShell scripts. The point is not the technical sophistication: it is the channel. PEC has legal standing, so people open it.
The channel matters more than the content
An Italian PEC mailbox is not an ordinary inbox with a longer name. It is a digital domicile: the provider certifies who sent a message and when, the receipt carries legal weight, and for a very large number of Italian businesses and professionals it is the channel on which the messages you cannot ignore arrive — invoices, formal notices, legal documents.
Which is exactly why it makes a good attack channel. Not because it is technically weaker than ordinary mail, but because the people who receive it open it. The mental filter applied to any random email — who is this, what do they want — drops on PEC, because the channel was built to be trustworthy.
CSIRT Italia, the incident response arm of Italy's National Cybersecurity Agency, has detected a campaign operating precisely here: PEC messages themed "Fattura Elettronica" (Electronic Invoice), sent — the advisory says — most likely from compromised certified mailboxes.
This needs stating precisely, because it is the most likely misreading: PEC as a system was not broken. What was compromised are individual mailboxes, which is to say individual credentials. The system does its job and correctly certifies the sender; it is just that the sender, at that moment, is not who they appear to be.
The chain, one step at a time
- 01PEC messagefrom a legitimate mailbox, compromised
- 02ZIP attachmentcontains an HTML file named like a tax document
- 03Local pagepolished interface, "Electronic Invoice" title, download button
- 04Clickthe real address is assembled on the fly, then PowerShell is fetched and run
The first interesting step is the ZIP attachment. Not a new trick, but still effective: many automated controls inspect attachments, and an archive is a container that demands one extra step.
The second is that the file opens locally. It is not a link to a website: it is a page living on the victim's own machine, and therefore one that does not pass a domain reputation check at the moment it is displayed. It shows a legitimate-looking interface — a central box, a title, descriptive text, a "Download invoice" button, and company and tax references in the footer, placed there to raise credibility.
The third is the most instructive, and worth spelling out because it says something about how automated analysis gets sidestepped. According to CSIRT Italia, the malicious behaviour activates only after user interaction, and the payload address is not written into the page: it is generated dynamically through JavaScript on mouse movement.
That is a choice with a precise target. A sandbox that opens the file, waits a few seconds and records what happens sees a page doing nothing, because nobody moves a mouse. An analyst reading the source finds no address to block, because the address does not exist yet. Its precondition is a human gesture.
Again per the advisory, the page is built to hit Windows systems: on macOS or Linux it displays an error message. That reduces noise too — fewer pointless executions, fewer samples reaching the people who analyse them.
Clicking the button leads to the download and execution of PowerShell scripts capable of compromising the machine.
What we do not know, and it is worth saying
This is where the documented part stops, and everything past it would need confirmations that currently do not exist.
It is not attributed to a known group. The final payload is not public: PowerShell is the vehicle, not the destination — it could lead to an infostealer, a loader, or initial access resold to others. Anyone claiming certainty is adding something the advisory does not contain.
The scale is unknown. There are no public figures on how many mailboxes were compromised or how many messages went out, and absent an official number, any figure would be invented.
How the sending mailboxes were compromised is unclear: reused credentials, earlier phishing, an infostealer on a workstation. All reasonable hypotheses, none confirmed.
One limit of this verification should also be recorded: the ACN portal responds unreliably to automated requests, and the reconstruction here follows the content of the CSIRT Italia advisory as presented on its public page. For the full text and technical indicators, that is the source to consult — not this page.
Why this campaign works better than average
The three properties stack badly for defenders.
The context is credible at no cost: an electronic invoice over PEC is not an exotic pretext, it is Italian administrative normality. No story needs building — the story is already the recipient's job.
Technical controls start at a disadvantage: the sender genuinely authenticates, the domain is legitimate, and blocklists based on sender reputation have nothing to grip. There is no "odd" sender to flag.
Automated analysis arrives late: if the malicious address only comes into being when someone moves a mouse, the static sample does not contain it and automated detonation does not produce it.
What to do, in order of usefulness
On behaviour. An invoice arriving over PEC as a ZIP attachment containing an HTML page is an anomaly in itself: Italian electronic invoices travel as XML, not as a web page with a button. A real document does not ask you to press a button to be downloaded — it is already attached. If a click is needed to "download the invoice" that was attached to the message, the right question is: download it from where?
On verification. When in doubt, the confirmation channel must not be the one in the message. You call the supplier on the number you already had, not the one printed in the footer of the suspicious page.
On the client side. Opening .html files that came out of downloaded archives is a behaviour worth making rare and noisy. On the PowerShell side, the item that matters is logging: Script Block Logging and Module Logging enabled, with logs shipped off the machine. If a compromise happens, the difference between reconstructing it and guessing at it lives there.
On the mailbox side. If a campaign departs from compromised PEC accounts, the structural countermeasure is protecting access to those accounts: multi-factor authentication where the provider offers it, credentials not reused elsewhere, and attention to logins from unusual places and hours. A compromised PEC mailbox is not only its owner's problem: it becomes a weapon against everyone in their address book.
On the organisation. The people who open invoices — accounting, the front office, an external firm — are usually not the people who run IT security, and often have no fast channel to ask does this look odd to you?. Opening that channel, and making it consequence-free to use, costs little and is worth more than many tools.
The point
A signature on a PEC message certifies the sender. It does not certify their intentions, and above all it does not certify that the sender still controls their own mailbox.
An obvious distinction once stated, and completely invisible in the moment you open one message among many, on a Monday morning, expecting an invoice.
