Triaging PowerShell Exploitation with Rekall

David recently published his article Spotting the Adversary so I figured I'd continue the trend and focus on Blue Team tactics in this post.

I've spent a fair bit of time in EnCase. They have a great product and a number of solutions to fit most of your needs, but at times it can feel bulky and a little stiff. Moreover, it has an arguably non-intuitive user interface and is an expensive solution that a lot of organizations cannot afford. Volatility is fantastic but for this post I wanted to focus specifically on Rekall. Incident Response and Forensics require a superb understanding of operating system internals, file system structures, and malware behavior patterns, but tools like Volatility and Rekall greatly reduce the barrier to entry for security analysts and service providers.

Rekall is a complete end to end memory forensics framework (branched from Volatility itself). The developers of this project wanted to focus on improving modularity, usability, and performance. One of the most significant advantages to using Rekall is that at allows for local or remote live forensic analysis. For this reason it is a core component of the Google Rapid Response tool.

In this article I wanted to document a common offensive tactic and then briefly step through some investigatory steps. This is by no means a complete incident response process, and the scenario assumes the attacker has some level of access to the system or network already.

Red Team

I am a big fan of Matt Graeber's PowerSploit. PowerSploit is essentially a set of PowerShell scripts designed to aid penetration testers during all phases of an assessment. You can use it to inject DLLs, reflectively load PE files, insert shellcode, bypass anti-virus, load Mimikatz and do all sorts of other wonderful and nefarious things. PowerShell has become extremely popular as an attack vector in the last two years as it is a native trusted process, lacks comprehensive security mechanisms (excluding perhaps the most recent versions), and is an extremely powerful scripting language (direct API support for Windows internals).

In our scenario we assume that the attacker has a limited shell and wants to gain more significant access. First let's set up our listener:

I've elected to use the Reverse_HTTPS Meterpreter payload as the PowerSploit Invoke-Shellcode script used later on only supports the Reverse_HTTPS and Reverse_HTTP variants (and as such it is preferable to pass this traffic over SSL).

On the compromised machine we will now execute a PowerShell one-liner to retrieve the Invoke-Shellcode PS1 script from the PowerSploit GitHub page. This is a nice method of retrieval as GitHub is not a suspicious or inherently untrustworthy page and the request is submitted over HTTPS (which can help with evasion at the URL filtering/web traffic content inspection layers). Additional levels of evasion can be employed by encrypting our PS1 script but I'm not going to explore that option for the purposes of this demo.

What's happening here? PowerShell is calling IEX (Invoke-Expression) to generate a new WebClient object and calls the DownloadString function to retrieve the URL. The Invoke-Shellcode script is executed with the switches that will instantiate a connection to our MSF listener. This is all executed in the context of the PowerShell process itself.

In Metasploit we see a session is established and migrate processes. In this example I am migrating to Notepad. This is not good trade-craft and I'm only doing this to make things more discernible and easy to grasp forensically in the next section.

At this point we can start looking at things from the other perspective.

Blue Team

First let's drop WinPMem on the system. WinPMem is a kernel mode driver that allows us to gain access to physical memory and map it is a device. 

Once this is done we can use Rekall to perform live memory forensics on the system. Navigate to your Rekall install directory and run the following command to mount the WinPMem device:

rekall.exe -f \\.\pmem

This will launch a Rekall interactive console.  Rekall has support for a lot of native plugins (that you are likely familiar with if you have ever used Volatility). Typing plugins. [tab] [tab] will print a list of options. To get additional information type plugins.[pluginname]? Many plugins also have switches that allow you to filter your query based on a specified criteria. To see the list of available switches type pluginname [tab].

A good starting point is the netscan plugin. 

You should also run pslist when starting your analysis to understand what processes are running. Nothing out of the ordinary but as we continue to browse we see Notepad has a network socket established:

It is clear that this process has been hooked as Notepad should never establish network connections. Let's use the LDRModules plugin to detect unlinked DLLs.

We see a list of unlinked DLLs and some that stand out as extremely suspicious. So we know that Notepad was injected into by a different process (or spawned by malware using a technique known as process hollowing). Obviously for this example we know that Meterpreter migrated to this process.

Meterpreter has a fairly standard migration process:

1. Identify the PID.
2. Scan for architecture of target process.
3. Check if the SeDebugPrivilege is set to get handle to target process.
4. Calculate payload length.
5. Call OpenProcess() to gain access to Virtual Memory of target process.
6. Call VirtualAllocEx() to assign PAGE_EXECUTE_READWRITE.
7. Call WriteProcessMemory() to write the payload into the target process allocated memory region.
8. Call CreateRemoteThread() to execute the payload.
9. Close the prior thread from the old Meterpreter session.

In knowing this we look for additional suspect processes. I like to look for cmd.exe or powershell.exe and dump these processes memory regions for string analysis. When I ran pslist earlier I identified a PowerShell process and ran the memdump pid=[PowerShellPID] plugin. This will produce a DMP file that you can load in your favorite editor.  

I was able to find suspicious strings by searching for keywords such as 'IEX', 'Download', and other commands that might be used by an attacker. At this point I am able to extract the full PowerSploit script from memory and have identified that my attacker downloaded a Meterpreter stager. From an Incident Response perspective we have numerous Indicators of Compromise to work with.

Lastly, ProcExplorer from Mark Russinovich is a great tool for at a glance identification of suspect activity. Let's look at spawned threads and stack information from a normal Notepad process relative to a hooked one:

This is by no means a complex attack and there is much more we can do from a memory analysis perspective, but I think the material covered serves as a gentle introduction to the topic. I'll likely follow up on this post in the future and go into more depth but hopefully this information is enough to get you started.

There are a number of fantastic writers covering these types of topics in the blogosphere and I wanted to link to them here as they are all doing amazing work. I came across some great posts while doing research:
http://holisticinfosec.blogspot.ca/2015/05/toolsmith-attack-detection-hunting-in.html
http://www.tekdefense.com/news/2013/12/23/analyzing-darkcomet-in-memory.html
http://www.behindthefirewalls.com/2013/07/zeus-trojan-memory-forensics-with.html
https://github.com/volatilityfoundation
http://www.rekall-forensic.com/
https://github.com/google/grr
https://github.com/google/rekall/releases/tag/v1.3.2