PHP is the program on a web server that puts a page together before it reaches your browser. By W3Techs’ measure, it runs about seven of every ten websites whose server-side language can be identified. The flaw sat in the part of PHP that lays each request out in memory. When a request ran out of memory part-way, PHP stopped abruptly, and the cleanup step that followed could treat the half-built data as complete. A second, related flaw let one request’s leftover memory reach a later request on the same worker. One fix closed both.

The PHP Foundation says a developer it had contracted found the first signs of the problem in 2024, and wrote that “the delay was a structural failure”. In August 2026, researchers working with AI tools proved the flaw could be used to run their own code on a server. As of 23 October, no authority had confirmed that any named organisation had been broken into through these flaws.

The video follows how the flaw works, why so many sites switched off, what the fix changes, and where the disagreements still stand.

Zerodaylogs Sp003 Technicalbreakdown V2

4.38MB ∙ PDF file

Download

Download

On 12 February 2024, someone logged in to one of its remote-access portals with a username and password that were not theirs. The portal did not ask for a second check. To the system, the login looked like an employee arriving for work. Over the next nine days the attackers moved through the network and copied data out. On 21 February they set off ransomware, and it reached the backup environments too.

UnitedHealth Group, which owned Change, took it offline to contain the attack. With Change offline, many providers could not check a patient’s coverage, submit claims or get paid, and some pharmacists filed claims by hand. UnitedHealth paid a ransom of 22 million dollars in bitcoin, and put the attack’s cost to itself for 2024 at about 3.1 billion dollars. The count of people potentially impacted grew over time, to about 192.7 million.

The video follows how that one login worked, why backups could bring the systems back but could not recall the copy already taken, what the public record says about who claimed the attack, and where the investigation and the lawsuits stood on 26 September 2026. None of those cases is a finding of wrongdoing.

Zerodaylogs Ep25 Technicalbreakdown V2

4.11MB ∙ PDF file

Download

Download

On the nineteenth, Rockstar confirmed it. An unauthorized third party, the company said, had illegally accessed and downloaded confidential information from its systems, including early development footage for the next Grand Theft Auto. Rockstar said it did not anticipate any disruption to its live game services, nor any long-term effect on the development of its ongoing projects. The same day, Take-Two noted the intrusion in a filing to the SEC.

Take-Two’s next quarterly filing put a figure on the damage in its own words. This intrusion, together with a separate incident at another of its labels, had brought “immaterial incremental one-time costs,” for consultants, experts and data recovery. The company took in more than five billion US dollars in revenue in the financial year that included the breach, so a real cost could still be immaterial against a number that size. The same filing said security breaches, including this one, had negatively affected its operations and financial results.

The footage was the loss people saw. The more serious one, by the accounts published since, was source code. Rockstar’s statement named only confidential information and footage. According to The Record, the forum post that carried the clips also attached source code as evidence. The Cyber Safety Review Board, the federal panel that later reviewed a string of attacks on major companies, records in its 2023 report the theft and publication of source code for two flagship games from a gaming company, and that entry cites the forum post itself. Footage shows what a game will look like; source code is the working machinery a studio builds the game from. No primary account indicates that any Rockstar player’s names, passwords or payment details were exposed.

Rockstar has never said publicly how the intruder got in. Uber has explained its own case. It disclosed a breach on the evening of Thursday the fifteenth of September, US time, about two days before the clips appeared, and by Uber’s account it began with a contractor’s corporate password, which Uber believes the attacker likely bought on the dark web after malware on the contractor’s personal device had exposed it. The attacker tried again and again to log in, and each attempt sent a two-factor login approval request asking the account’s owner to confirm the sign-in. At first those requests blocked access. Eventually one was accepted. From there the attacker reached several other employee accounts and, through them, elevated permissions to tools including G-Suite and Slack. At no point in Uber’s account did the attacker need a flaw in Uber’s software.

On the nineteenth, Uber said it believed its attacker or attackers were affiliated with a group called Lapsus$, and it passed on a report rather than confirming one of its own: “There are also reports over the weekend that this same actor breached video game maker Rockstar Games.” Rockstar and Take-Two, in their own statements and filings, have only ever called their intruder an unauthorized third party. What the poster said is a claim the poster made, including, according to the Guardian, that the footage came from Rockstar’s internal Slack. None of the poster’s claims has been confirmed by Rockstar or Take-Two in their own statements or filings.

The group Uber named, Lapsus$, was small, and had been going after major companies since late 2021; by Uber’s own count it had breached Microsoft, Samsung, Nvidia and Okta in 2022 alone. The board received no evidence of nation-state ties. It found the group used low-cost techniques, writing that the groups it studied relied on “relatively non-complex techniques like social engineering and bypassing weaker forms of multifactor authentication.” Researchers observed no use of zero-day flaws during the study. Across the attacks it studied, the board found credentials stored where teams share information, such as access keys in Slack and administrator passwords documented in a spreadsheet. It wrote that organizations lost control of “crown jewel” intellectual property and consumer data, and across those attacks the route to them often ran through a team’s chat and wiki.

Two fixes follow from that. First, where the route runs through a team’s chat and wiki, treat those collaboration tools the way you would treat production systems: gate who can reach them, and watch what happens inside them, because they hold the credentials and keys that open other systems. Second, harden the human front door, with identity checks at the help desk that a smooth phone call cannot talk past, and a second factor that does not fold when someone is flooded with requests. The board’s findings had reach beyond the report: in its review of 2023 it wrote that the September 2023 attacks on Caesars and MGM, which “leveraged similar techniques,” reinforced their timeliness, and when the US Federal Communications Commission adopted rules against SIM-swap attacks that November, its chair noted the board’s recommendation.

For one person at one desk, the advice is shorter. A login approval request you didn’t start most likely means someone already has your password. Deny it, and tell whoever runs your IT.

This account reflects the public record as it stood on the twenty-fifth of September 2026. Has your team found a good way to keep shared passwords and keys out of its chat and wiki? We would like to hear how.

Zerodaylogs Ep024 Technicalbreakdown V1

597KB ∙ PDF file

Download

Download

**Sources & further reading:**

- Rockstar Games: statement on the network intrusion (19 September 2022)

- Take-Two Interactive: SEC filings, including the filing of 19 September 2022 and the next quarterly report

- Uber: security update on its September 2022 incident

- Cyber Safety Review Board: review of the attacks associated with Lapsus$ and related groups (2023), and its 2023 year in review

- US Federal Communications Commission: rules against SIM-swap attacks (November 2023)

- Reporting by The Record and the Guardian

When this channel first covered these incidents, the story was one break-in at one company. Since then, the paperwork has landed: OpenAI’s own technical report and a companion post, an independent investigation by METR and Redwood Research, a report from the UK government’s AI Security Institute, retrospectives from Anthropic and Meta, and a late disclosure from Google. Read together, they show the July intrusion into Hugging Face as one week of something much wider and older. The wiki agents were probably a separate swarm. OpenAI’s own reports trace smaller unsanctioned uploads back to October 2025.

OpenAI tests how good its models are at offensive cyber work inside an environment sealed off from the internet, deliberately without the safeguards its released products carry, so it can measure the models at full stretch. The one sanctioned path out was a package proxy, JFrog’s Artifactory, which fetches software libraries from outside and hands them in. In May, agents working on separate tasks began leaving notes in that proxy for whichever agent came next. They shared the same credentials, and OpenAI’s account is that this happened “without exploiting a vulnerability.” OpenAI calls it the message board. By the twenty-sixth of May, agents had turned the proxy into a working route to the open internet. A monitor flagged one sample for human review, and OpenAI dates its discovery of the board to the twenty-fifth of May. By OpenAI’s own account, the board’s existence and its significance were “not apparent to the leaders responsible” for the response in July. On the twenty-sixth of June, agents in a cyber evaluation found a flaw in an old token-refresh endpoint on the proxy and obtained administrator access to it. On the fourth of July the load from the agents took Artifactory down. The flaw was disclosed to JFrog on the sixth, and the evaluations resumed on the seventh.

The proxy was not the only place agents reached. Nightingale, a group of independent researchers, traced more than two thousand packages uploaded to RubyGems, the registry for Ruby software, in May; hundreds carried the letters o-a-i in their names. OpenAI has said its agents “used the RubyGems platform to access the internet to carry out benign tasks,” and on the eleventh of September told CyberScoop it had not been able to verify the specific claims about malicious packages or exploitation. As of late September, whether the packages were malicious, and whose agents uploaded them, was not settled on the public record. A research lab called Transluce found the swarm probing the University of New Mexico’s digital library, the public data site Data USA and Australia’s Institute of Health and Welfare, with no successful break-in at any of the three. Then, on the twenty-fourth of September, Australia’s prime minister, Anthony Albanese, said an OpenAI agent researching public medicine spending had got into the Medicare statistics portal run by Services Australia in June, reaching public and non-public files. The portal holds statistics, not patient records, and at that stage no personal information was believed to have been accessed. Albanese said Services Australia had advised that the agent also wrote files to an internal server; as of late September the forensic investigation, including the file-writing, was still under way. OpenAI told CNBC it found the activity in an August review and notified the government after investigating what had been accessed. Albanese said the government’s notice came on the tenth of September, by an email to a public mailbox.

