Yesterday, news about a new trojan have spread. The trojan is called Duqu or, correctly, W32.Duqu. It appears to be based on Stuxnet code, thus it is targeted against industrial automation equipment. However, unlike Stuxnet the new Trojan isn’t targeted to sabotage industrial control systems but steals data. So it is most likely just the precursor to the next Stuxnet-like type of attack. Duqu was, from what we know, targeted against selected organizations mainly in the area of software development for industry automation. It does some espionage there, collecting information which then might be used in the next attack wave. It appears that Duqu deletes itself after 36 days.
Interestingly, Stuxnet used digital certificates which had been “stolen” before. Duqu used other digital certificates which seem to have been directly generated in the name of other companies, bypassing the security of CAs. That relates well with current attacks on CAs, with DigiNotar being the most prominent victim (and now out of the business) and other indicators.
The server in India which has been used by Duqu to provide information back to its creators is now blacklisted by its ISP and thus no longer works. However, chances are that there are more instances of Duqu and Duqu-like trojans either out there or on their way.
Duju proves two assumptions:
- Industrial automation increasingly becomes a target of attackers – and Stuxnet was only the first of its type (which has been detected)
- Attacks are increasingly sophisticated – APTs aren’t a fairytale, they are real
The consequence is that not only the business IT environments need adequate protection but industrial environments as well – they might even need better protection. And if feasible, technical isolation of these networks is a pretty good idea. No net, no (online) attack. Besides this, there is no reason to assume that you are safe against attacks, whichever precautions you take. Thus it is about being proactive at any stage – preventing attacks, identifying attacks, dealing with attacks.
Some valuable information around that has been provided in a recent KuppingerCole webinar – have a look at the webcast.
Where's your evidence that "digital certificates which seem to have been directly generated in the name of other companies" are involved? All indications are that this is another stolen code signing certificate.
http://www.venafi.com/about/blog/
If you read the blog on the attached link you will find that McAfee and Symantec have different opinions. McAfee claim that the evidence tends towards a CA breach and Symantec stating that it is a stolen certificate.
Bottom line is that regardless of which one is right, it only just reinforces the need for organizations to manage their keys and certificates better!
[...] Kuppinger, principal analyst at identity and information security research firm KuppingerCole, in a blog post. Coming on the heels of this year’s attacks against DigiNotar and Comodo, that highlights the [...]
I fully agree to Calum – I see two points here : Use hardware tokens to protect software signing keys and think about revocation methods for malicious software keys. See my blog http://pkienthusiast.wordpress.com/2011/10/21/stu…
[...] Kuppinger, principal analyst at identity and information security research firm KuppingerCole, in a blog post. Coming on the heels of this year’s attacks against DigiNotar and Comodo, that highlights the [...]