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.
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.
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 – PowerShell Script Block Logging
Es ist nicht praktikabel, alle Aufrufe der PowerShell zu verbieten, denn für administrative Zwecke ist sie ein unverzichtbares Werkzeug geworden. Sollte es aber einmal zu einem Angriff gekommen sein, dann sollte zumindest die forensische Analyse gewährleistet sein. Dafür ist eine Script-Protokollierung erforderlich. Durch Script Block Logging wird dies über eine GPO sehr einfach erreicht. Ohne ist der ausgeführte Code nach dem Beenden des Powershell-Prozesses nicht mehr verfügbar. Und das Eventlog bietet keine gespeicherten Infos:
Auch hier ist die Konfiguration über eine GPO möglich:
Durch eine reine Protokollierung wird natürlich kein Angriff verhindert:
Aber er kann nachvollzogen werden. Im Eventlog findet man nun eben auch den Code im Klartext:
Mit einem Monitoring auf übliche Schlüsselworte könnte im Hintergrund ein Alarm ausgelöst werden…
Nachteilig ist hierbei aber die lokale Protokollierung. Bei vielen Clients ist eine zentrale Auswertung nahezu unmöglich. Und natürlich kann ein Angreifer mit ausreichenden Rechten die Eventlogs nach seiner Aktion auch löschen… ☹
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