Let me answer to Takashi Toyota here. Maybe this blogpost will be corrected/edited later without notice.
The question was:
@CrySySLab @mikko Thank you for the info. “They” have dev platform called #tilded, dont they? From there many instances comming out!
|
In fact, this is an answer to our tweets “Duqu=Stars=Stuxnet (= #tilded) Duqu is an info stealing instance, Stuxnet is a PLC modifying, self-replicating instance.” and “Don’t think on Duqu as a traditional malware. It’s just a version of a info stealing instance of the #tilded platform.”
So the short answer is yes: Tilded-Duqu-Stuxnet-Stars is a development platform for making the right individual malware instance to the actual duty and the actual target.
For the second part the answer is: It depends on the industry if “many instances will come out”. Our CrySyS Duqu detector is the tool that is the first step to stop the threat at all and as such it is a groundbreaking (tilded-breaking) tool. However, this is just a first step, not a final solution!
Let me explain.
- Why is Duqu=Stuxnet?
When we started our investigations we saw raw binary code and had only partial, local information. In the recent months we were discussing a lot and read many interesting news, and the most interesting pieces were coming from Symantec and Kaspersky (and others as well). When we published our report, we were not sure what is the real target or if the code is surely based on source code of the Stuxnet. Now we are confident that the goals of Duqu are most likely highly related to Stuxnet’s goals and that most likely the same developers are behind the code.
Moreover, we really believe that actually Duqu is not a separated project from the Stuxnet/Tilde/Duqu/Stars team, but an integrated part of a workflow. And this workflow does not produce strains or pieces of malware, but they produce modules and compile “instances” for a particular target and a particular goal.
They have kernel drivers, they have exploits, keyloggers and infostealers as (~DN1), file packers as Stars, PLC modules as for Stuxnet, RPC module, injectors, rootkit stuff, and maybe a lots of other modules. Most of them are easy to modify, or to parametrize, and easy to cooperate (compile in, download, etc.) with other modules.
As such, yes, it is a platform. It is not a development platform as it is not an API, but a bunch of modules in different versions and modifications. Most likely, it is not based on a versioning tool, such as SVN where you just checkout the latest version, it is more about the target, the goals and the ideas. Maybe some times they divert to an old version as ‘oh, in that case that idea/modification was great and it’s fit to the current target’ and such.
So we fully agree now, Duqu is not and individual malware, but part of a long story, and we also proposed not to call the individual parts (Stuxnet, Duqu, Stars – SDS), rather we should name the platform somehow. Maybe tilded is the right word, maybe not, but calling them by individual names can be misleading
- War of definitions and names
Duqu was called a RAT, Remote Access Torjan. However, it is not a trojan as it does not state that it will do something good. It is installed through a 0-day windows exploit, so I would not call it a trojan. It is not a virus as well. It does not self-replicate, so still, malware is the best word.
Moreover, it contains a rootkit, as it loads a driver during windows startup. But it’s goal is not a backdoor, or it is not the only goal. That’s true, but it does not infect computers all the time, it can run it’s info stealing component on some targets without infection. Then again – is Duqu a simple keylogger/infostealer? No, it’s more.
Then Duqu is not a rootkit, the rootkit part is just some tool. The info stealing component is not active all the time, moreover, it is not even included into all the Duqu infections at the first step, it is just downloaded from the C&C servers. Okay, then Duqu is a malicious communication protocol? No, it can be, but it’s possible to use RPC to communicate with others without direct communication to the C&C server.
Why was it so important to discuss about this? To see that Duqu at whole cannot be put in any normal categories of malware. And the reason behind this is that “Duqu at whole” simply does not exists! It is a lego-kit of modules and You can only define the goal of the individual modules, not the kit at whole.
(So we totally agree with the definition of Duqu (Tilded) to be a lego-kit recently said by Kaspersky, we already used the verb in our short 5 minutes presentation in November at the Cyber-Security conference at ZMNE, Budapest).
- Why additional instances won’t come out in the near future?
When we identified that Duqu is so closely related to Stuxnet, the most basic question was: Why antivirus tools failed to identify Duqu? You can extend the questin: How is it possible that no one identified Stuxnet and Duqu for such a long time. How is it possible that so many different types existed and they recognize them only recently?
We want to work on this topic, but some preliminary remarks:
-There is a reason why the code of the parts of “Tilded” are so close to each other. Efficiency. Not to rewrite everything multiple times. And more interesting: “Tilded” is a special malware as the code is tested thoroughly and contains lot of careful error handling. Do you want to completly rewrite a code? The you have to restart testing procedures as well. Nobody likes to waste time, therefore basics remained the same for all the code produced by the team, if possible.
Simple changes were necessary and enough to avoid identification of new instances by Anti virus products, and these small changes (e.g. crypto code) were easy to test.
So why do we say that it is unlikely that the team will come out with new instances in the near future? Because if they do not change basic characteristics, these new version will be vulnerable to detections by tools such as our Duqu Detector Toolkit (will be later renamed to something more general).
We made our detector toolkit based on the basics how the Tilded/Duqu/Stuxnet tools work. Our tool does not only detect the driver by signature based techniques, but it detects the info stealer temporary files, any PNF files in the windows/inf directory which has more entropy than expected, etc.
All-in-all our Duqu detector toolkit makes it possible to detect ALL different version of the Tilded platform (Duqu, Stuxnet, who knows what) at some extent. I would not say that it will detect all the possible pieces of information, files or registry settings, but most likely our tool is able to pinpoint problems in a network weather it be 10 computers or 10.000. Again, not just Duqu, not just Stuxnet, but any intermediate instance might have signs that the detector might identify.
And it’s not just our tool. Several researchers made new tools that are not based on raw signatures, but some kind of heuristics. Check Bro, check Metasploit, check A/V vendors’ tools, and others, you can not even easily collect all the ways how people now check anomalies of the platform.
This is the reason why simple modifications on the malware platform now does not work. They need a complete re-write of the code to avoid rapid identification, or the story vanishes in time. Who knows what will come.
I should again thank for the collaboration to Kaspersky and Symantec on the topic.
- Boldi
Editorial note
Blog entries of the Lab is a rapid way of communications. Entries have not went through the regular quality check processes and might contain errors. We modify blog entries if necessary without prior notice. The blog post is a personal disclosure and does not reflect institutional opinion.
Surely the sponsors of the tilded platform are testing their code against your tool now. I expect that they are developing a new component, an infection mechanism that your tool (and all the other Duqu detectors) won’t detect. This new component’s job will be to check to see if your tool or another Duqu detector is installed on the target machine. They will use that component in their next wave of attacks. If the target has no Duqu detector, the same old components can be used. If the target is protected, the tilded sponsors will have rewrite the specific modules that they want to use against that specific target to avoid detection by the particular Duqu detector installed. I don’t think they need a complete rewrite all at once.They can gradually migrate their code to avoid detection.
Sadly, I don’t think this will slow them down all that much. They have what looks like an unlimited budget and a very deep commitment to their mission.
I agree same parts of your opinion, however some ideas: First, the duqu detector is not a persistent checking tool, it is something that can be run occasionally. So no need to check against the detector, or it is complicated what to do if it is detected.
Duqu uninstalls itself after a period of time, but sometimes some slack remains. Detector might find this slack. A possible way for Duqu developers is to correct this by more carefull cleaning of the files, that’s right.
Duqu detector is not “just” binary, it is a GPL open source program. As anybody can recompile it, protecting Duqu against the detector by signature based approach does not work as the contrary does not work, too. (signature based mechanisms against Duqu).
And again, Duqu might be modified to avoid detection. For doing that, one have to rewrite the kernel rootkit part, have new 0-days, might have to get rid of the current injection mechanisms, change temp path file names, change place where it stores config information, should change encryption mechanisms, change file formats, especially magic strings, but maybe record formats as well. They have to have new covert channel mechanisms (not for our detector but for IDS modules), probably new way of thinking about C&C servers. And this list might have to be continued even more.
And don’t forget that every part should be carefully tested, otherwise it will be detected in matter of days, not years.
And don’t forget that now there is a huge focus on any operation at the same types of targets, so exactly the same group with the same types of targets should have to count on honeypots and others as well…
So I respect your ideas, but I’m confident this slow down will be more than just weeks.