The Internet is based on IP datagrams, and these are switched, copied and routed everywhere by specialized hardware.
It wasn't always so; the very first prototypes were more or less cobbled together from repurposed circuits.
So let's imagine that a conspiracy sprouted somewhere around 1983-1984, when some people in the networking community were far-seeing enough to see how fast and far the concept of "networking" would go, and paranoid enough to fear it could be used for war, or that it could be useful to have a kill switch.
So they embedded a backdoor in the TCP/IP stack - somewhere that nobody would look unless they were tracking a severe malfunction, something that nobody would change without a hell of a good reason. Other ancillary protocols and routines were subtly tweaked to make life impossible for anyone trying to redesign things, and the backdoored section was so carefully inspected during the "sabotage" that it contained no real bugs - and nobody looked at the code anymore for forty years.
It sounds implausible, but there have been bugs in pieces of security code used for ciphering banking Internet connections that have lied undetected for decades. Also, horror stories abound on how you never touch the TCP/IP stack - below one of them Fiddle a bit, optimize, add features - but never touch the core:
Please don't rewrite your network stack unless you can afford to dedicate a team to
support it full time.
Twice in my career I have been on teams where we decided to rewrite IP
or TCP stacks. The justifications were different each time, though
never perf.
The projects were filled with lots of early confidence and successes.
"So much faster" and "wow, my code is a lot simpler than the kernel
equivalent, I am smart!" We shipped versions that worked, with high
confidence and enthusiasm. It was fun. We were smart. We could rewrite
core Internet protocol implementations and be better!
Then the bug reports started to roll in. Our clean implementations
started to get cluttered with nuances in the spec we didn't
appreciate. We wasted weeks chasing implementation bugs in other
network stack that were defacto but undocumented parts of the
internet's "real" spec. Accommodating these cluttered that pretty code
further. Performance decreased.
In both cases, after about a year, we found ourselves wishing we had
not rewritten the network stack. We started making plans to eliminate
the dependency, now much more complicated because we had to transition
active deployments away.
I have not made that mistake a 3d time.
Even those who did never questioned what appeared to be working code, and the backdoor was designed to simply crash the processing, not doing anything very complex - simply using a variable for an index that came from somewhere else that was always untainted and secured unless in very specific, impossible to "just happen" circumstances (which is how most such bugs are caught, by so called "input fuzzers")...
Year after year, the flawed algorithm gets replicated in routers, computers, laptops, switches, access points - whatever. Most of those actually employ chips produced by just a handful of manufacturers, and they all fiddle with speeds, offloadings, parallelization, error correction - they never question the original code. Why should they ever?
However, all good things must come to an end. A new AI designed to find and exploit vulnerabilities in remote code is deployed and tested by some random but powerful State, and after some time it stumbles on paydirt. A zero-day exploit that works with almost all network equipment. Even better, the original designers could not foresee that on some platforms (most of the modern ones, no less) this backdoor can be abused so that, instead of throwing a random error, it can actually execute instructions sent from the outside, even propagating them across firewalls.
So our black team quietly starts developing the ultimate virus infector. They only have this one chance, so they need something terrifyingly advanced.
First they prepare a small loader, that will create a "parallel internet" made up of dropped packets. Any network scan will report that a gigabit line has 0.1% packet loss - which is acceptable and actually not even felt by users. 20% of that is legit, actual damaged packets due to electrical noise, interference, and maybe solar protons. The remaining 800 kilobit/s allow a weakly encrypted payload to establish a virtual point-to-point connection that, once diagnosed the full capabilities of the target system, will transfer the megabyte-range secondary payload in about five minutes.
Ten minutes later, on more than 90% of vulnerable systems a tertiary payload will boot, designed to bluepill the targeted system and replicate on the victim's network. The full system is quite large - 12 megabytes of compressed code - but most systems have plenty of free space. On some systems, the infection can hide inside the hard disk CPU and resist reformatting.
One fateful day, a large scale experiment runs awry, and the virus begins replicating like wildfire. The developers have designed for such an occurrence, and the "ACTIVE KILL" command goes out. Everywhere in the building, copies of the virus start killing each other and suiciding after a while. Nobody notices that viruses actually first target and infect systems, and then kill them (or sometimes are killed by them).
And nobody notices the bored desk worker that had connected his laptop to watch some porn during the graveyard shift, and quickly shut it down and stowed it away when everybody started running around screaming.
In the morning, the guy goes home and sleeps, then in the afternoon he fires up the laptop to check his banking account. He checks his mail, then logs on a social network - but about one hour later, the network disconnects abruptly and no matter what he does, does not reconnect. After a while the guy realizes that the access point is dead. He goes to buy another, and has to pay cash because the store is having trouble with the POS connection...