“An individual working in one of our facilities accidentally downloaded a malicious file that they thought was legitimate. We have no reason to believe this was anything but an honest mistake.”
– An Ascension Spokesperson, June 12, 2024
This post revisits the 2024 ransomware breach of Ascension Healthcare. This is news again, because U.S. Senator Wyden pressed Microsoft to warn its users and address systemic Active Directory flaws that enable these horrible events. But, the story goes deeper than that. This is a case study about how what we know, dictates what we talk about, and informs who we blame. In this post, we’ll look into this breach, follow the reveals, and keep asking–what do we know now and who do we blame?
Ascension Healthcare Ransomware Breach
May 8, 2024, a months-long IT disaster became visible at Ascension, a St. Louis-based healthcare organization with 131,000 employees, 37,000 aligned providers, and 140 hospitals. They were the latest victims of a Black Basta ransomware attack.
This event shutdown Ascension’s Electronic Health Record system and forced hospitals to use paper and pen processes. In some cases, ambulances were routed to other hospitals. An NPR article shared stories from on-the-ground clinicians who struggled to work in this environment and recounted close calls and mix-ups from the chaos of this situation.
Ascension dedicated a webpage to the breach and shared updates with the general public. It would take them until mid-June to restore IT functionality and go back to most normal business.
The ransomware breach of Ascension wasn’t the first or last of 2024. Another group extorted $22 million from Change Healthcare in February 2024. Lurie Children’s hospital was attacked in January 2024, but refused to pay a ransom. The stolen data was posted by the threat actors.
The healthcare news organization STAT reports that Ascension suffered a $1.3 billion loss from this cyber attack. Despite this, there are silver linings. Ascension stated Black Basta only stole files from 7 of 25,000 servers. For the people whose data was on those servers, Ascension has generously offered the post-breach cure-all of free credit monitoring for two years–a windfall for those excited by this service.
What Happened?
In February 2024, a contractor working from an Ascension laptop conducted a search on Microsoft’s Bing, using Microsoft’s Edge browser, and they clicked on a link that they thought was legitimate. Unbeknownst to them, they ran malware that would open the door for Black Basta to compromise the entire organization.
Headlines, “How One Employee’s Honest Mistake Caused a Massive Ransomware Attack” and “A ‘mistake’ allowed hackers into Ascension’s IT system” said to the public: there’s nothing to see here. This is a story of bad luck, a click, some malware, and a healthcare system IT collapse.
These headlines are not just a journalist’s take. One post-breach podcast featured a Healthcare CISO expressing sadness that an organization can do everything right—security hygiene, centralized change management—and still have their whole system undone by a single click.
But, as a former security professional, I have questions. Microsoft Edge has features like Microsoft Defender SmartScreen, an on-by-default feature said to provide ‘peace of mind, for every click.‘ Where was the peace of mind for this click?
Surely, based on what we know, or can speculate… there’s more to this story than a contractor, a click, and Microsoft Edge’s Smartscreen. Fortunately, there is!
What the threat actors say…
We know more about the Ascension breach, thanks to the February 2025 leak of chat logs from the Black Basta ransomware group.
Reading the chats, I noticed the threat actors strategized about the negotiation. And, this discussion raised something I don’t see in public discourse much:
It’s not easy to pay a ransom! The victim organizations likely don’t have processes to make payments with cryptocurrency. And, that’s not the main hurdle. A victim that engages with organized crime risks breaking U.S. laws. For example, OFAC imposes strict liability for sending funds, even unknowingly, to a sanctioned entity.
This gives rise to the ransomware negotiator. A service often bundled with incident response. These deal makers are key for closing high-dollar transactions with organized crime. They know the price for decryptors and understand extortion’s going rates. They also bring turn-key process for the transaction’s compliance, diligence, and disclosure needs–helping the victim and criminal effect a “lawful” transaction smoothly and quickly.
Of course, the above is non-technical business speak. Ransomware is a cybersecurity failure, which is a technical failure. Certainly, this technical problem has a technical solution.
Let’s pivot to the technical. Black Basta’s chats say they encrypted and effectively seized 12,000 of Ascension’s systems. This differs from the official statement that data was only stolen from seven servers. While encrypting and exfiltration are different acts, the two numbers suggest different scales of compromise. This said, if Black Basta controlled Ascension’s Active Directory, it’s not an act of magic to touch 12,000 systems. Black Basta can do as they wish with Microsoft Windows remote execution and file sharing primitives. There’s no need for malware on each host.
The leaked chats include Black Basta’s technical reconnaissance of Ascension, where we learn something new: the installed security products. They saw Cylance EDR, McAfee, and Tanium.
I’m sad that we need threat actor chats to learn about present controls. We miss the chance to compare defense-in-depth claims with real-world failure context. During my time, I’ve only read about security product successes. Aren’t the failures a teachable moment too?
After a breach, industry experts often say AI will restore the advantage for defenders. Cylance EDR is an AI-powered solution!
Cylance is known for its prevention-first philosophy. The product uses AI to predict if a file is malicious before it’s run. We know Cylance’s efficacy claims at the time of the Ascension breach too.
May 6, 2024–days before Black Basta toppled Ascension, Cylance announced nearly 100% detection of the threats in a commissioned independent study. The study was run by the Tolly Group who used 1,000 then-recent malware samples in the test. The Tolly Group lauded Cylance’s low CPU use and ability to detect well in offline and internet connected scenarios.
We don’t know if Cylance was installed on the contractor’s laptop or the systems where Black Basta used malware. But, I want to point out a discrepancy between the security we sell and the reality of how it’s used. Given the outcome at Ascension, I ask, how did this AI-powered product help?
Senator Wyden Investigates
If this was just another tragic ransomware breach, with the same “someone clicked” narrative—-this blog post wouldn’t exist. But, this incident had a recent reveal that fills in details.
U.S. Senator Wyden’s office investigated the Ascension Healthcare breach. This included interviews to find the ground truth. The investigation found a key detail: Black Basta used Kerberoasting to go from the contractor’s laptop to full control of Ascension’s Windows enterprise. This full control is what allowed Black Basta to carry out their devastating ransomware attack.
Contrast this new detail with the industry discourse. Reputable organizations like the U.S. government and FIRST released advisories with IOCs, pie-chart breakdowns of .com vs. .net threat actor TLDs, and helpful advice. The advice includes: train users, implement 2FA, patch, use legal software, and watch out for remote management tools. For all of this well-meaning guidance, acting on a moment of interest, this connective tissue of Active Directory privilege escalation as a systemic issue didn’t come up.
Why didn’t Active Directory domain privilege escalation come up? Is it because everyone understands this issue, so there’s no point repeating it? Or, does this missing (and not missed) detail suggest cybersecurity’s narrative is about the wrong things?
Kerberoasting
Kerberoasting is a technique to become another, often globally privileged, user in networks managed with Microsoft’s Active Directory. I’m going to spare you a full description of Ticket Granting Service Tickets and cut to the chase.
Any user on an Active Directory-managed computer can request a file encrypted with the password of certain special accounts. These special accounts are for software services (e.g., an SQL database) and not people. This encrypted file is available for the Kerberos authentication protocol. Once the attacker has this file, the next step is to guess passwords to decrypt the file. We call this password cracking. This cracking happens on an attacker asset. It’s not visible to us. When cracking yields a password, the attacker now has a credential for this other account in the Active Directory network.
Any user can ask Active Directory for a list of these special accounts. This attack doesn’t require any special insider knowledge.
Cobalt Strike never had a Kerberoasting feature. So much of my work with the product was to provide methods to operationalize new and existing techniques. For example, SOCKS pivoting is how Cobalt Strike’s users Kerberoast with Impacket or other stand-alone tools. My work with Cobalt Strike also set conventions to develop and use post-exploitation tools, specifically .NET and BOFs. This made Cobalt Strike a first choice to use Rubeus and Kerbeus BOF. While Cobalt Strike only had basic post-exploitation primitives, I considered Kerberoasting a staple attack, and I taught it in my 2019 Red Team Operations with Cobalt Strike course.
Kerberoasting isn’t the root cause of the Ascension ransomware event. It’s Active Directory privilege escalation. This process involves harvesting credential materials and using them to become users who can do things the current user can’t. Pivoting identities is how an attacker goes from control of one laptop, via one person of 131,000+ clicking a link, to the power to enact their will at scale within the enterprise.
Active Directory privilege escalation is not a Kerberoasting problem. There are many ways to escalate privileges in Active Directory. More importantly, this is not a fully understood area of risk either. New features and work on Microsoft’s technologies occasionally introduce new Active Directory privilege escalation options. And, new privilege escalations are occasionally discovered too.
Active Directory privilege escalation isn’t an obscure issue that plagues irresponsible organizations. It’s a pervasive problem. An anecdote that was once relayed to me: a group of consultants went into a financial organization and measured how many employee computers had an automate-able path to full control of the network. I think the number was 96% or higher. The ubiquity of these paths to go from an unprivileged context to full control of a network is why I refer to Active Directory as IT’s lead in the pipes danger. These paths are not patched with software updates. And, they don’t necessarily exist in a network during day one of its build (or rebuild). Instead, they creep in, as unintended consequences of routine IT activity.
I do not want to discount the importance of Kerberoasting as a contributing factor in these ransomware breaches, either. In the 2025 blog post, Why Kerberoasting Still Matters for Security Teams, Varonis shared: “In nearly every Windows domain compromise our Forensics Team investigated last year, Kerberoasting was attempted, and often succeeded.” Kerberoasting is a go-to attack technique because the issue is fundamental to how network operators manage service accounts in Active Directory.
Since when?
With such a devastating issue, one of many, it’s fair to ask: when did we find out about this? What was done since we found out about it? Let’s discuss these things.
Tim Medin introduced Kerberoasting at SANS Hackfest 2014 in his talk: Kicking the Guard Dog of Hades. This talk was the beginning of the offensive security work to understand and socialize the issue. Recently, Tim wrote: “When I came up with Kerberoasting in 2014, I never thought it would live for more than a year or two. I (erroneously) thought that people would clean up the poor, dated credentials and move to more secure encryption. Here we are 11 years later, and unfortunately it still works more often than it should.”
The future of any security discovery is always uncertain. But, we do know others have to understand the issue before it’s possible to defend against it. And, understanding isn’t a given. I was in the audience that day. And, I didn’t understand the talk. I’m not an Active Directory expert and I never was. But, thanks to community tutorials, tools, and other exploration of Active Directory issues–I have a working knowledge I wouldn’t have gotten on my own. And, I assert that it’s the same for other security professionals, including security architects at Microsoft. This is why I’m so passionate about the Security Conversation. Without it, we have no chance to address the issue.
But, what happens when issues don’t get addressed? They move from temporary curiosity to repeated tragedy. This is where Active Directory attacks are today. These issues are absent from the broader cybersecurity narrative. What replaces these issues are simple narratives that point blame at other targets. This is the substance of the OST debate, a strategic campaign to educate the public on how criminals co-opt tools and research from the offensive security eco-system. While these critics may acknowledge the issues are a problem too, they hold individual offensive security researchers and tool authors morally responsible for harm and imply they must conclusively fix it.
I always felt these debates missed the big picture of the offensive security profession. Red Teamers are not a tiny cabal that execute niche security tests, solely for the benefit of “mature” client organizations. Offensive security insight is the technical truth of complex issues and yields strategic security leaps. Its formerly default-open culture is what socialized offense ideas to the security profession. But, that culture has changed, partially to align with its critics. The space is moving to fragmented closed eco-systems and a fragmented community as a whole. Some continue with openness and others prize offense insights as trade secrets to “Win” security tests. While this does reduce visibility and blame for offensive security, I believe it stagnates the security profession and further separates discourse from technical truth.
Senator Wyden’s Call to Action
We now have movement on Kerberoasting. In October 2024, Microsoft published guidance to help mitigate Kerberoasting. In the same post, Microsoft announced Windows Server 2025 and Windows 11 24H2 will deprecate RC4. And, Microsoft also introduced Delegated Managed Service Accounts–a new Kerberoasting-resilient way to manage software service accounts in Active Directory.
We know now that this action is from Senator Wyden’s pressure. In a public letter to the chair of the U.S. FTC, Senator Wyden revealed that his staff spoke with Microsoft in July 2024 and urged them to warn their customers about Kerberoasting.
Microsoft’s use of RC4 in Kerberos is one of the details Senator Wyden uses to justify his concerns about Microsoft’s security choices. The focus on RC4 is well-meaning, but it’s not the full picture of the attack. Tim Medin addressed this in Kerberoasting, Microsoft, and a Senator:
“With the Kerberoast attack, attackers are targeting the encryption key (the server’s password), not the underlying encryption protocol. The common encryption protocols for encryption on tickets are RC4, AES128, and AES256. The attackers aren’t fundamentally breaking RC4, but…”
“The fundamental problem that leads to a successful Kerberoasting attack is bad passwords. Ideally use Managed Service Accounts (see the Microsoft blog post) or use a long, secure, and preferably random password. Remember, attackers are guessing billions of passwords per second. A secure password for a user is much different than a secure password for these accounts.”
Kerberoasting’s BadSuccessor
Microsoft introduced delegated Managed Service Accounts (dMSA) to address Kerberoasting. This feature creates a path to manage service accounts with long random passwords, which makes them near-impossible to crack. dMSA also has an easy migration path for existing service accounts that are susceptible to Kerberoasting. This Windows Server 2025 feature shipped days after Microsoft’s October 2024 Kerberoasting guidance.
I’d love to say, problem solved. But, that’s not the whole story.
Yuval Gordon, a researcher at Akamai, looked at dMSA and found something horrifying. Microsoft’s dMSA feature added a trivial path to escalate privileges in Active Directory. What’s worse, this attack doesn’t require the organization to use dMSA; it just requires a Windows Server 2025 Active Directory domain.
Akamai reported the issue to Microsoft in April. Microsoft accepted the issue and said they would fix it. But, they rated the issue as Moderate severity. This means they didn’t see a need to immediately fix the issue (or warn users about it).
Yuval and his colleagues disagreed with Microsoft’s severity assessment. They worried that the ease of exploitation and lack of urgency for a fix put others at risk. They went public with their findings and steps to demonstrate the attack, which they dubbed BadSuccessor.
This decision re-ignited the coordinated disclosure debate. Critics maligned Yuval for seeking clout over the safety of potential BadSuccessor victims. Their logic: because Microsoft will fix the problem and there’s no fix now–it is harmful to make this attack public and arm criminals. This criticism was echoed in some of the industry media around BadSuccessor. In some cases, it featured prominently.
Some defended Yuval’s actions, but rarely with a blanket trust of Yuval’s professional judgement or respect for the role of offensive security. Rather, supporters described why it was OK “this time”. One supporter argued that Windows Server 2025 isn’t widely deployed yet and it’s better to know about the issue early. The public information pressures Microsoft to act. Another ally offered that, even if no fix is available, system administrators have a right to know if a supposed upgrade introduces a no-fix devastating attack into their environment.
Outsiders may see this as a spirited industry debate, two well-meaning sides working through difficult questions. But, these debates are not always nuanced considerations of two valid choices. They’re often character attacks for not making a specific choice. The party that loses is the selfish “clout chasing” security researcher.
CVE-2025-53779 was issued for BadSuccessor and Microsoft did patch it. This sounds like a win! The issue was identified, reported, and fixed. Except, BadSuccessor is not a software mistake. It’s a byproduct of complex interactions of permissions and features in Microsoft’s Active Directory. Yuval reviewed Microsoft’s fix and found that it did address the wide-open privilege escalation he reported. But, even with the fix dMSA adds attack-friendly credential and privilege abuse primitives.
Microsoft’s Bad Precedent
Kerberoasting and BadSuccessor remind me of a pattern I’ve seen before. To understand this pattern, we need to revisit pass-the-hash discourse from a decade ago.
We understand that if an attacker knows a username and password, they can do things as that user. Well, before 2FA anyways. But, it was quite a reveal in 1997, when Paul Ashton posted to NTBugTraq: Windows allows authentication with the user’s encrypted password. There’s no need to crack it. Just use it to authenticate. This is the pass-the-hash attack.
Mark Russinovich and Nathan Ide’s Pass-the-Hash: How Attackers Spread and How to Stop Them presentation at TechEd 2014 is a favorite overview. This talk was part of Microsoft’s efforts to socialize their new mitigations and efforts to address pass-the-hash. An effort that began in 2012 with the publication of guidance to mitigate pass-the-hash techniques..
Like, Kerberoasting, Microsoft waited to acknowledge and act on the issue. 15 years for pass-the-hash. 11 for Kerberoasting.
I chalk this up to Microsoft’s Public Security Servicing criteria. This is a list of stuff that Microsoft will act on when it’s reported. The list is a necessity. A lot of intended functionality aids attackers and authorized users alike–Microsoft has to set expectations. But, dogmatic adherence to these criteria slows Microsoft’s action on risks from intended behavior–even when attack trends show a serious issue. User-account control bypasses, as an example, don’t violate Microsoft’s concept of security boundaries and would go unaddressed for years.
We see this cultural tap dance with Active Directory issues. Mark and Nathan’s talk frames pass-the-hash as intended Single Sign-on behavior. This is the ability to use a share (the way Black Basta used shares) or print files without typing your username and password each time. Microsoft never admits their choices contribute to this problem, a stance that attracted a rebuke in Skip Duckwall and Chris Campbell’s post, “Why We Don’t Get It and Why We Shouldn’t.“
Microsoft’s pass-the-hash efforts followed a pattern we see with Kerberoasting now. Microsoft published guidance, made baseline changes, added mitigation features, and declared the problem mostly solved. Like Kerberoasting, Microsoft’s pass-the-hash efforts added a new attack tool. Prior to Windows 8.1, the Remote Desktop Protocol required the attacker to know the plaintext username and password to login. But, thanks to the mitigation features, it became possible to pass-the-hash with RDP.
Researchers evaluated Microsoft’s baseline changes and found that yes, they took away some options. But, the attack remains intact. Will Schroeder’s 2014 Pass-the-Hash is Dead: Long Live Pass-the-Hash is one of the definitive explorations of this topic. The pass-the-hash (really, pass-the-*) attack is still alive today and part of breaches like Ascension.
Microsoft did deliver powerful mitigation features and I imagine they expect them to address the remaining attacks. The challenge is some of the features are complex and difficult to use without specialized knowledge. Or, not possible to use without disabling a needed legacy feature. This makes their adoption less common. But, Microsoft doesn’t weigh this. They argue their product is defensible and it’s now their user’s problem to figure out these features.
With Microsoft’s dMSA, we’ve again welcomed a opt-in mitigation with new attack opportunities into Active Directory. This is after Microsoft’s patch to “fix” BadSuccessor. Our collective awareness of the new attack primitives isn’t from Microsoft. It’s from Yuval and the red teamers who will further explore his work. It was probably no accident that Yuval titled his post-fix review: BadSuccessor Is Dead, Long Live BadSuccessor(?)
This Blame Game’s Final Round
Senator Wyden’s public letter to the U.S. FTC starts with a damning conclusion:
“I write to request that the Federal Trade Commission (FTC) investigate and hold Microsoft responsible for its gross cybersecurity negligence, resulting in ransomware attacks against critical infrastructure, including U.S. health care organizations, which have caused enormous harm to health care providers, put patient care at risk, and continues to threaten U.S. national security.”
It’s in this letter, we also learned that Senator Wyden wasn’t too pleased with Microsoft’s actions so far:
“While my staff specifically requested that Microsoft publish and publicize clear guidance in plain English so that senior executives would understand this serious, avoidable cyber risk, Microsoft instead published a highly technical blog post on an obscure area of the company’s website on a Friday afternoon. Microsoft took no meaningful steps to publicize this blog post. Moreover, Microsoft declined to explicitly warn its customers that they are vulnerable to the Kerberoasting hacking technique unless they change the default settings chosen by Microsoft. As such, it is highly likely that most companies, government agencies, and nonprofits that are Microsoft customers remain vulnerable to Kerberoasting.”
I share Senator Wyden’s frustration here. When these issues were well-known and used by organized crime, Microsoft started a campaign to message it as human-operated ransomware. A tool and actor framing with a flawed defense roadmap that deflects blame from the systemic weaknesses in Active Directory. This message was bigger than my ability to take on, but it’s a message that’s fed the industry’s mob mentality to blame security researchers and the offensive security profession for these issues too.
Detecting and Mitigating Active Directory Compromises published by the Australian Signals Directorate has the guidance and acknowledgements Microsoft’s materials lack. It is one of many extra-Microsoft efforts to address this root cause issue.
Senator Wyden’s letter concludes with a damning statement about the whole thing:
“There is one company benefiting from this status quo: Microsoft itself. Instead of delivering secure software to its customers, Microsoft has built a multibillion dollar secondary business selling cybersecurity add-on services to those organizations that can afford it. At this point, Microsoft has become like an arsonist selling firefighting services to their victims.”
Ars Technica and other media outlets covered Senator Wyden’s letter. And, the Ars Technica article published a response from Microsoft:
”RC4 is an old standard, and we discourage its use both in how we engineer our software and in our documentation to customers – which is why it makes up less than .1% of our traffic. However, disabling its use completely would break many customer systems. For this reason, we’re on a path to gradually reduce the extent to which customers can use it, while providing strong warnings against it and advice for using it in the safest ways possible. We have it on our roadmap to ultimately disable its use. We’ve engaged with The Senator’s office on this issue and will continue to listen and answer questions from them or others in government.
In Q1 of 2026 any new installations of Active Directory Domains using Windows Server 2025 will have RC4 disabled by default, meaning any new domain will inherently be protected against attacks relying on RC4 weaknesses. We plan to include additional mitigations for existing in-market deployments with considerations for compatibility and continuity of critical customer services.”
Here, Microsoft latched onto the red herring of RC4, and failed another chance to own the Active Directory Domain privilege escalation problem set. Tim Medin also reacted to Microsoft’s response in his Kerberoasting, Microsoft, and a Senator post:
“Microsoft claims this affects “less than 0.1% of traffic”, but this statistic is misleading. It’s like saying “only 0.1% of our doors are used by burglars” – attackers will simply choose the weak door. Microsoft has prioritized backward compatibility over security, leaving all organizations vulnerable by default.
The truth is, since the protocol is enabled (by default), all an attacker needs to do is request an RC4 ticket. The surrounding traffic (99.9%) is irrelevant. Microsoft has left RC4 enabled because they have chosen to support backward compatibility (as mentioned in the quote), which leads to a faster Kerberoast attack.
The second paragraph is misleading as well. They state that “in Q1 of 2026 any new installations of Active Directory Domains using Windows Server 2025 will have RC4 disabled by default”. The key here is “new”. Existing Active Directory Domains will still maintain their backward compatibility, and RC4, by default. If a new server is installed, and it doesn’t support RC4, that doesn’t prevent the rest of the domain, and the Domain Controllers (the brains of the Domain) from preventing RC4.”
Working with these new details, Ars Technica published a second article. Their article used Tim Medin’s comments and explained Kerberoasting with more depth. When I saw the first article, I was excited by Senator Wyden’s attention to this systemic issue. But, Ars Technica’s second article went back to the same ol’ blame exercise. The article’s social media hook says it all:
“There’s no excuse for an organization as big and sensitive as Ascension suffering a Kerberoasting attack in 2025, though Microsoft is also partially to blame for the breach.”
Closing Thoughts
Thank you for your patience to stay with this long post. I didn’t know what this post would become when I started to write it. I saw a thematic opportunity to talk about Kerberoasting and advocate for offensive security. I didn’t expect, until I sat with the details, that the Ascension Breach, Senator Wyden’s pressure, Microsoft’s action on Kerberoasting, and the dMSA debacle were connected events.
Much of this post is about cybersecurity discourse and the blame game within it. What I hope you saw, with each reveal of new information, was a shifting concept of blame and moral responsibility. Whose actions led to this preventable tragedy? Whose actions or inactions, contributed to this tragedy?
The initial narrative focused on the contractor and how their one-click “honest” mistake led to the downfall of Ascension. Some pointed fingers at Ascension speculating that they did not take actions to prevent this foreseeable harm. Of course, we don’t know what actions Ascension did or didn’t take. This isn’t public information. We know nothing about their security maturity or IT baseline. If we did, we might have a chance to evaluate Ascension’s defense-in-depth and ask ourselves, what was missing or what didn’t work? This information doesn’t exist though. I think this is the industry being self-protective. But, if we knew this information, breach after breach, we might find that many organizations do the reasonable things and organized crime still succeeds. Senator Wyden’s letter brought Microsoft into this exercise. And, Senator Wyden asserts because Microsoft failed to warn their customers or address these issues–they are blameworthy too.
This cybersecurity culture of blame and moral outrage is why its narratives omit details, encourage deflection, and repeat easy answers. Players either feed this ugly or withdraw altogether, because it’s a no-win discourse. There is no sober ground truth in cybersecurity, even though the frequency, scale, and repeated patterns of failure suggests a systemic cybersecurity failure rather than persistent one-off cases of organization negligence or incompetence.
If I were playing the blame game, I would point at this broken discourse. I started my commercial offensive security work in the Windows XP-era. Back then, cybersecurity was a staid cost-center with established players. Since then, we’ve had technical improvements, cybersecurity has become a large industry, and society feels the stakes and consequences of our work. Yet, in this climate of innovation, resources, and buy-in; a single click from a contractor can collapse the IT of a large healthcare system? That’s the narrative? It’s like saying a skyscraper collapsed because someone left a window open. The problem isn’t the click. It’s this vacuum of information that no one questions.
For the security discourse, who to blame isn’t the right question. Instead, we should look at breaches systematically, with the full ground truth, and ask a different question. For each contributing factor, viewed as a system, who has the most leverage to act and prevent future criminal success? Active Directory privilege escalation is a root cause cybersecurity issue and Microsoft alone has the leverage to act on this in a systemic way. While I do not believe Microsoft perpetuates Active Directory privilege escalation to sell security products, I would like them to own Active Directory privilege escalation as a product flaw and action it to give their customers a fighting chance. I applaud Senator Wyden for adding weight to this downplayed part of the security conversation. And, to the Yuval Gordon and Tim Medin offensive security researchers out there—thank you for bringing these issues to light. You did your job, and we couldn’t have this discussion without your insight.
Disclosures: I was a cybersecurity researcher and entrepreneur, until I stepped away from the industry in 2021. The above are my opinions. I do not speak for any projects or companies I’ve had or have affiliation with. I own stock in Fortra and SpecterOps.
Adversary Fan Fiction Writers Guild 