Analyzing Penetration-Testing Tools That Threat Actors Use to Breach Systems and Steal Data
We discovered the use of two Python penetration-testing tools, Impacket and Responder, that malicious actors used to compromise systems and exfiltrate data. We share our key findings in this report.
Save to Folio
In den letzten Jahren haben wir immer häufiger beobachten können, dass bösartige Akteure legitime Windows-Tools in ihr Malware-Arsenal aufnehmen. Wir haben bereits gezeigt, wie PsExec, Windows Management Instrumentation (WMI), einfache Batch-Dateien oder Tools von Drittanbietern wie PC Hunter und Process Hacker verwendet wurden, um etwa Sicherheitsprodukte für Endgeräte zu deaktivieren, sich lateral im Netzwerk zu bewegen und Informationen zu exfiltrieren. Bei unserer neuesten Untersuchung stießen wir auf zwei Python-Tools, Impacket und Responder. Beide sind zwar nicht neu, aber erwähnenswert, da sie normalerweise für Penetrationstests verwendet werden.
Da Cyberkriminelle ihre Taktiken, Techniken und Verfahren (TTPs) häufig aktualisieren, um ihren Aktionsradius zu erweitern und wettbewerbsfähig zu bleiben, müssen Systemverteidiger heutzutage damit rechnen, dass Angreifer legitime Tools geschickt für schändliche Zwecke einsetzen.
Impacket und Responder
SecureAuth, der Entwickler von Impacket, definiert das Tool als Set von Python-Klasssen für die Arbeit mit Netzwerkprotokollen. Es bietet Low-Level-Zugriff auf die Pakete und einige Protokolle (wie SMB und MSRPC) oder die Protokollimplementierung selbst. Es stellt auch Werkzeuge zur Verfügung, mit denen ein Benutzer eine Remote-Ausführung vornehmen kann, z. B. smbexec.py für den Fall, dass der Zielcomputer nicht über eine schreibberechtigte Freigabe verfügt.
Responder wiederum ist ein Tool für die Übernahme von Windows-Umgebungen und wird häufig für interne Penetrationstests eingesetzt. MITRE ATT&CK® zufolge ist der Hauptzweck dieses quelloffenen Tools, „Name Services zu kompromittieren, um Hashes und Anmeldeinfos von Systemen im lokalen Netzwerk zu sammeln“. Es wird auch für die Kontaminierung von LLMNR, NBT-NS und MDNS mit eingebautem HTTP, SMB, MSSQL, FTP und anderem mehr genutzt. Viele halten Responder für ein wichtiges Pen-Tool.
Obwohl Windows-Tools häufiger erwähnt werden, ist Linux ebenso angreifbar durch solche heimtückischen Methoden. Es gibt eine lange Liste mit Linux-Binaries, die böswillige Akteure missbrauchen können, um „aus restriktiven Shells auszubrechen, erweiterte Rechte zu erlangen oder aufrechtzuerhalten, Dateien zu übertragen, Bind- und Reverse-Shells zu erzeugen und andere Post-Exploitation-Aufgaben zu erleichtern“. Die Akteure wechseln heutzutage zwangsläufig zwischen Windows und Linux, weil die Nutzung von Cloud-Technologie und die Implementierung von Remote-Arbeitsplätzen weiter voranschreiten.
Die Tatsache, dass Python sowohl unter Windows als auch unter Linux läuft, macht unsere Ergebnisse so bedeutsam. Während Unternehmen die Vielseitigkeit beider Systeme nutzen, stellt sie gleichzeitig ein zweischneidiges Schwert dar, da sie auch mehr Möglichkeiten für Cyberkriminelle bietet, Angriffe zu starten.
Die wichtigen Ergebnisse der Untersuchung
Da die böswilligen Akteure in vielen Phasen der Angriffe heimlich legitime Tools einsetzten, war es schwierig, anhand der von uns gesichteten Samples Einbrüche zu erkennen. Die Untersuchung des Threat Hunting Teams wurde durch das folgende Ereignis ausgelöst, das bei mehreren Hosts beobachtet wurde:
Zusätzlich entdeckten wir einen Tag vor dem Service Event Credential Dumping-Aktivitäten auf einem Host.
Die ungewöhnliche Kombination der oben genannten Ereignisse veranlasste das Trend Micro Managed Detection and Response (MDR)-Team, alle Endpunkte zu untersuchen, die von den verdächtigen Aktivitäten betroffen waren. Wir stellten fest, dass der verdächtige Random Service auf 27 Endpunkten vorhanden war. Die Liste der Endpunkte wurde im Laufe der weiteren Untersuchung immer länger.
Schon vor dem von uns beobachteten Credential Dumping gab es vereinzelte Hinweise auf eine mögliche Kompromittierung, auch wenn diese Ereignisse nicht eindeutig waren. Im Active Directory (AD) des Kunden wurde beispielsweise das zweite kompromittierte Konto, das wir identifizieren konnten, von den Angreifern verwendet, um sich über das Remote Desktop Protocol (RDP) anzumelden. Weitere technische Einzelheiten beinhaltet der Originalbeitrag.
Ausgehend von den im Bild gezeigten Informationen ist es möglich, dass es sich bei Patient Zero um den kompromittierten Linux-Host des Kunden handelt. Allerdings hatten wir vor der Untersuchung keinen Einblick in diesen Host, um diese Theorie zu beweisen. Diese Annahme stützt sich auf die Tatsache, dass die erste beobachtete verdächtige Anmeldung von dem genannten Host ausging. Später fanden wir außerdem heraus, dass die Angreifer ein anderes kompromittiertes Benutzerkonto für die verdächtigen Aktivitäten verwendeten.
Neues Nutzerkonto über Impacket
Der Dienst, den wir zunächst markierten, stellte sich als ein Ereignis heraus, das von dem Penetrationstest-Tool smbexec.py von Impacket erzeugt wurde, das wir schon in früheren Fällen gesehen haben. Dieses Ereignis ist jedoch ungewöhnlich, da es einen net.exe-Befehl ausführt, anstatt eine bösartige Anwendung zu starten. Ziel ist es, einen neuen Nutzer zu erstellen und ihn der lokalen Admin-Gruppe hinzuzufügen.
Im weiteren Verlauf unserer Untersuchung empfahlen wir dem Kunden die Installation des MDR-Agenten und wiesen ihn an, effiziente Detection and Response (EDR) zu aktivieren. Durch diese Maßnahmen wurde der Netzwerkzugang der bösartigen Akteure unterbunden. Nach einigen Tagen, während sich der Kunde von den Angriffen erholte und Best Practices für die Cybersicherheit implementierte, beobachteten wir, wie die böswilligen Akteure versuchten, sich über den Endpoint-Manager-Server des Kunden erneut mit dem Netzwerk zu verbinden. Weitere technische Details bietet der Originalbeitrag.
Es gab eine Diskrepanz bei der Auflösung von Hostnamen im ersten verdächtigen Anmeldeereignis, das im kompromittierten Windows AD des Kunden gesehen wurde. Dies könnte auf den frühen Einsatz von Responder zurückzuführen sein. Responder ist in der Lage, das Netzwerk abzuhören, um Passwort-Hashes und Benutzernamen zu ermitteln. Wenn ein Windows-Client einen Hostnamen nicht über DNS auflösen kann, wird er das LLMNR-Protokoll oder NBT-NS verwenden, um Computer in der Nähe zu befragen. In diesem Fall wird Responder aktiv: Er hört das Netzwerk auf LLMNR/NBT-NS-Rundrufe ab und kontaminiert dann die Anfragen, indem er sich als der Rechner ausgibt, mit dem der Windows-Client eine Verbindung herstellen will. Der Windows-Client gibt anschließend den Benutzernamen und den Kennwort-Hash an das Responder-Tool weiter. Der gesammelte Passwort-NTLM-Hash kann dann von den Angreifern mit Tools wie John the Ripper geknackt werden.
Einzelheiten zur Datenexfiltrierung mit Rclone und MegaSync finden Sie im Originalbeitrag.
Sicherheitsempfehlungen
MDR-Teams können ihre Arbeit wirksam erledigen, wenn Unternehmen ihre Monitoring-Lösung für die gesamte Umgebung aktivieren. Außerdem sollten sich die Nutzer der Risiken bewusst sein, die von der mangelnden Netzwerktransparenz ausgehen, denn sie könnten ihre Systeme unwissentlich ohne Absicht angreifbar machen und damit die Arbeit der Sicherheitsteams erheblich erschweren.
Eine proaktive Einstellung zur Cybersicherheit und die konsequente Umsetzung von Vorsichtsmaßnahmen im Bereich der Cybersicherheit sind von entscheidender Bedeutung, um Risiken zu mindern und einen Systembruch zu verhindern. Wir empfehlen Unternehmen die folgenden Best Practices:
- Stellen Sie sicher, dass Programme und Geräte nur dann mit dem Internet verbunden sind, wenn dies unbedingt erforderlich ist. Die Offenlegung von Teilen Ihrer Cloud-Infrastruktur bietet böswilligen Akteuren die Möglichkeit, auf Ihre Umgebung zuzugreifen.
- Priorisieren Sie internetfähige Infrastrukturen und kritische Systeme für System-Upgrades und die Verteilung von Patches. Halten Sie Ihre Softwareanwendungen und Betriebssysteme mit den neuesten Sicherheits-Patches auf dem neuesten Stand. Deaktivieren oder ersetzen Sie veraltete und anfällige Protokolle wie LLMNR und NBT-NS, die es böswilligen Akteuren ermöglichen, ihre Rechte problemlos zu erweitern.
- Aktivieren Sie eine Überwachungslösung mit Sichtbarkeit im gesamten Unternehmen. Blinde Flecken in der Sicherheit und Überwachung können zu unentdeckten und langwierigen Kompromittierungen führen.
- Stellen Sie sicher, dass die Ereignisprotokolle von 30 bis 60 Tagen für die Analyse zur Verfügung stehen. Im Falle einer länger andauernden Kompromittierung helfen diese Daten den MDR-Teams bei ihren Untersuchungen, um den Umfang der kompromittierten Endpunkte zu ermitteln. Passen Sie die Schwellenwerte für die lokale Speicherung und die Aufbewahrungsparameter an, oder ziehen Sie einen zentralen Speicherort für die Protokollierung in Betracht.
Trend Micro-Lösungen
Trend Micro Vision One™ unterstützt Sicherheitsteams dabei, einen Gesamtüberblick über Angriffsversuche in laufenden Kampagnen zu erhalten, indem die Lösung ihnen eine korrelierte Ansicht mehrerer Ebenen wie E-Mail, Endpunkte, Server und Cloud-Workloads bietet. Sicherheitsteams können eine breitere Perspektive und ein besseres Verständnis von Angriffsversuchen gewinnen und verdächtiges Verhalten erkennen, das bei Betrachtung nur einer Ebene harmlos erscheinen würde.