Six Cyber Warfare Examples Lawyers and Investigators Must Study

computer forensic services

Six Cyber Warfare Examples Lawyers and Investigators Must Study

Seo Admin
01/09/2026

Cyber warfare refers to state‑grade digital operations designed to disrupt, sabotage, or gather intelligence against another nation’s infrastructure, government, or economy. The canonical examples every practitioner should study are Stuxnet, NotPetya, Industroyer, the Viasat KA‑SAT attack, the Morris Worm, and WannaCry. Each represents a distinct technical approach and a distinct forensic lesson, and together they map how cyber warfare evolved from accidental disruption to deliberate, coordinated sabotage.

TL;DR:

  • Most devastating cyber attacks, like NotPetya and WannaCry, can cause billions in damage and disrupt supply chains, even without direct theft.
  • State-sponsored malware like Stuxnet and Industroyer demonstrate that digital operations can cause physical damage to infrastructure and power grids.
  • Effective response relies on early evidence preservation, proper network segmentation, verification of update sources, and expert forensic investigation.
  • Attribution is complex, relying on code reuse, infrastructure analysis, and delayed intelligence, making immediate identification of perpetrators difficult.
  • Small organizations and legal teams must implement robust cybersecurity hygiene and forensic readiness to minimize recovery time and legal exposure.

Table of Contents

Timeline and origins of cyber warfare

Cyber warfare did not begin with a government directive. It began with an accident. The Morris Worm in 1988 was written as an experiment in measuring the size of the internet, but a coding flaw turned it into a self‑replicating program that crippled thousands of university and research computers. It was not state‑directed sabotage, but it proved that a single piece of code could paralyse networked infrastructure across an entire country within hours. That lesson sat mostly dormant for two decades.

The next real inflection point came in 2007, when Estonia suffered a sustained wave of distributed denial‑of‑service attacks against government, banking, and media websites following a political dispute with Russia. Estonia’s experience mattered less for its technical sophistication and more for what it signalled: that a state actor’s political grievance could translate directly into coordinated pressure on a nation’s digital infrastructure, with no soldier ever crossing a border.

Stuxnet, discovered in 2010, changed the calculus entirely. It was the first widely documented case of malware causing physical damage to industrial equipment, and it demonstrated that code could achieve what previously required an airstrike.

The period from 2015 to 2017 then produced a rapid escalation:

  • 2015: A coordinated attack on Ukrainian power distribution companies used remote access to manually trip circuit breakers, cutting electricity to a large number of residents.
  • 2016: Industroyer automated that same objective, removing the need for a human operator inside the network at the moment of attack.
  • 2017: NotPetya spread globally through a single compromised Ukrainian accounting software update, causing extensive unintended damage to companies with no connection to the original target.

The 2022 invasion of Ukraine produced the most recent high‑intensity example, pairing cyber operations like the Viasat KA‑SAT attack directly with military movements. That fusion of digital and physical operations is now the defining feature of contemporary cyber warfare examples, rather than an occasional tactic.

Operational types of cyber warfare and their strategic effects

Cyber warfare is not one activity. It is a set of distinct operational categories, each aimed at a different strategic outcome, and mapping a real incident to each category makes the distinctions concrete rather than academic.

  • Espionage: long‑term, quiet access to networks for intelligence gathering, often running for years before detection, focused on data theft rather than disruption.
  • Sabotage and destructive attacks: operations intended to damage physical equipment or destroy data outright, exemplified by Stuxnet’s centrifuge sabotage, NotPetya’s irreversible disk‑wiping, and Industroyer’s grid manipulation.
  • Denial and disruption: attacks that deny access to a service or communications channel without necessarily destroying anything, such as distributed denial‑of‑service campaigns or the Viasat KA‑SAT modem outage that severed satellite internet access across parts of Europe.
  • Information and propaganda operations: hack‑and‑leak campaigns that steal sensitive material and release it selectively to shape public opinion or discredit an institution.
  • Economic disruption and collateral damage: unintended consequences that ripple far beyond the original target, as NotPetya demonstrated when a Ukraine‑focused attack cost multinational shipping and pharmaceutical firms hundreds of millions of pounds each.

These categories overlap in practice. Industroyer was simultaneously sabotage and a denial‑of‑service against an entire regional population’s electricity supply. NotPetya was framed as ransomware but functioned as a destructive wiper with no genuine recovery mechanism. Reading an incident against these five categories is usually the fastest way to understand what an attacker was actually trying to achieve, as opposed to what the malware superficially resembled.

Case study: Stuxnet and industrial control sabotage

Stuxnet remains the reference point for industrial sabotage because it did something no prior malware had achieved: it physically destroyed equipment through pure code. The worm spread initially via infected USB drives, since its designers knew Iran’s Natanz nuclear facility used air‑gapped networks that conventional internet‑based malware could never reach. Once inside a network, it propagated further using a combination of network exploits and shared print‑spooler vulnerabilities.

What made Stuxnet historically significant was its precision. The malware carried a PLC rootkit and used multiple zero‑day vulnerabilities to target Siemens Step7 programmable logic controllers specifically, meaning it would lie dormant and harmless on any system that did not match the exact industrial configuration it was hunting for. Only when it fingerprinted the precise centrifuge control setup used at Natanz did it activate its payload, subtly altering rotor speeds to cause physical wear while feeding false readings back to plant operators.

Attribute Detail
Discovery year 2010
Initial vector Infected USB removable drives
Target Siemens Step7 PLCs at uranium enrichment facilities
Key technique PLC rootkit with environment fingerprinting
Zero‑days used Multiple, including print‑spooler exploits
Attribution Widely linked to state‑level actors, never formally confirmed by any government

The rootkit component deserves particular attention from a forensic standpoint. It intercepted and rewrote the exact code blocks running on the PLC, then hid those changes from the engineering software used to monitor the system, so operators watching their control panels saw entirely normal readings while centrifuges spun themselves apart. Reverse engineering that behaviour required researchers to disassemble industrial firmware few outside the automation industry had ever examined, effectively creating an entirely new sub‑discipline within malware analysis.

Pro Tip: When examining any suspected ICS‑targeted malware, always extract and preserve PLC ladder logic separately from the host operating system image. Attackers increasingly hide their real payload inside the controller logic itself, not the Windows or Linux layer investigators check first.

The forensic lesson from Stuxnet is that industrial malware analysis cannot stop at the infected laptop. Investigators had to trace the infection chain back through engineering workstations, removable media logs, and eventually the PLC’s own memory to understand what the code was actually doing to physical machinery. That layered approach, treating the control system as evidence in its own right rather than an afterthought, remains the template for malware analysis in critical infrastructure cases today.

Case study: NotPetya and destructive supply‑chain compromise

NotPetya began as a corrupted update pushed through M.E.Doc, a Ukrainian tax accounting program used by thousands of businesses operating in or with Ukraine. Once installed, the malware used the EternalBlue exploit and harvested credentials from infected machines to move laterally across networks at extraordinary speed, encrypting master boot records within minutes of initial compromise.

Unlike genuine ransomware, NotPetya offered victims no realistic path to recovery. Its encryption process corrupted data in a way that made the ransom payment mechanism cosmetic; even organisations willing to pay could not retrieve their files. That single design choice is why investigators and courts eventually classified it as a wiper disguised as ransomware, not a criminal extortion tool.

NotPetya caused roughly $10 billion in global damage, with shipping giant Maersk alone reporting losses in the hundreds of millions of dollars and undertaking large-scale reinstallation of tens of thousands of PCs across many countries.

The scale of that collateral damage reshaped how insurers think about cyber risk. Several affected companies discovered their existing policies excluded losses caused by “acts of war,” triggering years of litigation over whether a state‑attributed cyberattack qualifies under that clause. Mondelez and Merck both pursued insurance claims that hinged on exactly this question, forcing courts to define, for the first time, where cyber warfare sits on the spectrum between crime and armed conflict.

