Popping a Shell

There are two ways to get a shell from a socket in Windows . In Unix, you would use dup2() to duplicate the file handles for standard in and standard out, and then execve ("/bin/sh" ). In Windows, life gets complicated. You can use your socket as input for CreateProcess("cmd.exe") if you use WSASocket() to create it instead of socket() . However, if you stole a socket from the process or didn't use WSASocket() to create your socket, you need to do some complex maneuvering with anonymous pipes to shuffle data back and forth. You may be tempted to use popen() , except it doesn't actually work in Win32, and you'll be forced to reimplement it. Remember a few key facts:

1. CreateProcessA needs to be called with inheritance set to 1 . Otherwise when you pass your pipes into cmd.exe as standard input and standard output they won't be readable by the spawned process.

2. You have to close the writeable standard output pipe in the parent process or the pipe blocks on any read. You do this after you call CreateProcessA but before you call ReadFile to read the results.

3. Don't forget to use DuplicateHandle() to make non-inheritable copies of your pipe handles for writing to standard input and reading from standard output. You'll need to close the inheritable handles so they don't get inherited into cmd.exe .

4. If you want to find cmd.exe , use GetEnvironmentVariable ("COMSPEC") .

5. You'll want to set SW_HIDE in CreateProcessA so that little windows don't pop up every time you run a command. You also need to set the STARTF_USESTDHANDLES and STARTF_USESSHOWWINDOW flags.

With this in mind, you'll find it easy to write your own popen() ”one that actually works.

Why You Should Never Pop a Shell on Windows

Windows inheritance is the one concept a Unix coder has trouble getting used to. In fact, most Windows programmers have no idea how Windows inheritance works, including those at Microsoft itself. Windows inheritance and access tokens can make an exploit developer's life difficult in many ways. Once you're in cmd.exe , you've given up the ability to transfer files effectively, which a custom shellcode could have made easy. In addition, you've given up access to the entire Win32 API, which offers much more functionality than the default Win32 shell. You have also given up your current thread's token and replaced it with the primary token of the process. In some cases, the primary token will be LOCAL/SYSTEM; in other cases, IWAM or IUSR or some other low-privileged user .

This quirk can stymie you, especially when you use your shellcode to transfer a file to the remote host and then execute it. You will realize that the spawned process may not have the ability to read its own executable ”it may be running as an entirely different user than what you expected. So, stay in your original process and write a server that lets you have access to all the API calls you'll need. That way you may be able to plunder the thread tokens of other users, for example, and write and read to files as those users. And who knows what other resources may be available to the current process that are marked non-inheritable?

If you do ever want to spawn a process as the user you're impersonating, you will have to brave CreateProcessAsUser() and use Windows privileges, primary tokens, and other silly Win32 tricks. Use the tools on Sysinternals ( www.sysinternals.com ), especially the process explorer, to analyze token issues. Token idiosyncrasies are invariably the answer to the question: "Why doesn't my Windows shellcode work the way I'd expected it to?"