Keine Shell? Kein Problem!
Host Enumeration ganz ohne CMD und PowerShell

In gehärteten Windows-Umgebungen mit strikten Sicherheitsrichtlinien sind klassische Angriffsmethoden und selbst legitime Tools oftmals blockiert. Doch auch wenn Powershell, Kommandozeile & Co. nicht mehr ausführbar sind, bietet ein kreativer Ansatz mit Visual Basic for Applications (VBA) und Windows-APIs alternative Wege.

Ausgangssituation

Im Rahmen eines Penetrationstests sollte die Sicherheit einer Microsoft Azure Virtual Desktop-Umgebung überprüft werden. Der Kunde nutzt diese Plattform, um externen Service-Partnern einen eingeschränkten Zugriff auf verschiedene Anwendungen zu ermöglichen – darunter auch einen Browser und Office-Produkte wie Excel, Word und Outlook.

Der Ausbruch aus den einzelnen Anwendungen war in wenigen Minuten erledigt und soll hier auch nicht weiter thematisiert werden – darüber gibt es schon mehr als genug Artikel im Netz.
Wirklich interessant wurde es, als es darum ging, eine Shell (Kommandozeile, PowerShell oder WMIC) zu starten, um sich anschließend einen umfassenden Überblick über die Umgebung zu verschaffen (Situational Awareness) und gezielt nach Schwachstellen für eine Rechteausweitung (Privilege Escalation) zu suchen.
Hierbei wurde schnell klar: Es handelt sich um ein ziemlich gut gehärtetes Windows 11 Enterprise-System, das offensichtlich überwiegend (später dazu mehr) nach dem CIS Level 1 Security Benchmark[1] konfiguriert worden war – inklusive Best-Practice-AppLocker-Regeln (vermutlich nach NSA AppLocker-Guidance) und aktiviertem PowerShell Constrained Language Mode[2].

Konkret bedeutet das:

• Ausführung von unbekannten/unsignierten Programmen wird blockiert.

• LOLBAS[3] und bekannte Systemtools wie cmd.exe, powershell.exe, regedit.exe, wmic.exe etc. sind gesperrt.

• PowerShell läuft nur im Constrained Language Mode:

• Nur grundlegende Built-in-Cmdlets erlaubt

• Kein Laden/Verwenden von externen Skripts, Modulen, Libraries

• Keine COM- oder Win32-API-Aufrufe

• Keine dynamische Codeausführung

• Strikte GPOs:

• Einschränkung weiterer Systemfunktionen und Rechte

• Erzwingen sicherer Konfigurationen und Einstellungen

• Portable Programme können nicht ausgeführt werden.

• SmartScreen aktiv:

• Ausführung von „unbekannter“ Software wird unterbunden

• Netzwerkzugriffe ggf. limitiert

• Erhöhte Protokollierung und Überwachung

Zusammengenommen erschwerten diese Maßnahmen klassische Angriffs- sowie Analysemethoden deutlich und minimierten die Angriffsfläche spürbar.

Versuche der Umgehung

Die Nutzung von Visual Basic bzw. Makros als Angriffsvektor ist längst etabliert und kommt seit vielen Jahren - insbesondere bei Phishing-Kampagnen, aber auch bei Malware zum Einsatz - um initialen Zugriff auf Endgeräte der Opfer und damit auf das interne Unternehmensnetzwerk zu erhalten. Typischerweise werden dafür präparierte Office-Dokumente verwendet, die Markos ausführen.

Die meisten im Internet verfügbaren Beispiele beschränken sich letztendlich jedoch darauf, eine Shell oder die Rechner-App (calc.exe) zu starten, Executables nachzuladen und auszuführen oder laufende Prozesse auszulesen. Spezielle Tools wie macro_pack, BadAssMacros oder OffensiveVBA unterstützen dabei, bösartige Makros zu generieren und Sicherheitslösungen zu umgehen.

