The Ad Script Every Site Trusted Just Stole Someone's Crypto
Picture a freelance designer in Austin invoicing a client in Singapore for $4,200 in USDT. The client copies the wallet address from the invoice PDF, pastes it into their exchange, hits send, and the funds vanish into a wallet neither of them has ever seen. Both sides double-check their own systems. Both come up clean. Neither one was ever the target — the website the invoice PDF was hosted on was.
That's the practical, unglamorous horror of what security researcher Kevin Beaumont uncovered when he found that Adform, an advertising technology company trusted by roughly 14,000 businesses and holding close to 30% of the demand-side platform (DSP) market, had a core tracking script silently turned into a cryptocurrency-stealing delivery mechanism. No phishing email. No malicious download. Just a normal page load on a normal website that happened to run Adform's analytics pixel.
This is the story of how that happened, why it slipped past every antivirus engine on VirusTotal, and — more importantly — what your SOC should be watching for right now if your organization runs any third-party ad or analytics script.
Table of Contents
- What Actually Happened at Adform
- How the Clipboard Hijacker Works
- Why Every Antivirus Engine Missed It
- Indicators of Compromise (IOCs)
- Detection: How to Check If You Were Exposed
- Prevention: Locking Down Third-Party Scripts
- Expert Tips From the SOC Floor
- Related Reading
- FAQ
- Final Thoughts
What Actually Happened at Adform
Adform operates a full adtech stack — a demand-side platform (DSP), supply-side platform (SSP), ad servers, and campaign management tools — used across Europe and beyond. Central to that stack is a JavaScript tracking file called trackpoint-async.js, served from Adform's own domain at s2.adform[.]net. Thousands of client websites embed this single script to measure ad performance.
That single point of trust became a single point of failure. Attackers modified the hosted script so that, in addition to its normal tracking duties, it quietly loaded a second-stage payload functioning as a clipboard hijacker and surveillance beacon. Because the script was served directly from Adform's legitimate infrastructure — not a sketchy third-party CDN — it inherited the trust every browser, firewall, and security tool already extended to Adform.
Beaumont's timeline suggests the malicious code had been live for at least a week before discovery. Adform itself has not published a full public breach disclosure detailing customer notification or scope, though later reporting references an internal detection date of July 27, 2026, with the company describing the incident as contained. As of this writing, no indicators-of-compromise list has been published by Adform directly — researchers pieced the picture together independently.
How the Clipboard Hijacker Works
This isn't exotic malware. It's a purpose-built, narrowly scoped piece of code doing one job extremely well: intercepting cryptocurrency payments at the exact moment a human is most likely to trust what's on their screen.
- Continuous clipboard polling: The script checks the victim's clipboard every few seconds for strings matching Bitcoin, Ethereum, or TRON wallet address formats.
- Silent substitution: When a match is found, it replaces the copied address with an attacker-controlled one — instantly, with no visible prompt or warning.
- Persistence through re-copying: If a victim notices the mismatch and copies the correct address again, the malware simply overwrites it again on the next polling cycle. This is the detail that should worry every incident responder — it defeats the most common "gut check" users perform.
- Passive reconnaissance: Independently of the crypto theft, the script logs the victim's IP address, the referring domain, and the specific URL path, then sends that data to an external command-and-control (C2) endpoint. That telemetry effectively let the attacker map their own blast radius in real time — which sites were compromised, and how much traffic was flowing through them.
Because the payload rides on a script already embedded for a completely different, legitimate purpose, there's no separate "malicious download" event for endpoint detection and response (EDR) tools to flag. The compromise happens entirely in the browser's execution context of a page the user already trusted.
Why Every Antivirus Engine Missed It
Here's the part that should change how your team thinks about third-party script risk: when researchers submitted the malicious file, domain, and associated IP address to VirusTotal, every single one of the 61 integrated engines returned a clean result.
That's not a failure of any one vendor. It's a structural blind spot. Reputation-based and signature-based detection systems are built to flag known-bad infrastructure. A script served from a legitimate advertising company's own domain, with years of clean history and enormous legitimate traffic volume, doesn't look like known-bad infrastructure — it looks like the opposite. That's precisely why supply chain compromises of trusted third-party vendors are so disproportionately effective compared to phishing or drive-by malvertising from disposable domains.
Indicators of Compromise (IOCs)
If your organization uses Adform's tracking services — or if you're auditing logs defensively even without a known relationship — check for the following:
| Type | Value | Description |
|---|---|---|
| Domain | s2.adform[.]net | Compromised Adform subdomain serving the malicious script |
| Malicious URL | hxxps://s2[.]adform.net/banners/scripts/st/trackpoint-async.js | Trojanized tracking script delivering the clipboard hijacker |
| C2 IP Address | 84.32.102[.]230 (port 7744) | Attacker-controlled beacon / command-and-control server |
| Beacon Pattern | hxxp://84.32.102[.]230:7744/p?h=<domain>&u=<path> | Exfiltration request pattern including victim domain and URL path |
| File Hash (SHA-256) | 02ff86c7f9fe609a753ff15bda90baa3c3e0d4a2e559ec4fcf8a3de0954b7c55 | Malicious payload — flags clean on VirusTotal, do not rely on AV alone |
Note: These IOCs may already be stale by the time you read this. Beaumont observed the malicious code disappearing in real time as he was documenting it — likely because either Adform or the attackers realized the operation had been exposed. Treat this as a historical snapshot, not a live blocklist.
Detection: How to Check If You Were Exposed
Whether you're a website operator embedding Adform's script, a SOC analyst reviewing proxy logs, or an individual who transacted crypto recently on a site with ads, here's a practical checklist:
- Search outbound proxy/firewall logs for connections to
84.32.102[.]230, especially on port 7744. - Review browser network logs (HAR captures) from any site using Adform's tag manager for unexpected beacon requests matching the
/p?h=...&u=...pattern. - Don't trust a clean VirusTotal result as proof of safety for this specific incident — the entire point of this compromise is that reputation-based detection missed it.
- Audit any cryptocurrency transaction completed while browsing a site that embeds Adform tracking during the exposure window (reported as at least the last week of July 2026). Compare the destination address in your transaction history against what you intended to send to, character by character.
- Use browser developer tools to inspect scripts loaded from third-party ad and analytics domains on your own production sites — not just once, but as a recurring integrity check.
curl -s https://s2.adform.net/banners/scripts/st/trackpoint-async.js | sha256sum
What this does: pulls the current version of the script directly and hashes it so you can compare against a known-good baseline over time. When to use it: as a lightweight, repeatable integrity check if your organization embeds this script and wants early warning of tampering, rather than waiting on a vendor disclosure. Expected output: a SHA-256 hash string — if it changes unexpectedly between checks with no corresponding vendor changelog, treat it as a red flag worth investigating.
Prevention: Locking Down Third-Party Scripts
You cannot audit your way out of trusting a vendor completely — but you can shrink the blast radius when that trust gets violated.
- Subresource Integrity (SRI): Where technically feasible, use SRI hashes on third-party scripts so the browser refuses to execute a file that doesn't match the expected hash. This is the single most direct technical control against exactly this kind of compromise.
- Content Security Policy (CSP): Restrict which domains scripts can load from and which external endpoints a page is allowed to connect to. A tight
connect-srcdirective would have blocked outbound beaconing to the attacker's IP even if the script itself executed. - Script sandboxing / iframing: Where possible, isolate third-party ad and tracking scripts in sandboxed iframes with restricted permissions rather than running them in the same execution context as sensitive page content.
- Vendor risk reviews aren't one-time events: A vendor's security posture at contract signing tells you nothing about their posture eighteen months later. Build periodic re-assessment into your third-party risk program, especially for vendors with script-level access to your pages.
- User-side hygiene for crypto transactions: Encourage anyone handling wallet addresses to verify the first and last several characters against a second source before broadcasting a transaction — not as a replacement for technical controls, but as a last line of defense.
Expert Tips From the SOC Floor
A few things worth internalizing beyond this specific incident:
- Treat "clean on VirusTotal" as one data point, not a verdict — especially for scripts served from high-reputation domains with massive legitimate traffic.
- Ad-tech and analytics scripts are frequently exempted from the same scrutiny applied to other third-party code, simply because they're "just tracking pixels." This incident is a direct argument against that assumption.
- Clipboard-monitoring malware is quiet by design. If your threat model doesn't already account for clipboard access as a sensitive API, it should — particularly for any organization or individual regularly handling wallet addresses, license keys, or credentials via copy-paste.
- Silence from a vendor after a researcher's public disclosure is itself a signal. Build vendor communication response time into how you score third-party risk going forward.
Related Cybersecurity Topics You Should Explore
- The Security Story Hidden Inside Windows 11's Big Update
- SplitVPN Data Breach: 865K Users Exposed, 'No-Logs' Was a Lie
- Brinks Home Data Breach: The Phone Call That Cost Millions
- GPG Command Tutorial: The Encryption Trick Real SOC Analysts Use
- AI Found a Chrome Bug Hiding for 13 Years. Here's How.
- This Open-Source AI Agent Turns ChatGPT Into a Hacker
- GenieLocker Ransomware Explained: How Toy Ghouls Hack ESXi Servers
- ln Command Explained: How Hackers Abuse Symlinks to Hack Root
- NVIDIA BlueField Flaw Lets Hackers Hijack Cloud Servers
- NGINX Buffer Overflow (CVE-2026-42533): Patch Before It's Exploited
- Windows 11 Finally Fixes Its Slowest File Deletion Problem
- Microsoft Just Killed the Fake KMS Server Trick for Good
FAQ
Q: Is my crypto at risk just from visiting a website that uses Adform?
A: The risk applies specifically to copying and pasting wallet addresses while the malicious script was active on a site using the compromised tracking file. Simply browsing without a crypto transaction did not directly expose funds, though your IP and browsing path may have been logged.
Q: Has Adform confirmed the breach officially?
A: As of this writing, Adform has not published a detailed public disclosure naming affected customers or scope. Some later reports reference an internal detection date of July 27, 2026, and describe the incident as contained.
Q: Why didn't antivirus software catch this?
A: The malicious script was served from Adform's own trusted, high-reputation domain, which reputation-based and signature-based AV engines are not designed to flag. All associated files, domains, and IPs returned clean results across 61 VirusTotal engines.
Q: What should I do if I sent a crypto transaction through a site using Adform recently?
A: Review your transaction history and compare the destination address, character by character, against the intended recipient's address from a separate trusted channel. If it doesn't match, the funds cannot typically be recovered due to the irreversible nature of blockchain transactions.
Q: Can Subresource Integrity (SRI) fully prevent this kind of attack?
A: SRI significantly reduces risk by causing the browser to refuse execution of a modified script, but it requires the site operator to implement and maintain it correctly, and vendors must support versioned, stable script URLs for it to work reliably.
Final Thoughts
The uncomfortable truth in this incident isn't the clipboard-hijacking technique itself — that's a known malware pattern. It's the delivery mechanism: a script that tens of thousands of websites embedded specifically because it was boring, routine, and trusted. That's exactly the profile attackers look for when picking a supply chain target, and it's exactly the profile most security teams under-scrutinize.
If you run a website with third-party ad or analytics tags, this is a good week to actually look at what those scripts are doing — not just whether they load, but what they connect to. If something in your logs matches the indicators above, don't wait on an official vendor statement to start investigating.
Found this breakdown useful? Share it with your SOC team, drop a comment with what you're seeing in your own logs, and subscribe for the next deep dive as more details on this incident emerge.







