← Course Home Moraine Valley Community College · Dept. of Engineering & Technology · Dr. John L. Sands
OT-101 · Day 3 · Lesson 6 · 4 Contact Hours

The OT Threat Landscape

Who attacks industrial systems and why, how ransomware crosses from the business network into production, and what documented insider, contractor, and supply-chain incidents teach us about where trust gets misplaced.

⚠ Case study analysis only
📊 Intermediate ⏱ 4 hours 🎯 6 objectives

Lesson Overview

For decades, the people who ran industrial plants and the people who ran cybersecurity programs worked in different worlds. Plant engineers worried about corrosion, vibration, and pressure limits. Security teams worried about stolen credit card numbers and leaked emails. That changed in 2010, when researchers discovered a piece of malware, later named Stuxnet, that had been quietly spinning uranium enrichment centrifuges at Iran's Natanz facility past their designed limits — using entirely legitimate industrial control commands — until the equipment tore itself apart. Stuxnet did not steal data. It did not encrypt files for ransom. It reached across the air gap that everyone assumed protected the plant, through an infected USB drive and manipulated engineering project files, and it caused physical, mechanical damage to spinning machinery by lying to the operators watching the control room screens. Security leaders who had spent their careers thinking about confidentiality and data loss suddenly had to reckon with a new category of consequence: malware that breaks things, hurts people, and stops production — not as a side effect, but as the entire point. Every case study in this lesson descends from that same realization.

Anchoring analogy

Think of a manufacturing plant's defenses like a hospital. The front lobby (the business network) has a receptionist, a badge reader, and cameras — reasonable but not extreme security, because the lobby itself isn't where the danger is. The operating rooms (the control systems that actually run pumps, valves, and centrifuges) are supposed to be a different world entirely, with restricted access and constant monitoring, because a mistake there can hurt a patient, not just embarrass the front office. Before Stuxnet, most industrial security thinking assumed a locked door between the lobby and the operating room was permanent and sufficient. This lesson is about the incidents that proved intruders can walk through that door — sometimes by breaking it down, sometimes because an employee, contractor, or trusted vendor leaves it propped open — and about what shows up on the operating table when they do.

Learning objectives

By the end of this lesson, you will be able to:

  • Explain how the discovery of Stuxnet changed how security leaders assess risk to physical, safety-critical systems.
  • Identify the primary categories of OT threat actors and the motivations that distinguish them.
  • Describe the typical path ransomware takes from a business-network infection to an operational shutdown.
  • Compare insider risk and third-party/contractor risk as distinct categories of OT threat.
  • Evaluate a supply-chain compromise case study to identify where trust was misplaced and what controls could have limited its impact.
  • Analyze a simulated attack-path scenario to explain how each stage of intrusion increases operational risk.
Part A · Threat Landscape Lecture

Threat Actors and Their Motivations

≈ 50 min

A threat actor is any individual or group whose actions, intentional or not, could cause harm to an information or control system. In OT security, it is worth resisting the instinct to picture a single archetype — a hooded figure at a keyboard — because the actors who actually show up in ICS incident reports have sharply different resources, patience, and goals, and those differences change what a defender should watch for. Nation-states bring years of patience and custom-built tools aimed at strategic disruption or espionage. Cybercriminal ransomware groups want a fast payout and usually don't care whether their victim happens to run a chemical plant or a law firm. Hacktivists want an audience and a headline. Insiders and contractors don't need to break in at all — they already have a badge, a password, or a maintenance contract. Understanding which category you're facing changes everything about how you defend against it.

Nation-State

Motivation: strategic advantage

Well-funded, patient, and willing to spend years inside a network before acting. Often after espionage or the ability to disrupt an adversary's infrastructure during a future crisis.

Cybercriminal / Ransomware Group

Motivation: financial extortion

Runs ransomware as a business. Usually targets the business network first; an OT shutdown is often collateral damage rather than the direct goal.

Hacktivist

Motivation: ideology / attention

