Fast16: Hochpräzise Software-Sabotage 5 Jahre vor Stuxnet

 (sentinelone.com)
2 Punkte von GN⁺ 2 일 전 | 1 Kommentare | Auf WhatsApp teilen
  • Ein undokumentiertes Sabotage-Framework aus dem Jahr 2005, das darauf ausgelegt ist, den Speichercode ausgewählter Berechnungssoftware zu patchen, um numerische Ergebnisse zu verfälschen
  • svcmgmt.exe wirkt äußerlich wie ein Service-Wrapper, enthält intern jedoch eine Lua-5.0-virtuelle Maschine, verschlüsselten Bytecode, Hilfs-DLLs und den Treiber fast16.sys, um aufgabenspezifische Payloads getrennt auszuführen
  • fast16.sys ist ein beim Systemstart geladener Dateisystemtreiber, der sehr früh geladen wird und dann gezielt mit dem Intel-C/C++-Compiler gebaute .EXE-Dateien auswählt, um Speicher-Patches auf Kernel-Ebene vorzunehmen
  • Die Patch-Engine arbeitet mit 101 Regeln und hinterlässt insbesondere durch FPU-Befehlsblöcke, die die Skalierung interner Array-Werte verändern, Spuren einer Zielausrichtung auf spezielle Rechenwerkzeuge für Bauingenieurwesen, Physik und Prozesssimulation
  • In Verbindung mit der fast16-Kennzeichnung aus dem ShadowBrokers-Leak zeigt sich, dass präzise industrielle Sabotage schon vor Stuxnet existierte und dabei eingebettetes Scripting, enges Targeting und Kernel-Patches kombinierte

Überblick und Identifizierungshinweise

  • fast16 ist ein undokumentiertes Cyber-Sabotage-Framework mit Kernkomponenten aus dem Jahr 2005; fast16.sys zielt selektiv auf hochpräzise Berechnungssoftware, patcht Code im Speicher und verfälscht Berechnungsergebnisse
  • svcmgmt.exe erscheint oberflächlich wie ein typischer Service-Wrapper aus der Windows-2000/XP-Ära, enthält intern jedoch eine Lua-5.0-virtuelle Maschine sowie einen verschlüsselten Bytecode-Container, den der Service-Entry-Point entpackt
  • Bei der Untersuchung Lua-basierter Malware lieferten die Bytecode-Magic-Bytes 1B 4C 75 61, Versions-Bytes, LUA_PATH und charakteristische C-APIs die entscheidenden Hinweise; in diesem Zusammenhang wurde svcmgmt.exe identifiziert
  • Die Zeichenkette C:\buildy\driver\fd\i386\fast16.pdb in svcmgmt.exe ist ein forensischer Hinweis, der die Service-Executable mit dem Kernel-Treiberprojekt verbindet
  • Im ShadowBrokers-Leak von 2017 taucht derselbe Name fast16 auch in drv_list.txt auf, wodurch die PDB-Zeichenkette aus svcmgmt.exe und ein Treiber für präzise Sabotage in einen Zusammenhang gebracht werden
  • Die Avoidance-Signatur von ShadowBrokers enthält die Formulierung fast16 *** Nothing to see here – carry on***

Carrier-Struktur und Ausführungsweise

  • svcmgmt.exe ist als adaptiver Carrier konzipiert, dessen Verhalten sich je nach Kommandozeilenargument ändert
    • ohne Argumente: Ausführung als Windows-Dienst
    • -p: setzt InstallFlag = 1 und wird als Dienst ausgeführt
    • -i: setzt InstallFlag = 1 und führt Lua-Code aus
    • -r: führt Lua-Code ohne Installations-Flag aus
    • sonstiges <filename>: arbeitet im Wrapper/Proxy-Modus und erzeugt zwei Kindprozesse, einen mit dem ursprünglichen Befehl und einen mit angehängtem Argument -r
  • Der interne Speicher enthält verschlüsselten Lua-Bytecode, Hilfs-DLLs und den Treiber fast16.sys
  • Die Lua-Umgebung ist über den Standardzustand hinaus erweitert und stellt das Modul wstring, die eingebaute symmetrische Kryptofunktion b sowie Bindings für Windows-NT-Dateisystem-, Registry-, Service-Control- und Netzwerk-APIs bereit
  • Die externe Carrier-Binärdatei bleibt relativ stabil, während aufgabenspezifische Payloads verschlüsselt getrennt werden, damit sie je nach Umgebung und Operationsziel wiederverwendet werden können
  • Die Identifikationsmerkmale von svcmgmt.exe sind wie folgt
    • Dateiname svcmgmt.exe
    • Größe 315,392 bytes
    • MD5 dbe51eabebf9d4ef9581ef99844a2944
    • SHA1 de584703c78a60a56028f9834086facd1401b355
    • SHA256 9a10e1faa86a5d39417cae44da5adf38824dfb9a16432e34df766aa1dc9e3525
    • Typ PE32 executable for MS Windows 4.00 (console), Intel i386
    • Link-Zeit 2005-08-30 18:15:06 UTC