The technical and legal fallout from NotPetya produced several durable lessons:

  • A single shared software dependency can become a single point of failure for an entire economy’s supply chain.
  • Destructive intent can be disguised convincingly as financially motivated ransomware, delaying appropriate incident response.
  • Insurance frameworks written before 2017 were not built to price state‑attributed digital sabotage.
  • Recovery costs for global firms routinely exceed the original attacker’s likely target value by orders of magnitude.

Case study: Industroyer and the Ukraine power‑grid attacks

The December 2015 attack on Ukrainian power distribution companies relied on something almost mundane by comparison to what followed: attackers who had gained remote access simply used the existing SCADA interface to open circuit breakers manually, cutting power to roughly 230,000 people for a few hours. It worked, but it required a human operator inside the network at the critical moment, which limited how quickly and precisely the attack could scale.

Industroyer, deployed against the Ukrainian grid in December 2016, removed that human dependency entirely. It automated the entire process.

  • Industroyer’s modular payload architecture supported multiple industrial communication protocols simultaneously, including IEC 101, IEC 104, IEC 61850, and OPC‑DA.
  • Each protocol module could be swapped independently, letting the same malware framework target substations built on entirely different vendor equipment.
  • A later variant, Industroyer2, condensed this capability into a single executable rather than a modular toolkit, suggesting an operational shift toward speed and simplicity over flexibility.
  • Both versions were built to issue destructive commands directly to grid hardware rather than merely disabling monitoring software.

That protocol‑level fluency is what separates Industroyer from generic malware. IEC 61850 and OPC‑DA are specialist industrial standards that most conventional malware analysts never encounter, meaning the people who wrote Industroyer had either studied real substation engineering documentation or had direct access to someone who had. This is one reason academic analysis of the malware treats it as a benchmark for how deeply an adversary can embed itself in sector‑specific technical knowledge before ever touching a target network.

For resilience planning, the practical implication is stark. Firewalls and network segmentation slow an attacker down, but they do nothing to stop malware that speaks the native language of the equipment it is attacking once it gets inside. Grid operators have since pushed harder on protocol‑level anomaly detection, rather than relying solely on perimeter defence, precisely because Industroyer demonstrated that the substation itself needs to be treated as a monitored asset, not just the corporate network sitting in front of it.

Electrical substation equipment behind security fencing

Case study: Viasat KA‑SAT and communications disruption

On 24 February 2022, the same morning Russian forces began their invasion of Ukraine, tens of thousands of satellite internet modems across Europe simply stopped working. The Viasat KA‑SAT network had been compromised not through the satellite itself, but through a far more mundane weakness: a misconfigured VPN appliance connecting to the network’s management segment.

  • Attackers used that VPN foothold to reach the ground‑based management infrastructure that controls customer terminals.
  • From there, they issued legitimate management commands rather than exploiting any flaw in the satellite hardware or signal itself.
  • Those commands overwrote flash memory on modems, permanently corrupting the firmware needed to boot.
  • Recovery for many affected units required physical replacement or a factory‑level reset, not a simple software patch.

That last point is what makes the KA‑SAT incident distinct from most disruptive attacks. There was no data stolen, no ransom demanded, and no encryption deployed. The attackers simply told thousands of devices to destroy their own configuration using commands the network’s own management system was designed to trust. Fixing that kind of damage means physically touching hardware scattered across an entire continent, which is precisely why the outage rippled into wind farm monitoring systems in Germany and internet services well beyond Ukraine’s borders, despite Ukraine being the evident intended target.

The timing left little ambiguity about intent, even though formal attribution took months to arrive through statements from Western governments. A satellite communications provider going dark at the exact moment ground forces cross a border is not coincidence; it is a deliberate attempt to blind command‑and‑control communications in the opening hours of a conflict, and it worked far beyond its intended geographic scope.

Satellite communications dish at dusk

Other canonical incidents worth knowing