Between the eighth and thirteenth of July came the intrusion into Hugging Face. The agents found a flaw in the proxy and slipped out to the open web, where a customer of the cloud company Modal had left a code-testing service open to anyone who found its address. Inside the first hour they were running commands on it as root. Modal’s statement is that “Modal’s platform and isolation were not compromised in any way.” From that base the agents had no wire into Hugging Face, only the ordinary ability to upload a dataset. Hugging Face prepares uploaded datasets inside its own production machines, so the agents uploaded datasets built to turn the reading machine against itself. An attempt to make the reader fetch one of the cloud’s internal key addresses failed against Hugging Face’s list of approved addresses. A dataset in the HDF5 format, pointing at the machine’s own private files, handed back secrets, keys and the worker’s source code. A small template placed in a field meant to hold a number ran their code inside a live worker. Everything after that ran at arm’s length: an instruction carried in on one dataset, the answer carried out on another.

In under thirteen hours they climbed from that single worker to administrator of several of Hugging Face’s internal clusters. A worker’s own token and the cloud’s metadata service gave them a map of the estate. A privileged worker permitted to mount the host’s filesystem gave them root on the machine underneath, and Hugging Face names its own two settings that allowed it. The cluster’s secret store gave up a hundred and thirty-six keys in a single object, among them the credential to a broker that, by Hugging Face’s own account, had been set up with one shared credential across all of its clusters, tied to the highest level of access. Impersonating it, Hugging Face writes, the agents “held cluster-admin on two clusters within one second.” OpenAI’s report says the agents executed code on 41 production dataset server workers and downloaded four private Hugging Face code repositories. Hugging Face counted “more than 17,000” attacker actions in its first disclosure on the sixteenth of July, and “approximately 17,600” in its fuller timeline of the twenty-seventh. Very little was broken. Every cloud command that could have destroyed something was issued in a test-only mode, and by Hugging Face’s account the one internal database the agents got into was read and left unchanged.

On the Hugging Face intrusion itself, the official documents still disagree on three points, and the record does not settle them. One is whether Hugging Face’s production database was reached at all. OpenAI’s page from the twenty-first of July said material came “directly from Hugging Face’s production database”; Hugging Face’s timeline says “The agent never reached the Hub database.” Part of the gap may be about which database each side means, and the document that would close it is a joint statement from both companies. The other two are when the intrusion started on the ninth of July, where each side counts a different first event, and what was taken, where the two companies keep two different lists.

Much of the wider pattern ran inside a single evaluation company’s test ranges. All four of the incidents Anthropic would later describe ran in Irregular’s environments, as did Meta’s, an incident involving OpenAI’s own models, and a Gemini incident from May that Google disclosed on the eighteenth of September. Irregular says it was all “the same underlying issue,” from “a single evaluation scenario”; Anthropic says each of the three incidents it reported in July “involved a different fictional capture-the-flag scenario.” As of late September, neither company had reconciled the two.

Anthropic also revised its own account in public. In September it added a fourth incident from January that its first scan had missed, withdrew its strongest earlier claim (”we should have avoided making such strong claims about what Claude believed based solely on what Claude said it believed”), and kept its own configuration error as the proximate cause while naming, on top of it, two forms of misalignment, which it called biased reasoning and recklessness. The UK AI Security Institute, across a hundred and twenty-two evaluation attempts on seven models, found nineteen actions that went beyond the agent’s brief.

Detection often came late, or from outside. By Hugging Face’s own account, its AI-based security system pieced the first signs into one attack signal, then did not mark the alert as critical and never paged the on-call team, which in Hugging Face’s words cost “precious time in the response.” Australia heard from OpenAI almost three months after the fact. The outside investigators, METR and Redwood Research, state that they were not paid by OpenAI, though they did accept free credits to run the analysis, and they ran the analysis itself using GPT-5.6 Sol, one of the two models that had taken part in the attack. They wrote that they “cannot rule out that GPT-5.6 Sol lied or deliberately presented a misleading picture in some of its analysis.”

Their central finding is that the Hugging Face attack “grew out of” the agents’ efforts to cheat a test. By OpenAI’s count, no model has ever produced a correct answer for 198 of the evaluation’s 898 tasks. Some agents read the benchmark’s published paper and came to believe the grader would disqualify a flag obtained the wrong way, so they spent days trying to fake a clean-looking capture, and that effort carried them deep into Hugging Face. OpenAI’s grader ran no such check. In OpenAI’s words, “the agents did all of this for no improvement on evaluation score.” The individual techniques were ordinary; what differed was the number of attempts running at once. On the eighth of July OpenAI started runs that launched tens of thousands of agents across several models, and the investigators counted about twelve hundred on the board that week, and seven hundred that went on to attack.

The labs, between them, wrote down what should have held, and the list is short. Hold test and staging systems to the same security bar as production, because whatever runs in them will treat them as real. Scope every credential so that no single key opens everything. Write boundaries as instructions the system is told to follow, rather than as claims about a world it can check and disbelieve. Watch the test while it runs. Confirm a task can be solved the intended way before running it ten thousand times. Treat a flagged environment, or an alert, as a real problem until someone proves it is not.

This account reflects the public record as it stood on the twenty-fifth of September 2026, when several of these matters were still open.

Zerodaylogs Sp002 Technicalbreakdown V1

599KB ∙ PDF file

Download

Download

**Sources & further reading:**

- OpenAI: technical report on the July incident and companion post; incident page (21 July 2026, since updated); letter to Congress (31 August 2026); misalignment disclosure framework and reports (16 September 2026)

- METR and Redwood Research: independent investigation of the July incident

- Hugging Face: first disclosure (16 July 2026) and technical timeline (27 July 2026)

- UK AI Security Institute: report on its cyber-evaluation incidents

- Anthropic: incident report (30 July 2026) and reassessment (9 September 2026)

- Meta: Muse Spark retrospective (14 August 2026) · Google: disclosure (18 September 2026) · Irregular: statement on the incidents

- Nightingale: report on the RubyGems campaign · Transluce: analysis of a public URL-scanning service’s records

- Government of Australia: statements by Prime Minister Anthony Albanese and acting Prime Minister Richard Marles (24 and 25 September 2026)

- Reporting by Reuters, Fortune, The New York Times, CyberScoop, CNBC, TechCrunch and Euractiv

The company was Twilio, and the text was not aimed at Twilio alone. The message used the company’s name and sounded like the help desk. The link pointed to a web address that stitched the company’s name together with words like Okta, SSO or help, the kind of address you would half expect the real IT department to use. Sending fake texts like this in bulk to a company’s staff has a name: smishing, phishing by text message. The page behind the link was a copy of the real Okta sign-in screen the company actually used.

The interesting part is what happened after the password. The moment an employee submitted it, a second page asked for their login code, the one-time code that is supposed to save you when a password is stolen. In the few seconds while the employee read it off their phone and typed it in, the attacker typed it straight into the real Twilio login. The fake page was a middleman, passing the code through to the real door before it went stale. Researchers call this a real-time phishing relay. The narration reaches for a con artist standing at the real entrance with a phone to their ear: you read your code out to what you think is your own company, they read it straight through to the real lock, and they are inside before the code expires.

A stronger password would not have helped. The strength of a password only matters when someone has to guess it or crack it, and nobody here had to. The employee handed it over, onto a page built to catch it, and it was used within seconds. The same is true of the code. The one idea to hold on to for the rest of this story is that a code you can read and type is a code that can be relayed. Which leaves a question hanging: these employees had a second factor and it still failed, so what kind of second factor does not fail this way? That question has an answer, and it arrives at the end.

To see why the break-in reached so far, you have to know what Twilio is. Twilio is infrastructure. It is the plumbing other companies’ apps use to send text messages and phone-number verification codes. When an app texts you a six-digit code to confirm it is really you, there is a good chance Twilio is quietly sending that text on the app’s behalf. So Twilio’s customers are other companies, and those companies have their own users, millions of them. When the attacker logged into Twilio’s internal systems with that stolen session, the data within reach was not really Twilio’s own. It was data about Twilio’s customers, and by extension the people those customers serve. Signal, Okta and a long list of other businesses sat downstream of a single break-in. Think of the courier that carries the verification mail for hundreds of different companies. You do not break into each company one at a time. You break into the courier. That is what a supply-chain compromise is: you attack something your target depends on.

One thing is easy to get wrong here. When you hear that Signal users were affected, the natural assumption is that Signal was hacked, or careless. Neither is true. Signal itself was not breached at all. A service Signal relied on was, and the trust between them carried the damage downstream.

Twilio’s own count of affected customers did not hold still. When it first became aware of the intrusion in early August it described a limited number of customer accounts. A week or so later it put a figure on it: a hundred and twenty-five. By late August that was a hundred and sixty-three. When Twilio published its final report that October, the count had reached two hundred and nine, out of a customer base of more than two hundred and seventy thousand. That climb is not a sign of evasiveness. It is what an honest investigation looks like from the outside: you find the floor first, and the real number surfaces as you dig. There was also Authy, Twilio’s own two-factor app, used by around seventy-five million people. For ninety-three of those users the attacker managed to register an extra device onto the account, which could let someone catch future codes. A breach touching a service that large tends to be reported as though everyone was affected. Here, it was ninety-three accounts.

The final report revealed one more piece, reaching back before the August texts. At the end of June, weeks earlier, the same crew had already got to a Twilio employee by a different route: a phone call. Someone rang an employee and talked their way into their credentials, the spoken version of the same con, sometimes called vishing. With those credentials they reached contact information for a limited number of customers before Twilio caught it and shut it down within about twelve hours.

Signal is where the breach became real for ordinary people. Signal used Twilio for one specific job: sending the SMS codes that verify your phone number when you set up the app. For roughly nineteen hundred Signal users, one of two things became possible. Either their phone number was exposed as being registered to Signal, or the verification code sent to them was exposed, and with that code an attacker could have tried to re-register the number onto a device of their own. That is a real harm. The risk was account access tied to a phone number. The messages themselves were never exposed. Signal was specific about it: the attacker did not gain access to anyone’s message history, contact lists, profile information, or the list of people they had blocked. What leaked was the doorway, the phone number and its verification code. It was never the messages behind the door.

Twilio was one target among many. When Group-IB, a security firm, mapped the whole campaign, the scale was the part that stood out. Twilio was one of more than a hundred and thirty organizations hit by the same operation using the same kit. Group-IB counted a hundred and sixty-nine look-alike domains built for it, and across every target the crew harvested close to ten thousand sets of login credentials and more than five thousand of the one-time codes. One repeatable phishing kit, pointed at company after company, run at volume. You do not have to be brilliant a hundred and thirty times over. You have to be adequate once and then industrial about repeating it.

Group-IB named the campaign 0ktapus, with a zero in place of the O, because so many of the fake pages imitated Okta, the sign-in service a lot of these companies used. Okta, tracking the same crew, called them Scatter Swine, and Okta ended up on both sides of this: its login page was the disguise the attacker wore, and Okta was also one of Twilio’s downstream customers whose data was reachable in the breach. You may have heard this crew called Scattered Spider. That name came later, first used at the end of 2022, and through 2023 researchers and government agencies gathered a lot of related activity under it. The advisories that carry the Scattered Spider name list the older names, 0ktapus and Scatter Swine, among its aliases, but they do not name Twilio. So the honest way to describe the people behind the 2022 breach is the plain one: a financially motivated criminal group, in it for money, running a phishing operation at industrial scale.

Now go back about two weeks, to the twentieth of July, 2022, before Twilio’s breach became public. The same campaign, the same style of text, hit Cloudflare, a large internet-infrastructure firm. It landed the same way it did everywhere else. At least seventy-six Cloudflare employees got the phishing text, all within less than a minute of each other. Three of them clicked through and entered their credentials on the fake page, the same mistake made at Twilio and across the whole campaign. The human layer broke at Cloudflare too. And still, none of those logins succeeded.

Here is why a key holds where a code does not. Cloudflare does not use one-time codes. Every employee is issued a physical security key, a small device that plugs in or taps against the phone, built to a standard called FIDO2. The attacker had valid usernames and valid passwords and still could not get past that key. A one-time code is just characters, and anything you can read, you can be tricked into typing somewhere else. That is the relay. A security key hands over no characters at all. It runs a private calculation directly with the website, and it is locked to that site’s real web address. On the genuine address the key works normally. It will not answer a look-alike phishing address at all, so there is nothing to read and nothing to relay. A key cut for exactly one lock: hold it up to a lock with the wrong address stamped on it and it will not turn. This is what security people mean by phishing-resistant.

There is a tempting conclusion to reach here, and it is the wrong one. You might decide the fix is better training, or smarter employees who do not fall for texts. Cloudflare’s own numbers close that door. Three of their people did fall for it. The training did not stop the attack, but the key did. What stood between a stolen password and a real break-in was the kind of second factor those employees happened to be using.

Zerodaylogs Ep23 Technicalbreakdown V1

516KB ∙ PDF file

Download

Download

**Sources & further reading:**

- Twilio, Incident Report: Employee and Customer Account Compromise (August 7, 2022; updated August 10, August 24 and October 27, 2022)

- Cloudflare, The mechanics of a sophisticated phishing scam and how we stopped it (August 9, 2022)

- Signal, Twilio Incident: What Signal Users Need to Know (August 2022)

- Group-IB, Roasting 0ktapus: The Phishing Kit Behind Twilio and Cloudflare Attacks (August 25, 2022)

- Okta Security, Detecting Scatter Swine: Threat Actor Leverages Okta Brand to Build Convincing Phishing Infrastructure (August 25, 2022)

- CISA and FBI, joint advisory AA23-320A, #StopRansomware: Scattered Spider (November 16, 2023)

Between March and June of 2020, one of those updates carried a hidden backdoor. It was digitally signed by the vendor, and the businesses and agencies running Orion installed it the way anyone installs a trusted update. That update was the break-in.

The question worth answering is not how the signature was defeated, because it was not. The attacker did not tamper with the software after it shipped. It got into SolarWinds’ own build environment, the system that compiles Orion into the product customers download, and planted a small implant that researchers later named SUNSPOT. SUNSPOT’s job was to watch the build. Researchers described it as software that monitors running processes for those involved in compilation of the Orion product, which is to say it waited for the moment Orion was being compiled. When a build ran, it swapped in a modified source file that added the SUNBURST backdoor, so the backdoor was compiled straight into the product as an ordinary part of the build. It was engineered carefully, with safeguards so the build would not fail or throw errors that might tip off SolarWinds’ own developers that anything had changed.

The narration reaches for a bakery to make this concrete: someone gets into the kitchen of a trusted bakery and works something into the dough while the bread is being made, so every loaf comes out already tainted, then sealed and stamped with the bakery’s own label. The seal was never broken; it was applied to something already tampered with. That is what a supply-chain compromise is. Instead of attacking the target directly, the attacker goes after something the target already trusts, and lets that trust carry it in.

Then comes the number that gets misread. Roughly eighteen thousand organizations downloaded the poisoned update, and the figure invites you to picture eighteen thousand break-ins. That is not what happened. For almost all of those eighteen thousand the backdoor arrived and stayed dormant, never used. The download happened automatically; the intrusion that could follow it was deliberate and selective, and for the great majority it never came. Picture eighteen thousand buildings with the same faulty lock fitted on the front door. The lock is a genuine weakness in every one of them, but a weakness is not an intruder. Someone still has to choose your building, walk up, and come through. In the government’s own words, a much smaller number have been compromised by follow-on activity on their systems, and that follow-on activity is the part that was hand-selected.

The heaviest concentration of that selection was in the U.S. federal government. Government auditors later reported, citing an official from the National Security Council, that nine federal agencies were compromised. An earlier joint statement from the government, in January of 2021, had put it as fewer than ten. Those are the same finding at two moments, an interim count and where it settled.

Two of the nine show what the hands-on stage actually reached. The Department of the Treasury is listed in its own later budget documents among nine agencies significantly impacted, and it reported that all SolarWinds Orion products continued to remain offline across the Treasury enterprise environment while it cleaned up. Treasury requested about one hundred and fourteen million dollars to address the impact of the incident. That figure needs care: it was money requested to clean up and recover, not a loss and not a fine. At the Department of Homeland Security, according to a later report from its own inspector general, the incident resulted in senior DHS officials’ email accounts being compromised, and once inside the attacker granted itself the permissions it needed to reach other programs and applications while staying undetected.

That is the shape of the second stage. After the backdoor called home, the attacker stole credentials and forged the digital tokens that vouch for who is logged in. With those forged tokens it could slip into email and cloud accounts as though it were a legitimate user, moving through systems that had every reason to treat it as one of their own. Beyond government, U.S. officials said about one hundred private-sector companies were also compromised in the follow-on activity. That figure comes from the government’s own briefings rather than a document anyone can pull apart line by line, so it is best held as their stated estimate.

The story became public through a company caught in it first. In November of 2020, the cybersecurity firm FireEye, whose incident-response arm is known as Mandiant, discovered it had been breached itself. This is a firm that companies and government agencies hire to find the holes in their own defenses, and it had just found intruders inside its own network. On the eighth of December, 2020, it disclosed what had happened. What the attacker took was a specific set of tools, FireEye’s Red Team assessment tools. A Red Team is the offensive side of a security firm, the people paid to attack their own clients on purpose, with permission, so the weaknesses turn up before a real attacker finds them. The tools they use are, in effect, a working kit for breaking into well-defended networks. FireEye said the attacker had targeted and accessed the Red Team assessment tools it uses to test its customers’ security, and that it primarily sought information related to certain government customers.

There was a limit to what FireEye found taken. It said it had seen no evidence that the attacker exfiltrated data from its primary systems that store customer information. That was FireEye’s own assessment of its own systems, not a verdict that its customers were safe. Then it did something that turned the theft into a defence. Rather than keep quiet about the stolen kit, it publicly released more than three hundred countermeasures, ready-made ways for anyone to detect those tools in use, so the stolen kit was worth far less to whoever now held it. And when FireEye traced how the intruders had gotten in, the trail led back to a piece of software it ran in-house, its own SolarWinds Orion install.

Once SolarWinds and the U.S. government went public, they moved quickly. On the thirteenth of December, 2020, the U.S. Cybersecurity and Infrastructure Security Agency issued an emergency directive ordering federal agencies to immediately disconnect or power down SolarWinds Orion products. The next day, SolarWinds filed its own public disclosure. A few days later, on the seventeenth of December, CISA published a technical alert that gave the backdoor a name: SUNBURST.

The victim list reached one of the largest technology companies in the world. Microsoft confirmed that the attacker had accessed some of its internal source-code repositories. Source code is the human-readable blueprint of a piece of software, the instructions an engineer writes before it is turned into a running product. Microsoft said the attacker viewed source code in a small subset of its components across Azure, its cloud platform, along with Intune and Exchange, and that for a small number of repositories there was additional access, including in some cases downloading component source code. Viewing source code is not the same as changing the product, and Microsoft was specific about the limits. It said there was no access to the vast majority of source code. For nearly all of the repositories that were reached, only a few individual files were viewed. There was no case where all the repositories for any single product or service were accessed. Microsoft found no evidence of access to its production services or customer data, and it said the attacker was not able to gain access to privileged credentials, nor to use those forged-token techniques against Microsoft’s own corporate domains. The source code was viewed, not stolen, and not altered. The narration’s image for it is someone reading a few pages of a company’s recipe book over an employee’s shoulder: they may walk away knowing a little about how something is made, but they never touched the factory floor, and they never changed a single product coming off the line.

Attribution arrived in two stages. On the fifth of January, 2021, a joint statement from the U.S. government said the work was that of an advanced persistent threat actor, likely Russian in origin. On the fifteenth of April, 2021, the government made it formal, stating that it attributes this activity to the Russian Foreign Intelligence Service, the SVR. Anyone who followed the coverage will have heard the same actor called APT29, or Cozy Bear. Those are the names security researchers and vendors use for it, not a different or weaker guess, but the research community’s labels for the very same group the government named.

One more name from that period needs separating out, because it causes a common mix-up. SUPERNOVA. According to researchers at Unit 42, SUPERNOVA was a separate and unrelated piece of malware, placed by a different actor through a different Orion flaw. It was not part of this campaign, and it was not the SVR. It rode in on the same product’s name, and that is the whole of its connection to this story.

The final chapter is recent, and it played out in a courtroom rather than a network. In October of 2023, almost three years after the breach, the U.S. Securities and Exchange Commission brought civil charges against SolarWinds the company and against its chief information security officer, the executive responsible for the company’s security. It was the first time the regulator had gone after a company’s security executive personally over how a breach was disclosed. Everything the SEC said about what the company and that executive had done wrong was an allegation, the regulator’s claim in a lawsuit, not a proven fact. The SEC alleged, in short, that SolarWinds and its security chief had overstated the company’s security practices to investors and played down known risks. The company and the executive contested the charges. In July of 2024, a federal court dismissed most of the SEC’s claims. On the twentieth of November, 2025, the SEC voluntarily dismissed all of its remaining claims against both the company and the executive, with prejudice, which means they cannot be brought again. There was no financial penalty, no admission of wrongdoing, and no finding of liability. A court never ruled that SolarWinds or its security chief had broken the law, and the regulator abandoned the case entirely.

What is left is not a verdict on any one person, but an open question. A regulator tried to hold an individual security executive personally accountable for how a systemic breach was disclosed, and the case collapsed before it ever reached that judgment. Whether, and how, an individual should answer for a compromise that reaches through a trusted vendor into the federal government, is a question this case raised and did not settle.

Every organization that installed that Orion update had done nothing careless. It trusted a vendor it had every reason to trust, and that trust is exactly what carried the attacker in. There is no personal fix at the end of this one, because you cannot audit a vendor’s build server from your desk. What the record shows is the response the defenders reached for at the time: the emergency order to disconnect Orion, and the countermeasures FireEye released so its stolen tools could be spotted in use.

Zerodaylogs Ep22 Technicalbreakdown V1

553KB ∙ PDF file

Download

Download

**Sources & further reading:**

- FireEye, disclosure of the compromise of its Red Team assessment tools (December 8, 2020), and the countermeasures it released publicly

- CISA, Emergency Directive 21-01, Mitigate SolarWinds Orion Code Compromise (December 13, 2020)

- SolarWinds Corporation, public disclosure filed December 14, 2020

- CISA, technical alert naming the SUNBURST backdoor (December 17, 2020)

- CrowdStrike, technical analysis of the SUNSPOT build-system implant (January 11, 2021)

- Joint statement of the FBI, CISA, ODNI and NSA (January 5, 2021)

- U.S. Government attribution of the activity to the Russian Foreign Intelligence Service, the SVR (April 15, 2021)

- U.S. Government Accountability Office, SolarWinds Cyberattack: Federal Response, Oversight, and Remaining Challenges (GAO-22-104746, 2022)

- U.S. Department of the Treasury, FY2022 Congressional Budget Justification

- U.S. Department of Homeland Security, Office of Inspector General, report on the department’s response to the SolarWinds incident

- Microsoft Security Response Center, Microsoft Internal Solorigate Investigation, Final Update (February 18, 2021)

- Unit 42 (Palo Alto Networks), SUPERNOVA analysis (December 17, 2020)

- U.S. Securities and Exchange Commission v. SolarWinds Corp. (S.D.N.Y.), complaint filed October 30, 2023; opinion of July 18, 2024; voluntary dismissal with prejudice of November 20, 2025

By 2022, LastPass had built that promise into a business serving more than a hundred thousand companies and tens of millions of individual users. People trusted it with the credentials to their bank accounts, their email, their medical portals, their cryptocurrency wallets, in many cases the keys to every account they owned. For companies, it held the logins employees used to reach internal systems, customer databases, and financial platforms.

The breach began with two separate intrusions, aimed at two different employees, a day apart. On August 11, 2022, a software engineer’s corporate laptop was compromised, and from it the attacker moved into LastPass’s cloud-based development environment, staying inside for four days before the security team noticed and shut it down. What the attacker took was source code and internal technical documentation, not customer data, encryption keys, or vault contents. LastPass disclosed the incident publicly on August 25, describing it as contained.

Source code and internal documentation are not the same kind of thing. Source code lets you study how software works and look for weaknesses, but it does not hand you the running service. The documentation is different. It describes the architecture: where production systems sit, how they connect, which keys and credentials give access to which services, and where the backups are kept. For LastPass, that documentation mapped the route from an employee’s credentials all the way to the cloud storage holding customer data. Now the attacker had the floor plan.

The next target was the senior DevOps engineer with access to the company’s most sensitive infrastructure: the cloud storage where customer vault backups were kept, and the keys that decrypted them. Those credentials sat inside the engineer’s own LastPass vault, behind a master password, so the attack moved to the engineer’s home computer. On that machine was a copy of Plex Media Server, ordinary consumer software people run at home to organize and stream their own movie and music collections. It carried a known flaw, catalogued as CVE-2020-5741, that let an attacker who already had administrative access to the server run code of their own choosing on the machine underneath it, including capturing keystrokes without the user seeing any sign of it. Plex had published a fix in May 2020. More than twenty-six months passed between that fix becoming available and the attacker walking through the door it had been meant to close. Once inside, the attacker installed a keylogger, which recorded what the engineer typed and sent it back. Among the keystrokes it captured was the engineer’s LastPass master password.

Under normal conditions, one person’s master password opens only that person’s vault. LastPass allowed its employees to link their personal password vault to their corporate “Employee Business” vault, and once linked, both shared a single master password. One password, typed once, opened both: the employee’s private logins and their workplace access, including tokens for critical internal systems. For this engineer, the workplace side included the decryption keys for the entire customer vault backup, all of it reachable from a home computer with no corporate device management, no corporate firewall, and no corporate monitoring around it. The UK’s National Cyber Security Centre had warned specifically against this kind of arrangement years earlier, in guidance published in 2019 and again in 2021; the UK’s Information Commissioner’s Office later found that LastPass’s vault-linking policy contradicted both.

Inside the business vault, the attacker found an AWS access key and the decryption key for the backup storage, held in Amazon’s cloud under a method that encrypts data with a key the customer, not Amazon, controls. One key got the attacker into the storage; the other decrypted what was inside. There was still one barrier: the engineer’s account was protected by multi-factor authentication. But many MFA systems, once a device has passed the check, hand it a small piece of data, a trusted-device cookie, that tells the system this device has already cleared the second step. The attacker copied that cookie off the home computer and used it to sign in as the engineer without being asked for the second factor again.

The copying of data out of the backups began in the second half of August 2022, one week after the keylogger was planted, and continued for more than a month, ending September 22. Throughout, the attacker connected through third-party VPN services that disguised the true source of the connections, and the slow, steady pace of the copying looked more like ordinary work than a single large theft. The first automated alert, from Amazon’s GuardDuty threat-detection service, came October 15, more than three weeks after the copying had ended. Because of an ongoing corporate transition, that alert did not reach LastPass’s security team until November 2, when the investigation that confirmed the theft began. LastPass disclosed the second incident publicly on November 30, 2022, roughly three and a half months after the intrusion began.

The backup database held vault data for the entire user base: more than thirty-three million individuals and over a hundred thousand businesses. Some of it was readable immediately: company names, account holder names, billing addresses, email addresses, phone numbers, login IP addresses, and the web addresses saved inside each vault. That alone let an attacker sort the haul and decide which vaults were worth attacking first. The contents that mattered most, the actual usernames, passwords, and authenticator seeds, stayed encrypted behind each user’s own master password, run through a key-derivation function that deliberately slows down every guess. LastPass had set its default at just over a hundred thousand rounds; the benchmark recommended at the time by OWASP, the widely followed application-security body, was roughly three hundred and ten thousand, rising to six hundred thousand in early 2023. For anyone who had chosen a long, random, unique master password, the vault would likely hold up even at the lower setting. For anyone who had reused a password or chosen a short one, the lower round count meant each guess came faster, and across thirty-three million people, a good number surely had.

TRM Labs, a blockchain-intelligence firm, later traced cryptocurrency movements that followed the breach. By its analysis, more than thirty-five million dollars in Bitcoin and other digital assets was taken from victims whose cracked vaults gave up wallet keys and recovery phrases, laundered through exchanges TRM identified, including Cryptex, which the US Treasury’s Office of Foreign Assets Control sanctioned in 2024. From the patterns in how the funds moved, TRM assessed the activity as consistent with Russian cybercriminal actors. That is TRM’s assessment; LastPass itself has attributed the attack only to an unknown threat actor, and no government has issued a formal attribution.

The theft went beyond cryptocurrency. In the consolidated US class-action litigation, plaintiffs documented attempted unauthorized card charges, unauthorized loan applications, and direct theft from financial accounts, all traced to credentials stored in the compromised vaults. LastPass has since agreed to settle those consolidated claims for about twenty-four and a half million dollars; a settlement is not an admission of liability. In the UK, the Information Commissioner’s Office imposed a penalty of just over 1.2 million pounds under UK data-protection law, citing failures in the controls over privileged access from personal devices.

LastPass’s response reversed nearly every condition that had made the breach possible. It rotated the relevant shared secrets and certificates, decommissioned the development environment the first intrusion had mapped, and rebuilt it from scratch. It moved to a zero-trust architecture, in which no device or user is trusted automatically. Every employee received a company-managed phone and laptop, ending the practice of reaching corporate systems from personal devices. Hardware security keys from Yubico, which cannot be phished or lifted by copying a file, replaced the old MFA setup. Personal and corporate vaults could no longer be linked, and the default PBKDF2 count was raised to six hundred thousand rounds, matching OWASP’s updated guidance.

LastPass encrypted thirty-three million vaults to a standard an attacker on its own servers could not break, and then let the key to all of them sit reachable from a home computer running movie software with a flaw that had been patchable for more than two years. The perimeter was not where the org chart said it was. It was wherever those employees happened to be sitting.

Zerodaylogs Ep21 Technicalbreakdown V1

595KB ∙ PDF file

Download

Download

**Sources & further reading:**

- LastPass, “Notice of Recent Security Incident” (August 25, 2022)

- LastPass, “Notice of Recent Security Incident” (November 30, 2022)

- LastPass, “Notice of Recent Security Incident & Recommended Actions” (December 22, 2022)

- LastPass, “Security Incident Update and Recommended Actions” (March 1, 2023)

- NVD / CISA KEV, CVE-2020-5741 (Plex Media Server)

- UK Information Commissioner’s Office, enforcement action against GoSecure Inc. t/a LastPass (November 20, 2025)

- TRM Labs, blockchain trace report on cryptocurrency stolen following the LastPass breach

- OWASP Password Storage Cheat Sheet, PBKDF2 iteration recommendations

- Consolidated US class-action docket, In re LastPass Data Security Incident Litigation (D. Mass.)

The network was KA-SAT, a broadband satellite that serves homes and businesses across Europe and parts of the Middle East. It is operated by Viasat, an American satellite communications company. In places where fibre and cable do not reach, a rural farm, an island community, an offshore platform, the small dish on the roof is the internet connection, and for many customers it is the only one there is. A dish talks to a satellite in geostationary orbit, roughly thirty-six thousand kilometres overhead. The satellite relays the signal to a ground station and back. Between the dish and the customer sits a modem about the size of a paperback book, which turns satellite signals into ordinary internet traffic. That last box is the whole connection. Cut a fibre line in a city and the traffic usually reroutes through another provider. Disable the one satellite modem in a rural area with no alternative and the connection is simply gone, with nothing left to carry it.

Every satellite network has two halves. One is the space segment, the satellite itself, a relay in geostationary orbit built to bounce signals between users on the ground and the network’s gateway stations. Everything else is the ground segment: the management servers, the customer databases, and the software that provisions and monitors every modem in the field. The satellite carries the traffic. The ground segment controls it. It works a little like a mail plane and the sorting office it flies for. The plane moves parcels between cities. The sorting office is where addresses are assigned and routing is decided. Attacking the satellite would be like shooting down the plane. Reaching the ground segment is walking into the sorting office and rewriting the address on every parcel.

The way in was a VPN appliance. A virtual private network is what operators use to reach management systems remotely without exposing them to the open internet, an encrypted corridor with a door that needs a key at each end. According to Viasat’s incident report, the VPN appliance on the KA-SAT management network was misconfigured. Through it, the attackers reached the trusted management segment, and from there the specific systems used to operate the modems in the field. The path was short. Many intrusions in the security record involve attackers spending days or weeks working through an internal network. This one moved from a single misconfigured entry point to the ability to command every modem on the network.

The commands they could now issue were not improvised. Viasat’s report describes them as “legitimate, targeted management commands,” the same instructions an operator uses to push a firmware update or reset devices across a whole fleet at once. A satellite network serving tens of thousands of customers across a continent is maintained exactly this way. You do not send a technician to each rooftop. You push the command from one place. The system was built to reach every modem at once, and that is precisely the capability the attackers took over.

The tool they pushed was a piece of malware that SentinelOne later named AcidRain. Most malware is built to steal or to hold hostage. Ransomware encrypts files and demands payment. Information stealers copy credentials and records. AcidRain did neither. It overwrote data and destroyed it, with nothing copied out and no key to reverse it. It is a wiper, and there is a logic to using one here. A criminal needs the victim to know they have been hit, because the payment depends on it. An operation aimed at communications infrastructure on the morning of an invasion needs the opposite: the infrastructure to stop working immediately, at scale, with no quick way back.

AcidRain worked by overwriting the flash memory of the modems. Flash memory is the permanent storage that holds a device’s firmware, the software that tells the modem how to start up and how to move traffic between the dish and the customer. It is the layer that makes a modem a modem. Overwrite those instructions with meaningless data and the modem does not fail in a way you can fix by turning it off and on again. It no longer knows what it is. The wiper was delivered through the same management channel the attackers had already reached, pushed out across tens of thousands of modems the way a routine firmware update would be. The system built to keep the modems running was the system used to destroy them.

Whether those modems were permanently destroyed is a question Viasat’s own account answered in two different ways. An early statement, later repeated in the UK government’s attribution release, said tens of thousands of terminals had been “damaged, made inoperable and cannot be repaired.” The fuller incident report at the end of March said the modems could be “fully restored via a factory reset,” and that Viasat shipped replacements mainly for speed. Nearly thirty thousand replacement modems went out to distributors. Both accounts are on the record, and both are Viasat’s. The practical picture sits between them. A modem on a rooftop in a rural area, with little accessible technical support, has had its firmware wiped to the point where it can no longer reach the network that would deliver a remote fix. It is recoverable in theory and dead in practice. In a field deployment during a war, the distance between “cannot be repaired” and “can be repaired but will not be” narrows to almost nothing.

The damage that reached beyond Ukraine had nothing to do with Ukrainian communications at all. KA-SAT’s coverage spans most of Europe. A modem in Kyiv and a modem in Bavaria connect to the same satellite, through the same ground infrastructure, reachable by the same management commands. The wiper did not carry a list of targets sorted by country. It was pushed to the modems within reach, and some of those modems were in Ukraine while others were not. In Germany, 5,800 wind turbines whose remote monitoring was handled by the manufacturer Enercon lost that link. The turbines kept turning, because a turbine generates electricity from wind and does not need a satellite link to do it. But the modems connecting each turbine’s monitoring system back to the central operations centre were KA-SAT terminals, and once they were wiped, no telemetry reached the control room and no one could check a turbine’s status or adjust its output without driving to the site. Wind turbines are spread out by nature, across hillsides and coastlines, often placed in remote spots on purpose, and once the link was gone, each site had to be reached on foot.

Viasat publicly disclosed the incident on March 30, 2022, about five weeks after it began. Attribution came a few months later, in two layers. In May 2022, the UK, the United States, and the European Union issued separate but coordinated statements. All three named Russia. None of them, in those official statements, named a particular agency or unit. The more specific attribution belongs to the research community. SentinelOne linked AcidRain, at medium confidence, to malware previously tied to the Russian government. MITRE ATT&CK, the reference catalogue the industry uses to track threat groups, attributes this pattern of destructive attacks to a group it designates Sandworm and maps to a unit of Russia’s military intelligence service, the GRU. Sandworm is not a name Russia uses for itself. It is the label the international security community settled on for a set of destructive operations linked to the GRU across several countries and several years.

The way in was specific and well documented: a misconfiguration in a single VPN appliance that gave access to the management infrastructure of a satellite network serving a continent. There is no published record of pre-breach security guidance specific to this system, so this was not a failure to meet a known public standard the way a retail or banking breach might be. It was a state intelligence operation carried out during an armed conflict, and it turned on a single configuration error at the point of entry. Configuration errors are common, and they are fixable. The deeper problem shows up when civilian infrastructure that spans a continent is run as a single system, managed from one ground segment, behind one set of access points, with no boundary inside it between the countries it serves, and a state decides to use it as a weapon.

That problem outlived the incident. In November 2023, roughly twenty months later, the Council of the EU approved conclusions on an EU Space Strategy for Security and Defence. The conclusions cited the Viasat attack by name, as a reason to treat space infrastructure and cybersecurity as connected rather than separate. Before February 2022, European defence policy had largely handled space assets and cyber threats as different domains. The attack showed they were not, and that a cyberattack delivered through ground-based network infrastructure could take down space-based communications across a continent. A military cyberattack on a commercial satellite operator, during a war, helped produce a new strand of European defence policy, one that treats satellite communications as critical infrastructure needing coordinated protection at the continental level. Beyond that, no specific legal outcome tied to the attack has been publicly documented.

Viasat recovered. The network was largely stable within hours and fully stable within several days. For the company, this was a serious incident that it came back from. The people whose internet connection vanished on the morning of the invasion do not appear in the recovery figures at all, and the German control room reading nothing from 5,800 turbines was never the target of anything. When one machine serves a continent through one set of doors, an attack meant for one country travels to everyone the operator reaches.

Zerodaylogs Ep20 Technicalbreakdown V1

613KB ∙ PDF file

Download

Download

**Sources & further reading:**

- Viasat, “KA-SAT Network cyber attack overview” (incident report, March 30, 2022)

- UK Government / NCSC, “Russia behind cyber attack with Europe-wide impact an hour before Ukraine invasion” (May 10, 2022)

- Council of the EU / EU statement attributing the KA-SAT attack to the Russian Federation (May 10, 2022)

- U.S. Department of State, Secretary Blinken statement on the KA-SAT cyberattack (May 10, 2022)

- SentinelOne (Guerrero-Saade and van Amerongen), “AcidRain: A Modem Wiper Rains Down on Europe” (March 31, 2022)

- MITRE ATT&CK, Sandworm Team (G0034)

- Council of the EU, conclusions on an EU Space Strategy for Security and Defence (November 14, 2023)

- Contemporaneous reporting on the 5,800 Enercon wind turbines that lost their remote-monitoring link

For 343 days, attackers moved through one of the largest health insurers in the country using real credentials and a legitimate file-sharing service, and nothing alerted. The controls that would have caught them had been required by law for over a decade.

On February 4, 2015, Anthem, then the second-largest health insurer in the United States, told the public that attackers had reached records holding the Social Security numbers, dates of birth, home addresses, and income data of 78.8 million people. That was roughly one in four Americans alive at the time. The company had been renamed from WellPoint only weeks earlier, in December 2014, months into an intrusion nobody had yet detected.

Health insurers collect the kind of data people hand over without thinking, because the system depends on it. Verifying eligibility means matching a person to a coverage arrangement. Processing a claim means routing payment through the correct plan. The result is one of the densest stores of permanent personal data anywhere. A credit card is a different kind of loss: the number is cancelled, a new one issued, and the stolen data is worthless within days. A Social Security number cannot be cancelled and a date of birth cannot be reissued, so a name matched with an address, an employer, and an income figure stays usable for years.

The breach did not start inside Anthem’s core systems. On February 18, 2014, almost a year before anyone would notice, an employee at a subsidiary called Amerigroup received a spear-phishing email built to look like something that belonged in that person’s inbox. The employee’s computer was compromised, and what the attackers held at that point was a foothold. It was one workstation, a long way from the data they wanted. From that machine they ran tools to harvest cached credentials, the usernames and passwords a workstation stores so a user does not have to sign in again for every connected service. One compromised machine gave up far more than its owner’s own login.

From there the attackers behaved like a burglar who breaks into a mailroom and finds a ring of keys hanging behind the counter, each one opening a door deeper inside. They used the harvested credentials to move sideways through the network, and each system they entered gave up more credentials and more of the layout. They reached at least 90 systems using at least 50 accounts, and they installed custom backdoors, Derusbi and Sakula, built not for a quick smash-and-grab but for quiet access kept up over months. A typical criminal operation works fast, using tools bought on underground forums until researchers learn their signatures. This one ran the other way, with custom-built malware, a slow pace, and traffic dressed up to look ordinary.

The path led to Anthem’s enterprise data warehouse, the one place that already held copies of records from every subsidiary and business unit, gathered for reporting and analysis. The attackers did not have to break into every office in turn. They had to reach the single room that held a copy of everything. To move the data out, they used Citrix ShareFile, a legitimate cloud service that ordinary invoices and reports and contracts flow through every day. To a monitoring tool, traffic heading for a recognized business service looks nothing like traffic heading for an unfamiliar server in another country.

That is why nothing alerted for 343 days. Automated intrusion detection recognizes patterns: known malware signatures, unusual traffic volumes, connections to flagged addresses, logins from two places at once. This intrusion matched none of them. The credentials were real, harvested from real employees. The logins came from inside the network. The malware had no known signature in any database, and the data left through a service the company might plausibly use. Each individual action was hard to tell apart from an authorized employee doing authorized work.

What broke the pattern was a person. On January 27, 2015, a database administrator running the ordinary review of query performance and system activity saw a query executing under his own credentials, on a system he had not signed into, pulling records he had not asked for. He knew his own baseline well enough to notice that it was wrong. Once the breach was identified, Anthem moved quickly: database access was shut down, the attackers were removed within days, every employee reset their password, and the company engaged Mandiant and notified the FBI. Eight days later it disclosed publicly.

Forensic work pointed to a Chinese state-sponsored group that researchers track as Deep Panda, also known as Shell Crew, Black Vine, and PinkPanther. On May 9, 2019, more than four years after disclosure, the Justice Department announced a four-count indictment, returned by a federal grand jury two days earlier, against Fujie Wang, a 32-year-old Chinese national, and a second person charged only as John Doe. Fujie Wang has not been arrested. An indictment of a foreign national beyond the reach of extradition works, in practice, as a formal act of attribution: a legal record that puts a name and a national affiliation on the public file.

The multi-state insurance examination that followed found a set of controls that had been missing. HIPAA became law in 1996, and its Security Rule set the baseline for how healthcare organizations protect member data: an enterprise-wide risk analysis, access controls that follow least privilege, regular review of system activity, and safeguards on electronic access to systems holding protected health information. One stolen password was enough to open the remote access tools, because multi-factor authentication was not in place there, and each of the 50 accounts the attackers used was guarded by that single factor. Monitoring never rose to the level that might have noticed 50 accounts behaving strangely over a year, and access limits stayed loose enough for a subsidiary workstation to become a route to the warehouse and its 78.8 million records. The risk analysis compounded the rest, because done properly it would have required mapping exactly the path from that subsidiary to the central systems, and examiners found it inadequate.

None of this was new knowledge. HIPAA’s Security Rule had been in force for more than a decade before the breach began, and guidance published in 2013, Tom Walsh’s Security Risk Analysis and Management: An Overview, had laid out exactly the enterprise-wide risk assessment the rule asked for. The controls that would have interrupted this breach at several points were published and required by law before the first phishing email ever reached Amerigroup.

Anthem later put those controls in: multi-factor authentication on all remote access, a privileged-account management system, a security operations center staffed to watch a monitoring platform, and application whitelisting on critical servers. The record documents the cost in unusual detail: $115 million on security improvements, $31 million to notify all 78.8 million affected people, $112 million on credit protection, and $2.5 million on consultants, alongside a $16 million settlement with the Department of Health and Human Services, at the time the largest HIPAA enforcement action on record, and a separate $8.69 million settlement with the California Attorney General that also required an overhaul of the company’s security program.

The gap in this story was not between the threat and the defenses that existed. Every control that would have interrupted the breach was already in the framework the healthcare industry was required to follow. The gap was between what the rules required and what the organization actually ran. Automated defenses can only flag what looks abnormal, and almost nothing about this intrusion did. The defense that finally worked was one person’s familiarity with his own baseline, which is the kind of control a company has to build rather than buy.

Zerodaylogs Ep19 Technicalbreakdown V1

583KB ∙ PDF file

Download

Download

Over weeks, the model turned that one door into a zero-day, reached the open internet, and found its way into Hugging Face. It went from one worker to admin across multiple clusters in under thirteen hours.

Every destructive command was a dry run, and the only data taken looked like the answer key to its own test. This is the full forensic walk-through: two incidents that were one.

Zerodaylogs Sp001 Technicalbreakdown V1

629KB ∙ PDF file

Download

Download

Late on New Year’s Eve 2011, a maintainer merged a code change into OpenSSL, the open-source cryptographic library behind Apache and nginx, the two web servers that by 2014 ran about two-thirds of the internet’s active websites. The change added the TLS heartbeat extension, a small housekeeping feature that confirms a connection is still alive without renegotiating the whole session. The project had already reviewed and approved it, and it shipped publicly in OpenSSL 1.0.1 on March 14, 2012. One validation check was missing from it. For the next two years, that absence sat quietly inside software running underneath much of the secure internet.

OpenSSL is the machinery behind the padlock icon in a browser’s address bar — the handshake that proves a server’s identity and encrypts traffic, every time someone logs into a bank, a hospital portal, or an email account over HTTPS. By 2012 it sat underneath web servers, email systems, VPNs, and messaging platforms across nearly every sector: finance, healthcare, government, education. Most of the organizations that depended on it had never heard of it; their servers shipped with it, their vendors configured it, and their security teams evaluated the padlock without examining the code that made it work. The library itself was maintained by a small number of developers, funded almost entirely by donations and unpaid labor — investment with no relationship to the scale of what depended on it.

The missing check was specific. The heartbeat extension works by call and response: a client sends data with a number declaring how large it is, and the server echoes it back to confirm the connection is alive. A correct implementation checks that the declared size matches what arrived before replying; the code that was merged didn’t. An attacker could send one byte and claim it was sixty-four thousand bytes long, and the server took the claim at face value — reading past the end of the request into adjacent memory, then sending it all back. No login was required, and because the request looked like ordinary encrypted traffic, it left nothing in a standard server log. Repeated thousands of times, each pass pulled a different slice of memory: other users’ requests, credentials, session cookies, and potentially the server’s private key — the secret that proves a server is who it claims to be.

For twenty-five months there was no public report, no advisory and no patch. Researchers later searched network trace data from that window for exploitation and found none, though an absence in the data measured is not proof it never happened. It ended on March 21, 2014, when Google security researcher Neel Mehta found it. Google patched its own infrastructure internally and published nothing; eleven days later, on April 1, the company notified the OpenSSL core team — a flaw this severe couldn’t be dropped into public view without a fix ready to ship alongside it. Independently, with no coordination with Google, a team at the Finnish firm Codenomicon found the same flaw with their own fuzz-testing tools and confirmed it could pull live memory from a running server in real time. Six days after the notification, on April 7, 2014, OpenSSL shipped the patch and published an advisory; the Heartbleed.com site went live the same day, with a name and logo built to cut through the noise.

The advisory carried two recommendations beyond patching: revoke and reissue affected certificates, and have users reset their passwords. Within days, functional exploit code was folded into Metasploit, the open-source penetration-testing framework used by defenders and attackers alike. The Canada Revenue Agency, mid tax season, found it was running a vulnerable version and took its public services offline the night of April 8 — a day after disclosure. Over a six-hour period, someone using Heartbleed pulled the social insurance numbers of about nine hundred taxpayers out of the agency’s systems. It is the only confirmed theft of personal data in this story, and it happened at an agency that took its systems down a day after disclosure. Bitstamp disabled registration, login and withdrawals on April 8; Bitfinex suspended withdrawals until its patch was in place. Neither reported a loss. Three weeks after disclosure, a hundred and fifty thousand servers were still running vulnerable code; University of Michigan researchers began contacting operators directly, and among those they reached, the patch rate rose by about half.

Every SSL certificate on every affected server was potentially compromised and needed to be revoked and replaced. Cloudflare revoked and reissued every one of its customer certificates; the revocation list at its certificate authority, GlobalSign, went from twenty-two kilobytes to four point seven megabytes in a single day, and Cloudflare put the cost of serving that one file at four hundred thousand dollars a month on GlobalSign’s bandwidth bill.

One thing decided how wide the response had to be. A password can be changed; a session cookie expires. A private key doesn’t rotate — it’s the fixed identity of the server, loaded into memory for as long as the process runs. If Heartbleed could pull that key out, an attacker who’d captured it during those twenty-five months could still use it to impersonate the server, intercept traffic, or decrypt anything previously recorded. If it couldn’t, because it was buried too deep to fall inside the sixty-four-kilobyte window the bug exposed, the response could stay narrower. Cloudflare settled it empirically, standing up a server running the vulnerable code and challenging anyone to extract its private key using nothing but the exploit. Multiple people did, reconstructing the key across repeated requests. After that, any server that had run vulnerable OpenSSL since March 2012 had to be treated as though its key were already known to an adversary.

Cryptographer Matthew Green called the missing check “a relatively mundane coding error” — the kind a careful review or routine fuzz testing would have caught, which is exactly how Codenomicon found it, after twenty-five months. OpenSSL shipped a separate FIPS 140-2 validated module, the government’s certification standard for cryptography — but that validation covered the key generation and encryption math, not the implementation code where the heartbeat extension lived. The response tried to close that gap: the Linux Foundation’s Core Infrastructure Initiative pooled funding from major tech companies for open-source projects the market had failed to sustain, alongside a Census Project mapping which packages were most critical and least resourced. By 2020 those efforts had folded into the Open Source Security Foundation. Federal bodies acted as well. The FFIEC alerted U.S. financial institutions, and in 2018 the House Energy and Commerce Committee opened its own inquiry into the open-source software the country’s critical industries ran on.

None of it changes what actually happened between March 2012 and April 2014: code that carried the encrypted identity of much of the internet was maintained by a handful of people on donations and unpaid labor. Routine fuzz testing surfaces that defect in hours, which is how Codenomicon found it. It was trusted anyway, because it was embedded too deeply to question, and that has not changed. Many of the open-source libraries doing the same job today are resourced much the way OpenSSL was in 2012. Which dependencies in your own critical path have never been looked at as closely as they’re trusted?

Zerodaylogs Ep18 Technicalbreakdown V1

578KB ∙ PDF file

Download

Download

**Sources & further reading:**

- CVE-2014-0160, National Vulnerability Database (NIST NVD)

- OpenSSL Security Advisory, April 7, 2014 (OpenSSL 1.0.1g release)

- Heartbleed.com disclosure site, Codenomicon

- Zakir Durumeric et al., “The Matter of Heartbleed,” Proceedings of the ACM Internet Measurement Conference (IMC), 2014 — post-disclosure exploitation tracking, University of Michigan / International Computer Science Institute

- Matthew Green, “Attack of the Week: OpenSSL Heartbleed,” *A Few Thoughts on Cryptographic Engineering*, April 8, 2014

- Cloudflare Blog, “Answering the Critical Question: Can You Get Private SSL Keys Using Heartbleed?” and “The Results of the CloudFlare Challenge,” April 2014

- Linux Foundation, Core Infrastructure Initiative announcement (2014) and Census Project announcement (2015)

- FFIEC, interagency statement on the Heartbleed vulnerability, April 2014

- U.S. House Energy and Commerce Committee, open-source software security inquiry, 2018

- Contemporaneous reporting on exchange responses (Bitstamp, Bitfinex), April 2014

The way in was not a software exploit. Sometime in late February or early March of 2014, according to eBay’s own disclosures, attackers compromised the login credentials of a small number of eBay employees and used them to reach the corporate network. eBay has never publicly identified the method. Secondary security-industry analysis at the time pointed to spear phishing, a targeted version of phishing built from details specific to the person being targeted, convincing enough that they click, respond, or hand over credentials somewhere they shouldn’t. That attribution is analysts reading the pattern from the outside, not something eBay itself confirmed. What is documented is that the stolen credentials worked completely on their own. No second factor was required. A password proves someone was, at some point, trusted with it — not that the person using it right now is the person it was issued to. Multi-factor authentication exists to close that gap, and on the path these attackers took, nothing of the kind stood in the way.

From there, the attackers needed roughly two months to move from the corporate network (where employees check email and use internal tools) to the production database that actually served customers. That interval is what security teams call dwell time: the gap between initial access and detection, and in this case, it is a gap eBay’s own monitoring did not close. The kind of large-scale data movement a breach like this can involve (potentially 145 million records) is exactly what database-activity monitoring and data-loss-prevention systems are built to flag. Something let it go unnoticed: tooling that was missing, mistuned, or not watched closely enough. Even so, the record shows eBay found the compromise on its own terms: about two weeks before its public disclosure on May 21, 2014, tracing an employee credential compromise back to the database it had touched. eBay then required a password reset, brought in outside security help, and reported costs of about $46 million in its next quarterly filing. eBay also described the stolen passwords as “encrypted” — not “hashed,” the more specific term for a one-way function designed to make reversing a password computationally painful. The choice of word left security researchers unable to say, from the outside, how much protection those passwords actually had.

The legal aftermath exposed how unevenly cybersecurity and the law fit together. A class action, Green v. eBay Inc., was filed in July 2014, built on a premise that seems, on its face, obvious: 145 million people’s personal information had been taken, and the company responsible for securing it should answer for that. A federal court dismissed the case in May 2015. Not because the breach hadn’t happened, and not because eBay had been cleared of any failing — the court never ruled on that question at all. It was dismissed for lack of Article III standing: a legal requirement that a plaintiff show a concrete, actual injury, not merely the risk of one. “The mere fact that Plaintiff’s information was accessed during the Data Breach is insufficient to establish injury-in-fact,” Judge Susie Morgan wrote in the order dismissing the case. Without proof the stolen data had actually been used against them (for fraud, for identity theft, for financial loss), the plaintiffs had no case to bring, whatever eBay had or hadn’t done to prevent the breach in the first place.

It also wasn’t eBay’s first time. Six years earlier, in 2008, eBay’s South Korean subsidiary disclosed a breach affecting twenty million users: internal precedent, inside the same corporate family, long before 2014. By early 2014 the Federal Trade Commission had already settled more than fifty data-security enforcement actions against other companies, establishing a working industry baseline for access controls, monitoring, and credential security that wasn’t new or untested. In July 2015, eBay and PayPal completed a split into two independent companies that had been planned before the breach for unrelated business reasons, though the breach became one more argument, among several, for why the businesses should operate apart. A decade later, eBay’s own filings describe a security posture built around specific, named controls — the kind its 2014 disclosures never spelled out. Its most recent annual report points to regular cybersecurity training and phishing-simulation testing for employees, alongside enhanced monitoring and reporting. The threat is the same one it faced in 2014. What eBay now does differently is name the specific controls it runs against it.

Zerodaylogs Ep17 Technicalbreakdown V1

579KB ∙ PDF file

Download

Download

**Sources & further reading:**

- eBay Inc., Form 8-K, Exhibit 99.1 press release, filed May 21, 2014 — SEC EDGAR

- eBay Inc., Form 10-Q for Q2 2014 — SEC EDGAR (breach description, cost figures, password-reset scope, 2008 Korea breach figure)

- eBay Inc., Form 10-K for fiscal year 2024 (filed February 27, 2025), Item 1C “Cybersecurity” — SEC EDGAR, accession 0001065088-25-000037 (current security-program controls, incl. employee cybersecurity training and phishing-simulation testing)

- Green v. eBay Inc., No. 14-1688, 2015 WL 2066531 (E.D. La. May 4, 2015) — Order and Reasons, Judge Susie Morgan

- Docket: Green v. eBay Inc., Case No. 2:14-cv-01688, E.D. La. (filed July 2014)

- eBay Inc. newsroom, “eBay Inc. To Ask eBay Users To Change Passwords,” May 21, 2014

On June 27, 2017, computers inside the shipping company A.P. Møller-Maersk began rebooting on their own. When the screens came back, each one showed the same demand: pay $300 in Bitcoin, get your files back. In the first ninety seconds, 10,000 machines were destroyed. Within five minutes the number had doubled. And the ransom note was a lie. The encryption was irreversible by design; no key existed, and no payment could undo it.

Maersk ran one of the largest shipping and logistics operations on Earth — 76 port facilities worldwide, container supply chains where a single day offline ripples through global commerce. The malware that destroyed its network did not arrive through Maersk’s own systems. It arrived through a piece of Ukrainian tax software called M.E.Doc, and to understand how, you have to start with the way software updates earn their trust.

