On March 25, 2019, Kaspersky Lab published an initial summary of a campaign they had been tracking since January. Between June and November 2018, attackers had distributed a backdoored version of ASUS Live Update Utility through ASUS's own update infrastructure, signed with ASUS's own legitimate code-signing certificate. The installer reached, by Kaspersky's estimate, at least 57,000 Kaspersky customers' machines. The true number is more likely 500,000 to one million globally.
And the entire thing was targeted at 600 specific MAC addresses.
The mechanics
ASUS Live Update Utility is pre-installed on essentially every ASUS consumer laptop and desktop. Its job is to auto-update BIOS, drivers, and ASUS-branded utilities. It runs with elevated privileges. It is, in practice, a privileged remote code execution channel held open by the vendor.
Between June 2018 and at least November 2018, attackers distributed a modified Setup.exe through ASUS's update servers at liveupdate01s.asus.com and liveupdate01.asus.com. The binary was signed with a legitimate ASUS Computer Inc. code-signing certificate, two of them actually, both still valid at the time of distribution.
Kaspersky's reverse engineering of the modified installer showed three stages:
- First stage, on every infected machine. The backdoor enumerated the MAC addresses of every network adapter on the host. It computed an MD5 hash of each MAC address and compared it against a hardcoded list of approximately 600 hashes embedded in the binary.
- If no MAC hash matched, exit. The vast majority of the half-million-plus infected machines never proceeded past this check. They were unwitting carriers, not targets.
- If a MAC hash matched, call home. The backdoor contacted a command-and-control server at
asushotfix.comand downloaded a second-stage payload. Details of that second stage have not been fully published, but telemetry from Kaspersky suggested a reconnaissance and persistence toolkit consistent with long-term espionage operations.
The MD5 hashes were the interesting artifact. 600 of them. Hashed, not plaintext, because the attackers did not want anyone analyzing the binary to recover the target list. But MD5 is small, and community brute-force efforts eventually recovered several hundred of the plaintext MACs. They mapped to specific vendor OUI prefixes: ASUS, Intel, Apple, some Samsung. The implication was that the targets were individual researchers, engineers, or executives known by their device MAC addresses to the attacker ahead of time.
Who did it
Kaspersky attributed ShadowHammer to the BARIUM group, also tracked by Microsoft as BARIUM/APT41, Symantec as Blackfly, and FireEye as one branch of APT17/APT41. This is the same actor family responsible for the CCleaner 2017 incident discussed elsewhere in this archive.
The through-line between CCleaner 2017 and ShadowHammer 2019 is too clean to ignore:
- Both used a legitimate software distribution channel of a consumer utility company.
- Both delivered a first-stage loader to a very large population.
- Both filtered down to a narrow target list using host fingerprint checks.
- Both relied on valid code-signing certificates to bypass consumer-grade endpoint defenses.
Kaspersky noted shared code between the ShadowHammer second stage and the CCleaner 2017 third stage, reinforcing the attribution.
ASUS's response, chronologically
- January 31, 2019. Kaspersky sends ASUS the first report of the compromise.
- February to March 2019. ASUS acknowledges privately, begins internal investigation. No public disclosure.
- March 25, 2019. Kaspersky publishes an initial summary. Motherboard (Vice) breaks the story to general press.
- March 26, 2019. ASUS releases a statement confirming the compromise, releases a new signed Live Update Utility (3.6.8), and publishes a standalone tool that lets users check whether their MAC address appears in the target list.
- April 23, 2019. At the SAS 2019 conference, Kaspersky publishes full technical details.
The public disclosure lag, roughly two months from initial vendor notification to public statement, drew criticism. Affected users during that window continued to run the compromised utility unaware. ASUS's defense was that disclosure during investigation might have tipped off the attackers and disrupted remediation. That defense is plausible. It is also the same defense every vendor gives.
The certificates
Two ASUS code-signing certificates were abused. Both were legitimately issued to ASUS Computer Inc. by DigiCert. Both were still on the valid-signing list at the time of the malicious distribution. Both were eventually revoked after disclosure.
The deeper problem was not revocation, it was that both certificates had been used to sign the malicious binary without any apparent compromise of the certificate itself. Kaspersky's analysis, and ASUS's subsequent internal review, pointed to the build pipeline: the attackers had access to machines or processes that could submit binaries to the ASUS signing service, and the signing service signed whatever the build team told it to sign.
This is the same failure mode as CCleaner. Code signing is a production process control. If you can compromise production, signing is automatic. The cert is not the secret; the ability to submit to the signer is.
The targeting, closer
The recovered plaintext MAC addresses were fascinating as an intelligence artifact. Some mapped to researcher laptops, including at security firms. Some appeared tied to specific individuals rather than roles. The list was small and curated.
The operational implication is that the attackers knew, ahead of time, the MAC addresses of machines they wanted to compromise. That knowledge had to come from somewhere, prior reconnaissance, a previous breach, purchased data, or insider information. A 600-entry list is not broad surveillance. It is a target package.
The half-million unaffected infections were collateral. ShadowHammer was designed to be lost in the noise of a consumer-scale update, surfacing only on the very small set of machines the operators actually cared about.
What the industry changed afterwards
Supply chain telemetry moved upstream. Kaspersky and others started looking for malicious binaries inside legitimate signed update streams, not just on endpoints. That required relationships with upstream vendors and, in some cases, direct integrations with CDNs.
ASUS added two-factor approval to its code-signing pipeline. Per the May 2019 ASUS press release, Live Update was moved to an "end-to-end encryption mechanism" and a revised build infrastructure.
Target-list extraction became a standard analysis step. Any binary with an embedded list of hashes, domains, or fingerprints now gets the list brute-forced if the keyspace allows. ShadowHammer was the training example.
The CCleaner-ShadowHammer pattern got a name. Many analysts began referring to this class of attack as "trojanized utility supply chain", distinct from ransomware supply chain (NotPetya) and build-dependency supply chain (event-stream). The class shares a common structure: abuse a vendor's privileged software distribution to reach a curated target list through a very large population.
The accounting
Direct financial damage from ShadowHammer is hard to quantify, because the true second-stage impact happened to 600 high-value targets whose breaches were not publicly disclosed. ASUS's brand took a hit, measurable in the consumer laptop market through 2019. No ASUS class-action suit of meaningful scale materialized.
The harder cost is harder to price: roughly 500,000 users ran a silently compromised update utility for six months with signed binaries from a Tier-1 OEM. If your threat model in 2019 still said "downloaded from the vendor's site and signed by the vendor" equals trust, ShadowHammer is the incident that was supposed to change your mind.
How Safeguard Helps
Safeguard treats vendor update channels as first-class supply chain inputs. Every OEM utility and pre-installed update agent running in your fleet produces an inventory entry with signing certificate fingerprints, update-check endpoints, and SBOM-level component listings so anomalies like ShadowHammer surface as diffs between published versions. Reachability analysis identifies which of those update paths have elevated privileges and network egress, ranking them by blast radius. Griffin AI flags binaries with suspicious embedded structures like target-hash tables, SBOM comparison catches silent additions to signed installers, and policy gates let you quarantine any vendor update that has not passed attestation review before it reaches your privileged endpoints.