Example 1: IoT Default Credentials — How Mirai Built the Biggest Botnet in History
In 2016, the Mirai botnet conducted the largest DDoS attacks the internet had seen to that point, taking down DNS provider Dyn and making major websites — Twitter, Reddit, Netflix, GitHub — unreachable for hours across the eastern United States. The botnet consisted primarily of IoT devices: IP cameras, DVRs, and home routers.
The Attack Method: Shockingly Simple
Mirai did not exploit a complex zero-day vulnerability. It scanned the internet for IoT devices and attempted login using a hardcoded list of approximately 60 default username/password combinations — admin/admin, root/root, admin/1234, and similar. Hundreds of thousands of IoT devices across the world had never had their default credentials changed. Mirai logged in, enrolled the device in the botnet, and moved on to the next target. The entire compromise relied on the single failure to change default credentials.
The Lesson for IoT Hardening
The organizations and individuals whose devices were compromised did not experience a sophisticated attack. They experienced the consequence of deploying devices with default credentials and taking no further action. Changing the default password on every IoT device at deployment would have prevented Mirai from recruiting each of those devices entirely.
The secondary lesson: segmenting IoT devices to their own VLAN limits what a compromised device can do. A botnet-enrolled IP camera on an isolated IoT VLAN cannot scan corporate servers. Network containment limits the blast radius when device-level hardening is insufficient.
The secondary lesson: segmenting IoT devices to their own VLAN limits what a compromised device can do. A botnet-enrolled IP camera on an isolated IoT VLAN cannot scan corporate servers. Network containment limits the blast radius when device-level hardening is insufficient.
IoT devices with unchanged default credentials are trivially compromised at internet scale. Change defaults immediately at deployment, and segment IoT to its own VLAN so that compromised devices cannot reach corporate systems.
Example 2: SCADA Compromise — When a Cyberattack Flips the Lights Off
In December 2015, attackers targeted three regional electricity distribution companies in Ukraine. Approximately 225,000 customers lost power for several hours. The attack demonstrated that SCADA/ICS systems can be compromised in ways that produce real-world physical consequences at scale.
How the Attack Worked
The attackers spent months doing reconnaissance inside the corporate IT networks of the target companies before pivoting to the OT (Operational Technology) networks that controlled the power distribution equipment. The ICS control network was accessible from the corporate network — there was insufficient segmentation between the two. Attackers gained access to the SCADA workstations, opened breakers remotely, and simultaneously conducted a telephone denial-of-service attack against the utility's call centers to prevent customers from reporting the outage. They also overwrote firmware on serial-to-Ethernet converters to prevent remote recovery.
What Should Have Been in Place
The critical failure was insufficient segmentation between corporate IT and the ICS network. Proper SCADA hardening would have included:
— A complete air-gap or highly restricted one-way data path between the corporate network and the ICS network
— No route from corporate workstations to SCADA management systems
— Authentication and access controls on SCADA systems preventing unauthorized remote command execution
— Monitoring for anomalous commands in the ICS environment
The connectivity that allowed the attackers to pivot from phishing a corporate workstation to opening power grid breakers should not have existed.
— A complete air-gap or highly restricted one-way data path between the corporate network and the ICS network
— No route from corporate workstations to SCADA management systems
— Authentication and access controls on SCADA systems preventing unauthorized remote command execution
— Monitoring for anomalous commands in the ICS environment
The connectivity that allowed the attackers to pivot from phishing a corporate workstation to opening power grid breakers should not have existed.
SCADA and ICS systems must be isolated from corporate IT networks. The path from corporate email to power grid control should not exist. Air-gapping or rigorous segmentation is not optional for critical infrastructure — it is the fundamental design requirement.
Example 3: The Cloud Management Workstation — Keys to the Kingdom Compromised
A technology company's lead cloud architect works daily from a laptop that has direct access to the company's AWS environment. One afternoon, the architect receives a convincing phishing email appearing to come from AWS billing, clicks the link, and enters credentials on a spoofed login page. The attacker captures the workstation credentials.
Without Hardened Cloud Management Workstation
The attacker establishes a remote access connection to the architect's workstation. The laptop has stored AWS CLI credentials and an active browser session with AWS Console administrator access. Within 20 minutes, the attacker:
— Creates a new IAM administrator user with their own credentials
— Copies 2TB of data from S3 buckets to an attacker-controlled cloud storage account
— Deploys crypto-mining EC2 instances across multiple regions
— Deletes the primary S3 backup buckets
The company has no Cloud-to-Cloud backup. The deleted data is unrecoverable. The mining instances run for several hours before detection, accumulating a significant AWS bill.
— Creates a new IAM administrator user with their own credentials
— Copies 2TB of data from S3 buckets to an attacker-controlled cloud storage account
— Deploys crypto-mining EC2 instances across multiple regions
— Deletes the primary S3 backup buckets
The company has no Cloud-to-Cloud backup. The deleted data is unrecoverable. The mining instances run for several hours before detection, accumulating a significant AWS bill.
What Hardening Would Have Prevented
— EDR on the workstation would have detected the attacker's remote access tools and command execution before they could pivot to AWS
— MFA on the AWS management account would have required a second factor the attacker did not have, blocking the console session even with stolen credentials
— Least privilege would have limited even an authenticated session — not every administrator needs the ability to delete S3 buckets or create IAM users
— C2C backup would have meant the deleted backup was not the only copy
— CloudTrail alerts on suspicious IAM actions would have detected the new administrator creation immediately
— MFA on the AWS management account would have required a second factor the attacker did not have, blocking the console session even with stolen credentials
— Least privilege would have limited even an authenticated session — not every administrator needs the ability to delete S3 buckets or create IAM users
— C2C backup would have meant the deleted backup was not the only copy
— CloudTrail alerts on suspicious IAM actions would have detected the new administrator creation immediately
The cloud management workstation controls the entire cloud environment. Its compromise is a crown jewel event. EDR, MFA, least privilege, C2C backup, and activity monitoring are all required — not optional — for cloud infrastructure hardening.
Example 4: Network Switch Compromised via Default Credentials
A medium-size law firm installs ten new managed network switches to upgrade its office network. The switches are configured by an IT contractor who sets up VLANs and port configurations but does not change the manufacturer default management credentials. The switches are deployed, the network works correctly, and the contractor moves on.
Six Months Later
An attacker who has compromised a workstation on the law firm's network runs a network scan and discovers the management interfaces of the switches. They attempt the manufacturer default credentials for the switch model — admin / admin — and gain full management access to all ten switches.
From the switch management interface, the attacker:
— Configures a SPAN (port mirror) on the core uplink ports, redirecting all network traffic to a port connected to a collection device
— Intercepts all unencrypted internal traffic including some legacy application credentials
— Gains access to credentials for the firm's billing system and document management platform
From the switch management interface, the attacker:
— Configures a SPAN (port mirror) on the core uplink ports, redirecting all network traffic to a port connected to a collection device
— Intercepts all unencrypted internal traffic including some legacy application credentials
— Gains access to credentials for the firm's billing system and document management platform
The Simple Fix
Changing the default credentials on every switch at deployment — taking approximately 5 minutes per device — would have prevented this entirely. The attacker's access relied entirely on the assumption that the defaults were unchanged. No sophisticated technique was required.
Additional hardening would include: configuring management access only from a dedicated management VLAN (restricting which IPs can reach the management interface), enabling centralized authentication via RADIUS or TACACS+, and enabling login auditing so failed attempts are logged.
Additional hardening would include: configuring management access only from a dedicated management VLAN (restricting which IPs can reach the management interface), enabling centralized authentication via RADIUS or TACACS+, and enabling login auditing so failed attempts are logged.
Network infrastructure devices with default credentials are trivially compromised by any attacker who can reach the management interface. Changing defaults immediately at deployment is the highest-priority hardening action for any network device — it takes minutes and eliminates an entire attack vector.
Example 5: Enterprise Hardening Program — All Nine Target Types
A 2,000-employee manufacturing company with IT and OT (Operational Technology) infrastructure runs an enterprise-wide hardening program. The security team manages all nine target types across the organization.
Mobile Devices (1,200 enrolled)
MDM platform enforces: screen lock after 2 minutes, full-disk encryption required, work profile isolating corporate email and apps from personal data, automatic OS update installation, remote wipe capability. Mobile security patches deployed within 48 hours of release.
Workstations (800 endpoints)
Active Directory Group Policy enforces password complexity, screen lock, and Windows Defender settings. Patch Tuesday patches tested on 50-machine pilot group Monday–Wednesday; deployed to full fleet Thursday–Friday. Annual software inventory audit removes unlicensed and unused applications. EDR deployed on all endpoints.
Network Infrastructure (45 devices)
All switches and routers authenticate against a TACACS+ server; no local accounts remain. Manufacturer security advisories monitored weekly; firmware updates applied within 30 days of release after lab testing. Management access restricted to management VLAN only.
Cloud Infrastructure (AWS)
Cloud management access restricted to two dedicated hardened workstations with EDR. All IAM roles scoped by least privilege — no wildcard admin permissions. All S3 buckets replicated daily to Azure (C2C backup). CloudTrail alerts on privilege escalation and bucket deletion events.
Servers (60 servers)
Windows Server and Linux servers patched monthly. Service accounts have minimum required permissions; all inactive accounts disabled quarterly. Servers accessible only from specific source IPs via firewall rules. EDR and file integrity monitoring on all servers.
SCADA / ICS (manufacturing floor)
Manufacturing control network completely air-gapped from corporate IT network. Physical access to the control room restricted by badge access. No wireless on the ICS network. Firmware updates tested in a lab environment before production deployment; change-controlled process with full rollback plan.
Embedded Systems + RTOS
Industrial controllers on isolated network segment with firewall. Manufacturer security advisories monitored; any available patches applied promptly after testing. No direct network paths from these devices to corporate systems.
IoT (150 devices: cameras, HVAC sensors, badge readers)
All IoT devices on dedicated VLAN with no route to corporate network. Default credentials changed at deployment and documented in a secrets management system. IoT firmware patches applied within 7 days of availability. Network monitoring alerts on anomalous IoT traffic volume.
A complete enterprise hardening program addresses all nine target types with controls appropriate to each platform's specific risks and constraints. No single approach applies to every target — IoT hardening relies heavily on network segmentation because device-level controls are weak; SCADA relies on air-gapping; cloud relies on least privilege and account protection; workstations rely on automated patch management and policy enforcement.