Loading date…
LinkedIn Twitter Instagram YouTube WhatsApp

Adform Hack Turns Trusted Ad Script Into a Crypto Stealer

Illustration of Adform ad script hijacked to steal cryptocurrency via clipboard hijacking malware

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

Diagram showing Adform's trackpoint-async.js tracking script compromised at s2.adform.net and distributed to client sites

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

Diagram of clipboard hijacker malware replacing a copied crypto wallet address with an attacker-controlled address

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

VirusTotal scan showing 61 antivirus engines returning a clean result for the malicious Adform script

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)

Table of Adform attack indicators of compromise including malicious domain, C2 IP address, and SHA-256 file hash

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

Checklist for detecting Adform malware exposure including firewall logs, HAR captures, and crypto transaction audits

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:

  1. Search outbound proxy/firewall logs for connections to 84.32.102[.]230, especially on port 7744.
  2. Review browser network logs (HAR captures) from any site using Adform's tag manager for unexpected beacon requests matching the /p?h=...&u=... pattern.
  3. 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.
  4. 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.
  5. 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

Diagram of prevention controls against third-party script attacks: Subresource Integrity, Content Security Policy, sandboxing

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-src directive 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

SOC analyst expert tips on third-party script risk, clipboard monitoring, and vendor security assessment

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

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.

Shubham Chaudhary

Welcome to Xpert4Cyber! I’m a passionate Cyber Security Expert and Ethical Hacker dedicated to empowering individuals, students, and professionals through practical knowledge in cybersecurity, ethical hacking, and digital forensics. With years of hands-on experience in penetration testing, malware analysis, threat hunting, and incident response, I created this platform to simplify complex cyber concepts and make security education accessible. Xpert4Cyber is built on the belief that cyber awareness and technical skills are key to protecting today’s digital world. Whether you’re exploring vulnerability assessments, learning mobile or computer forensics, working on bug bounty challenges, or just starting your cyber journey, this blog provides insights, tools, projects, and guidance. From secure coding to cyber law, from Linux hardening to cloud and IoT security, we cover everything real, relevant, and research-backed. Join the mission to defend, educate, and inspire in cyberspace.

Post a Comment

Previous Post Next Post