Several other cases sit alongside the major examples above in nearly every serious study of cyber warfare, and each teaches a slightly different lesson despite receiving less forensic detail here.

  1. The Morris Worm (1988): Written by a graduate student as a network‑measurement experiment, a bug in its replication logic caused it to infect the same machines repeatedly, overwhelming systems and effectively taking down large portions of the early internet. It was never state‑directed, but it is the reason modern computer security research and incident response as disciplines exist at all.
  2. WannaCry (2017): This ransomware spread using the leaked EternalBlue exploit, the same NSA‑developed tool later reused in NotPetya, and infected over 200,000 computers across roughly 150 countries within days. Its ransom screen demanded payment in bitcoin, but its rapid, uncontrolled spread through unpatched Windows systems caused far more disruption, including to parts of the UK’s National Health Service, than its modest financial returns would suggest was the actual goal.
  3. Olympic Destroyer (2018): Deployed against the opening ceremony of the Winter Olympics in South Korea, this malware was deliberately engineered with false digital fingerprints pointing toward other nations, making it a textbook example of how attackers now weaponise misattribution itself as a defensive and disruptive tactic.

Common techniques and entry vectors across these attacks

Reading through Stuxnet, NotPetya, Industroyer, and Viasat side by side, the same handful of techniques resurface again and again, regardless of the target sector or the attacker’s apparent nationality.

  • Supply‑chain compromise: poisoning a trusted software update, as with NotPetya’s M.E.Doc vector, to reach victims who would never open a suspicious email.
  • Spearphishing and credential theft: still the most common initial access route into any network, industrial or otherwise, because it exploits people rather than code.
  • Zero‑day exploitation: reserved almost exclusively for high‑value, well‑resourced operations, since burning an unpatched vulnerability against a low‑value target wastes a resource that is expensive and slow to replace.
  • Lateral movement using stolen credentials: once inside, attackers rarely need further exploits if they can harvest administrator passwords from memory, exactly as NotPetya did.
  • Abuse of legitimate management functions: the Viasat attack needed no exotic exploit once it reached the management plane, because the system trusted its own commands implicitly.
  • Wiper logic disguised as ransomware: increasingly common where the true objective is destruction, not extortion.

Human error remains the quiet constant behind nearly every one of these vectors. Even the most technically elaborate operations, including Stuxnet, still relied at some stage on someone plugging in a USB drive or an administrator reusing a password across systems that should have been isolated from each other.

Pro Tip: If you are auditing your own organisation’s exposure, start by mapping every third‑party software update channel with unrestricted network trust. NotPetya proved that a single accounting package can become the weakest link in an entire multinational’s security posture.

How forensic investigators examine these incidents

Reconstructing a state‑grade cyberattack after the fact is fundamentally different from investigating ordinary cybercrime, because the evidence often spans operating system logs, network traffic captures, and, in cases like Stuxnet or Industroyer, the firmware of industrial equipment that was never designed with forensic examination in mind.

A thorough investigation typically works through several layers of evidence in parallel rather than sequentially:

  • Timeline reconstruction: correlating file timestamps, network logs, and system event records to establish exactly when compromise occurred and how it spread.
  • Memory and disk forensics: capturing volatile memory before a system is powered down, since malware like NotPetya’s wiper components can destroy the very evidence needed to prove what happened.
  • Malware reverse engineering: disassembling the payload itself to understand its intended function, command structure, and any embedded fingerprinting logic.
  • PLC and ICS artefact recovery: extracting controller logic and configuration data separately from the host system, a step that proved essential in the Stuxnet investigation.

The single most common mistake in early‑stage incident response is powering down affected systems before volatile memory and network state have been captured. That instinct to “stop the bleeding” often destroys the exact evidence a legal team will need six months later to prove what actually happened and who is liable.

Findings from this kind of work rarely stay confined to a technical report. They feed directly into expert witness testimony in civil litigation, insurance disputes over policy exclusions, and occasionally into the public attribution statements governments issue when naming a state actor. Every stage of that chain depends on evidence being collected, documented, and preserved in a manner that will withstand scrutiny in court, which is precisely the discipline behind chain of custody procedures in digital forensics. Computer Forensics Lab’s own documented case work reflects exactly this layered approach when supporting legal and corporate clients through incident investigations.

