Expanding Your Empire

empire_logo_black

The “Empire Series”:

[Note: This has been cross posted on the Adaptive Threat Division blog]

This is the first in the “Empire Series”, a set of articles that will cover various aspects of Empire’s functionality and usage. These posts will be split between various Empire authors and contributors with a running set of links updated at the top of each entry. While I’ve posted updates covering the different releases of Empire, we haven’t yet shown a huge amount of Empire’s operational usefulness (though @enigma0x3 did post an “Empire Tips and Tricks” article in August, as well as showing how Empire can be used with SCCM compromises). This post will focus on lateral spread with Empire- others will cover privilege escalation, persistence, data mining, situational awareness, TrollSploit, and more.

Invoke-PsExec

PsExec has served us pentesters well for over a decade. Attackers love to use network administrators’ tools against them and PsExec is no exception. While we’re personally not the biggest fans of PsExec for lateral spread (and other teams have started to outgrow it just as we have) it is still a pentest staple and can be appropriate in specific situations.

Our custom implementation of PsExec (Invoke-PsExec) is based heavily on Metasploit’s approaches. It utilizes a reflection approach from exploit-monday.com in order to access underlying Window32 API functions, and operates as follows:

  1. OpenSCManagerA is used to open up a handle to the service control manager on a victim machine with SC_MANAGER_ALL_ACCESS (0xF003F) permissions.
  2. CreateServiceA is used with the resulting service control manage to create a new service with a specified name, set to launch a specified command.
  3. The service is then opened with OpenServiceA, started with StartServiceA, and execution pauses briefly for the service to start up and execute the given command.
  4. The service is then deleted with DeleteService.

This is obviously quite noisy (in that a service is created which a savvy defender could easily detect) but it has the advantage of giving us SYSTEM level execution on a target. All of this functionality is wrapped up in the lateral_movement/invoke_psexec module, which takes a Listener and ComputerName and handles all the configuration for you:

empire_psexec

Invoke-WMI

Our preference for lateral spread is definitely WMI. While there are a few caveats with using WMI for lateral spread (see the kerberos ‘double hop’ problem), it’s significantly quieter than PsExec. Our implementation, lateral_movement/invoke_wmi, uses Invoke-WmiMethod -Path Win32_process -Name create  to trigger an Empire stager on a remote host to get execution. With the double hop problem, you need to remember that in most cases (unless a host allows unconstrained delegation) this new agent will not be able to access additional remote network resources. You will need to use runas/pth or steal a token in order to refresh the credentials for your currently running agent.

empire_invoke_wmi

Invoke-PsRemoting

If Windows Remoting (WinRM) is enabled on a target, you can easily trigger an Empire agent remotely in the most “PowerShelly” way possible. By executing Invoke-Command on a remote system with the ScriptBlock set to Empire staging code, lateral spread is easy. Like Invoke-PsExec and Invoke-WMI, our implementation at lateral_movement/invoke_psremoting accepts a Listener and ComputerName. It also also accepts and optional UserName and Password (or a CredID specification) to run a stager with separate credentials on the remote host.

empire_psremoting

Invoke-WMIDebugger

One slightly novel lateral spread method we have is the ability to easily use WMI to set the debugger for any of the five Windows Accessibility binaries. These binaries include the notorious sethc.exe (‘Sticky Keys’, activated with shift x 5), Utilman.exe (the ‘Ease of Access’ button, activated with Win+U), Osk.exe (the on-screen keyboard, activated from the Utilman interface), Narrator.exe (text narration, also activated from the Utilman interface), and Magnify.exe (the screen maginifier, also activated from the Utilman interface). What’s great about these binaries is that they can be triggered from an RDP session BEFORE authentication! We use the registry ‘Image File Execution Options’ option instead of overwriting the binaries themselves, as this makes cleanup easier.

With lateral_movement/invoke_wmi_debugger you can set any of these binaries to trigger custom Empire staging code tied to your particular command and control server. If a listener is specified, the staging script is stored into the registry location specified by RegPath and launched by the specified binary. If a listener isn’t specified the program set in the Binary argument will launch instead (like cmd.exe):

empire_wmi_debugger

empire_wmi_debugger2