Wants a visible statement, not stealth. Frequently targets internet-exposed HMIs found through public search tools rather than sophisticated intrusion.

Malicious Insider

Motivation: revenge / financial gain

Already holds legitimate credentials and process knowledge. Does not need to breach a perimeter that a badge already opens.

Negligent Insider

Motivation: none — unintentional

Clicks the phishing link, reuses a password, or plugs in an unverified USB drive. The most common opening move in documented ransomware cases.

Third-Party / Contractor

Motivation: varies — often unwitting

Holds trusted remote-access credentials to do legitimate maintenance work. An attacker who compromises the contractor inherits that trust.

Concept map: six categories of OT threat actor, grouped by motivation. The dividing line that matters most for defense is not "outsider versus insider" but "does this actor need to defeat the perimeter, or does the perimeter already trust them?"

Case study — Ukraine power grid, 2015 and 2016

Nation-state · attributed to the group known as Sandworm

In December 2015, attackers used spear-phishing to gain a foothold on the corporate network of several Ukrainian regional power distribution companies, then used stolen VPN credentials to reach the SCADA network and remotely open breakers at dozens of substations — cutting power to roughly 230,000 customers. Operators had to travel to substations and close breakers manually to restore service. A year later, a follow-up incident used purpose-built malware known publicly as Industroyer/CrashOverride, which understood the specific industrial protocols the Ukrainian grid used well enough to issue commands directly to substation equipment. Both incidents are widely read as demonstrations of patient, well-resourced, nation-state capability aimed squarely at causing physical disruption to critical infrastructure — not at stealing data.

Teaching note

A useful in-class prompt: ask faculty which threat-actor category their own institution's building-automation or lab equipment is most exposed to. Most community colleges are unlikely nation-state targets, but hacktivists scanning for exposed HMIs, and contractors with standing remote-access credentials, are realistic concerns for almost any campus.

Ransomware Crossing from the Business Network into Production

≈ 55 min

Ransomware is malware that encrypts an organization's files and demands payment for the decryption key, and it is today the single most common way an OT environment ends up affected by a cyber incident. The important pattern to teach — because it surprises IT-background students — is that ransomware usually does not need to touch a single PLC to shut down production. In the majority of documented cases, ransomware infects business-network systems: email servers, file shares, engineering workstations, the historian database that stores years of process data. The plant then shuts down not because the controllers were attacked, but because operators can no longer safely bill customers, track inventory, dispatch, or trust the systems that support safe operation — so it shuts down as a precaution. This is exactly what happened to Colonial Pipeline.

Typical ransomware attack path from the business network into production, mapped to Purdue model levels A ransomware attack path usually begins with a phishing email reaching a laptop in the Enterprise IT zone at Purdue levels four and five. From there the attacker moves laterally within IT, then reaches a poorly segmented system in the demilitarized zone that bridges IT and OT, such as a historian mirror. From the DMZ the impact spreads into the Supervisory and Control zone at levels two and three, affecting engineering workstations and HMI servers. The Field and Process zone at levels zero and one, containing PLCs and physical equipment, is often never directly touched — but production stops anyway because operators can no longer safely see or manage the process. Enterprise IT — Levels 4–5 Phishing email lands on a business-network laptop; attacker moves laterally DMZ — Level 3.5 A poorly segmented bridge system (e.g. a historian mirror) crosses from IT into OT Supervisory & Control — Levels 2–3 Engineering workstations and HMI servers are impacted; operators lose visibility Field & Process — Levels 0–1 PLCs and physical equipment are frequently never directly touched — but production stops anyway

Diagram: the typical ransomware attack path runs top to bottom through Purdue model zones. The dashed arrow into the Field & Process zone is intentionally different — that boundary is often never crossed at all, yet the plant still stops.

Case study — Colonial Pipeline, May 2021

Cybercriminal ransomware group (DarkSide)