Wurmlet-Verbreitung und Umgehungsstruktur

  • svcmgmt.exe verhält sich wie ein Cluster-Munitions-Carrier, der mehrere Wormlets transportieren kann; im bestätigten Sample ist jedoch nur ein SCM-Wormlet enthalten
  • Der Ausführungsablauf umfasst Vorbereitung der Konfiguration, Umwandlung in Wide-Strings, Rechteausweitung, Installation und Start des Dienstes SvcMgmt, bedingte Bereitstellung von fast16.sys, Freisetzung des Wormlets, anfängliche Verzögerung und wiederholte Ausführung bis zu einem Fehlergrenzwert oder einer externen Abbruchbedingung
  • Das SCM-Wormlet zielt auf Windows-2000/XP-Umgebungen und sucht nach Netzwerkservern über Dateifreigaben mit schwachen oder Standard-Administratorpasswörtern, kopiert dann die Payload und startet einen entfernten Dienst
  • Die Verbreitung erfolgt nicht über ein maßgeschneidertes Netzwerkprotokoll, sondern über Standard-Windows-Verwaltungsfunktionen wie Service-Control-API und Dateifreigabe-API
  • Vor der Installation ruft ok_to_install() ok_to_propagate() auf, um die Umgebung zu prüfen; sofern keine manuelle Erzwingung vorliegt, wird die Möglichkeit zur Verbreitung anhand des Vorhandenseins bestimmter Registry-Schlüssel von Sicherheitsprodukten bestimmt
  • Ist einer der folgenden Registry-Schlüssel vorhanden, wird die Installation abgebrochen, um eine Verteilung in überwachte Umgebungen zu vermeiden
    • HKLM\SOFTWARE\Symantec\InstalledApps
    • HKLM\SOFTWARE\Sygate Technologies, Inc.\Sygate Personal Firewall
    • HKLM\SOFTWARE\TrendMicro\PFW
    • HKLM\SOFTWARE\Zone Labs\TrueVector
    • HKLM\SOFTWARE\F-Secure
    • HKLM\SOFTWARE\Network Ice\BlackIce
    • HKLM\SOFTWARE\McAfee.com\Personal Firewall
    • HKLM\SOFTWARE\ComputerAssociates\eTrust EZ Armor
    • HKLM\SOFTWARE\RedCannon\Fireball
    • HKLM\SOFTWARE\Kerio\Personal Firewall 4
    • HKLM\SOFTWARE\KasperskyLab\InstalledProducts\Kaspersky Anti-Hacker
    • HKLM\SOFTWARE\Tiny Software\Tiny Firewall
    • HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\Look n Stop 2.05p2
    • HKCU\SOFTWARE\Soft4Ever
    • HKLM\SOFTWARE\Norman Data Defense Systems
    • HKLM\SOFTWARE\Agnitum\Outpost Firewall
    • HKLM\SOFTWARE\Panda Software\Firewall
    • HKLM\SOFTWARE\InfoTeCS\TermiNET
  • connotify.dll übernimmt die Rolle eines minimalen Meldekanals
    • wird über die Windows-API AddConnectNotify() registriert und bei jeder neuen RAS-basierten Netzwerkverbindung aufgerufen
    • entschlüsselt eine verschleierte Zeichenkette, um die Named Pipe \\.\pipe\p577 zu erhalten, verbindet sich mit der lokalen Pipe, protokolliert Namen entfernter und lokaler Verbindungen und beendet sich dann
    • ist kein eigenständig ausführbares Modul und erfordert die Registrierung durch einen Host-Prozess
    • Dateiname svcmgmt.dll
    • Größe 45056 bytes
    • MD5 410eddfc19de44249897986ecc8ac449
    • SHA1 675cb83cec5f25ebbe8d9f90dea3d836fcb1c234
    • SHA256 8fcb4d3d4df61719ee3da98241393779290e0efcd88a49e363e2a2dfbc04dae9
    • Link-Zeit 2005-06-06 18:42:45 UTC
    • Typ PE32 DLL (i386, 4 sections)

