There are 3 major reasons I see why we should not be blaming the people behind these dangerous configurations:
First: It doesn't help. Honestly, what evidence do we have that screeching at admins to do "the basics" has created positive outcomes?
Second: Don't forget where you came from. No one is born with all the knowledge needed to avoid these mistakes. What you see as "basic", someone else sees as secret arcane knowledge. A little empathy goes a long way here.
Third: When we blame others, we pass the buck on to them and absolve ourselves of any responsibility to affect change. "Our industry would be 100% perfect if not for those admins messing everything up". Grow up. Take responsibility. Help or get out of the way.
Now, what patterns can we observe in those replies, and what conclusions can we draw from those patterns? There are three patterns and conclusions I see:
Pattern #1: "What you don't know will hurt you." Many of these stories include the pentester surprising the customer with the finding - the admin didn't know about that config, or didn't know the impact of the config.
Conclusion #1: The tools, techniques and procedures used by the pentester to generate the finding for the customer created a positive outcome for the customer. "If you aren't aware, you can't prepare" -- OSS tooling and the pros who use them create that awareness.
Pattern #2: Common platforms, common problems. So many replies in that thread have their own replies chiming in with, "I've seen that, too", or "Did we go to the same place?" It seems almost everyone testing a type of platform sees the same issues across all instances.
Conclusion #2: These issues are exceedingly *common*, and NOT exceedingly *rare*. Shift your thinking from, "No admin in their right mind would do this" to "Many admins running this platform do this."
Pattern #3: Backdoor, or bad config? Many replies in the above thread mention initially confusing a dangerous configuration with a backdoor. Something so egregious, only an adversary could have put it there as a back door. I've seen plenty of examples of that myself.
Conclusion #3: Remember Murphy's Law: "Whatever can happen will happen". This applies to everything, including how IT systems are configured. If the IT system or product *allows* a particular configuration, that configuration *will* happen.
Final thought: do not be so quick to blame people for the dangerous configurations in their environments. Be kind. See and recognize the patterns across industries and do something positive to help.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
The #BloodHoundEnterprise team's working culture, as explained by Marcus Aurelius, a short thread: 🧵
“The object of life is not to be on the side of the majority, but to escape finding oneself in the ranks of the insane.”
We are not afraid of challenging the status quo and doing things radically different than what came before.
“If someone is able to show me that what I think or do is not right, I will happily change, for I seek the truth, by which no one was ever truly harmed. It is the person who continues in his self-deception and ignorance who is harmed.”
There has never been a better time than right now to get involved with Azure security research.
Not convinced yet? Let's compare where we are with Azure versus where we are with on-prem AD: 🧵
Active Directory initially came out in December of 1999. Now it's 2022. What's happened between then and now?
We actually had pass-the-hash before AD came out, but it wasn't really made practical until @hernano released the PTH Toolkit in 2007, nearly 8 years after AD's release:
In Windows and Active Directory, there is one system responsible for making access decisions in nearly *all* cases: the Security Reference Monitor. This system makes access decisions by analyzing security descriptors on securable objects and User Rights Assignments:
In "Azure", the story is very, very different. There are multiple forms of access control, and multiple services responsible for making access decisions.
"Azure" means the 600+ distinct services that comprise Microsoft's cloud computing platform.
Understanding who has control of any given object in any given Azure service requires a complete understanding of *all* of these systems and how they cooperate with one another.
New abuse primitives that take advantage of legitimate administrative protocols and features are wildly exciting. Why? Because no object is an island. Everything is interconnected, and that interconnectedness can have enormous impact. Thread: 🧵
You may or may not be familiar with the childrens' book, "If You Give a Mouse a Cookie:"
It's a classic children's moral illustrating the slippery slope idea:
If you give a mouse a cookie, it will ask for a glass of milk.
But it's too hard to drink the milk, so now the mouse wants a straw.
The mouse is worried it has a milk mustache, so now it wants a mirror.
In the upcoming #BloodHound 4.1 release, we are introducing 3 new edges. Let me explain why this is actually more impactful than it may sound: 🧵
Let's say you have a basic graph with 3 nodes all connected to each other (this is called a Strongly Connected Graph). We'll call these nodes 1, 2 and 3:
How many possible paths are there? We can determine that by searching through non-cyclic trees originating from each node. For example, if we start at 1, we can visit 2 then 3, or 3 then 2:
I’m a firm believer in the (cliche) adage, “Outcomes, not output.” It’s not about the number of lines of code you wrote in 2021, but the impact those lines of code had - the outcomes they created. Here’s 5 small things you can do in 2022 to create big AD security outcomes:
#1: Audit the owners of your domain controller computer objects. Update the owner of each object to the Domain Admins group for that domain.
Time required: up to 1 hour
Potential attack path impact: extremely high.
Risk of breaking something: very low
#2: Use BloodHound to find where Domain Users/Everyone/Auth Users has privileged access, and remove all such instances.
Time required: up to 1 week
Potential attack path impact: extremely high.
Risk of breaking something: low