Last updated at Tue, 27 Aug 2024 15:42:56 GMT

This blog was co-authored by Steve Coward

Each year, Rapid7 penetration testers complete hundreds of internally and externally based penetration testing service engagements. This post is the second in a five-part series featuring testimonials of what goes on beneath the hoodie.

During Red Team engagements, Rapid7's operators are often pitted against some of the most well-hardened, locked-down, and mature environments. These clients are typically far along in their security maturity lifecycle and have spent large amounts of time and resources tuning their logging, deploying the latest and greatest security solutions, engaging users in security awareness training, and managing their vulnerabilities. However, sometimes all it takes is one misstep or oversight to bring all of that work crashing down.

Recently, we were on a Red Team engagement where this was exactly the case. Our target was a medium-sized company that is in the business of handling extremely sensitive information. Because they knew the risks that they operate under, they had spent years locking down their network as much as they possibly could. They also restricted all users’ accounts and workstations, deployed endpoint detection and response (EDR) solutions to all endpoints in the network, created an extremely efficient patching process, and had been through nearly a dozen penetration testing service engagements previously. These guys were good. Really good.

Cracking the code

We gained access through a VPN and got onto a restricted subnet with routes to only two subnets. We spent hours figuring out how to get a solid beachhead. There were no clients to attack on the local subnet due to guest isolation, no identifiable and exploitable vulnerabilities, no weak domain user passwords, and strong host-based security controls, and it was extremely difficult to target systems in the other subnets due to crossing a monitored network boundary. In an effort to get some type of foothold, we extracted the Kerberos service tickets for a small handful of accounts, put them into Hashcat, and left for the night.

Upon returning in the morning, we found that one had cracked. We quickly and discreetly got the domain group membership of the cracked service account and found that it was a member of the Enterprise Admins group. With this level of access, we could connect to any system in the target’s domain with elevated privileges. We began our hunt for critical data by guessing systems’ functions from their hostnames. On one of our first jumps using the compromised service account to RDP into a server, we struck gold—hundreds upon hundreds of pieces of information were at our fingertips. We were ready to start the exfiltration process.

Takeaways

The biggest takeaway from this engagement was that no matter how patched your systems are, how new and shiny your EDR solution is, or how hardened your network is, sometimes all it takes is one weak password or one overly privileged account to bring the entire show to a stop. Because of this, we always suggest that robust network monitoring and user behavior analytics be at the core of any security program to enable incident responders to detect anomalous behavior and begin the investigative process as soon as possible. As a matter of hygiene, organizations can also audit their Active Directory infrastructure for weak or out-of-compliance passwords, especially for those users who are members of admin groups.

Interested in learning more about how Rapid7 pen testers conduct their assessments? Give “This One Time on a Pen Test, Part 1: Curiosity Didn’t Kill the Cat—Honesty Did” a read and check out Part 3, "How Jumping a Fence and Donning a Disguise Helped Me Steal an Energy Company."