No shell? Host enumeration without CMD and PowerShell

In hardened Windows environments with strict security guidelines, classic attack methods and even legitimate tools are often blocked. But even if Powershell, command line & Co. are no longer executable, a creative approach with Visual Basic for Applications (VBA) and Windows APIs offers alternative ways.

Initial situation

As part of a penetration test, the security of a Microsoft Azure Virtual Desktop environment was to be checked. The customer uses this platform to provide external service partners with restricted access to various applications - including a browser and Office products such as Excel, Word and Outlook.

Breaking out of the individual applications was done in a few minutes and will not be discussed further here - there are already more than enough articles about this on the web.
Things got really interesting when it came to starting a shell (command line, PowerShell or WMIC) in order to then gain a comprehensive overview of the environment (situational awareness) and specifically search for vulnerabilities for privilege escalation.
It quickly became clear that this was a fairly well-hardened Windows 11 Enterprise system, which had obviously been configured predominantly (more on this later) according to the CIS Level 1 Security Benchmark[1] - including best practice AppLocker rules (presumably according to NSA AppLocker guidance) and activated PowerShell Constrained Language Mode[2].

In concrete terms, this means:

• Execution of unknown/unsigned programs is blocked.
• LOLBAS[3] and known system tools such as cmd.exe, powershell.exe, regedit.exe, wmic.exe etc. are blocked.
• PowerShell only runs in Constrained Language Mode:
  • Only basic built-in cmdlets allowed
  • No loading/use of external scripts, modules, libraries
  • No COM or Win32 API calls
  • No dynamic code execution
• Strict GPOs:
  • Restriction of further system functions and rights
  • Enforce secure configurations and settings
• Portable programs cannot be executed.
• SmartScreen active:
  • Execution of "unknown" software is prevented
• Network access may be limited
• Increased logging and monitoring

Taken together, these measures made traditional attack and analysis methods significantly more difficult and noticeably minimized the attack surface.

Attempts to circumvent

The use of Visual Basic or macros as an attack vector has long been established and has been used for many years - especially in phishing campaigns, but also in malware - to gain initial access to victims' end devices and thus to the internal company network. Typically, prepared Office documents that execute Markos are used for this purpose.

However, most of the examples available on the Internet are ultimately limited to starting a shell or the calculator app (calc.exe), reloading and executing executables or reading out running processes. Special tools such as macro_pack, BadAssMacros or OffensiveVBA help to generate malicious macros and bypass security solutions.

In 2016, Didier Stevens also showed how to start a command line with an Excel macro in his blog post Create Your Own CMD.XLS, and the VBA-RunPE script follows a similar approach and makes it possible to open a shell via Word or Excel.
However, both approaches have limitations: Stevens' CMD.XLS only works with 32-bit applications and is therefore no longer up to date. Although VBA-RunPE is more flexible and supports both 32-bit and 64-bit applications, it uses a technique to create the shell (inserting shellcode into a new instance of a legitimate process) that is also used by malware. This is why many security systems classify the behavior of VBA-RunPE as malicious and block its execution.
But even if this were not the case, this method would hardly help me in my case, as the Constrained Language Mode, the restrictive AppLocker rules and group policies severely limit me and even many legitimate system tools are not allowed to be executed.

Since the approaches mentioned are not effective under these conditions, this motivated me to develop my own bypass - independent of CMD or PowerShell and applicable even with a restrictive AppLocker policy.

What else can VBA actually do?

In view of the numerous possibilities that VBA offers, I asked myself the question:
"What else can I actually do with VBA?"

In 2020, Trustedsec showed in a multi-part blog post(Malicious Macros for Script Kiddies) that VBA can do much more than just reload payloads or start a shell:

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.

So VBA offers far more possibilities than I would have first suspected.
Perhaps access to Windows APIs, the registry and file system can be used to collect detailed system information and identify potential vulnerabilities for privilege escalation?

Another fact is that the underlying functionality of WMI remains usable even if access to wmic.exe, cscript.exe and wscript.exe is blocked.
The WMI Scripting API can be used to address a namespace, a class or an instance via the so-called "winmgmts:" moniker[4]. The Windows Script Host then uses the WMI interface to establish a connection and returns an SWbemServices object as a result. This object can then be used to continue working with WMI objects.

The following code example shows how the hotfixes installed on the system can be determined and displayed in the debug console with the help of the moniker mentioned:

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

MacroMania

MacroMania is essentially an attempt to perform classic checks for situational awareness and privilege escalation as exclusively as possible with VBA - without CMD, PowerShell, LOLBAS or reloading code.
Instead, system queries and evaluations are implemented exclusively via the Windows API and the WMI moniker.
This makes MacroMania particularly suitable for hardened environments in which classic tools and shells are blocked or cannot be used.