by Kim Zetter
* * *
1 Jóska Bartos is a pseudonym. The company asked Bencsáth not to disclose its identity or the identities of people working for it. The description of these events comes from an interview with Bencsáth except where otherwise noted.
2 They uploaded the keylogger to VirusTotal, a free online virus tool that researchers use to detect malicious files, to see if it was known malware. VirusTotal aggregates nearly four dozen antivirus engines from multiple companies to detect malicious files. Two scanners flagged the file as suspicious, but it was unclear if it was a known keylogger or something new. It was flagged by BitDefender and AVIRA scanners. Technically it was also detected by F-Secure and G-DATA, but only because both of these scanners use BitDefender’s engine. VirusTotal is sometimes used by attackers to test their malware before unleashing it to make sure virus engines won’t detect it. But the fact that this keylogger was flagged by two of the engines suggests the attackers either hadn’t bothered to test it against these two scanners before unleashing it or they weren’t expecting their victims to be using the two engines.
3 Confirmation of the nature of the company’s business did not come from Bencsáth or his lab but was gleaned from other sources who were familiar with the breach and the victim.
4 The inoculation value that Stuxnet had used—0x19790509 (which Symantec had interpreted to be a date—May 9, 1979)—also showed up in this new attack code. In Stuxnet it had been used to prevent the worm from infecting machines that had this value in their registry, but here it was part of the encryption.
5 The Microsoft researcher, Tareq Saade, was on the list because the government CERT had already sent Microsoft a copy of the keylogger file after it was discovered, so Bencsáth thought Microsoft should see the CrySyS Lab report as well.
6 The “en/us” letters in the URL merely indicated that the man had visited a site that was localized for English-speaking readers in the United States.
7 Researchers eventually uncovered multiple versions of Duqu, with varying removal times. In some cases it removed itself after 30 days, in other versions it was 36 days. In at least one case, the researchers found a version that lasted 120 days before deletion.
8 Dugald McConnel, “Iranian Official: New Computer Worm Discovered,” CNN, April 27, 2011. Available at cnn.com/2011/TECH/web/04/26/iran_computer_worm.
9 After news of Duqu broke, someone on Twitter who identified himself as an Iranian malware researcher in Virginia published a tweet saying that according to investigations by Iran’s CERT, “#Duqu is upgraded version of #Stars malware.” He deleted the tweet very quickly after posting it, however, and not long afterward also deleted his entire Twitter account. It’s unclear if there was any significance to the image of the galaxies in Duqu or if the attackers had just chosen a random picture, but Bencsáth thought it might have been used as a secret signal to identify Duqu as “friendly fire.” Sometimes various intelligence branches of the same government will target the same computers. If the United States or Israel was behind Duqu, the image might have been a signal to “friendlies” who came across the keylogger on an infected machine—in the course of trying to hack it themselves—that the machine was already infected by a compatriot.
10 Some criticized Symantec’s decision to go public so quickly. A more strategic approach would have been to remain quiet while gathering more intelligence about the attack—for example, asking companies hosting the command-and-control servers for a mirror image of the servers to see what the attackers were doing on them—before signaling to the attackers that they had been caught. It was an ongoing tension that existed between investigative and forensic needs and the needs of customers, who would want to know quickly if they had been infected so they could shore up their network against other attacks and determine if the intruders had stolen anything. But the CrySyS Lab had already sent its report to someone at McAfee, a competing antivirus firm, who might go public with the news or inadvertently tip off the attackers that they’d been caught. There were other drawbacks to waiting to go public. Without widening the net of people who knew about the malware, it would be difficult to obtain other samples of Duqu that could tell them more about the attack. The malware was very targeted, infecting only a small number of victims, and every file related to Duqu that they could collect from victims gave them a little more information about the attack.
11 Symantec’s Duqu report is available at symantec.com/content/en/us/enterprise/media/security_response/whitepapers/w32_duqu_the_precursor_to_the_next_stuxnet.pdf.
12 I was able to confirm the identity of the victim as NetLock from several sources not associated with the CrySyS Lab.
13 It wasn’t just security companies that responded differently this time. The government did as well. For some reason, during the many months the Symantec researchers had been analyzing Stuxnet and publishing pleas for help from PLC experts, ICS-CERT had remained distant, even though its analysts possessed the exact PLC expertise Symantec sought. A DHS official later acknowledged in an author interview that the department made a mistake in not reaching out to Symantec. This time around, ICS-CERT handled it differently and contacted Symantec to compare notes about its own findings about Duqu.
14 Microsoft’s Security Essentials program is based on Raiu’s RAV antivirus engine.
15 The attackers used a custom object-oriented C dialect known as OO-C.
16 While this component displayed masterful skills, there were other parts that were less masterful. The implementation of encryption, for example, was weak. Duqu was built like an elegant Chinese box with multiple layers of encryption to obfuscate its components and thwart detection. But the way the attackers implemented it was poorly done. One part had an encrypted configuration block that held a key to decrypt a registry; inside the registry was another key to decrypt Duqu’s main .DLL file. The design was supposed to make it hard for anyone who got hold of the .DLL to decrypt it without first obtaining the other two keys. But the programmers had undermined their security by making the keys for the registry and the .DLL identical and making the key for the configuration block 0. Once someone unlocked the configuration block, he already had the key to decrypt the main .DLL, bypassing the need for a separate registry key. Stuxnet, by contrast, had used different keys for each stage of encryption. The encryption algorithm used in Stuxnet was also a four-round cipher, while Duqu used a weaker one-round cipher. Clearly different but related teams had designed Duqu and Stuxnet, but even though both teams had strong and advanced methods of encryption at their disposal, the Duqu team hadn’t bothered to use them.
17 To accomplish this, they had to first seize control of the administrative account on an infected machine, then set up a task instructing the malware to spread via network shares.
18 Team Duqu also stored some of the scripts for controlling the operation at other locations, rather than on the command servers, so that anyone who seized control of these front-end servers couldn’t seize and examine the scripts to determine what Duqu was doing.
19 There may have been more victims over the years, but these were the only ones uncovered after Duqu was discovered. Symantec found victims in eight countries—one each in France, India, the Netherlands, Switzerland, Sudan, Vietnam, and Ukraine, and at least two in Iran. Kaspersky found eleven more infections in Iran, three in Europe, and four in Sudan. Other antivirus vendors found victims in Austria, Indonesia, and the UK.
20 Kelly Jackson Higgins, “Same Toolkit Spawned Stuxnet, Duqu, and Other Campaigns,” Dark Reading, January 3, 2012, available at darkreading.com/advanced-threats/167901091/security/attacks-breaches/232301225/same-toolkit-spawned-stuxnet-duqu-and-other-campaigns.html.
21 If Israel was behind Duqu, the delay might have had something to do with the fact that October 18, the date Symantec published its report, fell during the Sukkot holiday in Israel, which ran from October 13 to 19 that year. Sukkot
commemorates the forty years the Israelites spent in the Sinai desert after escaping slavery in Egypt. In Israel, the first day of the festival was a work holiday. Although the remaining six days were not mandatory holidays, many Israelis took them off anyway since schools were closed. Sukkot would have concluded on the nineteenth, with workers back to work on the twentieth—including, presumably, Duqu’s server team.
22 They left behind other traces as well. The night before stories about Duqu broke, the attackers had changed Duqu’s encryption keys and recompiled their Duqu files with the new keys before pushing out the new files to infected machines. The attackers likely intended for the new version of Duqu to replace older versions on infected systems, but they didn’t count on a quirk in the Windows operating system that caused traces of the older version to remain, which researchers later found when their antivirus products scanned the systems. The attackers may have changed the encryption keys because they sensed the malware had been discovered and were trying to outrun detection. But if they suspected they had been caught, they didn’t seem to comprehend the degree to which their mission was about to be exposed, because they also released an update to extend the malware’s life-span beyond thirty-six days, as if they fully expected to continue their operation for a while undisturbed. Once the news broke and they understood that their entire operation was toast, however, they had initiated the cleanup operation to wipe all the data from their servers.
23 The dropper didn’t immediately install its malicious cargo. Instead it waited until the computer was idle at least ten minutes before springing into action. The date on the computer also had to be within an eight-day window in August or Duqu wouldn’t install its files, further evidence of the amount of caution and control the attackers maintained over their code.
24 A blogger for the Finnish antivirus firm F-Secure called it “one badass exploit.” November 2, 2011, “Duqu Attack’s Installer Discovered,” available at f-secure.com/weblog/archives/00002263.html.
25 Researchers saw signs of cybercriminals trying, but failing, to replicate the Duqu exploit in June 2012, eight months after Symantec published information about the vulnerability. They finally succeeded in October 2012, after which Kaspersky saw a spike in attacks using copycat versions of the exploit in December 2012. Microsoft had patched the vulnerability in December 2011, however, so attackers could use the exploit only against unpatched machines.
26 The Kaspersky researchers found something else they thought might be an Easter egg in the code. A decryption key in one version of the Duqu driver had a value—0xAE240682—that also appeared to be a date: June 24, 1982. When Raiu looked it up it turned out to be the day a famous event in aviation history occurred—the date British Airways Flight 09 hit a volcanic ash cloud en route from London to New Zealand. The plane had just taken off after a stopover in Malaysia when gritty ash spewing from Mount Galunggung choked all four of the 747’s engines, leaving it dead in the air. The pilots attempted to glide it to a landing, and as the plane descended from 37,000 to 12,000 feet, oxygen masks dropped from the ceiling. That’s when the British captain, Eric Moody, made one of the most famous understatements in the history of aviation. “Ladies and gentlemen,” he told the passengers, “this is your captain speaking. We have a small problem. All four of the engines have stopped. We are doing our damnedest to get them going again. I trust you are not in too much distress.” (See “When Volcanic Ash Stopped a Jumbo at 37,000ft,” BBC, April 15, 2010. Available at news.bbc.co.uk/2/hi/uk_news/magazine/8622099.stm.) The pilots managed to restart the engines after about fifteen minutes and land in Jakarta. Was it a coincidence that this seemed to be the second aviation reference after the DEADF007 reference in Stuxnet? Or were the attackers just playing with researchers now and dropping little Easter eggs in the code to keep them guessing? Or was the value in the code simply a random number with no significance?
27 Kaspersky’s Costin Raiu bought all past episodes of the Dexter show to see if there was some reason the attackers referenced it in Duqu. Only one episode seemed remotely relevant. In it, Dexter’s sister, Debra, received a marriage proposal from Det. Joey Quinn. During a discussion about the proposal with her brother, he mused that if she were to marry Quinn, her initials would be DQ.
Raiu did see one other episode that reminded him of Duqu. To confuse investigators who were hot on the serial killer’s trail, Dexter crafted a thirty-page manifesto littered with biblical references to distract them. While the investigators wasted time sifting through the meaningless document for clues, Dexter continued his killing spree. The parallels weren’t lost on Raiu, who pondered the hours he’d wasted watching the TV show for clues about Duqu.
28 The dropper file, a driver, tried to pass itself off as a graphics driver from Intel, and was responsible for loading the Duqu back door onto a victim’s machine.
29 There were two attempts to infect the victim, first on April 17, 2011, which got blocked by the victim’s Outlook spam filter, and then on April 21, which succeeded.
30 At the time it was hacked, the Hungarian company would have been doubly alert for a breach because of two other—seemingly unrelated—assaults on certificate authorities that had occurred in the previous months. In March of that year, someone breached the account of a partner company that worked with Comodo Group, a certificate authority based out of New Jersey and the UK. The hacker, who used an IP address in Iran, parlayed the access to issue himself eight fraudulent certificates for mail.google.com, login.yahoo.com, and six other domains that would allow him to impersonate these sites in a man-in-the-middle attack. Four months later, a Dutch certificate authority named DigiNotar was also hacked. The intruders in this case generated more than 200 fraudulent digital certificates for top domains owned by Google, Yahoo, and Mozilla, as well as for the websites of the Mossad, MI6, and the CIA. These intrusions put other certificate authorities on guard, and the company in Hungary had likely stepped up inspection of its network as a result.
31 Duqu’s keylogger/infostealer created file names that began with ~DQ, but other parts of the malware created files whose names began with ~DO and ~DF. Stuxnet also created temporary files whose names began with ~D.
32 Multiple versions of the Duqu driver showed up on infected machines, each time bearing a different name. Each version appeared to contain the same code, however, and was compiled the same day. Notably, one variant of the Duqu driver that was found on the machines in Hungary was unsigned and tried to pass itself off as a product of JMicron—the Taiwanese company whose certificate was used to sign a driver that was found by ESET in July 2010 and was believed to have been associated with Stuxnet. In the “properties” description of the driver, the attackers had indicated that it was a JMicron Volume Snapshot Driver. It was yet another detail that connected Duqu and Stuxnet.
33 The driver file name was jmidebs.sys.
34 The name of this driver was rndismpc.sys.
35 The name of this driver was rtniczw.sys.
CHAPTER 15
FLAME
By the Spring of 2012, the team at Kaspersky had completed their analysis of Duqu and its servers, but they were sure there was more to the story than had so far been exposed. Even they, however, could not have imagined the discovery they were about to make: that Stuxnet—a program that awed with its boldness and destructive potential—was just an offshoot of a cyberspying operation that was orders of magnitude larger than this single digital weapon.
THE REVELATIONS BEGAN that April, when a virus began running wild on computers at the Iranian Oil Ministry and the Iranian National Oil Company, wiping out the hard drive of every system it touched. The damage was systematic and complete, destroying gigabytes of data at a time. First, the malware eliminated documents and data files, then it went after system files, zapping core parts of the hard drive to cause them to crash and burn.
It was unclear how many computers were affected, but there were rumors that the destruction had begun
on some computers as early as December. No one noticed the trend initially, until it spread and became impossible to ignore. It also was not clear how long the virus had lurked on machines before it turned destructive, but each time it did, the destruction began around the twentieth day of the month. Iranian officials dubbed it “Wiper” and pointed to the United States and Israel as the source. They insisted, however, that the attack caused no lasting damage, because all of the deleted data had been backed up.
When Raiu and the Kaspersky team got hold of a mirror image of one of the erased hard drives from Iran, it was filled with gibberish. Not only were all of the documents and critical system files gone, any sign of the Wiper malware was erased from the disk too. But one important clue remained—a single reference inside the registry key to a temporary file named ~DF78.tmp that had been created on the system at some point before the destruction began. The file itself was now gone, but its name lingered on, a ghost betraying its former presence. The ~D prefix in its name was a familiar signifier to the researchers by now. It was the same distinctive naming convention that Duqu had used for the temporary files it created on infected machines, as well as the naming convention that Stuxnet used for some of its files.
Had Duqu, or some other program written by the same team, been on the machine before Wiper erased it?1 Was Wiper a creation of the same team behind Duqu?
Raiu and his team programmed Kaspersky’s antivirus tools to search for the ~DF78.tmp file—and for good measure, to flag any other temporary file that had a name that began with ~D. They got a number of hits on machines in various countries, but the majority of them showed up on machines in Iran. When they obtained a copy of one of the files—this one named ~DEB93D.tmp—they discovered it was a log for a “sniffer” component that recorded passwords as they flitted across the infected machine’s local network. With a little digging, they also found a module that appeared to be responsible for creating the sniffer log.2 It turned out to be one of their most significant finds.
