PsTools Suite (Part 1)

This article will focus on the PsTools suite from Sysinternals and how they enhance the command line tools available in Windows.

If you missed the other parts in this article series please go to:

PsTools and you

You really have to admire people who donate their time and expertise to develop free tools for the community. The free part is great, but also is the sheer versatility of some of these tools that is pretty darn nice. We have Mark Russinovich and Dave Solomon of Sysinternals to thank for in this case, as it is they who developed a wide selection of freeware tools called PsTools. All of the tools contained within PsTools are driven from the command line via a cmd.exe session. Do many of you think as I do when it comes to command line driven tools? When I think of command line tools I immediately think of mischief. It could be a hacker breaking into a system, or furthering their exploitation of an already compromised network. A good chunk of the good hacking tools are used via a command prompt. Well what we shall do in this article series is explore the functionality of the PsTools suite and how it could impact you as a system administrator or practicing security professional.

Loved by both hackers and sys admins

Now the tools that are included in the PsTools suite are liked by both hackers and sys admins for several reasons. The tools are nice and small in size, and they are also quite functional. It is really handy to have a small program which will allow you to remotely reboot a computer, or list system information for example. What all of these things have in common is the manipulation of a computer, and typically remotely at that. That is where the thoughts of a hacker come to mind when I think of command line driven tools, and even more so when PsTools comes to mind. Bearing these thoughts in mind, it is likely a good idea to use these tools in a controlled lab environment to see how they work, and just what or why you would use them for.

The stage is set

In an effort to give context to the usage of some of these tools I shall use them after having obtained system level access to a computer here in my lab. That way, you could see what a malicious hacker might use these tools for. In order to gain remote code execution privileges I shall use the Metasploit Framework. After all, why bother compiling my own code when it is already there for usage via the aforementioned program? Beyond Metasploit I shall also use VMware and tcpdump.exe for this lab exercise. So with these tools in place let’s move onto the first tool within the PSTools suite.

psexec

The tool psexec is used to remotely execute programs on a computer. I have used this in the past to execute programs that I installed in an alternate data stream. Quite often when and if a hacker is able to gain access to one of the computers on the network that you work on, you will see psexec transferred over. Back when I wrote the above hyperlinked article psexec worked wonderfully well. Now that I am writing about it in this article there are some really odd quirks. It did not want to work and I had to spend an hour or so to try and figure out what went wrong. Well long story short I was able to get it working, but with a different syntax than in the article noted above. On that note, if any of you can tell me what is different here I would be most interested in knowing. With that said let's take a look at how to use psexec via a reverse shell as supplied by Metasploit.


Figure 1

We see in the above noted screenshot that psexec was invoked successfully. Although ipeye.exe (which is a command line port scanner I will write about in the future) does work, it kicks back an error code of 0. Odd really as it never did this before, however, the test does work and we were able to invoke an executable remotely using psexec. If you have system level access on a remote computer via a shell you can simply invoke a program directly as well. Play around with psexec, and get comfortable with it, as there are quite a few switches that are available for your usage.

psfile

This tool will allow you to see what files are opened remotely on the computer that you invoke this program on locally. By that I mean, if you invoke psfile on say 192.168.1.100 it will show you what files on 192.168.1.100 are presently being viewed by remote computers. It will not however show you the IP address of the computer which has remotely opened a file on your local computer. What it will allow you to do is close the file that is being viewed remotely if you so choose. That is a rather handy feature to have. Seeing is believing, so let’s take a look at what the tool looks like when invoked.


Figure 2

As you can see in the screenshot above, running psfile as such will list files that have been opened remotely. Also listed is the path on the local system where the file that is being viewed resides. That can be a handy feature as well in case you see some new directories on your system that were not there before!

psgetsid

The last tool that we will look at in this article before breaking it off will be psgetsid. This tool will allow you to query a computer for its SID. This is rather handy to have unless you wish to go muck about in the registry where most people are loathe to go. This tool will also allow you to not only see a computer's SID, it will also allow you to specify an account name as well. For instance if you wanted to see the administrator accounts SID then you would simply do as shown in the below noted screenshot.


Figure 3

Wrapup

We have so far seen only a couple of tools that comprise the PsTools suite. There are quite a few left that will be covered in the remaining parts of this series. Being able to use these tools effectively will allow you to not only better manage your network as a system administrator, it will also help you recognize potential hostile activity on your network. As is the case with many good tools, they are used both by sys admins and hackers alike. The versatility and functionality of these very same tools is what makes them attractive in the first place. It would be a good idea to try and imagine various scenarios in which these command line tools could be used in. Information is often not very useful without context, and in this case, context would be sample usage. This type of usage may become a little bit clearer once we have finished covering all of the tools in this suite. You will see that one tool will lead naturally to another one, and so on. See you in part 2.

If you missed the other parts in this article series please go to:

About Don Parker

Don Parker specializes in matters of intrusion detection, and incident handling. He has also enjoyed a role as guest speaker at various network security conferences, and writing for various online and print media on matters of computer security. You can contact Don Parker at dparker@bridonsecurity.com

Click here for Don Parker's section.

Share this article

Receive all the latest articles by email!

Get all articles delivered directly to your mailbox as and when they are released on WindowSecurity.com! Choose between receiving instant updates with the Real-Time Article Update, or a monthly summary with the Monthly Article Update.



Receive all the latest articles by email!

Receive Real-Time & Monthly WindowSecurity.com article updates in your mailbox. Enter your email below!
Click for Real-Time sample & Monthly sample

Become a WindowSecurity.com member!

Discuss your security issues with thousands of other network security experts. Click here to join!

Community Area

Log in | Register

Solution Center

Readers' Choice

Which is your preferred Email Anti Virus solution?