Attackers gained access to Colonial Pipeline's IT network using a compromised VPN password for an account that was no longer supposed to be active, and deployed ransomware against business systems, including the billing and accounting infrastructure the company used to measure and invoice fuel deliveries. The pipeline's operational technology — the pumps and valves that actually move fuel — was not reported as directly compromised. Colonial nonetheless proactively shut down the entire pipeline for several days, because it could not confidently bill customers for product it could not verify was reaching them, and because the company could not be certain the ransomware had not spread further. The shutdown, not the malware itself, caused regional fuel shortages and price spikes. This is the pattern worth emphasizing: the operational impact came from a business decision made in response to uncertainty, not from a direct attack on control equipment.

Worked example

Compare that to Norsk Hydro, a Norwegian aluminum producer hit by LockerGoga ransomware in March 2019. There, the ransomware spread further into plant-adjacent systems, forcing several smelting facilities to switch from automated to manual operation — workers manually adjusting settings that computers normally controlled — while IT teams rebuilt systems from backups. Production continued at reduced capacity rather than stopping entirely, illustrating that the same threat category, ransomware, can produce a spectrum of outcomes from full shutdown to degraded manual operation, depending on how thoroughly OT-adjacent systems were segmented from the business network before the incident.

Insider Risk and Contractor Access

≈ 50 min

Insider risk is the possibility that someone who already holds legitimate access — an employee, a former employee whose access was never revoked, or a contractor — uses that access to cause harm, whether deliberately or by mistake. It deserves its own category separate from the outsider threats above because the defensive playbook is different: firewalls and intrusion detection assume the attacker starts outside the perimeter, but an insider's access is often the perimeter. The closely related category of contractor and third-party risk covers a specific and very common variation: a vendor, integrator, or maintenance provider is given standing remote access to support equipment, and that access — or the contractor's own systems — becomes the path an attacker uses, whether or not the contractor did anything wrong themselves.

Anchoring analogy

Think of insider and contractor risk as the difference between a burglar picking your front-door lock and a burglar walking in through a door held open by someone who was handed a key years ago and never asked to give it back. The house's defenses — the lock itself — worked exactly as designed in both cases. The failure that let the second burglar in was never rescinding trust that no longer needed to exist.

Case study — Maroochy Shire wastewater system, Australia, 2000

Malicious insider (former contractor)

Vitek Boden had worked for the company that installed the SCADA radio-control system for a wastewater network in Queensland, Australia. After a falling-out related to a job application he did not get, he used a laptop and radio transmitter — equipment and knowledge he retained from his prior contractor role — to issue unauthorized commands to the sewage system's pumping stations over a period of weeks, causing an estimated one million liters of raw sewage to spill into local waterways and parks. No network was "hacked" in the sense of exploiting a software vulnerability; Boden used legitimate radio protocol knowledge and equipment access that should have been revoked when his contractor relationship ended. It remains one of the most cited examples of insider risk in ICS security precisely because the technical barrier to the attack was so low — the failure was entirely in access management, not in any missing security patch.

Worked example — contractor access as an attack path

Third-party risk does not always require a malicious contractor. In the well-documented 2013 breach of Target Corporation's payment systems, attackers first compromised the network credentials of a small HVAC and refrigeration contractor that had remote access to Target's systems for billing and project-management purposes. That contractor never intended harm — its credentials were simply stolen through a separate phishing incident and then used as a stepping stone into Target's broader network. The lesson for OT programs is the same one Colonial Pipeline and Maroochy Shire teach from different angles: any standing remote-access relationship, once granted, is only as secure as the weakest link in the chain of everyone who holds a credential to use it, and it should be reviewed, time-boxed, and revoked the moment it is no longer needed.

Teaching note

Ask faculty to consider their own campus: does the elevator maintenance company, the HVAC contractor, or the building-automation integrator hold standing remote-access credentials to campus systems? Most people can name at least one such relationship without having to research it, which is itself the point.

Supply Chain Compromise

≈ 45 min

