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.
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.
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.
No comments:
Post a Comment