Skip to main content
root@rebel:~$ cd /news/threats/appsflyer-web-sdk-hijacked-to-deliver-crypto-stealing-malware_
[TIMESTAMP: 2026-03-14 16:10 UTC] [AUTHOR: Runtime Rebel Intel] [SEVERITY: HIGH]

AppsFlyer Web SDK Hijacked to Deliver Crypto-Stealing Malware

AI-Assisted Analysis
READ_TIME: 3 min read
// executive briefing tl;dr
  • [01] AppsFlyer's Web SDK was hijacked to deliver malicious JavaScript designed to exfiltrate cryptocurrency from users visiting affected websites.
  • [02] Web-based applications utilizing the cdn.appsflyer.com SDK endpoint between August 20 and August 21, 2024, are primary targets.
  • [03] Organizations must verify SDK integrity and implement Subresource Integrity hashes to prevent unauthorized script execution from third-party CDNs.

On August 20, 2024, a sophisticated Supply Chain Attack targeted the infrastructure of AppsFlyer, a prominent mobile attribution and marketing analytics provider. Attackers successfully modified the company’s Web SDK, hosted on their Content Delivery Network (CDN), to include malicious JavaScript designed to steal cryptocurrency from end-users. This incident highlights the ongoing risks associated with third-party dependencies and the high-value target that analytics providers represent to financially motivated threat actors.

AppsFlyer Web SDK Crypto Stealer Analysis

The compromise was first identified by security researcher Cezary Podkul and subsequently confirmed by AppsFlyer. The attack involved unauthorized access to the Amazon S3 bucket used to serve the appsflyer-sdk.js file via cdn.appsflyer.com. According to BleepingComputer, the attackers appended a minified block of malicious code to the end of the legitimate SDK script. This ensured that while the SDK continued to function normally for the website owner—masking the intrusion—the malicious payload executed in the background for every visitor.

Technically, the injected script functioned as a browser-based stealer. It was specifically programmed to monitor for interaction with popular cryptocurrency wallet extensions, such as MetaMask, Coinbase Wallet, and Phantom. By intercepting form submissions or using XSS-like techniques to read DOM elements, the malware attempted to capture private keys, mnemonic phrases, and session tokens. These IoC findings suggest the attackers were prioritizing direct financial theft over long-term persistence or C2 communication.

Detection and Incident Response

Security teams should act immediately to determine if their web properties served the tainted SDK during the window of exposure. To detect AppsFlyer SDK hijacking, SOC analysts should review web server logs or EDR telemetry for any unexpected network requests originating from the browser to unknown domains. While the primary payload was contained within the SDK itself, many stealers attempt to exfiltrate data to actor-controlled infrastructure.

AppsFlyer has since reverted the changes and secured the affected S3 bucket. They stated that the unauthorized access was limited to a specific version of the Web SDK and did not affect their core mobile SDKs or backend data. However, the exact mechanism of the initial compromise—whether via credential theft, misconfiguration, or a secondary CVE in their deployment pipeline—remains under investigation.

Mitigate supply chain attacks in JavaScript environments

This incident underscores a critical failure point in modern web development: the implicit trust of third-party CDNs. To prevent similar compromises from impacting your organization, defenders should implement the following technical controls:

  • Subresource Integrity (SRI): This is the most effective defense against CDN tampering. By including a cryptographic hash in the <script> tag, the browser will refuse to execute the file if even a single byte has been modified by an attacker.
  • Content Security Policy (CSP): Implement a strict CSP to restrict which domains the browser is allowed to send data to, effectively breaking the exfiltration path for most browser-based stealers.
  • Local Hosting: Whenever possible, host critical third-party libraries on your own infrastructure rather than relying on external CDNs. This moves the library into your own security perimeter and change management process.
  • Audit Third-Party Scripts: Regularly inventory all external scripts and evaluate their necessity. Every third-party script represents a potential vector for Privilege Escalation or data theft within the client’s browser context.

Advertisement