Tuesday, September 29, 2015

NMAPgrapher: A tool to generate graph and other output from NMAP XML files.

NMAPgrapher can be found at https://github.com/attactics/NMAPgrapher

What is it?

A tool I created to assist me in providing supplementary data with my penetration test reports. I'm releasing it to the public to do as you wish with it. The primary purpose of this tool is to allow the user to quickly and easily output exploratory data from NMAP XML files. The tool is capable of generating the following:
  • Most and least common services
  • Most and least common ports
  • Most and least common operating systems
  • Hosts with most and least number of open ports
  • HTML document with tables including each host and open services / ports
Most of the data sets can be output to:
  • PNG
  • SVG
  • CSV
  • HTML
In order to make this tool more useful to others, I have added the ability to skin the HTML output with CSS styles, found in the css folder. In order to generate the included template I used csstablegenerator. If you want to create your own css styles, just make sure to name the css class name 'table'.

SVG and PNG graphs can be styled by modifying NMAPgrapher.py. I tried to use pygal's CSS styles and have a separate file for editing, however cairosvg was not liking it.

Quick Primer on Use

While NMAPgrapher has a fairly extensive help menu, here is the general usage structure:

NMAPgrapher.py [inputFile] [outputBaseName] [outputType]

  • inputFile  is the NMAP XML file you wish to process
  • outputBaseName is the base name of the output files. All output files will be placed in a subfolder from where you ran NMAPgrapher
  • outputType is the type of output you want (csv, png, html, svg)
The default behavior is to produce all possible outputs for the output type specified. Some outputs such as the host lost detailing all open ports and services is only output in HTML for the time being. This will automatically be output in HTML regardless of the type you specify.

There are also a number of optional flags to only output certain types of data, for more information on these please invoke NMAPgrapher.py -h. They should be pretty straight forward.


NMAPgrapher requires a number of libraries to operate. I recommend using pip to install them. You can install them with pip like so:
pip install pygal cairosvg cssselect tinycss lxml elementtree

Bugs and Feature Requests

I'm not a python ninja (...yet?). I know the code is not the prettiest and I will work on refining it as time allows. If there are any bugs or feature requests, please message me on twitter (@evasiv3) and I'd be glad to help.

Sample Graph and Table Screenshots

The following are two example outputs from NMAPgrapher. The visuals are customizable.

Tuesday, September 8, 2015

Tool Spotlight: Eyewitness

If you have ever had to conduct a large penetration test, you know just how daunting it can be when you finish port and service scanning and start looking at all the data. While I strongly recommend learning some python to help sift through data, I wanted to highlight a tool that I've used in the past for grabbing screenshots of various running services en masse.

EyeWitness, developed by Chris Truncer, is a handy little tool that allows you to quick and efficiently grab screenshots from various services, including:

  • RDP
  • VNC
EyeWitness is able to run on both Windows and *nix platforms and provides a number of scanning configurations and reporting options.

As we all know, it can be quite tedious hitting all these services by hand to weed out the interesting bits. EyeWitness does all the hard work for you, allowing you to spend your time reviewing the output for interesting findings.

I've personally found this tool especially effective for quickly identifying administration interfaces of devices that aren't commonly picked up by vulnerability scanners such as SCADA / ICS infrastructure.

A full HOWTO on using the tool is provided by Chris Truncer here.


Monday, September 7, 2015

Extracting Hashes & Plaintext Passwords from Windows 10

Windows 10 is here. Well... it's sort of been here for some time, but it's fully rolled out now and soon we will begin to see enterprise adoption. I, like I'm sure many others out there, have been playing with Windows 10 in a virtual environment the last few weeks. My motivation has primarily been to understand how the game has changed with respect to my standard set of tools. In this blog post we will only be discussing my findings in relation to hash and plaintext password extraction.

We all know the value of windows password hashes and the fun they let us have via pass-the-hash attacks! If you aren't aware, I strongly recommend looking in to it. Now, I prefer having the actual password whenever possible, but hashes will suffice if that is all I can get. Naturally, I put a number of my usual suspects up against Windows 10 to see how they would perform:
  • mimkatz 2.0
  • wce 1.42 beta
  • fgdump 2.10
All testing was performed on Windows 10 Pro x64.

mimikatz 2.0 alpha x64 output

wce 1.42beta x64 output

fgdump 2.1.0 output

The results:
  • mimkatz 2.0
    • We can dump hashes, but not plaintext passwords
  • wce 1.42 beta
    • Does not seem to dump hashes or plaintext passwords
  • fgdump 2.10
    • Works as expected and dumps our hashes

In general, this isn't really too bad. We have our hashes and we can either crack those and use them in pass-the-hash attacks... but no plaintext passwords? Boo!

I decided to poke around on the internet and consult some friends to see if they had stumbled upon any interesting tools that are capable of dumping plaintext passwords on Windows 10. This is how I discovered a set of tools created by Pierre-Alexandre Braeken called PowerMemory. Of particular interest was a PowerShell script called Reveal Windows Memory Credentials (RWMC).

I grabbed the RWMC from github (link here) and threw it at my test VM.

Note: You must first execute 'Set-ExecutionPolicy Unrestricted -force' within PowerShell in order to allow the script's execution.

The following screenshots demonstrate how to use RWMC to dump plaintext passwords from a local Windows 10 Pro x64 machine, although they should not really differ on any other Windows operating system.

Running RWMC

Interestingly, the tool advises that a registry key was set and a reboot is needed. I took a peak at the script to find this:

Ah, here we can see that a registry setting for storing credentials in plaintext for the WDigest provider, is being set to 1. I haven't mucked with any of the settings on this Windows 10 Pro install, so UseLogonCredential being set to 0 must be default behavior on Windows 10. After looking in to the matter some more, this seems to be the case at least going back to Windows 8.1.

Let's try RWMC once more, after the registry modification and reboot.

This looks better... and our results are:

Alright. So that worked - nice! RWMC has a number of other features including the ability to dump passwords remotely and to retrieve passwords from dumps. More information can be found here.

The one thing that threw me off was having to reboot if the registry setting wasn't enabled. This can be quite an inconvenience, but I haven't found a way around it with the limited testing I have performed.

But now that we have the registry setting enabled, lets throw mimikatz at it again and see what happens:

There we have it. Mimikatz is also now able to dump the hashes without issue. Interestingly, in my tests, WCE was still failing.

It's more or less business as usual:
  • mimikatz
    • enable the UseLogonCredentials registry setting
  • RWMC
    • enable the UseLogonCredentials registry setting
  • WCE
    • doesn't seem to work all around, in my quick tests anyways
  • fgdump
    • Works as expected. No registry tweaks needed, but then again it's not interacting with WDigest.
Interestingly enough, Windows Defender did complain about the tools why they were being executed, but did not stop any of them from executing.

Thanks for reading,

Thursday, September 3, 2015

Providing Value In Your Penetration Test Reports: Part 1

So, you've pwned all the things, you have the keys to the kingdom, and you've pilfered all the data. You've done a great job, and now you're done right? Wrong.

I've been working in the offensive side of the infosec space for some time now, and I've seen a number of competitors' reports come across my desk; some pretty darn good and others... well.. pretty terrible. To be quite honest, there was a time where my reports were pretty terrible too... but one day a client asked me a question that started to make me think.

It was 5 or 6 years ago. I had pretty much just finished a penetration test similar to the one I just described above, managing to gain access to the entire organization. I tediously documented a long report full of vulnerabilities and sent it off to the client. As usual, we had a call a few weeks after to discuss their thoughts and close out the project. The client was a bit distraught on the phone. They were happy that I was able to bring all of these vulnerabilities to their attention, but they made a few comments that stuck with me; What does this all really mean? Where do we start? Will this fix our problems and make us more secure?

Now, you might think that is pretty obvious. It means your security is terrible and you should start at the beginning (duh!) and then all your problems will be solved, right? Well maybe... but there is a lot more to it. I tried to put myself in my client's shoes, doing my best to understand what they might be thinking when they read my report. With that mindset, I sat down and read through the report myself. It wasn't before long that I could see what the client meant. My report was full of technical detail, a brief executive summary that outlined the top vulnerabilities and that was pretty much it.

This started me a down a path of trying to analyze what a client is really trying to achieve when they have a penetration test performed, and consequentially how I can provide them the good value for their money.

Now is a good time to bring up an important point, the report you produce at the end of your penetration test is the only tangible artifact that you leave with the client. It doesn't matter how good you were technically or how much you pwned them, if your report is garbage, you aren't providing a valuable service, period. The report is one of, if not the most important parts of the penetration test.

So, let's talk about some important considerations in producing a penetration test report that is provides some real value to your clients...

Know Your Audience

Understanding who will be digesting your penetration test report goes a long way in terms of knowing how to communicate your findings to your client. If the report is going to be consumed by someone at the director level and all you have in your report is technical vulnerability detail, they probably won't read 90% of it, and worse off, they probably won't see any real value.

But we're trying to write a great report here, not just one targeted for a specific audience. With that in mind, I propose the following three audience types your report should address.

Technical Audience

This audience is pretty straight forward. They usually don't care about pretty graphs or sexy templates. They aren't afraid to roll their sleeves up and get their hands dirty, they want to know your findings in all of their technical glory and gruesome detail.

Managerial Audience

This audience is a little harder to nail down, as they can vary a bit, in general though, most of the managerial audience is interested in the 'dashboard' view of the results. They don't really care about the technical details, they might peak at a few findings, but they are mainly interested in getting situational awareness.

Strategic Audience

This audience is focused on strategic initiatives and are usually in the executive / director seat. They generally don't care about CVE-2099-1337 or how you managed to shell the thing with some other thing. This audience wants to know what strategic changes they can make in their organization to decrease vulnerability, and consequentially risk. They want to know about root cause problems, not vulnerabilities.

Now is another good time to stop and make something clear: vulnerabilities are not the real problem. It took me a while to realize. It wasn't until I had been penetration testing for a few years before I finally understood this. If you perform penetration tests for the same client over and over again, you start to see a pattern. You find vulnerabilities, they fix them. You come back again, and find some new vulnerabilities, and they fix them. This process continues forever. Why you ask? Well, vulnerabilities are symptoms of another problem, but they are not the over-arching problem themselves.

As penetration testers, we have seen a lot of different networks, clients, and scenarios. After some time of being in this field you start to see things pretty clearly. For example, you perform a penetration test and find that over 100 hosts are critically vulnerable and many to different vulnerabilities. What does this tell you? it's a pretty good indicator that the organization has a weak patch management program. Another example, you find that the systems are patched fairly well, but there are all sorts of security misconfigurations that allow you to abuse functionality and still pwn the organization. This is generally a good indicator that the client has a weak or non-existent configuration and build hardening standard.

Do you see what I'm getting at here? As a seasoned penetration tester, you can infer a lot of systematic issues that are the real problems leading to the vulnerabilities you find. These are the root causes. Fixing these issues is the only real way to make a lasting improvement in the client's environment. I'm not saying that once root cause issues are fixed that you should never perform a penetration test again, certainly not. No matter how good your security program is, there is always room for improvement. That being said, if root cause issues are tackled instead of just focusing on the symptoms (read: vulnerabilities), you will find that overall the security posture improves and critical severity vulnerabilities a) exist for a shorter duration in the environment and b) are less common.

So let's put two and two together. We've talked about target audiences, and about how we can infer some root cause problems. Should we include this stuff in our report? Absolutely, and not only should we bring up the root cause issues, but we should provide at least some high-level guidance on where they can begin to address them. By doing so, we can create a report that speaks to our client on different levels; from the technical to the strategic. And while we are at it, we can include some nice graphs and dashboards in the report to give our managerial audience the situational awareness they need, at a quick glance. If they want to dig deeper, they certainly can, but lets make sure we make the information accessible without having to spend 5 hours reading a report.

Okay, so our great report is going to speak to three different audience types, but how do we organize this information? I'm sure there are a number of ways, but I personally like to structure my reports in such a way that they get more technical the deeper you read in to them. Put the root cause (strategic) stuff up front, the dashboards and graphs (managerial) stuff right after, and then finally start jumping in to the technical rainbow land. This way our strategic audience can leaf through the first few pages, our managerial audience

Connect The Dots

Remember we talked about how you pwned the organization and hacked all the things? Great job... but hold on a second. Let's say you found 100+ vulnerabilities, and you are a great gal / guy, so you go to painstaking lengths of explaining everything in detail to make sure that your client understands each and every vulnerability, and of course how to fix them! You've done a great job, right? I'd say you've done a good job, but there is still room for improvement, young jedi.

Think about it... 100+ vulnerabilities, some of which have write-ups 5+ pages long. How did you go from poking at their external web applications to pwning the entire domain? This is what I mean by connecting the dots. The report should walk the client through the penetration testing process, where did you start? what did you find? what did that lead you to?

I call this an attack narrative. I'm not saying I made up the term, it's just what I call it. When we include this section in our great report, we are effectively narrating the penetration test to the client. This way they can understand our thought process and what we chained together to go from A to Z. Clients often find this detail very valuable as it allows them to understand the steps in a methodical manner.

Group The Things

Don't just dump all the vulnerabilities in to one section. If you performed internal and external testing, looking at both the application and network layers; separate those findings! Your clients likely have multiple individuals who will be assigned to address vulnerabilities. So do them a favor and organize your findings in a logical manner, making it easier for your client to slice up the report and action it within their organization.

I hope you found some of this information useful. At the end of the day, we perform our penetration testing to make a difference, so make sure your reports and the services you provide help to make that difference.

I'll follow up with another blog post shortly. There are some other points I'd like to bring up as well, so keep an eye out for part 2!

happy hacking,