Wenn der Portscan legitim ist: Lesson-Learned aus (k)einem Incident

Incident Response

Sobald man als Incident Responder ein Erstgespräch mit einem Kunden führt, entwickelt man bereits (unbewusst) Theorien, wie der geschilderte Fall zustande gekommen sein könnte und was noch alles passieren kann. Ab und zu bekommt man jedoch einen Fall geschildert, bei dem man das Gefühl nicht loswird, dass es sich dabei nicht um einen Incident handelt, sondern um irgendein harmloses IT-Problem. Diesen Fall hatten wir neulich wieder. Die Ausgangssituation war, dass mehrere Portscans durch das NDR erkannt wurden und die firmeninternen Security Analysten Unterstützung benötigten. Die Portscans waren hier auch gegen Clients gerichtet und haben immer die gleichen Ports gescannt.

Zu diesem Zeitpunkt wurde bereits vermutet, dass es sich hierbei nicht um einen Incident handelt, da a) Clients gescannt werden und b) die Anzahl der scannenden Geräte sehr hoch ist. Ein Angreifer würde vermutlich eher Server scannen und die Anzahl der Geräte vielleicht etwas geringer halten, um nicht erkannt zu werden. Trotzdem muss man natürlich in alle Richtungen analysieren.

Da wir durch das NDR nur einen Timestmap, das Quellsystem und die gescannten IPs/Ports zur Verfügung hatten, entschieden wir uns, das betroffene System, welches einen Portscan durchgeführt hat, forensisch zu analysieren, um herauszufinden, was den Portscan verursacht hat und ob es bösartig war. Da wir über einen Timestamp des Portscans verfügten, konnten wir die initiale Triage auf einen kurzen Zeitraum eingrenzen und nichts Verdächtiges entdecken, außer dass viele verschiedene PowerShell-Skripte ausgeführt wurden, was im Windows-Powershell und Microsoft-Windows-PowerShell Operational Eventlog protokolliert wurde. Bei näherer Betrachtung stellte sich heraus, dass diese PowerShell-Skripte Teil des Defender Advanced Threat Protection (ATP) sind. Da wir einen großen Kreis von Defender Experten haben, wussten wir auch, dass der Defender ein Device Discovery Feature hat, das durch diese PowerShell Skripte ausgeführt wird. Bei der Device Discovery scannen die Systeme, die bereits mit dem Defender ausgestattet sind, das Netzwerk, um weitere Systeme zu finden und zu inventarisieren (mehr dazu hier https://learn.microsoft.com/en-us/defender-endpoint/device-discovery-faq?view=o365-worldwide).

Nach kurzer Recherche stießen wir auf diesen wunderbaren Blog-Post von Stephan Berger, der das von uns vermutete Verhalten beschreibt. Das macht die Analyse natürlich viel einfacher.

Im Windows-PowerShell.evtx Eventlog, haben wir folgenden Eintrag gefunden, welcher zeitlich mit dem Timestamp aus dem NDR Alarm übereinstimmt.

C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -ExecutionPolicy Bypass -NoProfile -NonInteractive -File C:\ProgramData\Microsoft\Windows Defender Advanced Threat Protection\Downloads\PSScript_{06C1AA36-99E0-48A8-BEBD-B908CFC3DDA1}.ps1 -ParamsAsBase64 <BASE64 BLOB>

Hier wurde das PowerShell Skript PSScript_{06C1AA36-99E0-48A8-BEBD-B908CFC3DDA1}.ps1 ausgeführt und dabei ein Base64 kodierter String als Parameter übergeben. Dekodiert man den Base64 String, so erhält man folgende Daten:


{
    "ScannerArgs":{
		"IpsToScan": "<Komma seperierte Liste an IPs die gescannt werden>",
	    "Guid":<GUID>",
	    "MachineId": "<ID der lokalen Maschine>",
	    "MachineConnections":[{
		    "DefaultGatewayMac":"<DEFAULT GATEWAY MAC>",
		    "AdapterId":"{<ADAPTER ID>}",
		    "NetworkNames":["<DOMÄNE>"]}],
	    "ScannedDeviceId":"48c8ffda910f3fff818ceb1bb98f744d166185e5",
	    "ExpirationDateTime":"2024-10-12T10:40:36.7794801Z",
	    "CvesToScan\":[],
	    "TargetMacs":"<MAC Adressen>",
		"DeviceIdsToScan":"<Komma seperierter List an DeviceIDs die gescannt werden>"
	    }",
    "Cert":  "<CERTIFICATE>",
    "InterfaceIndex":  "24",
    "SHA256Signature":  "<SHA256 Prüfsumme des Zertifikates>
}

Die IPv4 Adressen aus dem Feld IpsToScan  waren die IPs, die gescannt wurden. Dies wurde mit den Daten aus dem NDR abgeglichen.

Das eigentliche PowerShell Scipt wurde hierbei auch kurz analysiert. Weitere Defender ATP Skripte

Sollte man nun selber die Situation haben, dass Portscan erkannt werden und man grade den Defender ausrollt, so empfehle ich folgende Schritte um sicherzustellen, dass der Portscan von Defender ausgeführt wurde.

Lesson-Learned

Machmal hat das Bauchgefühl Recht und nicht alles, was nach einem Angreifer aussieht, ist auch von einem Angreifer. Das Verhalten hatte legitime Gründe, die sich im Nachhinein bestätigt haben. Daher ist die Lesson-Learned, dass während des Rollouts des Defenders auch die Device Discovery aktiv ist und dies beachtet werden muss, wenn andere Sicherheitstools parallel laufen. Alternativ kann man auch sagen, dass die Features der verwendeten Tools bekannt seien sollten, um solche Ereignisse nicht als Verdächtiig zu klassifizieren, aber wer kennt schon alle Features?

Beitrag teilen auf:

XING
Twitter
LinkedIn

Evgen Blohm • Autor

Senior Cyber Defense Consultant

Bereits als Werkstudent unterstützte Evgen die SECUINFRA in den Bereichen Malware Analyse und Forensik. Seit 2020 arbeitet er in den Bereichen SOC Analyse, Compromisse Assessment und Digitale Forensik für diverse Kunden.

> alle Artikel
Cookie Consent mit Real Cookie Banner