There’s one caveat- if you trigger an agent using this method, you will need to keep the RDP window alive long enough to inject into another process. As soon as the RDP pre-auth session closes, your original agent will as well. You should have about 30 seconds of non-activity until your current RDP session closes.

When you’re done, specify the Cleanup argument and everything will be set back to normal. Of note: this method of backdooring usability binaries for lateral spread is something that some adversaries have done in the wild.

Passing the Hash

“But what about pass the hash??!” you may be yelling. We couldn’t have a complete toolset without SOME kind of option for hash passing, and again in the case Benjamin Delphy (the @gentilkiwi) comes to our rescue. Using Joseph Bialek‘s Invoke-Mimikatz implementation. we can execute Mimikatz’ sekurlsa::pth module. This allows us to spawn a new process and inject the specified NTLM hash into the process space, performing an ‘over-pass-the-hash‘ attack that effectively turns this credential into a Kerberos ticket. You can pass the hash either with the credentials/mimikatz/pth module or the shortcut from the Agent menu of pth <CredID> (utilizing the Empire credential store):

empire_pth1

There are a few caveats with this approach. First, you need administrative privileges in order to execute it. And second, a new process will be spawned, so Empire’s implementation of Invoke-Mimikatz sets the new process to not spawn a new window. After the process executes, use steal_token (an alias for credentials/tokens, the integration of Joe’s Invoke-TokenManipulation script) in order to steal the token of the newly minted process.

empire_pth2

Wrapup

Lateral spread is an important component of every penetration test and red team engagement. PsExec, WMI, “Debuggers”, WinRM, and PTH all have their place in engagements, and Empire aims to allow operators to choose the best method to fit their given situation.

11 thoughts on “Expanding Your Empire”

  1. Could you please explain what is the “real-world” benefit of using Invoke-WMIDebugger ? I mean, in order to implant Windows Accessibility binary, the attacker must already have privileged access to that same machine. So, what’s it really used for ? Thanks

  2. Pingback: An Empire Case Study | enigma0x3

  3. Pingback: Phishing with Empire | enigma0x3

  4. Pingback: Phishing with Empire - IT大道

  5. Jerry Champion

    I have an issue when I use bypassuac, the victim’s computer is prompted with the sysprep tool. I do not get the elevated access as well.

    Has anyone else seen this before?

  6. Thanks for the great work on this project, really awesome!
    I am evaluating empire for some time now and there is one point I can’t answer after all the lab time: What would be the solution to a blocked powershell.exe? I know about injecting DLLs but that needs other ways of deploying an agent like exploits and so on. Also I know about psinject and its migration capabilities to other processes. But what about a machine that doesn’t allow powershell.exe and that is not exploitable to use the reflective DLL technique? What options for triggering the stager on it do we have then?
    Thanks again for your great work!
    flux

    1. I would check if ALL powershell.exe binaries are blocked (i.e. might have missed the powershell_ise.exe or syswow64 powershell.exe) – these can be combined with malicious profiles as well (http://www.exploit-monday.com/2015/11/investigating-subversive-powershell.html).

      If everything is blocked, you can generate custom C# programs that load the System.Management.Automation.dll (https://www.sixdub.net/?p=367). We have code for this in PowerPick/SharpPick – https://github.com/PowerShellEmpire/PowerTools/tree/master/PowerPick/SharpPick

  7. I left this comment in the github forum as well. Sorry for the double post, but I was not sure where to post it.

    I have created an external C2 server with DigitalOcean to see how vulnerable our company would be to an external attack from Empire.

    Our company is using a Blue Coat Proxy and blocks the agents callback to the listener over HTTP. When I used a signed SSL Cert from letsencrypt.org, the agents is able to call back to C2 server over HTTPS.

    With workstation compromised, I attempt a lateral move with Invoke_WMI. The module executes, but the new agent does not call back to the C2 Server over the same HTTPS listener. I do not get an error message, it just sits there.

    I have executed the same WMI lateral move from the same workstations with success when connected to the same local subnet over HTTP. It seems that the second target does not know how to handle the HTTPS listener.

    I created a pivot listener on the first target and pointed it to the original HTTPS listener, but I get the same results.

    Have I missed something? Any advice would be truly appreciated.

    Also, great work on this project, it has become my main go to application for all my pentest.

Leave a Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.