Résumé
In 2016 the Mirai botnet showed what happens when millions of insecure IoT devices get weaponized. Mirai scanned the internet for cameras, DVRs, and routers exposed over Telnet and logged in using a table of about 61 default and hardcoded credential pairs that owners never changed (and sometimes could not change). The conscripted devices launched record-breaking DDoS attacks: roughly 620 Gbps against the security site Krebs on Security, around 1.1 Tbps against the host OVH, and, after Mirai's source code was leaked, an assault on the DNS provider Dyn on 21 October 2016 that knocked Twitter, Netflix, Reddit, GitHub, and Spotify offline for much of the US. That public code release spawned countless variants that still operate today. It is the defining lesson in default-credential and IoT hygiene.
How it happened
Mirai was almost embarrassingly simple, which was the point. It scanned the internet for devices with the Telnet remote-login port open, the cheap cameras, DVRs, and home routers that flood the market, and tried to log in using a built-in list of about 61 default username-and-password pairs (admin/admin, root/xc3511, and the like) that manufacturers had baked in and most owners never changed. Many devices could not change them at all. When a login worked, Mirai loaded itself into the device's memory, and that device quietly became part of the botnet: waiting for orders from a command server while scanning for the next victim. The owners noticed nothing. At its peak Mirai controlled an estimated 600,000 devices.
A botnet that size is a firehose. Pointed at a target, all those devices flood it with traffic at once, a DDoS attack that no single server can absorb and that is hard to block because it comes from hundreds of thousands of ordinary IP addresses.
The damage
Mirai set records and broke the internet in slow motion. In September 2016 it hit the security journalist Brian Krebs with a 620 Gbps flood, almost twice the largest attack his provider had ever seen, so large the provider dropped him. It threw around 1.1 Tbps at the French hosting company OVH. These attacks traced to a few young men, Paras Jha, Josiah White, and Dalton Norman, who ran a racket in the Minecraft DDoS-protection market, attacking servers and rival mitigation firms to sell protection against their own floods; to muddy attribution as researchers closed in, one of them, under the handle "Anna-senpai," published Mirai's full source code on a hacker forum. That leak is why Mirai never really ended. Among the copycat botnets it spawned was the one that, on 21 October 2016, aimed at Dyn, a company that runs DNS (the internet's address book) for much of the web, and took Twitter, Netflix, Reddit, Spotify, GitHub, and PayPal offline across the US East Coast for hours; a separate attacker, then a juvenile, later pleaded guilty to that one. The three original authors pleaded guilty in 2017, and dozens of variants built on their leaked code remain among the most common internet threats years later.
Why Mirai still matters
Mirai is the case that put the "Internet of Things" security problem on the map. The lesson is brutally simple and still ignored: devices shipped with default or shared credentials, exposed to the internet, become weapons. The fixes belong partly to manufacturers (never ship a default password, force a unique one on first boot, do not hard-code credentials) and partly to everyone who runs a device (do not expose management interfaces to the internet, put IoT on its own segmented network, keep firmware patched, and filter outbound traffic so a compromised gadget cannot freely reach attack targets). And because botnets this big are now a permanent fact, any service that matters needs real DDoS resilience, redundant and anycast DNS plus a scrubbing provider, in place before it is needed.
Comment le corriger
- Change default credentials on every device and disable Telnet and other plaintext management protocols.
- Reboot and re-flash compromised devices with current firmware; Mirai lives in memory and returns if the exposure remains.
- Pull device management interfaces off the public internet and behind a firewall or VPN.
- For DDoS targets, engage upstream scrubbing and DNS redundancy to absorb and disperse the flood.
Comment l’éviter
- Never ship or deploy devices with default or shared credentials; force a unique password on first use and forbid hardcoded ones.
- Disable Telnet and UPnP and expose no device management to the internet; put IoT on its own segmented network.
- Keep IoT firmware patched, and retire devices that no longer receive updates.
- Filter egress so compromised devices cannot freely reach attack targets, and rate-limit and monitor outbound traffic.
- Build DDoS resilience: redundant and anycast DNS plus a scrubbing provider, before you need them.
Références
- https://krebsonsecurity.com/2017/12/mirai-iot-botnet-co-authors-plead-guilty/
- https://www.justice.gov/archives/opa/pr/justice-department-announces-charges-and-guilty-pleas-three-computer-crime-cases-involving
- https://www.justice.gov/archives/opa/pr/individual-pleads-guilty-participating-internet-things-cyberattack-2016
- https://en.wikipedia.org/wiki/Mirai_(malware)
Vulnérabilités liées
Tout Infra →- CRITICALCVE-2021-44228
Log4Shell, disclosed on 10 December 2021, was for a time the most dangerous vulnerability on the internet. It lived in Log4j, an Apache logging library so ubiquitous that it sat, usually invisibly, inside millions of Java applications, from enterprise servers to Minecraft to iCloud. The flaw was almost absurdly easy to trigger: if an attacker could get a crafted string like ${jndi:ldap://...} written into a log, a username, a chat message, a header, the server would reach out, fetch attacker-controlled code, and run it, giving full unauthenticated remote code execution. Because logging untrusted input is something nearly every application does, exploitation was trivial and everywhere. Within hours the entire internet was being mass-scanned, and defenders spent a frantic holiday season patching a dependency many did not even know they had. It is the defining example of why you must know, and be able to fix, every component buried in your software.
- HIGHINFRA-USBLITER8-2026
usbliter8, published on 18 June 2026 by a research group called Paradigm Shift, is an unpatchable BootROM exploit for Apple's A12 and A13 chips, the silicon inside the iPhone XS, XR and 11 families plus the Apple Watch Series 4 and 5. It is the long-awaited successor to checkm8, the 2019 exploit that broke every Apple chip from the A5 to the A11 and was assumed to be the end of that road. The bug lives in the SecureROM, the very first code an Apple device runs at power on, which is etched into the silicon at the factory and can never be altered by any software update. usbliter8 abuses a hardware flaw in the Synopsys DWC2 USB controller: a mismatch in how the controller tracks its DMA memory while buffering USB Setup packets lets an attacker walk a write pointer backwards through memory and overwrite arbitrary SRAM, ending in full code execution inside the most trusted code on the chip. From there it can boot unsigned firmware and step outside Apple's chain of trust entirely, stamping the string PWND into the device's USB serial number as proof of control. The catch is that it is not a remote attack: it needs physical possession of the device, DFU recovery mode, a USB connection and a small RP2350 microcontroller board, and nothing it changes survives a reboot. It also does not break the Secure Enclave, so a device protected by a strong passcode keeps its user data encrypted even after the boot chain has been taken over. Apple cannot repair the affected chips; the only real remedy is newer hardware, because the A14 and later configure the controller correctly and are out of reach.
- HIGHCVE-2026-31431
Copy Fail (CVE-2026-31431), disclosed on 29 April 2026 by the security firm Theori, is a Linux kernel flaw that turns any unprivileged local user into root with a 732-byte Python script and no luck required. Despite a name that sounds like a clipboard bug, it has nothing to do with copy and paste: it is a failed copy deep in the kernel's crypto code. A nine-year-old optimization in the AF_ALG crypto socket interface let an attacker steer the kernel into writing four attacker-chosen bytes into the page cache, the in-memory copy of files that the CPU actually executes. Patch the cached pages of a setuid-root binary like /usr/bin/su, run it, and you are root. The exploit is a straight-line logic flaw with no race condition and no hardcoded kernel addresses, so the exact same script runs at roughly 100 percent reliability across Ubuntu, RHEL, SUSE, Amazon Linux and every other distribution built since 2017. Worse, because the page cache is shared by the whole machine, it crosses container boundaries: one poisoned page in a Kubernetes pod can compromise neighbouring tenants and the host. The disk file is never touched, so file-integrity scanners stay silent. It rates CVSS 7.8 (High), was added to CISA's Known Exploited Vulnerabilities catalog on 1 May 2026, and is notable for how it was found: an AI-assisted code scan surfaced a bug that had been silently exploitable for nearly a decade in about one hour.
- CRITICALCVE-2025-1974
IngressNightmare was a chain of five vulnerabilities in the Ingress-NGINX Controller for Kubernetes disclosed on 24 March 2025 by the Wiz Research team, the most severe being CVE-2025-1974 (CVSS 9.8), which enabled unauthenticated remote code execution from the pod network. Wiz estimated about 43% of cloud environments were vulnerable and identified over 6,500 publicly exposed clusters, including Fortune 500 organizations. The controller's validating admission webhook ran as an unauthenticated HTTP endpoint reachable by any workload on the pod network, accepting attacker-supplied AdmissionReview requests containing crafted Ingress objects. The supporting CVEs (CVE-2025-24514 auth-url, CVE-2025-1097 auth-tls-match-cn, CVE-2025-1098 mirror UID, CVE-2025-24513 path bypass) injected unsanitized NGINX configuration directives via annotations into a temporary config the controller validated with nginx -t. The attacker uploaded a shared-library payload by abusing NGINX client-body buffering (an oversized Content-Length keeps the request file descriptor open in ProcFS) and then used the injected ssl_engine directive to load that library during validation, achieving code execution in the controller pod whose service account could read all cluster secrets across namespaces, enabling full cluster takeover.
- HIGHCLOUD-ENVFILE-EXTORTION-2024
On August 15, 2024, Palo Alto Networks Unit 42 detailed a large-scale extortion campaign that compromised cloud environments by harvesting exposed environment variable files. Attackers scanned at least 110,000 domains and collected over 90,000 unique variables, including roughly 7,000 cloud service credentials and 1,515 social media credentials, with their infrastructure probing around 230 million targets. The vector was a web server misconfiguration: .env files inside the web root were served as plaintext over HTTP because the servers had no rule denying access to dotfiles, exposing the long-lived AWS IAM access keys hardcoded inside. The initial IAM principals lacked full admin but retained permission to create roles and users, so attackers called CreateRole and attached AdministratorAccess to escalate, then spun up Lambda functions across regions to automate further internet-wide scanning. They used the victims' own AWS accounts to exfiltrate and delete S3 objects, then uploaded ransom notes demanding payment. The failure chain combined exposed dotfiles, long-lived hardcoded credentials, and over-permissioned IAM, not any cloud-provider flaw.
- CRITICALCLOUD-BUCKET-MONOPOLY-2024
In research disclosed to AWS on February 16, 2024 and presented at Black Hat USA and DEF CON 32 in August 2024, Aqua Security's Nautilus team described a class of S3 bucket-name takeover attacks they called Bucket Monopoly, affecting CloudFormation, Glue, EMR, SageMaker, Service Catalog, and CodeStar. These services auto-created S3 buckets with predictable names built from static prefixes plus the account ID and region, such as cf-templates-{hash}-{region}, aws-glue-assets-{account-id}-{region}, and sagemaker-{region}-{account-id}, where account IDs are discoverable from ARNs, access keys, and public repos. Because S3 bucket names are globally unique, an attacker could pre-create a victim's predictably named bucket in a region the victim had not yet used (a Shadow Resource), then the victim's service would later read attacker-controlled content from it. This enabled data tampering, information disclosure, remote code execution by injecting malicious Glue or CloudFormation content, and in some cases full account takeover via planted admin roles; AWS remediated by adding randomized suffixes to bucket names and enforcing aws:ResourceAccount conditions. The class also covers reuse of abandoned or dangling bucket names that a victim configuration still references.