Un acteur malveillant a mené une attaque sur la chaîne d'approvisionnement en compromettant l'infrastructure de domaine qui servait le SDK Web AppsFlyer, injectant un payload de vol de cryptomonnaies polymorphique dans des milliers de sites web. L'attaque a contourné les contrôles de sécurité en détournant le DNS au niveau du registrar, permettant aux attaquants de servir du code malveillant depuis ce qui semblait être des points de terminaison AppsFlyer légitimes. Le script injecté remplaçait l'API native window.fetch, surveillait le DOM à la recherche d'adresses de cryptomonnaies et envoyait les données des victimes vers des serveurs de commande et contrôle sous le contrôle des attaquants. L'attaque ciblait également les environnements serveur Node.js, exposant les frameworks SSR et les pipelines de build à des risques.
Ce que montre la télémétrie de cside
Avant que l'incident soit largement connu, la télémétrie Script Insights de cside avait enregistré un comportement inhabituel de la part du SDK Web AppsFlyer. À partir du 1er mars, les systèmes ont observé que deux hachages de script différents étaient servis depuis le point de terminaison officiel d'AppsFlyer sur le réseau surveillé. Cette rotation a débuté avant que l'incident soit confirmé, ce qui suggère que les attaquants testaient leur infrastructure de déploiement ou servaient délibérément des builds polymorphiques pour éviter la détection.
La télémétrie confirme que des plateformes majeures ont chargé le SDK compromis. Les domaines spécifiques sont retenus pendant que les organisations affectées finalisent leur remédiation. Pour les contrôles prescriptifs qui contiennent ce type d'incident, consultez nos bonnes pratiques pour sécuriser les scripts tiers contre les compromissions de la chaîne d'approvisionnement.
Le vecteur d'entrée : un détournement DNS au niveau du registrar
Les attaquants n'ont pas compromis l'infrastructure AWS d'AppsFlyer ni ses dépôts internes. Ils ont pris le contrôle via un détournement DNS au niveau du registrar.
En compromettant le compte du registrar de domaine pour appsflyer.com, les attaquants ont modifié ses serveurs de noms faisant autorité. Les enregistrements DNS montrent qu'au début de l'attaque, les serveurs de noms d'appsflyer.com sont passés d'AWS Route 53 à ns1.gcorelabs.net (GCore CDN).
Une fois le contrôle du DNS acquis, les attaquants ont routé tout le trafic vers websdk.appsflyer.com via leurs propres serveurs. Ils ont intercepté les requêtes vers le SDK légitime et livré un payload malveillant et rétrogradé. Comme la compromission s'est produite au niveau de la couche DNS, cette méthode a contourné les défenses périmètriques standard et les protections côté serveur.
Le principal indicateur forensique : un rétrogradage silencieux de version
Puisque les attaquants contrôlaient le DNS, ils n'ont pas altéré la logique centrale du SDK AppsFlyer, ils l'ont simplement utilisé pour livrer leur payload.
Le signe le plus évident d'altération était un rétrogradage silencieux de version. Le SDK de référence avant l'incident était la version 0.0.60 (hachage 7dbae31c...). Pendant l'attaque, la version servie depuis le point de terminaison officiel est revenue à 0.0.59 (hachage db0c4f61...). Les mises à jour légitimes ne reviennent jamais en arrière sur les numéros de version, ce qui constitue une preuve claire d'altération.
En comparant les SDK propre et rétrogradé, trois lignes modifiées ont été identifiées. Les attaquants ont supprimé des points de terminaison banner spécifiques et modifié la chaîne de version interne.
// SDK propre (0.0.60)
VERSION:"0.0.60"
banner.appsflyer.com/
banner.appsflyer.com/sb/
dismissInjectPixel // présent dans le build propre
// SDK compromis (0.0.59)
VERSION:"0.0.59"
banner.appsflyer.com/ // point de terminaison .sb/ supprimé
// fonction dismissInjectPixel supprimée
Les attaquants ont évité de modifier fvalid.appsflyer[.]com ou wa.appsflyer[.]com/events, ce qui aurait déclenché les vérifications de Subresource Integrity. À la place, ils ont utilisé le détournement DNS pour router tout le trafic appsflyer.com via leur infrastructure, depuis laquelle les payloads malveillants étaient servis.
Après l'attaque, AppsFlyer a migré son infrastructure vers appsflyersdk[.]com et publié un build propre 0.0.61 sur ce domaine. Le domaine appsflyersdk[.]com, enregistré en août 2019, appartient à AppsFlyer.
Désobfuscation des payloads polymorphiques
Le trafic routé via les serveurs compromis transportait le payload de vol de cryptomonnaies. L'analyse de trois fichiers malveillants a révélé une approche de déploiement polymorphique avec deux schémas d'obfuscation ciblant des environnements d'exécution distincts.
Type de build 1 : le payload navigateur (c7adfa8e)
Le premier payload, d'environ 170 Ko, s'exécute dans la portée globale window du navigateur. Il utilise un encodage base91 personnalisé avec un alphabet de 83 caractères pour décoder une table de chaînes de 786 entrées à l'exécution.
Dans un sandbox, ce payload remplace window.fetch et enregistre un MutationObserver pour analyser le DOM à la recherche d'adresses de cryptomonnaies. Il ajoute également un module interne appelé NetHooksmith à l'objet window (window.lIXMkR.NetHooksmith).
Type de build 2 : les wrappers Node.js (87e46457 & 9b0fac22)
La deuxième variante, trouvée dans deux builds d'environ 250 Ko chacun, utilise une technique d'obfuscation différente ciblant les environnements serveur. Au lieu du base91, ces fichiers encapsulent la logique centrale dans des constructeurs Function() imbriqués et décodent les chaînes via un tableau de constantes rotatif combiné à String.fromCodePoint.
Ces wrappers utilisent des objets getter pour s'accrocher aux contextes Node.js : par exemple get GKSDgsL(){return global} et get F1t0ak(){return exports}. Les applications Node.js, les frameworks SSR et les pipelines de build qui importaient le SDK via npm ou des bundlers étaient susceptibles d'être affectés.
En interceptant les appels fromCodePoint lors de l'exécution en sandbox, les chaînes décodées ont été obtenues. Celles-ci ont confirmé que les wrappers exécutaient la même logique centrale de remplacement de fetch, mais utilisaient des adresses de portefeuilles distinctes, révélant une infrastructure dédiée à la compromission côté serveur.
Les deux clusters de portefeuilles et l'infrastructure C2
L'analyse en sandbox a identifié deux clusters de portefeuilles attaquants distincts. Le payload navigateur (type de build 1) contenait un ensemble d'adresses, et les payloads Node.js (type de build 2) en contenaient un autre. Les deux les stockaient dans un objet global walletAddresses.
Cluster 1 (payload navigateur c7adfa8e)
- ETH :
0x1C069d0c73087D0Bae687a6f74a807350dCe1829 - BTC :
bc1qr7ngtnsh66demm4vzt4kmqxkqj8sqprnuklalt - SOL :
4LJi6mAczxZWbUvbMEk5scKhUZNPvfMDTjaVADkPFSsK - XRP :
rntqwheGbZihkabxf6xqZkUKGfTVyRhT14 - TRX :
TV6WtAkS4aAMJb3Rt2bfs8LxggF8Kmqbd9
Cluster 2 (wrappers Node.js 87e46457 & 9b0fac22)
- ETH :
0x782B93e52e62F25Bd002eeAA813B5A3fe49C9558 - BTC :
bc1q5nlx0exu0efldavw08wnjzpzluudaqh2qwlmjj - SOL :
B5hMeV7B72xqcjypzxxoPmLpNz3bi6VvZApQrnh8YwDP - XRP :
rEL7cB3jQNqtoym8oFJ36w1z3QLy9GjU - TRX :
T062f95a517fc05055b59e12c6f4b2a402
Points de terminaison de commande et contrôle (C2)
Les payloads communiquaient avec deux points de terminaison C2 sur l'infrastructure détournée :
https://websdk[.]appsflyer[.]com/v1/api/plugin- récupérait de nouvelles adresses de portefeuilles à l'initialisation.https://websdk[.]appsflyer[.]com/v1/api/process- téléversait les adresses de portefeuilles exfiltrées et les métadonnées via un paramètre de requête?rd=contenant des données obfusquées par XOR.
Signatures comportementales et détection
Comme les attaquants faisaient tourner les schémas d'obfuscation et les adresses de portefeuilles, les signatures statiques telles que les règles YARA étaient inefficaces. Le comportement des payloads, en revanche, est constant et peut être détecté.
Les équipes de sécurité doivent rechercher ces indicateurs :
- Sortie console : Tous les payloads affichent "Generating new wallets..." dans la console lors de l'initialisation.
- Remplacement de
fetch: Le payload écrase l'APIfetchnative pour intercepter les requêtes sortantes contenant des adresses de cryptomonnaies. - Pollution de l'objet global : Le payload crée un objet global
walletAddresses; la variante navigateur ajoutewindow.lIXMkR.NetHooksmith. - Suppression de la console : Le payload navigateur utilise 32 références aux méthodes
consolepour masquer les avertissements et les erreurs. - Surveillance des mutations DOM : Le payload navigateur enregistre un
MutationObserverpour analyser les nouveaux éléments DOM à la recherche de patterns d'adresses de cryptomonnaies.
Au-delà de l'incident : la surface de fingerprinting du SDK légitime
L'examen du SDK propre (hachage 7dbae31c) a révélé que le plugin PBA AppsFlyer légitime collectait des données de fingerprinting de l'appareil étendues, notamment des vérifications de polices canvas, la détection de bloqueurs de publicités, la détection de bots, et l'accès à localStorage, sessionStorage et indexedDB.
Le SDK charge également du code supplémentaire depuis fvalid.appsflyer[.]com/af/cp.sdk.1.2.7.js à l'exécution. Bien que courant dans les SDK marketing, cela représente un risque permanent pour la chaîne d'approvisionnement. Les organisations devraient évaluer la nécessité de ce type de tracking et appliquer des Content Security Policies (CSP) et une Subresource Integrity (SRI) strictes à tout code tiers.
Comment cside aurait pu aider
Un détournement de domaine au niveau du registrar contourne les défenses périmètriques et l'analyse statique. L'approche de sécurité côté client de cside détecte et bloque ce type d'attaques en temps réel grâce aux mécanismes suivants :
- Détection d'anomalies comportementales : cside surveille les actions des scripts plutôt que les signatures statiques, alertant sur les tentatives d'écrasement de
window.fetchou d'accès aux saisies de cryptomonnaies. - Blocage de l'exfiltration réseau : Si le payload s'exécute, les contrôles réseau de cside peuvent bloquer les connexions sortantes vers les serveurs C2, empêchant la récupération des portefeuilles et le vol de données.
- Alertes sur la rotation des hachages : La télémétrie de cside a détecté l'alternance des hachages de scripts plusieurs jours avant que l'attaque ne soit rendue publique, permettant une investigation précoce.
- Détection des rétrogradages de version : cside enregistre les versions et hachages exacts des scripts tiers. Un rétrogradage silencieux de
v0.0.60àv0.0.59aurait déclenché une alerte d'altération immédiate.
En appliquant des mesures de zéro confiance côté client, cside empêche les scripts de fournisseurs compromis d'exploiter la confiance des utilisateurs.
Indicateurs de compromission (IOCs)
- Domaine :
appsflyer[.]com- Domaine légitime détourné au niveau du registrar - Serveur de noms :
ns1.gcorelabs.net- Serveur de noms contrôlé par les attaquants pendant le détournement - URL (C2) :
https://websdk[.]appsflyer[.]com/v1/api/plugin- Point de terminaison C2 du payload (rotation des portefeuilles) - URL (C2) :
https://websdk[.]appsflyer[.]com/v1/api/process- Point de terminaison C2 du payload (exfiltration) - Paramètre URL :
?rd=- Contient des données d'exfiltration obfusquées par XOR - Portefeuille (ETH) :
0x1C069d0c73087D0Bae687a6f74a807350dCe1829- Cluster 1 (payload navigateur) - Portefeuille (BTC) :
bc1qr7ngtnsh66demm4vzt4kmqxkqj8sqprnuklalt- Cluster 1 (payload navigateur) - Portefeuille (SOL) :
4LJi6mAczxZWbUvbMEk5scKhUZNPvfMDTjaVADkPFSsK- Cluster 1 (payload navigateur) - Portefeuille (ETH) :
0x782B93e52e62F25Bd002eeAA813B5A3fe49C9558- Cluster 2 (wrappers Node.js) - Chaîne console : "Generating new wallets..." - Sortie en clair par tous les payloads
- Objet global :
walletAddresses- Injecté par toutes les variantes de payload - Objet global :
window.lIXMkR.NetHooksmith- Injecté par le payload navigateur - Chaîne de version :
0.0.59- Version SDK rétrogradée indiquant une altération
Recommandations
- Comparez immédiatement la version et le hachage du SDK servi depuis les points de terminaison AppsFlyer que vous utilisez avec des hachages de référence connus comme valides ; traitez tout rétrogradage silencieux comme une alerte d'altération prioritaire.
- Bloquez ou redirigez vers un sinkhole les requêtes sortantes vers les points de terminaison C2 identifiés et les serveurs de noms associés jusqu'à la fin de la remédiation.
- Renforcez la CSP et appliquez la SRI pour les ressources tierces dans la mesure du possible ; envisagez l'auto-hébergement des scripts de fournisseurs critiques après vérification de leur intégrité.
- Analysez les pipelines de build côté serveur et les déploiements SSR à la recherche des indicateurs de wrapper Node.js décrits ci-dessus et faites tourner les identifiants potentiellement compromis.
- Déployez cside pour surveiller les remplacements d'API (comme
fetch) et l'analyse par mutation DOM effectuée par des scripts tiers.
Cet incident n'est pas isolé. Pour un examen approfondi de la manière dont le blanchiment d'infrastructure étend la menace au-delà de la compromission d'un seul fournisseur, consultez notre analyse de l'infrastructure de polyfills sanctionnée.
Les détails forensiques, les hachages de fichiers et la télémétrie supplémentaire sont disponibles sur demande pour les organisations affectées et les intervenants en réponse à incident.
Note : Cet article résume les conclusions issues de la télémétrie Script Insights de cside et de l'analyse en sandbox. Certains domaines spécifiques et IOCs supplémentaires sont retenus pendant que les parties impactées procèdent à leur remédiation.
