Antivirus Protection & Internet Security Software
Middle East & Africa
For all other countries:Close
visit our Global Website
visit our Global Website
Our November post introducing our BlackEnergy2 (BE2) research described new findings on the group's activity. We presented both details on their plugins and significant findings about some of their targets and victims. In this post, let's examine several additional plugins more closely, targeting details around BE2 Siemens exploitation, and some of their unusual coding failures.
We previously introduced an unknown set of plugins and functionality for the linux platform, six in total. For the windows platform, we collected 17 plugins. The last post noted the difficulty in collecting on this group. We finish descriptions for our set in this post.
We also collected plugins for the MIPS/ARM architectures, as noted in the previous BE2 post.
Let's first examine some of the newest and most surprising Windows plugins. It's interesting that all of these plugins use a custom "FindByHash" function to evade detection schemes and to slow analysis...The "Destroy" plugin, dstr Name dstr.dll MD5 8a0a9166cd1bc665d965575d32dfa972 Type Win32 DLL Size 26,474 bytes CompiledOn 2014.06.17 08:42:43
The most troubling plugin in the list is the "dstr" plugin. It is a Windows-only plugin. It was used to overwrite data by the BE2 actor, destroying data stored on hard drives by overwriting file contents. While its use may be intended to cover their tracks, it is heavy handed to use this type of tool to cover one's tracks in a network. Most likely it is a tool of sabotage, much like the Destover wiper seen on Sony Pictures Entertainment's networks. However, it's interesting that the BE2 developers created wiper code different from the Destover and Shamoon wiper malware we saw in the Saudi Aramco and SPE attacks. Instead of re-using the commercial EldoS RawDisk drivers in their malware, the BE2 developers wrote their own low-level disk and file destruction routines. It's also a much more chilling deployment of wipers - instead of a poorly defended media studio, it was delivered to ICS environments.
In order to overwrite stored data on all Windows versions, the dstr plugin supports both user-mode and kernel-mode wiper functionality, which is somewhat surprising. The component maintains both an embedded win32 library and win64 driver modules for its kernel mode functionality. They are rc4 encrypted.
The plugin identifies device id's for the system's HDD and creates a handle to the system's physical drive, with "GENERIC_READ or GENERIC_WRITE" access. Several calls to DeviceIoControl collects data on the physical location of the volume, and the size and properties of this disk. It uses DeviceIoControl with the IOCTL_DISK_GET_DRIVE_GEOMETRY control code in order to retrieve Bytes Per Sector value. dstr then wipes out all open handles to the disk by dismounting it with the FSCTL_DISMOUNT_VOLUME control code.
This routine prepares the system for overwrite and ensures no conflicts for plugin file I/O. Then it makes multiple WriteFile calls to write a zeroed out buffer to disk.
The dstr plugin maintains code for unlocking and deleting the BE2 driver from disk, furthering the group's goal of keeping their traces hidden from researchers. And notice the FindByHash set of calls above, this sfc_os call disables Windows File Protection for a minute while an application can delete or modify the locked file. So this plugin and its call can proceed and delete the driver.
The plugin looks over all the services in the %system32%\drivers folder and checks the write permission. If access is provided, it unlocks the file, rewrites the embedded driver under the existing driver name and launches it.
Drivers and kernel mode functionality
Decrypted 32-bit driverName driver.sys MD5 c4426555b1f04ea7f2e71cf18b0e5b6c Type Win32 driver Size 5,120 bytes CompiledOn 2014.06.10 13:12:22 GMT
Decrypted 64-bit driverName driver.sys MD5 2cde6f8423e5c01da27316a9d1fe8510 Type Win64 driver Size 9,136 bytes CompiledOn 2014.06.10 13:12:04 GMT
The 32-bit and 64-bit drivers are identical and compiled from the same source code. These small Windows drivers are supposed to support FAT32 and NTFS file systems, and contain two large code implementation mistakes. In spite of these flaws, it is clear that the author's goal was to parse a file system and then write random data across files.Extraordinary Fails
These coding fails are unique to this dstr plugin, suggesting a development team effort behind the plugin set code.
Fail #1: The authors reversed the routines for FAT32 and NTFS data wiping when checking the presence of the "FAT32" string in the first 1024-bytes of the system drive.
Fail #2: In the FAT32 routine the Root Directory Sector Number is calculated and is dealt as the absolute offset inside the file rather than next multiplying this number by the bytes per sector
In comparison, there is no such mistake in the NTFS routine and the calculation of the MFT offset is implemented properly:
Apart from that, it is interesting that the authors implement NTFS wiping in an unusual way with strange logic compared to FAT32 'straightforward' wiping. The plugin accomplishes checks for FILE records and at first skips them. Then under certain conditions it rewrites non-FILE record sectors with random buffer which probably corresponds to some file contents and proceeds looping. Then it ends up rewriting the first sectors of MFT and MFT mirror.
This plugin creates a backup communications channel to yet another legitimate service. Most likely this backup channel is used to cloak outbound communications on monitored networks. We have seen APT using everything from Twitter to Google Docs to hide communications in plain sight, and this time the abused service is Google Plus.
This plugin implements the standard Windows HTTP services to interact with Google Plus over https, seeking to find a png file.
The plugin is provided with a specific Google Plus id to connect with, and uses the OLE stream Windows structured storage API along with the GDI+ bitmap functions to handle and parse this png file. This png file content is actually encrypted data containing the new BE configuration file just as it was obtained using 'normal' C&C communication. It is encrypted with RC4, just like the embedded dstr drivers. But unlike to the 'typical' RC4 BE decryption scheme that uses RC4 once, here it uses RC4 three times: once with hardcoded key found in the grc binary, the second time using the key extracted from the previous decrypted result, and the third time using the 'id' machine's identifier that is normally served as the encryption key during the C&C communication.Universal serial bus data collection plugin, usb Name usb.dll MD5 0d4de21a2140f0ca3670e406c4a3b6a9 Type Win32 DLL Size 34,816 bytes CompiledOn 2014.03.21 07:02:48
The usb plugin collects all available information on connected USB drives, and writes out all of these details to a text file, packs it, provides to the main BlackEnergy code, which communicates to a c2.
It uses multiple api calls to collect information on multiple types of connected usb storage devices. It enumerates all usb storage devices connected to the system and retrieves data from all, including SCSI mass storage devices. And, most interestingly, it may be the first implementation of BadUSB-related techniques in APT re-purposed COTS malware that we have seen in the wild.
The code queries scsi devices directly and sends them two types of SCSI commands. The first command with the opcode 0x1A which corresponds to MODE SENSE may result just in the logging of the failed call ('SendSCSICommand return false' message).
The second type of SCSI command remains mysterious. It uses undefined opcode 0xf0 and there is no direct evidence of its purpose as it is stated to be vendor specific. This mysterious opcode is referenced around the same time frame of the plugin development in BadUSB offensive research http://algorithmics.bu.edu/twiki/bin/view/EC521/SectionA1/Group5FinalReport. Here, it is noticed in the USB traffic generated by an SMI controller tool. To be specific, there are two calls with the opcode 0xf0 in the code, each passed its own parameters. One of the parameters, 0x2A, is mentioned in the paper to return the string containing the firmware version, NAND flash ID, and controller part number. But this returned information is not logged anywhere.
Also the code loops to retrieve detailed physical data about every attached storage device:
The bios plugin gathers low level host system information:
It uses several techniques to gather this information:
As a Windows Management Instrumentation (WMI) client application, it initializes COM and connects to the \\root\cimv2 namespace to use the IWbemServices pointer and make WMI requests. The code executes wql queries ("wql" is "sql for wmi", a subset of sql) to gather victim host details, like the query "SELECT Description, Manufacturer, Name, ProcessorId FROM Win32_Processor". Here are several queries from the BlackEnergy2 plugin code:
These wql calls provide the attacker with the data like the lines below:
Description=Intel64 Family 6 Model 60 Stepping 3
Name=Intel(R) Core(TM) i7-4710MQ CPU @ 2.50GHz
Name=Microsoft Windows 8.1 Pro
This selectivity is fairly usual. And the plugin does not modify its own behavior based the collected values. What can we infer about the selection of only these values, as they are only being collected and sent back to the attackers? Here are some possibilities:
When using standard win32 api, the application implements calls to retrieve information on system locales. Oddly, there is special handling for one nordic locale in this particular plugin, "Norwegian-Nynorsk".
The CPU data collection functionality first calls the Intel cpuid instruction directly. It also directly handles multi-cpu systems and each of their feature sets. This SMP support is hard coded into the plugin.Additional BE2 Siemens Exploitation Details
Targeting details for BE2 actor events are interesting. When focusing on research sites and energy engineering facilities, the group remotely exploited Siemens' Simatic WinCC systems. In these events, the attackers attempted to force the ccprojectmgr.exe process to download and execute a specific BlackEnergy2 payload. Let's examine a couple of example targets here. Based on the different delays for return, the attacks were possibly not automated.
The first exploit attempt ksn recorded was March 2014. The attackers returned with a second failed attempt to exploit that same research system on April 2014, approximately 30 days, 2 hours later.
The BE2 actor then attacked a new target system in May 2014 and failed, and returned with an exploit attempt on that same system in July 2014.
So it looks like there may be a timing cycle to their visits, but the volumes here are too low to be significant.
In all four of these attempts on two different targets, the attackers tried to download their payload from hxxp://94.185.85(dot)122/favicon.ico. The payload changed slightly from March 2014 to the very end of July 2014, presenting the following md5(s). All of these droppers are BE2 malware, modify an existing kernel driver service like "ACPIEC" and start it to load the BE2 kernel module. Note that the attackers planned on re-using the same c2 for the first target, but changed the callback c2 for the second target. None of these components are signed:
fda6f18cf72e479570e8205b0103a0d3 → drops df84ff928709401c8ad44f322ec91392, driver, debug string:"xxxxxxxx.pdb". C2: 188.8.131.52 (DE, Hetzner Online AG, AS24940)
fe6295c647e40f8481a16a14c1dfb222 → drops 39835e790f8d9421d0a6279398bb76dc, driver, debug string:"xxxxxxxx.pdb". C2: 184.108.40.206 (DE, Hetzner Online AG, AS24940)
ac1a265be63be7122b94c63aabcc9a66 → drops b973daa1510b6d8e4adea3fb7af05870, driver. C2: 220.127.116.11 (SE, Internetport Sweden AB, AS49770)
8e42fd3f9d5aac43d69ca740feb38f97 → drops f4b9eb3ddcab6fd5d88d188bc682d21d, driver. C2: 18.104.22.168 (DE, Leaseweb Germany GmbH, AS16265)
The Desert Falcons are a new group of Cyber Mercenaries operating in the Middle East and carrying out Cyber Espionage across that region. The group uses an arsenal of homemade malware tools and techniques to execute and conceal its campaigns on PC and Mobile OS.
#FalconsAPT is the 1st known campaign to be fully developed by Arabic #hackers to target the Middle East #TheSAS2015Tweet
The first Desert Falcons operations were seen in 2011 and the group made its first infections in 2013. By the end of 2014 and beginning of 2015 the group was very active.Full report
The full report can be found here.FAQ Where are the Victims Located?
There are more than 3,000 victims in 50+ countries. Most of them are found in Palestine, Egypt, Israel and Jordan, but others have been discovered in Saudi Arabia, the UAE, the US, South Korea, Morocco, Qatar and others.
The attacks targeted several classes of victim, including Military and Government organizations, employees responsible for health organizations, combating money laundering, economic and financial institutions, leading media entities, research and educational institutions, energy and utilities providers, activists and political leaders, physical security companies and other targets that have access to important geopolitical information.
Malware writers use a variety of technical and social engineering methods to deliver their files and encourage victims to run them, creating an effective infection vector. Examples include a fake website that promises to publish censored political information and asks users to download a plugin to view a video (the plugin contains the malware). Another example involves the use of spear phishing emails or social network messages to deliver malicious files using an extension override (e.g. malicious files ending with .fdp.scr would appear .rcs.pdf).
Sample of documents and videos used in spear phishingWhat are the goals of the operations?
The attackers are looking for sensitive intelligence information that could help them in further operations or even extortion. The victims are targeted for the secrets in their possession or intelligence information relating to their positions in governments or important organizations.
More than 1 million files were stolen from victims. Stolen files include diplomatic communications from embassies, military plans and documents, financial documents, VIP and Media contact lists and files.
The Desert Falcons operators are native Arabic speakers. There are about 30 of them working in three teams. Some of their identities are already known. The attackers are running three campaigns to target different types of victim.Where are the attackers based?
The attackers are based in Palestine, Egypt and Turkey.Which malware do they use to infect their victims?
There are three main backdoors used to infect victim devices:
Computer Backdoors give the attackers full scope to use keyloggers and screenshotters, access files and even make audio recordings. DHS naming is used by the attackers to describe the nickname initials of one of the developers (D** H*** Spyware).
We became aware of the threat during an incident investigation in the Middle East.Is it still active?
The operation is very active and is currently in peak condition. We are continuously identifying new samples and victims for all related campaigns.How is this different from any other Cyber espionage attacks?
Desert Falcons are the first known Cyber espionage attacks to be fully developed and operated by Arabic speakers to target the Middle East. It has affected a stunning range of victims, stealing more than 1 million special files.Is this a nation-state sponsored attack?
The profiles of the targeted victims and the apparent political motives behind the attacks make it possible that Desert Falcons operations could be nation state sponsored. At present, though, this cannot be confirmed.Why this name?
The falcon is a rare bird that has been highly prized for a centuries in desert countries in the Arab world. It is a symbol of hunting and sharp vision. The Desert Falcons are proficient cyberhunters with carefully chosen targets, all of whom are thoroughly investigated before the attack and closely watched after being infected.How can users protect themselves?
Kaspersky Lab products detect and block all variants of the malware used in this campaign:
At the Virus Bulletin conference in 2010, researchers from Kaspersky Lab partnered with Microsoft to present findings related to Stuxnet. The joint presentation included slides dealing with various parts of Stuxnet, such as the zero-days used in the attack.
Perhaps the most interesting zero-day exploit from Stuxnet was the LNK exploit (CVE-2010-2568). This allowed Stuxnet to propagate through USB drives and infect even machines that had Autorun disabled.
It was discovered during the 2010 research into Stuxnet that the LNK exploit has earlier been used in another malware, supposedly a Zlob PE, that pointed to "fanny.bmp".
Back in 2010, very few people paid much attention to a piece of malware that used the LNK exploit prior to Stuxnet. Zlob is a large malware family and these kinds of crimeware-grade samples are rarely of interest to researchers digging into zero-days and nation-state sponsored operations.
However, during our 2014 research into the Equation group, we created a special detection for the group's exploitation library, codenamed "PrivLib". To our surprise, this detection triggered a worm from 2008 that used the Stuxnet LNK exploit to replicate, codenamed Fanny.What's so Fanny?
This PrivLib-boosted Worm, which spreads using the Stuxnet LNK exploit and the filename "fanny.bmp" was compiled on Mon Jul 28 11:11:35 2008, if we are to trust the compilation timestamp. It arrived in our December 2008 collection from the wild, so the compilation might very well be correct.
"Fanny my name" could be an introductory message from the authors
The 2008 "Fanny.bmp" Worm is detected by Kaspersky Lab products as Trojan-Downloader.Win32.Agent.bjqt. The malware includes the LNK exploit, which means that it is a piece of malicious software that used the Stuxnet LNK exploit before Stuxnet!The second Stuxnet exploit (MS09-025)
If one piece of malicious software that used an exploit from Stuxnet before Stuxnet is a good catch, a second Stuxnet exploit makes it even more interesting.
The second exploit used to be a zero-day when Fanny was operational. This means that Fanny used two zero-days to replicate, both of which were later used by Stuxnet. The specific vulnerability used for privilege escalation was patched with MS09-025:"The security update addresses these vulnerabilities by correcting the methods used for validating a change in specific kernel objects, for validating the input passed from user mode to the kernel, and for validating the argument passed to the system call. The security update also addresses a vulnerability by ensuring that the Windows kernel cleans up pointers under error conditions."
The same exploit was later used in an early Stuxnet module from 2009, which was embedded into a large binary built using the Flame platform. That Stuxnet module, also known as "atmpsvcn.ocx" or Resource 207 was the technical link between Stuxnet and Flame. This story has previously been covered in our post.
#Fanny used two zero-days to replicate, both of which were later used by #Stuxnet #EquationAPT #TheSAS2015Tweet
While the vulnerability exploited by both the Stuxnet/Flame module and Fanny is the same, the implementation of the exploit is different. The exploit in Stuxnet targets a specific OS version, while Fanny is designed to be universal and is capable of running on multiple platforms. It has a unique shellcode and exploit-triggering procedures for:
The implementation of the exploit in Fanny is more complex than in Stuxnet: instead of running just one payload the authors created a framework to run as many payloads as they want by replacing a system service call dispatcher nt!NtShutdownSystem with their own custom pointer from theuser-space as shown in the next figure.
Fanny injected its own system service call dispatcher
This enables a persistent trampoline from user-mode to kernel-mode. This feature was not present in the Stuxnet module but there are other similarities. For instance, it seems that both the developers of Stuxnet and of Fanny follow certain coding guidelines such as the usage of unique magic numbers from each function call. Most of the returned results are simply disposed but they are still part of the code. This could be the remains of a debug version of the code which could potentially log every step in the code to ease the tracking down of an error while testing. In complex systems where kernel and user-space code is running with no interaction this seems a logical and even essential method. Again, it's implemented both in the Stuxnet code and in Fanny. See next figure.
Stuxnet (on the left) and Fanny (on the right) using magic return valuesThe Fanny Malware
So, what is Fanny essentially? It is a USB Worm with a sophisticated backdoor that uses the so-called "Stuxnet LNK vulnerability" to automatically execute from the USB drive even if Autorun has been disabled. It can elevate privileges to the local System using kernel exploit and drops and registers additional modules. It attempts to connect to a C&C server and deploys additional components if connection is available. If not, it uses the USB drive as a carrier to send/receive requests to and from the operator via a hidden storage area created in raw FAT structure.
Typically a victim plugs in a new USB drive and opens it with Windows Explorer. You can visually observe the two stages of infection from the USB which take seconds to execute.
This file is a DLL with two exports (to install and uninstall the malware). It contains a xor-encrypted config in binary resource with number 101. The config determines malware behavior: there is a command to deploy malware on the current system, URLs for the C&C server and local filenames and paths used to install embedded malware components.
Fanny components inside the main executable
Upon starting it checks the following mutexes:
Where is a 1-byte long integer taken from the config. If any of these mutexes exist, the code doesn't run. It means that another instance of the same code is running. InstanceNum most likely identifies a variant or generation of Fanny preventing the same version from reinfecting the system but allowing for different versions to run (possibly to enable enforced update of components).
The module also checks another important byte in its configuration. This byte is a counter that is decreased during successful system infection. When the counter reaches a minimal value of one the module cleans up the USB drive and stops spreading the worm. In this way the attackers limit the maximum length of the Worm's killchain.
If the module is named "fanny.bmp" (the file name that Fanny uses to spread via USB drives) the module self-installs from the USB drive.
As part of the initial infection process Fanny attempts to elevate current privileges if the user has no administrative rights on the current system. It uses a vulnerability patched by MS09-025 for that purpose. Only if the elevation succeeds does the malware attempt to connect to the C&C server using a URL which is stored in the config:
Below is a sample request issued by the malware:GET /ads/QueryRecord200586_f2ahx.html HTTP/1.1
The malware expects the C&C server to reply with an HTTP 200 response and append a 0x7f-xored string that has a second stage URL. The second stage response may contain an executable file body which is saved on disk and executed.
The C&C server is currently sinkholed by Kaspersky Lab, but according to our pDNS records it previously pointed to the following IP address:
The following describes the stages that were identified during the analysis of the initial and embedded components of Fanny.Infection
The module searches for fanny.bmp in the root of disk drives starting from drive D: and copies it to the following locations:
Why does Fanny make two copies of itself? Actually, there is a minor difference between these two files. Fanny patches its config in the resource section of one of the files (comhost.dll). The patched data is the value of remained maximum length of the Fanny killchain. "mscorwin.dll" is the original file copied as-is from the removable drive. So far, one copy is used for infecting other USB drives, the other is loaded on the system boot.
It also copies all *.lnk files from the USB drive to "%WINDIR%\system32\" in order to reuse them when infecting other attached USB drives. Note that there may be more than one LNK file, because each LNK contains a distinct path to the DLL which gets loaded. As far as the letter of a new drive on the target system is unknown, Fanny uses several LNKs for the most common drive letters. This method was improved later in Stuxnet, which used a relative DeviceID-dependent path to the USB drive. However, even that method required several LNK files (up to four) because of different relative paths on different versions of Windows, but that's far fewer than an almost full set of letters from the Latin alphabet.Persistence
Fanny creates the following registry value to achieve persistence:
This is not a common way to make code start automatically on a system boot and it's extremely invasive, but it guarantees that the module is loaded in the address space of each process in the system, including some critical processes such as lsass.exe and services.exe running as SYSTEM user.
When the module is loaded it checks other values that start from "filter" in the same registry key, i.e.:
The values contain a hosting process name and a path to a DLL or EXE file. If the current process name contains the value set as hosting process, then the module loads a DLL or starts a new process (in case of EXE file) depending on target file extension.
This is a map of the processes and modules that are used in Fanny:Process Fanny module Short Description winlogon c:\windows\MSAgent\AGENTCPD.DLL USB backdoor explorer c:\windows\system32\shelldoc.dll Windows Explorer rootkit lsass c:\windows\system32\mscorwin.dll USB worm USB Worm
The code of the actual Worm is part of %WINDIR%\system32\comhost.dll export with ordinal 4 (name of export is "dll_installer_4"). The DLL is a modified next-generation Worm which is copied to every attached USB drive with all related LNK files stored in Windows\System32 directory. This module is distributed by mscorwin.dll which is part of the lsass system process.Windows Explorer Rootkit
The rootkit functionality is provided by a shelldoc.dll file loaded in the Windows Explorer process. It hides some Fanny-related files (LNK-files and fanny.bmp) in Windows Explorer by removing them from the list of items in the foreground window that uses SysListView32 control (normally Windows Explorer window).
Some screenshots with disappearing files were demonstrated previously, however sometimes this approach may raise suspicions. Here is what it looks like if the user opens a system32 directory with Explorer:
Seven Fanny-related file icons disappeared in Windows Explorer
Apparently, it looks as if some of the file icons were cut off. In addition some of standard directories seem to be missing due to a bug in the rootkit code. It appears as if this component was not tested properly by the authors.Masquerade Mode On
There is an interesting part of the code in USB Backdoor DLL which at first glance doesn't make much sense. It takes some hardcoded constants and generates a random value which is saved to a registry key.
Fanny generates random values that are saved to the registry
Then it moves the current executable which is hosting the DLL to c:\windows\system32\msdtc32.exe. After that the executable path is appended to HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell registry value which makes this executable run on system boot.
The trick to mimic the behavior of traditional malware was used to avoid revealing further secret activities #FannyTweet
This may look like a traditional way for malware to add itself to autostart, but don't be fooled by that. The purpose of this move is to make certain automated systems and software, such as those based on sandboxes and emulators, believe that they have caught some known malware and not to let it run further. It seems that the component is so unique that the authors decided to avoid the risk of looking even more suspect. It might seem a paradox, but the authors prefer this code to be detected as malware if someone is checking it. The trick is to mimic the behavior of some traditional cybercriminal malware, a bot, and get detected as soon as possible, thereby not revealing any further secret activities. Considering that this component was spreading via USB drives and could pop up on many systems, discovering it as a traditional bot would put it in lower risk zone and as a result the malware would probably end up being deleted without proper analysis.
This might explain why this code was detected as a variant of Zlob malware in the past and no one paid proper attention to it.USB Backdoor
One of the modules, agentcpd.dll, is a backdoor that was designed to work as an advanced reconnaissance tool for air-gapped computers that are normally used in highly secure facilities. The backdoor waits for a USB drive to be plugged in and if that's a new disk, it instantly allocates some space for a hidden container using its own FAT16/FAT32 filesystem driver.
This is what the FAT root directory looks like before and after plugging a USB drive into an infected machine:
Hexdump of raw disk partition before and after plugging into an infected machine
On top of this hexdump the drive label "MYDRIVE" can be found (corresponding hex bytes are underlined with green). It is followed by a single byte flag value (0x08 in hex) which, according to Microsoft, means ATTR_VOLUME_ID. Each entry in this root directory table is 32-bytes long.
Subdirectory entries such as Pictures, Music, Documents and Work occupy 63 bytes, because of the long filename FAT feature. There are two variants of subdirectory names – short and long. A subdirectory entry uses a flag 0x10 following the short directory name, which, according to Microsoft, means ATTR_DIRECTORY.
The last record inserted by Fanny (highlighted in red) uses an invalid directory name and a flag 0x18, which combines ATTR_VOLUME_ID and ATTR_DIRECTORY. This combination of flags is not documented according to current FAT specifications and the whole entry is therefore ignored by filesystem drivers as if it were a data corruption or a bad block. As a result this entry is not visible in Windows, Mac OS and Linux and probably all other implementations of FAT driver.
It's possible that #Fanny was used to map some of the future targets of #Stuxnet #EquationAPT #TheSAS2015Tweet
While Fanny doesn't rigorously protect data in hidden storage (it doesn't mark the allocated space as bad blocks, probably to avoid attention), it changes the filesystem driver hint value indicating where to look for the next free cluster. In this way it reserves disk space of approximately 1Mb in size to use for a hidden storage.
When Fanny detects a new USB drive, with the help of its own FAT driver it looks into the root directory and locates the entry which starts with magic value 51 50 40 98 (see above). It then uses the offset which follows the flag value of 0x18. On the figure above it is set to 0x001e9c00. This offset on the same USB disk will have another magic value D0 CF CE CD serving as a marker for the beginning of the hidden storage:
Hexdump of Fanny hidden storage with list of running processes
Once Fanny has allocated space for hidden storage it populates the storage with basic information about the current system: i.e. OS Version, Service Pack number, computer name, user name, company name, list of running processes, etc.
This secret storage is also used to pass commands to computers that are not connected to the Internet. According to Fanny code, the container may carry additional components and internal commands: such as to copy certain file from the local filesystem to the USB drive (locations are defined as parameters, the file is set hidden and system file attributes), or to update the configuration block. It uses RC4 with the following hard-coded key to protect critical information:
18 05 39 44 AB 19 78 88 C4 13 33 27 D5 10 6C 25
When the USB drive travels to another infected computer connected to the Internet it can be used to carry important files and provide a way to interact with the operator. This simple and extremely slow method of communication is not used by traditional cybercriminals, that is why the whole code looks like a toolkit for professional cyberespionage. This component is one of the rare malware samples from a new class of malware called USB-Backdoors.
If you find this or a similar code of USB-Backdoor on some of your systems this is an indicator of a professional cyberattack.Sinkholing and victim statistics
We sinkholed the Fanny C&C server and collected victim statistics, shown below. In total, we observed over 11,200 unique IPs connecting to the sinkhole server over a period of five months:
At the moment, the vast majority of victims are located in Pakistan (a whopping 59.36%). Indonesia and Vietnam follow at great distance, with 15.99% and 14.17% respectively. The infection numbers in other countries are probably too small to be relevant.
Of course, this could raise the question: was Pakistan the true target of Fanny? To be honest, we do not know. The current infection situation might be different from what it was in 2008-2010. Considering that there are still over ten thousand victims worldwide, the number back in 2009 might have been much, much higher – perhaps even as high as 50,000 infections. It may be relevant that Pakistan is a top target for the Equation group's other malware, along with Russia and Iran.Conclusion
With Fanny, we begin yet another chapter in the story of Stuxnet, the Equation Group and Flame. Created in 2008, Fanny used two zero-day exploits. These two were added to Stuxnet in June 2009 and March 2010. Effectively, it means that the Equation group had access to these zero-days (and others) years before the Stuxnet group did.
While the true target of Fanny remains unknown, its unique capability to map air-gapped networks and communicate via USB sticks indicate a lot of work went into gaining the ability to access these air-gapped networks. As a precursor for the versions of Stuxnet that could replicate through the network, it's possible that Fanny was used to map some of the future targets of Stuxnet.
Another unusual fact is the very high number of infections coming from Pakistan. Since Fanny spreads only through USB sticks, which is rather slow, this indicates that the infection began in Pakistan, possibly before many other countries.
Was Fanny used to map some highly sensitive networks in Pakistan, for an unknown purpose, or was it used in preparation for Stuxnet? Perhaps time will tell.
One sunny day in 2009, Grzegorz Brzęczyszczykiewicz1 embarked on a flight to the burgeoning city of Houston to attend a prestigious international scientific conference. As a leading scientist in his field, such trips were common for Grzegorz. Over the next couple of days, Mr Brzęczyszczykiewicz exchanged business cards with other researchers and talked about the kind of important issues such high level scientists would discuss (which is another way of saying "who knows?"). But, all good things must come to an end; the conference finished and Grzegorz Brzęczyszczykiewicz flew back home, carrying with him many highlights from a memorable event. Sometime later, as is customary for such events, the organizers sent all the participants a CDROM carrying many beautiful pictures from the conference. As Grzegorz put the CDROM in his computer and the slideshow opened, he little suspected he had just became the victim of an almost omnipotent cyberespionage organization that had just infected his computer through the use of three exploits, two of them being zero-days.A rendezvous with the "God" of cyberespionage
It is not known when the Equation2 group began their ascent. Some of the earliest malware samples we have seen were compiled in 2002; however, their C&C was registered in August 2001. Other C&Cs used by the Equation group appear to have been registered as early as 1996, which could indicate this group has been active for almost two decades. For many years they have interacted with other powerful groups, such as the Stuxnet and Flame groups; always from a position of superiority, as they had access to exploits earlier than the others.
The #EquationAPT group is probably one of the most sophisticated cyber attack groups in the world #TheSAS2015Tweet
Since 2001, the Equation group has been busy infecting thousands, or perhaps even tens of thousands of victims throughout the world, in the following sectors:
To infect their victims, the Equation group uses a powerful arsenal of "implants" (as they call their Trojans), including the following we have created names for: EQUATIONLASER, EQUATIONDRUG, DOUBLEFANTASY, TRIPLEFANTASY, FANNY and GRAYFISH. No doubt other "implants" exist which we have yet to identify and name.
The #EquationAPT group interacted with other powerful groups, such as the #Stuxnet and #Flame groups #TheSAS2015Tweet
The group itself has many codenames for their tools and implants, including SKYHOOKCHOW, UR, KS, SF, STEALTHFIGHTER, DRINKPARSLEY, STRAITACID, LUTEUSOBSTOS, STRAITSHOOTER, DESERTWINTER and GROK. Incredible as it may seem for such an elite group, one of the developers made the unforgivable mistake of leaving his username: "RMGREE5", in one of the malware samples as part of his working folder: "c:\users\rmgree5\".
Perhaps the most powerful tool in the Equation group's arsenal is a mysterious module known only by a cryptic name: "nls_933w.dll". It allows them to reprogram the hard drive firmware of over a dozen different hard drive brands, including Seagate, Western Digital, Toshiba, Maxtor and IBM. This is an astonishing technical accomplishment and is testament to the group's abilities.
Over the past years, the Equation group has performed many different attacks. One stands out: the Fanny worm. Presumably compiled in July 2008, it was first observed and blocked by our systems in December 2008. Fanny used two zero-day exploits, which were later uncovered during the discovery of Stuxnet. To spread, it used the Stuxnet LNK exploit and USB sticks. For escalation of privilege, Fanny used a vulnerability patched by the Microsoft bulletin MS09-025, which was also used in one of the early versions of Stuxnet from 2009.
LNK exploit as used by Fanny
It's important to point out that these two exploits were used in Fanny before they were integrated into Stuxnet, indicating that the Equation group had access to these zero-days before the Stuxnet group. The main purpose of Fanny was the mapping of air-gapped networks. For this, it used a unique USB-based command and control mechanism which allowed the attackers to pass data back and forth from air-gapped networks.
Two zero-day exploits were used by the #EquationAPT group before they were integrated into #Stuxnet #TheSAS2015Tweet
In the coming days, we will publish more details about the Equation group malware and their attacks. The first document to be published will be a general FAQ on the group together with indicators of compromise.
By publishing this information, we hope to bring it to the attention of the ITSec community as well as independent researchers, who can extend the understanding of these attacks. The more we investigate such cyberespionage operations, we more we understand how little we actually know about them. Together, we can lift this veil and work towards a more secure (cyber-)world.