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 they've never had an actual whitebox security assessment, it's almost certain that they want at least a few of those - there's 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 didn't find in your pentest.

But let's say folks have done the security assessments, they're 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, you're 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 you'll get matching hashes or passwords (pastebin for the win!), but more than a few times I'll get confidential information posted either in their infrastructure or somewhere else, it's 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, you're 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 don't lock any accounts out.  Use Hydra or even Burp (if you're a web person) for this.  You'll 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, you've scanned their perimeter, so you have their VPN gateway/Citrix/Terminal Services/VDI remote access method (whatever they're using - it'll be something).  Try logging in.  Chances are there isn't any 2FA here either.  If that works, the "pen" part of the pentest is done, and you're inside.

What about if they've got 2FA?  Six months ago I'd 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 I'd 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 Rob's 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 I'll get CMD on an inside host.  Be sure that your script doesn't trigger their AV (hint - DON'T 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 you're 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" - you're using normal operating system components and admin tools to move around the network.  Any log entries you create shouldn't 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 you've spent 2-3 days getting pretty much everything, you get to spend 2-3-4 days writing a report about it.  You'll 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.  You'll 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 hasn't 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 you've done a good job on the report, at least one or two of the pricier fixes (2FA maybe) are already being positioned for next year's budget.

What else should be in your report?  A final reminder that this was a Pentest, not an full Assessment.  You likely didn't run scans against every server, workstation and IOT device to find other problems and other ways you might have gotten in.  You likely didn't try VLAN hopping from their guest network to production, you didn't 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 doesn't cover everything, that this is in writing and that they signed that document.

If this sounds a bit high level, it's really meant to be.  I'm 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 isn't really about the tools or the methods - if you think about it, regular users have access, so it's *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