PowerShell basierende Angriffe stellen seit jeher einen Alptraum für die IT-Sicherheit-Abteilung dar, da deren Ausführung kaum Spuren hinterlassen und diese auf einen beeindruckenden Umfang von Systemfunktionen zurückgreifen können. Es ist an der Zeit, dass die IT-Sicherheits-Abteilung ein Werkzeug erhält, um der Bedrohung Herr zu werden oder gar einen Schritt voraus zu sein.

Ausgangslage

Im Artikel PowerShell ♥ the Blue Team des Windows PowerShell Blogs stellt Microsoft neue Sicherheitsfunktionen der PowerShell Version 5.0 vor. Mit der Funktion Constrained PowerShell wird die Kontrolle mittels AppLocker verbessert. Wird AppLocker mit den Standardregeln im Allow Modus verwendet, erkennt dies PowerShell und setzt den Sprachmodus auf Constrained. Damit wird der Funktionsumfang reduziert und es sind nur noch Basis-Funktionen erlaubt. Als Resultat davon werden erweiterte Funktionen, wie unter anderem .NET Scripting oder die Interaktion mit COM-Objekten, nicht mehr ausgeführt. Diese Einschränkung dient als Schutz gegen Angriffstools, die diese Funktionen einsetzen und nun nicht mehr korrekt ausgeführt werden. Skripte, die hingegen explizit durch eine AppLocker Policy erlaubt werden, da diese signiert sind oder sich in einem vertrauenswürdigen Verzeichnis befinden, werden weiterhin im Full Mode betrieben. Diese Funktion vereinfacht das Blockieren von PowerShell enorm.

Dennoch ist das Blocken von PowerShell nur schwer realisierbar und kann vermutlich nur in spezifischen Umgebungen wie auf einem Terminal-Server konsequent umgesetzt werden. Auf allen anderen Systemen wird die Ausführung von PowerShell weiterhin möglich sein oder muss bewusst zugelassen werden. Als Konsequenz dessen sollte getreu nach dem Motto In God we trust, all others we monitor eine Monitoring-Lösung zur Protokollierung und Auswertung von PowerShell-Aktivitäten implementiert werden.

PowerShell-Aktivität aufzeichnen

Mit der Version 3.0 des Windows Management Framework führte Microsoft die Gruppenrichtlinie-Einstellung Turn On Module Logging ein. Diese befindet sich unter Computer Configuration\Administrative Templates\Windows Components\Windows PowerShell. Wird sie aktiviert, werden PowerShell-Kommandos und -Module im Eventlog Microsoft-Windows-PowerShell/Operational protokolliert. Damit kann die Ausführung von PowerShell auf einem System analysiert und überwacht werden.

In der Gruppenrichtlinie muss definiert werden, welche Module überhaupt protokolliert werden. Wenn nun sämtliche Module durch das Setzen der Wildcard-Einstellung * aufgezeichnet werden, dann führt dies zu einer grossen Menge an Einträgen. Das folgende Beispiel demonstriert dies eindrücklich. Die einmalige Ausführung des Scripts Invoke-Mimikatz, eine PowerShell-Adaption von Joe Bialek des Tools Mimikatz von Benjamin Delpy zur Extraktion von Windows Credentials, führt zu zirka 29’000 Einträgen im Eventlog, das dabei die Grösse von 56 MB erreicht. Eine Suche nach der Zeichenkette Mimikatz führt dann auch gleich zu 22’691 Treffern:

PS C:\> Get-WinEvent -LogName "Microsoft-Windows-PowerShell/Operational" | Where { $_.Message -like "*Mimikatz*" } | Group-Object Eventid | Format-Table Count,Name

Count Name
----- ----
22691 800

