Fortgeschrittene Verfolgung der persistenten Infrastruktur

Einführung

Die meisten Cyber-Aktivitäten böswilliger Akteure erfordern eine Infrastruktur wie Server im Internet. Je größer die Kampagne ist, desto mehr Server werden benötigt. Einige APT-Gruppen haben im Laufe der Jahre mehrere Tausend Command and Control (C2)-Server eingesetzt. Für Threat Intelligence bietet dies einzigartige Möglichkeiten, solche Aktivitäten zu verfolgen, da die C2-Server oft auf eine bestimmte Weise konfiguriert werden müssen und viele Akteure ihre eigenen Gewohnheiten bei der Einrichtung von Servern entwickelt haben. Ein wesentlicher Vorteil gegenüber rein forensischen Untersuchungen von Vorfällen besteht darin, dass durch die Analyse der Infrastruktur C2-Server manchmal schon identifiziert werden können, bevor sie bei einem Angriff eingesetzt wurden. Internet-Suchmaschinen wie Censys sind für diese Art der Analyse von entscheidender Bedeutung. Sie sammeln Informationen über Hosts im Internet und ihre Konfigurationen und ersparen den Forschern so die Mühe, große Adressräume selbst zu durchsuchen.

In diesem Artikel wird erklärt, warum das Aufspüren von Infrastrukturen möglich ist, welche Attribute wichtig sein können, um einen Blick darauf zu werfen, es werden zwei aktuelle Beispiele sowie ein Beispielprozess gezeigt und es werden einige Tipps für den Einstieg in die Infrastrukturanalyse gegeben. Beachten Sie, dass in diesem Artikel nur passive Methoden zum Auffinden und Clustern bösartiger Infrastrukturen besprochen werden. Aktive Methoden, wie z. B. das eigene Scannen nach Hosts, bieten weitere Möglichkeiten, wie z. B. die Nachahmung des Handshakes einer Malware, um C2-Server oder Opfer mit hoher Sicherheit zu identifizieren. Außerdem behandelt dieser Artikel nur HTTP(S)-basierte Infrastrukturen.

Hintergrund

Es gibt mehrere Gründe, warum bösartige Infrastrukturen über Censys und ähnliche Dienste gefunden werden können, und die meisten davon sind auf Fehler bei der Betriebssicherheit (OPSEC) zurückzuführen. Der folgende Abschnitt ist sicherlich nicht erschöpfend, aber er nennt einige wichtige Punkte, warum solche Fehler passieren. Einige Akteure sind sich ihrer Fehler vielleicht nicht bewusst, andere wiederum sind sich vielleicht sogar der Auswirkungen auf die OPSEC bewusst. Da sie jedoch die OPSEC gegen die Effizienz eintauschen müssen, scheinen sie sich manchmal zu entscheiden, das Risiko einzugehen.

1. Das Tempo der Cyberangriffe hat stark zugenommen Während Cyberangriffe vor einigen Jahren noch die Ausnahme waren, sind sie heute an der Tagesordnung. Aufgrund der wachsenden Zahl von Zielen ist auch der Bedarf an Infrastruktur gestiegen. Um wertvolle Zeit zu sparen, wird eine Art von Infrastrukturautomatisierung zur Einrichtung und Konfiguration von Servern eingesetzt. Einige Akteure wählen den einfachsten Weg, indem sie vorbereitete Images bereitstellen, während andere C2-Server über Skripte einrichten.

2. Verschiedene Teams sind für die Durchführung von Kampagnen und den Aufbau der Infrastruktur zuständig. Während einige erfahrene Betreiber (die die eigentlichen Angriffe durchführen) mit den OPSEC-Fallen vertraut sind, wird die Infrastruktur in einigen Gruppen von einem anderen Team aufgebaut, das die technischen Möglichkeiten zur Identifizierung seiner Server nicht kennt.

3. Oft ist es notwendig, den Opfern vorzugaukeln, dass die verwendete Infrastruktur legitim ist. Dies kann entweder der Fall sein, um sich im allgemeinen Netzverkehr zu verstecken, oder weil das Opfer verdächtige Adressen in der URL-Leiste erkennen würde, z. B. bei Phishing-Kampagnen.

