Comments for CrySyS Blog http://blog.crysys.hu CrySyS Lab Blog Site - Beta Thu, 05 Jan 2012 19:54:06 +0000 hourly 1 http://wordpress.org/?v=3.3.1 Comment on Duqu=Stuxnet=Stars=Tilded and it is a lego-kit by admin http://blog.crysys.hu/?p=15#comment-3 admin Thu, 05 Jan 2012 19:54:06 +0000 http://blog.crysys.hu/?p=15#comment-3 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. 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.

]]> Comment on Duqu=Stuxnet=Stars=Tilded and it is a lego-kit by William Ockham http://blog.crysys.hu/?p=15#comment-2 William Ockham Thu, 05 Jan 2012 19:20:16 +0000 http://blog.crysys.hu/?p=15#comment-2 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. 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.

]]>