Penetration Test Phase 6: Post Exploitation

Transcript

Welcome to this edition of A Cup of Joe. We’re still talking about the phases of the pen test, and today we’re up to phase six, post exploitation.

Now, as I’ve said before, I think there are more than just the traditional five phases of pen testing. By my count, there are at least ten. Some of the phases that I advocate don’t always fit into your process or practice, but there is one phase we can all agree on, and that’s phase six, post exploitation. Post exploitation, as I define it as the phase containing those techniques used to acquire situational awareness, maintain reliable reentry, attain privilege, escalation and harvest credentials to pivot and move vertically and laterally. Now, if you want to review my entire list of faces, you can click on the link below to read my blog post introducing all the phases of penetration testing on the Plex Track website. In my practices, phase six was almost always written into the statement of work. Without this phase, you’re really just performing a validated vulnerability scan.

So in my mind, it’s important to push for as many post exploitation activities as possible in your engagements, because hopefully this exercise is the closest your client will ever come to being well and truly hacked. Make everything negotiable and keep as few things off the table as possible. I read a Twitter thread a while back where offensive security practitioners were arguing against the idea of dumping ad password hashes and cracking them. I was kind of surprised. I thought everybody did this. I know that getting ad isn’t always the end of a test. A lot of times it’s like getting a black belt.

It’s only just the beginning. It’s also true that I’ve had a few clients feel a little queasy about letting my team go nuts inside their networks, usually because they had a set of cowboys in there before knocking things over and generally making a mess. You know, I totally get that. If I’m honest, I’ve had my fair share of unfortunate accidents too. Sometimes because I was inattentive, rarely because I was reckless, but mostly because the targets were known to be fragile or risky. And hey, you know what? That’s not entirely fair to the tester if you have assets that, you know, fall over when scanned or are so important to the organization that you haven’t restarted them in five years. I mean, come on.

That stuff is going to catch fire and burn and it will take all of our reputations with it. So before we throw a single packet at a client’s network, we need to have a well documented set of rules of engagement. The rules of engagement define all sorts of things in addition to what not to scan. But for starters, it should always include the success criteria. What constitutes a successful pen test? When are we done? A pen test can keep going and going and going for as long as everyone has the time the money and the stomach to endure it. But you know what? In most cases, there is a clear stopping point. You probably had engagements where the client said, if you get a domain admin, you know what? That’s it, you’re done.

We know there’s nothing in place to stop you at that point. So most of the time, though, you’re targeting a specific goal, a set of assets or a collection of information. Put that in the rules of engagement so the operator knows exactly when to call it quits. From there, you can outline things like what are the testing hours? Who’s your point of contact? What’s their phone number? Do you open a bridge at the start of testing? What do you do if you’re blocked, and how do you handle compromised credentials? And so forth. The rules I hated most included allowing a client representative to observe during the testing of God.

It was the worst when they wanted the sysadmin to be in the room and insisted there would be a monitor in the conference room mirroring my laptop. I don’t know about you, but I forget how to type when there’s somebody watching or hanging over my shoulder. And finally, you should document the limitations. In addition to what systems you’re not supposed to touch. Limitations might include things like no denial of service attacks, no system reboots, no brute forcing of Web email submission forms, or man in the Middle attacks against network protocols like HSRP or BGP. Phase Six generates a lot of information. You’ll be exploiting systems, capturing credentials, plundering through file shares and databases, all the while moving closer to your targets.

A lot of what we do is invasive during this phase, so it’s critical that we maintain logs of our activities and the changes we make to systems. Some exploits aren’t as well behaved as they could be, and they leave remnants behind after execution. We need to be nice to our clients and leave them a list of systems we touched so they know it was us. When six months later, the McAfee AV stumbles across a remnant and declares it a compromise. I used to keep a manual run log. Heck, you might use script to log everything in your Linux terminal. Whatever you use, you’ll have log files, screenshots, and file samples that you need to save as evidence to support whatever conclusions you make in your report.

Having a place to store it all safely and securely is vital. This is where I turn to the Plex Track platform for help. Now, I could have the Sow, the Rules of engagement, the project manager’s engagement notes, my run logs, and my evidence scattered in email and a file share and on my laptop. But if I’m juggling multiple engagement, it’s way too easy to lose track. I keep it all associated with my report and the Flex Track platform. Let me show you. There are a few places where it might make sense to build my document.

For example, I could use the assessment questionnaires, but to be fair, I think the neatest and cleanest is to do it inside of the artifacts. So if I go to my report and I click on artifacts, I can upload my files, text files, word docs, screenshots, whatever, and I can have it here, all at my fingertips. And because it’s stored using the same technologies used to secure the Plex track platforms, I can assure my customers that their data is safe. And I’ll always have it at my fingertips. What could be easier? That’s all the time we have today. Don’t forget to hit the like into subscribe button to get the latest cup of joke content and ideas. My name is Joe Perini, and I’m PlexTrac’s product evangelist Wishing you happy hacking.