03 Mar CODE BLUE in Tokyo Michael
18 Dec Destructive Malware – Five Wipers in the Spotlight Costin Raiu
14 Aug NSAccess Control Lists Roel
20 Mar South Korean 'Whois Team' attacks GReAT
15 Oct miniFlame aka SPE: "Elvis and his friends" GReAT
29 Aug What was that Wiper thing? GReAT
Join our blog
You can contribute to our blog if you have +100 points. Comment on articles and blogposts, and other users will rate your comments. You receive points for positive ratings.
On February 17th (MON) - 18th (TUE), 2014 we were at an event in Tokyo called “CODE BLUE”, a new international information security conference originating from Japan.
Even though this conference was being held for the first time, no less than 400 visitors attended, with people coming from about 10 different countries.
The overall atmosphere at the event was kind and friendly and everything seemed to go smooth and swiftly.
Topics on the first day were the keynote by Jeff Moss, followed by presentations about “The Current State of Automotive Security”, “A Security Barrier Device”, “Remote linux exploits” and hard-/software related hard disk matters.
For the Japanese speakers among you there’s a more detailed review of the event here.
Every single day, Kaspersky Lab processes more than 300,000 new malware samples. The vast majority of these malicious files is what we call crimeware -- computer programs designed for financial profit and used by cyber-criminals to make money. From the remaining percentage, a small amount are designed exclusively for cyber-espionage and used by a variety of advanced threat actors.
What is left is an even smaller percentage of the total and includes rare, unusual things. Wipers, which are highly destructive programs, are some of the rarest kinds of malware, however, their usage has spiked over the last few years.
Back in the old days, most of the malware was written by computer enthusiasts, cyber-hooligans and pranksters. Hence, destructive viruses, or Trojans, were much more common. Some examples include BadSectors, a computer virus that would mark disk sectors as bad, even if they weren’t, resulting in subtle corruption of data. Another example was OneHalf, a computer virus that would encrypt the hard drive cylinder-by-cylinder, transparently decrypting it on the fly while active. If one were to remove the virus,that would leave the data on the disk in encrypted format, without an easy way to decrypt it.
Perhaps the best known example is CIH, also known as Chernobyl. CIH, named after the initials of its author, Chen Ing-hau, was a computer virus that had the ability to wipe the BIOS flash memory. Computers affected by CIH couldn’t boot up anymore. This wasn’t a major problem for PCs, which had the BIOS memory in the form of a removal chip that could be reprogrammed on another system; however, for laptop owners, the CIH virus was quite destructive.
Over the last few years, we’ve seen a number of major incidents involving destructive malware. We’ve decided to put together a brief summary the most important Wiper incidents:
In late-2011, early-2012, reports emerged about computer systems that were compromised and rendered unbootable. The extent of the damage to these systems was so big that almost no data was recoverable. Some artefacts from the wiped systems indicated a possible link with Stuxnet and Duqu; however, these were never proven. The malware responsible for these attacks was named the "Wiper"; we wrote about it here.
Last week, I attended the International Conference on Cyber Security at Fordham University in NYC. This event brought together participants from government, the private sector and academia. The closing session was a panel featuring the directors of the CIA, FBI and NSA which drew a lot of attention.
FBI Director Robert Mueller speaking at the closing panel
Throughout the conference, there was a strong push for more cooperation internationally and between different sectors. While cooperation has come a long way, we still have a long way to go.
The topic of cyber-espionage didn't come up as much as I've been used to in recent times. Instead, there was more talk on cyber-sabotage with several presentations talking about this problem.
Earlier today, reports of a number of cyberattacks against various South Korean targets hit the news.
The attackers, going by the handle “Whois Team” left a number of messages during the defacements:
You can read our Full Technical Paper on SPE / miniFlame here.
In May 2012, a Kaspersky Lab investigation detected a new nation-state cyber-espionage malware, which we named "Flame". Our research also identified some distinguishing features of Flame’s modules. Based on those features, we discovered that in 2009, the first variant of the Stuxnet worm included a module that was created based on the Flame platform. This confirmed there was some form of collaboration between the groups that developed the Flame and Tilded (Stuxnet/Duqu) platforms.
A more in-depth research conducted in June 2012 resulted in the discovery of another nation state-sponsored and previously unknown malware which we named «Gauss». Gauss used a modular structure resembling that of Flame, a similar code base and system for communicating with command-and-control (C&C) servers, as well as numerous other similarities to Flame.
In partnership with Symantec, ITU-IMPACT and CERT-Bund/BSI, we also published our analysis of the Flame Command and Control servers. The analysis showed that the code can understand several communication protocols to talk to different «clients» or malware:
In April 2012, several stories were published about a mysterious malware attack shutting down computer systems at businesses throughout Iran.
Several articles mentioned that a virus named Wiper was responsible. Yet, no samples were available from these attacks, causing many to doubt the accuracy of these reports.
Following these incidents, the International Telecommunication Union (ITU) asked Kaspersky Lab to investigate the incidents and determine the potentially destructive impact of this new malware.
After several weeks of research, we failed to find any malware that shared any known properties with Wiper. However, we did discover the nation-state cyber-espionage campaign now known as Flame and later Gauss.
It is our firm opinion that Wiper was a separate strain of malware that was not Flame. Although Flame was a highly flexible attack platform, we did not see any evidence of very destructive behavior. Given the complexity of Flame, one would expect it to be used for long-term surveillance of targets instead of direct sabotage attacks on computer systems. Of course, it is possible that one of the last stages of the surveillance was the delivery of a Wiper-related payload, but so far we haven-t seen this anywhere.
It was not a closed-door event; we had guests from 13 countries of the region including our panelists from law enforcement agencies who work every day in the fight against cybercrime:
What is Gauss? Where does the name come from? Gauss is a complex cyber-espionage toolkit created by the same actors behind the Flame malware platform. It is highly modular and supports new functions which can be deployed remotely by the operators in the form of plugins. The currently known plugins perform the following functions:
The modules have internal names which appear to pay tribute to famous mathematicians and philosophers, such as Kurt Godel, Johann Carl Friedrich Gauss and Joseph-Louis Lagrange.The module named “Gauss” is the most important in the malware as it implements the data stealing capabilities and we have therefore named the malware toolkit by this most important component.
|Variant||Path to project files|
|Dec 2011-Jan 2012||c:\documents and settings\flamer\desktop\gauss_white_1|
The Flame inside StuxnetFirst of all, let’s recap the Stuxnet story. We managed to recover just three different variants of the worm, created in June 2009, and in March and April 2010. The March 2010 variant was responsible for the greatest number of infections and was detected in June 2010 by specialists from the company VirusBlokAda in Belarus. This particular version was subjected to the most detailed analysis by anti-malware companies. Shortly afterwards, when news of Stuxnet had already become widespread, files related to its June 2009 incarnation were detected. This version, the so-called Stuxnet.A (1.0), differed considerably from the 2010 variants. The main differences were:
The Tocy storyIn October 2010, our automatic system received a sample from the wild. It analyzed the file thoroughly and classified it as a new Stuxnet variant, Worm.Win32.Stuxnet.s. With Stuxnet being such a big thing, we looked at the sample to see what it was! Sadly, it didn’t look like Stuxnet at all, it was quite different. So we decided to rename it to Tocy.a and thought “silly automatic systems!”. When Flame was discovered in 2012, we started looking for older samples that we might have received. Between samples that looked almost identical to Flame, we found Tocy.a. Going through the sample processing system logs, we noticed it was originally classified as Stuxnet. We thought, how was it possible? Why did the system think that this Flame sample was related to Stuxnet? Checking the logs, we discovered that the Tocy.a, an early module of Flame, was actually similar to “resource 207” from Stuxnet. It was actually so similar, that it made our automatic system classify it as Stuxnet. Practically, Tocy.a was similar to Stuxnet alone and to no other sample from our collection. Going back to the story, this is how we discovered the incredible link between Flame and Stuxnet.
The Flame malware uses several methods to replicate itself. The most interesting one is the use of the Microsoft Windows Update service. This is implemented in Flame’s “SNACK”, “MUNCH” and “GADGET” modules. Being parts of Flame, these modules are easily reconfigurable. The behavior of these modules is controlled by Flame’s global registry, the database that contains thousands of configuration options.
SNACK: NBNS spoofingThe SNACK module creates a RAW network socket for either all or pre-set network interfaces and begins receiving all network packets. It looks for NBNS packets of other machines looking for local network names. When such a packet is received, it is written to an encrypted log file (“%windir%\temp\~DEB93D.tmp”) and passed on for further processing. When a name in the NBNS request matches the expression “wpad*” or “MSHOME-F3BE293C”, it responds with its own IP address. If “SNACK.USE_ATTACK_LIST” variable is set to “True”, it also checks whether packets originate from IP addresses specified in its “SNACK.ATTACK_LIST” and responds to machines with these addresses. “Wpad” is a name used for automatic proxy detection. By responding to “wpad” name requests with its own IP address, the SNACK module announces the infected machine as a proxy server for its local network. SNACK and MUNCH also communicate with the GADGET unit that provides facilities for handling different events that come from other modules. The Flame’s registry contains LUA modules for processing events like “MUNCH_ATTACKED”, “SNACK_ENTITY.ATTACK_NOW”.
MUNCH: Spoofing proxy detection and Windows Update request“MUNCH” is the name of the HTTP server module in Flame. It is started only if “MUNCH.SHOULD_RUN” variable is set to “True” and there are no running programs that can alert the victim. These programs (anti-virus, firewalls, network sniffers etc.) are defined in the Flame’s registry in a list called “SECURITY.BAD_PROGRAMS” When MUNCH is started, it reads a buffer from the “MUNCH.WPAD_DATA” variable, replaces the pattern “%%DEFAULT%%” with the IP address of its best suitable network interface and waits for HTTP requests.
So, when a machine configured with automatic proxy detection tries to access one of the Windows Update hosts, it receives an IP address of the infected machine from SNACK, and then receives the IP address of the same machine as a proxy server from “wpad.dat” provided by MUNCH. From then, requests to the Windows Update service are passed through the MUNCH server.When a network client connects to the MUNCH server and requests an URI other than “/wpad.dat” and “/ view.php”, the server : 1) Runs “MUNCH.SHOULD_ATTACK_SCRIPT” – Lua script that checks if the User-Agent header matches at least one of the patterns specified in “MUNCH.USER_AGENTS.CAB_PATTERN_*”. The Flame registry files that we have contained the following patterns: MUNCH.USER_AGENTS.CAB_PATTERN_4 : WinHttp%-Autoproxy%-Service.*