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:
There are so many more talented and generous people writing and talking about Azure. Please reply here if you are one of those people or know someone who is.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
“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.
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...