(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
 

=============== Rob VandenBrink Metafore

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
 
Django CVE-2016-9013 Hardcoded Password Security Bypass Vulnerability
 
Django CVE-2016-9014 Security Bypass Vulnerability
 
ISC BIND CVE-2016-8864 Remote Denial of Service Vulnerability
 

---
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
 
Adobe Acrobat and Reader CVE-2016-6937 Memory Corruption Vulnerability
 

I recently got asked what does a typical pentest look like?

Actually, it usually starts with some education, where we start by asking the client if they really want a pentest? If theyve never had an actual whitebox security assessment, its almost certain that they want at least a few of those - theres no point in a just like in the movies storm the castle pentest when all the doors and windows are open, and the flashing welcome sign is out. If you do end up having to pentest that sort of company, one of the recommendations in your report should be an internal, cooperative whitebox assessment to find all the things that you didnt find in your pentest.

But lets say folks have done the security assessments, theyre now patching, logging, have a reasonable set of defenses, and have made the business decisions around what else to add and pass on, defense wise. What does a pentest look like then?

First of all, it starts with defining scope and writing a Statement of Work. For the pentester, this is maybe the most important thing in the job. This is what keeps your identity as a security professional instead of as the number on your orange coveralls. Paraphrased from the SANS SEC560 courseware - the difference between a security pro and a criminal is permission ( https://www.sans.org/course/network-penetration-testing-ethical-hacking )

Once you start, are you storming the castle now? Nope, youre doing recon, maybe using open-source intelligence tools like recon-ng or spiderfoot, or maybe just using what comes with Kali (go theharvester! ) and some scripts you wrote yourself (shout out to Johnny Long and his Google dorks research). The goal here is to collect as much info as possible without ever sending a packet to the customer hosts. Often what you get is a list of userids, but sometimes youll get matching hashes or passwords (pastebin for the win!), but more than a few times Ill get confidential information posted either in their infrastructure or somewhere else, its not and uncommon to find an entire Sharepoint wide open and indexed on Google behind their secure login page.

What next, are we storming the castle now? Nope, after a quick scan of their perimeter, youre trying passwords. Put a list together, start with the worst 50 or 100 passwords on the internet (yes, those lists exist). Add the seasonal passwords Spring 2016 Spring16 and so on. Add local sports teams (G0Rapt0rs!). Scrape their website and Facebook page with CEWL for a few more organization specific words. Now use these words as passwords against OWA. Kudos to John Strand BHIS for coining the term password spraying - you want to try each password against all user accounts, and be sure to do only 2-3 at a time, so you dont lock any accounts out. Use Hydra or even Burp (if youre a web person) for this. Youll absolutely get a working login before you get to the end of your nobody would possibly use this for a password password list. What about 2 Factor Authentication (2FA) you ask? The answer is that this is almost never done on mail, it would make for a speed-bump for smartphone users .

What now? Storming the castle yet? Nope, youve scanned their perimeter, so you have their VPN gateway/Citrix/Terminal Services/VDI remote access method (whatever theyre using - itll be something). Try logging in. Chances are there isnt any 2FA here either. If that works, the pen part of the pentest is done, and youre inside.

What about if theyve got 2FA? Six months ago Id have said weaponize an office file with a good macro, email that and wait for a reverse shell. Except that I went to Derbycon this year ( https://www.derbycon.com/ ), and was lucky enough to attend Nick Landers presentation ( http://www.irongeek.com/i.php?page=videos/derbycon6/206-outlook-and-exchange-for-the-bad-guys-nick-landers ). What Id do now is:

  • Connect an actual Outlook client to their autodiscover server, using my working credentials (yes, this works fine on Office/365 too)
  • Create an inbox rule that says when you get an email from Rob, run this executable file on Robs malicious host on the internet. Yes, someone thought that start an application was a good Outlook rule action. I vote we give that person a raise!
  • That executable is a simple PowerShell reverse shell, so Ill get CMD on an inside host. Be sure that your script doesnt trigger their AV (hint - DONT send it to VirusTotal or it will!)

What next? Either way, now you are in - use your credentials to login to whatever that user has access to. Use any of the various Katz tools to pull hashes (hopefully for admin accounts) from memory, and proceed on to pivot-pivot-pivot. Using Powershell (https://www.sans.org/course/securing-windows-with-powershell ) or Powershell based tools (like Powershell Empire and that ilk) is a great help here, you will very likely have domain admin, SQL SA and everything right down to UPS access in a day or less. As soon as possible though, move your base of operations to a more stable host - remember that youre shell is on a workstation, at best you have until 5pm (unless that user is helpful and simply locks their machine at 5). Note that you are still not attacking - youre using normal operating system components and admin tools to move around the network. Any log entries you create shouldnt be distinguishable from what the Helpdesk does on any given Tuesday.

What, no storming the castle? Nope, not even once. Nothing like TV at all. Now that youve spent 2-3 days getting pretty much everything, you get to spend 2-3-4 days writing a report about it. Youll want it to be business-specific, you want to have real recommendations that tie to how you got in and tie that directly to business risk. If you uncover something that might be higher risk, but in their context is not that high, call that out. It needs to be a story about this organization, not a generic company - so you need to write the report, not cut and paste it from your last one. Youll want the doc to be in plain, non-technical language, and certainly less than a few pages. A 5-6 page Powerpoint works too, as long as you can get your point across without going to 12 point font that is. The reader you are speaking to in your report should be in Sr Management, someone who can fix this problem by assigning budget, not the technical person who from your Pentest results hasnt been able to get budget to fix these problems.

The primary goal of this is to leave the client better off than you found them. Fixing the easy / free stuff (better logging maybe, starting users on replacing passwords with passphrases and so on) should already be in progress before you do you are finished the project - or maybe even done. If youve done a good job on the report, at least one or two of the pricier fixes (2FA maybe) are already being positioned for next years budget.

What else should be in your report? A final reminder that this was a Pentest, not an full Assessment. You likely didnt run scans against every server, workstation and IOT device to find other problems and other ways you might have gotten in. You likely didnt try VLAN hopping from their guest network to production, you didnt assess their ecommerce buy our stuff here website for issues or any number of other things. You did exactly what you needed to get from zero to domain admin and obtain access to the crown jewels data - you got what you needed to help convince the client to improve their situation. Be sure that your client knows that your report doesnt cover everything, that this is in writing and that they signed that document.

If this sounds a bit high level, its really meant to be. Im planning to do a how to for each of the steps above - stay tuned at the Storm Center over the next few weeks. But Pentesting isnt really about the tools or the methods - if you think about it, regular users have access, so its *got* to be easy. Pentesting is all about the report at the end - the report that helps the client get things fixed!

Aside from more tool-specific stuff, have I missed anything? Use our comment form and let me know!

===============
Rob VandenBrink
Compugen

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
 
Oracle Java SE CVE-2016-5568 Use-After-Free Remote Code Execution Vulnerability
 
Oracle WebLogic Server CVE-2016-5535 Remote Code Execution Vulnerability
 
Schneider Electric Unity PRO Insecure File Downloading Remote Code Execution Vulnerability
 
Symantec Norton Mobile Security for Android CVE-2016-6587 Local Information Disclosure Vulnerability
 
Symantec Norton Mobile Security for Android CVE-2016-6585 Denial of Service Vulnerability
 
Symantec Norton Mobile Security for Android CVE-2016-6586 Security Bypass Vulnerability
 
Internet Storm Center Infocon Status