Stuxnet and Duqu - is there a connection?
The subject of cyber weapons is now on everyone's lips. Most of all love this topic exaggerate experts Kaspersky Lab. According to their statements, all significant samples of malware for the last three years are interconnected. For example, Stuxnet and Duqu. But is it really? It must be admitted that the material on Stuxnet is far from complete. For example, there is no description of the procedure for deploying Stuxnet to a computer. Does Kaspersky Lab say it is similar to that in Duqu? The answer is not quite. But about everything in order.
Stuxnet (information taken from Symantec's “W32.Stuxnet Dossier” analytical report, version 1.4, February 2011, pdf):
Duqu (information taken from Symantec 's W32.Duqu analysis report on the precursor to the next Stuxnet , version 1.4, November 2011, pdf):
In general, a general algorithm is viewed:
However, this does not mean that the same people implemented the code in the code.
Stuxnet and Duqu use the same method to call dll library functions, aimed at bypassing monitoring with anti-virus protection using LoadLibrary. For Ntdll.dll install interceptor (hook) functions:
Next, it calls LoadLibrary on a specially selected dll library name that does not exist in the system. Under normal conditions (without interception) this would cause an error. It is the interceptor that loads the real library into the address space.
Also, according to the information of Eset, and Stuxnet, and Duqu use the same interprocessor communication system (RPC), designed to update the components of malware on the local network.
')
Are these facts clear evidence of the connection between Stuxnet and Duqu? Apparently not. The above may well be the result of borrowing the method of implementation into the system or the RPC procedure code.
Now for the drivers. Stuxnet used the mrxcls.sys driver, signed with a Realtek certificate. A little later, another driver was discovered, jmidebs.sys, signed by JMicron. The latter was announced everywhere as a regular Stuxnet driver, but the main module with such a driver was never found. There were also other discrepancies, the mrxcls.sys driver used a direct call of the API functions by name, the jmidebs.sys driver looked for functions by their hashes. To implement the main module, mrxcls.sys created a stub file (exe) with a size of 6332 bytes, jmidebs.sys - with a size of 7061 bytes. Unusually, mrxcls.sys and jmidebs.sys used the same key - 0xAE240682, which, however, in other versions of Duqu was different, to decrypt the lines in the registry. One of the Duqu drivers had identical jmidebs.sys characteristics (stub file size and decryption key). Thus, it can be argued that jmidebs.sys, previously associated with Stuxnet, is actually part of Duqu. There is also an indirect sign - for the Duqu branch the name of the parameter in the registry is typed in capital letters - 'IDE' and 'FILTER', while the Stuxnet branch does not ('Data', 'Config' and 'Action'). Dell SecureWorks experts believe that the similarity of some elements of both malicious programs is an accident. For example, similar techniques are used in other samples of malware. The use of working file names starting with the '~' character is also not evidence of relationship. It is also not necessary to dismiss such a thing as imitation. Based on the time stamps of compilation of individual parts of Duqu, its development could refer to the beginning of 2007. The earliest manifestation of it is associated with the detection of temporary files like ~ DO (probably created by one of the spyware modules), which was created on November 28, 2008 ( article "Duqu & Stuxnet: A Timeline of Interesting Events"). Stuxnet, thus, could be created later, using several Duqu technologies, or their developers scooped information (or source code) from a single source. So the statement by Mikko Hipponen from F-Secure: “The similarity of the Duqu and Stuxnet codes is obvious. The Duqu kernel driver (jminet7.sys) is so similar to the Stuxnet driver (mrxcls.sys) that our systems decided that this is Stuxnet ”- not quite true (jminet7.sys and cmi4432.sys - Duqu drivers found in Hungary employees of the CrySyS laboratory).
Stuxnet (information taken from Symantec's “W32.Stuxnet Dossier” analytical report, version 1.4, February 2011, pdf):
- The main module is a dll;
- a dll contains several resources, including two signed files - the autoload driver and a rootkit to hide the fact of infection of USB Flash media;
- there is a configuration data block (the first half of it is encrypted using the XOR 0xFF operation, the second in another way);
- during installation, the main module and signed files were saved to disk under the names specified in the configuration data block;
- for autorun, a service was created that used a signed driver;
- in the registry at the address 'HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ MrxCls' in the 'Data' key, the names of the target processes (services.exe, S7tgtopx.exe, CCProjectMgr.exe) were saved to the injection process.
Duqu (information taken from Symantec 's W32.Duqu analysis report on the precursor to the next Stuxnet , version 1.4, November 2011, pdf):
- The installer is a dll;
- the dll contains three data blocks containing the signed driver, the main module and the installer configuration data;
- The installer configuration data block is encrypted using a 7-byte key (0x2b 0x72 0x73 0x34 0x99 0x71 0x98);
- during the installation, the main module and the signed drivers were saved to disk under the names specified in the configuration data block;
- for autorun, a service was created that used a signed driver;
- in the registry at the address 'HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ JmiNET3', in the 'FILTER' key, the name of the target process (services.exe), which was injected, was saved in encrypted form.
In general, a general algorithm is viewed:
- loading a signed driver;
- deciphering the data in the registry (containing the mapping 'target process - module');
- Inject a module into the target process.
However, this does not mean that the same people implemented the code in the code.
Stuxnet and Duqu use the same method to call dll library functions, aimed at bypassing monitoring with anti-virus protection using LoadLibrary. For Ntdll.dll install interceptor (hook) functions:
- ZwMapViewOfSection;
- ZwCreateSection;
- ZwOpenFile;
- ZwCloseFile;
- ZwQueryAttributesFile;
- ZwQuerySection.
Next, it calls LoadLibrary on a specially selected dll library name that does not exist in the system. Under normal conditions (without interception) this would cause an error. It is the interceptor that loads the real library into the address space.
Also, according to the information of Eset, and Stuxnet, and Duqu use the same interprocessor communication system (RPC), designed to update the components of malware on the local network.
')
Are these facts clear evidence of the connection between Stuxnet and Duqu? Apparently not. The above may well be the result of borrowing the method of implementation into the system or the RPC procedure code.
Now for the drivers. Stuxnet used the mrxcls.sys driver, signed with a Realtek certificate. A little later, another driver was discovered, jmidebs.sys, signed by JMicron. The latter was announced everywhere as a regular Stuxnet driver, but the main module with such a driver was never found. There were also other discrepancies, the mrxcls.sys driver used a direct call of the API functions by name, the jmidebs.sys driver looked for functions by their hashes. To implement the main module, mrxcls.sys created a stub file (exe) with a size of 6332 bytes, jmidebs.sys - with a size of 7061 bytes. Unusually, mrxcls.sys and jmidebs.sys used the same key - 0xAE240682, which, however, in other versions of Duqu was different, to decrypt the lines in the registry. One of the Duqu drivers had identical jmidebs.sys characteristics (stub file size and decryption key). Thus, it can be argued that jmidebs.sys, previously associated with Stuxnet, is actually part of Duqu. There is also an indirect sign - for the Duqu branch the name of the parameter in the registry is typed in capital letters - 'IDE' and 'FILTER', while the Stuxnet branch does not ('Data', 'Config' and 'Action'). Dell SecureWorks experts believe that the similarity of some elements of both malicious programs is an accident. For example, similar techniques are used in other samples of malware. The use of working file names starting with the '~' character is also not evidence of relationship. It is also not necessary to dismiss such a thing as imitation. Based on the time stamps of compilation of individual parts of Duqu, its development could refer to the beginning of 2007. The earliest manifestation of it is associated with the detection of temporary files like ~ DO (probably created by one of the spyware modules), which was created on November 28, 2008 ( article "Duqu & Stuxnet: A Timeline of Interesting Events"). Stuxnet, thus, could be created later, using several Duqu technologies, or their developers scooped information (or source code) from a single source. So the statement by Mikko Hipponen from F-Secure: “The similarity of the Duqu and Stuxnet codes is obvious. The Duqu kernel driver (jminet7.sys) is so similar to the Stuxnet driver (mrxcls.sys) that our systems decided that this is Stuxnet ”- not quite true (jminet7.sys and cmi4432.sys - Duqu drivers found in Hungary employees of the CrySyS laboratory).
Source: https://habr.com/ru/post/159533/
All Articles