Treiberstruktur und Methode des Memory-Patchings

  • fast16.sys ist die mächtigste Komponente des Frameworks. Es ist als Boot-Start-Dateisystemtreiber konfiguriert und wird zusammen mit dem Festplattentreiber in einem sehr frühen Stadium geladen.
  • Die Konfiguration ist Start=0, Type=2, Klasse SCSI, und es klinkt sich über NTFS, FAT und MRxSMB ein.
  • Beim ersten Einstieg setzt es den Wert EnablePrefetcher unter Session Manager\PrefetchParameters auf 0, sodass spätere Code-Page-Anfragen den gesamten Dateisystem-Stack durchlaufen.
  • Mit einfacher XOR-String-Verschlüsselung und einem Scan von ntoskrnl.exe löst es Kernel-APIs dynamisch auf und exponiert \Device\fast16, \??\fast16 sowie den benutzerdefinierten DeviceType 0xA57C.
  • Über IoRegisterFsRegistrationChange hängt es Worker-Device-Objects an aktive und neue Dateisystem-Geräte an und klinkt sich in IRP_MJ_CREATE, IRP_MJ_READ, IRP_MJ_CLOSE, IRP_MJ_QUERY_INFORMATION, IRP_MJ_FILE_SYSTEM_CONTROL sowie die zugehörigen Fast-I/O-Pfade ein.
  • Es wird zwar beim Booten geladen, aber die eigentliche Code-Injection-Engine auf Kernel-Ebene wird erst aktiv, nachdem explorer.exe geöffnet wurde.
  • Ein Patch-Ziel muss gleichzeitig zwei Bedingungen erfüllen
    • Der Dateiname endet auf .EXE
    • Direkt hinter dem letzten PE-Section-Header steht eine druckbare ASCII-Zeichenkette, die mit Intel beginnt.
  • Diese Bedingung zielt auf ausführbare Dateien ab, die mit dem Intel C/C++ Compiler gebaut wurden, und zeigt, dass die Angreifer die Toolchain der Zielsoftware kannten.
  • Auf passende Dateien wird eine Änderung des PE-Headers im Speicher angewendet: Die beiden Sections .xdata und .pdata werden neu injiziert, und Bytes aus der ursprünglichen Code-Section werden eingefügt, um eine saubere Kopie des Codes zu erhalten.
  • Die Identifikationswerte von fast16.sys sind wie folgt
    • Dateiname fast16.sys
    • Größe 44,580 bytes
    • MD5 0ff6abe0252d4f37a196a1231fae5f26
    • SHA1 92e9dcaf7249110047ef121b7586c81d4b8cb4e5
    • SHA256 07c69fc33271cf5a2ce03ac1fed7a3b16357aec093c5bf9ef61fbfa4348d0529
    • Typ PE32 executable for MS Windows 5.00 (native), Intel i386, 5 sections
    • Link-Zeit 2005-07-19 15:15:41 UTC

Regelbasierte Patch-Engine und Zielmerkmale

  • Die Patch-Engine ist ein kompakter zustandsbasierter Scanner mit 101 Regeln, der Ausführungscode beim Lesen von Dateien von der Festplatte per Pattern-Matching und Ersetzungslogik unauffällig im Speicher verändert.
  • Um die Leistung zu erhalten, filtert ein 256-Byte-Dispatch-Array einige Start-Bytes schnell vorab aus, Wildcards innerhalb der Muster sind erlaubt, und einige Regeln setzen und prüfen Zustands-Flags, um mehrstufige Modifikationssequenzen auszuführen.
  • Die meisten Patch-Muster entsprechen allgemeinen Befehlssequenzen in x86-Code, die den Ausführungsfluss kapern oder beeinflussen, doch eines besteht aus einem deutlich größeren FPU-Befehlsblock.
  • Dieser FPU-Block ist Code speziell für präzise Arithmetik und die Skalierung interner Array-Werte und zeigt damit einen anderen Charakter als gewöhnliche bösartige Injektionen.
  • Die Forschenden wandelten die Patch-Regeln in hexadezimale Muster von YARA-Signaturen um und wendeten sie auf einen zeitgleichen Software-Korpus an; Dateien mit zwei oder mehr Treffern waren mit weniger als zehn extrem selten.
  • Die Trefferdateien waren durchweg Spezialwerkzeuge für Berechnungen in Bereichen wie Bauingenieurwesen, Physik und physikalischer Prozesssimulation.
  • Der FPU-Patch skaliert Werte, die an drei interne Arrays übergeben werden, und verändert so Berechnungen subtil, was zeigt, dass das Ziel nicht unbefugter Zugriff oder allgemeine Verbreitung, sondern die Manipulation numerischer Ergebnisse war.
  • Da weder die exakten Ziel-Binärdateien noch alle Workloads vollständig verifiziert werden konnten, ließ sich die Bedeutung der Arrays nicht eindeutig bestimmen.
  • Würden Berechnungen auf einem separaten System verifiziert, könnte eine solche Sabotage scheitern. Wenn jedoch derselbe Treiber auf mehrere Systeme verteilt wird, die dasselbe Netzwerk und dieselbe Sicherheitsumgebung teilen, sinkt auch die Wahrscheinlichkeit von Abweichungen bei einer unabhängigen Gegenprüfung.
  • Im Anhang sind einige extrahierte Muster der Patch-Engine unverändert aufgeführt
    • 48 89 84 24 9C 00 00 00 4B 0F 8F 79 FF FF FF 00
    • D8 E1 D9 5D FC D9 04 00
    • 55 8B EC 83 EC 14 53 56 57 8B 3D ?? ?? ?? ?? 8B 0D 00
    • 8D 1D ?? ?? ?? ?? 52 8D 05 ?? ?? ?? ?? 51 8D 15 ?? ?? ?? ?? 8D 0D ?? ?? ?? ?? 53 50 52 51 56 57 E8 ?? ?? ?? ?? 83 C4 38 EB 0E 83 EC 04 00
    • B9 01 00 00 00 C1 E7 02 8B BF ?? ?? ?? ?? 8B D7 85 FF 8B 55 30 8B 45 30 D8 C9 8B 75 2C 00 9A 8B 00 00 00 1B 00 90 0F 94 C3 0B D8 33 D2 83 3D 00

