Countdown to Zero Day: Stuxnet and the Launch of the World's First Digital Weapon (39 page)

COSTIN RAIU, DIRECTOR
of Kaspersky’s Global Research and Analysis Team, 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.

Raiu was a thirty-three-year-old Romanian who worked for Kaspersky out of a tiny office in Bucharest with one other researcher and a handful of marketing folks. He had dark, close-cropped, graying hair and a maturity and wisdom that belied his age. The latter made him a natural mentor to younger members of his research team. He also had a calm, Buddha-like demeanor that served him well under pressure when they were juggling multiple complex projects at a time. It was a quality that would prove invaluable over the many months that followed as his team’s research into the Stuxnet-Duqu gang intensified and they began to draw the attention of intelligence agencies.

Raiu had joined the company in 2000 at the age of twenty-three, when it had just a few dozen employees. He was hired to work on its Prague project, the name the company gave the next-generation antivirus engine it was building.

Growing up in Communist Romania, Raiu’s passion hadn’t been computers but chemistry. He was fascinated by the combustible reaction of certain chemicals when mixed and by the fundamental knowledge that chemistry imparted about the nature and structure of the world. But when one of his experiments nearly blew up his parents’ apartment, they bought him a locally made PC clone to steer him toward less lethal pursuits. It wasn’t long before he’d taught himself programming and, while still a teenager, designed an antivirus engine from scratch called RAV.

His work on RAV began when his high school network got infested with a virus the school’s antivirus scanner didn’t detect. Raiu spent a night
writing signatures and crafting a detection tool for it. Over time, he added more code and features, and eventually began distributing it for free under the name MSCAN. When word of his creation got out, a Romanian entrepreneur hired him to work for his company, GeCAD Software, which began marketing his program under the name RAV, for Romanian Anti-Virus. It quickly became the company’s top-selling product, reliably beating out competitors in test after test, which drew the attention of Microsoft. In 2003, the software giant acquired RAV from GeCAD, but by then Raiu had already jumped ship to work for Kaspersky.
¹⁴

Kaspersky Lab was relatively unknown at the time in the United States, where Symantec and McAfee dominated the antivirus market. As a Russian firm, Kaspersky faced a battle of mistrust in the West—particularly since founder Eugene Kaspersky had been schooled in a KGB-backed institute and had served in Russia’s military intelligence. But the company slowly made a name for itself in eastern Europe and elsewhere, particularly in the Middle East, where the United States and US firms faced a similar battle of mistrust.

Raiu began with Kaspersky as a programmer, but in 2004 when the company launched a research team to investigate and reverse-engineer malware, Raiu joined the group. In 2010, he became its director, overseeing research teams on several continents. Now, with the discovery of Duqu, several of these teams went into action.

The technical work was led by Gostev, a whippet-thin analyst with short, light brown hair and a slight stoop that was suggestive of all the hours he spent bent in concentration over a computer. As he and his colleagues picked through the code, they were struck by a number of things.

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. Sometimes C++ could produce compiled code that was unpredictable and executed in unintentional ways. So the attackers had chosen C instead, Raiu surmised, to give them the greatest control over their malicious code, then modified it during compilation to make it more compact and easy to deliver to victims.
¹⁶

Their constraints on Duqu extended to its spreading mechanisms. In this regard Duqu was as tightly controlled as Stuxnet had been uncontrolled. The attack didn’t appear to have any zero-day exploits 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.
¹⁷
Duqu
was also much stealthier in communicating with its command servers than Stuxnet had been.
¹⁸
The communication was encrypted with a strong encryption algorithm known as AES, to prevent anyone from reading it, and was also tucked inside a .JPEG image file to help conceal it. And unlike Stuxnet, which struck more than 100,000 machines, researchers would eventually uncover only about three dozen Duqu infections.
¹⁹

The victims were scattered among various countries and ranged from military targets to manufacturers of industrial equipment, such as pipes and valves. All of them appeared to have been carefully targeted for their “strategic assets”—products they produced or services they rendered.
²⁰
Not surprisingly, many of the victims Kaspersky uncovered had a connection to Iran; either they had an office in the Islamic Republic or they had some kind of trade relationship with Iran. The only victim so far that didn’t appear to have a connection to Iran was the company in Hungary that discovered the attack.

Based on information gleaned from log files provided by some of the victims, the attackers appeared to be particularly interested in swiping AutoCAD files—especially ones related to industrial control systems used in various industries in Iran. AutoCAD, which stands for computer-aided design, is software used for drafting 2D and 3D architectural blueprints and designing computer boards and consumer products; but it’s also used for mapping the layout of computer networks and the machinery on plant floors. The latter would come in handy for someone planning to bomb a factory or launch a digital attack like Stuxnet.

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. The servers, in fact, turned out to be proxy machines—way stations for the attackers to redirect stolen data to other machines—to further prevent anyone from seeing the entire operation or tracking stolen data back to the attackers. Data from the victim in Hungary, for example, was first sent to a server in India before being redirected to one in the Philippines, where it was sent somewhere else. Data from victims in Iran went to a server in Vietnam before going to Germany and somewhere beyond. The researchers tried to follow the trail, but after hitting three different proxies in a row each time, they figured they’d never reach the end of the trail, and gave up.

With help from some of the companies that hosted the servers, however, Kaspersky obtained mirror images of five of the machines, including one in Vietnam that controlled infections in Iran. 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 traces of logs that provided Kaspersky with clues about their activity.
²²
The logs showed, for example, that the attackers had
signed into one of the command servers in Germany in November 2009, two years before Duqu was discovered. This suggested that Duqu was likely in the wild for at least that long. Perhaps, the Kaspersky researchers posited, Duqu was really a
precursor
to Stuxnet, not a successor to it, as Symantec assumed. It wouldn’t be long before they found the evidence to support this.

IT WAS INITIALLY
unclear to anyone how Duqu infected machines. Stuxnet had used the .LNK exploit embedded on USB flash drives to drop its malicious cargo. But the CrySyS Lab had found no dropper on machines at Bartos’s company and no zero-day exploits, either. After Symantec published its paper about Duqu, however, Chien asked Bencsáth to have the Hungarian victim search their systems again for anything suspicious that occurred around August 11, the date the infection occurred. That’s when they found an e-mail that had come in then with a Word document attached to it. The attachment was 700k in size—much larger than any documents the company usually received—which drew their attention. Sure enough, when the CrySyS team opened the e-mail on a test system in their lab, Duqu’s malicious files dropped onto it.
²³

Given that the attack code had gone undetected until now, the CrySyS guys suspected a zero-day exploit was at play. Bencsáth sent the dropper to the Symantec team, who determined that it was indeed exploiting a zero-day buffer-overflow vulnerability in the TrueType font-parsing engine
for Windows. The font-parsing engine was responsible for rendering fonts on-screen. When font code for a character appeared in a Word document, the engine consulted the proper font file to determine how the character should look. But in this case when the engine tried to read the font code, a vulnerability in the parsing engine triggered the exploit instead.

The exploit was quite “badass,” in the words of one researcher, because a normal exploit attacking a buffer-overflow vulnerability generally got hackers only user-level access to a machine, which meant they needed a second vulnerability and exploit to get them administrative-level privileges to install their malicious code undeterred.
²⁴
But this exploit cut through layers of protection to let them install and execute malicious code at the kernel level of the machine without interference. Buffer-overflow vulnerabilities that could be exploited at the kernel level are rare and difficult to exploit without causing the machine to crash, but the Duqu exploit worked flawlessly. It was several orders of magnitude more sophisticated than the .LNK exploit Stuxnet had used. The .LNK exploit had been copied by cybercriminals in no time after Stuxnet was exposed in July 2010, but this one would take months before anyone would successfully replicate it.
²⁵

The exploit was notable in itself, but the attackers had also embedded a couple of Easter eggs in their code—perhaps to taunt victims. The name they gave the fake font that executed their attack was Dexter Regular, and in the copyright notice for the fake font they wrote—“Copyright © 2003 Showtime Inc. All rights reserved. Dexter Regular.”
²⁶

It was clear they were referencing the popular TV show
Dexter
, which was then airing on the Showtime network. But the show didn’t begin airing until October 1, 2006, which made the 2003 copyright date seem odd. It was unclear if the Easter egg had any meaning or if it was just a joke. But the reference did appear to have one parallel to Stuxnet. The Showtime series focused on Dexter Morgan, a forensic scientist and vigilante killer who only murdered criminals, making him a killer with a moral code—a murderer who killed for the sake of the greater societal good. At least that’s how Dexter saw it. Arguably, it was also the way the United States and Israel might have viewed the cyberattack on Iran, or the attacks on Iran’s nuclear scientists—as a means to a greater good.
²⁷

The font name and copyright date offered a bit of distraction for the researchers, but the more notable part of the dropper was its compilation date—February 21, 2008—providing a clue about how long Duqu might have been around. Not long after this dropper was found, Kaspersky got
its hands on a second one, found on a machine in Sudan, that had been compiled even earlier.
²⁸

Sudan had close military ties to Iran—it received $12 million worth of arms from Iran between 2004 and 2006—and was a vocal supporter of Iran’s nuclear program. In 2006, Iran had publicly vowed to share its nuclear expertise with Sudan. Sudan was also a target of UN sanctions. Duqu’s victim in Sudan was a trade services firm that had been infected in April 2011, four months before the infection in Hungary. The malicious code arrived via a phishing attack using the same Dexter zero-day exploit that was used in Hungary. The malicious e-mail, purporting to come from a marketing manager named B. Jason, came from a computer in South Korea, though the machine had likely been hacked to send the missive.
²⁹
“Dear Sir,” the e-mail read, “I found the details of your company on your website, and would like to establish business cooperation with your company. In the attached file, please see a list of requests.” The attached document contained a handful of survey questions as well as an image of a green Earth with plants sprouting from its top. When the victim opened the attachment, the Dexter exploit sprang into action and deposited its illicit cargo onto the victim’s machine.