Six weeks since Crysys Lab in Hungary put out their initial paper on Duqu, four weeks since Symantec's first dossier, and the question I keep coming back to is what the people who built Stuxnet are doing now. Duqu is the answer that the public technical analysis is starting to converge on, and it is operationally substantial enough — and structurally interesting enough — that I want to write up where the analysis stands.
The proximate facts. Crysys Lab identified the malware while doing incident-response work for an unnamed European customer, recognised the structural similarities to Stuxnet, and shared samples with Symantec on 14 October. Symantec's analysis confirmed and extended Crysys's initial findings: the executable shares substantial code with Stuxnet, almost certainly written by the same operator group, but the payload is entirely different. Where Stuxnet was a precision weapon aimed at specific Siemens SCADA equipment, Duqu is an information-collection toolkit. It collects keystrokes and system information, takes screenshots, exfiltrates documents, and has a generic plugin architecture for additional capabilities. It is what you build when you have already broken into the target environment, want to maintain persistent access for some months, and want to extract material that supports a follow-on operation.
The implication is clear enough. Duqu is the reconnaissance phase for what is presumably the next Stuxnet-class operation — gathering the SCADA-environment information that will be needed to build a precision payload tailored to specific equipment in a specific facility. The targeting profile fits: confirmed Duqu infections so far are concentrated at industrial-control vendors and operators in Iran, Hungary, Sudan, Vietnam, France, the Netherlands, Switzerland, and the United Kingdom. Several of those locations correspond to facilities or vendors that supply equipment to Iran. Whether the operator is the same combination of nation-states that built Stuxnet, whether it is a different combination, or whether it is the same lead operator with new sub-contractors — these are the questions that the public analysis cannot answer, but the most coherent reading is that the same intelligence-and-engineering capability is in continuous use and is now visibly assembling its next operation.
The technical details I want to record. The injector component delivers the malware through a previously-unknown TrueType font parsing vulnerability in Windows; this is the kind of zero-day that nobody outside a substantial intelligence operation can reliably produce, and Microsoft is still working on the patch — Security Advisory 2639658 shipped on the third with workarounds, but no patch yet. The persistence mechanism uses signed kernel drivers, which require either compromised certificate-authority access (the DigiNotar shape) or stolen code-signing keys. The command-and-control protocol disguises traffic as image downloads from a remote server, which is a more careful operational-security choice than most commercial-cybercrime malware bothers with. The configuration permits per-target customisation, which means the operator can tailor the data-exfiltration rules to what they expect to find at each victim. The whole system reads as a careful, well-resourced engineering effort, with the resource profile of a state-grade operation.
What this changes for the field is the timeline. Stuxnet was identified in mid-2010, analysed through the autumn, and confirmed-and-attributed (in the public press at least) through early 2011. The window between Stuxnet becoming public and the apparent successor operation appearing — which is where Duqu sits — is approximately twelve to fifteen months. That is much shorter than the multi-year cycle most defensive thinking has been planning for. The implication is that the operational tempo of state-grade industrial-control attacks is not the once-in-five-years cadence we have been assuming, but something closer to annual, with the reconnaissance phase running on a roughly twelve-month cycle ahead of the precision-payload phase.
For the engagements with industrial-or-OT exposure — Northcott has some, two of the Hedgehog clients have some — this changes the conversation about what to defend against and at what intensity. The honest argument I have been making to the boards is that "we are not a Stuxnet target" is no longer the answer, because the reconnaissance phase does not require you to be the eventual target — it requires you to be the supplier or the engineering services provider to the eventual target, or to have engineers in your organisation who have done work for one. Several of my clients fall into one of those categories without thinking of themselves as in the threat model.
The Hungarian connection is the part I am personally most curious about. Crysys Lab identified Duqu in Hungarian environments because they are the local incident-response capability with the technical depth to spot the Stuxnet relationship. The fact that one of the early infections was in Hungary, and the fact that Crysys was the lab that recognised it, are presumably independent facts — but the localisation tells you something about where the operator believed targeting was rich. Hungary has substantial engineering services to several Iranian-adjacent industrial sectors. I will be reading Boldizsár Bencsáth's papers closely as more material lands.
The next post is probably either the year-end retrospective, given how close to December we now are, or whatever falls out of the Anonymous-aligned activity that is rumoured around Stratfor in the weeks ahead. Or possibly more on the SecurID-aftermath at the defence-contractor end, where two of my correspondents are seeing what they think is a continuation of the original campaign.