Mögliche Patch-Ziele

  • Das Ziel mit der stärksten Übereinstimmung in den Pattern-Matching-Ergebnissen waren LS-DYNA 970, PKPM und MOHID
  • LS-DYNA 970 ist eine Engineering-Simulationssoftware zur Analyse des Material- und Strukturverhaltens unter Extrembedingungen; sie behandelt Autokollisionen, Explosionen, Stöße, Metallumformung und Fertigungsprozesse und wurde in der Automobilindustrie, Luft- und Raumfahrt, Verteidigungs- und Militärforschung sowie in der Fertigung und Materialwissenschaft eingesetzt
    • wird seit 1976 entwickelt
    • MD5 1d2f32c57ae2f2013f513d342925e972
    • SHA1 2fa28ef1c6744bdc2021abd4048eefc777dccf22
    • SHA256 5966513a12a5601b262c4ee4d3e32091feb05b666951d06431c30a8cece83010
    • Dateigröße 5,225,591 bytes
    • Link-Zeit 2003-10-24 16:34:57 UTC
    • Dateityp PE32 executable for MS Windows 4.00 (console), Intel i386, 7 sections
  • PKPM ist eine in China weit verbreitete CAD-Produktsuite für das Bauingenieurwesen, die aus mehreren ausführbaren Modulen besteht und den gesamten Zyklus der Tragwerksplanung von Gebäuden abdeckt
    • SATWE ist die Kern-Engine für die dreidimensionale Strukturanalyse von Decken, Balken, Stützen, Wänden und Rahmen insgesamt
    • Kennungen des Moduls für die Bemessung von Betonscherkräften
      • MD5 af4461a149bfd2ba566f2abefe7dcde4
      • SHA1 586edef41c3b3fba87bf0f0346c7e402f86fc11e
      • SHA256 09ca719e06a526f70aadf34fb66b136ed20f923776e6b33a33a9059ef674da22
      • Dateigröße 7716864 bytes
      • Dateityp PE32 executable for MS Windows 4.00 (GUI), Intel i386, 6 sections
      • Link-Zeit 2011-08-26 10:58:17 UTC
    • Kennungen des Moduls Building Structure CAD
      • MD5 49a8934ccd34e2aaae6ea1e6a6313ffe
      • SHA1 3ce5b358c2ddd116ac9582efbb38354809999cb5
      • SHA256 8b018452fdd64c346af4d97da420681e2e0b55b8c9ce2b8de75e330993b759a0
      • Größe 11849728 bytes
      • Link-Zeit 2005-12-01 08:35:46 UTC
      • MD5 e0c10106626711f287ff91c0d6314407
      • SHA1 650fc6b3e4f62ecdc1ec5728f36bb46ba0f74d05
      • SHA256 06361562cc53d759fb5a4c2b7aac348e4d23fe59be3b2871b14678365283ca47
      • Größe 16355328 bytes
      • Link-Zeit 2012-07-07 08:47:11 UTC
    • Kennungen der Strukturanalyse-Engine SATWE
      • MD5 2717b58246237b35d44ef2e49712d3a2
      • SHA1 d475ace24b9aedebf431efc68f9db32d5ae761bd
      • SHA256 bd04715c5c43c862c38a4ad6c2167ad082a352881e04a35117af9bbfad8e5613
      • Größe 9908224 bytes
      • Link-Zeit 2011-01-12 06:37:39 UTC
      • MD5 daea40562458fc7ae1adb812137d3d05
      • SHA1 1ce1111702b765f5c4d09315ff1f0d914f7e5c70
      • SHA256 da2b170994031477091be89c8835ff9db1a5304f3f2f25344654f44d0430ced1
      • Größe 8454144 bytes
      • Link-Zeit 2012-11-29 03:10:12 UTC
      • MD5 2740a703859cbd8b43425d4a2cacb5ec
      • SHA1 ca665b59bc590292f94c23e04fa458f90d7b20c9
      • SHA256 aeaa389453f04a9e79ff6c8b7b66db7b65d4aaffc6cac0bd7957257a30468e33
      • Größe 16568320 bytes
      • Link-Zeit 2014-12-30 03:23:43 UTC
      • MD5 ebff5b7d4c5becb8715009df596c5a91
      • SHA1 829f8be65dfe159d2b0dc7ee7a61a017acb54b7b
      • SHA256 37414d9ca87a132ec5081f3e7590d04498237746f9a7479c6b443accee17a062
      • Größe 8089600 bytes
      • Link-Zeit 2009-04-22 01:46:46 UTC
      • MD5 cb66a4d52a30bfcd980fe50e7e3f73f0
      • SHA1 e6018cd482c012de8b69c64dc3165337bc121b86
      • SHA256 66fe485f29a6405265756aaf7f822b9ceb56e108afabd414ee222ee9657dd7e2
      • Größe 9219072 bytes
      • Link-Zeit N/A
    • Kennungen zusätzlicher PKPM-CAD-Dateien
      • MD5 075b4aa105e728f2b659723e3f36c72c
      • SHA1 145ef372c3e9c352eaaa53bb0893749163e49892
      • SHA256 c11a210cb98095422d0d33cbd4e9ecc86b95024f956ede812e17c97e79591cfa
      • Größe 6852608 bytes
      • Link-Zeit 2012-06-18 10:01:54 UTC
      • MD5 cf859f164870d113608a843e4a9600ab
      • SHA1 952ed694b60c34ba12df9d392269eae3a4f11be4
      • SHA256 7e00030a35504de5c0d16020aa40cbaf5d36561e0716feb8f73235579a7b0909
      • Größe 8392704 bytes
      • Link-Zeit 2012-11-29 03:10:12 UTC
  • MOHID ist ein von MARETEC am Instituto Superior Técnico in Lissabon, Portugal, entwickeltes Open-Source-System zur Modellierung von Gewässern, das Meeres- und Küstenhydrodynamik, Wasserqualitätssimulation, Sedimenttransport, Ölspill-Modellierung und Lagrangesches Partikel-Tracking abdeckt
    • Es wird erklärt, dass selbst zum jetzigen Zeitpunkt der beabsichtigte Angriffseffekt nicht eindeutig identifiziert werden konnte
    • MD5 f4dbbb78979c1ee8a1523c77065e18a5
    • SHA1 9e089a733fb2740c0e408b2a25d8f5a451584cf6
    • SHA256 e775049d1ecf68dee870f1a5c36b2f3542d1182782eb497b8ccfd2309c400b3a
    • Dateigröße 5443584 bytes
    • Dateityp PE32 executable for MS Windows 4.00 (console), Intel i386, 3 sections
    • Link-Zeit 2002-10-18 09:29:54 UTC
  • LS-DYNA wurde in öffentlich zugänglichen Berichten über mutmaßliche Verstöße des Iran gegen Section T des JCPOA zusammen mit Forschung zu Computermodellierung im Zusammenhang mit der Entwicklung von Atomwaffen erwähnt

