Résumé
Operation ShadowHammer, revealed by Kaspersky in early 2019, backdoored one of the most trusted programs on millions of computers: the ASUS Live Update utility that ships pre-installed on ASUS PCs to deliver driver and firmware updates. An APT group compromised ASUS's own update servers and pushed a malicious version, signed with a legitimate ASUS certificate so it looked completely authentic, to over a million users. But the attackers did not want a million victims. The malware checked each machine's network address against a hard-coded list of about 600 specific targets and only activated for them, ignoring everyone else. It is the textbook surgical supply-chain attack: poison the many to reach a precise few.
How it happened
ASUS Live Update comes pre-installed on most ASUS computers and fetches updates automatically with a high level of trust. An APT group compromised ASUS's official update infrastructure in mid-to-late 2018 and replaced the legitimate updater with a backdoored version. To make it indistinguishable from a real update, they backdoored an old, legitimately-signed 2015-era build (overwriting a small code block in place to keep the file size identical) and signed it with stolen ASUS code-signing certificates, switching to a second valid ASUS certificate when the first expired mid-campaign, a sign of sustained access to ASUS's signing capability.
So the malicious update arrived from ASUS's real servers, signed by ASUS, and over a million users installed it. But it was built as a sniper, not a shotgun. On each machine the malware read the network adapter's MAC address, computed its MD5 hash, and compared it against hard-coded tables of around 600 target hashes. Only for those few did it reach out for a second-stage payload; for everyone else, the backdoor simply sat inert. It is a supply-chain attack used as a precision-guided weapon.
The damage
More than a million users received the backdoored updater, while roughly 600 carefully chosen machines were the real targets. Kaspersky discovered the operation at the end of January 2019, briefly disclosed it in March, and published the full technical analysis in April; ASUS issued a fix and a tool that let users check whether their machine was on the target list. ASUS publicly downplayed the scale, calling it "a very small and specific user group," which contradicted Kaspersky's roughly one-million distribution figure, a now-classic example of vendor minimisation during a supply-chain disclosure. The intended victims behind the ~600 addresses were never fully identified publicly. The tradecraft, stolen certificates, file-size matching, and razor-narrow targeting, pointed to a sophisticated state-linked group (Kaspersky's BARIUM, overlapping with the Winnti / APT41 cluster), the same actor tied to the CCleaner attack, though the link was assessed as probable rather than proven.
Why ASUS ShadowHammer still matters
It is nearly identical in shape to the CCleaner compromise, and attributed to the same actor cluster: take over a trusted vendor's update channel, sign the malware with a valid certificate, distribute it to millions as a funnel, and activate only on a tiny curated list of targets. Kaspersky found the same technique used against software from at least three other vendors in Asia, so ShadowHammer was one node in a wider campaign, not an isolated ASUS event. The deeper lesson, as the researchers put it, is that your compiler and pipeline can lie to you: the malicious binary diverged from the source, so source-code review alone could never have caught it. The defences are the by-now familiar supply-chain hardening: isolate the build and release pipeline, protect signing keys in hardware, require reproducible and verified builds with provenance, monitor the integrity of released artifacts and update servers (not just source), and minimise and tightly control auto-updating pre-installed software.
Comment le corriger
- Pull the trojanized updater, ship a clean signed rebuild, and give users a way to check whether they were among the targeted machines.
- Rebuild the release pipeline from trusted media and rotate the compromised code-signing certificates and all CI/CD credentials.
- Hunt among high-value users for the second-stage payload and persistence.
Comment l’éviter
- Harden and isolate the build and release pipeline, protect signing keys in hardware, and require reproducible, verified builds with provenance.
- Monitor the integrity of released artifacts and update servers, not just source code; the malware was served from the real servers, validly signed.
- Minimize and tightly control auto-updating pre-installed software, which is a high-privilege, high-trust attack surface.
- Remember a valid signature proves origin, not safety; downstream defenders should still watch update behavior.
Références
- https://securelist.com/operation-shadowhammer-a-high-profile-supply-chain-attack/90380/
- https://securelist.com/operation-shadowhammer/89992/
- https://www.tomshardware.com/news/asus-responds-operation-shadowhammer-report-cybersecurity,38922.html
- https://spectrum.ieee.org/operation-shadowhammer-exploited-weaknesses-in-the-software-pipeline
Vulnérabilités liées
Tout Supply chain →- CRITICALGHSA-93qj-5q5v-3c2h
Trojanized pantheon-agents 0.6.1 and 0.6.2 on PyPI ship a credential stealer (supply-chain account compromise)
- CRITICALNPM-REDHAT-MIASMA-2026
In June 2026 the npm supply-chain worm finally produced something genuinely new and frightening: malicious packages that were signed and carried valid build provenance. Attackers used a compromised GitHub account inside Red Hat's own organisation to publish trojanised versions of 31 packages in the @redhat-cloud-services namespace through Red Hat's legitimate CI pipeline, so the poisoned releases arrived with authentic attestations proving they were built by the real build system. The payload, nicknamed Miasma, was a lightly re-skinned copy of Mini Shai-Hulud, a worm that a group called TeamPCP had open-sourced for anyone to reuse weeks earlier. No Red Hat customers were harmed, because Red Hat strips install scripts before deployment, but the permanent lesson is uncomfortable: a signature proves where a package was built, not that the build was clean.
- CRITICALNPM-AXIOS-2026
On 31 March 2026 the single most widely used HTTP client in the JavaScript world was turned into malware for about three hours. Axios carries well over 100 million weekly downloads and sits as a transitive dependency underneath a huge share of the npm ecosystem, so when a North Korea-nexus actor took over the maintainer's account and published two booby-trapped versions, the blast radius was enormous even though the bad versions were live only for one early-morning window. The poisoned releases pulled in a hidden dependency that ran on install and dropped a cross-platform remote access trojan onto developer machines and CI runners. It is the case study in why a few hours of a popular package being compromised is still a global incident, and in why a maintainer's own laptop is now a nation-state target.
- HIGHSC-NOTEPADPP-CHRYSALIS-2025
In 2025, a Chinese state-linked espionage group hijacked the update channel of Notepad++, one of the most widely installed Windows text editors, to plant a custom backdoor on a handful of carefully chosen targets. The attackers never touched Notepad++'s source code or its signing keys. Instead they compromised the third-party shared-hosting server that delivered updates, and abused the fact that the WinGUp updater shipped without any integrity check on what it downloaded (tracked as CVE-2025-15556). For machines on their target list, WinGUp was silently redirected to attacker-controlled servers that served a trojanized installer; everyone else kept receiving the genuine update. The campaign ran from roughly June to December 2025 and was only made public in February 2026 by Rapid7, with Kaspersky and Broadcom/Symantec corroborating it independently.
- HIGHSC-ESCAN-RELOAD-2026
On or around January 20, 2026, attackers who had broken into a regional update server for eScan, the antivirus product made by India's MicroWorld Technologies, pushed a trojanized Reload.exe through the legitimate update channel during a window of roughly two hours. The security software itself became the delivery vehicle for malware. The malicious binary carried eScan's code-signing identity, but its signature was actually invalid; it ran anyway because the updater trusted the channel rather than rigorously validating the signature. Once on a host, the malware rewrote the Windows HOSTS file to cut eScan off from its own update servers, blinded script scanning, and reached out to takedown-resistant command-and-control hosted on blockchain naming systems. Morphisec disclosed the campaign, with Kaspersky and Darktrace corroborating it independently.
- CRITICALNPM-SHAI-HULUD-2-2025
Shai-Hulud is the nightmare the npm ecosystem had long feared: a self-replicating worm. First seen in September 2025 and back in a more aggressive wave around 21-24 November 2025 ("The Second Coming"), it does not just poison one package and wait. When its malware runs in a developer's environment, it harvests every secret it can find, npm tokens, GitHub tokens, cloud keys, then uses those stolen npm tokens to automatically publish itself into other packages the victim maintains, spreading from maintainer to maintainer on its own. The second wave hit more than 25,000 GitHub repositories across roughly 500 compromised accounts, leaked the stolen secrets into public repos, and, if it failed to steal credentials, tried to wipe the victim's home directory. It is the moment supply-chain malware learned to propagate like a biological infection.