On the morning of May 12, 2017, the screens inside hospitals across England turned red. The message was identical on every one: your files have been encrypted, send $300 in Bitcoin, with a countdown clock ticking toward the moment the price doubled and then toward the moment the files were deleted for good. Staff taped handwritten signs to dead monitors and locked doors: *our computer systems are down.* Ambulances were waved off to other hospitals. Appointments stopped. Within hours, more than 200,000 machines in at least 150 countries were showing that same red screen.

The strange part was how it travelled. Nobody at those 200,000 machines had clicked anything. The malware moved on its own, jumping from computer to computer. And by that same evening it was stopped — not by a government or a security company, but by one researcher who spent about ten dollars registering a domain name. To understand how a web address halted a global attack, and why hospitals were in its path to begin with, you have to start with a decision made inside an American intelligence agency.

The ransomware was called WannaCry, and ransomware itself was old news by 2017 — malicious software that encrypts your files and demands payment for the key. The usual version arrives the usual way: someone opens a bad email attachment, and one organization’s files lock up. WannaCry broke from that in one decisive respect. It was a worm.

Most malware needs a person to make a mistake — click the link, open the file, run the program. A worm needs nothing. Once it infects one machine, it scans the network for other vulnerable machines and takes them automatically. It is the difference between a burglar, who needs someone to open a door, and a fire, which jumps from building to building on its own. A burglar robs one house at a time. A fire can take a city.

WannaCry took the NHS in hours. A third of England’s hospital trusts were hit. Five accident-and-emergency departments diverted patients elsewhere. Some 1,220 pieces of diagnostic equipment — MRI scanners, pathology systems, blood refrigerators — went dark. More than 19,000 appointments and operations were cancelled. No deaths were recorded, but the UK government’s own assessment was blunt: lives were put at risk. The worm did not discriminate by sector or border. Telefónica in Spain, Renault in France, Nissan in England — it went wherever an unpatched machine was listening.

Every Windows computer has a built-in way to share files and printers across a network — a decades-old protocol called Server Message Block, or SMB. Picture a mail slot cut into every office door: drop a document through one office’s slot and it lands in the next. SMB is always listening, the way a mail slot stays open even when nobody expects a delivery.

In 2017 there was a flaw in the slot — catalogued as CVE-2017-0144 — that let an attacker push a specially crafted message through it and run code on the machine at the other end. No username, no password, no permission of any kind. The slot was no longer just accepting documents. It was accepting instructions.

The tool that exploited that flaw was called EternalBlue, and it was not built by criminals. It was built by the United States National Security Agency. Like every major intelligence service, the NSA develops ways to break into software for surveillance work, and EternalBlue was one: a method to silently enter any unpatched Windows machine over a network.

When an intelligence agency finds a flaw in software the whole world runs, it faces a fork. It can tell the vendor, so the hole gets patched and every civilian machine is protected. Or it can keep the flaw secret and build a weapon from it, leaving those machines exposed for as long as the secret holds. EternalBlue was the second choice: the NSA found a flaw in a protocol running on virtually every Windows computer on Earth and chose to keep it. That is a defensible decision from an intelligence standpoint. It also staked the security of millions of civilian machines on a single assumption — that the weapon would never leave the building.

On April 14, 2017, the assumption failed. A group calling itself the Shadow Brokers dumped a collection of stolen NSA tools onto the open internet. EternalBlue was in it — and so was DoublePulsar, a kernel-level implant that installs itself beneath the floor the security guards patrol, in the operating-system layer most security software never inspects. Overnight, a classified capability became free attack infrastructure for anyone who could download it.

Someone did. WannaCry’s earlier versions, seen in small attacks that spring, had spread the old way, with stolen passwords. The version that detonated on May 12 had EternalBlue welded into it, so it needed neither a password nor a person — it opened the door itself. Once on a machine it encrypted the files and began scanning the local network and the open internet for any computer with port 445, the door reserved for SMB traffic, left open. Where it found an unpatched one, EternalBlue forced the door and DoublePulsar carried the ransomware through; that machine encrypted itself, raised its own red screen, and started scanning for the next. Each victim became a launch point, the spread compounding until by nightfall it had reached more than 150 countries.

