A compromised Adform tracking file used browser events, DOM observers and form-field hooks to keep substituting Bitcoin, Ethereum and Tron addresses.2026-08-025 min2026threatsappsec
5 min read
Read format

Adform Served a Script Built to Rewrite Crypto Addresses

A compromised Adform tracking file used browser events, DOM observers and form-field hooks to keep substituting Bitcoin, Ethereum and Tron addresses.

By Justin Howe
A translucent browser field routes luminous wallet-address characters through a glass script module that substitutes part of the sequence.

A compromised JavaScript file served from Adform’s advertising infrastructure could replace cryptocurrency wallet addresses inside a visitor’s browser. A copy captured on July 27 shows malicious code appended to trackpoint-async.js, a shared tracking resource. The code targeted Bitcoin, Ethereum and Tron address formats.

The affected surface was any downstream page that loaded the altered resource. The script did not depend on one clipboard swap. It watched newly inserted page text, scanned form controls, intercepted browser input events and hooked JavaScript value setters so the replacement could return after a user recopied or re-entered an address.

The browser had several routes to the same substitution

The captured file contains two malicious blocks after the legitimate Adform library. Both decode hardcoded replacement addresses with the same six-byte XOR key and apply regular expressions for the three wallet formats. The duplication adds overlapping ways to keep an attacker-controlled value in the browser.

One block registers a MutationObserver that examines new page elements. It also listens for a copy event, then tries to read and rewrite the clipboard after 100 milliseconds. A four-second timer repeats the clipboard check while the page stays open.

The second block covers more surfaces. It walks text nodes already in the document, scans input, textarea and contenteditable elements, and monitors later child and character changes. It replaces the value setter on HTMLInputElement and HTMLTextAreaElement, which lets it alter values written by page code as well as values typed by a person. Event handlers for copy, cut, paste and input add more interception points. A three-second timer rescans form fields.

A browser-surface map showing how the captured Adform script reached clipboard data, page text and editable fields before substituting wallet addresses.

Figure details

The figure places one browser wallet field at the center. On the left, intended Bitcoin, Ethereum or Tron address text enters the page. Around the field, the captured script has four distinct hook groups: copy and cut listeners plus a four-second clipboard poll; paste and input listeners; MutationObserver and text-tree scans for page content; and overridden input and textarea value setters plus a three-second field rescan. Each route reaches the same substitution function, which replaces a matching address with a decoded hardcoded value. A separate attempted HTTP request sends the page hostname and path to 84.32.102.230 on port 7744. The code proves the attempt, not that the request or clipboard access succeeded in every browser context.

The result is a race that favors the injected script. A person can notice the wrong address, copy the intended value again and still have another hook rewrite it before payment. Kevin Beaumont reported that the replacement continued after recopying. He published SHA-256 02ff86c7f9fe609a753ff15bda90baa3c3e0d4a2e559ec4fcf8a3de0954b7c55 for one observed file and said the sample, URLs, domains and IP address had no VirusTotal detections at the time of his check.

One outbound request exposes another line of inquiry

The first malicious block also constructs an HTTP GET to 84.32.102.230:7744. Its query string includes the current page’s hostname and path. That code establishes an attempted transmission path. It does not prove the request completed. Browser mixed-content rules, network controls and page context could prevent it.

The distinction is important during scoping. A connection to the address is stronger evidence than the code alone, but it still does not prove a wallet value changed or that money moved. Conversely, no connection does not clear the page because the replacement logic runs locally and does not require the beacon to succeed.

Adform’s incident notice says the company detected and removed the malicious code on July 27, notified affected clients and found no evidence that the code installed software or persisted after the page closed. Adform also warned that a cached copy could remain in a browser after removal. The public timing is unresolved: Beaumont wrote that he could see malicious activity through Adform over the preceding week.

Adform has not publicly established how many sites or page loads received an altered response, how the deployment path was changed, or whether any transfers were diverted. The captured code answers how substitution worked. It does not establish exposure or loss for a particular visitor.

Defenders should prove which script reached which wallet workflow

Site operators should first identify every page, tag manager and template that loaded s2.adform.net/banners/scripts/st/trackpoint-async.js. Disable the dependency until its integrity and cache state are known. Preserve any browser, proxy, CDN or synthetic-monitoring copy of the response before clearing caches. Hash retained files and compare them with Beaumont’s published sample, but do not treat a hash mismatch as clearance because the public record does not establish that only one altered build existed.

Search DNS, proxy, firewall and browser telemetry for the Adform script host and attempted connections to 84.32.102.230 on port 7744. Preserve the requested hostname and path when available. That evidence can identify an affected page even when the JavaScript response body is gone. Its absence remains a blind spot if encrypted traffic, mixed-content blocking or short retention removed the relevant record.

For pages used to copy, paste or submit cryptocurrency addresses, correlate page views with payment records during the widest defensible exposure window. Compare the intended recipient address from an independent source with the address actually submitted or recorded on-chain. Notify affected users with the exact page and time range, not a platform-wide estimate the evidence cannot support.

Close an exposure only when retained response or cache evidence shows the altered script was not served, or when page-level records show no wallet address interaction while it could have run. If a transfer occurred, closure requires independent confirmation of the destination address and disposition of any mismatch. Missing script bodies, browser history, page telemetry or transaction records leave the event unresolved.

Primary sources

Continue reading

Article figurePinch or double-tap to zoom, then drag to pan.