4. Kein OPSEC-by-design Im Allgemeinen scheinen viele Akteure kein OPSEC-by-design zu verfolgen. Anstatt sich im Voraus Gedanken darüber zu machen, wie Threat Intelligence-Analysten ihre Server identifizieren könnten, scheinen sie nach dem Prinzip "Versuch und Irrtum" zu leben oder zumindest ihre OPSEC nur zu verbessern, nachdem sie in einem Threat Intelligence-Bericht geoutet wurden¹. Da wir keine OPSEC-Tipps für aktuelle Bedrohungen geben wollen, befasst sich dieser Blog-Beitrag nur mit bereits bekannten Infrastrukturen, über die bereits in Blogs berichtet wurde.

Kriterien für das Clustering von Hosts

Es gibt mehrere Kriterien, die zum Auffinden und Clustern von Infrastrukturen verwendet werden können. Einige davon sind hier aufgeführt, einschließlich der jeweiligen Attribute, die für die Suche nach diesem Host verwendet werden können - wie immer ist diese Liste nicht vollständig. Im Allgemeinen gibt es drei Gruppen von Kriterien: Antwort-Header, Antwort-Inhalt und Zertifikate. Da einige Bedrohungsakteure benutzerdefinierte serverseitige Software oder bestimmte Bibliotheksversionen verwenden, enthalten Antworten auf HTTP-Anfragen oft eine charakteristische Kombination von Headern. Hosts können also entweder nach dem Fehlen eines Headers oder nach bestimmten Header-Strings geclustert werden. Ein Beispiel für das Clustern von Hosts anhand von Antwort-Headern wird weiter unten behandelt. Bei Censys Abfragen können die Header gefiltert werden über

<port>.http(s).get.headers.

Auch der Inhalt der Antwort kann charakteristische Artefakte enthalten. Einige Command and Control-Server versuchen, einen bestimmten Webserver zu imitieren und liefern daher eine Art Standardseite als Index- oder Fehlerseite. Ein bekanntes Beispiel ist die Verwendung der Standardwebseite des Microsoft Internet Information Service (IIS) als Indexseite für Powershell Empire². Scandienste greifen in der Regel nur auf die Indexseite zu oder erhalten eine Fehlerseite als Antwort, wenn der C2-Server den Zugriff auf einen bestimmten Pfad erwartet. In diesen Fällen kann oft der Hash-Wert des Antwortkörpers zum Clustern von Hosts verwendet werden.

Andere Akteure verwenden manchmal ein Standard-Setup, bei dem eine andere Website zunächst vollständig geklont und anschließend geändert wird. In diesen Fällen kann es hilfreich sein, nach bestimmten Ressourcen auf der Website zu suchen, z. B. nach verwendeten Favicons, eingebetteten Javascript-Snippets (und darin möglicherweise enthaltenen Werbenetzwerk- oder Tracking-IDs) oder enthaltenen CSS-Dateien. Die letzte Gruppe von Kriterien sind Zertifikate. Die Filterung nach Seriennummer, Fingerprint oder Distinguished Name (siehe Beispiel 2 unten) kann eine nützliche Methode sein, um Hosts nach ihren Zertifikaten zu gruppieren. Akteure können dazu neigen, eine bestimmte Zertifizierungsstelle mit recht eindeutigen Begriffen im gemeinsamen Namen zu verwenden oder sogar selbstsignierte Zertifikate für ihre gesamte Infrastruktur zu verwenden.
Sowohl die Antwortinhalte als auch die Zertifikate werden manchmal so erstellt, dass sie potenziellen Opfern legitim erscheinen und daher bestimmte Elemente enthalten.

Beispiel 1 - Verfolgung anhand von HTTP-Headern

Cobalt Strike (CS) ist ein weithin bekanntes kommerzielles Toolkit für Penetrationstests, das nicht nur von Red Teams verwendet wird. Im Laufe der Zeit wurde es von vielen verschiedenen Bedrohungsakteuren als erste Stufe verwendet (und wird wahrscheinlich auch weiterhin verwendet). Die typische Serverantwort für Cobalt Strike kann wie folgt charakterisiert werden:

• HTTP 404 nicht gefunden
• Inhalt-Typ: text/plain
• Inhalt-Länge: 0
• Datum Kopfzeile
• Kein Server-Header

