Adform's Breach Made the Ad Tracker the Malware
A trojanized trackpoint-async.js swapped crypto wallet addresses across thousands of sites while every scanner called it clean.
For a few days in late July, one of Europe's biggest ad-tech platforms was a malware distribution network. Attackers trojanized Adform's trackpoint-async.js — the tracking script its customers embed directly in their pages, served from s2.adform.net — and turned it into a cryptocurrency clipper. Adform says it detected and removed the malicious code on July 27; security researcher Kevin Beaumont, who published the details on July 31, found evidence the tampered script had been live for longer, with archived malicious samples dating to at least July 26.
The payload was old-school in the best way, from the attacker's perspective. It watched for Bitcoin, Ethereum, and TRON wallet addresses — intercepting copy, cut, and paste events, rewriting addresses in input fields and contenteditable elements, even hooking the value setters on input and textarea so programmatic writes got swapped in transit — and replaced them with attacker-controlled addresses. A loop re-ran the swap every three seconds, so noticing the wrong address and re-copying didn't save you. The script also beaconed the victim's page hostname and path to a bare IP, 84.32.102[.]230, on port 7744. At the time Beaumont found it, every security vendor on VirusTotal rated the file clean.
The headline take — Zack Whittaker's newsletter ran with "proving once again why ad blockers are necessary" — is satisfying and not wrong. But it's aimed at users. If you build for the web, the uncomfortable version is aimed at you: this wasn't a rogue ad creative slipping past review. It was the vendor's own script, served from the vendor's own CDN, on the URL thousands of engineering teams deliberately pasted into their templates. Ad blockers saved users. Nothing saved the sites.
This is a supply-chain attack, not malvertising
Malvertising has a known shape: an attacker buys inventory or compromises a creative, and a malicious ad rides through the auction pipeline into an iframe. The industry has (imperfect) defenses for that — creative scanning, sandboxed frames, SafeFrame.
None of that applied here, because trackpoint isn't a creative. It's a conversion-tracking tag that runs in the top frame of the embedding page, in the page's origin, with full DOM access — that's its entire value proposition. Which means the attackers didn't compromise an ad; they compromised the trusted first-party context of every page carrying the tag. Beaumont puts the script's footprint at roughly 14,000 businesses; Adform's own material says the platform enables about 1.5 billion ad impressions daily. Adform hasn't said how many page loads served the poisoned file, and probably can't.
The lineage here isn't malvertising at all. It's event-stream in 2018, where an npm dependency was backdoored to drain Copay bitcoin wallets. It's Magecart skimmers riding third-party scripts into checkout pages. It's the Polyfill.io takeover in mid-2024, when a trusted CDN domain changed hands and started injecting code into the 100,000-plus sites still hotlinking it. The pattern is consistent: attackers stopped breaching individual sites and started breaching the shared script infrastructure everyone embeds. Ad-tech tags are the fattest target in that category — enormous reach, first-party execution, and code that's supposed to change server-side without anyone reviewing it.
Why your existing defenses didn't apply
The standard answer to "untrusted remote script" is Subresource Integrity: pin the hash, and a swapped file fails to load. SRI is useless for ad-tech tags by design — vendors ship updates continuously, contracts require loading from their CDN, and a pinned hash would break the integration weekly. The business model of ad tech is structurally incompatible with the one browser primitive built for exactly this attack.
Content Security Policy is the defense that would have actually bitten. The stolen data went to a bare IP on a weird port — no connect-src allowlist on earth includes 84.32.102.230:7744. A site with an enforced CSP would have had the exfil beacon blocked and, more importantly, would have had report noise screaming about it on day one. But pages that carry ad tags overwhelmingly run permissive CSPs or none, precisely because ad tech's daisy-chained script loading makes strict policies painful to maintain. The attacker's biggest ally was the ecosystem's pre-existing surrender.
What to actually do
Concretely, this week:
- If you embed Adform tags: the company's incident notice says the code didn't persist and ran only while an affected page was open. Check whether your pages loaded
trackpoint-async.jsbetween July 26–27, and if you're anywhere near crypto flows, tell your users to verify any addresses they copied that week. - Inventory your tags like dependencies. Every
<script src>from a marketing vendor — and everything your tag manager loads transitively — is remote code execution granted to a third party, renewed on every page view. Most teams can't produce this list. Produce it. - Deploy CSP in report-only mode, then enforce
connect-src. It won't stop the DOM tampering, but it turns silent exfiltration into an alert, which is the difference between July 26 and July 31. - Snapshot and diff third-party scripts. Beaumont's timeline was reconstructed partly from Archive.org captures. A cron job fetching your third-party scripts and diffing them is embarrassingly cheap detection that almost nobody runs.
There's also a regulatory shoe yet to drop. The beacon shipped visitors' IP addresses, hostnames, and URL paths to the attacker — browsing data that's personal data under GDPR — and Whittaker reports Adform is still investigating whether browsing history was taken. Publishers who embedded the tag may have breach-notification questions their marketing team never signed up for.
The verdict
Adform's response was decent — fast containment, a public notice, cooperation with authorities. But the still-open questions are the story: no disclosed initial-access vector, no attacker attribution, no count of affected page loads, no accounting of stolen funds. And the structural problem survives contact with the incident report. Ad tech sells unpinnable, remotely mutable code running in your page's origin; that's a supply chain with no lockfile, and after event-stream, Polyfill.io, and now this, "trusted vendor" is doing an amount of load-bearing work that no engineering team would accept from a package registry. Expect a repeat with a different vendor's tag. The only question is whether your pages will be able to tell you when it happens — because the scanners, once again, said everything was clean.
Sources & further reading
- Online ad giant Adform was hacked, proving once again why ad blockers are needed — this.weekinsecurity.com
- Adform compromised to serve crypto stealer via supply chain attack — doublepulsar.com
- Online ad firm Adform's script compromised to steal cryptocurrency — bleepingcomputer.com
- Hackers Poison Adform Script to Swap Crypto Wallet Addresses Across Customer Sites — thehackernews.com
- Security Incident - Company Update — site.adform.com
Emeka has spent over a decade tracking threat actors, vulnerability disclosures, and the evolving landscape of application security, bringing a sharp continent-spanning perspective to his reporting. He's known for translating dense CVE advisories into clear, actionable context that developers and security teams alike actually read.
Discussion 1
supply chain attacks through ad tech are the obvious nightmare. every site loads this, antivirus sleeps.