Recently I was doing Incident Response for a company that had been thoroughly compromised, the attackers had acquired domain administration privileges within the Active Directory domain and even gained access to the backups. This was a company, however, that had spent the equivalent of a $100,000 on pentests anually in recent years and the most recent pentests found close to no vulnerabilities. So what when wrong?
So what did these pentests look like? Well, the company set the scope for the pentest to include the following: All of their public websites, their mail gateway and their internet-facing SAP NetWeaver installation. Earlier pentest reports hinted at some typical vulnerabilities (SQL Injection, Cross-Site-Scripting, etc.), but these were quickly fixed and no new vulnerabilities of these categories were detected afterwards. The mail gateway was hardened as per current standards and in every pentest, the SAP NetWeaver installation was up-to-date and no new 0days were found.
All of that sounds good. So, why did the company get so thoroughly compromised? Well, initial access was possible because of an unauthenticated RCE in SAP NetWeaver. Turns out, the company always brought their software up-to-date right before a pentest. Apart from that, the update/patch policy was somewhere between lax and non-existant. So when the breach happened, the last pentest - and with it, the last update - had happened over three months earlier. (At this point, let me also interject that lying to pentesters when they try to assess your security posture will only hurt you in the end. If you know you lack in some areas, be honest about it. Maybe the pentesters will have some creative ideas on how to fix that even with limited resources and time.) The Active Directory Certificate Services (ADCS) Certificate Authorities (CAs) also had some templates configured that were vulnerable to ESC1. This is essentially a one-click exploit (that is also often very hard to pick up among legitimate certificate requests) allowing an attacker with any type of access to an Active Directory domain to take over a domain administrator account. And that is exactly what the attackers did in this case. Finally, the backup servers were always attached to the internal network and there were no offline backups, completing the perfect storm.
So what could they have done better? First off, as the title of this post implies, the pentests could have been scoped a lot better. Despite the pentesters' repeated recommendations to the opposite, the company didn't want to test their internal IT infrastructure. But an initial breach is effectively unavoidable - be it through phishing, a forgotten dev system, lax patch management or (Goddess forbid!) a 0Day vulnerability in an Internet-facing system. So it's best to build security-in-depth: Assume that an initial breach will happen and build a resilient network that can withstand an attack afterwards. Then further build up resilience, separating subnets and systems, layering permissions and building detections at every step of escalation. To assure the efficacy of these, it's good to have internal and "assumed breach" pentests performed regularly. These pentests can even be very usesful at the very beginning to get an understanding of your own network and an overview of what steps to take first and which vulnerabilities to address most urgently.