“Attackers think in graphs. Defenders think in lists. As long as this is true, attackers win.”
If you’ve seen more than one of my talks, you might think I’m contractually obligated to include this quote in every talk I do.
This quote means a lot to me. A LOT. Graph theory, to me, almost seems like it was invented solely for the information security field. Its purpose and reach is obviously waaaaaaay further than our field, but…
… we have BARELY scratched the surface of what’s possible with applied graph theory in information security. The core feature of #BloodHound is finding the shortest path between two nodes. The algorithm this is based on was first published in 1959.
If you think about it this way, infosec is actually playing catch-up with graph theory, and mathematics as a whole. In playing catch-up, there are fundamental concepts like falsifiability that so far have not really existed in our field yet.
More immediately, there are practical concepts we can apply to infosec very soon that I believe will pay huge dividends.
The most obvious is the graph concept of “reachability” - how many nodes can reach this node, or vice versa, and in how many steps?
Don’t be turned off by this 3 dollar word, “reachability”. Think about it in a more practical sense - how many computers can be compromised if this one particular computer is comprised? That’s what reachability means.
Graph theory enables this kind of measurement. And just like shortest path, there is existing literature and math to help us figure out how to calculate these things in polynomial time.
So what does that mean, practically? Remember the OMIGOD vuln? This bug let you get a root shell on an Azure-hosted Linux box. This bug has an associated CVE. The “impact” of that CVE is limited to the host.
Now: think about reachability again. Think about it in the context of OMIGOD. Think about it in the context of every Azure subscription hosting a Linux VM. The context of every tenant trusted by each sub. The context of each tenant that trusts each of those tenants. Etc.
The real impact of OMIGOD reaches far beyond the individual host. The real impact of EVERY bug reaches far beyond the affected host. That impact is measured as reachability.
Imagine the difference between a vanilla vulnerability management system and a modern attack path management system. The vulnerability management system tells you impact to the host. The attack path management system tells you the impact to the entire environment.
Now: imagine knowing the potential impact of such a bug before it’s even discovered. Imagine eliminating that impact before those bugs are discovered. Imagine *not giving a fuck* about CVEs anymore. That’s what graph theory and mathematics will deliver over the next 10 years.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
There are worlds of untapped security research opportunities in Azure - growing, dynamic, and multiplying worlds. The next few years will produce amazing research. Get a head start with the following resources:
At a high level, what security-related strategies and policies should Microsoft employ over the next ten years? Here are my ideas, but I want to know what you think as well: 🧵
Number one: take radical ownership over customer security outcomes. Microsoft is already doing this with the introduction of built-in safety rails in Azure. But there’s much more opportunity here:
Historically, Microsoft has made all the tools available to admins to secure their networks: Windows firewall, device guard, application guard, etc. A well-resourced, well-financed admin can make an AD domain *amazingly secure*. But most do not.
Three of the most common issues #BloodHoundEnterprise finds, their impacts, and how you can use FOSS #BloodHound to find and fix these issues yourself, today: 🧵
Issue #1: Domain Controller object ownership. This issue is *extremely* common and *extremely* dangerous when looking at attack path possibilities this opens up. This is also *extremely* easy to fix.
In FOSS #BloodHound, run this query using the "raw query" bar at the bottom:
MATCH (g:Group)
WHERE g.objectid ENDS WITH '-516'
MATCH p = (n:Base)-[:Owns]->(c:Computer)-[:MemberOf*1..]->(g)
RETURN p
(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.
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...