How Not to Fail at a Pen Test: Slides and Stream

Earlier this week, John Strand presented a fantastic webcast that was chock full of pen test tips.  This post contains the slides as well as a link to the streaming slides and webcast audio.

Here’s the description of the talk:

In this presentation, John and Ed will cover some key components that many penetration tests lack, including why it is important to get caught, why it is important to learn from real attackers, and how to gain access to organizations without sending a single exploit.

One of my favorite slides in the presentation is John’s concluding Code of Ethics.  Click on the image below to download all of John’s slides.

If you’d like to hear the full audio stream, you can access it here.  Click on the link, login to your free SANS Portal account, and you can see and hear the stream.

On a directly related note, we’ll be running an exciting SANS Pen Test Hackfest event in Washington DC November 13-20, throwing in pretty much everything we have to make for a fun and exciting event, including an evening of missions in CyberCity, 3 nights of NetWars, and chance to earn up to four SANS Pen Test challenge coins.  Click the image below for details on this nifty event.

Thank you!
–Ed Skoudis.

 

Demanding MOAR From Your Vulnerability Assessments and Pen Tests – Slides and Link

A few weeks ago, I did a presentation on Demanding MOAR from Your Vulnerability Assessments & Pen Tests.  I’d like to share the slides with you now.  The presentation is full of tips, some easy and others more complex, for providing extra value in vuln assessment and pen test work.

Here’s the official description of the talk:

You pay good money for your vulnerability assessments and penetration tests, right? But are you getting real business value from these projects? Do you ever get the sense that your assessors and pen testers are just phoning it in, checking off boxes, and not really properly helping you improve your security stance? In this lively presentation, Ed Skoudis will provide hugely valuable tips for getting the maximum business value out of your vulnerability assessments and pen tests. With specific recommendations for people procuring such projects as well as for testers themselves, this webcast is chock full of insights for effective scoping, best-of-breed methodologies, potent communications, and just plain getting the most vuln assessment and pen test bang for your buck.

Here is the slide deck, which you can flip through at your own pace.

Or, if you prefer, here’s a link to the streaming audio and slides, if you’d like to hear me presenting it.  To see and hear it, click on the link at the right, sign in to your free SANS portal account, and you’ll get access to the stream.

Hope you find it fun and useful!

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

 

Dealing with the Many Stages of Pen Test Result Grief – Part 2

By Ed Skoudis

In this series of articles, we’re looking at some of the grief that penetration testers often encounter when they deliver their results and recommendations.  Our premise?  You, a great pen tester, work your tail off to conduct a wonderful, high-value, technically awesome pen test.  The result?  Target system personnel vomit all over your findings, push back on your recommendation, and just plain don’t see the value of what you’ve done.  The series, which began with article one here, focuses on practical tips you can use to avoid such situations up front, or, if they do occur later on, methods for defusing the situation and demonstrating the real value you are providing.

Article 1 in the series sets the backdrop and talks about Stage 1: Denial and Stage 2: We Meant to Do It That Way.  Here in article 2, we’ll pick up where we left off by exploring Stage 3: The Blame Game (Blame the Messenger) and Stage 4: That’s Not FAIR!

Stage 3: The Blame Game (Blame the Messenger)

Target System Personnel Reviewing the Report: “You’ve actually caused the issue at hand by running your freaky-deaky ultra-scary hacking tools.  Something like that would never happen in a real-world attack.”

This complaint sometimes comes from target system personnel not understanding how widespread and common hacking tools are today and the value they can provide in actually improving security.  You can hardly blame them.  For some people outside of the information security community, hacking tools are mysterious, edgy, voodoo magick.  Compounding the problem, many penetration test reports reinforce the voodoo magick misperception, because they don’t go into any details about how the tools found or exploited the flaw.  In my work reviewing pen test reports, I see a lot of deliverables that blurt out critical findings as though they just fell out of the sky, with little information for target system personnel to understand the true nature of the risk they face.

