Zusammenfassung
- Censys Daten sind unglaublich reich an Details, die ohne ein geschultes Auge oft unbemerkt bleiben. Dieser Leitfaden hebt den Wert dieser stark strukturierten Daten hervor und gibt Einblicke, wie wir sie intern nutzen, um verdächtige Infrastrukturen zu finden.
- Wir veröffentlichen ein kostenloses Dienstprogramm namens Censeyedas nützliche Pivots in Censys Hostdaten entdecken und (optional) verwandte Hosts mit Hilfe der Daten dieser Entdeckungen crawlen kann.
Pivot für Profit
Nach jahrelanger Arbeit mit den Daten von Censys erkennen Sie Muster, die sich der Internetanalyse nähern. Im Laufe vieler Ermittlungen wächst Ihr Werkzeugkasten mit neuen Dienstprogrammen, Begriffen und Techniken, die Ihnen helfen, nahtlos von einem Anhaltspunkt zum nächsten überzugehen. Ganz gleich, ob Sie eine noch nie zuvor gesehene Software identifizieren oder die mit dem Internet verbundene Infrastruktur eines mutmaßlichen Kriminellen proaktiv aufspüren, am Anfang steht oft ein einziger Hinweis, der, wenn er gezogen wird, eine umfassendere Geschichte zu enträtseln beginnt.
Oft sieht man extrem generisch aussehende Hosts mit nur wenigen Diensten, die nur manchmal das sind, was sie zu sein scheinen; im Vergleich zur Gesamtheit des Internets sind viele dieser Hosts in der Tat ziemlich einzigartig. Nehmen Sie die folgende HTTP-Antwort:
HTTP/1.1 200 OK
Date: <REDACTED>
Server: Apache/2.4.41 (Ubuntu)
Content-Length: 0
Content-Type: text/html; charset=UTF-8
Auf den ersten Blick handelt es sich um eine typische HTTP-Antwort von einem Apache-Webserver, der unter Ubuntu läuft. Wenn wir Hosts nach genau diesem Server-Header-Wert filtern, finden wir über 420.000 Hosts mit der gleichen Konfiguration - nichtgerade einzigartig. Wenn wir jedoch die gesamte Antwort mit einem SHA-256-Hash analysieren und unsere Suche auf Port 80 beschränken, werden diese 420.000 Treffer auf nur 1.961 Ergebnisse eingegrenzt.
Das gilt auch umgekehrt: Etwas, das einzigartig aussieht, ist oft ziemlich generisch. JARM-Fingerprints werden häufig als Indikatoren für bestimmte Arten von Malware verwendet, aber in Wirklichkeit repräsentieren diese Fingerprints nicht die Malware selbst, sondern die zugrunde liegende TLS-API, auf der die Malware läuft. Wenn Sie also einen JARM-Fingerprint eines vermeintlich bösartigen Servers erhalten und sehen, dass er mit Zehntausenden von laufenden Hosts übereinstimmt(wie Metasploit JARM), sollten Sie ihn mit Vorsicht genießen.
Der Teufel steckt bei Internet-Scandaten im Detail. Wenn etwas ganz Bestimmtes auf einer begrenzten Anzahl von Hosts gefunden wird, bedeutet das oft (aber nicht immer), dass eine Verbindung hergestellt werden kann. Aber die Identifizierung dieser sehr spezifischen Dinge kann eine Herausforderung sein, und es ist leicht, einige Dinge zu übersehen, die unser Gehirn zu sehen gewohnt ist.
Ein Beispiel für etwas sehr Einzigartiges, an dem ich leicht vorbeigehen könnte, wenn es keinen anderen Kontext gibt, ist dieses TLS-Zertifikat:
Wenn wir den Vorhang etwas weiter zurückziehen, sehen wir, dass die "Microsoft IT"-Organisation nirgendwo in der Nähe eines Microsoft-eigenen Netzwerks zu finden ist, und es gibt sogar vier verifizierte Cobalt Strike-Dienste (auf zwei Hosts), die ein "Microsoft IT"-Zertifikat präsentieren.
"Das sieht interessant aus", sagen Sie sich vielleicht und klicken auf die Host-Details, um andere Hosts mit demselben HTML-Titel zu finden, nur um zwei passende Hosts in derselben ASN, aber in verschiedenen Subnetzen zu finden:
Wir fragen uns also, was zum Teufel "nmps" ist und warum es nur auf zwei Hosts gefunden wird, von denen einer offensichtlich bösartig ist. Also öffnen wir wieder die Seite mit den Host-Details und sehen uns den gesamten Antworttext an, um herauszufinden, was das ist, denn eine Suche im Internet nach "nmps" zeigt uns nur, dass es offenbar "New Mexico Professional Surveyors" gibt:
Dennoch gibt es hier keine guten Informationen, die mir helfen würden, herauszufinden, was "nmps" ist. Der HREF scheint abgeschnitten oder vielleicht beschädigt zu sein, also nehmen wir einen Ausschnitt des Textes und fügen ihn in GitHub ein, um zu sehen, ob er Teil eines Open-Source-Projekts ist, insbesondere der Text "404 not found,power by":
Und jetzt haben wir eine Antwort. "nmps" ist ein Fork von "nps", einem (ich zitiere) "leichtgewichtigen, hochleistungsfähigen, leistungsstarken Proxy-Server für die Intranet-Penetration" und, den Repo-Statistiken nach zu urteilen, ein sehr bekannter Server.
Der eine Host mit "nps", auf dem Cobalt Strike nicht läuft, 47.108.57.1, sieht mit diesen neuen Informationen viel verdächtiger aus. Wenn wir bei VirusTotal nach der IP suchen, sehen wir, dass 14 Anbieter diese IP als bösartig eingestuft haben:
Auf der Registerkarte "Community" des VT-Ergebnisses berichteten mehrere Benutzer, dass vor nur 19 Tagen ein Cobalt Strike-Beacon auf Port 80 gefunden wurde:
Um dies zu überprüfen, haben wir uns die historischen Daten dieses Hosts angesehen und festgestellt, dass bis zum 26. Oktober 2024 tatsächlich ein Cobalt Strike Beacon auf diesem Host existierte, genau wie auf dem anderen Server mit dem "NPS"-Fehler.
Leider können wir anhand der Internet-Scandaten nicht mit Sicherheit feststellen, ob diese beiden Hosts miteinander in Verbindung stehen, aber wir wissen, dass wir mit ein paar Handgriffen eine bisher unbekannte bösartige Infrastruktur identifizieren konnten.
Berichterstattung und Automatisierung
Dies ist eine Aufgabe, die wir hier auf Censys häufig durchführen: Wir verwenden eine verdächtige Eingabe, um noch mehr Dinge zu finden, die ebenso verdächtig aussehen. Und wenn man nicht weiß, welche spezifischen Felder in unseren Daten sich zum Pivotieren eignen, dann kann diese Aufgabe ziemlich mühsam sein, wenn sie manuell durchgeführt wird. Aber Pivoting ist das A und O. Also haben wir einige dieser einfachen Aufgaben für den internen Gebrauch automatisiert, was sich als sehr nützlich erwiesen hat - so sehr, dass wir uns entschlossen haben, dieses Tooling der breiteren Internetgemeinde zugänglich zu machen.
Censys Die Scandaten sind meiner Meinung nach "hochstrukturiert", da jede Information in ihre eigenen Felder aufgeteilt ist - eine Sache verzweigt sich mit einer anderen zu einem hierarchischen Baum, der es Ihnen ermöglicht, die Zugehörigkeit eines Elements zum nächsten zu verstehen. Dieses strukturierte Format eignet sich sehr gut, um von einem Datenpunkt zum nächsten zu wechseln.
Einführung von "Censeye": ein Tool zur automatischen Berichterstattung
Censeye ist ein terminalbasiertes Tool, das wir im Laufe einiger Wochen entwickelt haben und das mit einer einfachen Prämisse begann: Man nehme ein einzelnes strukturiertes Host-Ergebnis und sage mir für jedes Feld, wie viele andere Hosts im Internet das Gleiche haben. Um dies zu erreichen, haben wir einfach ein Scan-Ergebnis geparst und einen CenQL-Ausdruck für alle Schlüssel/Wert-Paare erzeugt. Dann führten wir für jede generierte Abfrage einen aggregierten Bericht aus, bei dem das Aufteilungsfeld die Anzahl der IPs ist. Ziel war es, interessante Pivots zu finden, die wir bei der manuellen Betrachtung eines Hosts möglicherweise übersehen hätten.
Wir erkannten sehr schnell, dass nicht alle Suchbegriffe geeignet waren, um Pivots zu finden, also begannen wir, eine Liste zulässiger Begriffe für die Berichterstellung zu erstellen. Außerdem fügten wir eine einfache Logik hinzu, die bestimmte Suchbegriffe hervorhebt, die zu vielversprechenderen Ergebnissen führen könnten. Wenn beispielsweise ein Schlüssel/Wert auf mehreren Hosts gefunden wird, aber weniger als ein konfigurierbarer Höchstwert ist, sollten diese Suchbegriffe im Vordergrund stehen. Nachstehend sehen Sie die Standardausgabe eines Berichts, der für die IP-Adresse "114.55.250.233" erstellt wurde.
Hier sehen wir eine Tabelle mit drei Spalten - die erste Spalte ist die Anzahl der eindeutigen IP-Adressen, die dem Schlüssel von Spalte 1 mit dem Wert von Spalte 2 entsprachen. Die fettgedruckten Zeilen zeigen die Suchbegriffe, die mehr als eine, aber weniger als (die Standardeinstellung) 120 Übereinstimmungen hatten. Schließlich werden alle "interessanten" Suchbegriffe angezeigt, die auf dem Weg gefunden wurden. Wenn das Terminal dies unterstützt, sind alle angezeigten Daten interaktiv und leiten Sie zum Censys Suchergebnis für dieses spezifische Element weiter.
Es gibt einige zusätzliche Manipulationen, die im Backend für jede Eingabe vorgenommen werden; zum Beispiel werden einige der TLS-Ergebnisse tatsächlich mehrere Berichte auf unterschiedliche Weise erzeugen:
- Ein Bericht über den genauen TLS-Schlüssel/Wert: services.tls.certificates.leaf_data.subject.common_name: "example.com"
- Ein weiterer Bericht, der nach (nicht services.tls.certificates.leaf_data.subject.common_name: "example.com") und "example.com" sucht
Es geht darum, einen Hostnamen aus dem Zertifikat zu nehmen und zu sehen, ob er irgendwo anders im Internet auftaucht.
Kurz gesagt, der Arbeitsablauf von Censeye besteht aus einem sechsstufigen Prozess. Ausgehend von einer eingegebenen IP-Adresse ruft das System Hostdaten von Censys ab und extrahiert und verfeinert Schlüssel-Wert-Paare aus den Servicedetails, um nur die wichtigsten Felder zu erhalten. Aus Censys wird für jedes ausgewählte Schlüssel-Wert-Paar ein aggregierter Bericht erstellt, wobei die Anzahl der IP-Adressen als Aufschlüsselungsmetrik dient. Anschließend wird ein halb eindeutiger Schwellenwert angewendet, um "interessante Suchbegriffe" zu identifizieren. Wenn ein Tiefenparameter angegeben ist, holt das Dienstprogramm eine Liste übereinstimmender Hosts, extrahiert deren IP-Adressen und verwendet sie erneut als Eingabe im ersten Schritt. Dieser Zyklus wiederholt sich, bis der Tiefenzähler Null erreicht. Nichts Ausgefallenes.
Der nüchterne Berichtsmechanismus hat sich als unglaublich nützlich erwiesen, da wir viele neue Dinge gefunden haben, die wir ohne ihn vielleicht übersehen hätten. Ein alltäglicher Anwendungsfall für uns besteht darin, Hosts, die bereits als Command-and-Control (c2)-Server eingestuft wurden, zu füttern, um Verbindungen zu anderen Hosts zu finden, die nicht als "c2" gekennzeichnet sind. Mit anderen Worten: Wir fragen, ob es bekannte C2-Server gibt, die Verbindungen zu einer unbekannten Infrastruktur haben.
Standardmäßig liest Censeye von stdin, so dass es einfach ist, andere Tools, wie die Censys CLI, zu verwenden, um Hosts zu erzeugen. In diesem Fall wollen wir Hosts betrachten, die bereits als "c2" gekennzeichnet sind, aber bei der Erstellung der Host-Berichte für jedes Feld alle Hosts, die als "c2" gekennzeichnet sind, von den Gesamtwerten ausschließen. Dies wird mit dem Flag"-query-prefix" erreicht:
~$ censys search 'labels=c2' | \
jq '.[].ip' | \
python censeye.py --query-prefix 'not labels=c2'
Für jede der eingegebenen IPs wird derselbe tabellarische Bericht erstellt:
Sie werden bemerken, dass mehrere dieser Zeilen eine Host-Anzahl von Null haben; dies liegt an dem Abfrage-Präfix-Argument, das wir oben gesetzt haben - dies sagt uns, dass diese Zeilen nur auf Hosts gefunden wurden, die bereits das Label "c2" haben, so dass wir drei "interessante" Suchbegriffe haben, die auf Nicht-2-Hosts gefunden wurden:
Wo wir gerade beim Thema Zertifikate sind - wenn Censeye einen TLS-Zertifikatsfingerabdruck sieht, der nur auf einem einzigen Host zu finden ist (d.h. das Zertifikat wurde nur auf dem Host gesehen, den Sie gerade betrachten), versucht es festzustellen, ob dieses Zertifikat in der Vergangenheit auf irgendeinem anderen Host gesehen wurde, und wenn ja, wird diese Information zur Verfügung gestellt. Nehmen Sie diesen angeblichen MoonBounce C2-Server als Beispiel:
Dieses eine Zertifikat wird derzeit nur auf diesem Host beobachtet, ist aber seit 2020 auf über 17 verschiedenen Hosts aufgetaucht. Im Hauptbericht wird dies ebenfalls hervorgehoben, indem die Anzahl der (einzigartigen) historischen Hosts in Klammern angegeben wird. Dies ist nur eine schnelle Möglichkeit, um festzustellen, ob ein einzelnes Zertifikat auf einem Host schon einmal irgendwo anders aufgetaucht ist. Es ist zu beachten, dass die Historie und wie weit in die Vergangenheit Sie sehen können, an die Berechtigungsstufen Ihres Kontos gebunden ist.
Da wir bereits angeben, was wir für "interessante" Suchbegriffe halten, und eine strenge Liste von Feldern haben, die es befolgen wird, mit Beschränkungen für die Datenmenge, die wir abrufen können, haben wir genügend Leitplanken, damit das Tool unabhängig arbeiten kann. Anstatt also einen einzelnen Bericht abzurufen, sich die Ergebnisse der gefundenen Suchbegriffe anzusehen und dann weitere Berichte auf der Grundlage dieser Suchvorgänge zu erstellen, können Sie Censeye anweisen, dies für Sie zu tun.
Zur Veranschaulichung betrachten wir eine einzelne IP-Adresse(5.188.87.38), die in letzter Zeit als C2-Server für den Stealc-Infodiebstahl beobachtet wurde. Wenn wir uns den Host auf Censys ansehen, sehen wir, dass es nicht viel zu geben scheint:
Trotzdem können wir unter Censeye sofort sehen, dass der SSH-Dienst auf Port 22 einen Fingerabdruck hat, der mit 45 anderen Hosts übereinstimmt.
Wir können dies entweder manuell anklicken und selbst nachschauen, oder wir können ein neues Flag angeben, das das Tool anweist, Berichte über alle Ergebnisse der "interessanten Suchbegriffe" zu erstellen. Censeye kann sich wie eine Art Crawler verhalten - bei einer Tiefe von Null (der Standardeinstellung) zeigt es nur die Berichte über den abgefragten Host an. Erhöht man jedoch die Tiefe, holt das Tool passende Hosts für die "interessanten Suchbegriffe", die es auf dem ursprünglichen Host gefunden hat, und führt den gleichen Berichtsprozess für diese durch.
Hier ändern wir unsere ursprünglichen Argumente mit "-depth 1". Für alle "interessanten Suchbegriffe", die auf 5.188.87.38 gefunden werden, holt das Tool eine Liste von Hosts, die damit übereinstimmen, und erstellt für jeden denselben Bericht. Da wir bereits gesehen haben, dass der einzige gemeinsame Suchbegriff auf diesem Host der SSH-Fingerprint ist, zeigt das Tool bei dieser Tiefe nur Informationen über die anderen Hosts an, die denselben Fingerprint verwenden.
Die Ausgabe ist nun etwas anders; wir werden mit vielen weiteren tabellarischen Berichten für alle übereinstimmenden Hosts begrüßt, aber dieses Mal haben wir ein neues Ergebnis, das den "Pivot-Baum" anzeigt, der eine visuelle Darstellung der Hosts ist, die wir entdeckt haben, und wie das Tool dorthin gelangt ist.
In der obigen Ausgabe sehen wir mehrere neue IP-Adressen, die alle denselben SSH-Fingerabdruck haben wie unsere ursprüngliche IP-Adresse 5.188.87.38. Außerdem werden oben zwei "interessante Suchbegriffe" angezeigt, nämlich der ursprüngliche SSH-Fingerabdruck, mit dem diese Hosts entdeckt wurden, und ein zweiter (halbwegs) eindeutiger SSH-Fingerabdruck, 6278464b, der auf sieben verschiedenen Hosts läuft, darunter ein einzelner Host, 179.60.149.209.
Wenn wir uns diesen neuen Host in Censys ansehen, sehen wir, dass der ursprüngliche SSH-Fingerprint auf Port 22 läuft, während dieser neue SSH-Fingerprint (zusammen mit sieben anderen Hosts) an Port 2222 gebunden ist.
Spulen wir also ein wenig vor und setzen unseren "-depth"-Wert auf "3". Das bedeutet, dass das Tool versuchen wird, interessante Censys Suchbegriffe in drei Iterationen zu finden. Alle diese Hosts haben eine oder mehrere Verbindungen mit dem übergeordneten Rechner, in diesem Fall eine ganze Reihe von gemeinsamen SSH-Fingerprints.
Im obigen Beispiel führte 193.29.13.183 den SSH-Fingerprint bd613b3b aus, der mit Port 22 auf 185.232.67.15 identisch ist. Auf dem Host 185.232.67.15 lief auch 6278464b, der gleiche Fingerabdruck wie auf 179.60.149.209, Port 2222. Auf diesem Port lief f95812cb, derselbe Fingerabdruck, der auf unserem ursprünglichen (Stealc C2) Host 5.188.87.38 gefunden wurde.
Hinweis: Der Teil "(via: ...)" des Pivot-Baums ist der CenQL-Begriff, der zum Auffinden dieses Hosts verwendet wird.
Bei unserer letzten Suche (in Tiefe 3) wurden mehrere neue Suchbegriffe gefunden, die weitere Informationen liefern könnten:
Es sollte angemerkt werden, dass all dies auch mit historischen Hostdaten funktioniert; wenn ich zum Beispiel weiß, dass es einen Cobalt Strike Server auf einem Host gab, der entweder abgeschaltet wurde oder der Dienst entfernt wurde, und Sie das Datum kennen, an dem er zuletzt auf dem Host gesehen wurde, können Sie das '-at-time' Flag wie folgt angeben:
% python censeye.py 103.234.98.97 --at-time 2024-09-25
Angenommen, das Tool findet ein historisches Zertifikat (wie zuvor beschrieben, ein Zertifikat, das derzeit nicht läuft, aber in der Vergangenheit gelaufen ist), und das Flag "-depth" wird angegeben. In diesem Fall verwendet Censeye die historischen Hostdaten, in denen das Zertifikat gefunden wurde, um potenzielle Pivots für den aktuellen Tag zu finden. Sowohl der Host-Bericht als auch der Pivot-Baum zeigen Ihnen das Datum an, an dem diese Ergebnisse abgerufen wurden:
WARNUNG!
- Dieses Tool kann viele Abfragen verbrauchen, was bedeutet, dass die Betrachtung eines einzigen Hosts Ihr gesamtes monatliches Kontingent aufbrauchen kann.
- Das Tool ist auch nicht sehr schnell; für jedes (konfigurierte) Feld auf einem Host wird ein Bericht erstellt, was bedeutet, dass mehrere API-Aufrufe im Hintergrund erfolgen. Wenn Sie das Tiefenflag verwenden, erhöht sich die Anzahl der API-Aufrufe exponentiell.
Wir haben jedoch mehrere Zwischenspeicher implementiert, um die Anzahl der API-Aufrufe während einer einzelnen Sitzung zu verringern. Diese werden alle in einem benutzerdefinierten "Arbeitsbereich" gespeichert (der mit dem Argument "-workspace" neu definiert werden kann). Mein (persönlicher) Arbeitsablauf sieht so aus, dass ich für jede "Sache", die ich untersuche, einen anderen Arbeitsbereich verwende. Auf diese Weise habe ich eine lokale Version der Daten, die ich ursprünglich abgerufen habe, und kann sie später überprüfen und schrittweise in verschiedene Pivots einsteigen, die das Tool findet.
Outro
Ein README auf dem Censeye Github Repository wird mehr Informationen enthalten, da es sich noch in aktiver Entwicklung befindet.
