AppsFlyer Web SDK supply-chain compromise - polymorphic crypto stealer

A malicious actor carried out a supply chain attack by compromising the domain infrastructure that served the AppsFlyer Web SDK, injecting a polymorphic crypto-stealing payload into thousands of websites. The attack bypassed security controls by hijacking DNS at the registrar level, letting the attackers serve malicious code from what appeared to be legitimate AppsFlyer endpoints. The injected script replaced the native window.fetch API, monitored the DOM for cryptocurrency addresses, and sent victim data to attacker-controlled command and control servers. The attack also targeted Node.js server-side environments, exposing SSR frameworks and build pipelines to risk.

What cside's telemetry shows

Before the incident was widely known, cside's Script Insights telemetry recorded unusual behavior from the AppsFlyer Web SDK. Starting on March 1, systems observed that two different script hashes were being served from the official AppsFlyer endpoint across the monitored network. This rotation began before the incident was confirmed, suggesting that the attackers were testing their deployment infrastructure or deliberately serving polymorphic builds to avoid detection.

Telemetry confirms that major platforms loaded the compromised SDK. Specific domains are being withheld while affected organizations complete remediation.

The entry vector: a registrar-level DNS hijack

The attackers did not breach AppsFlyer's AWS infrastructure or internal repositories. They gained control through a registrar-level DNS hijack.

By compromising the domain registrar account for appsflyer.com, the attackers changed its authoritative nameservers. DNS records show that at the start of the attack, the nameservers for appsflyer.com changed from AWS Route 53 to ns1.gcorelabs.net (GCore CDN).

Once in control of DNS, the attackers routed all traffic for websdk.appsflyer.com through their own servers. They intercepted requests for the legitimate SDK and delivered a malicious, downgraded payload. Because the compromise occurred at the DNS layer, this method bypassed standard perimeter defenses and server-side protections.

The primary forensic indicator: a silent version downgrade

Since the attackers controlled DNS, they did not alter the core logic of the AppsFlyer SDK, only used it to deliver their payload.

The clearest sign of tampering was a silent version downgrade. The baseline SDK before the incident was version 0.0.60 (hash 7dbae31c...). During the attack, the version served from the official endpoint reverted to 0.0.59 (hash db0c4f61...). Legitimate updates do not roll back version numbers, marking this as clear evidence of tampering.

By comparing the clean and downgraded SDKs, three modified lines were identified. The attackers removed specific banner endpoints and changed the internal version string.

// Clean SDK (0.0.60)
VERSION:"0.0.60"
banner.appsflyer.com/
banner.appsflyer.com/sb/
dismissInjectPixel // present in clean build

// Compromised SDK (0.0.59)
VERSION:"0.0.59"
banner.appsflyer.com/ // .sb/ endpoint removed
// dismissInjectPixel function removed

The attackers avoided altering fvalid.appsflyer[.]com or wa.appsflyer[.]com/events, which would have broken Subresource Integrity checks. Instead, they used the DNS hijack to route all appsflyer.com traffic through their infrastructure, where the malicious payloads were served.

After the attack, AppsFlyer moved its infrastructure to appsflyersdk[.]com and released a clean 0.0.61 build on that domain. The appsflyersdk[.]com domain, registered in August 2019, is owned by AppsFlyer.

Deobfuscating the polymorphic payloads

Traffic routed through the compromised servers carried the crypto-stealing payload. Analysis of three malicious files revealed a polymorphic deployment approach with two obfuscation schemes targeting separate execution environments.

Build type 1: the browser payload (c7adfa8e)

The first payload, about 170KB in size, runs in the browser's global window scope. It uses custom base91 encoding with an 83-character alphabet to decode a 786-entry string table at runtime.

In a sandbox, this payload replaces window.fetch and registers a MutationObserver to scan the DOM for cryptocurrency addresses. It also adds an internal module called NetHooksmith to the window object (window.lIXMkR.NetHooksmith).

Build type 2: the Node.js wrappers (87e46457 & 9b0fac22)

The second variant, found in two builds of about 250KB each, uses a different obfuscation technique aimed at server environments. Instead of base91, these files enclose core logic in nested Function() constructors and decode strings through a rotating constant array combined with String.fromCodePoint.

These wrappers use getter objects to hook into Node.js contexts: for example get GKSDgsL(){return global} and get F1t0ak(){return exports}. Node.js applications, SSR frameworks, and build pipelines that imported the SDK through npm or bundlers were susceptible.

By intercepting fromCodePoint calls during sandbox execution, the decoded strings were obtained. These confirmed that the wrappers executed the same core fetch replacement logic but used separate wallet addresses, showing dedicated infrastructure for server-side compromise.

The two wallet clusters and C2 infrastructure

Sandbox analysis identified two distinct attacker wallet clusters. The browser payload (Build type 1) contained one set of addresses, and the Node.js payloads (Build type 2) contained another. Both stored these in a global walletAddresses object.

Cluster 1 (browser payload c7adfa8e)

• ETH: 0x1C069d0c73087D0Bae687a6f74a807350dCe1829
• BTC: bc1qr7ngtnsh66demm4vzt4kmqxkqj8sqprnuklalt
• SOL: 4LJi6mAczxZWbUvbMEk5scKhUZNPvfMDTjaVADkPFSsK
• XRP: rntqwheGbZihkabxf6xqZkUKGfTVyRhT14
• TRX: TV6WtAkS4aAMJb3Rt2bfs8LxggF8Kmqbd9

Cluster 2 (Node.js wrappers 87e46457 & 9b0fac22)

• ETH: 0x782B93e52e62F25Bd002eeAA813B5A3fe49C9558
• BTC: bc1q5nlx0exu0efldavw08wnjzpzluudaqh2qwlmjj
• SOL: B5hMeV7B72xqcjypzxxoPmLpNz3bi6VvZApQrnh8YwDP
• XRP: rEL7cB3jQNqtoym8oFJ36w1z3QLy9GjU
• TRX: T062f95a517fc05055b59e12c6f4b2a402

Command and control (C2) endpoints

The payloads communicated with two C2 endpoints on the hijacked infrastructure:

1. https://websdk[.]appsflyer[.]com/v1/api/plugin - fetched new wallet addresses on initialization.
2. https://websdk[.]appsflyer[.]com/v1/api/process - uploaded exfiltrated wallet addresses and metadata using a ?rd= query parameter containing XOR-obfuscated data.

Behavioral signatures and detection

Because the attackers rotated obfuscation schemes and wallet addresses, static signatures like YARA rules were ineffective. The behavior of the payloads, however, is consistent and can be detected.

Security teams should look for these indicators:

• Console output: All payloads print "Generating new wallets..." to the console during initialization.
• fetch replacement: The payload overwrites the native fetch API to intercept outbound requests with cryptocurrency addresses.
• Global object pollution: The payload creates a global walletAddresses object; the browser variant adds window.lIXMkR.NetHooksmith.
• Console suppression: The browser payload uses 32 references to console methods to hide warnings and errors.
• DOM mutation tracking: The browser payload registers a MutationObserver to scan new DOM elements for cryptocurrency address patterns.

Beyond the incident: the legitimate SDK's fingerprinting surface

Reviewing the clean SDK (hash 7dbae31c) revealed that the legitimate AppsFlyer PBA plugin collected extensive device fingerprinting data, including canvas font checks, ad-blocker detection, bot detection, and access to localStorage, sessionStorage, and indexedDB.

The SDK also loads additional code from fvalid.appsflyer[.]com/af/cp.sdk.1.2.7.js at runtime. Although common in marketing SDKs, this represents an ongoing supply-chain risk. Organizations should assess the necessity of such tracking and apply strict Content Security Policies (CSP) and Subresource Integrity (SRI) to all third-party code.

How cside could have helped

A registrar-level domain hijack bypasses perimeter defenses and static analysis. cside's client-side security approach detects and blocks such attacks in real time through the following mechanisms:

• Behavioral anomaly detection: cside monitors script actions rather than static signatures, alerting on attempts to overwrite window.fetch or access cryptocurrency inputs.
• Network exfiltration blocking: If the payload runs, cside's network controls can block outgoing connections to C2 servers, preventing wallet retrieval and data theft.
• Hash rotation alerts: cside's telemetry detected alternating script hashes days before the attack became public, allowing early investigation.
• Version downgrade detection: cside logs exact versions and hashes of third-party scripts. A silent downgrade from v0.0.60 to v0.0.59 would trigger an immediate tampering alert.

By applying zero-trust measures on the client side, cside prevents compromised vendor scripts from exploiting user trust.

Indicators of compromise (IOCs)

• Domain: appsflyer[.]com - Legitimate domain hijacked at registrar level
• Nameserver: ns1.gcorelabs.net - Attacker-controlled nameserver during hijack
• URL (C2): https://websdk[.]appsflyer[.]com/v1/api/plugin - Payload C2 endpoint (wallet rotation)
• URL (C2): https://websdk[.]appsflyer[.]com/v1/api/process - Payload C2 endpoint (exfiltration)
• URL parameter: ?rd= - Contains XOR-obfuscated exfiltration data
• Wallet (ETH): 0x1C069d0c73087D0Bae687a6f74a807350dCe1829 - Cluster 1 (browser payload)
• Wallet (BTC): bc1qr7ngtnsh66demm4vzt4kmqxkqj8sqprnuklalt - Cluster 1 (browser payload)
• Wallet (SOL): 4LJi6mAczxZWbUvbMEk5scKhUZNPvfMDTjaVADkPFSsK - Cluster 1 (browser payload)
• Wallet (ETH): 0x782B93e52e62F25Bd002eeAA813B5A3fe49C9558 - Cluster 2 (Node.js wrappers)
• Console string: "Generating new wallets..." - Plaintext output by all payloads
• Global object: walletAddresses - Injected by all payload variants
• Global object: window.lIXMkR.NetHooksmith - Injected by browser payload
• Version string: 0.0.59 - Downgraded SDK version indicating tampering

Recommendations

1. Immediately compare the SDK version and hash served from any AppsFlyer endpoints you consume with known-good hashes; treat silent downgrades as high-priority tamper alerts.
2. Block or sinkhole outgoing requests to the identified C2 endpoints and associated nameservers until remediation is complete.
3. Harden CSP and apply SRI for third-party resources where feasible; consider self-hosting critical vendor scripts after verifying integrity.
4. Scan server-side build pipelines and SSR deployments for the Node.js wrapper indicators described above and rotate any affected credentials.
5. Deploy cside to watch for API overrides (like fetch) and DOM mutation scanning by third-party scripts.

Forensic details, file hashes, and additional telemetry are available upon request to affected organizations and incident responders.

Note: This post summarizes findings from cside's Script Insights telemetry and sandbox analysis. Some specific domains and additional IOCs are withheld while impacted parties remediate.