To head this one off in advance, you as the penetration tester should try to help educate target system personnel by including some relatively small but very important details in your report.  Make sure your report includes the names of the tools you used during the test for each finding.  Also, for particularly critical findings, explain at a high-level the underlying technique your tool used to discover the finding, along with how common that technique is applied in the wild.  Explain how real-world attackers use the same or similar tools to exploit these kinds of flaws every day.  Your goal is to make the critical issues you’ve discovered real to your report readers, tying them to real-world threats.  These small tweaks to your report will not only help inform target system personnel about the validity of your findings, they will also help them better understand what they are up against in defending their environments.

That’s one form of the Blame Game that pen testers may encounter.  We’ll see another variation of the Blame Game in a follow-up article in this series, where target system personnel blame not the pen testers, but another organization or entity outside their control.

Stage 4: That’s Not FAIR!

Target System Personnel Reviewing the Report: “Well, well, well… Sure you can come up with such findings if you cheat. The only way someone could discover such a flaw is by utilizing some super secret inside knowledge, which we gave you in good faith at the outset of the pen test before you betrayed us, Benedict Arnold.  No real bad guy would ever be able to figure that out and mount such an attack.”

Here’s a classic response that comes up surprisingly often.  During the initial scoping of the project or during project update debriefings, target system personnel will almost always share information that proves extremely useful in finding juicy flaws during your penetration test.  They might mention an architectural problem, a broken process, a particularly weak system, or more, allowing you to find and exploit the crap out of the target environment.  When you report on your results, sometimes target system personnel turn on you and say, “That’s not FAIR!”

To deal with this, I always start a project by talking with target system security and operations personnel trying to defuse an inherent conflict.  You see, target system personnel sometimes fear pen testers (as they worry that we may accidentally break something like a bull in a china shop), and other times they just plain loathe us (as we look through their work to find flaws which could get them in trouble).  This mix of fear and loathing can make for… er… rather complex emotions during the test, to put it lightly.  At the outset of a project, I usually say in a nice way, “Look, we both have the same goal – to help improve the organization’s security and its operations.  Let’s work together to make that happen.”

I go even further, saying, “You know this environment better than I ever will… I’m sure there are some things you know that would help improve security, but you haven’t been able to get management to invest the resources needed to do so.  Use me.  I can be a vehicle by which you can move your organization to improving its security stance, if we work together.”  It’s a sincere pledge on my part, and being explicit about it up front can help you identify important issues early on during a project.  You are planting the seeds for a good working relationship with target system personnel so that you don’t find yourself with a “That’s Not FAIR” claim.

Then, of course, when you write up the report, you should point out those issues that were identified during the beginning of the project, emphasizing the importance of the issues and their associated defenses.  Only mention that you learned of the issues from the in-house team if the individuals on that team have agreed to such a mention.  You also have to show, in your report, how a real-world bad guy could find and exploit the security issue that was, for your pen test, kind of a “gimme” by target system personnel.  Help them to understand how real-world attackers working over months may find this same issue, which you modeled in your penetration test over the course of a week or two.

Even if you do all of this flawlessly, you may still hear a cry of “That’s Not FAIR!”  If this happens to you, remember to keep calm and never get your back up.  You are in the right, as long as you’ve stayed within scope, followed your rules of engagement, and utilized real-world attack techniques.

Here’s what I like to do when this occurs: When someone claims, “That’s Not FAIR,” I translate them in real time, in my head, using an internal voice that sounds like a bad voice over from an old kung fu movie to, “You have bested me with your impressive kung fu, and I congratulate you on your success. Please help me understand how you have done this great feat so that I can improve the security of my enterprise.”  Yeah, it’s a little wordy replacement for “That’s Not FAIR,” but it helps me smile instead of reacting negatively.  You can then proceed calmly to explain how a real-world attacker would find the associated issue using publicly available tools and information, along with your recommendations to help improve the organization’s security stance.

So, that’s Stage 3 and 4.  In part 3 of this series, we’ll discuss some tips to use when dealing with Stage 5 (“I don’t think that finding means what you think it means”) and Stage 6 (“Scope-a-Dope”).  Please stay tuned.

In the mean time, if you are interested in all things penetration test related, I’d love to see you take the SANS Security 560 course from me.

