On November 14, 2016, two people contacted Uber to say they had downloaded the personal records of fifty-seven million users and drivers, and they wanted to be paid. Inside the company, the breach was confirmed within days. Within weeks, it was closed — passwords reset, multi-factor authentication required on the developer accounts that had been the way in, the exposed cloud key rotated, the datastore locked down. By any technical measure, Uber handled the incident quickly.

That is the part of the story that tends to get lost. The break-in itself was unremarkable. A password reused from another breach opened a private code repository. Inside the code sat an access key, written in plain text, that unlocked the datastore. The records were stored without encryption, so anyone who reached them could read them. None of the four controls that would have stopped this were exotic; all four were baseline, and the company put them in place once it knew. If the story ended there, it would be one more entry in a long ledger of preventable breaches.

It does not end there, and the reason it became a landmark has nothing to do with how the data was taken. It has to do with what happened after the company already knew.

When the breach was confirmed, Uber was not free to decide privately how to respond. Eighteen months earlier, after a separate 2014 compromise, the Federal Trade Commission had issued a Civil Investigative Demand — a binding legal instrument that, among other things, required Uber to report future unauthorised access to personal data. The order was active on the day the 2016 breach was confirmed. The obligation to disclose was not a matter of judgment or public relations. It was already law for this company.

What Uber did instead was route a hundred thousand dollars to the attackers through its bug-bounty platform, structured to look like a reward for a security researcher, and have them sign agreements stating that no data had been taken. The disclosure did not happen for a year.

The federal case that followed did not charge anyone for the breach. It charged Joseph Sullivan, the chief security officer, for the concealment — on two counts. Obstruction of justice covered withholding the breach from the FTC while its investigation was open and its order in force. Misprision of a felony covered something narrower and, for anyone in the field, more pointed: it is the crime of knowing a felony has occurred and taking active steps to conceal it. The distinction is the word active. A failure to report is an omission; the payment dressed as a bounty and the agreements asserting nothing was taken were acts, and it was the acts that turned an unmet reporting obligation into a personal crime.

A jury convicted Sullivan in 2022. He was sentenced to three years of probation in 2023. In March 2025, the Ninth Circuit Court of Appeals affirmed the conviction, which makes the precedent settled appellate law rather than a single jury’s verdict.

Here is the part the episode could only point at. For most of the history of corporate security, the consequences of a mishandled breach landed on the company: a fine, a consent decree, a quarter of bad headlines, sometimes a firing. The individual who made the call was insulated by the institution around them. That insulation is what the Sullivan case removed. The decision to conceal a known breach is now something a person can be convicted for, individually, regardless of what the company absorbs in parallel. The role of chief security officer carries an exposure it did not carry before — not for failing to prevent an attack, but for what one does in the hours after discovering one.

There is a second thread worth pulling, because it complicates a system the security industry generally regards as a good one.

A bug-bounty program is a standing arrangement: a company invites outside researchers to find weaknesses and report them through a managed platform, and pays them for doing so. The platforms exist to make that exchange orderly and documented. The payment is logged. The researcher’s identity is verified. The disclosure leaves a paper trail. All of that machinery is built to create a clean, auditable record of legitimate security work.

In this case, the same machinery was used to produce the opposite. The people being paid were not researchers who had found a flaw; they were attackers who had taken data and asked for money. The payment ran through the platform anyway, recorded as a reward. The agreements they signed entered the file as evidence that nothing had happened. Every artifact that normally signals a healthy disclosure — the logged payment, the verified identity, the signed paperwork — was present, and every one of them was pointed backward, building a record in which a breach of fifty-seven million people did not exist.

What that shows is that a process designed to create trust can also be used to launder its absence. A bounty payment is not self-authenticating. A reward in a platform’s ledger says that money moved through a channel; it does not, on its own, say the money paid for research rather than for silence. That distinction lives in facts the ledger does not capture — what was taken, by whom, and what was demanded — and those were exactly the facts the structure was being used to bury.

