Indicators of Compromise (IoCs) in der OT: Wonach soll ich konkret suchen? (Teil 2)

In meinem letzten Blog (siehe hier) habe ich ein paar simple, gängige IoCs vorgestellt und ihre Bedeutung für Incident Response in der OT eingeordnet. Nun geht es weiter mit ein paar komplexeren IoCs, die oft schwieriger zu rekonstruieren, dafür aber umso aufschlussreicher sind:

Angriffstools

Welche Tools benutzt ein Angreifer für seinen Angriff? Das kann man durch Analyse von vorliegenden IoC herausfinden, da diese Tools spezielle IoCs erzeugen.

Beispielsweise deutet ein sechszehnstelliger, zufällig generierter Prozessname unter Windows darauf hin, dass dieser Prozess automatisch von Metasploit (einem beliebten Hackertool) erzeugt wurde beim (offensichtlich erfolgreichen) Versuch, sich auf dem Windows-System zu persistieren. Es entspricht einfach den Standardeinstellungen von Metasploit, Prozessnamen zufällig mit 16 Stellen zu generieren. Als Angreifer kann man diese Standardeinstellung ganz leicht ändern, aber einige Angreifer tun dies nicht, sei es aus Nachlässigkeit oder weil sie sich sicher sind, sowieso nicht entdeckt zu werden.

Das Wissen darüber, wie sich eine Malware verhält hilft also Incident Respondern und auch Angriffserkennungstools dabei, die Malware zu erkennen. Meist ist dies deutlich komplizierter als das oben genannte Beispiel von Metasploit: ein einzelner IoC lässt i.d.R keine eindeutigen Rückschlüsse auf die eingesetzten Tools zu. Es müssen stattdessen mehrere IoC miteinander korreliert werden, Hypothesen aufgestellt und überprüft werden, bevor sich ein vollständiges Bild ergibt.

Da kein Incident Responder das Verhalten jeglicher Angriffstools auswendig kennen kann, gibt es hierfür Datenbanken (welche oft auch dazu genutzt werden, um Angriffserkennungstools auf dem neuesten Stand zu halten). Als „Trockenübung“ für Incident Responder lohnt sich jedoch auch ein Blick in das MITRE ATT&CK® Framework, insbesondere für OT-spezifische Malware (und davon gibt es mehr, als man denkt). Für viele bekannte Angriffstools ist dort aufgelistet, welche Techniques (siehe nächstes Kapitel) diese benutzen. Beispielweise erfährt man dort, dass die Software „Industroyer“ (eine Schadsoftware, die 2016 genutzt wurde, um das ukrainische Stromnetz anzugreifen) eine manipulierte Version von Windows Notepad für ihre Persistenz nutzt. Als Incident Responder kann man entsprechend prüfen, ob diese Software in dieser Weise manipuliert wurde. Das setzt natürlich voraus, dass man bereits den Verdacht hat, es könnte sich um Industroyer handelt. ATT&CK ® listet übrigens mehrere Dutzend solcher Techniques für Industroyer auf. Wenn man eine einzelne erkannt hat, bedeutet das also noch nicht, dass man die Malware sicher kennt!

Tactics, Techniques und Procedures

Diese drei Begriffe (abgekürzt als TTP) sind bekannt als das Herzstück von MITRE ATT&CK ®. Angreifer bedienen sich immer einer Kombination aus verschiedenen TTP um ihr Ziel zu erreichen (z.B. die Exfiltration von Daten oder deren Verschlüsselung und anschließende Erpressung der Opfer).

Wer als Incident Responder ein Verständnis für die TTP der Angreifer hat kann die Suche nach IoCs (und damit die Rekonstruktion des Angriffs) deutlich beschleunigen. Entweder man können die gefundenen IoCs einer bekannten Malware zugeordnet werden (wie im vorherigen Kapitel beschrieben), woraufhin man weiß, welche Technique die Angreifer hier angewandt haben. Oder man kann den IoC (z.B. erfolgreiche Loginversuche des selben Users an vielen Systemen gleichzeitig, was auf die Tactic „Lateral Movement“ hindeutet) direkt aus dem IoC ableiten.

Dies liefert stets Hinweise, wonach man als nächstes suchen sollte. Im o.g. Beispiel, bei mit Metasploit ein Windows-Prozess erzeugt wurde (zwecks Tactic „Persistance“) würde man sich als nächstes nach dessen Entdeckung fragen, wie die Angreifer überhaupt Zugriff auf das kompromittierte System bekommen haben (also durch welche Technique wurde die vorhergehende Tactic „Lateral Movement“ oder „Initial Access“ durchgeführt?) oder wie die Rechte zur Installation der benötigten Schadsoftware erlangt haben (Tactic „Priviledge Escalation“). Da man bereits weiß, dass die Angreifer Metasploit eingesetzt haben kann man zunächst nach IoCs suchen, die von diesem Framework erzeugt werden.

Auch in der OT ist dieses Vorgehen bei der Untersuchung von Vorfällen hilfreich. Die ICS-Matrix von ATT&CK ® kennt weniger Tactics und weniger Techniques. Dem folgend, sind die Möglichkeiten der Angreifer in der OT tendenziell begrenzter, was die Nachvollziehbarkeit von Angriffen durch Incident Responder erleichtert.

IoCs aus Controllern

Jetzt tauchen wir nochmal tief in die OT ab. Bisher waren OT-IoCs solche, die man im Traffic des Feldbusses, oder in den Purdue-Ebenen darüber findet. Aber kann man auch weiter unten, also in Controllern oder gar in Feldgeräten IoCs finden?

Die Antwort lautet: Ja, kann man. Wenn es denn welche gibt, und das ist eher selten der Fall.

SPS-Programme ändern sich i.d.R. nicht täglich, der naheliegendste IoC ist also, wenn sich im Programm etwas verändert hat und keiner weiß, warum. Wenn man nun festgestellt hat, dass das Programm sich geändert hat, gibt es i.d.R. Herstellertools, um die Änderungen sichtbar zu machen und zu untersuchen.

Am besten lässt man sich eine Abweichung der Checksumme im Leitsystem alarmieren (das Leitsystem ist hier sowieso das beste System zur Angriffserkennung, wenn man die richtigen IoCs alarmiert). Aber auch andere Veränderungen, z.B. eine signifikante Abweichung der Zykluszeiten oder unerwartete Fehler (Division durch null o.Ä.) können darauf hinweisen, dass sich der Programmcode geändert hat.

Befragung von Menschen

Wie in jedem Kriminalfall muss man auch bei Cyberangriffen i.d.R. Menschen nach ihren Erlebnissen im Zusammenhang mit dem Angriff befragen, um an wertvolle Informationen zu kommen. Beispiele für Fragen können sein:

- Um welche Uhrzeit haben Sie auf den Phishing-Link geklickt?

- Haben Sie eine Erpressernotiz bemerkt?

- Gab es eine Meldung des Antivirus?

- Welches System war als erstes betroffen?

- …

Viele dieser Fragen können auch durch Untersuchung von Systemen beantwortet werden, aber im ersten Moment ist die Befragung von Menschen schneller und effektiver, um sich ein erstes Bild der Lage zu verschaffen. Man kann sich allerdings (wie bei einem Kriminalfall) nicht darauf verlassen, dass alle Aussagen immer der Wahrheit entsprechen. Im Gegensatz zum Krimi kann bei der Incident Response die Aussagen aber oft technisch überprüfen, was man auch tun sollte!

Gute Incident Responder haben neben den neusten und ausgeklügelsten Forensik-Tools auch immer eine Liste mit Fragen dabei, die sie den betroffenen Mitarbeitenden stellen. Zumeist hat die Befragung zwei Ziele:

• Initiale Eingrenzung der betroffenen Systeme, als Grundlage für die Triage (welche Systeme untersuche ich zuerst?)
• Den zeitlichen Ablauf des Angriffs zu verstehen. Wenn man z.B. sicher weiß, um welche Uhrzeit auf einen Phishing-Link geklickt wurde, dann weiß man auch, dass alle vor diesem Zeitpunkt angefertigten Backups clean sind

In OT-Umgebungen spielt die Befragung von Menschen oft eine umso größere Rolle. Die zu befragenden Personen sind hier oft Ingenieure, Handwerker, Operatoren oder Werker. Incident Responder müssen auch in der Lage sein, die richtigen Fragen zu stellen, da sich der Incident i.d.R. auf das Anlagenverhalten auswirkt. Man bekommt die Auswirkungen des Incidents dann in der Sprache der OT erklärt (z.B. „Erst hat Messwarte X bemerkt, dass sich die Messstellen ABC out-of-Spec werte liefern. Dann ging in Schaltraum Y der Alarm im Tafelfeld an, dann hatten wir bei der SPS auf einmal längere Zykluszeiten…“).

In jedem Fall hilft es bei der Response zu einem Incident, wenn Mitarbeitende vorher geschult wurden auf verdächtige Aktivitäten bzgl. Cybersicherheit zu achten. Die meisten Awarenessschulungen zielen auf Prävention von Vorfällen ab („Bitte nicht auf den Phishing-Link klicken!“), aber aus meiner Sicht ist es genauso wichtig, grundlegende Regeln zu vermitteln für den Fall, dass ein Incident bereits eingetreten ist. Es beschleunigt die Incident Response ungemein, wenn

• Menschen wissen, was z.B. ein „verdächtiges“ Systemverhalten ist und dies entsprechend schnell an die Incident Responder weitergeben können
• Menschen die richtigen Maßnahmen treffen können, um den Incident zumindest nicht noch schlimmer zu machen

IoC Datenbanken nur für OT?

Zum Schluss noch ein abschließender Gedanke: Wieso gibt es eigentlich keine spezielle IoC-Datenbanken nur für OT, um speziell OT-Angriffe zu erkennen? Wäre sowas nicht sinnvoll?

Meine Antwort auf diese Frage lautet: Vielleicht ist es sinnvoll, aber in keinem Fall ausreichend, denn:

• Es gibt nur sehr wenige reine OT-Angriffe. Bis auf einige Ausnahmen (möglicherweise Stuxnet oder Incontroller) kommen bei Angriffen auf OT auch immer Techniken zu Einsatz, die auf IT-Systeme abzielen. Das ist nicht verwunderlich, schließlich sind Leitsysteme oder Engineering-PCs meistens mit normalen Windows oder Linux-Betriebssystemen ausgestattet, die man mit IT-Angriffstechniken angreifen kann. Ein „OT-Angriff“ kombiniert daher immer Angriffstechniken aus IT und OT.
• Selbst wenn man es mit einem Angriff nur auf die OT zu tun hat, kommt diese Erkenntnis erst spät im Incident-Response Prozess. Am Anfang weiß man noch nicht, womit man es zu tun hat und ermittelt in alle Richtungen. Die IT dabei auszulassen wäre sträflich, weil — wie oben erwähnt — bei den allermeisten Angriffen IT auch involviert ist. Kein Incident Responder würde sich also mit einer reinen OT IoC Datenbank begnügen können

Diese Gedanken kann man auch auf die Angriffserkennung anwenden: Wenn ein Angriffserkennungstool behauptet, auch OT-Umgebungen absichern zu können bedeutet das i.d.R., dass auch Anomalien in Industrieprotokollen erkannt werden können. Das geschieht zusätzlich zur Überwachung der “normalen“ IT-Anomalien. Es würde wohl niemand auf die Idee kommen, Angriffserkennung nur in der Feldbusebene zu betreiben (wenn man dort einen Angriff detektiert, ist es meistens schon zu spät). Stattdessen müssen auch die höheren Ebenen in die Angriffserkennung mit einbezogen werden.