Microsoft had already fixed the flaw. On March 14, 2017 — two months before the outbreak, a full month before the Shadow Brokers even leaked the exploit — it published security bulletin MS17-010, closing CVE-2017-0144 and several related holes. The fix was free. NHS Digital, responsible for cybersecurity guidance across the health service, sent trusts critical alerts in March and April urging them to install it. The warnings ran back further still: leave Windows XP, the government had told trusts as far back as 2014, since Microsoft no longer issued security updates for it — deadline April 2015.

On May 12, the machines that had not applied the free patch were the machines that turned red. The ones that had were untouched.

Buried in WannaCry’s code was one odd instruction. Before encrypting anything, the malware tried to reach a specific, gibberish web address that pointed to no website. If the address answered, the malware switched itself off. If it did not, it proceeded. On the evening of May 12, a security researcher, picking through the code, saw that dead domain and registered it for $10.69. The instant it went live and began answering, every fresh copy of WannaCry that phoned home received a reply — and obeyed its own instruction to stop.

The check was almost certainly a defense against analysis. Researchers study malware by detonating it in a sandbox — a sealed environment that often fakes internet connectivity by answering every domain lookup. WannaCry’s authors appear to have built the dead domain as a tripwire: a nonexistent address that answered meant the software was being watched, so it shut down to hide. The logic held only as long as the domain stayed unregistered — and its authors assumed it always would.

The kill switch saved no one already infected — those files stayed locked — but new infections dropped to almost nothing. The firm that ran the domain as a sinkhole later estimated it absorbed 14 to 16 million further infection attempts over the next two weeks. By May 17, most NHS services were back, and Microsoft had shipped emergency patches for Windows XP and other operating systems it had officially stopped supporting years earlier.

The question of authorship took longer. In December 2017, the United States publicly attributed WannaCry to the Lazarus Group, an arm of North Korea’s Reconnaissance General Bureau, with the United Kingdom, Australia, Canada, Japan, and New Zealand concurring. The case rested on the code itself. A Google researcher, Neel Mehta, had spotted that a distinctive slice of WannaCry was identical to code in the malware that destroyed Sony Pictures’ network in 2014 — an attack long attributed to the same group. Shared cipher routines, shared data tables, shared file-deletion functions: the fingerprints matched, and reached back to Sony and forward to the 2016 theft of eighty-one million dollars from Bangladesh’s central bank.

That lineage explains the motive. Most states that run offensive cyber operations — the US, Russia, China, Israel — do it for intelligence, and avoid visibly wrecking civilian systems, because wreckage becomes a diplomatic crisis. North Korea, walled off by sanctions, uses its hackers to raise money instead: bank theft, cryptocurrency fraud, ransomware. WannaCry fit the pattern — not espionage, but a revenue operation aimed at civilians, and a dismal one at that. For all the hospitals it froze, it collected roughly $140,000 in ransom, and the NHS paid none of it. The Justice Department later charged three North Korean operatives and the Treasury sanctioned one of them; a money launderer for the group drew an eleven-year sentence. The principal defendants remain in North Korea, beyond reach.

WannaCry is what happens where two decisions to leave a known danger in place meet. The first was made in an intelligence agency that found a flaw in software the whole world runs and chose to keep it rather than fix it, betting the weapon it built would never escape. The second was made, thousands of times over, in every organization that received a free patch and a written warning and did not act on them. The first decision created the weapon. The second decided where it landed. Neither was exotic; both were the ordinary result of treating a known risk as tomorrow’s problem.

The controls that would have contained it were all on the record before May 12: patch promptly, retire operating systems too old to patch, close port 445 at the network boundary, and wall critical medical devices off from ordinary office PCs. Britain rewrote its NHS cyber playbook afterward. But the lesson underneath was never a missing control. WannaCry did not exploit a secret. It exploited the distance between a fix that already existed and the machines that never received it. That distance was measured in months for some organizations and in years for others, and a weapon built in secret found every place it was widest. A great many of those places turned out to be hospitals.

## Sources & further reading

