Son of Stuxnet: The Digital Hunt for Duqu, a Dangerous and Cunning U.S.-Israeli Spy Virus

WHISTLEBLOWING - SURVEILLANCE, 18 Nov 2014

Kim Zetter – The Intercept

Boldizsár Bencsáth took a bite from his sandwich and stared at his computer screen. The software he was trying to install on his machine was taking forever to load, and he still had a dozen things to do before the Fall 2011 semester began at the Budapest University of Technology and Economics, where he taught computer science. Despite the long to-do list, however, he was feeling happy and relaxed. It was the first day of September and was one of those perfect, late-summer afternoons when the warm air and clear skies made you forget that cold autumn weather was lurking around the corner.

Bencsáth, known to his friends as Boldi, was sitting at his desk in the university’s Laboratory of Cryptography and System Security, a.k.a. CrySyS Lab, when the telephone interrupted his lunch. It was Jóska Bartos, CEO of a company for which the lab sometimes did consulting work (“Jóska Bartos” is a pseudonym).

“Boldi, do you have time to do something for us?” Bartos asked.

“Is this related to what we talked about before?” Bencsáth said, referring to a previous discussion they’d had about testing new services the company planned to offer customers.

“No, something else,” Bartos said. “Can you come now? It’s important. But don’t tell anyone where you’re going.”

Bencsáth wolfed down the rest of his lunch and told his colleagues in the lab that he had a “red alert” and had to go. “Don’t ask,” he said as he ran out the door.

A while later, he was at Bartos’ office, where a triage team had been assembled to address the problem they wanted to discuss. “We think we’ve been hacked,” Bartos said.

They found a suspicious file on a developer’s machine that had been created late at night when no one was working. The file was encrypted and compressed so they had no idea what was inside, but they suspected it was data the attackers had copied from the machine and planned to retrieve later. A search of the company’s network found a few more machines that had been infected as well. The triage team felt confident they had contained the attack but wanted Bencsáth’s help determining how the intruders had broken in and what they were after. The company had all the right protections in place—firewalls, antivirus, intrusion-detection and -prevention systems—and still the attackers got in.

Bencsáth was a teacher, not a malware hunter, and had never done such forensic work before. At the CrySyS Lab, where he was one of four advisers working with a handful of grad students, he did academic research for the European Union and occasional hands-on consulting work for other clients, but the latter was mostly run-of-the-mill cleanup work—mopping up and restoring systems after random virus infections. He’d never investigated a targeted hack before, let alone one that was still live, and was thrilled to have the chance. The only catch was, he couldn’t tell anyone what he was doing. Bartos’ company depended on the trust of customers, and if word got out that the company had been hacked, they could lose clients.

The triage team had taken mirror images of the infected hard drives, so they and Bencsáth spent the rest of the afternoon poring over the copies in search of anything suspicious. By the end of the day, they’d found what they were looking for—an “infostealer” string of code that was designed to record passwords and other keystrokes on infected machines, as well as steal documents and take screenshots. It also catalogued any devices or systems that were connected to the machines so the attackers could build a blueprint of the company’s network architecture. The malware didn’t immediately siphon the stolen data from infected machines but instead stored it in a temporary file, like the one the triage team had found. The file grew fatter each time the infostealer sucked up data, until at some point the attackers would reach out to the machine to retrieve it from a server in India that served as a command-and-control node for the malware.

Bencsáth took the mirror images and the company’s system logs with him, after they had been scrubbed of any sensitive customer data, and over the next few days scoured them for more malicious files, all the while being coy to his colleagues back at the lab about what he was doing. The triage team worked in parallel, and after several more days they had uncovered three additional suspicious files.

When Bencsáth examined one of them—a kernel-mode driver, a program that helps the computer communicate with devices such as printers—his heart quickened. It was signed with a valid digital certificate from a company in Taiwan (digital certificates are documents ensuring that a piece of software is legitimate). Wait a minute, he thought. Stuxnet—the cyberweapon that was unleashed on Iran’s uranium-enrichment program—also used a driver that was signed with a certificate from a company in Taiwan. That one came from RealTek Semiconductor, but this certificate belonged to a different company, C-Media Electronics. The driver had been signed with the certificate in August 2009, around the same time Stuxnet had been unleashed on machines in Iran.

Could the two attacks be related? he wondered. He mulled it over for a minute, but then dismissed it. Anyone could have stolen C-Media’s signing key and certificate, he reasoned, not just the attackers behind Stuxnet.

Then a member of the triage team noticed something else about the driver that seemed familiar—the way it injected code into a certain process on infected machines. “I know only one other attack that does this,” he told Bencsáth. He didn’t have to say the name; Bencsáth knew he was talking about Stuxnet. But Bencsáth dismissed this connection too, since he was pretty sure the technique wasn’t unique to Stuxnet.

Twice more over the next few days, Bencsáth and the triage team found something in the attack code that reminded them of Stuxnet. But each time they convinced themselves it was just a coincidence. There was just no way lightning would strike twice, they reasoned. Besides, there was no sign that this new attack was targeting programmable logic controllers, the industrial computers that Stuxnet manipulated to wreak havoc on Iran’s nuclear facility in Natanz.

But when Bencsáth and the team examined the drivers used in the two attacks–Stuxnet and this new one–side-by-side, they got a big surprise. The only difference between them was the digital certificates used to sign them.

Bencsáth immediately called Bartos, the company’s CEO, and told him he needed to bring the other members of the CrySyS lab on to the investigation. This wasn’t a simple hack anymore; it looked like it might be a nation-state attack with national-security implications. Bartos agreed.

Bencsáth made plans to tell his colleagues the following Monday. Over the weekend, he collected all the technical literature he could find on Stuxnet and reread it to refresh his memory. When he reached the part discussing the encryption routines that Stuxnet used to conceal its code, he pulled up the encryption routines for the new attack and got another surprise. They were nearly identical. The new attack code even used one of the same decryption keys that Stuxnet used. It also used some of the same techniques that Stuxnet used to pull off its attack. There was no doubt in his mind now that the two attacks were related.

Attacking the Trust Relationship That Makes the Internet Function

When Eric Chien awoke on October 14, a Friday, he immediately reached for his BlackBerry to check his e-mail. The subject line of one message caught his eye. It read simply, “important malware,” and came with an attachment. It had been sent to Chien, the technical director of Symantec’s security response team, by two computer scientists at an obscure university lab in Hungary, who wrote in stilted English that they’d discovered a new attack that bore “strong similarities” to Stuxnet. They dubbed it “Duqu” (dew queue)—because temporary files the malware created on infected machines all had names that began with ~DQ. They were certain that Duqu would “open a new chapter in the story of Stuxnet.”

Chien forwarded the e-mail to the rest of the incident-response team at Symantec and sent a text message to his colleague Liam O’Murchu telling him to read it as soon as he woke up. Then he headed to the office feeling cautiously excited.

Over the past year, Chien had grown wary of people contacting him with false alarms about new Stuxnet sightings. Working for an antivirus firm, he was already used to friends and neighbors appealing to his expertise whenever they thought their computers were infected with a virus. But after Chien and his team at Symantec received public credit for their role in unmasking Stuxnet, random strangers began contacting him too, insisting that the government was spying on them with Stuxnet. One guy even sent an envelope stuffed with fifty pages of printed-out screenshots and network traffic logs that he’d highlighted in yellow to back his claim.

Despite Chien’s cynicism about every new Stuxnet claim that crossed his desk, he only had to read the first two pages of the report from Hungary before he knew that this one was different. “This is Stuxnet,” he said with certainty. The fingerprints of Stuxnet’s creators were all over this new code.

O’Murchu was still half-asleep when he saw Chien’s text message that morning, but his grogginess quickly dispersed when he opened the attachment and read the report. There was nothing like staring down the barrel of a suspected cyberweapon to clear the fog in your mind. “I’ve got to get to the office,” he told his girlfriend as he threw on some clothes and dashed out the door.

As he drove to work, he tried to wrap his mind around what he’d just seen, and couldn’t believe the Stuxnet gang was still active. After all the media attention and finger-pointing at Israel and the United States, he thought for sure the attackers would have laid low for a while to let things cool off. At the very least he thought they would have altered their methods and code a little to make sure that any attack they unleashed hereafter couldn’t be traced back to them if found. But judging by the report from Hungary, it appeared they hadn’t bothered to alter their signature moves at all. They really had balls, he thought. They were determined to do whatever they had to do to conduct their attack and didn’t care who knew it was them. Either that, or they were already so invested in using the Duqu code that they were loath to replace it even after Stuxnet had been caught.

Duqu was essentially a remote-access Trojan, or RAT, which operated as a simple back door to give the attackers a persistent foothold on infected machines. Once the back door was installed, however, Duqu contacted a command-and-control server, from which the attackers could download additional modules to give their attack code more functionality, such as the keystroke logger/infostealer the Hungarians had found on one of their systems.

As for Duqu’s intent, it was pretty clear it wasn’t a saboteur like Stuxnet, but an espionage tool. Whereas Stuxnet was a black ops mission bent on destruction, Duqu appeared to be the forward scout, sent out to collect intelligence for future assaults. Symantec suspected it was the precursor to another Stuxnet-like attack. Duqu’s life-span was limited, however; a kill date in the code forced it to self-destruct after thirty-six days, deleting all traces of itself from an infected machine.

One thing that made Duqu particularly scary was its target. Though the Hungarian researchers and Symantec took pains to conceal its identity when they went public with the news of Duqu and never identified the firm, other researchers quickly determined that the victim was NetLock, a “certificate authority” in Hungary — an agency responsible for issuing digital certificates that governments, financial institutions, and companies use to sign their software and websites, providing users with assurance that they are downloading a legitimate program made by Microsoft or entering their account login credentials at a legitimate website operated by Bank of America or Gmail.

The implications were alarming. Certificate authorities are at the core of the trust relationship that makes the internet function. Attacking such an authority would allow the attackers to issue themselves legitimate certificates in the name of any company and use it to sign malware. If Duqu was the work of the United States or Israel, it meant that a NATO country or ally had compromised a fundamental part of the trusted infrastructure that made transactions on the internet possible, all for the sake of advancing a covert campaign. If the United States was behind the attack, it also meant that while one branch of the government was touting the importance of securing critical infrastructure at home and developing acceptable norms of behavior for the internet, another was busy compromising critical systems that were important for the security of the internet, and establishing questionable norms of behavior that others would copy.

The “Starry Night” of Malware

Costin Raiu, director of the global research and analysis team for the Russian security firm Kaspersky Lab, was in Beijing when news of Duqu broke, preparing to board an early-morning flight to Hong Kong for a meeting. His first thought was to call his colleagues back in Moscow, but they were still asleep. So before boarding his plane, he quickly downloaded the Duqu files Symantec made available to researchers and examined them during his flight.

As soon as he landed in Hong Kong, he contacted Alexander Gostev in Moscow, a young, highly skilled reverse-engineer and the company’s chief malware researcher. Symantec and the CrySyS Lab had examined the Duqu files thoroughly, but Raiu and Gostev suspected there was much more intelligence to be gleaned from the threat, and they were right.

It was clear to them immediately that Duqu was the work of master programmers. The code was remarkably different from other spyware that crossed their desks—Raiu likened it to the difference between Vincent Van Gogh’s “Starry Night” and an art-school student’s amateur rendition of a star-filled night. The master brushstrokes and genius in the code were evident to the practiced eye.

One particularly interesting part was the component the attackers used to download additional payload modules to a victim’s machine to siphon data. Unlike every other Duqu and Stuxnet module, this one was written not in C or C++ but in a language Gostev and Raiu had never seen before. They tried for weeks to identify it and even consulted experts on programming languages, but still couldn’t figure it out. So they put out a call for help on their blog and were finally able to conclude, piecing bits of clues together, that the attackers had employed a rarely used custom dialect of C, along with special extensions to contort the code and make it small and portable. It was a programming style common to commercial software programs produced a decade ago, but not to modern-day programs, and certainly not to malware. It was clear these weren’t hot-shot coders using the latest techniques, but old-school programmers who were cautious and conservative.

Duqu was also as tightly controlled as Stuxnet had been uncontrolled. The attack didn’t appear to have any so-called zero-day exploits—previously unknown software vulnerabilities—to help it spread, and it also couldn’t spread autonomously as Stuxnet did. Instead, once on a machine, it would infect other machines only if the attackers manually sent instructions from their command server to do so. And unlike Stuxnet, which struck more than 100,000 machines, researchers would eventually uncover only about three dozen Duqu infections.

The attackers were systematic in how they approached their victims, compiling new attack files for each target and setting up separate command servers throughout Europe and Asia so that only two or three infected machines reported to a single server. This segmentation no doubt helped them track different operations and sets of victims, but it also ensured that if any outsider got access to one of the servers, their view of the operation would be very limited.

With help from some of the companies that hosted the servers, Kaspersky obtained mirror images of five of the command-and-control servers. They discovered that on October 20, two days after Symantec had gone public with news of Duqu, the attackers had conducted a massive cleanup operation in a panicked attempt to scrub data from the servers. Why it took them two days to respond to the news was unclear. But in their haste to eliminate evidence, they left behind valuable traces of logs that provided Kaspersky with clues about their activity. The logs showed that the attackers had signed into one of the command servers in Germany in November 2009, two years before Duqu was discovered. Duqu, it turns out, had been in the wild for much longer than anyone had suspected. Perhaps, the Kaspersky researchers posited, it was really a precursor to Stuxnet, not a successor to it, as Symantec assumed.

It seemed the story of Stuxnet was still incomplete.

_______________________________

Adapted from Countdown to Zero Day: Stuxnet and the Launch of the World’s First Digital Weapon. Copyright © 2014 by Kim Zetter. Published by Crown Publishers, an imprint of Random House LLC.

Email the author: kzetter@wired.com

Go to Original – firstlook.org

Share this article: email mastodon facebook 🔗 copy link

DISCLAIMER: The statements, views and opinions expressed in pieces republished here are solely those of the authors and do not necessarily represent those of TMS. In accordance with title 17 U.S.C. section 107, this material is distributed without profit to those who have expressed a prior interest in receiving the included information for research and educational purposes. TMS has no affiliation whatsoever with the originator of this article nor is TMS endorsed or sponsored by the originator. “GO TO ORIGINAL” links are provided as a convenience to our readers and allow for verification of authenticity. However, as originating pages are often updated by their originating host sites, the versions posted may not match the versions our readers view when clicking the “GO TO ORIGINAL” links. This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available in our efforts to advance understanding of environmental, political, human rights, economic, democracy, scientific, and social justice issues, etc. We believe this constitutes a ‘fair use’ of any such copyrighted material as provided for in section 107 of the US Copyright Law. In accordance with Title 17 U.S.C. Section 107, the material on this site is distributed without profit to those who have expressed a prior interest in receiving the included information for research and educational purposes. For more information go to: http://www.law.cornell.edu/uscode/17/107.shtml. If you wish to use copyrighted material from this site for purposes of your own that go beyond ‘fair use’, you must obtain permission from the copyright owner.

Comments are closed.