A supply chain compromise happens when an attacker doesn't attack the final target directly, but instead compromises something the target already trusts and voluntarily installs — a vendor's software update, a hardware component, or an engineering file passed between organizations — and rides that trust straight through defenses that would have stopped a direct attack. This is what made Stuxnet, discussed in the lesson overview, so effective: rather than attacking Natanz's network from the internet, it spread through infected USB drives and Siemens engineering project files that technicians trusted and used routinely, eventually reaching air-gapped systems that had no direct network connection to anything.

Supply chain trust chain and where it can be broken A trusted vendor builds and signs a software update. That update passes through a distribution or update server to the customer's network, where it is installed because the customer trusts the vendor. If an attacker compromises the vendor's build process or update server instead of the customer directly, every customer who installs the update also installs the attacker's code, inheriting the same trust the customer placed in the vendor. Trusted Vendor Builds & signs update Compromise Point Attacker inserts code here Update/Distribution Signed package delivered Customer Network Installs because it trusts the vendor

Diagram: a supply-chain compromise inserts malicious code at the vendor or distribution stage, upstream of the customer. Every customer who installs the trusted update inherits the compromise without ever being directly attacked themselves.

Case study — SolarWinds Orion, discovered December 2020

Nation-state–attributed supply chain compromise

Attackers compromised the build environment for SolarWinds' Orion network-management software and inserted malicious code into legitimate, digitally signed software updates. Roughly 18,000 organizations downloaded the compromised update, including U.S. federal agencies and numerous private-sector companies, some with ties to critical infrastructure and industrial operations. Because the update was signed by SolarWinds and delivered through SolarWinds' own official update mechanism, it passed directly through defenses — antivirus, application allowlisting, change-control review — that were designed to catch unauthorized software, precisely because from the customer's point of view, nothing unauthorized had happened. This case is frequently taught alongside Stuxnet's USB-and-engineering-file vector because both demonstrate the same underlying principle: supply chain attacks succeed by exploiting trust relationships that conventional perimeter defenses are not designed to question.

Teaching note

A good discussion question: if your program's PLC training lab downloads firmware or project files from a manufacturer's website, what verifies that the file actually came from that manufacturer unmodified? Most students have never been asked to verify a checksum or signature on an industrial software download — this is often the first time the idea comes up.

Threat Actors Side by Side

≈ 15 min

The table below summarizes the six threat-actor categories covered in this lesson, so you can compare motivation, typical capability, and how each one usually reaches an OT environment in one place.

Comparing OT threat-actor categories by motivation, capability, and typical path to impact
Actor typePrimary motivationTypical capability & resourcesHow it usually reaches OTDocumented example
Nation-stateStrategic/geopolitical advantage, disruption, or espionageWell-funded, highly patient, custom tools, deep protocol knowledgeLong-term espionage; can escalate to direct control-command manipulationUkraine power grid attacks, 2015–2016
Cybercriminal / ransomware groupFinancial extortionCommodity ransomware, access brokers, moderate technical sophistication, high volumeUsually starts in IT via phishing or exposed remote access; OT impact is often a precautionary shutdown rather than the direct targetColonial Pipeline, 2021
HacktivistIdeological or political statementVariable skill; often opportunistic, using public search tools to find exposed devicesDirect manipulation of internet-exposed, poorly secured HMIsExposed water-utility HMI manipulation incidents, 2023–2024
Malicious insiderRevenge, financial gain, grievanceLegitimate credentials and system/process knowledge; no perimeter to breachDirect, authorized-looking access to control systemsMaroochy Shire wastewater sabotage, 2000
Negligent insiderNone — unintentionalNormal user access, misused by mistake rather than maliceOpens the door via a phishing click, weak password, or policy shortcutThe most common initial foothold across documented ransomware cases generally
Third-party / contractorVaries — the contractor itself may be an unwitting victimLegitimate, standing remote-access credentials trusted by the target organizationVendor VPN or remote-support access becomes the attacker's entry pointTarget Corporation breach via HVAC vendor credentials, 2013
Teaching note

