PowerShell für Angreifer

PowerShell ist in Windows integriert, eng mit dem Betriebssystem und .NET verzahnt und wird von Administratoren als vertrauenswürdig angesehen. Dadurch ist es ein beliebtes Living-off-the-Land-Tool für Angreifer – sie müssen keine Malware ablegen.

Diese Lektion behandelt Konzepte des offensiven PowerShell, die Sie verstehen müssen, um Windows anzugreifen und zu verteidigen.

PowerShell-Befehle sind Cmdlets in der Form Verb-Nomen. Sie reichen umfangreiche Objekte (nicht nur Text) durch die Pipeline weiter, wodurch Enumeration besonders leistungsfähig wird.

Angreifer verwenden integrierte Cmdlets, um einen Host schnell zu untersuchen – Benutzer, Dienste, Netzwerk und installierte Patches.

Die Ausführungsrichtlinie schränkt das Ausführen von Skriptdateien ein, stellt aber keine Sicherheitsgrenze dar. Viele einfache Schalter umgehen sie, daher sollten sich Verteidiger nicht darauf verlassen.

Bei einer verbreiteten Technik wird eine Payload abgerufen und im Speicher ausgeführt, sodass nur wenige Spuren auf der Festplatte zurückbleiben. Deshalb sind Netzwerküberwachung und AMSI wichtig.

Der Schalter -EncodedCommand führt Base64-codiertes PowerShell aus und wird häufig verwendet, um die Absicht vor einer oberflächlichen Prüfung und einfachen Filtern zu verbergen.

Verteidiger decodieren diese Einträge aus den Protokollen, um sichtbar zu machen, was tatsächlich ausgeführt wurde.

Ausgereifte Toolkits bauen auf diesen Grundlagen auf:

• PowerSploit / PowerView – AD-Enumeration und Post-Exploitation.
• Empire / Covenant – Command-and-Control.
• Nishang – offensive Skripte.

Die meisten werden inzwischen von Schutzmechanismen umfassend anhand von Signaturen erkannt.

In einer Domäne bildet PowerShell (PowerView oder das AD-Modul) Benutzer, Gruppen und Vertrauensbeziehungen ab – die Grundlage, um einen Pfad zu Domain Admin zu finden.

Microsoft hat speziell zum Schutz vor dem Missbrauch von PowerShell folgende Abwehrmechanismen hinzugefügt:

• AMSI (Antimalware Scan Interface) scannt Skriptinhalte vor der Ausführung.
• Script Block Logging protokolliert, was ausgeführt wird.
• Constrained Language Mode schränkt gefährliche Funktionen ein.

Angreifer versuchen, AMSI zu umgehen; Verteidiger überwachen die Protokolle.

Blue Teams suchen nach schädlichem PowerShell, indem sie auf Folgendes achten:

• Codierte oder verschleierte Befehle.
• Netzwerkabrufe mit DownloadString / IEX.
• Ungewöhnliche übergeordnete Prozesse (Office startet PowerShell).
• AMSI- und Script-Block-Protokolle mit der Ereignis-ID 4104.

Diese Techniken sind leistungsfähig und entsprechen direkt Vorgehensweisen bei realen Eindringversuchen. Führen Sie sie nur in Ihrem eigenen Labor oder mit einer ausdrücklichen schriftlichen Genehmigung aus.

Auch die defensive Seite zu üben – Protokolle zu lesen und AMSI-Treffer zu erkennen – ist genauso wertvoll wie die offensive Seite.

Bewerten Sie die Ausführungsrichtlinie als Kontrollmaßnahme.

Sie haben offensives PowerShell untersucht:

• Objektbasierte Cmdlets machen Enumeration leistungsfähig und unauffällig (Living-off-the-Land).
• Herunterladen und Ausführen, codierte Befehle sowie Frameworks wie PowerView und Empire.
• Die Ausführungsrichtlinie ist keine Sicherheitsmaßnahme; AMSI und Script Block Logging sind die tatsächlichen Schutzmechanismen.
• Arbeiten Sie stets verantwortungsvoll und befassen Sie sich auch mit der defensiven Seite.

Damit ist der Kurs zu den Windows-Interna abgeschlossen.