The following thoughts on internal network penetration strategies are drawn from "OPFOR4Ever," which I'll be presenting later this week with my colleague Chris Pogue at Microsoft's BlueHat Security Conference.
Network penetration testers love to complain about the unrealistic scope restrictions that get placed on our work. "Please exclude these IP addresses." "Please only test between 1 and 5 AM Pacific Time." "Layer 2 attacks are out of scope." These are familiar refrains. But we have only ourselves to blame.
Our clients place these restrictions on our work because at some point in the past they got burned. A penetration tester locked out user accounts, created an accidental black hole in the network, or brought down a production server.
But isn't it ironic that blackhats bent on data theft so rarely cause system outages? Especially since modeling blackhat behavior is the inspiration behind penetration testing in the first place? Blackhats place a high priority on stealth, naturally. But notice that stealth implies safety. If we return to our roots -- modeling real attack scenarios involving stealth -- we get safety for free. By conducting safe tests, consistently, we can build confidence in our clients to see the artificial constraints as no longer necessary, and our tests will better model real-world risks.
This isn't just a pipe dream. I've been doing it.
Certainly not with every client, but whenever our initial discussions bring to light some artificial constraint they intend to place on the scope or ground rules, I do my best to bring them around. I've convinced clients to allow testing 24x7when before they mandated specific time windows, to allow mission-critical systems to be in scope when before they were excluded, and to allow Layer 2attacks (e.g., ARP cache poisoning) when before they were prohibited. And since my tests were concluded safely --there was no impact to system availability due to my efforts -- future tests will also be performed in this more realistic mode, and the next pentester to work at these sites will also get the benefits.
The client management skills needed to perfect this craft need book-length treatment. I am still very much a beginner and won't attempt to address those issues here. But here are some technical strategies you can use to adopt a "safety first" mentality for internal network pentesting.
Make every packet count.
Port scanning is for losers. The signal-to-noise ratio is horrible, and in many situations port scanning is simply unnecessary. We reach first for port scans on internal networks either out of simple habit, or because we're confused about the purpose of a penetration test. The goal of a typical pentest is to demonstrate a realistic attack that results in unauthorized access to data. It is not to inventory a network for vulnerabilities, and exploit some of them. Beyond being unnecessary, they are the antithesis of stealth, and they can even be dangerous. Yes, here in2012, a half open SYN can still cause system outages. (Another commonly used technique with a horrible signal-to-noise ratio is the use of over-the-network password-guessing utilities.)
Instead of active port scanning, use passive network monitoring to learn what's happening over broadcast and multicast traffic. If systems are doing name resolution through NBT or LLMNR, take advantage of that. If this leads nowhere, use ARP to intercept unicast traffic. If database traffic isn't encrypted, take advantage of that. If that doesn't pan out, use other tricks to encourage local users to authenticate to your servers. Assuming you've done the prep-work to ensure you get placed on a well-populated user desktop network, chances are good that at this point you have compromised a user's password.
Go native.
Now that you have valid credentials, go native. Your victim's desktop will tell you where to go next. Follow the breadcrumbs left by the valid users as they move about the network. From here on out, as you exploit trust relationships and gain access to ever more powerful credentials, you'll carry out all your activities under one or more of your false identities. Your adversaries' IDS and anti-virus signatures can't help them here, since all your actions are "normal".
One exception to this rule is the need to execute hash dumpers. To avoid detection, first look to see if your compromised systems consistently enforce anti-malware defenses. You may find a legacy server with no anti-virus installed, but rich in stored credentials. Also, check the access rights of each compromised account. Sometimes you may find that your lowly compromised user, not a member of any special-privilege groups at the domain level, is actually a member of the Local Admins group on every server. Stranger things have happened. So only run your hash dumper when you have to, make it count, and be sure you've done everything you can to obfuscate your code to avoid detection. If you're not confident your hash dumper won't get detected, consider disabling the detector. But this goes against our next mantra:
Don't change anything.
If you can avoid making changes on a compromised system, avoid it. Don't use your administrative access to create a new account. The only purpose this serves is to alert the defenders that something is up. If you've hijacked a database connection, don't begin by adding a new user. First, make sure the database isn't storing your target data. Second, attempt to read password hashes from the user tables.
Get into the habit of hosting the few obfuscated binaries you need to execute on your SMB share. More often than not, you can execute them over the network without having to first copy them over or to later remember to clean things up. You may ultimately resort to making changes, but save it for the last resort -- and be sure to log everything you do so that your client can undo it.
In this respect the blackhat's goal is also your goal: your victims should never know you were there.
