by Kim Zetter
The attackers then used the signed hash with their rogue certificate to sign their malicious .CAB files. It appeared to be a legitimate certificate, since it had the signed hash generated by Microsoft.
The Windows Update hijack was a brilliant feat that pushed the boundaries of mathematics and could only have been achieved by world-class cryptographers.14 When the Kaspersky researchers learned of it, they dubbed it the “God-mode exploit,” since it was so technically astute and so much more potent than spreading malware via a zero-day exploit.15 The only thing that would have made it more powerful and dangerous was if the attackers had actually subverted the Windows Update patch servers themselves.
Microsoft’s engineers initially estimated it would take just twelve days for other well-resourced attackers to learn everything they needed to know about Microsoft’s certificate and update system to pull off a copycat attack to spread their own malware. But when they did a test run, walking through all the steps someone would need to take to copy the Windows Update hijack, and timed themselves while doing it, they realized that someone could actually pull off a less-sophisticated version of the attack—one that didn’t require an MD5 hash collision—in just three days.16
Working against the clock, Microsoft rushed out an emergency out-of-band patch to fix the vulnerabilities that allowed the attack to occur. The company had released only one out-of-band patch in all of 2011, the previous year, and reserved such releases for only the most significant vulnerabilities, so it was an indication of just how seriously Microsoft viewed the Flame exploit that it took this step.
The attackers behind Duqu and Stuxnet had already struck at the underpinnings of the validation system that made the internet possible—first by stealing individual security certificates from the companies in Taiwan to sign the Stuxnet drivers, then by sending Duqu to steal data from a certificate authority itself. But this exploit went even further than that by subverting the trust between the world’s biggest software maker and its customers. Assuming that the perpetrators behind it were American, they likely justified the operation and even got legal approval for it by arguing that they weren’t subverting the Microsoft Windows servers themselves—thereby putting all of Microsoft’s customers at risk—but simply subverting the Windows client on individual customer machines. In this way, they could focus the attack on victims and machines that weren’t in the States.17
But ultimately it mattered little that they hadn’t subverted Microsoft’s servers. Subverting the update client tool was enough to create customer mistrust in the integrity of the update service itself—which could lead users to disable the tool and prevent them from receiving the security updates that were critical for the safety of their systems.
Who was responsible for threatening this trust between Microsoft and its customers? About three weeks after the news of Flame broke, former US government officials claimed ownership, telling the Washington Post that Flame had been a joint operation between the NSA, the CIA, and Israel’s military.18
The unnamed sources said Flame had been developed sometime around 2007—confirming the general timeframe Raiu and his team had established for it—to collect intelligence about Iranian officials and to map computer systems that were part of Iran’s nuclear program. But the officials also suggested that Flame had been an early-generation tool that had since been surpassed by others.
“This is about preparing the battlefield for another type of covert action,” a former US intelligence official told the paper, adding that cyber collection against the Iranian program was “way further down the road than this.” He may have been referring to things like the implants the NSA uses that can transmit stolen data via radio waves from infected machines. (See this page.)
Notably, the Post’s sources also cleared up a mystery about the Wiper attack that had struck Iran earlier that year. They told the paper that the attack, which had erased hard drives on machines at Iran’s oil ministry and had led to the discovery of Flame, was also a nation-state construct. But unlike Flame and Stuxnet, which had been joint operations of Israel and the United States, Wiper, one source said, had been launched against Iran by Israel alone. An official told the Post, in fact, that the United States had been caught off guard by the destructive attack.
THE REVELATIONS ABOUT nation-state attacks were coming at a rapid pace now, with one operation after another being exposed, after years of remaining stealth. And the revelations weren’t done yet. The Kaspersky researchers would soon find evidence that still more malicious tools created by the same teams were lurking in the wild.
The key break came for them when they obtained access to some of the command servers used by Flame. They discovered that ten days before the news of Flame broke, the attackers had launched a massive cleanup campaign to cover their tracks and erase any trace of their activity from the servers, suggesting further that, indeed, the attackers had had advance notice that their operation was about to be exposed.19 But they had made one big mistake that left a server in Malaysia with its data largely intact. Several weeks before the cleanup operation, the attackers had carelessly changed the settings on the server and inadvertently locked themselves out. As a result, they weren’t able to get back in to wipe it clean, leaving a wealth of forensic data for Kaspersky to find.20
Left intact was the control panel the attackers had used to deliver the Flame modules to infected machines and to process stolen data retrieved from them. The control panel was designed to resemble a publishing platform for a business called NewsforYou, so that if any outsiders got access to the server, they’d think it belonged to a newspaper or media company. Malicious modules the attackers planned to install on victim machines were stored in directories the attackers named “News” and “Ads,” while a directory called “Entries” stored the data and files that were swiped from victim machines.
The Kaspersky researchers also found logs listing the IP address of every infected machine that had contacted the server. The server had only recently been set up, on March 25, but during a ten-day span of its operation, at least 5,377 infected machines in dozens of countries had contacted it. About 3,702 of these were in Iran, and another 1,280 in Sudan. Other countries had fewer than 100 infections.
Raiu and his team realized that if just one command server, out of more than eighty the attackers had registered, communicated with 5,000 infected machines in just ten days, and the malware had been in the wild since 2007 or 2008, the total number of victims had to be tens of thousands more than they originally calculated. They also found a file on the Malaysian server that was stuffed with 5.7 GB of data stolen from victim machines during the same ten-day period. If the attackers had purloined this much data in just ten days, Raiu suspected their total booty must have amounted to terabytes of data over the five-plus years that Flame had operated.21
But these revelations paled in comparison to another piece of evidence the Flame engineers left behind, which showed that the Malaysian server was configured to communicate with not just one piece of malware, but four. They were identified by the attackers as SP, SPE, FL, and IP, and had been created in that order, with SP being the oldest. Each of them was designed to communicate with the command server using a different custom protocol the attackers had written.22
FL referred to Flame, but the other three attack codes were a mystery. The Kaspersky researchers knew for certain that SPE existed, because they had seen evidence of it in the wild. When they had created their sinkhole to intercept data headed for the Flame servers, about ninety machines in Lebanon, Iran, and France infected with the SPE code had contacted their sinkhole thousands of times attempting to communicate with it using that code’s specific protocol. The other two malicious programs had yet to turn up, though. They hadn’t been able to obtain a copy of SPE, so they still didn’t know what it did.
But all of this confirmed that as shocking as the revelations about Stuxnet, Duqu, and Flame were, they likely were just the shallow tip of a stockpile of tools and weapons the
United States and Israel had built.
Indeed, a couple of weeks after the news of Flame broke, Kaspersky stumbled upon yet another nation-state spy tool that had evaded detection for years.
Every time Raiu’s team discovered new files or a little more information about Stuxnet, Flame, or Duqu, they would refine the signatures in their antivirus products and tweak the search terms they used to dig through their archive to see if they could find other variants of the same files. During one search of their archive, they found a suspicious file that had come in through their automated reporting system from a customer machine in the Middle East. The file had been flagged by the system as a Flame module and communicated with the same command-and-control servers as Flame. But it clearly wasn’t Flame or any of the other three mysterious programs—SP, SPE, or IP.
They added signatures for the file to their antivirus engine and found about 2,500 victims infected with it in twenty-five countries. More than 1,600 of the victims were in Lebanon. The next highest number, 482, were in Israel, and another 261 were in the Palestinian Territories. About 40 victims were in the United States, and only 1 was in Iran.
As they reverse-engineered the code and began to analyze it, they saw that it contained some of the same libraries, algorithms, and base code that Flame contained, which explained why their system had flagged it as such. The coders had even left path and project data in some of the files, which showed that the files had been stored on the attackers’ machines in a directory they had called Flamer.23
The Kaspersky researchers dubbed this new attack “Gauss,” after the name the attackers had given one of its main modules. The name appeared to pay tribute to noted mathematician Johann Carl Friedrich Gauss—since other modules were named Lagrange and Gödel, apparently after mathematician Joseph-Louis Lagrange and cryptographer Kurt Gödel. The reverence for math and cryptography became clear when the researchers discovered that the attack had a payload that used a highly complex and sophisticated encryption scheme worthy of a master cryptographer.
Like Flame, this new mystery malware was an espionage tool, but it was much smaller than Flame and was clearly part of a separate spy operation. The malware contained a handful of modules for stealing system passwords, recording configuration data, and swiping login credentials for social networking, e-mail, and instant-messaging accounts. There was also a module for infecting USB flash drives with the same .LNK exploit Stuxnet had used.
But there was something else the new attack had that the researchers had never seen in a nation-state tool before—a Trojan program for stealing login credentials to bank accounts. This wasn’t a run-of-the-mill banking Trojan, though. Rather, it focused on customers of banks in Lebanon—the Bank of Beirut, EBLF, BlomBank, ByblosBank, FransaBank, and Credit Libanais. There was no sign the Trojan was being used to steal money from the accounts, but some of Lebanon’s banks were suspected of being used to launder funds for Iran’s nuclear program and for the Iranian-backed Hezbollah, so the attackers may have been monitoring balances and transactions to map relationships between accounts and trace the movement of money.
There were two mysteries with the code that the researchers couldn’t resolve—one involved a custom font file the attackers called Palida Narrow that Gauss installed on infected machines. Like Duqu’s Dexter Regular, Palida Narrow was a fabricated font name. But unlike Duqu, the Palida Narrow file contained no exploit or malicious code. In fact, it appeared to have no functionality at all so the researchers were clueless as to why the attackers installed it.24
But a bigger mystery lay in an encrypted payload that Gauss deposited onto some machines, which was locked in an impenetrable shell.
Unlike Stuxnet, which delivered its payload to every machine it infected but executed the payload only on machines with a specific configuration, Gauss only delivered its payload to machines that had a specific configuration. It seemed the attackers had learned from mistakes made with Stuxnet. By limiting the number of machines to which they spread the Gauss payload, they greatly reduced the chance that it would be discovered.
Gauss delivered its warhead in a very restricted manner via USB flash drives. It would infect only one USB flash drive inserted into an infected machine and no more. When that flash drive then got inserted into another machine, it passed the payload to the machine only if the machine had the specific configuration Gauss was seeking. It also collected the configuration data from any machine it entered and stored it on the USB flash drive in a hidden file. If the flash drive was inserted into any other machine that was infected with Gauss and that was also connected to the internet, Gauss transmitted the hidden file back to the attackers’ command server. In this way, the attackers would know when Gauss had reached its target.
Gauss also took another precaution with its payload. Unlike Stuxnet, the keys for unlocking this mysterious payload were not stored in the malware. Instead, the warhead could only be decrypted with a key that was dynamically generated from the configuration data on the machine it was targeting.
But to generate the key, the malware went through a series of elaborate contortions to ensure that it wouldn’t unload on the wrong machine and that no one would be able to unlock it using brute force. First it collected very specific configuration data from the targeted machine—information about directories, program files, and other resident data—then combined the names of each file, one by one, with the name of the top directory in the Windows Program Files folder on the machine. To this string of data it added a special value, then ran it through the MD5 hash algorithm 10,000 times, rehashing the resulting hash to produce a new hash each time.25 If, at the end, it generated the correct hash it was seeking, the malware proceeded to the next step.
Even when Gauss arrived at the hash it was seeking, it didn’t immediately unlock the payload. Instead, it recalculated the 10,000th hash using a different added value. The hash from this operation then became the key that unlocked the warhead. Once the payload was unlocked, Gauss used the same path and program data that produced the very first hash, added yet a new value to it, then decrypted a second section in the attack code, before repeating the same steps to decrypt yet a third section.
If you were trying to run an exceptionally careful and controlled operation, this was the way to do it. Stuxnet’s payload had hardly been secured at all by comparison, allowing researchers to easily unlock it and determine what it was doing. But the complex encryption scheme used for Gauss’s payload ensured that the warhead remained locked in an impenetrable vault that no one could break.
Indeed, although the Kaspersky researchers tried millions of data pairings to uncover the configuration that unlocked Gauss’s payload, they were unable to produce a key that could crack it. They had to wonder what was so special about Gauss’s payload that the attackers had gone to so much trouble to secure it. They couldn’t rule out the possibility that it was something destructive like Stuxnet or Wiper or that it was extra-sensitive because it had something to do with Gauss’s banking Trojan and financial networks.
Gauss’s locked payload prevented the researchers from fully deciphering the attack, but in the course of analyzing this threat, they stumbled upon another find that had eluded them until then: a sample of the mysterious SPE malware.
SPE was one of the four programs that communicated with Flame’s command servers and that had contacted their Flame sinkhole months earlier. They discovered that it was actually a standalone module, instead of another attack entirely, that could be used either on its own or in conjunction with Flame or Gauss to expand the spying powers of either of these tools.26 The module, which Kaspersky dubbed “mini-Flame,” was the first direct link they found that connected Gauss and Flame. Previously they had believed the two attacks were entirely separate operations run by the same attackers, but mini-Flame proved otherwise. Kaspersky even found one machine in Lebanon that was infected with all three programs—Flame, Gauss, and mini-Flame.27
This junior Flame opened a back door onto infe
cted computers and also operated as an infostealer, allowing the attackers to remotely examine the configuration of machines and map any other systems connected to them. The attackers likely first infected a system with Flame or Gauss to collect basic intelligence about it and determine if it was a high-value target, then installed mini-Flame only on key machines belonging to high-profile victims when they needed to directly control the machine, swipe specific data from it, or further explore the victim’s local network. Once mini-Flame was installed, the attackers likely sent out a module from their command servers to delete the larger Flame spy kit from the machine and thereby reduce their footprint.
Kaspersky found only about fifty victims infected with mini-Flame, located primarily in Iran and other parts of the Middle East, but also in Lithuania and the United States. Among the victims, they found six different variants of the module, all created between October 2010 and September 2011. But the development of the first mini-Flame module likely occurred in 2007, when Stuxnet, Duqu, and the larger Flame were created, since this is when the protocol that mini-Flame used to communicate with command servers was created. Oddly, though mini-Flame communicated with Kaspersky’s sinkhole some 14,000 times over a four-month period in the summer of 2012, it completely halted communication with the sinkhole between July 4–7 of that year—a gap that Kaspersky could never explain.