Zudem zeigte bereits 2016 Didier Stevens in seinem Blogbeitrag Create Your Own CMD.XLS, wie sich mit einem Excel-Makro eine Kommandozeile starten lässt und auch das Skript VBA-RunPE verfolgt einen ähnlichen Ansatz und ermöglicht es, über Word oder Excel eine Shell zu öffnen.
Beide Ansätze haben allerdings Einschränkungen: Stevens’ CMD.XLS funktioniert ausschließlich mit 32-Bit-Anwendungen und ist daher nicht mehr zeitgemäß. VBA-RunPE ist zwar flexibler und unterstützt sowohl 32-Bit- als auch 64-Bit-Anwendungen, allerdings nutzt es zur Erzeugung der Shell eine Technik (Einfügen von Shellcode in eine neue Instanz eines legitimen Prozesses), die auch von Malware eingesetzt wird. Deshalb stufen viele Sicherheitssysteme das Verhalten von VBA-RunPE als schädlich ein und blockieren dessen Ausführung.
Doch selbst wenn dies nicht der Fall wäre, würde mir diese Methode in meinem Fall kaum weiterhelfen, da mich der Constrained Language Mode, die restriktiven AppLocker-Regeln und Gruppenrichtlinien stark einschränken und selbst viele legitime Systemtools nicht ausgeführt werden dürfen.

Da die genannten Ansätze unter diesen Bedingungen nicht zielführend sind, motivierte mich dies, einen eigenen Bypass zu entwickeln – unabhängig von CMD oder PowerShell und selbst bei restriktiver AppLocker-Policy anwendbar.

Was kann VBA eigentlich noch?

Angesichts der zahlreichen Möglichkeiten, die VBA bietet, stellte ich mir die Frage:
„Was kann ich mit VBA eigentlich noch alles machen?“

Trustedsec zeigte 2020 in einem mehrteiligen Blogbeitrag (Malicious Macros for Script Kiddies), dass VBA viel mehr kann, als nur Payloads nachzuladen oder eine Shell zu starten:

VBA is a powerful scripting language that exposes numerous APIs, objects, and events allowing the programmer to interact with the system from the somewhat privileged context of a trusted application. We can make use of VBA code, COM objects, OLE automation, and Win32 APIs to explore the host, access the filesystem, and run commands.

VBA bietet also weit mehr Möglichkeiten, als ich zuerst vermutet hätte.
Möglicherweise lassen sich mittels Zugriff auf Windows-APIs, Registry und Dateisystem detaillierte Systeminformationen sammeln und potenzielle Schwachstellen zur Rechteausweitung identifizieren?

Eine weitere Tatsache ist, dass die zugrundeliegende Funktionalität von WMI weiterhin nutzbar bleibt, selbst wenn der Zugriff auf wmic.exe, cscript.exe und wscript.exe blockiert ist.
Mithilfe der WMI Scripting API kann über den sogenannten „winmgmts:“-Moniker[4] ein Namespace, eine Klasse oder eine Instanz adressiert werden. Der Windows Script Host nutzt anschließend die WMI-Schnittstelle, um eine Verbindung herzustellen, und liefert als Ergebnis ein SWbemServices-Objekt zurück. Über dieses Objekt kann dann mit WMI-Objekten weitergearbeitet werden.

Das folgende Codebeispiel zeigt, wie sich mit Hilfe des genannten Monikers die auf dem System installierten Hotfixes ermitteln und in der Debug-Konsole ausgeben lassen:

Sub ListHotfixes()
    Dim objWMIService As Object
    Dim colHotFixes As Object
    Dim objHotFix As Object

     ' Connect to WMI
    Set objWMIService = GetObject("winmgmts:\\.\root\cimv2")
    ' Query installed Hotfixes
    Set colHotFixes = objWMIService.ExecQuery("Select * from Win32_QuickFixEngineering")

    For Each objHotFix In colHotFixes
        ' Print the HotFix ID to the Debug Console
        Debug.Print objHotFix.HotFixID
    Next
End Sub

Die Summe dieser Überlegungen und Experimente führte schließlich zur Entwicklung von MacroMania.

MacroMania

MacroMania ist im Wesentlichen der Versuch, klassische Prüfungen zur Situational Awareness und Privilege Escalation möglichst ausschließlich mit VBA durchzuführen – ohne CMD, PowerShell, LOLBAS oder das Nachladen von Code.
Stattdessen werden Systemabfragen und Auswertungen ausschließlich über die Windows-API sowie den WMI-Moniker umgesetzt.
Dadurch eignet sich MacroMania besonders für gehärtete Umgebungen, in denen klassische Tools und Shells geblockt sind oder nicht eingesetzt werden können.