Erkennungsregeln und Kompromittierungsindikatoren

  • Kompromittierungsindikatoren

    • Die drei bestätigten Dateien sind fast16.sys, connotify.dll und svcmgmt.exe
    • fast16.sys: MD5 0ff6abe0252d4f37a196a1231fae5f26, SHA1 92e9dcaf7249110047ef121b7586c81d4b8cb4e5, SHA256 07c69fc33271cf5a2ce03ac1fed7a3b16357aec093c5bf9ef61fbfa4348d0529
    • connotify.dll: MD5 410eddfc19de44249897986ecc8ac449, SHA1 675cb83cec5f25ebbe8d9f90dea3d836fcb1c234, SHA256 8fcb4d3d4df61719ee3da98241393779290e0efcd88a49e363e2a2dfbc04dae9
    • svcmgmt.exe: MD5 dbe51eabebf9d4ef9581ef99844a2944, SHA1 de584703c78a60a56028f9834086facd1401b355, SHA256 9a10e1faa86a5d39417cae44da5adf38824dfb9a16432e34df766aa1dc9e3525

  • apt_fast16_carrier

    • Wurde so entworfen, dass Carrier, Lua-Payloads und Klartext-Varianten erkannt werden; der Referenz-Hash ist 9a10e1faa86a5d39417cae44da5adf38824dfb9a16432e34df766aa1dc9e3525
    • Verwendet den Lua-Bytecode-Magic-Wert 1B 4C 75 61 sowie die Strings build_wormlet_table, unpropagate, scm_wormlet_install, install_implant, start_worm, ok_to_propagate
    • Bezieht zahlreiche Registry-Schlüssel von Sicherheitsprodukten in die Bedingungen ein, darunter Symantec, Sygate Personal Firewall, Zone Labs\TrueVector, Kaspersky Anti-Hacker
    • Erkennt außerdem Byte-Muster verschlüsselter Strings, zwei Chiffrierkonstanten, Code zum Entschlüsseln der Länge eines Speichercontainers sowie eine Speicherdatensatz-Signatur mit dem String file
    • Die Bedingung greift bei MZ-Headern und Dateien unter 10 MB, wenn entweder 3 von $s*, 12 von $rk*, ein beliebiges $e*, die nahe Platzierung der zwei Chiffrierkonstanten und eines von $code1 oder $stor1 erfüllt sind, oder wenn der Lua-Magic-Wert und 7 von $s* erfüllt sind

  • apt_fast16_driver

    • Wurde so entworfen, dass der Treiber oder zugehörige Projektdateien erkannt werden; der Referenz-Hash ist 07c69fc33271cf5a2ce03ac1fed7a3b16357aec093c5bf9ef61fbfa4348d0529
    • Verwendet zahlreiche Strings zur Identifikation von Quelldateien wie @(#)foo.c :, @(#)par.h :, @(#)pae.h :, @(#)ree.c :
    • Enthält Muster wie \\Device\\fast16, \\??\\fast16, C:\\buildy\\, driver\\fd\\i386\\fast16.pdb, push 0A57Ch ; DeviceType
    • Auch API-Muster, die ExAllocatePool, ExAllocatePoolWithTag, ExFreePool, ExFreePoolWithTag in XOR-Form pushen, sind Teil der Signatur
    • Die Bedingung greift bei Dateien unter 10 MB zusammen mit MZ-Header, wenn entweder 2 PDB-Pfade, C:\\buildy\\ und 1 Quelldatei-Identifikator, #devtype == 3, pe.machine == pe.MACHINE_I386, pe.subsystem == pe.SUBSYSTEM_NATIVE und eines von einem beliebigen api* oder 2 dev* erfüllt sind, oder wenn 6 Quelldatei-Identifikatoren erfüllt sind

  • clean_fast16_patchtarget

    • Erkennt die zu patchende Zielsoftware, ist mit most probably clean gekennzeichnet, und der Referenz-Hash ist 8fcb4d3d4df61719ee3da98241393779290e0efcd88a49e363e2a2dfbc04dae9
    • Verwendet zahlreiche Byte-Muster von $el0 bis $el99
    • Die Bedingung lautet: Datei unter 20 MB, MZ-Header und mindestens 2 Treffer unter den definierten Signaturen

  • apt_fast16_patch

    • Erkennt den Patch-Code selbst und kann in statisch gepatchten Dateien oder Speicher-Dumps vorkommen
    • Der Referenz-Hash ist 0ff6abe0252d4f37a196a1231fae5f26
    • Definiert drei Byte-Muster: $p1, $p2, $p3
    • Die Bedingung ist any of them; schon ein Treffer unter den drei Mustern löst die Erkennung aus

Abstammung und historische Implikationen

  • Der String @(#)par.h $Revision: 1.3 $ im Binärfile ist ein Hinweis, der Rückschlüsse auf die Abstammung dieses Frameworks erlaubt
  • Das Präfix @(#) verweist auf die Quellcodeverwaltungs-Konventionen der SCCS/RCS-Familie aus dem Unix der 1970er und 1980er Jahre; in Windows-Kernel-Treibern der Mitte der 2000er sind solche Spuren selten
  • Solche Artefakte wirken eher wie Spuren eines langjährigen Engineers, der mit der Kultur und den Toolchains älterer Hochsicherheits-Unix-Umgebungen vertraut ist, als die eines typischen reinen Windows-Entwicklers
  • svcmgmt.exe wurde vor fast 10 Jahren bei VirusTotal hochgeladen, hat aber bis heute eine sehr niedrige Erkennungsrate; nur eine Engine klassifiziert sie mit begrenzter Sicherheit als generische Malware
  • In Verbindung mit den Signaturen von ShadowBrokers’ Territorial Dispute zwingt fast16 dazu, den Entwicklungszeitpunkt schwerwiegender, verdeckter staatlicher Cyber-Sabotage neu zu bewerten
  • fast16 zeigt schon vor bekannteren Familien eine konsistente Architektur, die eingebettete Scripting-Engines, compilerbasiertes enges Targeting und Kernel-Level-Patches kombiniert
  • Über lange Zeit gab es kaum öffentliche Analysen, benannte Kampagnen oder Verbindungen zu bekannten Vorfällen, und selbst die intern hinterlassenen, für Menschen lesbaren Marker bleiben in zurückhaltender Form wie *** Nothing to see here – carry on***
  • Es wird als Verbindungspunkt innerhalb der APT-Evolutionslinie eingeordnet, die später zu Lua- and LuaJIT-based toolkits führte

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2 일 전
Hacker-News-Kommentare

  • Diese Stelle fand ich besonders interessant
    Der Vergleich, dass die SCCS/RCS-Notation im Windows-Kernelcode von 2005 auftauchte, entspreche ungefähr dem Anblick eines Wählscheibentelefons in einem heutigen Büro, war ziemlich überzeugend
    In dem Astrophysik-Labor, in dem ich 2006 gearbeitet habe, wurde ebenfalls noch svn benutzt, und im Codebestand gab es viel Fortran mit Spuren von Systemen aus den 70er- und 80er-Jahren
    Trotzdem lief alles dank moderner optimierender Compiler gut, und auch die Migration in den 90ern von Vax auf Linux war überraschend reibungslos
    Das erinnerte mich an den Vortrag do over or make due, dessen Kern war, dass es sich meist nicht lohnt, einen großen, im Wesentlichen funktionierenden Codebestand komplett neu zu schreiben, wenn man ihn mit modernen Werkzeugen gerade noch zusammenhalten und weiterverwenden kann

    • Ich habe bis etwa 2012 noch in einer Firma gearbeitet, die ein RCS-basiertes SCM benutzte; im Grunde war das ein zusammengehacktes System, das RCS über einen gemeinsamen Fileserver gestülpt hat
      Es hieß MKS und verwaltete bestimmte Revisionsbäume als „project file“; selbst damals wirkte es eher wie eine Altlast aus den 90ern als wie irgendeine in Java EE neu gebaute Version
      Oben in den Dateien standen Tags wie $Revision: 1.3 $ und ein Changelog, aber in vielen neueren Dateien fehlten die Tags komplett, sodass nichts ersetzt wurde, und die Konsistenz war miserabel
      Die Zielgerätefamilie begann zwar Mitte der 90er, aber der eigentliche Code zu diesem Zeitpunkt war praktisch nirgends älter als fünf Jahre
      Obwohl es nur einige Dutzend Ingenieure waren, gab es ständig Commit-Konflikte und der gesamte Baum war oft kaputt
      Aus Spaß schrieb ich ein Skript, das die komplette Historie auslas und nach git importierte, aber schon wenn man nur ein paar Jahre zurückging, war die Historie völliges Chaos
      Warum das damals noch verwendet wurde, weiß ich nicht, aber Hardware-Firmen haben Source Control offenbar noch überraschend lange eher als „entfernten gemeinsamen Ordner“ betrachtet, weshalb Versionsverwaltung auf der Software-Seite wohl keine Priorität hatte
    • Wenn man 2026 noch R benutzt, ist die Wahrscheinlichkeit groß, dass man irgendwo fast sicher Code aufruft, der aus Fortran der 70er oder 80er kompiliert wurde
      In der Welt des numerischen Rechnens bildet diese Linie bis heute ein Fundament
    • Früher war ich bei der These eines staatlichen Hintergrunds von Stuxnet etwas skeptisch, aber wenn man solche Notizen sieht, versteht man, warum man darauf kam
      Es gab tatsächlich noch bis in die 2000er Orte, die RCS nutzten, und als Werkzeug hatte es in mancher Hinsicht sogar Vorteile gegenüber SVN oder CVS
    • Dann fragt man sich, ob solche Drei-Buchstaben-Behörden für jede Malware-Kategorie Leute mit genau passendem Fachhintergrund heranziehen konnten
      Man kann sich etwa vorstellen, dass fast16 von jemandem geschrieben wurde, der ursprünglich wissenschaftliche Rechensoftware entwickelt hat, und Stunex von jemandem, der bei Siemens gearbeitet hatte
    • Refactoring ist kein Allheilmittel
      Wenn die ursprünglichen Ursachen, die den Code überhaupt refactoring-bedürftig gemacht haben, unverändert bleiben, landet man am Ende wieder im selben Zustand
      Solche Ursachen reichen oft tief in psychologische Schichten hinein, etwa Gewohnheiten, Überzeugungen oder berufliche Traumata der Entwickler
      Kommt dann noch Conways Gesetz dazu, baut das Team am Ende zwangsläufig Software, die der größeren Organisationsstruktur ähnelt, und wenn sich die Organisation nicht ändert, wiederholen sich auch die Ergebnisse von Refactorings meist
      Ausnahmen gibt es eher dann, wenn man die Codebasis eines anderen Teams oder die eines Vorgängers übernimmt und die Struktur neu ordnet
      Wenn aber dieselben Leute das Refactoring ihres eigenen Codes ausrufen, endet es oft nur darin, dass sie sich noch eine weitere, für sie bequemere Mausefalle bauen
      Das fortlaufende Verbessern des Produkts der eigenen Denkweise ist in Ordnung, aber wenn man vom Karussell herunter will, sollte man die Ursachen schlechter Architektur aufschreiben und sich selbst schonungslos prüfen
      Die Vorstellung, an die viele Entwickler gern glauben, dass man „mit Vorsicht und Fleiß auch ein mäßig schlechtes Design gut umsetzen kann“, stimmt meistens nicht
      Die Wurzel ist letztlich das Design; man muss entweder den daraus gewachsenen Baum akzeptieren oder fällen, bloßes Beschneiden der Äste stößt schnell an Grenzen

  • Dieser Artikel wirkt ziemlich unheimlich
    Allein die Tatsache, dass diese Malware 20 Jahre lang unter dem Radar blieb, ist schon düster genug

  • Hier ist der Download-Link für Neugierige
    https://bazaar.abuse.ch/sample/9a10e1faa86a5d39417cae44da5ad...
    Ich würde wahrscheinlich zuerst eine Windows-XP-VM aufsetzen

    • Ich frage mich, ob dazu schon einmal die Windows-Service-Datei hochgeladen wurde
      Das sieht für mich nur nach dem Loader aus

  • IEEE-754 erzwingt korrektes Runden nur für +-*/ und sqrt
    Bei transzendenten Funktionen wie sin/cos/exp/log/pow sind Abweichungen von einigen letzten ULP erlaubt, und genau so verhalten sich glibc, musl, MSVC und Intel SVML auch tatsächlich
    PID verwendet nur Grundoperationen und ist daher weniger von libm-Unterschieden betroffen, aber Motorvektorregelung oder Sensorlinearisierung berühren solche Funktionen in jedem Zyklus, weshalb sich kleine Abweichungen aufsummieren
    Deshalb kann sich das Verhalten im Feld allein durch eine geänderte gelinkte libm verschieben, auch wenn der Source-Code-Diff exakt null ist
    Solche Unterschiede treten tatsächlich bei Payne-Hanek-Argumentreduktion oder an den schlimmsten Grenzen des table-maker’s dilemma auf
    Vermutlich schreiben Richtlinien für sicherheitskritische Systeme deshalb nicht einfach nur „IEEE-754-konform“, sondern pinnen einen bestimmten libm-Build fest

  • Wirklich ein großartiger Fund
    Mich interessiert sehr, auf welche Ziele diese Regeln genau abzielten und wie sie die Ergebnisse veränderten
    Vielleicht waren sie so ausgelegt, dass sie nur unter ganz bestimmten Simulationsbedingungen Unterschiede erzeugen, etwa bei einem Reaktor

    • Ich habe ein wenig dazu recherchiert, wie Software wie LS-DYNA manipuliert werden könnte
      Zum Beispiel ist die EOS_JWL-Gleichung im öffentlichen Handbuch [1] eine von LS-DYNA implementierte Formel, die zusammen mit anderen Gleichungen offenbar genutzt werden kann, um Dinge wie die Zeit zu berechnen, bis der Zünder eines Raketensprengkopfs den Hauptsprengstoff zur Explosion bringt und in 20 m Entfernung eine bestimmte Druckwelle erzeugt
      Von diesem Ergebnis aus könnte man rückwärts auch das nötige Zünder-Timing abschätzen
      Die Gleichungen und Parameter in LS-DYNA stammen aus wissenschaftlichen Arbeiten wie [2], einer US-Regierungsforschung aus den 1980ern zu hochexplosiven Stoffen
      Darin finden sich auch Experimente, die messen, wie sich der Sprengstoff an verschiedenen Materialien seiner Ummantelung reibt
      Da die Gleichungen für die Modellierung von Sprengstoffen bereits vorhanden sind, könnte man durch eine kleine Änderung solcher Gleichungen und ±20 % Rauschen beim Reibungskoeffizienten leicht erreichen, dass Wissenschaftler oder Ingenieure zunächst eher Probleme bei der Qualität der Stahlherstellung vermuten als eine Manipulation der Software
      Als modernes Analogon kann man sich vorstellen, dass ein feindlicher Staat eine Raubkopie von Ansys Autodyn 2026 R1 verwendet, die eine chinesische Cracking-Gruppe in einem chinesischen Forum gepostet hat und die von wenigen Seedern hinter einem russischen ISP verteilt wird
      Wenn später Messwerte und Berechnungen immer wieder nicht zusammenpassen, könnte man dann irgendwann vermuten, dass die Raubkopie absichtlich manipuliert wurde
      Andererseits könnte es heute für einen feindlichen Staat einfacher sein, legitime Kopien aus kompromittierten Netzwerken irgendeiner Universität oder eines Luft- und Raumfahrt- bzw. Rüstungsberatungsunternehmens zu ziehen
      Es wäre außerdem naiv anzunehmen, dass ein feindlicher Staat im Jahr 2026 die Software nicht auch ganz von Grund auf selbst bauen könnte; auch mit Handrechnungen oder Experimenten kann man zum gewünschten Ergebnis gelangen
      Um die Fertigungsqualität zu validieren, braucht man am Ende ohnehin Versuchsaufbauten und Fähigkeiten
      Simulationssoftware dient vor allem dazu, den Bau von Modellen und die Anzahl physischer Experimente zu reduzieren und damit Kosten und Zeit zu sparen
      Ein Szenario wie in [3], bei dem ein Geschoss auf eine Panzerplatte trifft, tausendmal durchzuspielen ist billig; das in der Realität zu wiederholen ist viel teurer und dauert deutlich länger
      [1] https://ftp.lstc.com/anonymous/outgoing/jday/manuals/LS-DYNA...
      [2] https://www.osti.gov/servlets/purl/6530310
      [3] https://www.youtube.com/watch?v=_dv2PecKUBM

  • Wenn ich Dinge veröffentliche, an denen RCS-Revisionsdaten hängen, hoffe ich immer, dass die Leute zumindest kurz stutzen

  • Das letzte Buch, das ich gelesen habe, war Sandworm: A New Era of Cyberwar and the Hunt for the Kremlin's Most Dangerous Hackers von Andy Greenberg
    Ich fand es ziemlich gut, und da ständig neue Informationen auftauchen, könnte es eigentlich eine Fortsetzungsreihe gebrauchen

  • Wenn man sieht, dass Guix und reproduzierbares Computing bis auf PowerPC oder Legacy-Maschinen portierbar werden, dürften Regierungen oder 1984-artige Institutionen und einige Organisationen im Nahen Osten das wirklich hassen
    Je heterogener die Umgebung, desto besser

  • Die Schlüsselzahl ist Wurm
    Selbst wenn man auf einem anderen Computer nachprüft, wird nichts gefunden, weil es von vornherein keinen sauberen zweiten Computer gibt

  • Ein interessanter Fund, aber der Kommentar zur Source Control wirkt etwas daneben
    Dinge ähnlich wie SCCS dürften damals immer noch im Einsatz gewesen sein, und ich komme kurz ins Grübeln, ob CVS stilistisch nicht ähnlich war

    • Ich vermute, der Kommentar sollte eher heißen, dass so etwas in Windows-Software ungewöhnlich war
      Das deutet darauf hin, dass die Entwickler ursprünglich auch auf der UNIX-Seite gearbeitet hatten, wo SCCS/RCS durchaus verbreitet war