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.

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

What are disclosure controls?

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

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

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

Why this matters beyond Yahoo

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

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

The question worth asking

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

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

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

Zerodaylogs Ep08 Technicalbreakdown V1

29KB ∙ PDF file

Download

Download

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

---

### 1. The pipeline was physically fine.

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

Colonial shut the pipeline down voluntarily.

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

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

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

---

### 2. Eleven years without an update.

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

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

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

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

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

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

---

### The episode

If you haven’t watched yet:

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

🎧 Podcast drops in 2-3 days on all platforms

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

Zerodaylogs Colonialpipeline Technicalbreakdown

26.6KB ∙ PDF file

Download

Download

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

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

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

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

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

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

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

Three questions worth sitting with:

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

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

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

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

Zerodaylogs Ep06 Technicalbreakdown V1

61.9KB ∙ PDF file

Download

Download

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

What the episode covers

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

The part the episode couldn’t go deeper on

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

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

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

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

Technical breakdown

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

Zerodaylogs Ep05 Technicalbreakdown V1

85.1KB ∙ PDF file

Download

Download

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

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

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

The real-time credential relay deserves a closer look.

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

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

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

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

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

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

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

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

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

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

Zerodaylogs Ep04 Technicalbreakdown V1

29.4KB ∙ PDF file

Download

Download

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

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

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

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

Zerodaylogs Ep03 Solarwinds Technicalbreakdown

48.7KB ∙ PDF file

Download

Download

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

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

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

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

Zerodaylogs Ep02 Okta Technicalbreakdown

46.5KB ∙ PDF file

Download

Download