The following thoughtson internal network penetration strategies are drawn from "OPFOR4Ever," which I'll be presenting later this week with my colleague ChrisPogue at Microsoft's BlueHat Security Conference.
Network penetration testers love to complain about theunrealistic scope restrictions that get placed on our work. "Please exclude these IPaddresses." "Please only testbetween 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 atsome point in the past they got burned. A penetration tester locked out user accounts, created an accidentalblack hole in the network, or brought down a production server.
But isn't it ironic that blackhats bent on data theft sorarely cause system outages? Especiallysince modeling blackhat behavior is the inspiration behind penetration testingin the first place? Blackhats place ahigh priority on stealth, naturally. Butnotice that stealth implies safety. If we return to our roots -- modeling realattack scenarios involving stealth -- we get safety for free. By conducting safe tests, consistently, wecan build confidence in our clients to see the artificial constraints as nolonger 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 wheneverour initial discussions bring to light some artificial constraint they intendto 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-criticalsystems 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 willalso be performed in this more realistic mode, and the next pentester to workat these sites will also get the benefits.
The client management skills needed to perfect this craftneed book-length treatment. I am stillvery much a beginner and won't attempt to address those issues here. But here are some technical strategies youcan 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 portscanning is simply unnecessary. We reachfirst for port scans on internal networks either out of simple habit, orbecause we're confused about the purpose of a penetration test. The goal of a typical pentest is todemonstrate a realistic attack that results in unauthorized access to data. It is not to inventory a network forvulnerabilities, and exploit some of them. Beyond being unnecessary, they are the antithesis of stealth, and theycan even be dangerous. Yes, here in2012, a half open SYN can still cause system outages. (Another commonly used technique with ahorrible signal-to-noise ratio is the use of over-the-network password-guessingutilities.)
Instead of active port scanning, use passive networkmonitoring to learn what's happening over broadcast and multicast traffic. If systems are doing name resolution throughNBT or LLMNR, takeadvantage of that. If this leadsnowhere, 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 toencourage local users to authenticate to your servers. Assuming you've done the prep-work to ensureyou get placed on a well-populated user desktop network, chances are good thatat this point you have compromised a user's password.
Now that you have valid credentials, go native. Your victim's desktop will tell you where togo next. Follow the breadcrumbs left bythe valid users as they move about the network. From here on out, as you exploit trust relationships and gain access toever more powerful credentials, you'll carry out all your activities under oneor more of your false identities. Youradversaries' IDS and anti-virus signatures can't help them here, since all youractions are "normal".
One exception to this rule is the need to execute hashdumpers. To avoid detection, first lookto see if your compromised systems consistently enforce anti-malwaredefenses. You may find a legacy serverwith no anti-virus installed, but rich in stored credentials. Also, check the access rights of eachcompromised account. Sometimes you mayfind that your lowly compromised user, not a member of any special-privilegegroups at the domain level, is actually a member of the Local Admins group onevery server. Stranger things havehappened. So only run your hash dumperwhen you have to, make it count, and be sure you've done everything you can toobfuscate your code to avoid detection. If you're not confident your hash dumper won't get detected, considerdisabling the detector. But this goesagainst our next mantra:
Don't change anything.
If you can avoid making changes on a compromised system,avoid it. Don't use your administrativeaccess to create a new account. The onlypurpose 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 fromthe user tables.
Get into the habit of hosting the few obfuscated binariesyou need to execute on your SMB share. Moreoften than not, you can execute them over the network without having to firstcopy them over or to later remember to clean things up. You may ultimately resort to making changes, but save it forthe last resort -- and be sure to log everything you do so that your client canundo it.
In this respect the blackhat's goal is also your goal: your victims should never know you were there.