When we usually hear the term ‘memory injection’, it tends to refer to compromising a process on an unsuspecting target, either to run covert code, in relation to token theft or performing a similar activity. As an attacker, there are very few circumstances in which using this technique on your own tools, on your own laptop, might be useful on a live penetration test or red-teaming engagement.
One example of where this might be useful is against Sysinternals’ AD Explorer; anyone who has used it will know that it is very useful, especially for rapid offline analysis of an AD structure which, for example, has been acquired during a penetration test in order to gain situational awareness. Once you have credentials, you can take a ‘snapshot’ of a remote Active Directory structure and perform offline queries and searches. This is particularly useful on red-teaming engagements; the need for an understanding of the AD structure is paramount in such circumstances, and the ability to gain an understanding without repeatedly sending queries to the DC is a useful one.
One of the unfortunate limitations of AD Explorer is that you cannot copy/paste or select the results from the Search Container, which makes it awkward to use in anger. For example, you could perform a complex search that gives you a list of users that you wish to target, but there is no easy or built in way of exporting that list to a text file that you can include in scripts or import into your remote access tool.
In order to overcome this, I wrote a tool that pulls the results out of this tool. In order to do this, it needed to allocate and manipulate memory inside AD Explorer’s process, because one process cannot routinely access another process’ memory. The tool itself sits in your system tray and, when you double-click its tray icon, it will copy whatever is in the first column of the Search Container, write it to a log file and copy it to clipboard for you.
This project started out as a quick and dirty solution to offer the ability to electronically export results in a tool that is otherwise really useful but lacking in that regard. However, it turned into an interesting project, especially as there are a few practicalities to bear in mind. Be mindful that none of these techniques are new or special, but should be interesting to anyone who has an interest in memory manipulation of Windows processes in C, just using native Win32 API calls.
If you just want the binary or source code, you will find it on Github at http://mwr.to/ff2z.
Initially, I wrote a DLL to hook the windows messages to AD Explorer’s ListView control; my plan was simply to intercept the LVM_INSERTITEM message and read the lParam->pszText item in the LVITEM struct. However, it seems that they chose to set pszText to LPSTR_TEXTCALLBACK and use notify messages to actually set the text. It would be more complicated to hook those messages because it would involve intercepting WM_NOTIFY messages, identifying LVN_GETDISPINFO requests and intercepting the responses.
An alternative method is to send windows messages such as LVM_GETITEM to the ListView control in order to extract the data, column by column. However, processes cannot write to other process’ memory, meaning that it was not as simple as simply sending LVM_GETITEM. The way that I chose to deal with this is to read and write directly from AD Explorer’s memory.
When attempting to capture the listbox contents, ADEGrab:
ADEGrab now performs two optional activities:
It then displays a balloon tip (in the system tray) to the user, informing them of the captured data.
Primarily, I use it by minimising ADEGrab to the tray, double-clicking it whenever I want to save the results and then pasting into whatever file I want. This works across VMs (tested on VirtualBox) as long as VirtualBox tools are installed and Clipboard is set to bidirectional.
Note that ADEGrab opens and closes all handles on each capture attempt. This means that it does not matter whether you load ADEGrab first, or AD Explorer first, or whether you close or open them.
AD Explorer v1.44 can be downloaded at https://download.sysinternals.com/files/AdExplorer.zip
The ADEGrab binary can be downloaded at https://github.com/stufus/ADEGrab/releases/download/v1.00/ADEGrab.zip. Grab the source, check it and recompile it if you are worried about executing an untrusted binary.
SHA256 (ADEGrab.zip) = 6860b91288eb796a2721b66158cfa668f4f108cac0faa3e5e00a35012a05f3fb
SHA512 (ADEGrab.zip) = 5636d84e608e9e90986b43d740fe043bea6223cce02aedd1927353f946e9600419e3d42f3de5bc8673618ec60038e7d
If you want to compile and run it yourself, just open ADEGrab.sln in Visual Studio 2013 (I used VS2013 Community Edition). You will need to ensure that it is compiled using Unicode rather than ANSI (it will compile but not function correctly in ANSI mode because AD Explorer is Unicode). For those old-timers out there, this is oldschool C (ish) code; no .NET in sight. I’ve nothing against C# by the way; I’m just not a C# coder and there is something I like about C and Win32 APIs.
There are a whole bunch of compiler warnings, mainly because I have not casted variables properly. This is because this started as a quick and dirty project to meet a need, not to win any awards for coding style.
Additional functionality that I will stabilise and release will include:
This is not meant to be an example of perfect code. However, I hope you find it useful.