- **UK National Audit Office** — *Investigation: WannaCry cyber attack and the NHS* (2018): the definitive account of the NHS impact, the unpatched-systems finding, and the timeline.

- **NHS England / Department of Health and Social Care** — *Lessons learned review of the WannaCry ransomware cyber attack* (February 2018): the 1,220 affected devices and the operational response.

- **UK Parliament, Public Accounts Committee** — report on the NHS and WannaCry, on patch management and legacy systems.

- **Microsoft Security Response Center** — bulletin MS17-010 (March 14, 2017) and the out-of-band *Customer Guidance for WannaCrypt attacks* (May 2017).

- **U.S. Department of Justice** — the 2018 complaint against Park Jin Hyok and the 2021 indictment of three Lazarus Group operatives, laying out the Sony–Bangladesh–WannaCry code lineage.

- **CISA / US-CERT** — technical alerts and indicators for WannaCry and North Korean cyber activity.

- **Kryptos Logic** — operator of the kill-switch sinkhole; source for the 14–16 million infection attempts absorbed.

On September 8, 2018, a monitoring tool inside Marriott International’s network flagged a single query it could not explain. Something was reading the Starwood guest reservation database in a pattern that matched no legitimate operation. Pulling on that one thread unwound four years of history. It led back to July 2014 — to a time when the compromised systems did not belong to Marriott at all. They belonged to a company Marriott had not yet announced any intention to buy.

The intruder had been inside Starwood’s network before the acquisition was public. Still inside when the deal closed. And inside for two more years after that, while the two companies spliced their systems together one migration at a time. The question this breach leaves on the table is an unusual one: how does an attacker survive a corporate merger?

Starwood Hotels & Resorts ran thousands of properties across dozens of countries, tied together by a loyalty program called Starwood Preferred Guest. Book a room and you handed over your name, address, phone number, email, date of birth, and payment card — and, travelling internationally, your passport number. For loyalty members the database also kept arrival and departure dates and reservation histories. It filled the way a filing cabinet fills when no one is assigned to empty it: one guest at a time, year after year. Some folders dated back to 2002.

In November 2015, Marriott announced it would acquire Starwood; the deal closed in September 2016. What Marriott also acquired — though this would not surface for two more years — was an active intrusion that had been running inside Starwood’s network since July 2014.

When Marriott finally disclosed the breach on November 30, 2018, the first estimate reached as high as 500 million guests. Forensic work later settled the figure at roughly 339 million records exposed worldwide. For a limited set of guests, the exposure included unencrypted payment card numbers. And for 5.25 million guests, it included unencrypted passport numbers.

That last category is the one most breaches never reach. A compromised payment card is cancelled and reissued in days. Replacing a passport takes a government office visit, a fee, and weeks of processing — and in the interim the number stays valid, still tied to its holder in every system that ever recorded it. Those costs — new passports, replacement cards, identity monitoring — fall on the people whose data was held, not on the company that held it.

The way in was a Starwood web server — one of the systems that faced the public internet, taking requests from outside. In July 2014, an attacker reached that server and planted a web shell.

A web shell is a small piece of code left on a web server that hands whoever planted it a remote command line — the ability to run instructions on that server from anywhere, at any time, as if seated at its keyboard. Picture a hotel lobby that never closes, and someone who walks in during business hours, finds a service corridor, and mounts a hidden phone behind a utility panel. From then on they call in whenever they like and have their instructions carried out inside the building. The lobby stays open. The guests keep arriving. The phone is invisible to anyone who does not already know it is there.

From that foothold the attacker installed three separate remote-access trojans — tools that hold open a persistent channel back to the attacker’s own machines. One web shell can be found and removed; three redundant channels mean losing one is not losing the network. Then came the step that turned a foothold into free movement: credential harvesting with a well-known tool called Mimikatz. When someone authenticates to a server — an administrator logging in, an application connecting to a database — the system briefly holds those credentials in active memory, because it needs them for the session. That necessity is also a weakness. The credentials sit there the way a sign-in sheet at a security desk holds every badge number currently checked in: the desk needs the sheet, but anyone who can read the desk can read every badge on it. Mimikatz reads the desk — scanning memory for what the operating system has already placed there, no cracking or guessing required. On Starwood’s server it harvested highly privileged administrative credentials. Not the key to one room. The keys that managed the building.

Those credentials unlocked the network. Regulators later mapped the movement: more than 480 systems compromised across 58 locations — corporate offices, data centres, and individual hotels, linked by the corporate network that ties every property back to the central reservation system. The attacker moved laterally, planting key loggers and memory-scraping malware to gather still more credentials along the way. Nothing forced them to stop. Network segmentation — the internal walls that keep a compromise in one area from becoming access to every other — is the control that should have broken that movement. Starwood’s walls were not there, and the path from the web server to the reservation database was open.

The interval between that first compromise and its discovery ran more than four years, against an industry median measured in weeks or months — a category of persistence that outlasted operating-system upgrades, staff turnover, and a change of corporate ownership.

By the time the acquisition closed in September 2016, the attacker had been inside for over two years, and the work of merging two companies was only starting: systems inventoried, networks consolidated, accounts migrated, data moved off legacy platforms. A corporate acquisition audits assets with real rigour — properties, brands, revenue, contracts. What it does not audit with the same rigour is the security posture of every system it absorbs. Regulators later named the gaps that let the intruder ride through: multi-factor authentication not fully deployed, especially for administrative accounts; monitoring too thin to catch the attacker’s tools; software outdated and unpatched. None of those gaps appeared during the merger — they predated it. The merger was simply the moment they became Marriott’s, inherited alongside the brands and the guest database. With read-and-write access the whole time, the attacker could watch the integration happen: which systems were being consolidated, which were getting attention, which were not. They did not have to evade a team hunting for them — only to stay in the spaces no one was watching, and the monitoring that would have watched those spaces had never been built.

In July 2018, four years in, the attacker added one more tool: an open-source VPN — an encrypted tunnel into a network they had occupied since 2014. Organizations use VPNs routinely to let employees reach internal systems from outside; the attacker built one for the same purpose. Two months later, it was the thing that finally got noticed.

The alert came from IBM Guardium, a database activity monitor — a tool that watches the queries hitting a database and compares them against the patterns legitimate systems produce. On September 8, 2018, it flagged a query against the guest reservation database that did not fit. Guardium caught what years of network monitoring had missed, and the reason is the whole lesson: it was watching the database itself, not the network around it. The attacker’s tools had lived on hundreds of systems without tripping an alert, because coverage across the broader network was too sparse to produce one. It took a monitor trained on the exact system the attacker was ultimately after to see anything at all — a demonstration of what happens when monitoring exists in one place and not the others.

Eighty-three days then passed between that alert and public disclosure while investigators established the scope — days in which the company knew 339 million people’s information had been taken and those people did not. That asymmetry sits inside every breach timeline; the only variable is how long it lasts.

Who the intruder was, the public record does not say. The regulatory complaint calls them only “malicious actors” — no threat group named, in it or in the securities filings or the settlements, and no arrests publicly tied to this intrusion. Several news organizations reported that investigators suspected Chinese state-sponsored actors, but that attribution never entered the primary legal record. Who was inside that network, and why, remains formally unanswered.

Marriott reported $198 million in breach-related expenses through the first three quarters of 2019 alone, offset by roughly $77 million in insurance recoveries. Forty-nine U.S. states and the District of Columbia reached a combined $52 million settlement. The UK’s data-protection regulator, after proposing a penalty of nearly £100 million, ultimately issued £18.4 million — European data-protection law applying only to the portion of the breach after May 2018. And the Federal Trade Commission ordered Marriott to run a comprehensive security program under independent assessment every two years for the next twenty.

The most telling part of that order was not the security program but a requirement to delete guest data that no longer serves an active business purpose — a direct answer to a database still holding records from 2002. A guest who checked in that year and never returned still had their name, address, and date of birth in a live system sixteen years later, reachable by anyone who got that far. Deleting data past its useful life has a name — data minimization — and its absence is a policy gap, not a technical one. Every year a database runs without review, the pile an intruder can reach only grows.

What separates this breach from a story about sophistication is that none of the attacker’s tools were exotic. A web shell. Mimikatz. Off-the-shelf remote-access trojans. An open-source VPN. All of it documented, widely known, some of it free. The attacker did not need to invent anything — only a network whose foundational controls, from authentication to encryption to data retention, had gaps wide enough to move through quietly for four years, straight through a corporate acquisition, without being seen.

The distance underneath this breach is the distance between acquiring a company and auditing its defences. An acquisition transfers the assets. It transfers the exposure just as completely — every unpatched system, every unwatched segment, every administrative credential without a second factor. What the purchase agreement does not transfer, unless someone insists on it, is visibility into what is already living inside the infrastructure being bought. Four years of an attacker moving through a database as it changed hands between two companies is what that distance looks like when someone is standing inside it.

Zerodaylogs Ep14 Technicalbreakdown V1

550KB ∙ PDF file

Download

Download

Sources & further reading

- **U.S. Federal Trade Commission** — the complaint and final order, *In the Matter of Marriott International, Inc. and Starwood Hotels & Resorts Worldwide* (2024): the attack path, the 480-systems / 58-locations scope, and the itemized missing controls.

- **Marriott International SEC filings** — the 8-K disclosing the breach (November 30, 2018) and subsequent 10-K / 10-Q filings reporting breach-related expenses and insurance recoveries.

- **UK Information Commissioner’s Office** — the penalty notice against Marriott International (October 30, 2020): the £18.4 million fine, reduced from a proposed £99.2 million.

- **Office of the Privacy Commissioner of Canada** — the joint investigation report under PIPEDA into the Starwood breach.

- **State Attorneys General** — the 2022 multistate settlement ($52 million across 49 states and the District of Columbia).

- **U.S. Senate** — the 2018–2019 committee hearing record examining the Marriott/Starwood breach and its disclosure timeline.

By the first week of December 2014, Sony Pictures Entertainment was writing its employees’ paychecks by hand. The machines that normally issued them were dead. Staff pulled old BlackBerry devices out of storage closets because corporate email no longer functioned. The company could not close its third-quarter financial statements, because the systems that processed the numbers no longer existed in working form. Somewhere between seven and eight thousand workstations had gone dark at once, and Sony had pulled its entire network off the public internet to stop whatever was still spreading.

The visible trigger was a single image. On the morning of November 24, a glowing red skeleton and a block of text signed by a group calling itself the Guardians of Peace appeared on every working screen in the company. But the people who put it there had been inside the network for two months. The message was the loud ending of a breach that had begun very quietly.

## Two months of silence

The entry point was an email. It arrived on September 25, 2014, from a Hotmail address, offering advertising video clips and carrying an attachment named to look like an Adobe Flash video. The file was not a video. It was a program, and it executed the moment it was opened.

Ordinary phishing casts a wide net: thousands of identical messages, generic enough to fool a small percentage of anyone who receives them. Spear phishing narrows the net to one person. The attacker researches a specific individual, writes a message tailored to their role, and sends it directly to them. It is the difference between a flyer shoved under every door on the block and a letter addressed to you by name, referencing your job title, arriving from someone you would plausibly hear from. The generic version relies on volume; the targeted version relies on research. Research is what the next two months were for.

Between mid-September and November 24, the attackers held quiet, persistent access. Security teams have a term for the interval between an intruder getting in and anyone noticing: dwell time. Two months of it bought two months of reconnaissance. The attackers did not sit on the machine they first compromised; they moved through the network the way a burglar who enters through the mailroom works toward the executive floor, opening doors along the way. And as they moved, they took inventory. They catalogued roughly ten thousand individual machine names: workstations, servers, and the specific addresses of the systems employees logged into every day. This was not confirming that a building existed. It was photographing every office number and every nameplate inside it.

Those ten thousand names were then written directly into the malware the attackers would detonate on November 24. They were hard-coded, baked permanently into the program’s instructions, so that when it ran it did not need to hunt for targets. It already held the address of every machine on its list. The weapon was not a general-purpose tool that happened to be pointed at Sony. It was manufactured for this one network.

## An arsonist, not a burglar

Most malware in a major incident wants something. Ransomware scrambles an organization’s files and demands payment for the key; the data is leverage. Data-theft operations copy files out and walk away with the information itself, to sell or to publish. Both are crimes of acquisition: the attacker takes something valuable and either ransoms it or keeps it.

What hit Sony wanted nothing. The primary component, a wiper that researchers named Destover, did not steal or encrypt or hold anything hostage. It destroyed. Where ransomware locks a door and names a price to reopen it, a wiper burns the building down. There is no key and no negotiation, because no copy was ever kept to sell back. Data is overwritten, replaced with garbage or zeroed out, and the machines that held it are left inoperable. Destover did not work alone: a network worm called Brambul spread it automatically from machine to machine, and a hidden backdoor kept the attackers’ connection alive throughout. Because a wiper destroys rather than locks, recovery could not be a payment. It had to be a rebuild from nothing, which is why the paychecks went out by hand.

The destruction was only half of it. The wiper annihilated what was inside the network, but before it ran, the attackers had copied the most sensitive material out: the personal records of more than forty-seven thousand current and former employees and their families, including Social Security numbers, salaries, medical histories, and background checks. The fire consumed the originals, and the theft guaranteed that copies survived outside, in the attackers’ hands and eventually in public. A stolen credit card can be cancelled overnight. A Social Security number cannot be reissued, and a medical history cannot be changed. The plaintiffs in the class action that followed alleged they would have to guard against identity theft for the rest of their lives.

## Convergence

U.S. investigators attributed the attack to the Lazarus Group, also tracked as Hidden Cobra, a unit tied to North Korea’s Reconnaissance General Bureau. Attribution in these cases rarely rests on one decisive clue. It rests on convergence: several independent lines of evidence, each circumstantial on its own, all pointing the same direction at once. The malware’s code and data-deletion methods matched tools seen in earlier North Korean operations. The command infrastructure overlapped with networks already tied to North Korean actors. The operators had routed their traffic through anonymizing proxies and leaned on infrastructure belonging to a company the Justice Department later identified as a North Korean front. No single thread was proof on its own, but together they made a case.

The consequences arrived in stages. In 2018, the Justice Department charged a North Korean national, Park Jin Hyok, for his role. In 2021, two more operatives were indicted on related charges. And the same case file connects forward: the fingerprints that tied a person to Sony tied the same person to the 2016 theft of eighty-one million dollars from Bangladesh’s central bank, and to WannaCry, the 2017 ransomware that seized hospitals and companies across more than a hundred countries. The unit that burned down a studio over a movie would, within three years, be stealing money at global scale. Sony is where it first stepped into public view.

The motive was the strange part. Sony was not attacked for espionage or for money. It was attacked in retaliation for a film, *The Interview*, a comedy built around the assassination of North Korea’s leader. A nation-state deployed a destructive cyber weapon against a movie studio because it objected to the content of a comedy. By the assessment of the people who responded to it, that made this one of the first major state cyberattacks driven by culture rather than by intelligence or sabotage.

## The warning and the weapon

Return to September 25, 2014, the day the spear-phishing email went out. On that same day, the consulting firm PricewaterhouseCoopers completed an audit of Sony Pictures’ security posture. The audit found that Sony’s security team had not been monitoring its firewalls and more than a hundred other network devices. A firewall is a gate between an internal network and the outside world, inspecting traffic and deciding what passes. Monitoring it means watching what it lets through: reading its logs, noticing the unusual pattern. Not monitoring it means the gate still stands, but no one is watching who walks past. For more than a hundred devices, no one was watching.

The class-action complaint added another detail: the attackers had exploited a known vulnerability. The word *known* is the one that matters. A known vulnerability has already been found, documented, and usually patched by the vendor. The fix exists. It has been published. The only open question is whether the organization applied it.

The controls the audit implied were missing were not exotic. Sony’s workstations could talk directly to one another across the network, so the Brambul worm spread without hitting a single internal wall. That is a failure of network segregation, the practice of dividing a network so that reaching one part does not mean reaching all of it. Social Security numbers and passwords were found sitting in clear-text files, readable by anyone who opened them, because the most sensitive data the company held had never been encrypted. And there was no second factor behind the stolen passwords, no requirement to prove possession of a physical device on top of knowing the password, so every credential harvested through the phishing campaign was a working key with nothing behind it. None of these are rare findings. They are the routine contents of security audits across every sector.

The auditor and the attacker described the same weaknesses on the same day. The auditor’s version became a report that recommended fixing them. The attacker’s version became the malware that used them.

## The pattern

The lesson here is not that an audit failed to prevent a breach. Audits identify problems; organizations either act on them or they do not. Attackers succeed in the interval between knowing a gap exists and closing it, and Sony’s interval was wide. Its missing controls had been standard practice across the industry for years before the attack. The policy world absorbed the shock afterward: a 2016 presidential directive clarified how federal agencies coordinate during a major cyber incident, and the Cybersecurity Act of 2015 built new channels for sharing threat information between companies and the government. None of it changed the underlying arithmetic. Somewhere in most organizations is a document listing the weaknesses someone has already found. What decides how a story like this ends is how quickly that document turns into action.

Zerodaylogs Ep13 Technicalbreakdown V1

547KB ∙ PDF file

Download

Download

## Sources & further reading

- **FBI** — *Update on Sony Investigation* (December 19, 2014): the Bureau’s public attribution to North Korea.

- **U.S. Department of Justice** — the criminal complaint against Park Jin Hyok (2018) and the superseding indictment of three Reconnaissance General Bureau–affiliated operatives (2021): the most detailed technical account of the Lazarus toolset, linking Sony to the Bangladesh Bank heist and WannaCry.

- **CISA / US-CERT** — the “HIDDEN COBRA” advisories on North Korean state-sponsored cyber activity.

- **Corona v. Sony Pictures Entertainment** — the employee class-action complaint: source for the PwC audit findings, clear-text credential storage, and the 2016 settlement.

- **Novetta** — *Operation Blockbuster* (2016): independent analysis of the malware family behind the attack.

- **The White House / U.S. Congress** — Presidential Policy Directive 41 (2016) and the Cybersecurity Act of 2015 (enacted within H.R. 2029).

It wasn’t. Four years later, a dataset surfacing on a dark web marketplace revealed the actual number: a hundred and sixty-seven million accounts. And because of how those passwords had been stored, researchers cracked the vast majority in under twenty-four hours.

The gap between 6.5 million and 167 million is where this story lives.

How it actually happened

For years, the explanation for how the attacker got in was SQL injection — a database manipulation technique that appeared in civil litigation filings. The criminal trial told a different story. The attacker, Yevgeniy Nikulin, targeted a single LinkedIn employee whose work machine was running a virtual machine — a sealed environment hosting a personal web server as a side project. Think of a house with a sealed room inside it. As long as the room holds, the side project is harmless. Nikulin broke out of the room, through a flaw in the software layer beneath it, and from there reached the employee’s access to LinkedIn’s corporate network.

One stolen VPN credential later, he had the entire user database.

Why salting was the whole game

What he took were hashed passwords — passwords run through a one-way mathematical transformation. Hashing alone wasn’t the failure. The failure was that LinkedIn didn’t salt its hashes: it didn’t add a unique random value to each password before hashing it. Without salt, ten thousand people who chose the same password produced ten thousand identical hashes. Crack one, and you’ve cracked all ten thousand. Salting wouldn’t have made any single password harder to break — it would have made the entire database exponentially harder to break at scale. That one decision is the difference between a nuisance and a catastrophe.

The four-year silence

LinkedIn’s response in 2012 was real and, measured against what it believed had happened, proportionate. It reset the 6.5 million accounts in the public dump. But it never determined that the entire database had left the building. The remaining 160 million accounts were never forced to reset — they sat unchanged, unsalted, and crackable for four years while the full database circulated privately. In 2016 it surfaced for sale. The same year, Microsoft bought LinkedIn for roughly $26 billion.

Why this is about you

A cracked password is only worth something if it’s reused. Credential stuffing — taking a stolen email-and-password pair and trying it automatically against hundreds of other services — turns one company’s breach into an attack on every platform where you used the same password. The LinkedIn database became foundational material for nearly a decade of these attacks against platforms that had nothing to do with LinkedIn.

The full breakdown — the intrusion, the hashing, the response, and the economy it created — is in the episode.

Zerodaylogs Ep12 Technicalbreakdown V1

49KB ∙ PDF file

Download

Download

🎧 Listen / watch above. Zero Day Logs is a documentary series on the security failures that shaped the internet.

In August 2013, Visa sent retailers a security alert describing malware that scrapes payment-card data out of a terminal’s memory. In January 2014, the FBI distributed its own warning about point-of-sale malware to the industry. The technique was named. The mechanism was described. Then, in April 2014, almost exactly that technique went live inside Home Depot’s self-checkout terminals and ran for five months.

This is the part that’s easy to misread as negligence and harder, and more useful, to read as structure. Nobody at Home Depot needed to invent a defense. The warnings existed. The PCI DSS requirements existed — firewalls, current antivirus, encryption in transit, monitoring. The FTC’s data-security guidance had existed since 2007. The gap was never knowledge. The gap was the distance between receiving a warning and confirming that the specific control it describes is actually in place, on the specific systems that matter, today.

That distance is where most breaches live, and it doesn’t show up on any dashboard. A warning arrives as a document. A control is a state of the world. The work that connects them — taking the alert, finding the exact systems it implicates, and verifying the control is on and current — is unglamorous, easy to defer, and almost never has an owner. Home Depot’s antivirus was a 2007 product still running in 2014. Somebody could have read the FBI alert and asked “is our endpoint protection current on the POS fleet?” The answer was available. The question was never connected to the warning.

So the practical takeaway isn’t “patch faster” or “buy the tool.” It’s to treat every external warning — every vendor advisory, every ISAC alert, every framework requirement — as a question that demands a confirmed answer about your own environment, with a name attached to confirming it. Not “we’re aware of this.” A verified, dated “this control is in place on these systems.”

One concrete starting point, and the question we left the episode on: what is the oldest piece of security software still running in your environment, and when did anyone last confirm it was current? If you can’t answer the second half quickly, that’s the distance.

The full technical breakdown of the breach — the network path, the memory-scraping mechanism, the response timeline, and the controls that were required but missing — is a free one-page PDF below.

Zerodaylogs Ep11 Technicalbreakdown V1

59.8KB ∙ PDF file

Download

Download

The technical part of the Pearson story is almost ordinary. A platform called AIMSweb, used by thousands of schools to track student progress, was running software with a known critical flaw. A patch existed. For roughly six months, nobody applied it. In late 2018, someone walked through the open door and left with around 11.5 million rows of student data — names, dates of birth, and in some cases email addresses — drawn from some 13,000 schools and universities.

If the story ended there, it would join a very long list. “The patch was available” is the most common sentence in breach forensics. What makes Pearson worth an episode is what happened next, in writing.

In 2019, Pearson described the incident to its investors as a risk that could occur — a hypothetical. By then the company had been notified by the FBI, had confirmed the data was taken, and had hired forensic consultants. The breach was not a possibility it was bracing for. It was a past event it was managing. In 2021 the SEC charged Pearson with misleading investors and the company paid a one-million-dollar penalty.

Notice what the penalty was for. Not the unpatched server. Not the six months. The SEC’s case was about the gap between what Pearson knew and how Pearson described it — the difference between “this might happen” and “this happened.” That gap is the whole episode in one sentence. A document existed. A decision existed. They never quite met.

There’s a practical takeaway hiding in here for anyone who isn’t a public company, too. The reason the unapplied patch is so common isn’t laziness; it’s that patching production systems is genuinely disruptive, and the cost of not patching is invisible right up until the moment it isn’t. The advisory that warned Pearson named the exact flaw that was later used. The warning and the fix arrived together, months early. The only missing step was the one nobody is rewarded for taking on an ordinary Tuesday.

The full one-page technical breakdown — the timeline, the vulnerability class, and the disclosure chain — is here:

Zerodaylogs Ep10 Technicalbreakdown V1

56KB ∙ PDF file

Download

Download

Zero Day Logs reconstructs one major cybersecurity incident a week — what happened, and what it teaches. If you want the next one in your inbox, subscribe. It’s free.

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