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.
Szenario – AMSI (Anti Malware Scan Interface)
Angriff ohne Schutz
Hilft ein Virenscanner gegen Schadcode-Dateien? Nun ja, Scripte sind zunächst einmal Textdateien. Weisen diese ein bestimmtes Muster auf, dass der Virenscanner erkennt, dann kann er reagieren. Auf meinem Desktop liegen 2 Dateien, die den gleichen Code beinhalten. Aber eine davon habe ich modifiziert:
Mein Virenscanner ist also in der Lage, den Schadcode im Klartext zu identifizieren. Aber modifiziert ist alles OK:
Klassischerweise hilft ein Virenscanner bei maskiertem Code (obfuscaded code) nicht mehr, da er mehr auf die Datei und deren Aufbau fixiert ist. Seit Windows 10 hat Microsoft eine Schnittstelle für AV-Lösungen bereitgestelt, mit der Schadcode vor der Ausführung im RAM überprüft werden kann – AMSI, oder Anti Malware Scan Interface. Damit KANN ein Virenscanner in den Prozess eingreifen, bevor der Code ausgeführt wird.
Hier sieht man den maskierten Code OHNE AMSI:
Konfiguration der Schutzkomponente
Für AMSI benötigt man Windows 10 und einen kompatiblen Virenscanner.
Angriff eines geschützten Systems
Mit allen Voraussetzungen wird der Code einfach aufgehalten:
Danach hält der Code einfach an:
Nebenwirkungen und nützliche Hinweise
Wie bei jedem Virenscanner ist hier nur eine Wahrscheinlichkeit der Erkennung vorhanden. Wenn ich den Code oben VOR dem Maskieren umbaue, dann erkennt mein Kaspersky auch nichts mehr…
Aber es ist besser als nichts. Und bekannte Schadcodes werden durchaus zuverlässig aufgehalten! 
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