–Ed Skoudis
SANS Institute Fellow
SANS Penetration Testing Curriculum Lead
Author and Instructor, SANS Security 560: Network Pen Testing & Ethical Hacking

Upcoming SANS Special Event – 2018 Holiday Hack Challenge

KringleCon

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
kringle_02

Data, Data, Everywhere – What to do with Volumes of Nessus Output

[Editor’s note: Here’s a really nice article by Kevin Fiscus on a tool that’ll help you analyze and manage a great deal of Nessus vulnerability scanner output.  This is really helpful, cool stuff!  Thanks, Kevin.  –Ed.]

By Kevin Fiscus

Doing really good, high-value penetration testing is hard. You have to start with a solid, repeatable methodology on which you build a process implemented via tools and techniques. It is a technical endeavor that is, more often than not, remarkably creative.  But, to do it well, you need to understand hacker techniques, cyber defense, protocols, packets, and even people. Sometimes, however, basic logistics get in the way. The problem, in many cases, is that the tools are simply too good, or rather, they give too much information but lack a particularly effective way for a penetration tester to use that information. Case in point: Nessus.

Nessus is a fantastic vulnerability scanner. It has the capability to perform both credentialed and uncredentialled scans of target environments, and test for tens of thousands of vulnerabilities across an enormous range of platforms. For the budget conscious among us, it is also one of the more cost effective commercial solutions on the market. Unfortunately, while superior in many ways, it is not known for its reporting capabilities. Tenable Network Security, the creators of Nessus, have additional products to provide more advance reporting capabilities, but purchasing them changes the cost structure considerably.

The problem, thus, is one of data overload from any vulnerability scanner, including Nessus. Particularly when performing internal, credentialed scans against network resources, the amount of data generated can be overwhelming. While generally presented in an easy-to-understand format, the data you’ll be given includes each vulnerability individually. Nessus has the capability to view results by IP address or by vulnerability, so identifying the most vulnerable server by vulnerability count or the most common critical severity vulnerability is fairly easy. But what if you wanted to identify the most vulnerable server in terms of the common vulnerability scoring system (CVSS), or wanted to count the number of servers with at least one high or at least one critical severity vulnerability? These things can be difficult within the Nessus interface and are more difficult when looking at Nessus output reports. Fortunately, there are answers for nifty and high-value ways to slice and dice Nessus results.

Nessus has the ability to output reports in a variety of formats, one of which is XML. This has allowed the security community to create tools to parse Nessus results and convert them into a variety of other formats. The one I tend to like can be found at http://www.melcara.com and is called, very originally, “Nessus Parser.” The current version, as of the writing of this posting, is v20a.  And, it’s free.

The Melcara Nessus Parser is a Perl program that converts Nessus XML output into a Microsoft Excel workbook. It doesn’t just create a CSV file with basic scan results, it creates an entire workbook consisting of over TWENTY tabs. A brief tour of at least a few of these tabs will help illustrate the benefits of this tool.

The “Home Worksheet” tab contains summary information about the numbers and counts of vulnerabilities and vulnerable systems as shown below:

The “CVSS Score Total” tab includes, for each IP address scanned, Common Vulnerability Scoring System results and allows you to tune the final scores by introducing a score modifier. By changing the value of a few cells, you can increase the contributing factor of a medium severity from 1 to 1.25, a high severity to 1.5 and a critical to 1.75 (or any value you want). The spreadsheet has been formatted to allow easy sorting on any column.

A series of five tabs labeled Critical, High, Medium, Low, and Informational provide counts and details for each identified vulnerability. For each tab, it lists the type of vulnerability (plugin family), the vulnerability name (plugin name), the number of instances of that vulnerability identified, a description of the vulnerability, the recommended solution, and whether there are exploits for the vulnerability included in Canvas, Metasploit, or Core Impact.  That last tidbit is really cool and helpful for penetration testers looking to move from scanning into outright exploitation of target systems.

The “Device Type” tab provides the IP address, fully qualified domain name, NetBIOS name, and device type for every tested system while the “HostConfigData” tab provides the number of vulnerabilities by severity for each IP address. This tab also provides information about minimum password length, password history length, minimum/maximum password age, complexity requirements and account lockout information if credentialed tests were run. The “portScanData” tab contains information about listening ports and services for each IP address while “InstalledSoftwareData” provides information about software identified to be installed on each target system.

The “UserAccount Data” tab provides information about user accounts found on each tested system, including where the account was found (local or Active Directory), the account name, and the SID and the type of account (e.g. Domain User, Domain Administrator, etc.). This tab also includes information about whether the password for the account has ever been changed, whether the account has been disabled, whether it has ever logged in, and information about certain group membership. Additional tabs provide information about Wireless Access Points and SSIDs detected, passed or failed compliance or policy checks, and various summary information.

Other than the “Home Worksheet”, all of the tabs are formatted to allow for filtering and sorting of the data in any column, and because the data is in Excel, the workbooks can be expanded with graphs, charts, pivot tables, etc. That’s pretty sweet.  Also, got a whole bunch of Nessus results from several scans against several target environments?  The Melcara Nessus Parser has the capability of taking multiple Nessus XML files as input, and track which file the results came from, for each row of data presented. Thus, if you wanted to scan five different locations individually, you could look at their results individually, as a whole, or any subset thereof.

Getting the Nessus Parser to run can be somewhat challenging. You, of course, need to install Perl and there are a whole set of CPAN modules that need to be installed for it to run. That said, it is my experience that the author of the tool is extremely helpful, should you run into problems. Once everything is set up, running the tool is easy and involves these steps:

Step 1: Export the results of your Nessus scans in XML (or .nessus) format
Step 2: Place all the XML files into a directory
Step 3: Execute the command “perl parse_nessus_xml.v20a.pl -d <directory>” where the directory is the location of the XML files.

The parser will look at all of the files in the selected directory, identify those that contain Nessus output, and generate an output report based on provided input. There are a couple of additional command line switches that can be used to control the output:

  • The default output file will be called “nessus_report_XXXXXXXXX” where the X’s will be replace with data and time information. If you want to change the prefix of “nessus_report” to something else, you do it with the -o option
  • If you want to run the tool against an individual file instead of a directory, you can use the -f <filename> instead of -d <directory>.
  • The -r option allows you to change the severity of individual Nessus plugins by plugin ID.

The Melcara Nessus Parser can be of tremendous value in reviewing, sorting, analyzing and working with Nessus output. As a penetration tester, the ability to identify the most vulnerable targets or to find that one obscure vulnerability is awesome. As a defensive security professional using Nessus to attempt to improve security, the ability to take the output from a scanning tool like Nessus and truly work with the output is amazing.

If you are new to vulnerability scans, Nessus and/or penetration testing in general, or if you have been doing this type of thing for a while and want to take your skills to the next level, you will definitely want to check out SANS SEC560: Network Penetration Testing and Ethical Hacking. This course not only teaches you cool hacker tools and techniques, it also provides you with an industry proven methodology that ensures your penetrations tests provide real business value.

–Kevin Fiscus
SANS Certified Instructor

UPDATE: Diligent reader Vikneswaran Kunasegaran (@SecurityBazinga) noticed that the Melcara script didn’t work on Kali Linux (and possibly some Debian systems) due to some missing dependencies.  He wrote a handy little script that automatically pulls down those dependencies and gets your system ready.  You could do what the script does manually, if you’d prefer, or just copy and paste it into a file, chmod it so that it is executable, and run it.  Thanks, Vikneswaran.  Nice work!  Here’s the script:

#!/bin/sh
#install dependencies for running nessus parser melcara.com#

#update#
sudo apt-get update

#install dependencies#
sudo cpan install XML::TreePP
sudo cpan install Data::Dumper
sudo cpan install Math::Round
sudo cpan install Excel::Writer::XLSX
sudo cpan install Data::Table
sudo cpan install Excel::Writer::XLSX::Chart

#Thank you Have Fun!#

Upcoming SANS Special Event – 2018 Holiday Hack Challenge

KringleCon

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
kringle_02