Die Powershell ist ein mächtiges, administratives Werkzeug. Viele Tätigkeiten lassen sich automatisieren. Fast alle Bereiche der Microsoft-Produkte lassen sich so steuern. Und die Powershell ist nativ mit an Bord. Jedes moderne Betriebssystem hat sie dabei.

Da ist es nur natürlich, dass auch unsere Hacker-Kollegen seit Langem einen Gefallen an dieser Plattform gefunden haben. Es existieren etliche Schadcodes für eine Vielzahl von Angriffen…

Doch auch Microsoft hat nicht (mehr) geschlafen! In der aktuellen PowerShell-Version gibt es einige interessante Schutzmechanismen. Diese möchte ich in einer Serie einmal vorstellen.

Voraussetzungen

Für einige der neuen Schutzmöglichkeiten wird die PowerShell-Version 5 benötigt. Diese gehört zu Windows 10 und Windows Server 2016 standardmäßig zur Grundausstattung. Auf älteren Systemen kann die PowerShell natürlich aktualisiert werden. Davon halte ich persönlich nicht viel, denn zu oft habe ich danach Probleme auf Clients und Servern beobachten dürfen. Aber auch für diese Systeme gibt es ein paar Einstellungsmöglichkeiten.

Generell halte ich es nicht für sinnvoll, die PowerShell einfach zu deaktivieren bzw. zu blockieren. Sie ist so tief im System verankert, dass ein geübter Angreifer es dennoch schaffen wird, auf einen PS-Prozess zuzugreifen. Und zudem ist sie für das Daily-Business einfach zu wertvoll!

Für die Angriffe habe ich eines meiner PSHacking-Scripte ausgewählt.

Und um einen Enterprise-Charakter darzustellen werde ich die Konfiguration natürlich über Gruppenrichtlinien vornehmen. Dazu steht in meiner LAB-Umgebung ein kleiner DomainController bereit.

mögliche Angriffsszenarien

Die Szenarien sind extrem vielfältig. Da die PowerShell auch auf das gesamte .net-Framework und alle WMI-Repositories zugreifen kann ist hier der Fantasie kaum eine Grenze gesetzt. Einige interessante Beispiele kommen gleich in meinen Szenarien vor.

In meinem Beispiel verwende ich einen Code, mit dem die Internet-Explorer-Passworte aus dem Credential-Manager ausgelesen werden. Das funktioniert für Benutzer mit und ohne administrative Berechtigungen und der Code ist nicht besonders lang:

$ClassLoader   = [Windows.Security.Credentials.PasswordVault,Windows.Security.Credentials,ContentType=WindowsRuntime]
$PasswordVault = new-object Windows.Security.Credentials.PasswordVault
$PasswordVault.RetrieveAll() | 
    ForEach-Object { $_.RetrievePassword() ; $_ } | 
        Select-Object -Property Resource, UserName, Password | 
            Sort-Object Resource | 
                Format-Table -AutoSize

Es ist also ideal für eine Demonstration. Die erforderliche Klasse existiert aber erst seit Windows 8.x. Daher wird das auf Windows 7 nicht funktionieren. Egal, denn ich verwende ein aktuelles Windows 10.

PS-Security – PowerShell Transcription

Szenario – PowerShell Transcription

Angriff ohne Schutz

Besser als die Protokollierung in Eventlogs wäre gleich eine zentrale Sammlung von Protokollen auf einem Laufwerk. Das lässt sich mit Transcripts erzwingen. Ohne ist die Ausgangslage die gleiche wie im Punkt vorher: der Angriff kann nachträglich nicht analysiert werden.

Konfiguration der Schutzkomponente

Transcripts werden ebenfalls in einer GPO definiert. Zusätzlich benötigen wir aber auch ein zentrales Laufwerk. Dieses habe ich auf meinem LAB-Server erstellt:

PS-Security – PowerShell Transcription

Man erkennt (hoffentlich), dass ich den authentifizierten Benutzer nur erlaube, Daten zu schreiben oder anzuhängen. Auf diese Weise verhindere ich, dass ein Angreifer die Transcript-Dateien nachträglich löscht.

In der GPO fehlt nicht mehr viel:

PS-Security – PowerShell Transcription

Angriff eines geschützten Systems

Nachdem die Richtlinie aktiviert wurde, wird die PowerShell jede Ausführung zentral protokollieren. Der User bekommt davon nichts mit:

PS-Security – PowerShell Transcription

Auf dem Server wird je Session eine eigene Datei erstellt. In dieser finden wir neben dem EncodedCommand auch die Klartext-Codes – und auch die Ergebnisse:

PS-Security – PowerShell Transcription

Da so natürlich auch sensible Informationen abgegriffen werden können muss ein Schutz des Verzeichnisses eine hohe Priorität haben. Ggf. könnten die Files nach deren automatischer Analyse gezippt und verschlüsselt werden – oder man löscht sie einfach nach deren Analyse. Bis dahin gibt es bei mir dank NTFS-Permission nichts zu sehen:

PS-Security – PowerShell Transcription

Nebenwirkungen und nützliche Hinweise

Der Schutz ist hier ebenfalls nur die Möglichkeit einer forensischen Analyse. Ggf. findet eine Automatik in den Textdateien Schlüsselworte, die auf einen Angriff hinweisen.

Aus Angreifersicht könnte man nun aber einfach den SMB-Datenstrom vom Client zum Server mitschneiden und so an sensible Informationen herankommen. Die PowerShell wird ja doch eher von Admins verwendet. Und die führen damit natürlich ganz interessante Tätigkeiten aus…

Ebenso nachteilig sind mobile Arbeitsstationen. Die PowerShell versucht natürlich, den Zielserver zum Schreiben des Transcripts zu erreichen, aber wenn das fehlschlägt, wird eben OHNE Protokollierung ausgeführt:

PS-Security – PowerShell Transcription

Ein Angreifer vor Ort könnte also einfach das Netzkabel herausziehen bevor er loslegt… Aber für interne Systeme ist das eine interessante Plattform!

Fazit

Aus meiner Sicht hat Microsoft noch einiges an Arbeit vor sich, um das nützliche Werkzeug PowerShell vernünftig
abzusichern. Erste Ansätze sind erkennbar. Ich bleibe auf jeden Fall dran. Ihr auch?

Stay tuned!

PS: wer mag, kann meine ersten 5 Szenarien zur PS-Absicherung auch hier als PDF herunterladen. Die GPOs sind als Backup und html-Report natürlich auch mit dabei: WSHowto – PowerShell-Security