Premise
When I started red teaming, I would often want to know the answers to impossible questions while writing my post-assessment report:
- What was that command I used that I didn't think would be important to making my point, but now I realize it is?
- The output indicated a Windows error message - which error was it?
- Which IP address was leased to me when I did that?
Naturally a red teamer should always be taking copious screenshots, recording IP addresses frequently, and incrementally reporting in tandem with the engagement. But knowing what will be significant later is sometimes a challenge. It would be nice to have a backup.
In this post, I talk about researching and constructing a tool for logging 32-bit cmd.exe commands and output local to one's Windows attack VM. Then I discuss limitations and post source code. I've wanted to do this for a while, but I recently had a project that gave me an excuse to use Detours, so while I was at it, I decided to quickly knock out this project.
Tools
Microsoft Research produced a very useful tool for both investigating this problem and developing a solution, called
Microsoft Detours. Detours is a library for hooking Win32 APIs, which allows one to instrument and extend binary applications. The non-commercial version can be
downloaded for free, but only covers 32-bit architectures. This will suffice for our proof of concept. These techniques are
older than 1999, so I leave it as an exercise for the student to extend this to 64-bit.
One of the Detours samples, named traceapi, hooks 1,401 Windows API functions, and can provide detailed insight into how an application works. Meanwhile, another Detours sample, named simple, shows an example of hooking and extending the Windows SleepEx API. This is all we need to get started.
Investigation
To use the traceapi sample, you must copy the Detours root to a writable directory, open a 32-bit Windows SDK Prompt, and invoke nmake from the samples directory. The bin.x86 Detours sub-directory will contain many files, including the following tools necessary to this exercise:
- traceapi.dll (or trcapi32.dll - I seem to recall getting different results depending upon how I built this)
- withdll.exe - for loading an application with a DLL in its address space
- syelogd.exe - for logging trace output from Detours tools
When using traceapi, I expected to find patterns including CreateFile(CONIN$) / ReadFile, or some such. Then I anticipated hooking functions to record which handles corresponded to CONIN$, CONERR$, and CONOUT$ so that I could know which ReadFileW and WriteFileW activity corresponded to console input and output.
To begin the investigation, I launched syelogd.exe to log to a file, as follows:
C:\Users\someone\Detours\bin.x86> syelogd.exe trace_cmd.log
I then launched the 32-bit cmd.exe with traceapi.dll in its address space to begin tracing:
C:\Users\someone\Detours\bin.x86> withdll.exe /d:traceapi.dll C:\Windows\SysWOW64\cmd.exe
At this point, I typed a few commands like DIR and EXIT, and then terminated syelogd.exe.
 |
| Ah, beautiful trace output |
What I found was happily contrary to my expectations...
 |
| Found the "Easy" button |
The Windows command interpreter uses the ReadConsole and WriteConsole APIs for reading to and writing from the console. All the easier to hook, with no state tracking required.
Development and Features
The Detours sample named simple contains all you need to get started. Copy that folder, name it something else, update the Makefile, and get cooking. One bump I ran into and hacked up a fix for was that the 32-bit rc.exe crashed when executing it within my 32-bit Windows SDK Prompt. This is why my own Makefile (not uploaded) directly references the 64-bit rc.exe.
Logging
To customize the sample code to do my bidding, I followed the simple example's hooking pattern to first hook ReadConsoleW and WriteConsoleW. My initial logging hooks simply returned the value of the real functions just for testing purposes. I then tried printf("WriteConsole: %S", lpBuffer) to test whether I could output the data, and finally opened a file within the DllMain function.
Here is an example of the logging for a call to net.exe:
 |
| Logs for days |
Why is there a separate log for each process? Because my DLL creates a new, unique log every time it is loaded. See the Limitations section below for discussion.
Why does net.exe create two logs? Because net.exe calls out to net1.exe to do its work.
IP Address Logging
Status Command
I wanted a way of knowing for sure that logging was enabled, without typing EXIT and having my parent prompt close on me. So, I implemented a secret command, REM status. Because my command begins with the REM command, it will be ignored by the command interpreter but intercepted by my hook on its way to the application.
BOOL WINAPI
LogReadConsoleW(
HANDLE hConsoleInput,
LPVOID lpBuffer,
DWORD nNumberOfCharsToRead,
LPDWORD lpNumberOfCharsRead,
PCONSOLE_READCONSOLE_CONTROL pInputControl
)
{
BOOL ret = pReadConsoleW(
hConsoleInput,
lpBuffer,
nNumberOfCharsToRead,
lpNumberOfCharsRead,
pInputControl
);
TODO
if (!wcsncmp((const wchar_t *)lpBuffer, CMD_QUERY_STATUS,
wcslen(CMD_QUERY_STATUS)))
{
printf("Logging to %s\n", cmdlog_fname_expanded);
LogInfoStampToFile(stdout);
}
LogToFile(cmdlog, "%S", lpBuffer);
State = clsLabel;
return ret;
}
The result is satisfactory. I type REM status, and if I'm hooked, I see a nice little confirmation that logging is enabled, including the log file name and some IP address information.
 |
| Yes, Neo, you are in the Matrix. |
Limitations
Otherwise known as "problems I don't plan to solve until I get a copy of Detours Enterprise and some more time." The last 10% always takes 90% of the time, amirite?
Single-File Logging
This will probably entail using IPC, and some IPC mechanisms (like named pipes) cannot be initialized in DllMain because they could cause a deadlock by precipitating an attempt to acquire the loader lock (check out
Microsoft's article on DLL best practices). This means writing "lazy initialization" code. I leave this as an exercise for the student.
Another scheme is for each child to share a log file with the parent process whose name is based on the PID of the top-most parent of the current process that has our DLL loaded in its address space. The APIs used to do this might entail a LoadLibrary or some APIs that violate DLL best practices, so again... Exercise left for the student.
Alternately, I could just open and close a single logfile with a single name, but then if I open several logged command prompts, one may fail to get access to the log as another is writing to it (say, if I'm running a command that outputs continuously while running another command in the other prompt). So, I didn't do that.
Cross-Architecture Process Creation
Because Detours Express is only for 32-bit, we have no 64-bit DLL. So here's what happens when you try to load a 64-bit process...
 |
| Nope. |
Hooking 64-bit, while fun, is not something I have time for right now (I'm a father; give me a break). But my employer has a license for 64-bit, so perhaps I will extend this later. How? I anticipate that I will use the
ImageHlp APIs or something to figure out whether the CreateProcess call is for a 32- or 64-bit process, and then load the appropriate DLL. Yay!
^M&^M's
If you open the output log files in something like
gvim, you will see stray ^M's (character 0x0d) all over the place. Yuck. But a quick swipe of the %s/^M//g in gvim eliminates these, so I just can't bring myself to care.
Source Code
As is frequently the case with my spare-time experimentation, this code is proof of concept only. If it doesn't compile because I didn't close a pair of parentheses, rest assured that it's because I had to drop everything and rush over to my young daughter to prevent her from acquainting herself with an electric socket. Forgive me. But hopefully the thought process published here and the examples available in the code will help you think of new ways to solve problems.
The code is here:
https://github.com/strictlymike/tools/tree/master/cmdlog
