{"id":49967,"date":"2014-11-18T11:58:15","date_gmt":"2014-11-18T11:58:15","guid":{"rendered":"https:\/\/www.transcend.org\/tms\/?p=49967"},"modified":"2015-05-05T21:29:30","modified_gmt":"2015-05-05T20:29:30","slug":"son-of-stuxnet-the-digital-hunt-for-duqu-a-dangerous-and-cunning-u-s-israeli-spy-virus","status":"publish","type":"post","link":"https:\/\/www.transcend.org\/tms\/2014\/11\/son-of-stuxnet-the-digital-hunt-for-duqu-a-dangerous-and-cunning-u-s-israeli-spy-virus\/","title":{"rendered":"Son of Stuxnet: The Digital Hunt for Duqu, a Dangerous and Cunning U.S.-Israeli Spy Virus"},"content":{"rendered":"

\"son_of_stuxnet_v2-feature-hero-b<\/a><\/p>\n

Boldizs\u00e1r Bencs\u00e1th 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.<\/p>\n

Bencs\u00e1th, known to his friends as Boldi, was sitting at his desk in the university\u2019s Laboratory of Cryptography and System Security, a.k.a. CrySyS Lab, when the telephone interrupted his lunch. It was J\u00f3ska Bartos, CEO of a company for which the lab sometimes did consulting work (\u201cJ\u00f3ska Bartos\u201d is a pseudonym).<\/p>\n

\u201cBoldi, do you have time to do something for us?\u201d Bartos asked.<\/p>\n

\u201cIs this related to what we talked about before?\u201d Bencs\u00e1th said, referring to a previous discussion they\u2019d had about testing new services the company planned to offer customers.<\/p>\n

\u201cNo, something else,\u201d Bartos said. \u201cCan you come now? It\u2019s important. But don\u2019t tell anyone where you\u2019re going.\u201d<\/p>\n

Bencs\u00e1th wolfed down the rest of his lunch and told his colleagues in the lab that he had a \u201cred alert\u201d and had to go. \u201cDon\u2019t ask,\u201d he said as he ran out the door.<\/p>\n

A while later, he was at Bartos\u2019 office, where a triage team had been assembled to address the problem they wanted to discuss. \u201cWe think we\u2019ve been hacked,\u201d Bartos said.<\/p>\n

They found a suspicious file on a developer\u2019s 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\u2019s 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\u00e1th\u2019s help determining how the intruders had broken in and what they were after. The company had all the right protections in place\u2014firewalls, antivirus, intrusion-detection and -prevention systems\u2014and still the attackers got in.<\/p>\n

Bencs\u00e1th 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\u2014mopping up and restoring systems after random virus infections. He\u2019d 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\u2019t tell anyone what he was doing. Bartos\u2019 company depended on the trust of customers, and if word got out that the company had been hacked, they could lose clients.<\/p>\n

The triage team had taken mirror images of the infected hard drives, so they and Bencs\u00e1th spent the rest of the afternoon poring over the copies in search of anything suspicious. By the end of the day, they\u2019d found what they were looking for\u2014an \u201cinfostealer\u201d 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\u2019s network architecture. The malware didn\u2019t 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.<\/p>\n

Bencs\u00e1th took the mirror images and the company\u2019s 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.<\/p>\n

When Bencs\u00e1th examined one of them\u2014a kernel-mode driver, a program that helps the computer communicate with devices such as printers\u2014his 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<\/em>, he thought. Stuxnet\u2014the cyberweapon that was unleashed on Iran\u2019s uranium-enrichment program\u2014also 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.<\/p>\n

Could the two attacks be related?<\/em> he wondered. He mulled it over for a minute, but then dismissed it. Anyone could have stolen C-Media\u2019s signing key and certificate, he reasoned, not just the attackers behind Stuxnet.<\/p>\n

Then a member of the triage team noticed something else about the driver that seemed familiar\u2014the way it injected code into a certain process on infected machines. \u201cI know only one other attack that does this,\u201d he told Bencs\u00e1th. He didn\u2019t have to say the name; Bencs\u00e1th knew he was talking about Stuxnet. But Bencs\u00e1th dismissed this connection too, since he was pretty sure the technique wasn\u2019t unique to Stuxnet.<\/p>\n

Twice more over the next few days, Bencs\u00e1th 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\u2019s nuclear facility in Natanz.<\/p>\n

But when Bencs\u00e1th and the team examined the drivers used in the two attacks\u2013Stuxnet and this new one\u2013side-by-side, they got a big surprise. The only difference between them was the digital certificates used to sign them.<\/p>\n

Bencs\u00e1th immediately called Bartos, the company\u2019s CEO, and told him he needed to bring the other members of the CrySyS lab on to the investigation. This wasn\u2019t a simple hack anymore; it looked like it might be a nation-state attack with national-security implications. Bartos agreed.<\/p>\n

Bencs\u00e1th 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.<\/p>\n

Attacking the Trust Relationship That Makes the Internet Function<\/strong><\/p>\n

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, \u201cimportant malware,\u201d and came with an attachment. It had been sent to Chien, the technical director of Symantec\u2019s security response team, by two computer scientists at an obscure university lab in Hungary, who wrote in stilted English that they\u2019d discovered a new attack that bore \u201cstrong similarities\u201d to Stuxnet. They dubbed it \u201cDuqu\u201d (dew queue)\u2014because temporary files the malware created on infected machines all had names that began with ~DQ. They were certain that Duqu would \u201copen a new chapter in the story of Stuxnet.\u201d<\/p>\n

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\u2019Murchu telling him to read it as soon as he woke up. Then he headed to the office feeling cautiously excited.<\/p>\n

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\u2019d highlighted in yellow to back his claim.<\/p>\n

Despite Chien\u2019s 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. \u201cThis is Stuxnet,\u201d he said with certainty. The fingerprints of Stuxnet\u2019s creators were all over this new code.<\/p>\n

O\u2019Murchu was still half-asleep when he saw Chien\u2019s 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. \u201cI\u2019ve got to get to the office,\u201d he told his girlfriend as he threw on some clothes and dashed out the door.<\/p>\n

As he drove to work, he tried to wrap his mind around what he\u2019d just seen, and couldn\u2019t 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\u2019t be traced back to them if found. But judging by the report from Hungary, it appeared they hadn\u2019t 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\u2019t 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.<\/p>\n

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.<\/p>\n

As for Duqu\u2019s intent, it was pretty clear it wasn\u2019t 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\u2019s 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.<\/p>\n

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 \u201ccertificate authority\u201d in Hungary \u2014 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.<\/p>\n

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.<\/p>\n

The \u201cStarry Night\u201d\u00a0of Malware<\/strong><\/p>\n

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.<\/p>\n

As soon as he landed in Hong Kong, he contacted Alexander Gostev in Moscow, a young, highly skilled reverse-engineer and the company\u2019s 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.<\/p>\n

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\u2014Raiu likened it to the difference between Vincent Van Gogh\u2019s \u201cStarry Night\u201d and an art-school student\u2019s amateur rendition of a star-filled night. The master brushstrokes and genius in the code were evident to the practiced eye.<\/p>\n

One particularly interesting part was the component the attackers used to download additional payload modules to a victim\u2019s 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\u2019t 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\u2019t hot-shot coders using the latest techniques, but old-school programmers who were cautious and conservative.<\/p>\n

Duqu was also as tightly controlled as Stuxnet had been uncontrolled. The attack didn\u2019t appear to have any so-called zero-day exploits\u2014previously unknown software vulnerabilities\u2014to help it spread, and it also couldn\u2019t 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.<\/p>\n

\"countdowncover-199x300<\/a>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.<\/p>\n

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.<\/p>\n

It seemed the story of Stuxnet was still incomplete.<\/p>\n

_______________________________<\/p>\n

Adapted\u00a0from\u00a0<\/em>Countdown to Zero Day: Stuxnet and the Launch of the World\u2019s First Digital Weapon<\/a>.\u00a0Copyright \u00a9 2014 by Kim Zetter. Published by Crown Publishers, an imprint of Random House LLC.<\/em><\/p>\n

Email the author: kzetter@wired.com<\/a><\/em><\/p>\n

Go to Original \u2013 firstlook.org<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"

It was clear to them immediately that Duqu was the work of master programmers.<\/p>\n","protected":false},"author":4,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[60],"tags":[],"class_list":["post-49967","post","type-post","status-publish","format-standard","hentry","category-whistleblowing-surveillance"],"_links":{"self":[{"href":"https:\/\/www.transcend.org\/tms\/wp-json\/wp\/v2\/posts\/49967","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.transcend.org\/tms\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.transcend.org\/tms\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.transcend.org\/tms\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"https:\/\/www.transcend.org\/tms\/wp-json\/wp\/v2\/comments?post=49967"}],"version-history":[{"count":0,"href":"https:\/\/www.transcend.org\/tms\/wp-json\/wp\/v2\/posts\/49967\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.transcend.org\/tms\/wp-json\/wp\/v2\/media?parent=49967"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.transcend.org\/tms\/wp-json\/wp\/v2\/categories?post=49967"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.transcend.org\/tms\/wp-json\/wp\/v2\/tags?post=49967"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}