The Keys Were Public. The Accounts Were Open.

# The Keys Were Public. The Accounts Were Open. The most surprising thing on the wire this morning isn't a sophisticated zero-day or a state-sponsored APT utilizing a novel side-channel attack. It's the fact that hundreds of corporate AWS access keys are currently floating around in the open, granting full administrative control over their respective accounts. When we see these reports, the press likes to call it a "credential leak" as if it were an act of God. It isn’t. This is a key-management flaw masquerading as a security breach. There's no "crypto flaw" here; the AES and RSA implementations powering AWS are fine. The failure is human. We've spent decades building vaults with three-foot-thick steel walls, only to leave the master key under the welcome mat. Claude Shannon once reminded us that information is the resolution of uncertainty. In this case, the uncertainty for an attacker was resolved by a developer hard-coding a secret into a public GitHub repo or leaving a `.env` file in an unsecured S3 bucket. Once those keys are out, the "military-grade" encryption on your data becomes irrelevant because the attacker isn't breaking the lock—they have the key. To actually fix this, you have to stop using long-lived access keys entirely. For a sysadmin, the alternative is the AWS Security Token Service (STS). Instead of a static key that lasts until someone remembers to rotate it (which is never), STS issues temporary, limited-privilege credentials. You use an IAM role; the service requests a token; the token expires in an hour. If that token leaks, the attacker has a window of sixty minutes, not a lifetime pass to your infrastructure. It's a simple shift in logic: move from "something I have" (a static string) to "something I am allowed to be for a moment" (a temporary session). The situation with Entra ID is more systemic and far more dangerous. Microsoft has patched a vulnerability that we’re seeing exploited in the wild, carrying a CVSS score of 10.0. That's the highest possible severity rating because this allows Remote Code Execution (RCE) within the identity provider itself. Let me explain why RCE in an identity provider is the nuclear option of vulnerabilities. In a standard network, if a web server gets popped, you have a foothold on that server. You then have to pivot, escalate privileges, and find the crown jewels. But Entra ID *is* the source of truth for who is allowed to do what across your entire Microsoft ecosystem. If an attacker can execute code at the provider level, they aren't just stealing a password; they are rewriting the rules of the kingdom. They can forge tokens, create new global admins, and bypass MFA by simply telling the system that the MFA has already happened. The industry loves to treat identity as a layer on top of the stack. It isn't. Identity is the stack. When the provider fails, every single security control downstream—from your conditional access policies to your encrypted blobs—becomes a suggestion rather than a rule. The logic here is circular and terrifying: we trust Entra ID to tell us who to trust, but we have no way to verify that trust if the mechanism itself is compromised. The only real defense against this is an architectural shift toward "Zero Trust," which ironically usually just means adding more layers of identity checks. If you're relying on a single provider for everything, you haven't removed the single point of failure; you've just concentrated it into one very large, very complex target. While we worry about the elegance of RCE, some criminals are taking a much more boring, business-like approach to destruction. Medusa ransomware has hit north of 500 critical infrastructure organizations recently. The detail that should keep you up at night isn't the encryption algorithm they used—it's how they got in. They didn't burn a zero-day. They bought access. We are seeing the professionalization of "Initial Access Brokers" (IABs). These are specialists who spend their days scanning for leaked keys, phishing mid-level managers, or exploiting old VPN bugs. Once they have a foothold, they don't deploy ransomware. They package the access—the usernames, passwords, and network maps—and sell it on a marketplace to groups like Medusa. It's a supply chain for crime. The IAB does the reconnaissance, and the ransomware gang does the demolition. This is why patching one "critical" bug doesn't stop the bleeding; you might have patched the hole the IAB used last month, but the broker has already sold the session token to three different gangs. This systemic failure extends into the healthcare sector, where the scale of negligence is starting to look like a liability issue rather than a technical one. CareCloud recently leaked just under 3.7 million records, including Social Security numbers and medical data. Simultaneously, investors are alleging that UnitedHealth knew about massive gaps in their security before a breach hit 190 million people. The common thread here is the "availability" trap. Healthcare providers prioritize uptime over everything because if a system goes down, patients might die. That's a valid priority. However, it has been used as an excuse to avoid the friction of proper security hygiene. They treat security as an obstacle to availability, forgetting that a ransomware attack—like the one currently disabling HVAC and doors at a Canadian hospital—is the ultimate availability failure. The tech sector remains the primary target on the wire, clocking 186 stories this week alone. Government follows at number two with 136. This isn't because attackers love Linux kernels or policy papers; it's because that's where the high-value identity tokens live. We see a recurring pattern: a vendor releases a patch, a few organizations apply it, and then we find out three weeks later that the exploit was already integrated into an automated botnet before the patch was even written. We are operating in a window where the time-to-exploit is often shorter than the time-to-patch. The only way out of this cycle is to stop treating security as a series of patches and start treating it as a reduction of surface area. If you don't have static AWS keys, they can't be leaked. If you don't rely on a single identity provider for every single internal movement, an Entra ID flaw isn't a total collapse. The cost to move from static keys to an STS/IAM role-based architecture? For a mid-sized team, it's about two weeks of engineering time and a few hours of training for the devs. It costs almost nothing in licensing, but it costs a lot in ego because it requires admitting that your current "secure" setup is actually just a collection of secrets waiting to be found.