(1/6) One of the most powerful and valuable aspects of a red team assessment is its ability to cut straight through any pre-existing notions of a network's security posture. 🧵
(2/6) The facts of a devastating attack path, well-executed, cut through egos, politics, ineffective operational momentum, and spell it out very plainly for everyone to see: the red team got in, took control of everything, and you couldn't stop them.
(3/6) Getting your teeth kicked in like that hurts, but professional red teams know how to turn that pain into value for the customer, and help them see it as an opportunity to improve.
(4/6) Any red teamer who's been around long enough has seen the same thing: "you'll never get in" evolves into "well if we would have done X..." which finally evolves into "ok how do we actually deal with this?"
(5/6) Some folks in our field hold this idea that Active Directory isn't that big of a risk: I'm here to tell you that this perspective is dangerous and is the exact perspective that many admins have before getting THEIR teeth kicked in, either by a red team or a real adversary.
(6/6) You shouldn't take my word for it though. I put this blog together so you, the AD security practitioner, can see *for yourself*, *for free*, how big of a problem attack paths are in *your* AD: medium.com/p/28147dedb73b
• • •
Missing some Tweet in this thread? You can try to
force a refresh
Point #1: Red teamers know how year after year the same tools and methodologies can be used to take over almost any organization running Active Directory. Sometimes even the same exact attack path steps find their way into reports year after year.
We shouldn't be satisfied with doing the same attacks against our clients for years (even decades) and collecting paychecks - what exactly is the point of all this tailchasing if things aren't getting better?
(1/n) The other day, @JulioUrena asked a great question in the BloodHound Slack:
"How can I determine which Group Policies apply to members of a certain group?"
We can use #BloodHound to answer this question, but I want to explain the moving pieces here as well
(2/n) Group Policy can't be applied directly to security groups, except when using SID filtering and linking the Group Policy correctly. SID filtering on GPOs is not very common, so #BloodHound doesn't currently model that.
We can still use #BloodHound to figure this out though
(3/n) Take for example this security group -- real data so labels are hidden (left CTRL in BloodHound GUI). This group has 7 users in it, but because it has a group added to it...
A thread of major points about BloodHound Enterprise:
Once an attacker has access to Active Directory, it's virtually guaranteed they can find an attack path resulting in the compromise of a Tier 0 asset (Domain Admin). Owning Tier 0 means owning AD. Owning AD means owning the organization, all its data, users, processes, etc.
The scale, availability, and growth of those attack paths has exposed an enormous gap in how we try to secure Active Directory today. Organizations try (and fail) to fill that gap with technologies, products, and processes.
The hardest targets I faced while pentesting/red teaming all had one thing in common: mature, funded, and empowered vuln/patch management programs.
The hardest of all combined vuln/patch management with least privilege enforcement - and inspired the creation of #BloodHound.
Are patch/vuln management and least privilege enforcement sexy? No.
Are they easy? Hell no.
Are they worth the initial and continued investment? Absolutely yes.
The best teams have processes for pretty easily dealing with things like Zerologon. They hear about the new scary vuln, understand its impact, test patch deployment to a subset of affected systems, then deploy to all affected systems, and audit patch deployment/effectiveness.
(1/9) My first pentest job was at a company called TrustCC - little-known then and since purchased. We had a tradition whenever got DA: horrible, awful, cringe-worthy puns.
(2/9) We would send internal emails that were half celebratory, half instructive, explaining how we got DA in that particular client environment. But the email subject was REQUIRED to be a pun based on the client name.
(3/9) So if the client was "Sunny Hills Bank", the email subject might be "Walking on the Sunny (Hills Bank) Side of the Street: Path to DA #1".
1/n Domain trust boundaries are not, of course, security boundaries; however many organizations effectively treat them as such. #BloodHound's attack graph tells the real story of how isolated our domains are from each other. Take this simple 3-domain forest for example.
2/n The domain trust map is pretty simple. Domain 1 is trusted by Domain 2, and Domain 2 is trusted by Domain 3. (This is real, anonymized data). So principals in Domain 1 can query Domain 2 or 3 for information, but no privileges are implied by default.
3/n With #BloodHound we can easily find the shortest attack paths from "Domain Users" in Domain 1 to "Domain Admins" in Domain 3. Pretty easy attack path, and very common situation in the real world: