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.
There are MANY reasons for this, but only one organization on the planet has the money, talent, and power to make usage of these technologies commonplace: Microsoft. And Microsoft can achieve this by taking radical ownership of customer security outcomes.
Number two: take radical ownership of emergent risks. An emergent risk is an attack primitive, abuse, or class of attack methodology that “emerges” from seemingly disparate components. Take Responder for example.
Responder is capable of performing NBNS/LLMNR poisoning, which can be used to bait authentication from a privileged account, which can be relayed to a system that doesn’t enforce SMB signing.
There are at least three different components here: DNS lookup order, NTLM authentication, and SMB server settings. But there’s also the local admin rights, the lack of inbound or outbound traffic filtering, not to mention the Windows service control manager.
No one team at Microsoft controls all those components, but the organization itself does. This emergent risk (and many others) is *extraordinarily common*.
By taking radical control of emergent risks, I believe Microsoft can eliminate entire classes of attack primitives.
Number three: envision a future where Microsoft platforms and software are universally regarded as the most secure platforms and software to do business on. And then create that future.
Microsoft has had many, very public security-related tumbles (think MS08-067). But it has had several huge security-related accomplishments as well (LAPS, AMSI, etc).
As we look at the next ten, twenty, even thirty years of computing, it’s obvious that cloud computing will play a major part.
I won’t pretend to be an economist or business strategist, but I do know this: customers don’t leave a vendor because another vendor has a better solution - they leave a vendor because the vendor stops taking care of them.
My own experience with Azure so far has led me to this conclusion: there are many lessons learned from the on-prem days, but also many repeated sins.
Chief among those sins is in giving admins enough rope to do their jobs, enough to hang themselves with, but not enough to keep the rope from forming a noose.
Who knows what will happen in the future, but with the dramatically reduced cost in changing cloud platforms when compared to on-prem platforms, Microsoft must take excellent care of its customers in this arena.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
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...
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.