SANS Penetration Testing

SANS Penetration Testing

A Penetration Tester's Pledge

by Ed Skoudis

Over the weekend, I was thinking about the wonderful psexec capabilities of tools like Metasploit, the Nmap Scripting engine smb-psexec script, and the psexec tool itself from Microsoft Sysinternals. It's my go-to exploit on Windows targets, once I have gained SMB access and admin credentials (username and password, or username and hash for pass-the-hash attacks). It works on a fully patched Windows environment, giving you code execution with local system privileges of a program or Metasploit payload of your choice. That's especially helpful in a penetration test once you gain access to an internal network that is relatively well patched. We talk a lot about how to leverage this capability creatively and effectively in my SANS 560 course on Network Penetration Testing and Ethical Hacking.

During my class, this lesson sinks in with some students faster than others. Where it doesn't sink in, target crashing inevitably ensues as people try other service-side exploits to hammer a target. To help make the lesson of the usefulness of psexec a little more memorable, I've created the following Despair-like poster, titled "A Penetration Tester's Pledge":


*Photo credit: Wiki Commons, User Grj23

Don't get me wrong: I love service-side exploits as much as the next guy. But, some of them could crash target processes or even entire systems. Further, psexec is so wonderful because it comes in handy once you've compromised one target (perhaps with a client-side exploit), escalated privileges, grabbed some juicy-licious admin credentials, and are looking to spread to more prey. Now, you can target other fully patched Windows systems in the environment with psexec, your new besty-best friend forever.

The psexec capability just completely rocks, and we have several different variants to choose from:

  • If you want super flexibility in making the target machine run a Metasploit payload of your choosing, such as the mighty Meterpreter, use Metasploit's psexec module (windows/smb/psexec), which also supports pass-the-hash for authentication (no need to know what the password is; instead, just set SMBPass to the LM:NT hashes). You can also choose a custom RPORT besides TCP 445, so you can port-forward pivot other ports through to your ultimate target's TCP port 445.
  • If you want to run something at scale across a large number of machines you've scanned, consider using Ron Bowes' psexec Nmap Scripting Engine script on targets where you've found TCP port 445 open, which also supports pass-the-hash sweetness.
  • If you are in an environment that prohibits you from running third-party attack tools like Metasploit or Nmap (oucha, I know), you might want to use Microsoft SysInternals' own psexec program, which typically doesn't flag anti-virus tools because it comes from Microsoft itself and is regularly used for system administration. This version doesn't explicitly support pass-the-hash, but you can use Hernan Ochoa's excellent Windows Credentials Editor (WCE) to inject your hashes into your Windows machine's memory, and then use Sysinternals psexec with the new credentials.
Regardless of the variant you use, psexec leverages your credentials to make an SMB connection to the target machine, writes into its file system some code you want to execute, creates a service on the box, and uses the service to execute your code. If you use the Metasploit or NSE versions of psexec, it then cleans up after itself, by deleting the service and removing the code from the file system (both the service and code have a pseudo-random name in Metasploit and NSE). Yaaaayyyy, Metasploit and NSE! Thanks for doing it right.

Important note: the Microsoft Sysinternals psexec program doesn't remove the service that it creates. Thus, as a penetration tester, you'll either leave behind an installed service on the machine, or you'll need to remove it after you are done. I like to remove it, restoring the environment to what it was like before I was there, lest I slightly increase the attack service of the target machine by leaving behind the psexec service and its related code. You can remove it using the Microsoft service control (sc) command, as follows:

C:\> sc \\<RemoteTarget> stop psexesvc

C:\> del \\<RemoteTarget>\admin$\psexesvc.exe

C:\> del \\<RemoteTarget>\admin$\system32\psexesvc.exe

C:\> sc \\<RemoteTarget> delete psexesvc


And, one more SUPER IMPORTANT NOTE: The Sysinternals psexec has an option to allow you to specify a different user and password other than your current credentials (the -u <user> and -p <password> command flags). If you don't use the -u <user> and -p <password> option with the Sysinternals psexec, the tool uses whatever Microsoft Windows authentication your client and the target support (such as NTLMv2), passing through your existing credentials via a challenge/response protocol. However, if you use -u and -p with Sysinternals psexec, it will PASS THROUGH THESE CREDENTIALS IN CLEAR TEXT (as described brilliantly by Mike Pilkington here and in Section 4 of this article by Jean-Baptiste Marchand here). That's why I recommend you NEVER use -u and -p with psexec, unless you are comfortable passing through admin-level creds in cleartext. Your best bet it so use it without the -u and -p options.

So, there you have it. Psexec... a great capability and trusted friend, along with a few notes on its safe usage.

By the way, I'm really excited to be teaching my SANS Security 560 Network Pen Testing course in Amsterdam in April (22nd through 27th). Join us by registering here: http://www.sans.org/event/secure-europe-2013/course/network-penetration-testing-ethical-hacking

I'll also be teaching 560 at SANS FIRE in DC June 17th through 22nd. You can sign up for that one here: http://www.sans.org/event/sansfire-2013/course/network-penetration-testing-ethical-hacking

Thanks!

--Ed Skoudis

SANS Institute Fellow
Counter Hack Challenges Founder

5 Comments

Posted March 18, 2013 at 3:58 PM | Permalink | Reply

Ken Connelly

I took SEC560 from Ed and Tim via vLive in Jan/Feb. I got more good out of it than most I've taken.

Posted March 29, 2013 at 2:47 PM | Permalink | Reply

Mike Pilkington

Good post Ed! And thanks for the nice words and link to my PsExec post. I actually have a much newer "Deep Dive" post on PsExec located here: http://computer-forensics.sans.org/blog/2012/12/17/protecting-privileged-domain-accounts-psexec-deep-dive.

In this post, I discuss the issues with using the "-u" option. Not only does it pass credentials in the clear, it also loads hashes

Posted March 29, 2013 at 6:52 PM | Permalink | Reply

Ed Skoudis

Thanks, Ken. That means a lot to me. I really enjoyed that Smell-o-vision class! :)

Mike -- great point. Your new article makes a fantastic point: Not only does the -u option send cleartext creds to the target, it leaves hashes ripe for dumping. Your comments on the delegation token are also worth noting. Thanks for the great work, my friend.

(For those looking for the link, Mike includes it above... or you can go to: http://computer-forensics.sans.org/blog/2012/12/17/protecting-privileged-domain-accounts-psexec-deep-dive).

Posted April 25, 2013 at 6:32 PM | Permalink | Reply

Martin G

Ed,

You're the most pedagogical pentester there is. Great article. As always.
At every evaluation at SANS I have requested you to come to Europe for the 560. And now, I noted that the wish had come true. And guess what, I can't attend.
F*ck.

Posted April 26, 2013 at 4:08 AM | Permalink | Reply

Ed Skoudis

Thanks, Martin, for your kind words! I'm in Amsterdam right now, teaching 560. It's been a great week. Today is Day 5. Tonight, we'll finish hour NetWars Tournament. And, then tomorrow is the big Day 6 CtF. Wish you were here, sir! Maybe next time. I am looking forward to it!

Post a Comment






Captcha

* Indicates a required field.