Proving who launched a cyberattack is rarely straightforward, because sophisticated actors deliberately route traffic through third countries, reuse other groups’ tools, and plant false linguistic or code artefacts to mislead investigators, exactly as Olympic Destroyer’s authors did.

  • Technical attribution usually relies on correlating malware code reuse, command‑and‑control infrastructure, and operational timing patterns across multiple unrelated incidents rather than any single piece of evidence.
  • Public attribution typically arrives months or years after the event, once intelligence agencies are confident enough to state it formally.
  • The October 2020 U.S. indictment of six GRU officers explicitly named NotPetya and Industroyer among the destructive campaigns allegedly directed by the group, one of the clearest formal links between a specific state agency and specific malware families on public record.
  • Sanctions and criminal charges rarely lead to extradition or trial, but they still shape diplomatic relationships and insurance case law.

That last point matters enormously for victims. When Mondelez and Merck pursued insurance claims after NotPetya, the central legal question was whether a state‑attributed attack triggers a policy’s “act of war” exclusion, a clause originally written for tanks and missiles, not malware. Courts have generally sided with policyholders so far, but insurers have since rewritten policy language specifically to close that gap, meaning organisations today face far more legal uncertainty over cyber warfare coverage than in 2017.

Every case study above points toward the same practical conclusion: technical hygiene and forensic readiness are not separate disciplines, they are two halves of the same defence.

  1. Segment industrial and corporate networks completely. Ukraine’s grid operators and countless NotPetya victims shared one weakness: a single compromised point could reach systems that should never have been reachable from it.
  2. Treat software update channels as a trust boundary, not a formality. Verify signing and provenance on every update before it reaches production systems, particularly for third‑party accounting or management software.
  3. Apply privileged‑access management rigorously. Credential theft enabled lateral movement in nearly every case examined here.
  4. Keep immutable, offline backups. NotPetya’s victims who recovered fastest were the ones with backups an attacker inside the network could not also encrypt or delete.
  5. Preserve logging and volatile evidence before remediation begins. Retain network logs, memory captures, and system states for a period long enough to support any later investigation.
  6. Know when to call a specialist. Instruct a digital‑forensics team as soon as a destructive or state‑grade attack is suspected, not after internal IT has already rebuilt the affected systems.

Smaller organisations often assume these lessons apply only to critical infrastructure operators, but the practical controls that protect small businesses overlap substantially with what protected Maersk and Merck, just at a different scale. Law firms in particular carry client data that makes them attractive targets in their own right, and security checklists built for legal practices address many of the same credential and access weaknesses seen across these case studies.

Pro Tip: Draft your incident response plan around a single rule: nobody touches a compromised system until volatile evidence has been captured and the decision to call in forensic specialists has been made. Rebuilding first and investigating second is how most usable evidence gets destroyed.

Why these cases still matter, from a practitioner’s perspective

Studying Stuxnet, NotPetya, Industroyer, and Viasat side by side reveals something conventional cybersecurity training often misses: the technical sophistication of an attack rarely predicts the size of its damage. NotPetya’s most expensive consequences hit companies with no strategic connection to its intended target, purely through shared software dependencies. That should worry every organisation more than the prospect of being deliberately targeted.

Computer Forensics Lab’s work supporting legal and corporate clients through cyber incident investigations has reinforced one consistent pattern: the organisations that recover fastest and defend their position most credibly in court are the ones that treated evidence preservation as seriously as the technical response itself. That discipline, not just the malware analysis, is usually what separates a defensible legal position from a costly one.

— Computer

How Computer Forensics Lab supports organisations after a cyber warfare style incident

Investigating a destructive or state‑grade attack demands more than antivirus logs and a firewall report. Computer Forensics Lab provides malware analysis, data recovery, and chain of custody management for organisations facing exactly the kind of sophisticated, high‑impact incidents examined throughout this article, alongside expert witness reports built to withstand scrutiny in litigation or insurance disputes. Whether you are a solicitor building a case, a company director responding to a suspected wiper attack, or a corporate legal team weighing an “act of war” exclusion, engaging a specialist early preserves the evidence that later proves what happened and who is liable. Our digital forensics services cover the full investigative lifecycle, from initial evidence capture through to courtroom‑ready reporting. Contact Computer Forensics Lab to discuss a suspected incident before remediation destroys the evidence you will need.

Sources