Demzufolge gilt es einen Kompromiss zwischen der Datenmenge und den aufzuzeichnenden Modulen zu finden. Um sämtliche Angriffe erkennen zu können, ist der Einsatz der Wildcard-Einstellung notwendig, da ein Angreifer eigene, benutzerdefinierte Module verwenden könnte, die sich dann nicht in der Filterliste befinden. Bei der Implementation der Monitoring-Lösung sollte die Datenmenge zumindest berücksichtigt werden. Eventuell lohnt es sich eine erste Filterung der Resultate bereits auf dem Client vorzunehmen und nicht alle Einträge vom Client an die Monitoring-Lösung zu senden, um so die anfallende Datenmenge zu reduzieren.

Mit dem Windows Management Framework 5.0 wird eine zusätzliche Logging-Funktion namens PowerShell Script Block Logging eingeführt. Ein Script Block legt die Basis für ausführbaren Code und tritt in interaktiven Konsolen-Befehlen, in Kommandoaufrufen mittels des Parameters -Command $command sowie in Funktionen oder Skripten auf. Die Aktivierung der Einstellung führt dazu, dass alle durch PowerShell prozessierten Script Blocks aufgezeichnet werden. Der Vorteil dieser Einstellung gegenüber dem Module Logging ist, dass wenn in einem Script Block dynamischer Code benutzt wird, wird nebst diesem Code auch die generierte und tatsächlich ausgeführte Variante ebenfalls protokolliert. Dies ermöglicht es Code von Anwendungen zu protokollieren, die bewusst dynamische Code-Generierung zur Verschleierung einsetzen, unter anderem der Einsatz von Kodierungs- oder Verschlüsselungsmethoden. Dies ist ein verbreitetes Mittel zur Umgehung von Sicherheitslösungen, da der Schadcode erst zur Laufzeit erkennbar ist und nicht vorgängig durch den Scan einer Antivirus-Lösung.

Eine beliebte Technik ist der Einsatz von Base64-kodierten Payloads. Ein Base64-Payload kann direkt mittels des Parameters -EncodedCommand $commandBase64 ausgeführt werden, wie das folgende Beispiel zeigt. Hier wird ein kodierter Befehl über die Konsole ausgeführt. Was der Befehl macht, ist anhand des Aufrufs nicht ersichtlich.

PS C:\> powershell.exe -Enc "VwByAGkAdABlAC0ATwB1AHQAcAB1AHQAIAAnAFIAdQBuAG4AaQBuAGcAIABXAGkAbgBkAG8AdwBzAF8ATABvAGMAYQBsAF8ARQB4AHAAbABvAGkAdAAuAC4ALgAnAA=="

Im Eventlog wird nun erstens der eigentliche Aufruf protokolliert. Zusätzlich wird in einem weiteren Logeintrag die kodierte Form des Befehls aufgezeichnet. Dadurch kann nachvollzogen werden, was tatsächlich ausgeführt wurde. Eine einfache Analyse ist natürlich mit PowerShell möglich, wie das folgende Code-Beispiel zeigt. Mittels des Befehls Get-WinEvent werden die letzten zwanzig Einträge ausgelesen und als Array in das Objekt $eventLog gespeichert. Der Eintrag $eventLog[10] beinhaltet den Logeintrag des Script Blocks in der Form, wie dieser in der Konsole ausgeführt wurde, mit der Base64-Payload. Im Eintrag $eventLog[6] ist dann die dekodierte und tatsächlich ausgeführte Form protokolliert.

PS C:\> $eventLog = Get-WinEvent -LogName "Microsoft-Windows-PowerShell/Operational" -MaxEvents 20

PS C:\> $eventLog[10].Message
Creating Scriptblock text (1 of 1):
powershell.exe -Enc "VwByAGkAdABlAC0ATwB1AHQAcAB1AHQAIAAnAFIAdQBuAG4AaQBuAGcAIABXAGkAbgBkAG8AdwBzAF8ATABvAGMAYQBsAF8ARQB4AHAAbABvAGkAdAAuAC4ALgAnAA=="

