Nach Erkenntnissen von Forschenden bei Symantec und Carbon Black (beide gehören zu Broadcom) wurde der auf Lua basierende Schadframework fast16 entwickelt, um die Ergebnisse von Simulationen der Verdichtung von Uran gezielt zu verfälschen – eines Prozesses, der für die Konstruktion von Atomwaffen von kritischer Bedeutung ist. Sollten die Schlussfolgerungen der Forschenden zutreffen, handelt es sich um einen der frühesten bekannten Fälle cybernetischer Sabotage industrieller Prozesse, der Stuxnet zeitlich vorausgeht und die Chronologie staatlicher Cyberangriffe auf kritische Infrastrukturen neu definiert.

Technischer Mechanismus der Sabotage

Laut dem Bericht des Threat Hunter Team fängt fast16 selektiv Berechnungen innerhalb zweier Ingenieursanwendungen ab – LS-DYNA und AUTODYN. Beide Softwarepakete werden breit eingesetzt, um reale physikalische Prozesse zu modellieren: von Crashtests für Fahrzeuge bis hin zu Simulationen der Detonation von Sprengstoffen.

Das zentrale Merkmal der Malware ist eine hochselektive Aktivierung. Nach Angaben der Forschenden prüft fast16 die Dichte des modellierten Materials und wird nur dann aktiv, wenn ein Schwellwert von 30 g/cm³ überschritten wird – ein Wert, den Uran ausschließlich bei Stoßkompression in einem Implosionsgerät erreicht. Damit ignoriert der Schadcode routinemäßige ingenieurtechnische Berechnungen und springt ausschließlich bei vollumfänglichen Detonationssimulationen an.

Die Architektur von fast16 umfasst 101 Abfangregeln (Hook Rules), die in 9–10 Gruppen organisiert sind. Jede Gruppe zielt auf einen bestimmten Build von LS-DYNA oder AUTODYN ab, was nach Einschätzung der Forschenden auf eine methodische Pflege hindeutet: Die Entwickler verfolgten Updates der Zielsoftware und passten die Malware an neue Versionen an.

Die Forschenden beschreiben drei Angriffsstrategien, die über die Hook-Mechanismen umgesetzt werden:

• Die Verfälschung wird nur bei vollumfänglichen transienten Berechnungen von Explosion und Detonation ausgelöst
• Die Malware verbreitet sich automatisch auf andere Knoten im selben Netzwerk und sorgt so auf jeder Maschine, die Simulationen ausführt, für identisch verfälschte Ergebnisse
• Fast16 vermeidet die Infektion von Rechnern, auf denen bestimmte Schutzlösungen installiert sind

Bemerkenswert ist ein Detail, das bei der Analyse der Abfolge der Regelgruppen entdeckt wurde: Nach Angaben der Forschenden wurden einige Gruppen für ältere Versionen der Software nach den Gruppen für neuere Versionen hinzugefügt. Dies könnte darauf hindeuten, dass Nutzer der Simulationssoftware bei Auffälligkeiten auf eine vorherige Version zurückgegangen sind – die daraufhin ebenfalls ins Visier genommen wurde.

Kontext und Attribution

Zuvor hatte das Unternehmen SentinelOne fast16 als den ersten bekannten Sabotage-Framework beschrieben, dessen Komponenten mutmaßlich bereits 2005 entwickelt worden sein könnten – zwei Jahre vor der frühesten bekannten Version von Stuxnet (Stuxnet 0.5). Es ist anzumerken, dass diese Datierung nicht durch unabhängige Primärquellen belegt ist, sondern auf analytischen Schlussfolgerungen der Forschenden beruht.

Zu den indirekten Hinweisen gehört die Erwähnung der Zeichenfolge „fast16“ in einer Textdatei, die 2017 von der Hackergruppe The Shadow Brokers veröffentlicht wurde. Diese Datei war Teil eines Tool-Konvoluts, das mutmaßlich von der Gruppierung Equation Group eingesetzt wurde. In den verfügbaren Unterlagen fehlen jedoch Primärquellen für diese Behauptung, weshalb diese Verbindung mit Vorsicht zu betrachten ist.

Wie die Journalistin Kim Zetter berichtet, bezeichnete der technische Direktor von Symantec, Vikram Thakur, das für die Entwicklung einer solchen Malware im Jahr 2005 erforderliche Fachwissen als „erstaunlich“. Die Forschenden betonen, dass für die Entwicklung von fast16 ein tiefes Verständnis der Zustandsgleichungen, der von bestimmten Compilern generierten Calling Conventions sowie der Logik zur Klassifizierung von Simulationen notwendig war – Kenntnisse, die zu jeder Zeit selten sind und für das Jahr 2005 als außergewöhnlich gelten.

Bewertung der Auswirkungen

Symantec und Carbon Black ordnen fast16 konzeptionell in eine Linie mit Stuxnet ein: Beide Malware-Familien wurden nicht nur an ein Produkt eines bestimmten Herstellers angepasst, sondern an einen konkreten physikalischen Prozess, der durch dieses Produkt modelliert oder gesteuert wird. Der Unterschied besteht darin, dass Stuxnet auf physische Anlagen einwirkte (Urananreicherungszentrifugen in Natanz über Siemens-Controller), während fast16 Berechnungsergebnisse verfälschte und damit potenziell ganze Forschungszyklen ungültig machte.

Die Folgen einer solchen Sabotage sind besonders tückisch: Anders als bei destruktiven Angriffen kann die Verfälschung von Simulationen lange unentdeckt bleiben, das Vertrauen in Forschungsergebnisse untergraben und zu fehlerhaften konstruktiven Entscheidungen führen.

Nach den vorliegenden Informationen ist derzeit unbekannt, ob es eine moderne Version von fast16 gibt.

Empfehlungen

Auch wenn fast16 zum historischen Arsenal gehört, sind die identifizierten Prinzipien seiner Funktionsweise für den Schutz moderner Forschungs- und Entwicklungsumgebungen hochrelevant:

• Integritätskontrolle der Berechnungen: Organisationen, die LS-DYNA, AUTODYN oder vergleichbare Simulationssoftware einsetzen, sollten Mechanismen zur Verifikation der Ergebnisse implementieren – etwa Kreuzprüfungen auf isolierten Systemen mit unterschiedlichen Builds
• Netzwerksegmentierung: Systeme für kritische Simulationen sollten von der allgemeinen Netzwerkinfrastruktur isoliert werden, insbesondere vor dem Hintergrund der Fähigkeit von fast16, sich automatisch im Netzwerk zu verbreiten
• Monitoring von Modifikationen: Überwachung der Integrität der ausführbaren Dateien der Simulationssoftware sowie Erkennung nicht autorisierter Abfangmechanismen (Hooks) in Simulationsprozessen
• Versionsaudit: Dokumentation und Kontrolle aller eingesetzten Versionen der Ingenieurssoftware, da fast16 ein Muster der Anpassung an Rollbacks auf frühere Versionen zeigt

Die Analyse von fast16 zeigt, dass strategische Sabotage von Rechenprozessen keine theoretische Bedrohung, sondern eine seit zwei Jahrzehnten dokumentierte Praxis ist. Organisationen, die mit kritischen Simulationen in der Rüstungs-, Nuklear- und Luft- und Raumfahrtindustrie arbeiten, sollten ihre Bedrohungsmodelle um Angriffe auf die Integrität von Modellergebnissen erweitern – und nicht nur auf die Verfügbarkeit oder Vertraulichkeit von Daten fokussieren.