In May 2012, researchers pulling apart an espionage toolkit found in the Middle East hit something that stopped them cold. The malware — Kaspersky called it Flame, the CrySyS Lab in Budapest called it sKyWIper, Iran’s CERT called it Flamer — could spread from one infected machine to the others on the same network by handing them a Windows Update. A real-looking one. Signed by Microsoft.
That last part is the part that matters. Anyone can write a program that pretends to be an update. The trick is getting Windows to accept it, and Windows accepts an update because it is signed by a certificate that chains up to a Microsoft root. To fake that, you either steal Microsoft’s signing key — nobody did — or you make a certificate that Windows believes Microsoft signed, without Microsoft ever having signed it. Flame did the second thing. It forged a Microsoft-trusted code-signing certificate. And the cryptography it used to do it was, according to the person best placed to judge, a technique the open research world had not published.
The certificate is a chain, and every link was defensible
Start with how the fake update actually worked, because the crypto is the last step, not the first.
Flame carried three modules that together turned an infected PC into a malicious update server for its neighbors. One watched the local network for the broadcast queries machines send when they’re looking for a proxy — the WPAD requests — and answered them, so nearby computers started routing their traffic, including their Windows Update checks, through the infected box. Another ran an HTTP server that impersonated Microsoft’s update endpoint. The third assembled the payload the victim would receive: a small signed executable, about 28 KB, that presented itself as a legitimate update and therefore ran without a single warning dialog.
None of that works without a valid signature. And here is where the chain of “each piece was individually reasonable” starts.
Microsoft ran a service for Terminal Server licensing — the plumbing that lets Remote Desktop deployments activate their client-access licenses. That service issued certificates, and to make activation painless the certificates it issued chained all the way up to the Microsoft Root Authority. So far, so ordinary: a company signing its own operational certificates off its own root. The enrollment for those licensing certificates didn’t require any internal access to Microsoft’s real code-signing infrastructure — again, sensible, because licensing has nothing to do with shipping software.
The problem is that “chains to the Microsoft root” is exactly what Windows checks when it decides whether to trust signed code. On older versions of Windows, a certificate from that licensing service would be honored for code signing, because nothing in the chain said “this is only for licensing, not for signing programs.” A certificate minted to count Remote Desktop seats could vouch for an executable. Nobody designed that capability. It fell out of the intersection of two systems that each looked fine on their own — which is the recurring shape of these stories, and the one worth training yourself to see.
The one obstacle, and the collision that removed it
The licensing certificates had a catch that should have closed the hole. Each one carried an extra field — an extension Microsoft used internally, marked critical. “Critical” in X.509 means: if you don’t understand this field, refuse the certificate. Windows Vista and everything after it did the correct thing and refused to accept a certificate with that unrecognized critical extension for code signing. So on a modern machine, the licensing certificate as issued was useless to an attacker.
The obvious move is to make a cleaner certificate — one without the offending extension, and with the right validity for code signing. But you can’t just edit a certificate. A certificate is only trusted because the issuer signed a hash of its contents; change a byte and the hash changes and the signature no longer matches. To produce a different certificate the CA would still appear to have signed, you need two documents with the same hash: the harmless-looking one the licensing service actually signs, and the weaponized one you keep. That is a hash collision, and it only helps you if the CA’s signature is over a hash weak enough to collide.
It was. The licensing service signed with MD5.
MD5 was not a surprise in 2012. Researchers had produced MD5 collisions in 2004, and in 2008 a team including Marc Stevens at CWI Amsterdam had used an MD5 chosen-prefix collision to mint a rogue certificate authority that browsers trusted — a public, published, widely-reported demonstration that this exact category of attack was real. A chosen-prefix collision is the dangerous kind: the attacker fixes two different meaningful beginnings — here, two different certificates — and the math finds the filler bytes to append to each so their hashes land on the same value. It is the shape of attack that forges real, structured things instead of two junk files.
So the theory was four years old and the proof was four years old, and Microsoft was still signing production certificates that chained to its root with MD5. The loaded gun had been sitting on the table since 2008.
The part that should still make you uncomfortable
When Stevens examined the certificate Flame carried, he found it was not made with his 2008 method. The collision bore the marks of a chosen-prefix attack, but a variant — one that had not appeared in the public literature. His assessment was blunt: designing it required world-class cryptanalysis. Whoever built Flame was ahead of the published research.
Sit with that, because it inverts the comforting way we usually reason about broken crypto. The story we tell — the one the SHA-1 collision fit so neatly — is that a primitive is “theoretically broken” for years, and the real risk arrives the day someone posts a proof of concept you can download. Under that model you get to watch the danger approach. You can point at the paper. Flame breaks the model. The most capable attackers don’t wait for the PoC and they don’t limit themselves to the published attack. They may be a technique ahead of the entire open field, and you will find out only when you reverse-engineer what they already deployed. “No public attack exists yet” is not the same as “no attack exists,” and against a nation-state budget the two can be years apart.
There’s one more institutional footgun that made the collision practical, and it’s a mundane one. A chosen-prefix collision needs you to know the prefix in advance — you have to fix the exact bytes of the certificate the CA is going to sign before you compute the matching filler. That means predicting the certificate’s serial number and the precise validity timestamps the licensing server would stamp on it, down to a tight window, because those bytes are part of what gets hashed. The licensing service made that prediction feasible: its serial numbers were sequential and its timestamps followed the clock. Predictable issuance turned a collision that would otherwise require guessing an unguessable prefix into an engineering problem with a solution. Randomize the serial number — which is now standard CA practice, precisely because of attacks like this — and the whole approach gets dramatically harder.
What actually got fixed
Microsoft moved fast once it understood the mechanism. On June 3, 2012, it issued Security Advisory 2718704, revoking the intermediate certificate authorities under the Terminal Server licensing hierarchy so that anything chaining through them stopped being trusted. It followed up by pulling licensing certificates out of the code-signing path entirely and hardening how Windows Update authenticates what it installs, so that a certificate never intended for signing software could no longer be bent into signing software. The specific hole — licensing certs usable as code-signing certs — was closed.
But notice that none of the individual fixes were about MD5, and that’s the tell. The collision was the last link. The links before it were the ones that made the target worth attacking: a licensing PKI that chained to the root, certificates that could sign code they were never meant to sign, and predictable issuance that handed the attacker the prefix they needed. Every one of those was a locally reasonable decision. Together they built a path from “activate a Remote Desktop license” to “sign malware as Microsoft.”
The lesson isn’t “MD5 is broken”
Everyone knew MD5 was broken. It had been broken in public for years, with a headline-grade certificate forgery to prove it, and it was still holding up a signature in a Microsoft production system in 2012. The lesson is that a broken primitive left in production is not a low-priority ticket you’ll get to after the next feature. It is a live capability sitting in your infrastructure waiting for someone with the budget and the prefix to use it — and the someone may be better at the math than the papers you’re reading.
The second lesson is the one about chains. Flame did not defeat a strong system. It walked a path assembled out of a half-dozen individually sensible choices, and the security of the parts did not add up to the security of the whole. A certificate is a chain of trust in the literal sense, and the interesting failures are almost never in a single link. They’re in the places where two systems meet and each assumes the other one is holding the rope.