Hacking a penetration tester

I just finished reading this article titled “Hacking a Penetration Tester” and made a few notes that I thought may be helpful to pass along.  The basic premise of the article is that the author (Wesley McGrew) and his team were conducting a penetration test and found a Meterpreter shell that had been left behind by a previous tester.  The notes below are in no particular order and are ideally short enough to be read relatively quickly.

  • The offensive security industry right now is effectively the wild, wild west.  In many (most?) cases, the customers requesting a penetration test don’t know what they need or what to expect when the test is complete.  Unfortunately, many of the people / teams / organizations that are doing the work aren’t really sure what a penetration test is either (many are just running Nessus scans, swapping the logo at the top of the report and calling it done).  If you are considering hiring a penetration tester, find out what their process is (an excellent one is the Penetration Test Execution Standard) and confirm that they at least have one.  The more you understand the process, the better you will understand the results (and the more value you will get from them).
  • One of the most important parts of a pen test is the cleanup afterwards.  Making detailed notes and keeping logs of what was done during the test can be used as a ‘checklist’ for cleanup to make sure that nothing (like a live payload) is overlooked.
  • Failure to use best practices like encryption (Meterpreter is the defacto tool for many pentesters [myself included in many cases] and will happily use a non-encrypted channel for communications).  The article mentions creating a meteterpreter shell  as the payload with paranoid mode and other shells (for example, Powershell Empire agents) are encrypted by default.
  • A pen test is, by design, is mimicking aspects of a real attack.  I agree with many of the assertions that McGrew is making but think that it’s worth noting that a client may specifically want a pentester to use some of these tools (TOR, for example) because that may be one of the things that they’re worried about (and they want to see if their blue team will catch it).  If we eliminate everything that could be dangerous from the scope, we’ve neutered the test.
  • Ideally it would not happen but, if a pen tester does get compromised on his or her workstation, that should have no bearing on previous or future engagements.  Our standard operating procedure for any penetration test (or vulnerability assessment, for that matter) is to maintain standard images for our test machines and clone those images for each test.  This gives us a consistent, known-good and uncontaminated baseline to work from (and gives us the best chance that our tools aren’t going to fail during an engagement because of an unsupported configuration, etc.).  A natural byproduct of this is that there is that an engagement has no bearing on previous or future engagements, the tools or each engagement are effectively sterile.

Misc / Errata

Leave a Reply