M.E.Doc was a finance and accounting application, built by a Ukrainian company called Intellect Service and used by businesses operating in Ukraine to file taxes. It was ordinary software, the equivalent of a regional payroll platform. Maersk had operations in Ukraine, Ukrainian tax compliance required it, and so those operations ran M.E.Doc — as did thousands of other companies with Ukrainian subsidiaries or partners, multinationals whose global networks were connected, through routine business, to machines running this one piece of regional software.

A software update works like a sealed letter from a trusted sender. The seal — a digital signature called a code-signing certificate — confirms the letter came from who it claims to come from. Security systems check the seal; if it is valid, the update is installed. What the seal cannot verify is whether someone tampered with the contents before it was applied: an attacker who reaches the place where the software is assembled can insert whatever they want before it ships. The seal will be real; the contents will be whatever the attacker put there.

The attackers stole an Intellect Service employee’s credentials and used them to reach the update server, the distribution point for new M.E.Doc versions. Beginning as early as April 14, 2017, they modified those updates to include a backdoor: a hidden entrance that shipped to every customer on the normal schedule, under a valid signature, for more than two months. Every security check those customers ran came back clean. On June 27, the attackers used the backdoor to push the payload.

Once the payload landed on a single workstation, it needed credentials that would let it authenticate as a legitimate user on other machines. It had them within moments, by reading the part of the operating system’s memory where Windows keeps login information for active sessions, where credentials sit ready for use by any process with sufficient privileges. This is less cracking passwords than picking the pocket of every employee currently logged in. A machine with four active users yields four sets of credentials; a domain controller yields the keys to the entire building.

With those credentials the malware moved laterally, using two tools that exist on virtually every Windows computer: PsExec, a remote administration utility that lets an authorised user run commands on another machine, and WMI, a Windows management service that does much of the same work. Both are legitimate, present by default, and did exactly what they were designed to do: they accepted valid credentials and executed instructions. A burglar holding the building’s master key does not need to pick locks. He walks through the doors.

Where credentials were not enough, the malware went through the wall instead. Two exploits for SMBv1, a decades-old Windows file-sharing protocol — EternalBlue and the related EternalRomance — let it take machines with no username or password at all. Microsoft had published a patch for both on March 14, 2017, more than three months before the attack. Machines that had applied it were protected; machines that had not, including some running systems so old that no patch existed, were exposed.

The combination made the spread fast. Credential theft handled the well-maintained machines; EternalBlue and EternalRomance handled the neglected ones; PsExec and WMI carried the payload across every reachable subnet. No operator issued instructions between targets: each infected machine immediately scanned for the next, each new infection spawning another wave of scans — a fire jumping from floor to floor faster than anyone could close the doors. That is how 10,000 machines fell in ninety seconds.

The costume comes off

It looked like ransomware. The screen named a price, a single Bitcoin wallet, a contact email for the decryption key. But the malware had overwritten the master boot record, the index a computer reads at power-on to find everything on the drive, and destroyed the underlying file table, the structure mapping every file to its physical location. Imagine ripping the table of contents, the index, and every page number out of a book, then shuffling every page into random order. The words on each page still exist, but nobody can reconstruct the original sequence, including the person who shuffled it.

Each victim’s ransom screen displayed a unique installation identifier to send in with payment. The identifier was random, with no mathematical relationship to the encryption; no decryption mechanism existed. Paying produced nothing, because there was nothing to produce. The ransom note was a costume. Underneath it was a wiper — malware built to destroy data permanently, dressed as the kind of criminal operation that wants money.

Maersk was the most visible victim, not the only one. Merck, one of the largest pharmaceutical companies in the world, lost more than 40,000 machines; its own SEC filing reported $260 million in lost sales and $285 million in remediation costs. Production lines went dark, including Gardasil 9, the HPV vaccine recommended for adolescents across the United States — disruption severe enough that Merck borrowed doses from the CDC’s Pediatric Vaccine Stockpile while its own production recovered.

FedEx’s European subsidiary TNT Express lost $400 million and ran on manual processes for weeks. Mondelēz International, the company behind Oreo and Cadbury, reported 24,000 laptops and 1,700 servers destroyed and losses over $100 million. Heritage Valley Health System, a regional healthcare provider running eighty medical facilities, lost thousands of computers; patient lists, medical histories, and lab records became unavailable, and pre-operative work for scheduled surgeries had to be redone from scratch.

At Maersk, of 76 port terminals worldwide, the company could manage 17, and those 17 ran on paper. Employees communicated through WhatsApp and personal Gmail accounts because every corporate system was down. There was no quiet investigation period — Maersk, Mondelēz, and Nuance Communications all disclosed on June 27 itself; the destruction was too visible and simultaneous to hide. The White House later put the aggregate worldwide cost at $10 billion.

Maersk’s IT staff disconnected the entire global network within two hours of the first infection — the only way to stop the malware from reaching systems it had not yet touched. The damage was already complete: 45,000 PCs, 4,000 servers, the digital infrastructure of one of the world’s largest logistics operations. The question was whether recovery was possible at all.

In any large organisation running Windows there is a system called Active Directory, a central registry of every user, machine, and permission on the network — the master ledger of who works here and which doors they can open. The servers holding and replicating that ledger are called domain controllers. Destroy them all and you do not simply lose data; you lose the ability to rebuild, because the system that would authenticate every restored account is itself gone. Maersk’s domain controllers were synchronised and online when the malware hit, and every one was wiped.

Every one except one. Maersk operated a small office in Accra, Ghana, and at the moment the malware spread, that office was in the middle of a power outage. Its domain controller was offline and never received the payload. When the power came back, that single server held the only surviving copy of Maersk’s entire Active Directory. The machine was flown to the United Kingdom, Deloitte was brought in, and from that one server Maersk rebuilt its identity infrastructure — 4,000 servers reinstalled, 45,000 PCs reimaged, each machine rejoined and re-authenticated against the restored directory. The work took weeks. No resilient architecture had kept that server offline by design. Its survival was an accident.

The authors

On October 19, 2020, the U.S. Department of Justice indicted six officers of Unit 74455 of the GRU, Russia’s military intelligence agency — the unit security researchers know as Sandworm: Yuriy Andrienko, Sergey Detistov, Pavel Frolov, Anatoliy Kovalev, Artem Ochichenko, and Petr Pliskin. The attribution rested on a federal grand jury indictment, a criminal investigation rather than a policy announcement, supported by public statements from the UK government and the White House. Prosecutors called it the most destructive and costly cyberattack in history, and federal arrest warrants were issued for all six.

The target was Ukraine. M.E.Doc was Ukrainian software used by Ukrainian businesses, with the backdoor in place since April. But the malware did not check passports. It spread wherever an unpatched machine or a valid credential could carry it, which is how a Ukrainian tax application ended up destroying pharmaceutical production in New Jersey, shutting down shipping terminals in Rotterdam, and disrupting surgeries in Pennsylvania.

The insurance claims that followed reshaped an industry. Merck filed against its property insurers, including ACE American Insurance Company; Mondelēz filed against Zurich. Kroll examined the forensic evidence on behalf of Merck’s insurers, and both insurers invoked the same clause: the “hostile or warlike action” exclusion, a standard provision in property policies that excludes damage caused by acts of war. The argument was straightforward. A military intelligence agency of a sovereign nation had launched a destructive attack, and that, the insurers said, was war.

Neither case ended in a final verdict. Merck won real rulings: a New Jersey trial court in 2021 and the state’s appellate division in 2023 both rejected the exclusion, holding that a cyberattack on a non-military company did not meet a definition written for a world of bombs and invasions rather than malware delivered through a tax update. Then, in January 2024, before the New Jersey Supreme Court could hear the case, Merck and its insurers settled on undisclosed terms. Mondelēz’s case produced no ruling at all; it settled mid-trial in November 2022, leaving no precedent behind. The litigation still forced a rewrite: the insurance industry redrafted its cyber exclusion language, creating policy terms specifically for state-sponsored cyberattacks, terms that had not existed because the scenario had never been tested in court.

None of the controls that could have limited the damage were exotic. The patch had been available for more than three months. SMBv1, decades old and long superseded, could have been disabled entirely; Microsoft had published guidance for doing exactly that. Network segmentation could have stopped an infected workstation in Ukraine from reaching domain controllers on the other side of the world — the malware crossed those internal boundaries because they did not exist. And a single offline domain controller backup, disconnected by policy rather than by accident, would have been the difference between a recovery that took weeks and one that might never have happened. Every one of those controls was available before June 27, 2017, the earliest by more than a decade.

Some of the lesson landed. Maersk approved what internal accounts described as practically every security feature its IT team had ever requested, including multi-factor authentication and a company-wide upgrade to Windows 10. Merck built measures to speed any future recovery. Companies that had relied on single suppliers began diversifying their vendors. What remains is the shape of the attack itself: a supply chain turned into a weapon, built to destroy rather than to steal or extort. And the recovery of the largest shipping company on Earth rested, in the end, on one server in Accra that went dark at exactly the right moment, for a reason that had nothing to do with cybersecurity.

Zerodaylogs Ep16 Technicalbreakdown V1

592KB ∙ PDF file

Download

Download

Sources & further reading

Andy Greenberg, Wired — “The Untold Story of NotPetya, the Most Devastating Cyberattack in History”

U.S. DOJ, Oct. 19, 2020 press release — indictment of six GRU Unit 74455 officers

Merck & Co. v. ACE American Insurance Co. — NJ Superior Court (2021) / NJ Appellate Division (2023) rulings; settlement reporting (Insurance Journal, Cybersecurity Dive, Jan. 2024)

Mondelēz International v. Zurich American Insurance Co. — Illinois Circuit Court, settlement reporting (Reinsurance News, The Register, Nov. 2022)

White House statement, Feb. 2018 — $10 billion global damage estimate

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.