ScriptBlock ID: 6310fcc4-c2e5-4790-98d7-69ca0133abce
Path:

PS C:\> $eventLog[6].Message
Creating Scriptblock text (1 of 1):
Write-Output 'Running Windows_Local_Exploit...'

ScriptBlock ID: 152104d8-dc65-41a7-8c2e-67a87828a9a4
Path:

Zurück zum Beispiel des Skripts Invoke-Mimikatz: mit der Einstellung Turn On PowerShell Script Block Logging werden nur noch 413 Einträge in das Eventlog geschrieben. Dies ist im Gegensatz zu zirka 29’000 Einträgen eine überschaubare Datenmenge und kann direkt für weitere Auswertungen genutzt werden.

Sammeln von Eventlogs

Das Aufzeichnen der PowerShell-Aktivitäten ist nur der erste Schritt für eine Monitoring-Lösung. Es muss sichergestellt sein, dass die Logeinträge nicht verändert oder gelöscht werden können. Die National Security Agency (NSA) und der Central Security Service (CSS) haben im Dezember 2013 ein Whitepaper namens Spotting the Adversary with Windows Event Log Monitoring veröffentlicht. Das Dokument beschreibt, wie mit Eventlogs umgegangen werden soll und welche Schutzmassnahmen notwendig sind. Ein wichtiger Punkt ist, dass die maximale Grösse eines Eventlogs angepasst und verhindert wird, dass Einträge beim Erreichen dieser Maximalgrösse überschrieben werden. Ferner muss die Integrität der Logs sichergestellt sein. Dazu gehört, dass Administratoren keine Schreibrechte auf die Log-Dateien haben. Es wird empfohlen, dass ein dedizierter Server zur Sammlung von Eventlogs eingesetzt wird. Im Whitepaper wird dazu die Konfiguration von Event-Subscriptions und der Event-Forwarding-Policy beschrieben. Dies kann natürlich auch mit anderen Mitteln oder Produkten von Drittanbietern realisiert werden.

PowerShell-Aktivität auswerten

Das Aufzeichnen aller PowerShell-Aktivitäten auf einem System oder mehreren Systemen führt zu einer grossen Menge an Daten. Diese Daten müssen entsprechend ausgewertet werden, um bösartige Vorgänge zu erkennen. Ein simpler Signatur-basierter Ansatz, wie das Durchsuchen nach Stichworten wie Mimikatz, Invoke-Mimikatz oder Invoke-Shellcode, greift dabei zu kurz und kann mit einfachen Mitteln umgangen werden.

Der zielführende Ansatz ist die Suche nach bestimmten Schlüsselwörtern von PowerShell-Objekten, -Methoden oder -Commandlets, die für die Zwecke von Angriffs-Tools benötigt werden. Sean Metcalf, CTO von DAn Solutions und Security Researcher, hat in seinem Vortrag namens Red vs. Blue: Modern Active Directory Attacks & Defense an der DerbyCon 2015 eine Liste von solchen Schlüsselwörtern zusammengestellt. Eine solche Liste von Schlüsselwörtern sollte regelmässig überprüft und aktualisiert werden.

• Allgemeine Schlüsselwörter
  • (New-Object Net.WebClient).DownloadString
  • Invoke-WebRequest
  • Invoke-Expression / IEX
  • EncodedCommand / -enc
  • Bypass
• Invoke-Mimikatz
  • System.Reflection.AssemblyName
  • System.Reflection.Emit.AssemblyBuilderAccess
  • System.Runtime.InteropServices.MarshalAsAttribute
  • TOKEN_PRIVILEGES
  • SE_PRIVILEGE_ENABLED
• Invoke-TokenManipulation
  • TOKEN_IMPERSONATE
  • TOKEN_DUPLICATE
  • TOKEN_ADJUST_PRIVILEGES
• Invoke-CredentialInjection
  • TOKEN_PRIVILEGES
  • GetDelegateForFunctionPointer