Notice that only two of the six rows describe an actor who set out specifically to damage industrial equipment (nation-state and malicious insider). The other four reached OT as a side effect of a broader compromise — which is exactly why "we're not an interesting target" is not a defensible security posture for any organization running industrial systems.

Threats and Countermeasures at a Glance

≈ 20 min

Every incident in this lesson maps to a control that could have reduced its likelihood or its blast radius. None of these are exotic — most trace directly back to IEC 62443 zone-and-conduit segmentation, NIST SP 800-82 guidance, and the widely referenced SANS ICS "5 Critical Controls" (linked in Further Reading, and available as a downloadable PDF below). Tap or click each card to see the matching countermeasure.

⚠ Reference material only — no configuration should be applied to live or production systems in this exercise

📄 Download: The Five Critical Controls for World-Class OT Cybersecurity

Part B · Applied Lab

Activity: Match the Case Study to Its Threat Category

Individual, then pair-share ≈ 20 min

Individual (10 min): For each documented case study, select the threat-actor category it best illustrates. Pair-share (10 min): Compare answers with a neighbor — some cases have secondary elements of more than one category, but each has one best fit as discussed in this lesson. This is case-study analysis only; no activity in this exercise involves reproducing, simulating, or executing any part of the attacks described.

Case studyBest-fit threat category
Ukraine power grid attacks (2015–2016)
Colonial Pipeline (2021)
Maroochy Shire wastewater sabotage (2000)
SolarWinds Orion compromise (2020)

Attack Path Simulator: From Inbox to Outage

≈ 25 min

An attack path is the sequence of systems and trust relationships an intruder moves through to get from an initial foothold to a meaningful impact. The simulation below walks through six stages of a composite ransomware scenario modeled on the Colonial Pipeline pattern described earlier in this lesson — where the controllers themselves are never directly touched, but production stops anyway. Step through each stage to see which network zone is affected and how the plant's operating status changes as a result.

⚠ Simulation only — no live equipment. This is a scripted narrative walkthrough with no real network activity, exploit code, or attack tooling.
Network zone diagram showing which zone is currently affected in the simulation Enterprise IT — Levels 4–5 DMZ — Level 3.5 Supervisory & Control — Levels 2–3 Field & Process — Levels 0–1 (PLCs, physical equipment)

Stage 1 of 6 — the highlighted zone below shows where the incident currently stands.

Stage 1 of 6 — Initial Compromise

A phishing email delivers a ransomware dropper to an employee's laptop on the business network. Nothing in the plant has changed yet — production is running normally, and the historian and HMI are both healthy.

ProductionRunning
HistorianReachable
HMI / SCADANormal
Field ControllersUnaffected
Stage 1 of 6
Debrief prompt

At which stage would earlier detection have made the biggest difference to the outcome? Most incident responders would say Stage 2 or 3 — before the compromise crosses the DMZ — which is exactly why the "no visibility into lateral movement" countermeasure card above exists.

Review & Knowledge Check

≈ 15 min
Q1.Why did the discovery of Stuxnet change how security leaders assessed risk to industrial systems?
Q2.In most documented ransomware incidents that affect industrial operations, what is the typical path to impact?
Q3.What is the key distinction between insider risk and third-party/contractor risk as categories?
Q4.What made the Maroochy Shire wastewater attack possible?
Q5.What defines a supply-chain compromise, as illustrated by the SolarWinds Orion incident?
0 / 5
Suggested assessment artifact

Have each faculty member choose one case study from this lesson other than Stuxnet or Colonial Pipeline, and produce a half-page "threat brief" identifying: the threat-actor category it best represents, the specific trust relationship or access control failure that made it possible, and one countermeasure from this lesson's threat/countermeasure flip cards that would most directly have reduced its impact. This mirrors the comparison table's structure and confirms the threat-category-to-countermeasure connection transferred before Lesson 7's vulnerabilities and countermeasures discussion.

Further Reading