The four controls that were missing before this breach had all been available beforehand, the earliest of them for years. Putting them in place afterward took a matter of weeks. The breach was the recoverable part.

The concealment was not. Disclosure exists so that the people whose data was taken can act on it — watch their accounts, change what can be changed — and for a year, fifty-seven million people did not have that option. The law now treats the choice to impose that silence as one a person makes on their own account. That is the line the Uber case drew, and the appeals court has left it standing.

Zerodaylogs Ep09 Technicalbreakdown V1

29KB ∙ PDF file

Download

Download

Watch or listen to the full episode, and download the one-page technical breakdown — the timeline, the attack path, and the four controls that were missing — at zerodaylogs.com.

The episode itself traces the full technical chain: spear phishing, lateral movement, the User Database, forged authentication cookies. But the part I want to expand on here is the piece the SEC actually prosecuted — the disclosure gap.

What are disclosure controls?

The term sounds bureaucratic, and it is. Disclosure controls are the internal processes that connect the people who know something to the people who decide whether to tell the public. In a public company, these controls are a legal obligation under Sarbanes-Oxley. They exist specifically to prevent a situation where material information sits in one department while the company continues filing financial statements as if nothing has happened.

At Yahoo, the security team learned about the 2014 breach within days. The information then entered a chain of management reviews, legal assessments, and risk evaluations. Somewhere in that chain, it stopped. For nearly two years.

The SEC’s enforcement order didn’t charge Yahoo with being breached. It charged Yahoo with failing to maintain controls adequate to ensure the breach information was “properly assessed for potential disclosure.” The distinction matters: the breach was the attacker’s responsibility. The silence was Yahoo’s.

Why this matters beyond Yahoo

Before this enforcement action, the regulatory consequence for a breach was primarily about remediation — notify affected users, offer credit monitoring, pay for forensic investigation. The SEC added a new dimension: if you knew and didn’t tell investors, that’s a securities violation independent of the breach itself.

The 2018 SEC interpretive guidance that followed codified this. Public companies now have an explicit obligation to maintain processes for evaluating cybersecurity incidents for potential disclosure. The guidance doesn’t prescribe what those processes must look like. It says they must exist, and they must work.

The question worth asking

The episode ends with a question: if your organisation discovered a breach tomorrow, how many handoffs would it take before that information reached someone authorised to tell the public?

Map it. Count the steps. Identify where a finding could sit for weeks without escalation. That gap — between knowing and telling — is the thing the SEC decided it could measure and penalise. It’s worth measuring before a regulator does it for you.

Watch the full episode on YouTube. The technical breakdown is available at zerodaylogs.com.

Zerodaylogs Ep08 Technicalbreakdown V1

29KB ∙ PDF file

Download

Download

The episode traces the complete chain from entry to aftermath. But two details stuck with me long after the research was done, and neither gets enough attention in the usual coverage of this breach.

---

### 1. The pipeline was physically fine.

This is the part most people miss. The ransomware never touched the operational technology — the pumps, valves, and pressure systems that move fuel. DarkSide encrypted IT systems: billing, email, enterprise software. The physical infrastructure was verified intact after the shutdown.

Colonial shut the pipeline down voluntarily.

Why? Because the IT network and the OT network were connected, and once the IT side was compromised, Colonial couldn’t verify whether the OT side was clean. The CEO testified to this under oath: they couldn’t prove the attackers hadn’t crossed the boundary. So they shut everything down — not because the pipeline was broken, but because they couldn’t prove it wasn’t.

The shutdown wasn’t a technical failure. It was an uncertainty problem. The digital side couldn’t vouch for the physical side, so the physical side stopped.

That distinction matters because it changes what the fix is. The fix isn’t better ransomware detection (though that helps). The fix is architectural: the relationship between the IT network and the OT network needs to be designed so that losing one doesn’t force you to shut down the other.

---

### 2. Eleven years without an update.

TSA — yes, the airport security agency — is also responsible for pipeline cybersecurity. Their security framework for pipelines was last updated in 2010.

