Trustwave SpiderLabs Uncovers Unique Cybersecurity Risks in Today's Tech Landscape. Learn More

Trustwave SpiderLabs Uncovers Unique Cybersecurity Risks in Today's Tech Landscape. Learn More

Services
Capture
Managed Detection & Response

Eliminate active threats with 24/7 threat detection, investigation, and response.

twi-managed-portal-color
Co-Managed SOC (SIEM)

Maximize your SIEM investment, stop alert fatigue, and enhance your team with hybrid security operations support.

twi-briefcase-color-svg
Advisory & Diagnostics

Advance your cybersecurity program and get expert guidance where you need it most.

tw-laptop-data
Penetration Testing

Test your physical locations and IT infrastructure to shore up weaknesses before exploitation.

twi-database-color-svg
Database Security

Prevent unauthorized access and exceed compliance requirements.

twi-email-color-svg
Email Security

Stop email threats others miss and secure your organization against the #1 ransomware attack vector.

tw-officer
Digital Forensics & Incident Response

Prepare for the inevitable with 24/7 global breach response in-region and available on-site.

tw-network
Firewall & Technology Management

Mitigate risk of a cyberattack with 24/7 incident and health monitoring and the latest threat intelligence.

Solutions
BY TOPIC
Microsoft Exchange Server Attacks
Stay protected against emerging threats
Rapidly Secure New Environments
Security for rapid response situations
Securing the Cloud
Safely navigate and stay protected
Securing the IoT Landscape
Test, monitor and secure network objects
Why Trustwave
About Us
Awards and Accolades
Trustwave SpiderLabs Team
Trustwave Fusion Security Operations Platform
Trustwave Security Colony
Partners
Technology Alliance Partners
Key alliances who align and support our ecosystem of security offerings
Trustwave PartnerOne Program
Join forces with Trustwave to protect against the most advance cybersecurity threats
SpiderLabs Blog

How to Hack and Not Get Caught

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.

Latest SpiderLabs Blogs

Zero Trust Essentials

This is Part 5 in my ongoing project to cover 30 cybersecurity topics in 30 weekly blog posts. The full series can be found here.

Read More

Why We Should Probably Stop Visually Verifying Checksums

Hello there! Thanks for stopping by. Let me get straight into it and start things off with what a checksum is to be inclusive of all audiences here, from Wikipedia [1]:

Read More

Agent Tesla's New Ride: The Rise of a Novel Loader

Malware loaders, critical for deploying malware, enable threat actors to deliver and execute malicious payloads, facilitating criminal activities like data theft and ransomware. Utilizing advanced...

Read More