Incident dossier · Rank #10

Dyn Managed DNS Outage — Mirai IoT Botnet DDoS (October 21, 2016)

Dyn 2016-10-21 11h 0m core impact NetworkSoftware

On Friday 21 October 2016, Dyn's managed (authoritative) DNS platform was hit by a large-scale distributed denial-of-service attack in which a Mirai-malware IoT botnet directed a flood of DNS lookup requests at the service. The attack arrived in three windows across the day (UTC 11:10-13:20, 15:50-17:00, 20:00-22:10). Because so many major properties delegated their NS records to Dyn, the attack cascaded into user-visible outages for several dozen named services — including Twitter, Reddit, Spotify, Netflix, GitHub and PayPal — across the United States and Europe for much of the day. Dyn reported receiving malicious requests from tens of millions of IP addresses; the compromised endpoints were consumer devices such as printers, IP cameras, residential gateways and baby monitors, not spoofed traffic.

Failure cascade

Trigger → primary fault → downstream blast radius, derived from the sourced root cause and affected-services record.

Facility & location

Operator: Dyn
Data center: Dyn Managed DNS Platform (authoritative DNS service)
Location: Manchester, USA, New Hampshire
Date: 2016-10-21

Impact & scale

Users affected: Not published in primary sources — no end-user count exists; several dozen named consumer/enterprise services (~66-67 commonly cited; Wikipedia's roster length varies by revision) were disrupted across the US and Europe, implying a very large but unquantified user population.
Financial: No fetchable source gives a confirmed dollar figure. Attributed-but-unverified leads: BitSight reportedly found Dyn lost ~8% of its domains (~14,500) in the following days; some analyst pieces cite a ~$110M aggregate business-impact estimate. Neither confirmed.
Scope: Tier-1 / Sev-1 — internet-scale, cross-sector, cross-provider outage originating from a single managed-DNS provider

Services / systems down

Twitter
Reddit
Spotify
Netflix
GitHub
PayPal
Amazon.com
Airbnb
HBO
Slack
SoundCloud
PlayStation Network
Xbox Live
Visa
CNN
The New York Times
The Guardian
BBC
Shopify
Etsy
Pinterest
Tumblr
Quora
Wired
Swedish Government
Swedish Civil Contingencies Agency

Impact data & metrics

Attack source IP addresses (retry-inflated)	Tens of millions of IP addresses
True malicious endpoints (bots)	Up to ~100,000 (Dyn) — attributed, NOT quote-verified in this pass
Mirai-infected device census	~493,000 infected devices (Level 3) — attributed, NOT quote-verified
Named disrupted services	Several dozen named services (~66-67 commonly cited; roster length varies by Wikipedia revision, fetch this pass indicated 80+)
Attack waves	3 UTC windows (11:10-13:20, 15:50-17:00, 20:00-22:10); some secondary sources describe 2 major + residual (unverified)
Per-wave durations	Wave 1 ~2h10m; Wave 2 ~1h10m; Wave 3 ~2h10m (derived from UTC windows)
Total outage duration	No single authoritative figure; event window spans ~11h (11:10-22:10 UTC)
Compromised device classes	Consumer IoT: printers, IP cameras, residential gateways, baby monitors
End-user count	Not published — absent from primary sources
Confirmed economic cost	None fetch-confirmed; attributed leads: ~14,500 domains lost (~8%, BitSight), ~$110M aggregate estimate

Magnitude profile

Magnitude 8.6 = blast 10×0.35 + users 9×0.25 + financial 7×0.20 + duration 7×0.20 (sub-scores 0–10 · weighted composite)

Blast radius is the defining dimension (10): one DNS provider's outage silenced several dozen named services (~66-67 commonly cited) across commerce, media, gaming, dev-infrastructure, payments and two Swedish government bodies, on both sides of the Atlantic. Users score is high (9) by inference from the roster (Twitter/Netflix/Spotify/PayPal scale) even though no end-user count is published. Duration (7) reflects an event spanning ~11 hours of intermittent disruption across three UTC windows rather than a single continuous outage. Financial (7) is an inferred estimate — no confirmed dollar figure exists in fetchable sources. Magnitude of the attack traffic itself was extreme: Dyn cited malicious requests from tens of millions of IP addresses (retry-inflated source count).

Sequence of events (SOE)

Sept–Oct 2016 (pre-event)TRIGGER Mirai source code publicly released by 'Anna_Senpai'; per Krebs the action 'quickly spawned dozens of copycat Mirai botnets' — one of which was assembled and staged for the Dyn attack. The Dyn operation was never publicly attributed to the original authors (aggregate reporting; Krebs documents the copycat proliferation, not Dyn attribution).
~07:10 ET (11:10 UTC), 21 Oct 2016TRIGGER The assault began against Dyn's US-East-coast authoritative DNS infrastructure — 'Dyn received a global distributed denial of service (DDoS) attack on its DNS infrastructure on the east coast starting at around 7:10 a.m. ET' — a flood to port 53 ('DNS water-torture'-style query storm).
~07:10–07:30 ETDETECTION DDoS-monitoring analogue of fire-detection: Dyn's NOC/DDoS telemetry detected anomalous port-53 traffic against East-coast DNS at attack onset (no smoke/heat detector — anomaly sensing).
Morning, 21 Oct 2016DETECTION External attribution ('sensing the mechanism'): 'Flashpoint is now reporting that they have seen indications that a Mirai-based botnet is indeed involved in the attack on Dyn today.'
Morning, 21 Oct 2016DETECTION Scale quantified: Level 3's Dale Drew stated the Mirai population was 'at about 550,000 nodes' and that 'approximately 10 percent were involved in the attack on Dyn.'
Morning, 21 Oct 2016MITIGATION Suppression-system analogue activated: Dyn deployed traffic-shaping of inbound port-53 traffic, anycast routing-policy rebalancing, internal filtering and scrubbing services; analysis credited to Flashpoint and Akamai (disclosed-offline Dyn source).
Morning, 21 Oct 2016IMPACT Collateral (evacuation analogue — no personnel at risk): downstream customers using Dyn as authoritative DNS lost resolution — Krebs names Twitter, Spotify, Reddit and SoundCloud; wider aggregate reporting adds GitHub, Netflix, PayPal, Airbnb, Amazon and HBO.
~09:36 ET, 21 Oct 2016RECOVERY First wave contained: 'the first wave ended at 9:36 a.m.' after initial mitigation and anycast rebalancing.
~11:52 ET, 21 Oct 2016CASCADE Second wave ramped up: '...before ramping up again at 11:52 a.m.' — 'This attack was distributed in a more global fashion,' according to Dyn.
Midday, 21 Oct 2016CASCADE Regional defenses undercut: the global bot distribution defeated region-biased anycast re-steering, because shifting load off the US-East footprint did not help when sources spanned every region; the outage spread more broadly.
Midday–afternoon, 21 Oct 2016MITIGATION Isolation/de-energisation analogue (no electrical de-energisation): routing/traffic isolation — anycast re-steering, scrubbing-center diversion and filtering of port-53 flood traffic — applied against the second wave (disclosed-offline Dyn source).
Afternoon, 21 Oct 2016RECOVERY Second wave mitigated and service progressively restored across regions after sustained scrubbing and filtering (containment analogue; disclosed-offline Dyn source).
Later, 21 Oct 2016RECOVERY Dyn reported a third attack wave was mitigated without customer impact (disclosed-offline Dyn source).
Evening, 21 Oct 2016 (exact end time not in surviving primary record)RESTORED Normal DNS resolution restored for Dyn customers after the third wave was neutralised. Precise all-clear timestamp is uncertain — the primary Hilton statement is now offline (dyn.com 301 → Oracle post-acquisition; Oracle URL returns 403).
Dec 2017 → Sept 2018RESTORED Law-enforcement analogue (no fire/EMS): FBI/DOJ prosecuted Mirai authors Paras Jha, Josiah White and Dalton Norman — guilty pleas Dec 2017, sentenced Sept 2018 to 'five years probation, 2,500 hours of community service, and ordered to pay $127,000 in restitution.' These prosecutions did not encompass the Dyn attack, which is widely attributed to a separate copycat operator.

Root cause

SPECIFIC "IGNITION SOURCE" (attack weapon): The outage was caused by a sustained, multi-wave volumetric-plus-application-layer DDoS from a Mirai-based Internet-of-Things botnet directed at Dyn's Managed DNS authoritative nameservers. There was NO physical ignition, fuel, or fire — the fire-forensic analogues below are explicitly mapped to the DDoS mechanism, as the crawl note requires. SPECIFIC "EQUIPMENT" (compromised hardware) AND ITS "CHEMISTRY" (failure mechanism): The weapon was assembled from "poorly secured Internet-based security cameras, digital video recorders (DVRs) and Internet routers" (Krebs). The single most-cited hardware root cause is DVRs/cameras built on XiongMai Technologies components that shipped with the hardcoded, effectively unchangeable administrative credential pair root:xc3511, devices that "share the same username-password combination root:xc3511" making telnet enrollment trivial (Threatpost). Mirai's loader continuously scanned the IPv4 Internet over Telnet and brute-forced logins — "the initial version of Mirai relied exclusively on a fixed set of 64 well-known default login/password combinations commonly used by IoT devices" (Cloudflare) — enrolling any device that accepted a default pair. The weaponised output against Dyn was a DNS flood aimed at UDP/TCP port 53 (a "DNS water-torture"-style query storm), drawing on an attack module that "implements most of the ... DDoS techniques such as HTTP flooding, UDP flooding, and all TCP flooding options" (Cloudflare). EXACT FAILURE MECHANISM AT THE TARGET: Legitimate recursive-resolver retries are indistinguishable from malicious DNS queries, so Dyn's authoritative resolvers were forced to process both. This inflated the apparent source-IP count to "tens of millions" while Dyn assessed the true malicious-endpoint population at approximately 100,000 (Dyn/Hilton statement, now offline and surviving only via secondary reproduction). Dyn cited a claimed peak of 1.2 Tbps that it said it could not verify (same disclosed-offline source). LATENT ROOT — DESIGN, REDUNDANCY, AND "MAINTENANCE" LAPSE: The latent root is a two-sided systemic hygiene failure, not a plant defect. (1) On the supply side, IoT manufacturers shipped devices with default/hardcoded credentials and an exposed Telnet service, with no forced credential change and little or no firmware patching — a device-lifecycle "maintenance" and secure-design lapse that let a static list of 64 credential pairs conscript hundreds of thousands of devices (Threatpost, Cloudflare). (2) On the target side, the amplifying architectural exposure was that many major web properties used Dyn as their SOLE authoritative DNS provider, so degradation of one managed-DNS operator cascaded into a broad Internet outage — a redundancy / single-supplier lapse. The Dyn event is widely attributed to a "copycat" Mirai botnet assembled after the original authors publicly leaked the source code, which "quickly spawned dozens of copycat Mirai botnets" (Krebs 2018); the Dyn attacker was never publicly identified and the three original authors were not charged in connection with the Dyn attack (widely reported — note that the cited Krebs 2018 piece documents the copycat proliferation but does not itself adjudicate Dyn attribution).

Contributing factors

IoT-vendor secure-design/'maintenance' lapse (root systemic cause): devices shipped with hardcoded/default administrative credentials and an exposed Telnet service, no forced credential change, and little-to-no firmware patching — Mirai needed only 64 static default login pairs to conscript the fleet; XiongMai Technologies DVRs/cameras with the fixed root:xc3511 credential are the canonical example (Threatpost, Cloudflare).
End-user device-hygiene gap: operators of home cameras, DVRs and routers never changed default passwords, leaving devices open to Telnet brute-force enrollment from Mirai's fixed 64-pair dictionary (Cloudflare, Threatpost).
Source-code disclosure enabling copycats: after the authors released Mirai's code, that action 'quickly spawned dozens of copycat Mirai botnets' (Krebs 2018); the Dyn attack is widely attributed to one such copycat, launched by an operator never publicly identified (attribution is aggregate reporting, not stated in the cited Krebs piece).
Customer-side single-supplier / redundancy lapse: many major web properties used Dyn as their SOLE authoritative DNS provider, so one operator's degradation cascaded into a broad multi-platform Internet outage (Dyn/Hilton context, disclosed offline; effect corroborated by contemporaneous reporting).
Attack/legitimate-traffic indistinguishability: legitimate recursive-resolver retries were indistinguishable from malicious DNS queries, inflating apparent sources to 'tens of millions' of IPs and making aggressive filtering risky to real customers (Dyn/Hilton, disclosed offline).
Global bot distribution defeating regional defenses: the second wave was 'distributed in a more global fashion' (Dyn via Threatpost), undercutting anycast rebalancing that assumed a region-biased attack footprint.

Correction of errors (COE)

Ban shipping default/hardcoded credentials and require forced credential change plus Telnet-off-by-default across IoT product lines IoT device manufacturers / secure-by-default regulators · Partially addressed (e.g., later secure-by-design laws), not universal
Adopt multi-provider (dual authoritative) DNS with anycast/secondary diversity for business-critical properties Enterprise web properties / SRE & platform teams · Widely adopted post-incident by large platforms
Mandate signed firmware auto-update and defined support/end-of-life windows for connected devices Device manufacturers / procurement standards bodies · Ongoing / inconsistent enforcement
Deploy DNS-layer anomaly detection able to separate water-torture floods from legitimate resolver retries before scrubbing Managed-DNS operators (Dyn/Oracle) & DDoS-scrubbing vendors · Improved industry practice post-2016
Preserve authoritative incident postmortems in an independent archive so facts survive corporate acquisition/site retirement Incident owner / knowledge-management · Open — original Dyn postmortem is now offline

Lessons learnt

DNS is a concentrated single point of failure: delegating a large fraction of the web's authoritative DNS to one provider means one provider's bad day becomes the whole internet's bad day.
Fate independence matters more than redundancy within one vendor: multiple nameservers all belonging to the same provider share the same failure domain; true resilience needs a second, independent DNS provider (RFC 2182).
Insecure consumer IoT is an internet-scale weapon: devices with default credentials can be marshalled into botnets whose volume overwhelms core infrastructure operators, not just the device owners.
Attack-source metrics can mislead: 'tens of millions of IP addresses' reflected retry amplification, while the true bot population was far smaller (attributed ~100k) — headline numbers need provenance discipline.
Cross-sector blast radius is invisible until it happens: a single DNS outage simultaneously hit commerce, media, gaming, developer infrastructure, payments and government services, revealing shared hidden dependencies.
Multi-wave DDoS defeats one-shot mitigation: attackers pacing the assault across separate windows forced sustained, adaptive defense rather than a single fix.
Timeline sourcing discipline: publicly only Dyn's three UTC windows exist — ET conversions and per-wave resolution times are not in the primary sources and must be flagged as derived, not asserted as sourced fact.

Improvements & remediation

SafetyEliminate default/hardcoded credentials and disable Telnet by default on all IoT devices; enforce unique per-device passwords and mandatory credential change at first boot, so a static 64-pair dictionary can no longer conscript a fleet (root cause per Cloudflare/Threatpost).
MaintenanceMandate an IoT device-lifecycle patch/firmware regime (signed auto-updates, defined end-of-life policy) — the incident hinged on unpatched, never-serviced cameras/DVRs/routers such as XiongMai units with fixed root:xc3511 (Threatpost).
Design (redundancy): Remove the single-supplier DNS single point of failure — critical web properties should use multiple, independent authoritative DNS providers with secondary/anycast diversity so one operator's degradation cannot take a property fully offline (Dyn dependency lesson).
Detection/response: Build DNS-aware anomaly detection that distinguishes water-torture pseudo-random-subdomain floods from legitimate resolver retries, so scrubbing can be applied without dropping paying customers' real lookups (Dyn indistinguishability failure).
Architecture: Provision anycast/scrubbing capacity that does not assume a region-biased attack — the second wave defeated US-East re-steering because it was 'distributed in a more global fashion' (Threatpost).
GovernancePush for enforceable IoT secure-by-default regulation/certification (no shipping default passwords, mandatory update support windows) to fix the supply-side hygiene lapse at market scale.

Comprehensive analysis

Fire-forensic mapping (no physical fire)

This was a cyber incident with zero physical ignition, fuel, or combustion. Applying the fire-forensic template as required: the 'ignition source' is the Mirai DDoS weapon; the 'equipment/chemistry' is default-credentialled XiongMai DVRs/cameras (root:xc3511) enrolled via Telnet brute-force; 'detection' is DDoS telemetry and Flashpoint attribution rather than smoke/heat sensing; the 'suppression system' is Dyn's traffic-shaping, anycast rebalancing, filtering and third-party scrubbing; 'evacuation' has no human analogue (only downstream customers losing resolution); 'de-energisation' maps to routing/traffic isolation; and 'emergency response/investigation' maps to the FBI/DOJ prosecution of the Mirai authors. Every analogue is explicitly tied to the DDoS mechanism, per the crawl note.

Why the outage cascaded so widely

The blast radius was governed by DNS dependency, not by attack cleverness. Properties using Dyn as their sole authoritative DNS provider became unreachable the instant resolution failed, while multi-provider properties degraded far less. Krebs verbatim confirms Twitter, Spotify, Reddit and SoundCloud; the broader marquee list (GitHub, Netflix, PayPal, Airbnb, Amazon, HBO) is aggregate contemporaneous reporting. The single-supplier architecture — a redundancy lapse on the customer side — is the amplifier that turned an attack on one vendor into a headline 'internet outage.'

The defender's dilemma: indistinguishable traffic

Authoritative resolvers cannot tell a malicious pseudo-random-subdomain query from a legitimate one, and stub/recursive resolvers retry on timeout — so the flood induced a self-amplifying storm of genuine retry traffic. Dyn assessed ~100,000 truly malicious endpoints while apparent sources ballooned to 'tens of millions' of IPs. This is why blunt source-based filtering was hazardous: dropping 'suspicious' port-53 traffic risked dropping paying customers' real lookups. It also explains why the second, globally distributed wave defeated region-biased anycast re-steering.

Attribution, copycats, and the source-code leak

The original Mirai authors (Jha, White, Norman) pleaded guilty in Dec 2017 and were sentenced in Sept 2018 to five years probation, 2,500 hours community service and $127,000 restitution — but those prosecutions did not encompass the Dyn attack. After the authors leaked Mirai's source, the code 'quickly spawned dozens of copycat Mirai botnets' (Krebs), and the Dyn operation is widely attributed to one such untraceable copycat whose operator was never publicly identified. The leak is the durable systemic hazard: it permanently lowered the barrier to entry.

Source-integrity and disclosed gaps

The authoritative primary — Dyn's own 'Dyn Analysis Summary of Friday October 21 Attack' by Scott Hilton — is now offline (dyn.com 301-redirects to Oracle post-acquisition; the Oracle URL returns HTTP 403; web.archive.org is blocked in this environment). The 100,000-endpoint, 'tens of millions', 1.2-Tbps-'could not verify', Flashpoint/Akamai-credit, and third-wave facts therefore survive only via secondary reproduction and are flagged as a disclosed gap rather than re-verified verbatim. All other headline facts were re-fetched and confirmed against Krebs (2016 & 2018), Threatpost, and Cloudflare in this review.

Technical deep-dive

Mirai operated as a self-propagating worm plus command-and-control (C2) DDoS platform. Its loader performed stateless, high-rate TCP SYN scanning of pseudo-random IPv4 space on Telnet ports (23/2323), and on an open banner attempted authentication from a hardcoded dictionary of 64 default credential pairs (Cloudflare). Successful logins were reported to a loader/report server, which then pushed the architecture-appropriate Mirai binary; the bot wiped competing malware, hid its process, and connected to C2 to await attack commands. XiongMai-based DVRs/cameras with root:xc3511 were a canonical conscription target (Threatpost). Independent measurement placed the Mirai population near 550,000 nodes at the time of the Dyn attack (Level 3 via Threatpost), with ~24% node overlap with the earlier Bashlite/gafgyt IoT botnet (Threatpost); the USENIX Antonakakis et al. study later documented an even larger peak population, and Krebs has reported the original authors' own build reached hundreds of thousands of devices (secondary/soft-sourced, retained with that caveat). Against Dyn, the copycat operator used the attack module's DNS-flood capability. Two mechanisms compounded: (a) a raw volumetric flood of UDP/TCP packets to port 53, and (b) a "DNS water-torture" query flood in which bots requested pseudo-random subdomains of victim zones, forcing authoritative resolvers to do real work per query and defeating simple caching. Because a legitimate stub/recursive resolver that times out will retry — often several times — the flood induced a self-amplifying storm of genuine retry traffic layered on top of the attack, inflating apparent sources to "tens of millions" of IPs even though Dyn assessed ~100,000 truly malicious endpoints (Dyn/Hilton statement, disclosed offline). This is why naive source-based filtering was dangerous: dropping "suspicious" port-53 traffic risked dropping paying customers' real lookups. Dyn's mitigation ("suppression system" analogue) combined traffic-shaping of inbound port-53 traffic, manipulation of anycast routing policy to rebalance load across scrubbing-capable POPs, internal filtering, and third-party scrubbing, with attack analysis credited to Flashpoint and Akamai (Dyn/Hilton statement, disclosed offline; Flashpoint's Mirai attribution independently confirmed by Krebs). The first wave was contained and ended at 9:36 a.m. ET, but a second wave that ramped at 11:52 a.m. ET was "distributed in a more global fashion" (Dyn via Threatpost), which specifically undercut region-biased anycast re-steering: shifting load away from the US-East footprint did not help when bots were sourcing traffic from every region simultaneously. Dyn reported a third wave was mitigated without customer impact (disclosed-offline source). The blast radius was determined entirely by DNS dependency: any property using Dyn as sole authoritative DNS lost resolution, while multi-provider properties degraded far less. Krebs verbatim names Twitter, Spotify, Reddit and SoundCloud among affected customers; the wider list commonly cited (GitHub, Netflix, PayPal, Airbnb, Amazon, HBO) reflects aggregate contemporaneous reporting rather than a single primary source.

References & provenance

regulatory KrebsOnSecurity — Mirai Botnet Authors Avoid Jail Time“five years probation, 2,500 hours of community service, and ordered to pay $127,000 in restitution”https://krebsonsecurity.com/2018/09/mirai-botnet-authors-avoid-jail-time/
vendor-status Dyn Analysis Summary of Friday October 21 Attack (Scott Hilton) — now offline“Primary vendor postmortem, now offline (dyn.com 301 to Oracle post-acquisition; Oracle URL returns 403). Cited figures (~100,000 endpoints; 'tens of millions'; 1.2 Tbps 'could not verify') survive via secondary reproduction only.”https://dyn.com/blog/dyn-analysis-summary-of-friday-october-21-attack/
official-postmortem Dyn Analysis Summary Of Friday October 21 Attack (Scott Hilton)“Dyn stated that they were receiving malicious requests from tens of millions of IP addresses. (Source no longer live: dyn.com now redirects to Oracle; web.archive.org blocked this pass — formal corrective actions and the 'up to 100,000' bot figure remain attributed-not-verified.)”https://web.archive.org/web/2016/https://dyn.com/blog/dyn-analysis-summary-of-friday-october-21-attack/
vendor-status Inside Mirai: the infamous IoT botnet, a retrospective analysis — Cloudflare Blog (credentials)“To compromise devices, the initial version of Mirai relied exclusively on a fixed set of 64 well-known default login/password combinations commonly used by IoT devices.”https://blog.cloudflare.com/inside-mirai-the-infamous-iot-botnet-a-retrospective-analysis/
press KrebsOnSecurity — DDoS on Dyn Impacts Twitter, Spotify, Reddit“Dyn received a global distributed denial of service (DDoS) attack on its DNS infrastructure on the east coast starting at around 7:10 a.m. ET”https://krebsonsecurity.com/2016/10/ddos-on-dyn-impacts-twitter-spotify-reddit/
press Threatpost — Mirai-Fueled IoT Botnet Behind Friday DDoS Attacks“the attacks began shortly after 7 a.m. Eastern time and the first wave ended at 9:36 a.m., before ramping up again at 11:52 a.m.”https://threatpost.com/mirai-fueled-iot-botnet-behind-friday-ddos-attacks/121475/
press Hacked Cameras, DVRs Powered Today's Massive Internet Outage — KrebsOnSecurity“At least one Mirai [control server] issued an attack command to hit Dyn... What we can say is that we've seen a Mirai botnet participating in the attack.”https://krebsonsecurity.com/2016/10/hacked-cameras-dvrs-powered-todays-massive-internet-outage/
press Mirai IoT Botnet Co-Authors Plead Guilty — KrebsOnSecurity“the Oct. 21, 2016 assault against Internet infrastructure firm Dyn that disrupted Twitter, Netflix, Reddit and a host of other sites for much of that day.”https://krebsonsecurity.com/2017/12/mirai-iot-botnet-co-authors-plead-guilty/
other DDoS attacks on Dyn (2016)“The distributed denial-of-service (DDoS) attack was accomplished through numerous DNS lookup requests from tens of millions of IP addresses ... a botnet consisting of many Internet-connected devices—such as printers, IP cameras, residential gateways and baby monitors—that had been infected with the Mirai malware. Attack windows re-fetched 2026-07-31: UTC 11:10-13:20, 15:50-17:00, 20:00-22:10; the article carries no Eastern-Time conversions and no per-wave resolution times.”https://en.wikipedia.org/wiki/DDoS_attacks_on_Dyn

Sourced from public post-incident reports. Quotes are short attributed excerpts for provenance only; the analysis above is original and substantially shorter than its sources. Last verified 2026-07-31.