by Kim Zetter
The module didn’t resemble Stuxnet or Duqu and didn’t appear to be Wiper, either—it contained no code for erasing the hard drive of infected machines. They searched their archive to see if anything resembling it had come through their automated reporting system in the past, and to their surprise, module after module popped up, as if they’d just been sitting in the archive waiting to be discovered. They found twenty different files in all, each with odd names like Euphoria, Munch, Limbo, Frog, and Snack. The files all appeared to be plug-ins or components for a related attack.
What intrigued them most, however, was that one of the files had come in through their system in October 2010 and was tagged by the system as a Stuxnet file. At the time, this hadn’t made sense to them because when they had examined the file, it didn’t look anything like Stuxnet. But now when they examined it again they discovered what the two had in common—both files contained a zero-day exploit that they and Symantec had overlooked when they examined Stuxnet two years earlier.
The exploit had been embedded in a part of Stuxnet called Resource 207, which appeared only in the June 2009 version of the attack code, not the 2010 versions—which explained why they had overlooked it before. Most of the Stuxnet files Kaspersky and Symantec examined had come from the 2010 attacks. Very few samples of the 2009 variant had ever been found on infected machines.
Resource 207 contained the code that Stuxnet 2009 used to trick the Autorun feature in Windows machines to spread itself via USB flash drives. But it also contained this overlooked exploit that was now in the new attack code. The exploit gave the attackers escalated privileges on infected machines by exploiting a buffer-overflow vulnerability in the wallpaper feature of Windows. The vulnerability had been a zero day when the attackers created the exploit in February 2009, but by the time they released Stuxnet four months later that June, Microsoft had patched the hole.3 When it came time to release the next version of Stuxnet in March 2010, the attackers had eliminated this exploit, along with the Autorun code, and replaced it with the .LNK exploit and two other privilege-escalation exploits that were still zero days at the time.
The discovery of the wallpaper exploit meant that instead of four zero-day exploits—which was already an impressive record—Stuxnet had actually used five zero-day exploits during its lifetime. More important, though, the link between Stuxnet and this new attack provided further evidence that Stuxnet was part of a suite of malicious tools created by the same team.
KASPERSKY’S ALEX GOSTEV and his team divvied up the twenty modules they had found for this new attack and went to work reverse-engineering them to see how they were connected. They worked day and night, fueled by caffeine and the excitement of knowing they had just uncovered another tool in the Stuxnet arsenal.
At the end of three weeks, they had a digital spy kit on their hands that was larger than anything they had seen before. They dubbed it “Flame,” after the name of one of the main modules in the attack.4
Stuxnet had tipped the scales at 500 kilobytes when compressed, but Flame was at least 20 megabytes with all of its components combined, and consisted of more than 650,000 lines of code. It also had astounding complexity to match its girth. They estimated it would have taken a team of half a dozen programmers at least three years to code it all, and it would take the entire Kaspersky team years more to completely decipher it. Instead, they settled for deciphering just enough of the code to understand it.
The Kaspersky team had seen a lot of digital spy tools over the years—many of them believed to be nation-state tools from China—but this one rewrote the book. If James Bond’s Q Branch had a digital armory, Flame would have been part of it. It came with a cornucopia of spy gadgetry aimed at collecting intelligence from victims in a multitude of ways. Among them was one module that siphoned documents from infected machines, and another that recorded keystrokes and captured screenshots every fifteen to sixty seconds. A third module surreptitiously engaged an infected computer’s internal microphone to eavesdrop on conversations in its vicinity. A fourth module used the computer’s Bluetooth function to swipe data from any discoverable smartphones and other Bluetooth-enabled devices in the area.
Flame appeared to be a multipurpose espionage tool created to meet every need, depending on the mission. Not every victim got the full Flame treatment, though. Each component was installed as needed. A 6 MB starter kit got loaded onto many infected machines first, which included a back door through which the attackers could install new spy modules from their command server at will.5
The infrastructure set up to support Flame was also massive and like nothing the researchers had seen before. They found at least eighty domains operating as command servers in Germany, the Netherlands, Switzerland, and elsewhere through which the attackers controlled infected machines and collected siphoned documents from them.6 The attackers had likely set up so many domains in order to manage different operations and groups of victims separately.
They used various fake identities to register the domains—Ivan Blix, Paolo Calzaretta, Traian Lucescu—and purchased some of them with prepaid credit cards so they couldn’t be traced. The Kaspersky researchers got traffic for about thirty of the domains redirected to a sinkhole that they controlled, and as soon as it was set up, infected machines in Iran and around the world began calling in. Stolen files intended for the attackers also poured in, though the files were encrypted so the researchers weren’t able to see what the attackers were stealing.
After adding signatures for Flame to Kaspersky’s antivirus tools, infections showed up on several hundred machines. Iran, no surprise, was at the top of the list. At least 189 machines were infected there. But there were also 98 victims in the Palestinian Territories, and about 30 victims each in Sudan and Syria.
While Kaspersky was still examining Flame’s modules, Bencsáth in Hungary contacted Raiu with news of a suspicious file found in Iran that someone had sent him. They had become well acquainted with Bencsáth when they had worked on Duqu, so it wasn’t unusual for him to contact them. The file he had received from Iran turned out to be one of the same modules Raiu and his team had already been examining. Bencsáth also passed the file to Chien at Symantec, who began to examine the threat in parallel with Kaspersky. When the Symantec researchers added signatures to their antivirus engine to detect it, they uncovered more victims in Austria, Hungary, Lebanon, Russia, the United Arab Emirates, and Hong Kong.
More than 1,000 victims were eventually uncovered, many more than the 36 victims Duqu was known to have hit, although nowhere near the more than 100,000 machines that Stuxnet had struck. But that’s because unlike Stuxnet, Flame couldn’t spread automatically. All of its spreading mechanisms worked only when deployed and commanded by the attackers. So while the majority of Stuxnet’s victims were collateral damage, everyone Flame hit was presumably an intended target. Raiu suspected the victims were infected in groups, based on whatever mission the attackers were conducting at the time.
There was no discernable pattern to the pool of victims—Flame targeted individuals, private companies, government agencies, and academic institutions. But it wasn’t difficult to see what types of files the attackers were after, since the malware contained a list of file extensions it sought, including Microsoft Word documents, PowerPoint presentations, and Excel files. But also high on the list were AutoCAD drawings, which had been targeted by Duqu as well. Flame, notably, was also looking to steal digital certificates.
Although Flame had a long list of files it was seeking, it didn’t steal every file it found. Instead, it extracted 1 KB of text from each and transmitted it back to one of the command servers. From there it was likely passed to another location, where Raiu suspected the attackers had a supercomputer set up to sift through all the text samples that came in and determine which files the attackers wanted to grab in full. Notably, a year later when the NSA documents leaked by Edward Snowden were published, they described a system codenamed TURBINE that was designed to do something very sim
ilar to this. (See this page.)
With such an elaborate operation set up for Flame, it was no surprise that the attack had been around for a while. The earliest infection uncovered, on a machine in Europe, occurred in December 2007.7 A machine in Dubai was struck in April 2008. Some of the domains the attackers used for their command servers were also registered around this time. A handful of others were registered in 2009 and 2010, but the majority were registered in 2011, after Stuxnet was exposed. All of this meant that Flame had been active in the wild infecting systems for at least five years before it was discovered and was active during the same time that Stuxnet and Duqu were being developed and unleashed.
A clear picture was beginning to emerge of a digital arsenal filled with spy tools and weapons created to attack not just Iran’s nuclear program but other targets as well. Two separate platforms had been used to create the malicious code discovered so far. One was the Flame platform, upon which the massive Flame spy tool had been built. The other was the Tilde-d platform, upon which Duqu had been built. The Flame platform was much more dense and complex than the Tilde-d platform, and had therefore probably been created in parallel by a different team. Both platforms, however, were used to develop Stuxnet at various stages.
Raiu surmised that the development of Flame likely began in 2005 or 2006, due to the fact that some of the custom code the attackers wrote for their command servers had been developed in December 2006.8 Development of the spy tool likely reached maturity in early 2007. The earliest known dates for Duqu were August 2007, when one of Duqu’s droppers was compiled, and November 2008, when Duqu’s infostealer showed the first signs of being in the wild.
Raiu believed that when it came time to build Stuxnet, the attackers used Flame to jumpstart the digital weapon, then later switched to the Duqu platform for subsequent versions of the attack. He based this in part on the fact that Resource 207 found in the 2009 version of Stuxnet—which contained the Autorun code and the wallpaper exploit—looked a lot like an early version of Flame’s main module. Flame would have already existed as a basic espionage tool by 2007, and when it came time to write the missile portion of Stuxnet in 2009, it appeared that the team behind Flame shared source code for Resource 207 with the Stuxnet crew, essentially kick-starting the creation of the missile code. The payload was already created by then, and the attackers just needed something to deliver it. “Probably there was some kind of urgency to get [Stuxnet] out the door, so that’s why they took this already mature plug-in from Flame and used it in Stuxnet,” Raiu says.
After this, however, Stuxnet and Flame diverged. The programmers behind Flame continued to build their platform into a massive espionage tool, and in 2010 when the attackers behind Stuxnet prepared the next version of their code for a subsequent assault, they switched to the Tilde-d platform—which had already been used to create Duqu—to recraft the missile for launching their attack. The switch to the Duqu platform likely occurred because the missile portion of the variant Stuxnet 2010, with all of its zero-day exploits and additional spreading mechanisms, was much more complicated and required more code. And the Tilde-d platform was a much simpler and more compact tool to use.
The sequence of events determined by Raiu and his team seemed to match the scenario depicted by New York Times reporter David Sanger, who reported in his book Confront and Conceal, citing current and former government officials, that the earliest version of Stuxnet was developed by the United States, while later versions were developed by the United States and Israel. Raiu believed that Flame and the Flame platform were created by the United States, while Israel created Duqu and the Tilde-d platform. Both then used their respective platforms to build their portions of Stuxnet.
Whatever Flame’s role in Stuxnet, the whole spy operation around it came crashing down on May 28, 2012, when Kaspersky and Symantec went public with news of its discovery in near-simultaneous announcements.9 Once news of the spy tool was out, the response of Flame’s operators was swift. Within an hour of the first news stories being published, command servers used for the spy tool went dark as the attackers shuttered their operation, thus ending a massively successful five-year espionage campaign in a matter of minutes. It was almost as if they had been waiting for the news to break.
Flame’s reign was now over, but its effects would live on. Days after the servers went dark, Microsoft announced that it had found an even more disturbing discovery about the Flame attack that the Kaspersky and Symantec researchers had missed.
IT WAS THE Memorial Day holiday in the United States when news of Flame broke, and not many people at Microsoft headquarters in Redmond, Washington, were working. But when engineers in the company’s Security Response Center learned that a new attack campaign, attributed to the same team behind Stuxnet and Duqu, had been uncovered, they immediately grabbed samples of the Flame files made available by researchers. They wanted to see if the new attack used any zero-day vulnerabilities in Windows, as Stuxnet and Duqu had done. But as they examined one of the files they received, they realized they were looking at something much worse than a zero day—Flame was performing a sophisticated attack against part of Microsoft’s Windows Update system to spread itself between machines on a local network.
Windows Update is the automated system Microsoft uses to distribute software updates and security patches to millions of customers. To obtain the updates, a client-side tool sits on each customer machine and contacts the Microsoft servers to download patches whenever they’re available.
For years, the security community had warned of the security nightmare that would occur if hackers ever hijacked the Windows Update system to deliver malicious code, threatening the security of millions of Windows customers. This attack didn’t rise to that level exactly, but it was just as dangerous. Instead of subverting the actual Microsoft servers that delivered Windows software updates to millions of customers, it subverted the Windows Update tool that sat on customer machines. The distinction was subtle but important. If the attackers had subverted Microsoft’s servers, they could have compromised machines on a global scale. But the way they performed the attack meant they could compromise machines only on specific networks that they targeted, leaving anyone else unaffected.
Like the Windows software, the update tool itself gets periodically updated by Microsoft. Each time the tool launches on a customer’s machine, it sends out a kind of beacon to Microsoft servers to see if a new version of itself is available. Microsoft distributes the updates through a series of so-called .CAB files, signed with a Microsoft certificate to verify their legitimacy.
The attackers subverted this process by first infecting one machine on a victim’s network with Flame. Then when the update client on any other machine on that victim’s network sent out a beacon to Microsoft servers to check for updates to the Windows Update tool, the infected machine intercepted the beacon and sent a malicious Flame file, masquerading as a legitimate Microsoft .CAB file, to the new machine instead, thus infecting it with the spy tool. This wasn’t the most sophisticated part of the attack, however. To pull off the hijack, the attackers had signed their malicious .CAB file with a legitimate Microsoft certificate—except in this case the certificate indicated that the company it belonged to was “MS,” not Microsoft Corporation, as it should have said. When Microsoft’s research team saw this, they immediately suspected something was wrong. The certificate appeared to have been issued and signed by Microsoft’s Terminal Services Licensing Certificate Authority in February 2010, but it was clearly a rogue certificate, which the CA should not have generated and signed. Had Microsoft’s server been compromised or its cert-signing key stolen? The engineers had to quickly figure out how the attackers obtained the cert before anyone else could repeat the feat. They put out a call for any colleagues available to work on the holiday and quickly assembled a team.
It turned out the attackers had pulled this off using something called an MD5 hash collision. An MD5 hash is a cryptographic representation of data—in
this case the data on the certificate—generated by a cryptographic algorithm known as MD5. Hashes are supposed to function like a fingerprint, so that every data set run through the algorithm produced a unique hash. If the data changed, the algorithm would produce a different hash. The MD5 algorithm, however, had been found years earlier to have a weakness that would allow someone to create the same hash from different data sets.10 This was called a hash collision. Many companies had stopped using the MD5 algorithm for this reason. But Microsoft hadn’t changed the algorithm used for its Terminal Services (TS) Licensing service since 1999, when the system was architected.
TS Licensing is a system used by Microsoft corporate customers when setting up a server with Microsoft software running on it so that multiple employees or machines can use the software. The customer purchases licenses from Microsoft—say 100 licenses for 100 employees or machines—then submits a request for a certificate to Microsoft’s Terminal Services Licensing Certificate Authority. Microsoft’s CA generates a certificate with the customer’s name on it, as well as a timestamp indicating when the certificate was issued and a serial number for the digital document.
When Microsoft issues the certificate, it runs all of the data on the certificate, including the timestamp and serial number, through the MD5 algorithm to create a hash, then signs the hash and sends the cert to the customer. The customer then uses the signed certificate to ensure that only authorized machines or people issued the certificate use the software licensed from Microsoft. But in this case, the attackers used the hash from Microsoft to sign their rogue certificate and then to sign their malicious .CAB files.
Before the attackers submitted their certificate request to Microsoft, they created a rogue certificate that contained information that they anticipated the real Microsoft certificate would contain, as well as some minor alterations—alterations that they had to be sure would produce a hash that was identical to the one Microsoft would issue. This was no easy task. Among other challenges, it required running thousands and thousands of different variations of the data on their rogue certificate through the MD5 algorithm to get one that produced an identical bit-for-bit hash as the legitimate Microsoft certificate that contained different data, a feat that required a lot of computational power. It also required anticipating the serial number that Microsoft would give the certificate and the exact time when Microsoft’s licensing server would sign the legitimate certificate, since the timestamp and serial number were part of the hash that Microsoft generates and signs.11 If they estimated the wrong time by even a millisecond, the signed hash would not be transferable to their rogue certificate, since the two hashes would no longer match.12 The attackers would have needed to research the Microsoft system extensively and test multiple certificates—possibly hundreds—before they got the timing and serial number right.13