For one hundred and twenty three days, an intruder moved freely through a corporate network. When investigators finally arrived, every system was still running normally. No alarm, no crash, nothing broken. On one domain controller, a single extra file quietly copied every employee's password in plain text, each time they logged in or changed it. Nobody had broken Windows. Someone had registered with it, using a feature the operating system offers on purpose. That distinction is the subject of this briefing, and it is the reason two of Microsoft's May 2026 investigations deserve a closer look through a human lens.
Two Breaches, One Underlying Problem
Microsoft published two incident reports describing the same failure pattern from different angles. In the first, a threat actor tracked as Storm-2949 turned a single compromised identity into a cloud wide breach, exfiltrating thousands of files and dozens of stored secrets. In the second, Microsoft Incident Response investigated an intrusion that ran for one hundred and twenty three days, conducted entirely through a trusted third party IT provider and the organization's own monitoring software.
Neither attacker broke in, in the conventional sense. Both inherited access that the organizations had already granted to someone else: a user, a vendor, a piece of software. That handoff point, where an organization's security assumptions transfer control to something outside its direct oversight, is the trust boundary. It is rarely audited, precisely because it does not look like a vulnerability. It looks like normal business.
The Human Step That Starts Everything
The Storm-2949 intrusion did not begin with malware. It began with a phone call. The attacker impersonated internal IT support, told employees their accounts needed urgent verification, and walked them through approving a multifactor authentication prompt during what looked like a routine password reset. Once a user approved that prompt, the attacker reset the password, stripped out the existing authentication methods, and enrolled a device of their own choosing.
This is the moment where the technical story and the human story meet. The employee did not act carelessly. They responded to an urgent request from a source that sounded legitimate, using a workflow the organization itself trains people to expect, since real IT support does sometimes call about account issues. The attacker did not need a technical exploit. They needed a plausible reason and a small window of trust. That single approved prompt became the foundation for everything that followed.
What One Identity Can Unlock
Once inside, the attacker treated the compromised identity the way an administrator would. They ran a script against the Microsoft Graph API to enumerate users, groups, and applications across the entire tenant, then used the same social engineering approach to compromise three more accounts. From there, they reached the organization's Azure Key Vault, a centralized store for credentials and connection strings. In four minutes, they read dozens of secrets.
The speed matters. It illustrates that the initial human deception was the hard part. Everything after it was fast, because cloud platforms are built to trust a valid login by default. The organization's defenses were not absent, they were pointed at the wrong boundary. They watched for malware and unauthorized code, while the actual point of failure was a person granting access to another person who was not who they claimed to be.
When the Vendor Is the Way In
The second case removes the compromised employee from the picture entirely. Here, the attacker never contacted the victim organization at all. Instead, they compromised the victim's third party IT provider, who managed an enterprise monitoring platform already authorized to run scripts across the victim's servers and domain controllers. Microsoft was explicit that no software vulnerability was exploited. The platform worked exactly as designed. It simply was not clear, to the victim organization, how much unmonitored authority it had handed to a vendor's employees and their tools.
This is the second trust boundary, and it is arguably harder to see than the first. An organization can train its own staff to recognize a suspicious call. It has far less visibility into who has access on the vendor side, how that access is protected, and what happens if that vendor is compromised. The one hundred and twenty three day duration of this intrusion is itself evidence of the gap: an attacker operating through an already trusted channel does not need to hide from detection tools built to catch outsiders, because on paper, they never were one.
Why This Keeps Happening
Both cases point to the same underlying condition. Security programs are generally built to defend a perimeter and to scrutinize unfamiliar activity. Trusted relationships, whether with an employee's login, a vendor's platform, or a built in system feature, are treated as settled questions rather than ongoing risks. Attackers have noticed this. Rather than developing new exploits, they are increasingly choosing to locate the trust relationship an organization has already extended and stepping into it. Industry reporting has tracked a rising share of breaches attributed to third parties, reinforcing that this is not an isolated pattern but a broader shift in how intrusions begin.
The Takeaway
The common thread in both incidents is not a software flaw. It is a decision, made by a person, to extend trust: an employee approving a prompt during a stressful, urgent seeming call, or an organization granting a vendor's tool standing access to its most sensitive systems. Technical controls matter, but they were largely functioning as intended in both cases. What failed was the assumption that a verified identity or a familiar vendor relationship no longer needed scrutiny. Mapping out where your own trust boundaries sit, with employees, with vendors, and with the built in features of your own tools, is a more immediate step than waiting for the next patch.
If this kind of analysis is useful to you, subscribe free at threatlevelhuman.substack.com. Subscribers also get the free Social Engineering Red Flags field guide, a practical reference for spotting the kind of human centered manipulation that made both of these breaches possible.
<- back to the blog