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.
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 in 2012, 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.
Related Link:
