It has already spread to a significant number of countries.
What we know is this:
- It is obvious that every single Duqu incident is unique with its own unique files using different names and checksums;
- Duqu is used for targeted attacks with carefully selected victims (The term APT has been used to describe this, but I don’t like this expression and prefer not to use it);
- We know that there are at least 13 different driver files (and we have only 6 of them);
We haven’t found any ‘keylogger’ module usage. Either it has never been used in this particular set of incidents, or it has been encrypted, or it has been deleted from the systems; - Analysis of driver igdkmd16b.sys shows that there is a new encryption key, which means that existing detection methods of known PNF files (main DLL) are useless. It is obvious that the DLL is differently encoded in every single attack. Existing detection methods from the majority of AV vendors are able to successfully detect Duqu drivers. But it is almost 100% certain that the main DLL component (PNF) will go undetected.
- Duqu is a multifunctional framework which is able to work with any number of any modules. Duqu is highly customizable and universal;
- The main library (PNF) is able (export 5) to fully reconfigure and reinstall the package. It is able to install drivers and create additional components, record everything in the registry, etc. It means that if there is a connection to active the C&C and commands, then Duqu’s infrastructure on a particular system might be changed completely.
The potential malice for us contained in these sophisticated creations is very concerning. This is clearly coming from a state, or combination of states, although precisely who remains unknown, and for what purpose. It appears it is time to rethink how our infrastructure works using the internet, and to come up with some effective defense against things like this, lest we be very unpleasantly surprised some day.
No comments:
Post a Comment