Gaining SYSTEM in any Windows box

As enticing as the topic of today’s article is, we will be understanding the underlying concepts of how one becomes NT AUTHORITY/SYSTEM by just executing Getsystem (Incase one has a meterpreter foothold) or PowerUp(PowerSploit Module), in a nutshell — Debunking the magic Meterpreter performs to get you the highest privileged shell on a Windows system.

Named Pipes

Microsoft has always liked doing things their own way. Named pipes in Windows have some important distinctions from the concept in Unix-like systems. For one, whereas named pipes can persist beyond process lifetime in Unix, in Windows, they disappear when the last reference to them disappears. Another Windows quirk is that named pipes, although they work a lot like files, cannot actually be mounted in the filesystem. They have their own filesystem and are referenced with \\pipe\[name]. There are functions available to the software developer to work with named pipes (for example CreateFile, WriteFile, and CloseHandle), but the user isn’t going to see them.

There are some situations in which a named pipe is visible to the user in Windows. Using system debuggers like WinDbg

Let’s examine the concept as implemented in Windows a little deeper. I gave examples of functions for working with named pipes. Those are pipe client functions. The initial creation of the named pipe can be done with the CreateNamedPipe function — a pipe server function. The creator of a named pipe is a pipe server, and the application attaching to and using the named pipe is a pipe client. The client connects to the server end of the named pipe and uses CreateFile and WriteFile to actually communicate with the pipe. Although named pipes can only be created locally, it is possible to work with remote named pipes. The period in the named pipe path is swapped with a hostname to communicate with remote pipes:

Architecture for Named Pipes Concept

The server-client terminology is no accident. The pipe server creates the named pipe and handles pipe client requests.

Impersonating the security context of a pipe client

Superfluous pipes and pipe creation race conditions

A similar situation occurs when a malicious process creates a named pipe before the legitimate process gets the chance to — a race condition. In the Unix-like world, named pipes are also called FIFOs in honor of their first-in, first-out structure. This is pretty much how flowing through a pipe works, so it’s fitting. Anyway, a consequence of this FIFO structure in a named pipe creation race condition is that the first pipe server to create the named pipe will get the first pipe client that requests it. If you know for a fact that a privileged pipe client is going to be making a specific request, the attacker just needs to be the first in line in order to usurp the client’s security context.

This is the theoretical understanding of how getsystem creates a race condition by firing up a series of NamedClients and tries reaching to the services of unflagged NamedServers I highly recommend it to study the Ruby file within /usr/share/metasploit-framework/scripts/meterpreter After understanding this underlying concept, the script is pretty much self-explanatory — even for coders who don't use Ruby as their primary-coding language.

I have always been interested in knowing and understanding ‘Behind-the-scenes’ of anything that takes me by surprise. Please feel free to comment on any queries below or if you’d like to share any other insights or facts.



I make things, I break things and I make things that break things

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store