The discovery of Duqu 1.5 shows that the threat actor behind the malware did not go dark — as previously believed — after their operations were exposed by security researchers in 2011.
Following the initial public exposure of Duqu in 2011, the actor seemed to disappear from the threat landscape, only to emerge in 2015 more powerful and sophisticated than before.
With strong connection to the Stuxnet family due to code sharing and the use of a modular design, the Duqu malware was used to spy on companies across Europe, Africa, and the Middle East, as well as to compromise Certificate Authorities to ensure the effectiveness of further attacks.
Completely overhauled, the Duqu 2.0 malware platform that emerged in 2015 could operate almost entirely in-memory and in a semi-wormlike fashion across an enterprise network. The malware, which had over 100 modules, was used to spy on Kaspersky and other entities.
Researchers at Chronicle, a cybersecurity unit of Google’s parent company Alphabet, discovered that in the four-year gap between the two Duqu variants, a third version of the malware had been used. Referred to as Duqu 1.5, it managed to remain unnoticed for at least five years, it seems.
In a compromised environment, the researchers found a kernel driver that was digitally signed and appeared benign, but which was in fact providing persistence for a complex in-memory modular malware platform.
The platform included two types of encrypted Virtual File Systems (VFS), namely an in-memory orchestrator, along with multiple encrypted plugin modules.
Resembling Duqu 2.0, this transitional variant “appears over-engineered or bloated,” the security researchers say. It features “a maze of unpacking routines, encoded strings, and dynamically loaded API calls,” a structure superficially reminiscent of Regin, but featuring a distinct implementation of its features.
The experts couldn’t determine the delivery method for the kernel driver, but know that it begins the multistage infection process. Duqu 1.5 also employs shellcode loaders for the deployment of submodules.
The in-memory orchestrator, KMART.dll, which handles the deployment and interaction between the various modules, was also designed to bypass Kaspersky Antivirus using a method inherited by Duqu 2.0. KMART deploys plugins in a staged rollout process, from an on-disk RC4-encrypted VFS.
Duqu 1.5 contains fewer modules compared to Duqu 2.0 and only a few of them have been recovered, the researchers say. The malware platform, however, does employ a version of the Pipe Backdoor plugin.
For lateral movement, Duqu 1.5 leverages Windows Installer Packages (MSI) generated on-the-fly, but the researchers haven’t determined yet whether the spreader module uses the same method as Duqu 2.0 for deploying the payload to remote systems.
Both HTTP and HTTPS requests were used for communication with the command and control (C&C) servers, likely in an attempt to blend with normal traffic. The researchers were able to identify a single C&C server and IP address associated with the malware.
Chronicle’s researchers discovered a close connection between the Duqu, Stuxnet, Equation and Flame threat actors, and refer to the cluster as the GossipGirl Supra Threat Actor (STA). During their analysis, they uncovered a new component, named Stuxshop, that suggests a fourth team tracked as Flowershop was involved in the early development of Stuxnet. They also uncovered Flame 2.0.
“Duqu is the first example of an apex threat actor that burned down its operations entirely, disappeared for 2-3 years, and was caught having returned. This offers a remarkable opportunity for researchers to understand the meta-trends in toolkit development following public scrutiny. The iterative redesign of from Duqu 1.0 to 1.5 and finally 2.0 is an incremental effort towards a unique-per-target style platform,” Chronicle concludes.
Ionut Arghire is an international correspondent for SecurityWeek.
Tags: 
