Command Hijacking with .COM

In this writeup we talk demonstrate a technique that allows for command interception from a target user's command prompt or powershell on modern Windows systems

Part One: Introduction

If you follow me on Twitter, you've probably seen my raving about this book:

The Giant Black Book of Computer Viruses is a deep dive into late 90s early 2000s techniques, tactics, and procedures. One of the things about this book that I love so much is that it covers .COM executables to a depth that most modern researchers avoid.

Even though it might not feel relevant, today we're going to talk about one of the weird features of Windows that’s briefly covered in this book, and we'll present a use case for this technique in support of Red Team persistence.

Part Two: Getting Started

We're going to begin by using this code template:

#include <windows.h>
#include <stdio.h>

int main(void){
	// print our message
	printf("HELLO THERE!");
	
	// wait for a little bit
	Sleep(5000);
	
	//execute calc
	WinExec("calc.exe", 0);
	
	return 0;
}

It's pretty straightforward. Our code prints a message sleeps for 5 seconds, then executes calc.exe. This will later serve to forge legitimate user action.

We compile our code with MingW

x86_64-w64-mingw32-g++ -o implant.exe main.cpp

If we run our program now, we should see that it does exactly what we expect.

Part Three: The Technique

During my reading, I noticed this interesting paragraph:

In essence, the DOS command prompt would always try to load .COM files before .EXE files for any given command. Weirdly enough, that is still the case in modern Windows systems. However, because the modern Windows loader does all the appropriate checking at load time we can change the extension of a valid .EXE to .COM and achieve command interception without crashing or special handles in our implant.

Let's go back to our sample program for a demonstration.

In our current directory we have implant.exe, lets make a copy of that and call it implant.COM instead.

Now, lets modify our source code to give a message that will allow us to differentiate between the two files.

And the last step is to compile our program once again and then run it.

Now...what if we don't use a file extension when calling our program. What happens then?

Here we can see that modern Windows systems retain the .COM prioritization when loading commands. Let's see if we can find some places where this might be useful.

Note: if you call "implant.exe" specifically, the .COM implant will NOT get called

Part Four: Utility

This might seem like a trivial trick, but with a little bit of clever thinking, we can place a .COM file in special directories that enable persistence. For this proof of concept, we'll continue using calc.exe as our target, but other .exes can be targeted for a similar effect. Of particular interest are explorer.exe, cmd.exe, and powershell.exe because these commands are often called without file extensions.

Let's rename implant.COM to calc.COM and place it in C:\Windows\System32

Now let's open up powershell and call "calc"

And we once again validate that we can intercept the command!

Part Five: Conclusion

In this writeup we saw how we could use the Windows extension prioritization to take a renamed executable and intercept user commands. This technique allows persistence mechanisms in the form of ".COM" files that are initiated on user action.

In this example, we used WinExec to forge the call to calc.exe after the user-initiated implant, but more complex implementations would require significantly more complicated setups to forward arguments to the actual target program and retain operational security.

References

The Giant Black Book of Computer VirusesAmazon.com

Difference between .com, .exe, and .bat?Stack Overflow