PsExec Examples: How Remote Execution Works

December 02, 2015

In today’s Whiteboard Wednesday, David Maloney, Sr. Software Engineer for Rapid7, discusses the origins of PsExec, how remote execution works, how compromised credentials can lead to remote execution on your network, and how to test this in your environment using Metasploit.

Watch the video to learn more!

Video Transcript

Welcome to this week's Whiteboard Wednesday. I'm David Maloney, Sr. Software Engineer on the Metasploit team and this week we are talking about PsExec: The Internals of Remote Execution.

Show more Show less

So PsExec is a tool created for remote system administration back in the 90s by a guy named Mark Russinovich who created a whole bunch of real useful tools and later got acquired by Microsoft. Most of you have probably heard of him by now. He's kind of a big deal. Why this is important to us is what PsExec allowed you to do was to take any arbitrary program and push it to a remote machine and tell the remote system "run this program," which is great for a system administrator. But if you stop and think about it for a second, it's great for an attacker too. As long as you have credentialed access you have the ability to push any arbitrary code to your victim and tell that victim, "Yeah, just go ahead and run this. It'll be fine. I promise."

So this is the way to test credentials on Windows systems. If you get any kind of credentials for a Windows box, you're going to want to test it against the SMB service and use the PsExec module to see if you can actually turn that credential into a compromisable box. It is one of the top ways people use Metasploit to gain access to a Windows victim. So let's talk real quickly about how it actually works under the covers. So you have your attacker here, whether it's Metasploit or just using the PsExec tool itself that Mark Russinovich wrote and what you're going to do is you're going to embed something malicious inside of a service executable and these service executables are, for the most part, just like any .exe program that you would run on your machine.

They're set up a little differently so that the service control manager understands them. But we'll get to that in a second. So we take our malicious code and we wrap that into a .exe file. We authenticate to our victim machine and try and gain access to the admin dollar share. This is usually C:\windows\system32 on your actual file system. It has to be this location because that is a privileged file location on the Windows file system and if we can gain that access, we will push our malicious executable into that admin dollar share. Now, we're not going to do anything with it just yet. All we're doing is getting it into that location on the file system for our victim.

Now, we make a separate call to the RPC or remote procedure call service on our victim machine which is also running over the SMB protocol. We authenticate to the RPC service and through it, we talk to what's called the service control manager. The service control manager is what's responsible for managing and maintaining all running background services in the Windows operating system. We tell the service control manager that we have placed this .exe in admin dollar and it should run that as a service. Service control manager loads that .exe up, treats it as a service. It has some special functions that it calls inside that .exe and our .exe says, "Hey, I'm a service, and I only really want to do one thing and that's put this malicious code into memory."

Once it does that, the service shuts itself down and all this cleans itself up behind it. But now running in the memory of your system is that malicious payload. In the example of Metasploit, this would be your Meterpreter payload. So you say, "Okay, that's interesting. But that's fairly basic stuff. What can I really do with this?" Well, Metasploit has a way to use this to great effect without even having to know the credentials ahead of time as long as you've already compromised one machine. We do this by abusing what are called local authentication tokens and we have a post module called PsExec as local user.

So imagine you have a scenario where you have compromised this machine B through the firewall. You can't talk to machine C, D or E in this network but Box B can. Furthermore, the user that you're running as on Box B is authorized to gain access to these three boxes. So PsExec as local user will use the local authentication token of your current running process and run the same exact process, but it will run it out against all the boxes it can see in this network. So we tell Box B to now run PsExec from itself to Boxes C, D and E using the credentials that we might not even know. So we don't have to know what that password is.

The Windows operating system does it all for us and the end result is that we go from Metasploit to Box B to compromising all four of these boxes all through using mechanisms that are in place provided to us by the operating system itself. So, once again, this is just a way that illustrates how fundamentally important to security, proper credential management and auditing the usage of credentials in your environment is because PsExec allows you to turn any compromised credential into unfettered access to one or more assets in your environment.

Thank you for joining us this week, and we'll talk to you next week.

Free Metasploit Trial

What could an attacker do with your vulnerabilities? Find out with a free trial of our pen testing software.

Download Now