In 2010, ransomware was a consumer nuisance. By 2021, it was a professionalized industry with franchise models, affiliate programs, and quarterly revenue.

The GAO found that TSA’s pre-breach guidelines didn’t include key mitigations that were standard practice elsewhere. The agency responsible for pipeline cybersecurity was working from a framework that predated the threat it was supposed to defend against.

After Colonial, TSA issued two emergency security directives in rapid succession — the first mandatory cybersecurity requirements for pipelines ever. Incident reporting to CISA. 24/7 cybersecurity coordinators. Vulnerability assessments. Specific mitigation measures. Architecture reviews.

All things that could have been required before May 7, 2021. None of them were.

The eleven-year gap between the last regulatory update and the breach is the full width of the problem: the threat evolved across that entire span while the framework stayed frozen at the starting point.

---

### The episode

If you haven’t watched yet:

🎥 [Watch on YouTube](https://youtube.com/zerodaylogs)

🎧 Podcast drops in 2-3 days on all platforms

📋 [Free one-page PDF breakdown](https://zerodaylogs.com/colonial-pipeline)

Zerodaylogs Colonialpipeline Technicalbreakdown

26.6KB ∙ PDF file

Download

Download

Every episode of Zero Day Logs is built from primary sources — Senate testimony, CISA advisories, court filings, GAO reports — not headlines. If you find that approach valuable, subscribe. New episodes weekly

On September 20, 2013, an independent security assessor certified Target Corporation as PCI-DSS compliant. Eight weeks later, malware was running on nearly every cash register in the company.

This week’s episode traces the full attack path from an HVAC contractor’s stolen password to 40 million compromised payment cards. But the episode can only touch on what I think is the most important question the Target breach raised — and the one the compliance industry has still never fully answered.

Every control that appeared in Target’s post-breach settlement injunction — network segmentation, two-factor authentication, default credential elimination, application whitelisting, threat detection response — had been documented in existing guidance before the breach occurred. Most were in the same PCI-DSS standard Target had been certified against. The earliest guidance was four years old. The most recent was two years old.

Target was not operating without a framework. It had been assessed. It had been certified. The certification said it met the standard. The breach demonstrated that it did not.

This is not a Target-specific problem. The gap the Target breach exposed exists wherever compliance certification is treated as equivalent to operational security. Certification measures whether an organisation can demonstrate adherence to a set of controls at a point in time, under the conditions of the assessment, to the satisfaction of the assessor. Operational security is whether those controls are deployed, maintained, monitored, and responded to continuously.

These are different things. The Target breach is what happens when an organisation achieves the first and assumes it has achieved the second.

Three questions worth sitting with:

1. Who is the certification for? PCI-DSS certification exists because the payment card brands (Visa, Mastercard) needed a mechanism to distribute liability. If a merchant is certified compliant and still breached, the liability framework shifts. The certification serves the ecosystem’s risk distribution needs. Whether it serves the merchant’s actual security posture is a different question — and the Target breach suggests the answer is: not necessarily.

2. What does “point in time” mean in practice? Target was certified in September 2013. The breach began in November 2013. Two months. The certification did not become wrong in those two months — the gaps it failed to catch were there during the assessment. The point-in-time framing implies that security is a snapshot. In practice, security is a continuous state, and snapshots can miss what was already there.

3. What happened to Trustwave? The assessor that certified Target compliant eight weeks before the breach — Trustwave — was later retained by Target as part of the incident response team. The same organisation that certified the security posture that failed was brought in to help recover from that failure. This is not inherently corrupt — Trustwave had deep familiarity with Target’s systems. But it illustrates a structural tension in the compliance ecosystem that remains unresolved.

The full episode covers the technical attack path, the missed alerts, the financial consequences, and every missing control with its pre-breach guidance date. The one-page PDF summary is available for download below.

Zerodaylogs Ep06 Technicalbreakdown V1

61.9KB ∙ PDF file

Download

Download

The patch was never applied. Two months later, attackers walked through the door — and spent seventy-six days inside.

What the episode covers

The full 2017 Equifax breach — from the OGNL injection mechanism that turned a text field into a command line, to the vulnerability scanner that checked the wrong directories, to the SSL inspection appliance that had been blind for over a year because nobody renewed a certificate. The breach response that created a fake-looking real website, buried an arbitration clause in the credit monitoring terms, and issued sequential PINs that anyone could guess. The insider trading convictions. And the 2020 federal indictment that revealed the attackers were four members of the Chinese military — and that the stolen data was never sold. It was intelligence.

The part the episode couldn’t go deeper on

Equifax is not a service you sign up for. Banks, lenders, landlords, and employers report your financial activity to Equifax as part of the system’s infrastructure. You did not choose this relationship. You cannot leave it. There is no alternative provider you can switch to, no account you can close, no terms of service you agreed to and can revoke.

Before 2017, freezing your credit report cost money in most states — you had to pay the company that lost your data for the privilege of locking it down. The Equifax breach changed that. The Economic Growth, Regulatory Relief, and Consumer Protection Act, signed in May 2018, made credit freezes free nationwide. That was a direct legislative consequence of the breach.

But the underlying structure hasn’t changed. Equifax still collects your data without your consent. It still sells access to your credit profile to any institution with a permissible purpose. The 2019 settlement required Equifax to implement a comprehensive information security programme with third-party assessments every two years — controls that had been available, documented, and recommended before the breach occurred. The earliest by nearly a decade.

The fundamental question isn’t whether Equifax’s security has improved. It probably has. The question is whether an organisation that holds the data that defines your financial identity — collected without your consent, stored without your control — should be allowed to operate without your explicit, revocable permission. That question remains unanswered.

Technical breakdown

The full technical breakdown — the complete attack timeline, the OGNL injection mechanism, the expired certificate blind spot, every missing control with its pre-breach availability date, and the intelligence mosaic connecting Equifax to the OPM, Anthem, and Marriott breaches — is available as a free downloadable PDF.

Zerodaylogs Ep05 Technicalbreakdown V1

85.1KB ∙ PDF file

Download

Download

This week’s episode covers the July 2020 Twitter breach — the incident where a 17-year-old in Tampa, Florida, hijacked the verified accounts of Barack Obama, Joe Biden, Elon Musk, Bill Gates, and dozens of others to post a Bitcoin scam.

The episode tells the full story: the vishing calls, the real-time credential relay, the Agent Tools admin panel, and the three phases that escalated from credential theft to OG handle seizure to the hijacking of world leaders’ accounts. The New York Department of Financial Services investigated and published one of the most detailed public post-mortem reports ever issued for a cybersecurity incident.

The episode covers the DFS findings in full. This companion expands on two specific takeaways that the episode could only touch on briefly.

The real-time credential relay deserves a closer look.

The mechanism that defeated Twitter’s MFA is not exotic. The attacker sets up a fake login page. The employee types credentials into it. The attacker immediately enters those same credentials into the real site. The real site sends a push notification to the employee’s phone. The employee, expecting exactly this prompt, approves it. The attacker is now authenticated.

What makes this worth pausing on is that the employee did everything right. They used MFA. They approved the prompt they expected. The failure isn’t human error — it’s an architectural limitation. Application-based MFA verifies the user. It does not verify the site. A hardware security key does both: it checks the web address cryptographically, finds the mismatch, and refuses to respond. Against a credential relay, the distinction between these two approaches is the entire story.

The DFS report concluded that hardware MFA would have stopped the attackers. Not “might have reduced the risk.” Would have stopped them. The mechanism the attackers used simply does not work against keys that verify the site’s identity before responding.

If your organisation uses push-notification MFA or TOTP codes for critical systems, the Twitter breach is the case study for why hardware keys matter for high-privilege access. The relay attack is fast, requires no sophisticated tools, and defeats the security control most organisations consider sufficient.

The missing CISO is the structural story beneath the technical one.

Twitter had no Chief Information Security Officer for seven months before the breach. The position had been vacant since December 2019. A new CISO was hired in late September 2020 — after the breach.

The DFS report identifies five specific controls that were absent: hardware MFA, access scope restrictions on Agent Tools, anomaly detection, access tier separation, and secondary approval for sensitive actions. Every one of these controls existed, was documented, and was available for deployment. None were deployed.

The episode poses the question but doesn’t answer it, because the answer isn’t technical: why would any company leave these controls undeployed? The episode’s thesis line offers one framing — “Security controls are the only category of investment whose success is indistinguishable from its absence.” When security works, nothing happens. When nothing happens, it looks identical to not having security at all. The CISO is the role that makes the case for investing in the absence of visible threat. When that role is empty, the case doesn’t get made.

The DFS report went further than most regulatory investigations. It recommended that social media platforms be treated as systemically important institutions — subject to the same kind of stress testing that banks undergo. The counterargument is structural: platforms change their code daily, serve users across all jurisdictions, and have no existing examination framework. Whether that counterargument holds is the open question the episode leaves with the viewer.

The full technical breakdown PDF — covering the complete attack timeline, the credential relay mechanism, the Agent Tools access scope, and the five missing controls — is available for free download at zerodaylogs.com.

Zerodaylogs Ep04 Technicalbreakdown V1

29.4KB ∙ PDF file

Download

Download

This is the companion technical breakdown for Zero Day Logs Episode 03.

In 2020, a foreign intelligence service walked through the front doors of the US Treasury, the Department of Homeland Security, and parts of the Department of Defense. They were invited by a software update that every security check confirmed was completely legitimate. Because it was.

The full technical breakdown covers the SUNBURST backdoor architecture — the build pipeline compromise, the 12-14 day sandbox evasion, DNS covert command-and-control, and the selective activation of approximately 100 of 18,000 infected networks. It documents how FireEye’s investigation of its own breach exposed one of the largest intelligence operations in history, the three missing controls and what each would and would not have stopped against a nation-state adversary, and the formal attribution to APT29 and the Russian SVR.

It also covers what changed after — from Executive Order 14028 mandating software bills of materials, to the SEC case against SolarWinds that was dismissed in November 2025.

Zerodaylogs Ep03 Solarwinds Technicalbreakdown

48.7KB ∙ PDF file

Download

Download

This is the companion technical breakdown for Zero Day Logs Episode 02.

Okta processes billions of authentication requests per month for over eighteen thousand organisations. It is the invisible gatekeeper sitting between employees and every system they log into — at governments, banks, and technology companies across the globe. It was breached in 2022. Twenty months later, it was breached again.

The full technical breakdown covers both breaches: the 2022 Lapsus$ contractor compromise and the 2023 HAR file session cookie theft, including the November 29th expanded disclosure revealing the full customer contact list harvest. It documents the three missing controls, the downstream impact on Cloudflare, 1Password, and BeyondTrust, and how a service account credential moved outside every corporate security control through Chrome’s password sync.

It also covers what good vendor accountability looks like — contractual disclosure timelines, independent verification over self-reported questionnaires, and why the vendors trusted most deeply are structurally the highest-risk link in the chain.

Zerodaylogs Ep02 Okta Technicalbreakdown

46.5KB ∙ PDF file

Download

Download

This is the companion technical breakdown for Zero Day Logs Episode 01.

In September 2023, a group of attackers brought MGM Resorts to a standstill. No software vulnerability was exploited. No sophisticated malware was deployed. The public record shows a single phone call to an IT help desk.

The full technical breakdown covers the complete attack timeline, the step-by-step attack chain from LinkedIn reconnaissance through SAML token forgery to ESXi ransomware deployment, the three missing controls that would each have independently broken the chain, and what the post-breach remediation confirms about what was absent.

Written for two audiences: security practitioners who want the precise technical record, and everyone else who wants to understand what this breach means for them personally.

Zerodaylogs Ep01 Mgm Technicalbreakdown

35.2KB ∙ PDF file

Download

Download