Mit diesen Kriterien können wir mit der folgenden Abfrage Censys leicht Server finden:

80.http.get.status_line: "404 nicht gefunden" 
AND 80.http.get.headers.content_type: "text/plain" 
AND 80.http.get.headers.content_length: 0 
NOT _existiert_:80.http.get.headers.server

_{Censys Abfrage nach Cobalt Strike-Instanzen auf Port 80}

Beachten Sie, dass nicht alle Ergebnisse, die Sie sehen, unbedingt Cobalt Strike-Instanzen sind, aber es ist ein guter Indikator. Außerdem ist Cobalt Strike, wie Sie vielleicht schon vermutet haben, nicht auf Port 80 beschränkt. Neben dem vom Tool verwendeten Standard-TLS-Zertifikat können Sie weitere Instanzen finden, die TLS verwenden, indem Sie zusätzlich nach gängigen Zertifizierungsstellen oder selbst signierten Zertifikaten suchen.

87f2085c32b6a2cc709b365f55873e207a9caa10bffecf2fd16d3cf9d94d390c

_{Censys Abfrage mit dem SHA256-Hash des standardmäßigen Fingerabdrucks des Cobalt Strike-Zertifikats}

Es gibt eine enorme Menge an Cobalt Strike-Infrastrukturen, die online verfügbar sind. Daher benötigen Sie höchstwahrscheinlich eine andere Art von Datenquelle, wie z. B. passive DNS-Daten, um die gefundenen Instanzen richtig zu clustern.
Ergebnisse für typische Cobalt-Strike-Header auf Port 80:

Beispiel 2 - Rückverfolgung anhand von Zertifikatsdaten

Im Juli 2020 veröffentlichte NCSC UK, die nationale Cybersicherheitsbehörde des Vereinigten Königreichs, einen Hinweis auf APT29, der auf die COVID-19-Impfstoffforschung^abzielte3. Die auch als "The Dukes" oder "Cozy Bear" bekannte Gruppe nutzte Citrix- und VPN-Schwachstellen, um verschiedene Unternehmen anzugreifen, die mit der Impfstoffentwicklung in Verbindung stehen. Bei diesen Kampagnen verwendete die Gruppe zwei maßgeschneiderte Malware-Familien, WellMess und WellMail. Die von den Tätern genutzte Infrastruktur umfasste sehr spezifische selbstsignierte Zertifikate, die es ihnen leicht machten, sie zu verfolgen, wie mehrere Quellen berichten. PwC veröffentlichte kürzlich einen Bericht über die von den Tätern verwendete serverseitige Software^4.

Aussteller: C=Tunis, O=IT, CN=* Betreff: C=Tunis, O=IT

Anhand der in Tabelle 1 aufgeführten Namen von Zertifikaten können wir eine Abfrage erstellen, um die neueste Infrastruktur zu finden:

443.https.tls.certificate.parsed.subject_dn: "C=Tunis, O=IT" AND 443.https.tls.certificate.parsed.issuer_dn: "C=Tunis, O=IT, CN=*"

Mit der Abfrage in Tabelle 2 können 20 Hosts anhand der Zertifikatsdetails gefunden werden.

Beispiel Prozess

Als ich mit der Verfolgung von Infrastrukturen begann, schrieb ich ein einfaches Python-Tool, das auf der Grundlage einer bestimmten Regel verschiedene Datenquellen abfragte.

Die Regel (siehe Abbildung 3) enthielt die erforderliche Abfrage, und das Skript schickte die Ergebnisse an andere Systeme. Da diese anfangs nur als Benachrichtigung dienten, nannte ich den Abschnitt "Alerts". Nachdem man Cronjobs eingerichtet hat, um seine Skripte auszuführen, kann man loslegen - ohne einen riesigen Software-Stack zu benötigen. Für den Fall, dass ich die rohen Antworten der abgefragten Quellen benötige, speichere ich alle API-Antworten in einer JSON-Datei. Auf diese Weise kann ich bei Bedarf eine völlig neue Datenstruktur erstellen,
ohne Daten zu verlieren.

Tipps für Einsteiger

Auch wenn Sie Ihre eigenen Verfahren für die Verfolgung der Infrastruktur entwickeln müssen, möchte ich einige Ratschläge für Neueinsteiger geben und hoffe, dass Sie die folgenden Tipps nützlich finden.

1. Kombinieren Sie verschiedene Ressourcen.

Um ein möglichst genaues Bild der von Angreifern genutzten Infrastruktur zu erhalten, ist es sehr hilfreich, verschiedene Dienste zu kombinieren, die unterschiedliche Arten von Informationen liefern. Zusätzlich zu den Host-Daten (z. B. von Censys oder Shodan) kann die Durchsicht der Infrastruktur durch passive DNS-Daten (z. B. RiskIQ oder Domaintools) und Zertifikatsdaten (z. B. Censys oder crt.sh) verbessert werden. Wenn Sie Daten von verschiedenen Anbietern nutzen, sollten Sie ein gemeinsames Datenmodell verwenden⁵.

2. Speichern Sie die Ergebnisse in einer durchsuchbaren und flexiblen Weise.

Nachdem Sie mit der Infrastrukturverfolgung begonnen haben, werden Sie irgendwann eine Menge Daten in den Händen halten, und Sie wollen auf jeden Fall in der Lage sein, diese Daten sehr schnell zu durchsuchen. Wenn Sie Ihre Daten in einem Elasticsearch-Cluster oder einem ähnlichen durchsuchbaren Datenspeicher haben, werden Sie eine Menge Zeit sparen. Wenn Sie Ihr Toolset einrichten, sollten Sie daran denken, dass Sie Ihre Daten mit regulären Ausdrücken durchsuchen möchten.

3. Behalten Sie ältere Ergebnisse.

Löschen Sie nicht die Ergebnisse älterer Suchanfragen. Die Aufbewahrung und Aktualisierung von Host-Informationen ermöglicht die Entdeckung interessanter Muster. Außerdem ist es sehr nützlich, das Datum des ersten und letzten Besuchs von C2-Servern zu kennen.

4. Dokumentieren Sie Ihre Abfragen.

Ihre ständig wachsende Zahl von Abfragen muss irgendwie dokumentiert werden, sonst verlieren Sie den Überblick. Ein guter Ausgangspunkt ist die Erstellung eines Schemas2 , das Metadaten wie eine Beschreibung enthält.

Schlussfolgerung

Bedrohungsakteure unterliegen ähnlichen Zwängen wie Netzwerkverteidiger - Zeit, Geld, Fähigkeiten und Faulheit. Dies führt zu Fehlern oder bestimmten Gewohnheiten beim Aufbau ihrer Infrastruktur. Mit etwas Kreativität und entsprechenden Werkzeugen können Netzwerkverteidiger diese Fehler und Gewohnheiten ausnutzen, um bösartige Infrastrukturen aufzuspüren. Die Belohnung sind IoCs und Einblicke in die Aktivitäten der Angreifer. Censys und andere Tools geben Analysten einen großen Vorsprung. Die Magie liegt dann in den Abfragen, die Sie schreiben. Ich hoffe, dass Sie die oben genannten Techniken und Tipps hilfreich fanden. Ich würde mich freuen, von Ihren Erfahrungen zu hören, Sie können mich über Twitter erreichen⁶ oder Keybase⁷.

1. _{Vgl. S. 75 Steffens, Timo (2020). Attribution of Advanced Persistent Threats.
   https:// doi.org/10.1007/978-3-662-61313-9}
2. _{Vergleichen Sie https://github.com/BCSECURITY/Empire/blob/master/lib/listeners/http.py#L262}
3. _{NCSC-UK (2020). APT29 zielt auf COVID-19-Impfstoffentwicklung.
   https://www.ncsc.gov.uk/files/Advisory-APT29-targets-COVID-19-vaccinedevelopment.pdf (Zugriff am 21.09.2020)}
4. _{PwC UK (2020). WellMess-Malware: Analyse des Command and Control (C2)
   Servers. https://www.pwc.co.uk/issues/cyber-security-services/insights/wellmessanalysis-command-control.html (Zugriff am 21.09.2020)}
5. _{Gemeinsames OSINT-Datenmodell für die Infrastrukturanalyse:
   https://github.com/3c7/common-osint-model (Zugriff am 21.09.2020)}
6. _{https:// twitter.com/0x3c7}
7. _{https://keybase.io/nkuhnert}