• Invoke-DLLInjection
  • System.Reflection.AssemblyName
  • System.Reflection.Emit.AssemblyBuilderAccess
• Invoke-Shellcode
  • System.Reflection.AssemblyName
  • System.Reflection.Emit.AssemblyBuilderAccess
  • System.MulticastDelegate
  • System.Reflection.CallingConventions
• Get-GPPPassword
  • System.Security.Cryptography.AesCryptoServiceProvider
  • 0×4e,0×99,0×06,0xe8,0xfc,0xb6,0×6c,0xc9,0xfa,0xf4
  • Groups.User.Properties.cpassword
  • ScheduledTasks.Task.Properties.cpassword
• Out-MiniDump
  • System.Management.Automation.WindowsErrorReporting
  • MiniDumpWriteDump

Mit diesen Schlüsselwörtern wird eine erste Filterung der Datenmenge vorgenommen. Auch in diesem Fall kann auf PowerShell-Funktionen zurückgegriffen werden. Das Feld Message wird nach Treffern durchsucht und alle betroffenen Einträge werden aufgelistet.

PS C:\> $keywordsMimikatz = "System.Reflection.AssemblyName|System.Reflection.Emit.AssemblyBuilderAccess|System.Runtime.InteropServices.MarshalAsAttribute|TOKEN_PRIVILEGES|SE_PRIVILEGE_ENABLED"

PS C:\> Get-WinEvent -ErrorAction SilentlyContinue -FilterHashtable @{ProviderName="Microsoft-Windows-PowerShell"} | Where { $_.Message -imatch $keywordsMimikatz } | Format-Table -AutoSize TimeCreated,Id,RecordId,MachineName,Message

TimeCreated           Id RecordId MachineName           Message
-----------           -- -------- -----------           -------
10.03.2016 14:39:45 4104   360280 client02.labs.scip.ch Creating Scriptblock text (1 of 1):...
09.03.2016 11:26:45 4104   360249 client02.labs.scip.ch Creating Scriptblock text (1 of 1):...
09.03.2016 11:26:45 4104   360248 client02.labs.scip.ch Creating Scriptblock text (1 of 1):...
09.03.2016 11:19:28 4104   360246 client02.labs.scip.ch Creating Scriptblock text (1 of 1):...
09.03.2016 11:19:28 4104   360245 client02.labs.scip.ch Creating Scriptblock text (1 of 1):...
09.03.2016 11:18:54 4104   360243 client02.labs.scip.ch Creating Scriptblock text (1 of 1):...
09.03.2016 11:18:54 4104   360242 client02.labs.scip.ch Creating Scriptblock text (1 of 1):...
09.03.2016 11:18:20 4104   360240 client02.labs.scip.ch Creating Scriptblock text (1 of 1):...
09.03.2016 11:18:20 4104   360239 client02.labs.scip.ch Creating Scriptblock text (1 of 1):...
09.03.2016 11:16:55 4104   360233 client02.labs.scip.ch Creating Scriptblock text (1 of 1):...
09.03.2016 11:16:55 4104   360232 client02.labs.scip.ch Creating Scriptblock text (1 of 1):...

Die Verwendung dieser Schlüsselworte sind nur ein erster Anhaltspunkt dafür, dass ein möglicher Angriff stattfindet. Da diese Schlüsselwörter aber auch von legitimen PowerShell-Anwendungen verwendet werden können, ist eine weitere, gegebenenfalls manuelle, Auswertung der Resultate notwendig. Dabei sollte die komplette Ausgabe des Script Blocks überprüft werden, da dieser die vollständige Anweisung enthält. Zudem existieren zu jedem Eventlog-Eintrag weitere Informationen wie der Zeitstempel, der Computer- und Benutzername, die zur Nachforschung genutzt werden können.

Anstelle einer Ausgabe aller gefunden Resultate können diese auch als Array in ein Objekt geladen werden, und über die Shell kann dann auf die einzelnen Einträge zugegriffen werden:

PS C:\> $logs = Get-WinEvent -ErrorAction SilentlyContinue -FilterHashtable @{ProviderName="Microsoft-Windows-PowerShell"} | Where { $_.Message -imatch $keywordsMimikatz }

PS C:\> $logs[123].Message
Creating Scriptblock text (1 of 131):
function Invoke-Mimikatz
{
<#
.SYNOPSIS

This script leverages Mimikatz 2.0 and Invoke-ReflectivePEInjection to reflectively load Mimikatz completely in memory. This allows you to do things such as dump credentials without ever writing
the mimikatz binary to disk. The script has a ComputerName parameter which allows it to be executed against multiple computers...
<redacted by scip AG>

In dem Logeintrag befindet sich im Script Block die Definition der Funktion Invoke-Mimikatz. Es kann dementsprechend davon ausgegangen werden, dass es sich bei den aufgezeichneten Ereignissen um einen Angriff handelte.

Zusammenfassung

Wie jede anderen Monitoring-Lösung ist es auch bei der Analyse von PowerShell-Aktivitäten so, dass die Konfiguration und Zusammenstellung von Filtern regelmässig überprüft und optimiert werden muss, damit diese effektiv arbeiten und sinnvoll eingesetzt werden können. Es reicht nicht aus, das Sammeln von Eventlogs zu implementieren und eine einmalig zusammengetragene Liste von Merkmalen oder Signaturen zur Auswertung einzusetzen. Eine solche Liste sollte neuen Entwicklungen entsprechend erweitert werden.

In der Initialisierungsphase des Monitoring sollte ein Grundverständnis für die PowerShell-Aktivitäten innerhalb der eigenen Infrastruktur entwickelt werden. Daraus kann abgeleitet werden, welche Tools und Skripte regelmässig ausgeführt werden und für den Betrieb notwendig sind. Mit diesem Wissen kann die Monitoring-Lösung fein eingestellt werden, um sowohl False-Positive-Alarme zu verhindern als auch die Erkennung von Anomalien in der Infrastruktur zu verbessern.

Wenn eine solche Anomalie erkennt und ein Alarm ausgelöst wird, muss dieser sorgfältig untersucht werden. Dabei können die Aufzeichnungen aller Aktivitäten eines Script Blocks genutzt werden. Diese Analyse sollte es möglich machen, eine Bedrohung für die Infrastruktur zu erkennen. Eine IT-Sicherheit-Abteilung, die eine solche PowerShell-Monitoring Lösung aufbaut und betreibt, wird zukünftig wieder ruhiger schlafen können.

Über den Autor

Michael Schneider arbeitet seit dem Jahr 2000 in der IT. Im Jahr 2010 hat er sich auf die Informationssicherheit spezialisiert. Zu seinen Aufgaben gehören das Penetration Testing, Hardening und das Aufspüren von Schwachstellen in Betriebssystemen. Er ist bekannt für eine Vielzahl in PowerShell geschriebener Tools zum Finden, Ausnutzen und Beheben von Schwachstellen. (ORCID 0000-0003-0772-9761)

Links

• http://blog.gentilkiwi.com
• http://www.nsa.gov/ia/_files/app/Spotting_the_Adversary_with_Windows_Event_Log_Monitoring.pdf
• https://adsecurity.org/?p=1632
• https://blogs.msdn.microsoft.com/powershell/2015/06/09/powershell-the-blue-team/
• https://raw.githubusercontent.com/PowerShellMafia/PowerSploit/master/Exfiltration/Invoke-Mimikatz.ps1
• https://twitter.com/JosephBialek
• https://twitter.com/Pyrotek3
• https://twitter.com/gentilkiwi
• https://www.microsoft.com/en-us/download/details.aspx?id=34595
• https://www.microsoft.com/en-us/download/details.aspx?id=50395