Owning Networks and Evading Incident Response with PowerShell

Up until several months ago, I was a member of a penetration test team tasked with compromising data centers and evading detection. Industry standard tools such as Metasploit (an attack toolkit that includes a backdoor named Meterpreter) and Mimikatz (a password dumper) worked well, but I was a paranoid attacker and was worried that running these tools (compiled as unsigned EXE files) would get me detected.

I started to take a look at PowerShell after reading a blog post by Matt Graeber on launching Meterpreter using PowerShell. Since antivirus pays no attention to PowerShell scripts, I was able to use Meterpreter without launching a suspicious EXE and without having to worry about disabling antivirus.

I wanted to go a little further though. Instead of just loading Meterpreter, I wanted to be able to load unmanaged DLLs and EXEs (both are actually Windows PE files) without calling LoadLibrary or CreateProcess (because these APIs can be monitored by AppLocker and other similar tools).

The solution to this problem was to write my own PE loader. Instead of relying on Windows APIs (LoadLibrary, CreateProcess) to load PE files in memory, I wrote a PowerShell script Invoke-ReflectivePEInjection that roughly recreates the functionality provided by the Windows API. The benefits of Invoke-ReflectivePEInjection are over the Windows APIs are:

  1. The PE file doesn’t need to be written on disk, it can be supplied as a byte array
  2. No logging or application whitelisting will be done on process creation or DLL loads because Windows sees nothing
  3. Antivirus will not currently detect this

I gave a short talk at DEF CON on the details of this script that can be found here:

I also have several blog posts that dive in the details of the script. I treat Invoke-ReflectivePEInjection like a Swiss Army knife, and have used it to create a few more scripts:

  1. Invoke-Mimikatz: This combines Invoke-ReflectivePEInjection with Mimikatz to provide an easy to use PowerShell script that can dump the credentials for all users logged in to a system.
  2. Invoke-NinjaCopy: This script packages an NTFS file system parser in to a PowerShell script. Sometimes you need access to a file but another process has an exclusive access to the file, preventing you from accessing it. If you are an administrator, you can open a handle to the volume the file is on (ex: C:\ volume) and parse the NTFS file system data structures manually to identify the location of the raw data you need on the volume. You can then directly copy the data off the volume without ever opening a handle to the file in question. Invoke-NinjaCopy allows you to copy files off of remote systems over PowerShell remoting (meaning you write no files to disk on the remote system). This is useful for attackers and defenders (collecting forensic evidence). More information on this script can be found here.
  3. Invoke-CredentialInjection: This is a script that can be used to call the Windows API “LsaLogonUser” from within a process of the attackers choosing. Windows logs which processes are calling the logon APIs and sometimes investigators can detect attacker activity by looking for logons happening from non-standard processes. This script allows an attacker to create a logon originate from any process on the system. For more information about the script and what specifically it is used for, you can read my blog post here.

I have also created scripts unrelated to PE injection.

One such script, Invoke-TokenManipulation, allows an administrator to enumerate the logon tokens for all users logged on to the system. It then allows the administrator to create new processes using any of the tokens impersonated (which effectively makes the process run under the other users account, but on the desktop of the administrator who created the process). This script is similar to the tool Incognito. For more information about Invoke-TokenManipulation, see my blog.

Although I no longer do penetration testing against data centers, I do still maintain these tools. Financially motivated or state sponsored attackers can have large budgets for their toolkits, but penetration testers usually do not. For this reason, it is important for penetration testers to have free, quality tools available to test with to simulate the threat of advanced and well-funded adversaries.

I now work for the Microsoft Security Response Center on the REACT team. I’m responsible for assessing vulnerabilities reported to Microsoft (and 0-days exploited in the wild), finding variants, and doing software penetration tests on high value components. In my new role, I use PowerShell to automate tasks such as configuring servers used for reproducing bugs and automating things such as fuzzing runs.

As a final note, all of the tools mentioned above can be found both on my personal GitHub account, and as part of the PowerSploit toolkit.

Filed in: Articles, Community, Online Only Tags: , , , ,

8 Responses to "Owning Networks and Evading Incident Response with PowerShell"

  1. Dave Wyatt says:

    “Since antivirus pays no attention to PowerShell scripts, I was able to use Meterpreter without launching a suspicious EXE and without having to worry about disabling antivirus.”
    This seems to be the root of the problem. Prior to PowerShell, was there any other way for a malicious program to execute without being potentially spotted and blocked by AV or a whitelister?
    If the answer to that question is “no”, how can we get these security programs to detect, and ideally prevent these types of code execution in PowerShell? Perhaps Microsoft could add a hook to the PowerShell engine which calls out to one or more AV / whitelist apps, giving them a chance to analyze and allow or deny each command before it executes.

    • Joe Bialek says:

      Prior to PowerShell, there were (and still are) many ways to bypass anti-virus. Even if PowerShell added ways for A/V to hook in to it, people would still be able to get around A/V. A/V is good at looking for things it knows about, and it is generally pretty bad at finding things it has never seen before.

      While it would be cool if A/V could instrument PowerShell realtime, it would also probably have a massive performance penalty. The point of my comment in the article was more of a “there’s also this nice benefit”, and not “PowerShell is bad because it allows you to bypass A/V”. As an attacker, A/V will never scare me. PowerShell is just one of many ways to get around it.

      • Dave Wyatt says:

        AV’s probably a bad example. What about whitelisting; is it just as easy to get around something like AppLocker in Allow mode without using PowerShell? If so, what’s the point? “We can block the lazy malicious code, but our network is an open book to anyone who is determined?”

        • Joe Bialek says:

          A good question Dave.

          Application whitelisting can be bypassed in many ways. Examples:

          1. VBScript, or any other whitelisted scripting language which is whitelisted

          2. If you whitelist by file path, an attacker can simply replace the files

          3. Do you also perform whitelisting on DLL’s? If not, RunDLL can be used to load malicious DLL’s

          4. Do you allow debuggers to run?

          The list goes on. Application white listing is a security control that is used to restrict what can be run in an environment. It is not an end-all be-all security boundary that will definitively prevent a determined adversary from running malicious code.

          One additional note. Unlike most scripting languages, PowerShell does have application whitelisting for script files. Interactive input cannot be whitelisted just due to its nature.

Leave a Reply

Submit Comment

© 2017 PowerShell Magazine. All rights reserved. XHTML / CSS Valid.
Proudly designed by Theme Junkie.
%d bloggers like this: