Getting the Most Out of DEF CON: Some Tips for First Timers

by Ed Skoudis

Are ya going to DEF CON?  Thousands of hackers, infosec pros, security researchers, curious newbies, reporters, and countless others will.  I’ve had the honor of attending the world’s biggest hacker conference for 13 of the past 14 years (I missed in 2011 because my wife needed big-time surgery… she’s doing great now, thankfully!).  I thoroughly enjoy the conference and bring my whole team there each year.  I have always been amazed at its ability to attract first-timers to the conference.  During the closing ceremony, The Dark Tangent, DEF CON’s venerable founder and fearless leader, asks for a show of hands: Raise your hand if this is your first DEF CON.  On my completely unscientific guestimate of the number of hands raised among the several thousand people in the ginormous room, about 30 to 40% are brand new to the DEF CON experience.

This year, two of my closest friends will be embarking on their first trip to the ultimate hacker mecca, and we’ve been chatting about it for the past several weeks.  I’ve written up a couple of tips below for them, and I thought others might find them interesting as well.  Please note that I’m neither an organizer nor in the leadership of DEF CON.  I’m just a little hacker, a happy DEF CON attendee, wanting to share some tips that I’ve found useful over the years.

Tickets: You don’t register or pay in advance for DEF CON tickets. Just show up and pay cash for them at the door.  The lines get kinda long, so bring some water and a snack, as well as a friend, to help pass the time while waiting.

Badges: DEF CON typically has amazing badges chock full of electrical gadgetry and ciphers, but they often run out of the super cool ones early, leaving paper or cardboard badges for everyone else.  If you want one of the best badges, get in line early on Thursday.  The most common kind of badge is the “human” badge, which is for general attendees.  Other badges include speaker, goon, press, and the much coveted uber black badge for top conference leaders and winners of the most prestigious contests.

Hotel: The conference is an all-encompassing experience which may tie up 14 to 20 hours a day of your time.  Don’t spend a lot of money on a hotel, because you won’t be there much.  You can find cheap hotels within walking distance for Thursday night and Sunday night, likely in the $49/night or less range.  Friday and Saturday get more expensive, as tourists flock to Vegas, but if you hunt around and sweet talk some hotel reservation lines, you may be able to find something in the $59 to $109 range.  Early in my career, I’d share a room with two or three other attendees to split the costs, getting our average per night room rate to about $30 or so.  It was great fun, and quite affordable.

When to Get There?  The con runs from Thursday to Sunday.  A lot of the activities get underway on Friday, so many people show up then.  But, I recommend making sure you get there on Thursday.  There are some amazing vendor parties on Thursday night for people staying over from the Black Hat conference to attend DEF CON.  Plus, there’s a much better chance you’ll get a cool badge if you are there on Thursday.

When to Go Home?  Around 5:30 PM on Sunday, the conference quickly becomes a ghost town.  I am always filled with sadness as the conference winds down and disappears.  You could leave Sunday night, just like almost everyone else.  But, I started a little ritual about 8 years ago that helps assuage my post-con blues. I go out for a nice meal with a bunch of my closest friends, and then fly back on Monday morning.  You may want to try something similar.

Goons: The folks who do crowd control at DEF CON are known as Goons.  They are all volunteers and work diligently to make the conference flow.  The Goons may sometimes sound gruff or pushy, but treat them well, respect them, and do what they say.  I know that one of the themes of DEF CON is questioning authority, but the Goons really have the conference goers’ best interests in mind.  Be good to them, and they’ll be good to you.

Sleep:  Don’t plan on getting much sleep at the conference.  Sleep in advance.  Sleep afterward.  Many of us get 4 hours or less per day of sleep during conference time.  Priest (the head goon at DEF CON) said to me years ago at the conference, “Sleep? You’ll have plenty of time to sleep when you’re DEAD!”  Whenever I grow weary at DEF CON, I can actually hear Priest’s voice in my head saying that, which helps get me going again,for more DEF CON learning, fun, and mayhem.

Parties: Some of the best attractions at DEF CON are the plentiful parties hosted by several different hacker groups.  Some of the parties are open attendance, while others are invite only.  I’ll often go to three or four parties each night, just to make the rounds, see old friends, meet new people, and have fun.  Make sure you take in some parties.  Even if you aren’t the partying type, these events are a great way to network and learn.  I typically learn more during the parties than I do at the talks themselves.  If you are the shy type, look around for other shy people just standing around at the party and engage in a conversation.  “Is this your first DEF CON?” “Where are ya from?” “What was the coolest talk you saw today?” are decent conversation starters.  Various groups post a list of DEF CON parties online, so make sure you check them out regularly, as they are frequently updated during the con itself.  Simply searching for “DEF CON parties” and the year will get you a good list.

Talks: Try and attend at least a few talks on a variety of topics.  Some of the most popular talks, though, are a mad house, with long lines, overflow crowds, and room size restrictions so some people are turned away.  Early on in the con, pick a few must-go-to talks that you really want to see, but always have a backup alternative, just in case your first pick’s room is maxed out.

Hardware Village: Stop by the hardware village at least once, check out all the electrical gizmos, and pick a lock.  Don’t know how to pick?  No problem.  There will be coaches there to help you, and it’s super fun.  In fact, it is surprisingly easy to pick most locks, and it’s a great thrill to pop your first lock. You’ve gotta check it out.

On the Topic of Drinking: Vegas lies in the middle of a big honkin’ desert.  Daytime temps often surpass 107 degrees Fahrenheit.  Even if you stay indoors, the air itself will vacuum water out of your body and your very soul.  Drink lots of water, double or triple what you’d normally consume.  And, if you plan on imbibing some alcohol while at the conference, have even more water, perhaps a glass in between each alcoholic beverage you enjoy.  Otherwise, your colossal headache the next morning will prevent your full enjoyment of the con.

Chill: DEF CON is so full of different activities, it can be overwhelming. Make sure you get some down time to relax.  There is typically a large breakout room for just hanging out and resting.  Use it.  If there’s not enough stimulation in that room for you, take a stroll through the big Capture the Flag room and watch some of the crazy videos played on the big wall.

Con Network: DEF CON has a big wireless network that is free for anyone at the conference to use. That’s the good news.  But, I have had many friends and associates get hacked big-time while on this network, their systems laced with malware and other nasty stuff.  I recommend staying off of the conference network entirely.  In fact, I recommend disabling Wifi and Bluetooth on your laptops and mobile devices at the conference.  I carry only a cell phone, which I use for text messaging friends to meet at the conference, and to review the conference agenda and party list, but NEVER via Wifi.  Also, it’s probably wise to avoid any ATMs for getting cash at the conference.  In past years, cash machines have mysteriously appeared and later disappeared at the conference, likely there to dupe unsuspecting users into providing a mag stripe and a PIN.

The Closing Ceremony: At the end of DEF CON on Sunday, the whole DEF CON crew stages a multi-hour closing extravaganza.  This event includes some great conference memories, applause for all the organizers of various events, and the announcement of winners for various contests held during the conference, including the awarding of the black badges.   Although it is always too long, the closing ceremony is an excellent way to wind down the conference.  I wouldn’t miss the closing ceremony for the world.

Well, I hope those tips serve you well.  Have fun at the con!

–Ed Skoudis.
SANS Fellow
SANS Penetration Testing Curriculum Lead

Announcing: the ULTIMATE SANS Pen Test Poster!

by Ed Skoudis

I am super excited to announce the release of our brand-new SANS Ultimate Pen Test Poster!  Three months in the making, this poster is chock full of tips, tricks, ideas, tools, resources, references, practice environments, and much much more, all focused on helping penetration testers and related security professionals excel in their work.  Behold Side 1 of the poster:

The Ultimate Pen Test Poster: Side 1

Side 1 of the poster (above) includes the following items:

  • An awesome mind map by Aman Hardikar .M, which lists over 100 free penetration testing practice environments including downloadable distributions, capture the flag environments, and “hack this site” style web sites.  This is a printed version of the incredibly useful mind map which Aman offers here.  A special thanks to Aman for letting us reprint and distribute his incredible work.
  • A description of the SANS Pen Test Coins, describing how you win them in courses such as SANS SEC 504, 560, 660, 575, 542, 642, 617, and NetWars, as well as the customized ciphers included on each coin designed for you to crack.
  • A description of our upcoming penetration testing event called The SANS Pen Test Hackfest Summit and Training Event, which will feature four nights of NetWars, an evening of CyberCity missions hands-on, and a chance to win up to four SANS Pen Test Coins.  Please do check out that event and register!  It’s gonna rock.
  • A description of the SANS Pen Test Curriculum, including each course we offer to help penetration testers master their trade and build their skills.

That’s all well and good, but the BEST part of the new poster is Side 2.  Check. This. Out:

The Ultimate Pen Test Poster: Side 2

Side 2 of the poster is split into the different types of penetration testing work we all do.  For each type of pen test, we provide a list of must-have tools, describing what each one does and how you can use it.  We also include tips and tricks for maximizing your effectiveness in that particular arena, with ideas for applying a high-quality methodology in your work.  And, the poster provides a set of web sites and twitter feeds for staying current in each and every one of its topic areas.  These sections were written by some of the best penetration testers, instructors, and security researchers I’ve ever met, and I’m thankful for their input.  The sections include:

  • Network Penetration Testing by John Strand
  • Exploit Development by Steve Sims
  • Mobile Device Penetration Testing by Josh Wright
  • Wireless Penetration Testing by Larry Pesce
  • Web App Penetration Testing by Kevin Johnson

I also wrote a section on pulling it all together, integrating the results from different parts of your penetration test by using collaboration and analysis tools and ensuring that your results are high quality, repeatable, and understandable.

Note also that the back of the poster is built up from little building blocks, just like a really good penetration test.  I think these multi-colored, interlocking building blocks give the poster a cool look and whimsical tone, while keeping it professional so you can hang the poster in your office with pride.

So, how do you get a poster?  Well, you can click on the links above to download them.  For a printed copy, if you are at SANSFIRE this week in Washington DC, we have passed them out in each of the penetration testing courses.  If you are at SANS FIRE and didn’t get one, ask me or another pen test instructor for one, and we’ll gladly hand one to you.  Also, tonight at the SANS NetWars event at SANSFIRE, we’ll have some posters for you.

Furthermore, the posters are being included in the SANS postal mailing of upcoming big brochures.  If you receive SANS brochures in the mail, be on the lookout for one with the Pen Test Poster.  I’ve heard some people started receiving them this week already.  It’ll be bundled with the brochure, so look carefully, and don’t throw it away.  :)

And, finally, if you come to an upcoming SANS course on penetration testing in the next couple of months, we’ll make sure to have posters ready and available for you.

Thanks for reading, and I hope you enjoy the posters.  Again, a special thanks to all the contributors to the poster for their hard work.

–Ed Skoudis
SANS Penetration Testing Curriculum Lead
Founder, Counter Hack

Announcement: The Network Scanning Watch List

[Editor’s Note: A recurring concern among penetration testers is that a scan may have an unexpected and seriously undesirable impact on some target devices.  We’ve all heard stories about a simple TCP SYN scan killing this or that network device or SCADA system.  Wouldn’t it be cool if someone built and maintained a list of such devices, so we know what to watch out for?  I’m happy to announce that Owen Connolly and Robin Wood (digininja) have done some great work pulling together the Network Scanning Watch List of devices that have encountered problems when scanned.  In this post, Owen describes the project, links to the current list, and invites you to contribute.  Here at Counter Hack, we’ll be helping out in keeping the list updated with input from the community. Awesome stuff, Owen and Robin!  Thanks for contributing to the community and helping penetration testers.  –Ed.]

By Owen Connolly

So, one day, an interesting discussion started on the SANS pen test discussion list (called the “GPWN” list). Robin Wood (a.k.a., DigiNinja) asked if there was a list of devices maintained anywhere, that tended to hang, fall over, or otherwise behave weirdly when scanned in a penetration test or vulnerability assessment. This excellent request prompted me and several other people to leap in with definitive “No! But I’d watch out for XXX device…”. Those warnings of course led to a lot of similar answers and a few new and interesting ones.  As penetration testers, one of the last things we want to do is inadvertently break things in a target environment by running a simple port or vulnerability scan.  A list of stuff to watch out for would be very helpful to people.

After letting the ideas, warnings, and tales of woe run for a while and having a couple of chats with Robin, we agreed to compile our findings so far and also ask in a few other fora  for other examples of things. We then took all the submissions and put them in a spreadsheet on Google docs and have agreed to maintain this list going forward.

Without further adieu, we’d like to announce…

The Network Scanning Watch List

This list contains reports of unusual negative behavior (such as crashing, freezing, or massive performance hits) suffered by various devices while under common port and vulnerability scans.  The list includes the vendor, product, scanning tool (if such information is available), the impact, and some comments.

The list can be found here

We would very much like to keep this alive and for that reason, we have set up a Google group/mailing list at!forum/netscanwatch. We hope people will use this group to help keep us informed of any new devices they come across and also sharing additional advice.

We hope it helps a few of you out there and that maybe some of the vendors/manufacturers involved would be interested in figuring out why their stuff doesn’t like being scanned! We welcome input from all directions…

Thanks also to Ed for offering to publish this through the SANS Pen-test blog.  As we started from the GPWN mailing list, announcing it here only seems right! Oh, and Ed also offered us the use of his assistant… After clarification, we realised he meant to help us keep the list updated! :-)

Thanks to all who contributed and those who hopefully will!


Owen Connolly

Part 3: Quick and Useful Tricks for Analyzing Binaries for Pen Testers

[Editor’s Note: In part 3 of this series on techniques penetration testers can use to analyze executable files, Yori Kvitchko takes a look at reverse compiling code, with specific tips for Python and Java. They are often chock full of useful stuff in pen testing, and Yori provides a bunch of helpful tips in teasing out their secrets!  –Ed.]

By Yori Kvitchko

In the first part of this series, I discussed analyzing binary files and looking for hints about their communications streams.  In the second part of the series, I delved into the data files that binaries often create.  For the third and final blog post in this series about analyzing binaries, I’ll be discussing some quick and easy techniques for decompiling binaries that don’t compile into raw assembly. I use the term “compiled” here rather loosely. The extent and difficulty of analyzing assembly is outside the scope of this blog post, so what I’ll be talking about is analyzing executable files that are not pure assembly. These executable are either a “compiled” version of an interpreted language, such as Python, or are compiled into byte code and run in a virtual machine such as the Java Virtual Machine (JVM).

Seeing the source code of an application is big. It’s the grand slam of reverse engineering because it gives you pretty much everything about what’s going on inside the program itself. If you can see the entire source code of an application, assuming no trickery such as staged downloads, you know everything the application does. Just having the source code by itself isn’t very helpful though, unless you know what to look for. Not only can source code often be difficult to search through to find what you’re looking for, but it also depends on you knowing the language it’s written in well enough to analyze it. So, what are some easy things to look for in source code that don’t require poring over each line of code?

The usual suspects from my last two blog posts are much easier to look for in source code. Hardcoded passwords, URLs, and even XML or plain text configurations can often be found by searching for with relevant keywords that often appear in variable names such as “pass” or “xml”. On top of that, looking at the source code can also inform the process of analyzing files created by the executable. Often times, encoding or encryption is done with libraries that can easily be seen in source, telling us exactly how we might decode a given file. Furthermore, looking at source code is probably the easiest method for decoding a network protocol. Searching for function names such as “getInt” or “getString” can often reveal the area of the source responsible for decoding a custom protocol.

Now that we know what to keep an eye out for, here are some languages and corresponding tools that will let us get at the juicy source code innards of these executables. Keep in mind though, that there are source code obfuscation tools for each of these languages that can make an executable much harder to analyze with these techniques.


C Sharp is everywhere; from standalone applications, to languages inside of other tools, to web applications. Microsoft’s .NET platform and all related technologies are flexible, relatively easy to code, and therefore used all over the place. With such a large attack surface to work with, as well as a similar need coming from the developer side, it’s no wonder that there are a number of tools that can decompile C# binaries and libraries.

Probably the best of these tools is redgate’s Reflector. It works exceptionally well, rarely fails, and has a number of great features that help in analyzing the resulting source code. The only problem is that it isn’t free. If you need it though, it might be well worth the asking price.

On the free side, we have ILSpy  as one of the top contenders for decompiling and analyzing C#. In addition to having a relatively high success rate in decompiling code, it also has a number of very useful features. First, it allows you browse the code much like you would in a modern IDE. Going to the definition of a function or variable is easy, as is finding all references to them. On top of that, ILSpy allows you to save all of the relevant source code as a series of source files and corresponding project file. This gives you the ability to then browse the source in the editor or IDE of your choice and use tools such as grep to quickly search through it.

Both of these tools will automatically analyze any imported libraries making it easy to see what the analyzed source code is importing and browse through that code as well. I’ve personally used ILSpy to great effect, while trying to replicate a network protocol.


Although losing its popularity a bit in the last few years, Java still has a number of developers dedicated to it and the advent of Android phone development has only strengthened Java’s presence. Much like C#, Java is a byte code compiled language and can often be reverted back to near-original source code. Applications often come packaged in JAR packages, which are little more than zip files of byte code compiled Java code.

With most of the functionality provided by ILSpy for C#, the Java Decompiler  is freely available and does a great job with decompiling Java class files and JAR packages. It allows you to browse the source, find definitions, and save the source code for viewing in an IDE like Eclipse.

Probably the most common use for decompiling Java, other than internal tools, is the analysis of Android applications. For more on this topic, check out SANS Sec 575 which covers analyzing Android apps in detail.


Ever the favorite for small scripts and the occasional Django web application, Python can still be found in the toolkit of many a developer. As an interpreted language, Python has an even looser definition of compiling, but still has a compiled layer in the form of Python byte code stored as “.pyc” files. These pyc files tend to be much more easily reversible than Java and C# so unless the source has been obfuscated you can almost always retrieve the exact source code made to create the final executable.

There are a number of tools that can perform the necessary decompile operation, but my personal favorite is It’s easy and it works, but it only supports up to Python version 2.6. For later versions, check out unpyc and unpyc3.

Although decompiling is great, there is actually an even cooler alternative for getting at the innards of a Python script. Because Python is an interpreted language, interacting with it can be done in a much more dynamic fashion. For example, the python interpreter can be executed with the “-i” option. What this option does is executes the given Python script then, without clearing any state, immediately gives you a Python prompt. This prompt then allows you to run any Python command inside of the environment left over by the Python script. What this means is that any variables stored by the script can be accessed with a simple print statement, and any functions can be called at will. Both are discoverable and listed by using the dir() function. That’s quite a bit of power just from using the built in features of the Python interpreter.

$ python -i
>>> dir()
['__builtins__', '__doc__', '__name__', '__package__', 'secret_variable']
>>> print secret_variable
secret value

That’s it for my series on analyzing binaries. Any other languages I didn’t cover will typically fall into the byte code category such as C# or the interpreted category such as Python, so a bit of Googling will often reveal tools that fill a similar function for those languages.

I hope those of you who are new to the subject learned a little bit to get started with and bypass that mental barrier of thinking that reverse engineering requires you to know assembly. For any experts reading, I hope you picked up a trick or two as well. Thanks for reading and as always, happy hacking!

–Yori Kvitchko
Counter Hack

Call for Speakers: SANS Pen Test Hackfest Training Event and Summit

SANS Pen Test Hackfest Training Event and Summit

Call For Speakers – NOW OPEN!

Summit: November 7-8, 2013
Post-Summit Courses: November 9-14, 2013

The Dupont Circle Hotel
1500 New Hampshire Avenue NW
Washington, D.C. 20036, USA
(202) 483-6000

The SANS Pen Test Hackfest Training Event and Summit is an ideal way to take your penetration testing and vulnerability assessment skills to an entirely new level, as an attendee or as a speaker. Featuring top-rated, industry-leading experts sharing their best tips and advice, this must-attend event is focused on building your skills to provide high value in your penetration testing and vulnerability assessment work. Other hacker and pen test conferences cover interesting hacks, but only the SANS Pen Test Hackfest is focused on imparting skills you can directly apply to your next project.

With two days of in-depth Summit presentations followed by your choice of SANS top-rated six-day penetration testing courses, the SANS Pen Test Hackfest Training Event and Summit is the place to be in November in Washington, DC.  The five best reasons to attend this event are:

  • Lots of NetWars: This event will include FOUR full evenings of NetWars hands-on Capture the Flag challenges, doubling the amount of NetWars time over a traditional SANS conference.
  • Coin-a-palooza: For participants who have taken a given SANS course in the past, but have not won the Capture the Flag challenge coin for that course, this event will offer the ability to catch up on the coins by participating in the four nights of NetWars challenges.  You’ll have an opportunity to win up to 4 challenge coins for your collection.
  • First CyberCity Missions ever at a SANS Event: The SANS CyberCity project helps teach cyber warriors that computer and network activities can have major kinetic impact. With its power grid, traffic lights, and water reservoir included in a physical model city, participants access and gain control over these assets, preventing attackers from wreaking havoc. This event will include a full evening session of CyberCity missions, the first time SANS has offered access to CyberCity at a conference!
  • Summit: Two full-days of in-depth presentations chock full of cutting-edge penetration testing topics focused on helping you provide technical excellence and real business value in your vulnerability assessment and penetration testing work.
  • Training: Six days of deep SANS training in real-world penetration techniques you can use immediately when you return to your job, with classes including network pen testing (560), advanced pen testing, exploits, and ethical hacking (660), mobile device security (575) and advanced web app pen testing (642)

More details about this truly special event are available at:

The SANS Pen Test Hackfest Training Event and Summit Call for Speakers is now open. If you are  interested in presenting or participating on a panel, we are looking for:

  • innovative tips & tricks,
  • useful and powerful techniques,
  • and user-presented case studies…

…All with communicable lessons that attendees can apply directly in their penetration testing and vulnerability assessment work.

The Pen Test Summit offers speakers opportunities for exposure and recognition as industry  leaders. If you have something substantive, challenging, and original to offer, we urge you to submit a talk proposal.  Reasons to present at this event include:

  • Promotion of your speaking session and company recognition via the Pen Test website  and all printed materials.
  • Visibility via the Pen Test post-event presentation email link for many months following the Summit.
  • Badge to attend all 2-day Summit sessions.
  • Private speaker lunch.
  • Speakers may also be recorded and made available via the Internet to a wider audience  (at the discretion of SANS).

If you are interested please send the following:

Author Name(s)
Author Title
Speaker Contact Information
Address, phone number, email address

Your biography should be approximately 160 words. You may include your current position, titles, areas of professional expertise, experience, awards, degrees, personal information, etc.

The presentation abstract should outline your presentation and what attendees will learn. All content must be strictly educational.  Also, the presentation should be relevant to penetration testing techniques and approaches in enterprise environments, with ideas and skills that can be directly applied in pen test and vuln assessment projects.

Session/panel length: 60 minutes
Presentation: 50-55 minutes
Question & Answer: 5-10 minutes

 Call for Speakers – Now Open 

Submit your submissions to  by July 5th, 2013.

Invasion of the Network Snatchers: Part 2

[Editor’s Note: In this follow-up article, Tim Medin continues the discussion of pen testing network devices via the Simple Network Management Protocol (SNMP).  He provides really helpful hints and tidbits throughout! Please check it out.  –Ed.]

By Tim Medin

In our last episode,   we attacked network gear via SNMP.  We scanned for SNMP-accessible devices.  Then, we developed a good, fine-tuned word-list dictionary and used it to guess a valid read-write community string (the “password” that allows access via SNMP). With this community string, we were able to retrieve the configuration from a Cisco device. We have a running configuration… now what? First: PASSWORDS!

With cipher-text password representations in the configuration file, the obvious approach is to crack them to determine the clear-text passwords. But how does Cisco store passwords?

Cisco stores passwords in four ways:

Type 0: This is an unencrypted password, there is no need to crack it.

Type 7: This password is stored with reversible encryption using the Vigenere cipher and the key dsfd;kfoA,.iyewrkldJKDHSUBsgvca69834ncxv9873254k;fg87. There are many online tools to reverse this password, or you can use a local cracker such as     ciscocrack by THC. All of these tools will quickly give you the cleartext password by simply reversing the cipher operation.

Type 5: This is a properly hashed and salted MD5 hash and is currently the most secure storage mechanism on Cisco devices. This password type can be attacked with John the Ripper using the raw-md5 format.

Type 4: This is a SHA256 hash, but it is not salted and it only uses one iteration (check out this  advisory  for details).  Sadly, this format is the reason that Type 5 has been deprecated. Newer versions will support Type 4 but not Type 5, thus eliminating salts and making for a less secure approach.  This password type is not currently crackable by the stable versions of John the Ripper, but the bleeding-jumbo does support the format.

To extract passwords from the config file we can use grep, like this:

$ grep ‘secret\|password\|line\|login\|encryption’

service password-encryption
enable secret 5 $1$X6A6$YyErWuzmkKA9jMm7jURrp2
enable password 7 03275A053F00347E4B081D311F1B18
username billybob password 7 13080E020A1F17
username sallysue secret 5 $1$K9rk$XtLt7Paa9qdW.wJuQB0kR/
line con 0
  password 7 0110090A48040A0A314D5D1A0E0A0516
line vty 0 4
  login local

You’ll notice the configuration above contains “secret” and “password” lines. The “secret” items are stored in a one-way hash format, while the “password” items are stored in a reversible (Type 7) format. “Passwords” are stored this way so they can be used with protocols that require the original password, such as CHAP and ARAP.  If both the enable secret and the enable password have been set, the enable secret takes precedence and the enable password will be ignored.

The configuration can also contain local users (see the username lines).  If the “line” is setup to use “login local”, then the device will require a valid username/password combination for authentication.  If the “line” is configured with “login”, then it will use the associated line password.

In the example above, the console port (con 0) would require the password “consolepassword” and a Telnet, SSH, or HTTP(S) connection would require authentication via billybob or sallysue and the associated password.  But what if the device used TACACS or Radius and we didn’t have admin credentials, or what if the device was setup properly with this configuration?

username toughtommy secret 5 $1$7aYI$Lt3sh3UJM20CGfuhnHuXd0
line vty 0 4
login local

This will require that we use Tommy’s username and password, but he used a really good password. His password isn’t going to crack in our lifetimes. We need another way.

In the last episode, we used SNMP to tell the device to send its configuration to us. We can do something similar to upload a new configuration.  The extremely flexible Cain tool on Windows allows us to upload (or download) the configuration from Cisco devices.  To invoke this Cain functionality, first click the CCDU (Cisco Config Downloader/Uploader) button on the row of tabs.  Then click the + button and enter the target IP address of thee router or other SNMP-managed device and community string.  Finally, click OK to download the file.  At this point, you have the file and you can view it or edit it for re-upload.  It really is that straight-forward with Cain.

To open the file from Cain in a text editor, right click on the file in the center Cain panel and click View. This will open the file in your preferred editor. You can then edit the file to create new configurations to create users, change ACLs, enable services, setup a VPN, or whatever you want, but BE CAREFUL!  While you are editing the config file locally, you will later upload this to the router, and will apply the new configuration.  If you mess this up, you could take down the network.  If the device is using TACACS or Radius, you will see “login authentication somename” so you will need to remove that item to login locally. My edits usually include something like this:

line vty 0 4
  no login authentication someword
  login local
username tinytim privilege 15 secret MyReallyGreatPassword

This configuration will remove the external authentication and create my account that will drop me straight to the enable (privileged) prompt.  Note, this is a secret so it will be hashed once the device receives it, but it will travel to the device in the unencrypted form across TFTP.  After uploading and applying this config, we can login to the device, preferably via SSH (or… shudder… telnet if we have to).  I’ll usually disable logging, if it is allowed by the rules of engagement, by prefixing each of the log related commands with “no” to remove them.

With privilege 15, we will be dropped into the higher privileged Enable Mode prompt immediately upon login.  This allows us to make any changes we want. Depending on the device and its location, I like to do one of two things: setup a VPN connection or modify the VLANs to put myself on another network.

At this point, I highly suggest that you get some experience with Cisco devices or find a partner who has that experience.  You can do some really cool stuff with the network, but you can also do some really bad stuff.  I suggest setting up a lab with come Cisco devices you’ve purchased from Ebay or virtual devices using the dynagen/dynamips virtual network device environment.  Some attacks at this stage take a long description to safely identify and setup.  However, changing your VLAN is pretty simple and is less likely to cause damage, so let’s delve into that.

First, look closely at the configuration for VLANs with descriptions, VLANs with IP address, interfaces with interesting descriptions and the associated VLAN, and the first and last ports (admins usually keep those for special functions). In our case, let’s say we find the following interesting information:

interface vlan 4094
 ip address

This is a VLAN on our device with an IP address.  It is likely a network management subnet that is completely unmonitored and unfiltered.  We can see the devices that are on the same network by pinging the devices on the network.  In our case ping reveals something on (likely the upstream router) and nothing at  We can use one of those IP addresses for our attacking system when we switch networks. To switch networks we need to find our network port and then move it to the new VLAN.

switch1# show mac address-table | i 00:11:22:33:44:55  # i is short for include, similiar to grep
  Vlan        Mac Address         Port       Type
-------- --------------------- ---------- ----------
  284      00:11:22:33:44:55      gi8      dynamic
switch1# conf t                                 # enter configuration mode
switch1(config)# int gi8                        # configure the port we are connected to
switch1(config-if)# switchport access vlan 4094 # switch my vlan

At this point, we are on the same segment as the switch itself.  This will likely allow us access portions of the network that we were unable to access as a normal user with a normal system. We can then change our IP address to and start poking the network. Most of the defenses are protecting traffic into the network management network, not out of it.  Have fun!

–Tim Medin
Counter Hack

P.S. If you’d like to learn more about penetration testing in-depth, you can join me as I teach the  SANS SEC560: Network Penetration Testing and Ethical Hacking at SANS Boston 2013 | Boston, MA | Mon Aug 5 – Sat Aug 10, 2013.  It’s going to be a rocking good time, and I’d be happy to see you there!