Supply Chain Hit: AppsFlyer Web SDK Compromise & Crypto-Stealer Injection
Just saw the BleepingComputer report about the AppsFlyer Web SDK getting hijacked. It looks like another classic supply-chain attack where a trusted CDN-delivered script was swapped out for malicious code targeting cryptocurrency wallets.
This is particularly nasty because the malicious JavaScript runs in the context of the victim's browser, inheriting the trust of the hosting domain. From an analysis perspective, the payload seems to focus on intercepting clipboard data or enumerating browser extensions to siphon keys.
Since this hits the client side, standard server-side WAFs might miss it unless they have specific heuristic signatures for the script content. I've put together a quick KQL query for Sentinel to hunt for clients making requests to known suspicious endpoints associated with this campaign shortly after loading the AppsFlyer SDK:
DeviceNetworkEvents
| where Timestamp > ago(24h)
| where RemoteUrl contains "appsflyer" or InitiatingProcessCommandLine contains "appsflyer"
| where ActionType == "ConnectionSuccess"
| join kind=inner (DeviceNetworkEvents
| where RemoteUrl has_any ("mixer", "crypto", "pool") and RemotePort in (443, 80)
) on DeviceId
| project Timestamp, DeviceName, RemoteUrl, InitiatingProcessFileName
Has anyone moved to enforce Subresource Integrity (SRI) strictly for all third-party marketing SDKs? We've been hesitant due to the overhead of updating hashes every time a vendor does a minor patch, but this might be the tipping point.
We enforce SRI for all our critical third-party scripts. It's a bit of a pain to manage the workflow when vendors like AppsFlyer update, but it completely negates this attack vector. If the hash doesn't match the script we pinned, the browser refuses to execute it.
Here is the command we use in our CI/CD pipeline to generate the SHA-256 hash for our CSP headers automatically:
openssl dgst -sha256 -binary ./appsflyer-sdk.js | openssl base64 -A
From a SOC perspective, this was noisy. The script was obfuscated, but the behavioral trigger was clear: it tried to access the clipboard API immediately after loading, which is abnormal for an attribution SDK.
We wrote a quick Python script to scan our local node_modules and cached assets for the specific obfuscated string pattern found in the malicious payload:
import os, re
malicious_pattern = r'atob\(.*?crypto.*?\)'
for root, dirs, files in os.walk('./static/js'):
for file in files:
if file.endswith('.js'):
with open(os.path.join(root, file), 'r', encoding='utf-8') as f:
if re.search(malicious_pattern, f.read()):
print(f"Suspicious pattern found in {file}")
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access