Using PsTools in a pentest

I’m going to start off this blog by wishing a happy birthday to a very important person – me. :)

Now, onto the content!

PsTools is a suite of tools developed by Sysinternals (now Microsoft). They’re a great complement to any pen test, and many of my Nmap scripts are loosely based on them. As good as they are, they aren’t without their quirks!

Here are a few topics worth discussing:

  • Ports and traffic
  • Specifying an account
  • Running it purely in a console

Most (possibly all) of the PsTools use standard Windows functions. That makes life easy – we can expect PsTools to act the same way other remote functions work. If we know how!

Ports and traffic

To me, understanding the traffic is the most important part of using a tool. And it’s especially important if you’re creating a netcat tunnel or something.

Since PsTools uses standard Windows functions, we can expect it to use port 445 for all traffic. The majority of them use that port and nothing else. Simple stuff!

Although PsTools are closed source, I’ve implemented similar functionality in many of my Nmap scripts. Have a look at the smb-* scripts (included with Nmap 4.85beta4 and higher) if you want to understand the traffic more.

Specifying an account

By default, PsTools will use the account it’s running as to connect to the remote server, including your password. So, if you’re ‘Administrator’ with the password ‘Password1’, that’s what’ll be used by default when you run a PsTools program. That’s helpful on a pentest – if you exploit a system as a user account and run PsTools, you’re effectively getting access to every system with the same password!

You can try this by setting up two boxes with the same username/password, logging into one, and running the following command:

PsInfo.exe \\a.b.c.d

If you want to use a specific account, you can normally pass -u and -p parameters (for username and password). I seem to recall, however, that not all PsTools apps take those parameters (although I tested a couple quickly and they all did, so maybe I’m lying?)

In any case, you can give a username and password without relying on PsTools to support it by establishing a session with the machine using the following command:

net use \\a.b.c.d

You’ll be prompted for a username and password. This is similar to starting a NULL Session, except that you actually provide an account. When it’s done, you’ll have an authenticated SMB session over TCP.

Then run the PsTools program as usual:

PsInfo.exe \\a.b.c.d

And it’ll use the account (and, in fact, the same TCP session) you already established. When you want to terminate the session, delete it with:

net use \\a.b.c.d /del

Finally, passing the hash with PsTools. Passing the hash takes advantage of Windows’ single-sign-on capabilities that I alluded to earlier – the ability to log in with the local account instead of giving a full password. This is using the user’s hash to log in (the hash of ‘Password1’) instead of the password.

Because PsTools uses Windows’ implementation of SMB, it has to use Windows’ authentication routines. For some reason, Microsoft didn’t want people logging in with just the hash, so that means passing the hash natively is impossible.

Fortunately, the good folks at Core Security released a tool called the Pass the Hash Toolkit. It contains a program called “iam.exe”, which will replace your username/hash in memory with an arbitrary username/hash. Then, when you try to log in, it’ll use the specified hash instead of your own!

Let’s look at an example (I’ve removed most of the hashes for readability):

C:\>iam.exe -B -h administrator:domain:293b2c[...]:c35f1c[...]

This will copy the given username and hashes on top of the current user’s credentials in Windows’ memory. When you use the PsTools programs now, they’ll connect with the given username and hash.

PsInfo.exe \\a.b.c.d

Running purely in a console

Finally, this is the most annoying part about PsTools – the first time you run it on a particular system, a graphical box with the EULA comes up. While it’s great, and you should understand the EULA, it’s incredibly inconvenient when you’re trying to be discreet. For that reason, I put together a .bat and .reg file automatically agrees to the EULA for all PsTools programs for the current user.

Note that by running this file, you are implicitly agreeing to the EULA for PsTools. You should only use this if you’re trying to run the tools in console-only mode. eulas.bat

@echo off

rem Turns off the registration agreements for the PsTools programs, so they can be used in
rem a pen-test without popping up on the user.
rem
rem Naturally, you should familiarize yourself witht he EULAs before doing this.

echo Trying to import...
echo Running: regedit /s eulas.reg
regedit /s eulas.reg

You’ll also need eulas.reg

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Sysinternals]

[HKEY_CURRENT_USER\Software\Sysinternals\loggedon]
"EulaAccepted"=dword:00000001

[HKEY_CURRENT_USER\Software\Sysinternals\Psexec]
"EulaAccepted"=dword:00000001

[HKEY_CURRENT_USER\Software\Sysinternals\psfile]
"EulaAccepted"=dword:00000001

[HKEY_CURRENT_USER\Software\Sysinternals\PsGetSid]
"EulaAccepted"=dword:00000001

[HKEY_CURRENT_USER\Software\Sysinternals\PsInfo]
"EulaAccepted"=dword:00000001

[HKEY_CURRENT_USER\Software\Sysinternals\PsKill]
"EulaAccepted"=dword:00000001

[HKEY_CURRENT_USER\Software\Sysinternals\PsList]
"EulaAccepted"=dword:00000001

[HKEY_CURRENT_USER\Software\Sysinternals\PsLoglist]
"EulaAccepted"=dword:00000001

[HKEY_CURRENT_USER\Software\Sysinternals\PsPasswd]
"EulaAccepted"=dword:00000001

[HKEY_CURRENT_USER\Software\Sysinternals\PsService]
"EulaAccepted"=dword:00000001

[HKEY_CURRENT_USER\Software\Sysinternals\PsShutdown]
"EulaAccepted"=dword:00000001

[HKEY_CURRENT_USER\Software\Sysinternals\PsSuspend]
"EulaAccepted"=dword:00000001

Put that .bat and .reg file in the same folder, run the .bat file on the commandline, then go about your pentest without worrying about the user getting a PsTools popup on their machine.

Conclusion

That was a quick discussion on the aspects of the PsTools suite that I’ve always had issues with. Hopefully it’s helpful!

If you have any questions on what I’ve said here, or about PsTools’ functionality in general, please let me know. I have a pretty good understanding of how PsTools programs work, and am happy to share it. If there’s enough demand, I’ll even do a blog about the individual pieces of software. :)

Ron “Happy birthday to me!”

PS: If you believe that the registry modification goes against the spirit of the PsTools EULA, or you take exception to my post, please let me know and I will modify it. I’m not trying to upset people or provoke legal responses here :)

Ron Bowes

Comments

Join the conversation on this Mastodon post (replies will appear below)!

    Loading comments...