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 #TheSAS2015

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.

Who are the Victims?

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.

How are the victims infected?

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 phishing

What 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.

Who are the attackers and what do we know about them?

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

The Main Falcons Trojan

The DHS* Spyware Trojan

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 #TheSAS2015

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:

Windows NT 4.0

Windows 2000

Windows XP

Windows 2003

Windows Vista, 2008 and possibly others from NT6.x family

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 values

The 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:

Global\RPCMutex

Global\RPCMutex

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:

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:

210.81.22.239

IP information

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:

%WINDIR%\system32\comhost.dll

%WINDIR%\system32\mscorwin.dll

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:HKLM\System\CurrentControlSet\Control\MediaResources\acm\ECELP4\Driver.

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.

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 #Fanny

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 #TheSAS2015

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 #TheSAS2015

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:

Government and diplomatic institutions

Telecoms

Aerospace

Energy

Nuclear research

Oil and gas

Military

Nanotechnology

Islamic activists and scholars

Mass media

Transportation

Financial institutions

Companies developing encryption technologies

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 #TheSAS2015

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 #TheSAS2015

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.

The story of Carbanak began when a bank from Ukraine asked us to help with a forensic investigation. Money was being mysteriously stolen from ATMs. Our initial thoughts tended towards the Tyupkin malware. However, upon investigating the hard disk of the ATM system we couldn't find anything except a rather odd VPN configuration (the netmask was set to 172.0.0.0).

At this time we regarded it as just another malware attack. Little did we know then that a few months later one of our colleagues would receive a call at 3 a.m. in the middle of the night. On the phone was an account manager, asking us to call a certain number as matter of urgency. The person at the end of the line was the CSO of a Russian bank. One of their systems was alerting that data was being sent from their Domain Controller to the People's Republic of China.

Up to 100 financial institutions have been hit.Total financial losses could be as a high as $1bn#TheSAS2015#Carbanak

When we arrived on site we were quickly able to find the malware on the system. We wrote a batch script that removed the malware from an infected PC, and ran this script on all the computers at the bank. This was done multiple times until we were sure that all the machines were clean. Of course, samples were saved and through them we encountered the Carbanak malware for the first time.

Modus Operandi

Further forensic analysis took us to the point of initial infection: a spear phishing e-mail with a CPL attachment; although in other cases Word documents exploiting known vulnerabilities were used. After executing the shellcode, a backdoor based on Carberp, is installed on the system. This backdoor is what we know today as Carbanak. It is designed for espionage, data exfiltration and remote control.

Each bank robbery took 2-4 months, from infecting the first computer to cashing the money out #TheSAS2015 #Carbanak

Once the attackers are inside the victim´s network, they perform a manual reconnaissance, trying to compromise relevant computers (such as those of administrators') and use lateral movement tools. In short, having gained access, they will jump through the network until they find their point of interest. What this point of interest is, varies according to the attack. What they all have in common, however, is that from this point it is possible to extract money from the infected entity.

The gang behind Carbanak does not necessarily have prior knowledge of the inner workings of each bank targeted, since these vary per organisation. So in order to understand how a particular bank operates, infected computers were used to record videos that were then sent to the Command and Control servers. Even though the quality of the videos was relatively poor, they were still good enough for the attackers, armed also with the keylogged data for that particular machine to understand what the victim was doing. This provided them with the knowledge they needed to cash out the money.

Cash out procedures

During our investigation we found several ways of cashing out:

ATMs were instructed remotely to dispense cash without any interaction with the ATM itself, with the cash then collected by mules; the SWIFT network was used to transfer money out of the organisation and into criminals' accounts; and databases with account information were altered so that fake accounts could be created with a relatively high balance, with mule services being used to collect the money.

Infections and losses

Since we started investigating this campaign we have worked very closely with the law enforcement agencies (LEAs) tracking the Carbanak group. As a result of this cooperation we know that up to 100 financial institutions have been hit. In at least half of the cases the criminals were able to extract money from the infected institution. Losses per bank range from $2.5 million to approximately $10 million. However, according to information provided by LEAs and the victims themselves, total financial losses could be as a high as $1 billion, making this by far the most successful criminal cyber campaign we have ever seen.

Losses from #Carbanak per bank range from $2.5 million to approximately $10 million #TheSAS2015

Our investigation began in Ukraine and then moved to Moscow, with most of the victims located in Eastern Europe. However thanks to KSN data and data obtained from the Command and Control servers, we know that Carbanak also targets entities in the USA, Germany and China. Now the group is expanding its operations to new areas. These include Malaysia, Nepal, Kuwait and several regions in Africa, among others.

The group is still active, and we urge all financial organizations to carefully scan their networks for the presence of Carbanak. If detected, report the intrusion to law enforcement immediately.

For a full description of the campaign, IOCs and list of infections please see our report.

To check your network for Carbanak's presence, you can also use the open IOC file available here.

FAQ
What is Carbanak?

Carbanak is the name we use for an APT-style campaign targeting (but not limited to) financial institutions. The main difference with other APT attacks is that attackers do not see data but money as their primary target. We say APT-like, however the attack is not strictly speaking Advanced. Strictly speaking, the main feature defining the attackers is Persistence.

We name the backdoor Carbanak since it is based on Carberp and the name of the configuration file is "anak.cfg".

What are the malicious purposes of this campaign?

The attackers infiltrate the victim´s network looking for the critical system they can use for cashing money out. Once they have stolen a significant amount of money (from 2.5 to 10 MM USD per entity), they abandon the victim.

Why do you think it is significant?

Banking entities have always been a primary target for cybercriminals. However it was almost always through their customers. This time attackers are targeting financial entities directly in an unprecedented, determined, highly professional and coordinated attack, and using any means from the target to cash as much money out as possible, up to an apparently auto-imposed limit.

Can you explain the timeline of the campaign?

According to what we know, the first malicious samples were compiled in August, 2013 when the cybercriminals started to test the Carbanak malware. The first infections were detected in December, 2013.

On average, each bank robbery took between two and four months, from infecting the first computer at the bank's corporate network to cashing the money out.

We believe that the gang was able to successfully steal from their first victims during the period of February-April 2014. The peak of infections was recorded in June 2014.

Currently the campaign is still active.

Why didn´t you make the details public until now?

Since we started working on this campaign we have collaborated with the different LEAs involved in the investigation and helped them as much as possible. As it remains an open investigation, we were asked not to share any details until it was safe to do so.

Have you reached victims and Computer Emergency Response Teams (CERTs) in those countries where you have detected the incidents?

Yes, this investigation turned into a joint operation between Kaspersky Lab's Global Research and Analysis Team and international organizations, national and regional law enforcement agencies and a number of Computer Emergency Response Teams (CERTs) worldwide.

One of our main goals was to disseminate our knowledge of the campaign and IOCs among all detected and potential victims. We used national CERTs and LEAs as the distribution channel.

How did you contribute to the investigation?

We're helping to assist in investigations and countermeasures that disrupt malware operations and cybercriminal activity. During the investigations we provide technical expertise such as analyzing infection vectors, malicious programs, supported Command & Control infrastructure and exploitation methods.

How was the malware distributed?

Attackers used spear phishing emails with malicious attachments against employees of the targeted financial institutions, in some cases sending them to their personal email addresses. We believe the attackers also used drive by download attacks, but this second assumption is still not 100% confirmed.

What is the potential impact for victims?

Based on what the attackers stole from victims, a new victim faces potential losses of up to 10 million $. However this figure is arbitrary based on what we know: nothing limits the potential loss once an institution is infected.

Who are the victims? What is the scale of the attack?

Victims are mainly institutions in the financial industry; however we have also found traces of infections in POS terminals and PR agencies. For a sense of the scale of the attack please see the different charts and maps we provide in our report.

As with many malware campaigns there are a variety of companies/individuals analyzing the malware, resulting in requests to the Command and Control server. When we analyze those servers, all we see are the IPs and possibly some additional information. When this additional information is not present, and when the IP cannot be traced back to its owner, we mark it as an infection.

Based on this approach our analysis concludes that Russia, the US, Germany and China are the most affected countries.

How are corporate users protected against this type of attack? Does Kaspersky Lab protect their users?

Yes, we detect Carbanak samples as Backdoor.Win32.Carbanak and Backdoor.Win32.CarbanakCmd.

All Kaspersky Lab's corporate products and solutions detect known Carbanak samples. To raise the level of protection, it is recommended to switch on Kaspersky's Proactive Defense Module included in each modern product and solution.

We also have some general recommendations:

Do not open suspicious emails, especially if they have an attachment;

Update your software (in this campaign no 0days were used);

Turn on heuristics in your security suites, this way it is more likely that such new samples will be detected and stopped from the beginning.

In 2013 we conducted our first in-depth research into the financial cyber-threat landscape. At that time we registered a sudden surge in the number of attacks targeting users' financial information and money. The financial cyber threats landscape was discussed in detail in Kaspersky Lab's "Financial Cyber-threats in 2013" report.

In 2014, the situation changed considerably: the number of attacks and attacked users significantly decreased, as did the amount of financial phishing. The key findings of the study into the financial cyber-threat landscape in 2014 are as follows:

Attacks with Financial malware in 2013 and 2014

Financial phishing attacks

In 2014 financial phishing attacks, which include phishing that targets Banks, Payment Systems and E-shops, accounted for 28.73% of all phishing attacks (a decrease of 2.72 percentage points).

Bank-related phishing accounted for 16.27% of all attacks.

The amount of phishing against Payment Systems increased 2.4 p.p. (from 2.74% in 2013 to 5.14% in 2014)

Financial malware attacks

In 2014 Kaspersky Lab products detected 22.9 million attacks involving financial malware against 2.7 million users. This represents a YoY decrease of 19.23% for attacks and 29.77% of users.

Among the total number of users subjected to all types of malware attacks, 4.86% of users encountered attacks involving some kind of financial threat – that's 1.34 percentage points less than in 2013.

The amount of Banking malware rose 8.89 percentage points to 75.63% of all financial malware attacks in 2014.

The number of attacks involving Bitcoin mining malware tripled: from 360,065 attacks in 2013 to 1,204,987 in 2014

There are several possible reasons for these changes. First of all, law enforcement agencies around the world actively prosecuted cybercriminals who were spreading financial malware and phishing. In particular, last summer, law enforcement agencies in the US and the UK stopped the activities of two dangerous malicious campaigns – Gameover / Zeus and Shylock.

The second reason for the decline in the number of attacks might be a shift in the cybercriminals' focus – instead of attacking end-users they are now pursuing organizations that work with financial information and payment tools. Throughout the year there were frequent reports of malicious attacks on large stores, hotel chains and fast food restaurants that serve millions of customers a day. In each case the fraudsters used malicious software that could steal bank card data directly from the memory of the POS terminals used by the organizations under attack. Banks became yet another "new" cybercriminal target. In 2014, Kaspersky Lab investigated several attacks targeting banks rather than their users' accounts. Neither of these "new" types of attack prompted a rash of new AV detections simply because there are so few organizations involved compared with the number of private users running antivirus solutions, so it is difficult to compare the number of attacks. Nevertheless, the damage from such attacks amounted to millions of dollars so this threat can hardly be dismissed.

#Cybercriminals are less interested in "mass" malicious attacks, preferring fewer, more "targeted" #attacks

A third possible reason for the reduced number of cyberattacks lies in a general trend observed by Kaspersky Lab specialists in 2014. According to the company's experts, cybercriminals are less interested in "mass" malicious attacks on users, preferring fewer, more "targeted" attacks. This is shown by the increased levels of targeted phishing: fraudsters only go after a specific group of users (for example, online banking users) rather than spreading mass mailings with malicious links.

This tactic suggests that a selective malicious mailing is less likely to be detected by IT security specialists and the lifespan of malicious links and malware samples will be extended. The trick is not always successful, but one consequence of its use is a decline in the absolute number of registered cyberattacks.

Android financial malware attacks

And what about mobile financial threats?

First of all, when we talk about mobile cyberthreats we focus on Android cyberthreats. According to Kaspersky Lab experts, more than 99% of mobile malware they are aware of is designed to attack Android devices.

In 2014 Kaspersky Lab and INTERPOL released a joint study on Mobile Cyberthreats which – among others – covered financial malware targeting Android users. According to the findings, there were 3,408,112 attacks against 1,023,202 users recorded in the period from August 1st, 2013 to July 31st 2014. About 500,000 users have encountered Android malware designed to steal money at least once. More than half a year has passed since the end of the period covered by the Kaspersky Lab / INTERPOL study and here is how things changed since:

In comparison with 2013 the number of financial attacks against Android users increased 3.25 times (from 711,993 to 2,317,194 attacks) and number of attacked users was up 3.64 times (from 212,890 to 775,887 users)

Attacks against users of Android-based devices in 2013 and 2014

In other words, the ever-increasing numbers of financial attacks against users of Android-based devices is a strong trend that shows no sign of declining.

Over the last decade DKIM signatures have become an important technology in the extensive list of methods for fighting against spam. Despite the fact that many users have no idea what the term DKIM even means, it is exactly this system that behind the scenes keeps our mailboxes guarded from various types of unsolicited mail, as well as protects a part of the world mail traffic from being wrongly labeled as "spam".

In this article we investigate the structure of DKIM in perspective from its emergence all the way up to nowadays. We also reveal the main advantages and downsides of this piece of technology, as well as explore typical spammers' tricks for forging DKIM signatures.

Concept of DKIM

DKIM technology (DomainKeys Identified Mail) provides a sender verification and guarantees the integrity of the delivered email. The verification is based on the electronic message signature which is generated with asymmetric cryptography. This signature is added to the service headers and is transferred transparently for the end user.

DKIM signature validation occurs automatically on the user side. It relies on the data extracted from the DKIM header as well as on the public encryption key retrieved from the sender's DNS domain name records. The message might be marked as scam, phishing, or suspicious if the specified domain name was not authorized to send this message, depending on the user's policies. Email clients are more loyal to the correspondence with successfully validated DKIM headers, as opposed to the messages with failed DKIM verification. In the meantime, emails without any DKIM headers are processed in the standard mode.

DKIM history

The history of DKIM starts in 2003 with an independent technology DomainKeys (DKIM ancestor) developed by Mark Delany as a part of his work at Yahoo. Two years later Yahoo is granted a patent for Domainkeys, and a wide range of vendors starts to prepare the first recommendatory version of DKIM standard.

In parallel with the DomainKeys development in 2003-2007, Cisco creates their own project "Identified Internet Mail" (IIM), based on a similar concept of authentication with the message signature.

In 2007 IETF publishes DomainKeys standard RFC 4870 (as already deprecated one) and the first standard of DKIM RFC 4871. Later on DKIM standard improves and gets updated in 2009 (RFC 5672). Finally, in 2011 IETF decides to merge two specs, IIM and DKIM, into the final standard RFC 6376.

Despite the fact that new standard had been published, by the year 2012 numerous companies were still using a deprecated 2007-year version of standard. This created a lot of interesting research on potential vulnerabilities in DKIM which we discuss below.

How it works

DKIM is based on the standard asymmetric encryption.

5 main DKIM stages:

For every server a public/private key pair (or a set of pairs) is generated.

The private key is stored on the sender's server and is being used to create all corresponding DKIM headers for the outgoing mail.

The public key is added to the domain DNS zone file in the form of special TXT-record by the domain owner and be comes accessible to everyone.

Email with DKIM signature is sent to the recipient (see below).

Signature is verified using the public key retrieved from the DNS records.

DKIM-signed email delivery

Compose and send message.User sends an email and it is accepted by the sender's mail server.

Create DKIM signature.The mail server adds a new "DKIM signature" header. This header includes an electronic signature created with the private encryption key, the message's body, its headers, current time, and other parameters.

Transfer signed message.Message with a new signed "DKIM signature" header is sent to the recipient.

Message reception and signature validation.The recipient's mail client analyzes the DKIM header and gives a verdict based on the public key, whether the sender and email are legitimate or not.

DKIM header validation

The very last stage, message validation, is especially interesting.
Main milestones:

Sending DNS-request.
Mail client/service performs a DNS-request that includes the domain name from which allegedly the message was sent.

Public encryption key retrieval.
The corresponding TXT-record that includes a public key is extracted from the response body from the DNS-server

DKIM header analysis:

Every tag in the header is decrypted from Base64 to its text representation.

Received strings are decrypted using the previously retrieved public key.

Final verdict.
The last stage is to compare the body text and headers with the decrypted information from the DKIM header. Any sort of discrepancy leads to dkim=fail, whereas if the content matches the verdict is dkim=pass.

DKIM header structure

Typical DKIM signature headers comprises of a list of tags like "tag=value". Tags names have short names and usually are 1-2 characters long.

TagTag descriptionb
message content (body + headers, encoded in Base64)
bh
hash of the canonicalized body part of the message(also in Base64)
d
domain name of the signing entity
h
list of signed headers

Additional headers:

TagTag descriptiona
main algorithm to generate the signature
v
system version
s
selector subdividing the namespace for the "d=" (domain) tag
c
algorithm to use to convert the body and headers to the canonical form
q
list of query methods used to retrieve the public key
x
signature expiration time
i
identity of the client on behalf of which the message is signed (in quoted-printable)
l
body length count in the number of octets in the body included in the cryptographic hash
t
signature timestamp
z
copied header fields at the moment of signature generation
Common attack methods on DKIM
Simple attacks

First attempts to use DKIM by spammers were observed by us back in 2009. Originally, spammers tried to add headers with content that was far away from valid DKIM signatures. Spammers paid very small attention to the accuracy of the signature, what created some pretty interesting cases.

For example, spammers used the same header for all emails in this spam mailing (the genuine DKIM headers are actually different for non-identical messages since each of them is based the message body, headers, timestamps, and other unique factors).

Tags spoofing

Other spam samples show how spammers copied DKIM signature from the legitimate third-party website and for every email changed content of only one DKIM-tag, completely forgetting that other tags also depend on the message content and should have different values as well.

Similar mistakes systematically appeared in spam throughout the last years.

Some of the most popular of them:

Spammers correctly generate the "b"-tag which describes the message body, but forget about the "bh"-tag (hashed body).

Domain name specified in "d"-tag does not correspond to the sender, nor to any details information in the email at all.

Specified timestamp ("t"-tag) is not accurate and is related to some other date in the distant past.

Legitimate DKIM headers in spam

Spammers are capable of setting up their own mail servers and domains in order to generate legitimate DKIM headers as the average system administrator would do. In spite of that, valid DKIM headers have been fairly uncommon in spam until recently.

This is largely due to the complexity of the installation process of the DKIM server side for the valid signatures generation. However, the number of domain names involved in the spam activity has increased significantly over time, therefore attacks on DKIM have become more efficient and profitable for spammers. For these reasons spammers had to learn how to skillfully operate DNS-records of their numerous domains.

In the example below we can see a perfectly valid DKIM signature along with a correct domain's TXT-record which lead to the "dkim=pass" verdict when coupled together.

This extra work appears to be reasonable enough for spammers since many email services are more loyal to the messages with correct DKIM signatures, and spammers' mail eventually has higher chances not to be banned by anti-spam filters and end up in the user's mailbox.

In addition to simple checks for the "DKIM=fail" verdict in message headers, our Kaspersky Security for Linux Mail Server detects all email spam with mentioned spammers tricks. It either detects this mail as spam and forwards straight to the junk folder or increases the spam rate of the message.

Vulnerabilities and weaknesses of DKIM

DKIM does not provide any guarantees.

It is not reasonable to rely solely on DKIM for the following reasons:

а) Spammers, as well as the average users, can correctly configure DKIM on their own website.
b) It is possible that some of mail coming from a single domain name does not have any DKIM headers. One example might be if the domain uses multiple mail servers with different configurations, although there might be many other scenarios.

Because of these reasons, the standard advises not to "penalize" any mail without DKIM signatures.

Lack of sustainability when message structure changes.

DKIM signature becomes invalid when the headers order is even slightly modified, when new headers are added, or when headers had any minor changes in their content. These kinds of changes are quite common and occur when the message is processed by the server-forwarder on the way to the recipient.

Short encryption keys are vulnerable.

All DKIM signatures signed with private keys shorter than 1024 bits in length are vulnerable according to the research by Zach Harris published in Wired in October 2012. Moreover, Harris managed to crack the 384-bit authentication in just 24 hours using his laptop only. You can read about other requirements to DKIM in our blog article about this news.

Interestingly enough, Harris had successfully sent emails to Google founders Sergey Brin and Larry Page in 2012 by spoofing their DKIM headers and formatting messages as their personal correspondence between each other.

Recently, numerous companies including Google and Microsoft started to intensively promote the use of encryption keys with the sufficient length. Despite that, there are still a great number of insecure mail servers signing DKIM headers with private keys of not cryptographically strong lengths.

Advantages of DKIM

Correctly created DKIM signature confirms that the received message has been indeed sent from the specified domain.

DKIM is a powerful tool for building a domain reputation based on the variety of messages received throughout a period of time (often used by diverse anti-spam solutions and by members of the DKIM reputation project)

DKIM gives another indicator which helps to make a decision on the client side, whether to trust the sender or not.

How to use DKIM?

DKIM is used in combination with other technologies of mail reputational analysis. The majority of modern email services and mail clients already support DKIM verification. However, it is useful to ensure that DKIM is configured correctly if you use your own domain name, or if you want to set up DKIM on your own mail server.

DKIM installation on the corporate mail service

Many corporate email services support DKIM installation with only several clicks required. However, the domain administrator will have to manually edit the DNS zone file to add corresponding TXT-records.

For example, this is how the DKIM activation process looks like for Gmail for Work service.

Confirm the intention to activate the "Email-authentication" and click "Generate new record".

Service will generate the content of new TXT-record that you have to store in your domain's DNS zone file. To do that, open your domain's administrator panel, find a section for manually editing the domain zone, add a new record with TXT type, and copy there all values offered by Gmail.

Final content of the zone record should be similar to:

google._domainkey IN TXT v=DKIM1; k=rsa; p=(generated public key)

As an extra step, you can create another TXT-record in order to support SPF policy as well. For Gmail for Work service this record should be:

@ IN TXT v=spf1 include:_spf.google.com ~all

This record authorizes Google servers to send mail from your domain name, and therefore the reversed verification on the recipient side will result in the spf=pass verdict.

Shortly after you finish all previous steps (often already after 20 minutes, but may take up to 48 hours), all emails sent from your domain start to be labeled with dkim=pass and spf=pass flags, confirming the legitimacy of the sender.

If you have any problems with installation, the DKIM installation manual and SPF record manual from Google Apps should be helpful. For the details on the zone file editing, refer to your domain name registrant documentation.

DKIM installation on your own mail server

Setting up DKIM on your own mail server is a less trivial process. We will give a short explanation of the DKIM installation procedure for Postfix mail agent on the server with Debian-like distribution. DKIM installation for other mail servers and OS is analogous. For more details, refer to the documentation on the interested email client and the information at the OpenDKIM project website.

Main stages:

Install Postfix MTA and the following OpenDKIM packages from the official repositories depending on your distribution

postfix opendkim opendkim-tools

Generate the private key to be able to create DKIM signatures in the future. You will need to specify your domain name, as well as the selector name that can be chosen arbitrarily (used later).

$ opendkim-genkey -r -s selector -d yourdomain.com

Store the generated key to the arbitrary file in the server directory with limited access and specify the path to it in the configuration file below.

Copy the example file from /etc/opendkim/opendkim.conf.sample to /etc/opendkim/opendkim.conf and edit the following options depending on your domain name and the chosen selector name:

Create new TXT-record in your DNS zone file (see also examples of zone file configuration above in the example for Gmail for Work service). Do not forget to specify your selector name picked on the previous steps. The record should look similar to:

selector._domainkey IN TXT v=DKIM1; k=rsa; p=...

You can validate the TXT-record of your domain with a simple request using host tool:

host -t TXT selector._domainkey.yourdomain.com

However, take into account it might take up to several hours to have your TXT-record updated because DNS providers cache data on their side.

The last stage is the integration of opendkim to Postfix. Edit the configuration file /etc/postfix/main.cf and add the following data to it:

The majority of public email services support DKIM signatures, validate them transparently for the user, and use the received verdicts for their own anti-spam systems.

Some services try to make DKIM-check more visual and mark emails that successfully pass DKIM validation.

For example, Gmail service marks emails with a 'secured connection' icon if the sender is verified and this email passes some internal validations for the sender.

You can enable this functionality in Settings → Labs → Authentication icon for verified senders.

As another example, Yandex.Mail service supports DKIM-indicators by default. It shows the icon when this email has a valid electronic signature.

Alternatives to DKIM

DKIM technology has various competitors and has become a basis for other sender authentication solutions.

Sender Policy Framework (SPF)

SPF also uses DNS for storing information, and is a tool for verification the sender's domain. As opposed to DKIM, SPF stores not the public key in DNS records, but the list of the servers authorized to send email messages. Overall, SPF allows to verify the authenticity of the domain name, but not the message text or its headers.

Nonetheless, SPF technology is more widespread than DKIM and is supported by the vast majority of mail clients and email services.

Pretty Good Privacy (PGP)

PGP is currently the most popular algorithm for email encryption in the world. It allows to encrypt the entire message under assumption that both sides generate public/private keys in advance and exchange the public keys. DKIM does not try to compete with PGP while being just an extension of the ordinary concept of email-message with the ability to validate the sender.

DMARC is a relatively fresh authentication method that combines both SPF and DKIM technologies. This system was presented for the first time in 2011 and numerous top vendors expressed interest in it. In 2013 DMARC was already protecting more than half of the world mailbox while still not yet being an official standard, which once again proves the success of DKIM technology that underlies DMARC.

Nothing holds a potential reader's attention stronger than a story about a catastrophe. A few days ago we came across an excellent example of a mass mailing where spammers took full advantage of this universal fascination with destruction.

The mass mailing in question is intended primarily for the US users. In it, the spammers list a series of recent tragedies and predict that worse is yet to come. They also propose a solution – just click the link to find out how to protect yourself and your family from harm.

In the email below the authors mention Sandy hurricane that hit North America about two years ago.

The spammers recall the crisis that faced many Americans after that hurricane – stranded in badly-damaged houses without food or electricity. The author of the email claims to know a guy who lived right in the center of the storm, in a wind-lashed city in New Jersey, and who suffered no shortages of anything. Click the link, and the spammers promise you'll enjoy the same good fortune if disaster strikes your neighborhood.

Yet another example mentions the recent terror attacks in France.

In this email, the spammers paint a bleak picture of America's immediate future, claiming the government is hiding the truth but expects blood to flow in the streets as it did in France. But there is an answer – just click the link and you'll find out how to protect your family from any attack.

When users follow these links they are taken to sites that are also striking. They start with an audio presentation of a confidential story told by a well-wisher.

The design of the site, the voice and the details of the story differ but the essence is the same: anyone who spends a few minutes to listen to the audio will be introduced to our hero, understand why he decided to share his warnings about the disasters in store for America and, eventually, find out how to build a miracle machine that can be easily assembled in your own home. The link to the video tutorial on self-assembly of this life-saving device costs just a few dozen dollars and shows you how to create a generator so simple that even your grandmother could make it work. Happy buyers don't only get an autonomous source of energy to be used in the event of disaster; they ca also save on household energy bills.

The audio is supported by a presentation which displays the speaker's text. So even users who cannot turn on the sound need only have the patience to watch for a few minutes, see the offer and reward the spammers for their efforts to spread paranoia by sending them their hard-earned dollars.

There is no doubt WhatsApp is among the most popular mobile IMs nowadays – its 700 million users worldwide were eagerly awaiting this week's promised desktop version. However, it wasn't just users who were waiting – cybercriminals were quick to start using this new feature in their attacks, aiming to spread malware and infect users.

In fact we've been seeing malicious messages about a supposed desktop WhatsApp long before the app added that platform to its repertoire. Fake downloads appeared in several languages and countries, and now there is a real product out there the fraudsters have returned to their old attacks, dressed them up in new clothes and sent them on the prowl for new victims. In Brazil, for example, we soon saw messages like this:

"WhatsApp for your PC" is now real, but this link is malware

We found several malicious domains registered to be used in these attacks. Some were already in use and others were waiting their owners' command, such as whatsappcdesktop.com.br, spreading Brazilian Trojan bankers (b93417abdc82cf79d79b737b61744353 and 9f485efea5c20b821e9522e3b4aa0e11):

However, other bad guys decided to prepare a nice design and ask users to install a suspicious Chrome extension that had nothing to do with WhatsApp:

You do not need a Chrome extension to use WhatsApp Web…

There are also some unofficial desktop versions of WhatsApp circulating among speakers of Arabic and Spanish. Here a website offer a version of "WhatsApp Plus" for installation:

And here the "WhatsApp Spy" targeting Spanish-speaking countries:

To download the supposed desktop version you need to inform your mobile number:

Why they ask your number? To subscribe on premium services that will cost money and to send you spam. Yes, spam. One thing is certain: all these web services aim to easily collect your mobile number and feed the long-established spam industry that already uses WhatsApp. As pointed out by Adaptive Mobile, the number of these spam messages increases day by day. WhatsApp process around 30 billion messages per day – not surprisingly, many of them are spam:

Mobile Spam, now on your instant message

It´s not difficult find Brazilian spammers who are already doing this, masquerading as 'marketing companies' and selling packages to disperse spam. Their services don't just include text, there's also the opportunity of spreading pics, audio or even video for the low price of $0.03 cents per message, including an admin and API panel:

U$75 for 5k credits, which correspond to 125,000 spam messages

Unfortunately, it is not possible block messages from unknown contacts on WhatsApp; all you can do is block the sender after the message was arrived, which does not solve the problem at all. In all cases keep in mind the real web services of WhatsApp are located at https://web.whatsapp.com so please refuse imitations and suspicious apps.

A digital certificate with a file is always seen as a token of its security. For users, a digital certificate is an indication that the file does not contain malicious code. Many system administrators develop their corporate security policies by allowing users to launch only those files that are signed with a digital certificate. In addition, some antivirus scanners automatically consider a file to be secure if it is signed with a valid digital certificate.

However, users' absolute trust in files signed with digital certificates encourages cybercriminals to search for various ways to have their malicious files signed with the same trusted digital certificates to help use them in their criminal schemes.

This article looks into the main threats associated with signed files, and suggests practical methods of mitigating the risks associated with launching them.

Creating digital signatures for files

Before we explore the threats associated with using digital certificates, let us first look into the process when a file is signed with a digital certificate:

The software developer compiles the file.

A hash sum (MD5, SHA1, or SHA2) is calculated for the file.

That hash sum is encrypted with the software developer's private key.

The obtained encrypted block of data and the digital certificate are added to the end of the file.

The digital certificate contains the software developer's public key, which can be used to decrypt the message and check the file's integrity. It also contains information with which the software developers' authenticity can be checked.

The authenticity of the file's manufacturer is confirmed with the help of the Certification Authority (CA). This entity certifies to other users that the public key that decrypts the hash sum and checks the file's integrity does indeed belong to the developer in question. To do so, the CA signs the developer's certificate and thus testifies that the unique pair of public and private keys belongs to that particular developer. A certificate from the CA testifying that the file is authentic is also added to the end of the file alongside the developer's certificate.

CA certificates are verified by no one other than these entities. For Windows to trust the certificates issued by a certain CA, that CA's certificate must be placed into the operating system's storage of certificates. The certificates of the most authoritative CAs have undergone an audit and are automatically included into the storage and are delivered to users along with Windows updates. Certificates issued by other CAs can be added to the storage at the discretion of the user.

The use of trusted certificates by cybercriminals

Now let's look at attacks that can be carried out at each stage of signing a file. We are not interested in theoretical attacks based on the weaknesses of the encryption algorithms used to sign the file, but will concentrate instead on the attack methods most often used by cybercriminals in practice.

Planting malicious code at the file compilation stage

In many large software companies, files are signed automatically immediately after the file compilation is complete. File compilation is done centrally on a dedicated Build server.

If cybercriminals gain access to a software manufacturer's corporate network, they can use the corporate Build server to compile a malicious file on it, so it automatically gets signed with the company's digital signature. As a result of this attack, cybercriminals obtain a malicious file signed with a valid digital certificate.

In practice this type of attack is quite rare because large software manufacturers have adequate security in place to protect their Build servers. Nevertheless, there have been identified cases when targeted attacks were successfully conducted and malicious files were signed with a trusted company's certificate.

Stealing a private key

Sometimes, cybercriminals succeed in penetrating a corporate network and gaining access to a private key used to sign files. With that key, they can sign any malicious file and pass it off as a file produced by a legal software manufacturer.

One way to steal a private key is to use specialized malware created specifically for this purpose.

After stealing a private key, the cybercriminal either uses it or sells it to someone else to use. The more famous the software manufacturer from which the key was stolen, the more valuable the key will be among cybercriminals. Software from well-known manufacturers does not attract any suspicion from users and security administrators on corporate networks.

At the same time, large software manufacturer companies keep their private keys in dedicated, well-protected hardware modules, which makes it much more difficult to steal them. As a result, private keys are typically stolen from smaller companies or private software manufacturers who do not pay enough attention to security.

Vulnerabilities in the algorithms that check executable file signatures

For an operating system to know which part of the file is supposed to contain the information about the presence of a digital certificate, the header of each signed executable file includes 8 bytes of data that contain information about the location and the size of the digital certificate. These 8 bytes are ignored when checking the file's signature. If a block of data is added to the end of the file's signature, and the size of the signature is increased by an appropriate amount, these changes also will also have no effect on the outcome of the signature check. This makes it possible to gain extra space in a signed file where data can be added without affecting the outcome of a signature check.

This algorithm is used actively in legal web installers: software developers who create these web installers modify the size of the digital signature to make room for an additional block of data, so that the digital certificate block includes a link to a file for that installer to download from the software developer's page and install on the users' system. This is a practical approach for software developers because the installer does not have to be re-signed each time the link to the software distribution kit is changed: it is enough to simply change the link stored in the digital signature block.

Cybercriminals, in turn, can use this algorithm for their own purposes. A cybercriminal takes a web installer for legal software, and changes the link so a different distribution kit to be downloaded. The installer then downloads and installs malware on the user's system. After that, the cybercriminal uploads the modified installer to software distribution sites.

To fix this vulnerability, Microsoft released a security update that enforces a rigorous check of each file's digital certificates. However, this update does not apply automatically because many software developers use the above algorithm in their installers, and their software programs would be considered unsigned if this update was applied across the board. The user can enable this update manually, if required.

The use of legally obtained certificates

A few years ago, digital certificates were actively used by large software manufacturers that were legally registered companies. Today, certificates are used increasingly often by individual software developers and small companies. The graph below shows how the number of certificates with which to sign software code known to Kaspersky Lab changed over time. As can be seen, the number of certificates is steadily growing year on year.

The number of certificates verified by CAs and known to Kaspersky Lab

The procedure of purchasing a certificate to sign executable code is quite simple: individuals must present their passport details, and companies must present their registration details. Some certificate-issuing CAs make no further checks into the activities of the companies seeking to purchase the certificate. All a CA does is it issues a certificate entitling the client to sign executable files, and verifies that the certificate has indeed been issued to the specific person or company.

This enables cybercriminals to legally purchase a certificate to sign their malicious and/or potentially unwanted software.

It is companies manufacturing potentially unwanted software that most often purchase certificates. On the one hand these companies do not manufacture malware programs, so they can legally purchase a digital certificate to sign their software. On the other hand, they produce software annoys users. In fact, they get their software signed with digital certificates precisely to encourage users to trust them.

Untrusted certificates

In all cases described above, be it stealing a private key, compromising a company's infrastructure and signing a file with that company's digital certificate, or purchasing a certificate with the intent of signing malware with it, the end result is the same: a trusted certificate is used to sign a malicious file.

Therefore, these certificates cannot be considered trusted in spite of the fact that their authenticity has been verified by a CA, as they were (or continue to be) used to sign malicious files. We will hereafter describe these certificates as 'untrusted'.

If a private key is stolen from a software developer, or a company's infrastructure is compromised and a trusted certificate is used to sign a malicious file, the CAs cease verifying the trustworthiness of the certificate that was earlier issued by them (a process also known as recalling the certificate). The speed of the CA's reaction depends on how soon it becomes known that the certificate has been used by somebody other than the legitimate developer.

However, when a certificate was purchased to sign potentially unwanted software, the CAs do not always recall the certificate. As a result the certificate could remain valid and be used to sign potentially dangerous software.

The following chart shows the proportions of untrusted certificates used to sign malware and potentially unwanted software (Kaspersky Lab data).

Breakdown of untrusted certificate numbers by their type

Methods of protection against launching software programs signed with untrusted certificates

We have discussed the most popular cybercriminals techniques to get files signed with digital certificates. Recently we have seen an increasingly significant problem concerning malicious and potentially unwanted files being signed with digital certificates. In 2008, 1,500 certificates were later used to sign malware; in 2014, there were more than 6,000 of these cases.

The number of untrusted certificates known to Kaspersky Lab

Given the growing number of threats associated with malicious files signed with digital certificates, users and administrator can no longer risk placing blind faith in signed files and just allow them to be launched simply because they have a digital certificate.

Here are a few practical tips to reduce your chances of launching a new malware program that has a valid digital certificate and hasn't yet reached your anti-virus databases:

Only allow the launch of software programs signed by a reputable manufacturer.

You can substantially reduce the risk of infection on your computer by disabling the launch of all software programs signed with digital certificates belonging to unknown software manufacturers. As described above, certificates are most often stolen from smaller software companies.

Only allow programs to be launched after they are identified by their unique digital signature attributes.

Several certificates issued to the same company may be distributed under the same name. If one of these certificates is stolen from a reputable company, a check that automatically trusts well-known publishers would allow a file signed with a stolen certificate.

To prevent this from happening, before allowing programs signed with known certificates to launch, it is necessary to check other attributes as well as the certificate name. These attributes might be the serial number or certificate fingertip (hash sum). Serial numbers are only unique within the range of certificates issued by a single CA, so we recommend checking this along with the company that issued the certificate in the first place.

For experienced users and system administrators, it is advisable to enable update MS13-098 – it fixes an error which enables the inclusion of additional data in a signed file without tampering with the file's signature. To read more about how to activate this update, follow this link to Microsoft Security Center.

Do not install certificates from unknown CAs into your security storage.

It is not a good idea to install root certificates from unknown CAs into your storage. If you do so, any files signed with a certificate confirmed by that specific CA will subsequently be considered trusted.

Use a trusted certificates database from a security software manufacturer.

Some security software manufacturers, including Kaspersky Lab, include a database of trusted and untrusted certificates in their products; this database is updated on a regular basis along with the anti-virus databases. With this database, you will receive prompt updates about as-yet unrecalled certificates used to sign malware and/or potentially unwanted software. Files signed with untrusted certificates from this database require enhanced monitoring by the security product.

The database of trusted certificates includes certificates from reputable software publishers that were used to sign trusted software programs. If a certificate is listed in this database, it is a strong indicator that corporate application control can allow the application to launch.

If this kind of database is included in a security product it will help make the administrator's job easier, sparing them the need to create and maintain an in-house database of trusted certificates.

The number of digital certificates used to sign malware and/or potentially unwanted software is doubling every year on average. That is why it is vital that companies exercise ever greater control over signed files with the help of security product tools, and follow the above security policies.

On January 17 2015, Spiegel.de published an extensive article based on documents obtained from Edward Snowden. At the same time, they provided a copy of a malicious program codenamed "QWERTY" (http://www.spiegel.de/media/media-35668.pdf), supposedly used by several governments in their CNE operations.

We've obtained a copy of the malicious files published by Der Spiegel and when we analyzed them, they immediately reminded us of Regin. Looking at the code closely, we conclude that the "QWERTY" malware is identical in functionality to the Regin 50251 plugin.

Analysis

The Qwerty module pack consists of three binaries and accompanying configuration files. One file from the package– 20123.sys – is particularly interesting.

The "20123.sys" is a kernel mode part of the keylogger. As it turns out, it was built from source code that can also be found one Regin module, the "50251" plugin.

Using a binary diff it is easy to spot a significant part of code that is shared between both files:

Most of the shared code belongs to the function that accesses the system keyboard driver:

Most of the "Qwerty" components call plugins from the same pack (with plugin numbers 20121 – 20123), however there is also one piece code that references plugins from the Regin platform. One particular part of code is used in both the "Qwerty" 20123 module and the Regin's 50251 counterpart, and it addresses the plugin 50225 that can be found in the virtual filesystems of Regin. The Regin's plugin 50225 is reponsible for kernel-mode hooking.

This is a solid proof that the Qwerty plugin can only operate as part of the Regin platform, leveraging the kernel hooking functions from plugin 50225.

As an additional proof that both modules use the same software platform, we can take a look at functions exported by ordinal 1 of both modules. They contain the startup code that can be found in any other plugin of Regin, and include the actual plugin number that is registered within the platform to allow further addressing of the module. This only makes sense if the modules are used with the Regin platform orchestrator.

The reason why the two modules have different plugin IDs is unknown. This is perhaps because they are leveraged by different actors, each one with its own allocated plugin ID ranges.

Conclusions

Our analysis of the QWERTY malware published by Der Spiegel indicates it is a plugin designed to work part of the Regin platform. The QWERTY keylogger doesn't function as a stand-alone module, it relies on kernel hooking functions which are provided by the Regin module 50225. Considering the extreme complexity of the Regin platform and little chance that it can be duplicated by somebody without having access to its sourcecodes, we conclude the QWERTY malware developers and the Regin developers are the same or working together.

Another important observation is that Regin plugins are stored inside an encrypted and compressed VFS, meaning they don't exist directly on the victim's machine in "native" format. The platform dispatcher loads and executes there plugins at startup. The only way to catch the keylogger is by scanning the system memory or decoding the VFSes.

Kaspersky Lab would like to alert users in the Middle East for new malware attacks being delivered through Syrian news and social networking forums. Malware writers are using multiple techniques to deliver their files and entice the victims to run them, creating an effective infection vector. Mainly depending on social engineering, the attackers exploit Victims' trust in social networking forums, curiosity in following news related to the conflict in Syria, their standing in Syria, in addition to their lack of Cyber Security awareness. Once criminals infect the victim's computer, attackers have full access and control over victim's devices.

In the first report on Syrian malware, Kaspersky Lab detailed many attacks being used in Syria to spy on users, the report included attacks from different teams and many sources.

This post will follow up on one of the domains, seemingly the most active in the last period: thejoe.publicvm.com

The malware files were found on activist sites and social networking forums, some others were reported by regional organisations like CyberArabs.

All the files hide under the hood a full-featured variant of a RAT, Remote Administration Trojan (Bitfrose/NjRAT/Shadowtech/Darkcomet...), capable of getting full control over victim machines and devices, monitoring any movements and accessing all files. The thejoe.publicvm.com domain is related to many samples, here we will focus on the most important and luring, that most probably collected the highest number of targeted victims, estimated in thousands.

There are many factors and entities at play in this event, we will only focus on the malware and the facts that have been found during the analysis, presenting only relevant information, in the hope of setting a clear context for this research.

What is the information we had on theJoe?What has the Joe been doing in the last period?Who is the Joe?

What is the information we had on the Joe?

The Joe is one of the most active cyber criminals in Syria and the Middle East, targeting all types of users, following is the information collected on the Joe and his activities.

Domain information "thejoe.publicvm.com"

The Joe is using a dynamic domain to be able to change his IP address and maintain anonymity:
The domain thejoe.publicvm.com has been seen using the following IP addresses located in Syria and Russia:

31.9.48.146

31.9.48.119

31.9.48.146

31.9.48.80

31.9.48.78

31.9.48.119

31.8.48.7

TCP ports used in the attacks: 1234, 1177, 5522.

Malware information

From the malware samples collected, we were able to find strings in the code, from the Windows device used by the Joe.

The Channel is distributing malware files under the name "Lions of the revolution" or other...

What has the Joe been doing in the last period?

The Joe was busy in the last period; In the below we display some of the most graphical and luring samples collected by the Kaspersky Intelligence services and the Kaspersky Security Network (KSN cloud), detailing their functionalities and how The Joe is able to use the situation in Syria to have the users automatically open the files even if they suspect infected. The most targeted countries are Syria, Turkey, Lebanon and Saudi Arabia. The number of victims is estimated around 2000.

Following up on the vulnerabilities in the OPENSSL, and the amount of news it reached, the cyber criminals are trying to benefit of the user perception of such news but lack of awareness on how the vulnerabilities could be fixed.

Demonstration video on the Heartbleed vulnerability + Link to download the "Fix" with infection

2 - Now Let us clean your Skype!

MD5 Hash: d6ab8ca6406fefe29e91c0604c812ff9
File Name: Skype.exe

Another social engineering trick used to lure criminals to download and execute a malicious file, the skype cleaner to "protect and encrypt your skype communications".

3 - Did you update to the latest VPN version?

MD5 Hash: 2e07e8622b4e997f6543fc0497452dad
File Name: VPN.exe

Psiphon, a legitimate application used around the world for anonymity protection, is particularly effective and used in Syria for users to protect their traffic from snooping or interception, the application here is bound with malware and delivered to the users as an updated version.

4 - Let's Check if your phone number is among the monitored numbers

MD5 Hash: ad9a18e1db0b43cb38da786eb3bf7c00
File Name: Syriatel.exe

Another one of the popular malware files, is used to fake a tool that is used to check the mobile phone numbers under surveillance and sorted by location, delivered as a "leaked program" to the victims.

5 - The Facebook account encryption application

MD5 Hash: efdaa73e0ac1b045d5f2214cadd77f09
File Name: Rooms.exe

6 - What's your favourite security product?

One of the latest files used to infect users is quite different: a binding of a Kaspersky Lab tool with malware. Developed by Kaspersky Lab, TDSSKiller is a powerful free tool that can detect and remove a specific list of rootkit malware families.

Bound with malware, the Joe is using the Kaspersky name to deliver the malware in an attempt to lure victims to open and trust the files he is sending.

Who is "The Joe"

Hundreds of samples were analyzed relating to the Syrian malware, one of the samples, extracts to multiple documents, in one of which, we were able to find a metadata slip which extracted to some interesting information.

The metadata slip by the guy using "Joe" as his nickname, revealed his personal email, which using further research leads to his other emails, full identity, social pages...

Kaspersky Lab detects all malicious files used in the attacks.All files are actively being used by the cybercriminals at the time of this report.

Conclusion

Syrian malware has a strong reliance on social engineering and the active development of malicious variants. Nevertheless, most of them quickly reveal their true nature when inspected carefully; and this is one of the main reasons for urging Syrian users to be extra vigilant about what they download and to implement a layered defense approach. We expect these attacks to evolve both in quality and quantity.

With high profile threats like Regin, mistakes are incredibly rare. However, when it comes to humans writing code, some mistakes are inevitable. Among the most interesting things we observed in the Regin malware operation were the forgotten codenames for some of its modules.

These are:

Hopscotch

Legspin

Willischeck

U_STARBUCKS

We decided to analyze two of these modules in more detail - Hopscotch and Legspin.

Despite the overall sophistication (and sometimes even over-engineering) of the Regin platform, these tools are simple, straightforward and provide interactive console interfaces for Regin operators. What makes them interesting is the fact they were developed many years ago and could even have been created before the Regin platform itself.

This executable module was designed as a standalone interactive tool for lateral movement. It does not contain any exploits but instead relies on previously acquired credentials to authenticate itself at the remote machine using standard APIs.

The module receives the name of the target machine and an optional remote file name from the standard input (operator). The attackers can choose from several options at the time of execution and the tool provides human-readable responses and suggestions for possible input.

Here's an example of "Hopscotch" running inside a virtual machine:

Authentication Mechanism (SU or NETUSE) [S]/N:
Continue? [n]:
A File of the same name was already present on Remote Machine - Not deleting...

The module can use two routines to authenticate itself at the target machine: either connecting to the standard share named "IPC$" (method called "NET USE") or logging on as a local user ("SU", or "switch user") who has enough rights to proceed with further actions.

It then extracts a payload executable from its resources and writes it to a location on the target machine. The default location for the payload is: \\%target%\ADMIN$\SYSTEM32\SVCSTAT.EXE. Once successful, it connects to the remote machine's service manager and creates a new service called "Service Control Manager" to launch the payload. The service is immediately started and then stopped and deleted after one second of execution.

The module establishes a two-way encrypted communication channel with the remote payload SVCSTAT.EXE using two named pipes. One pipe is used to forward input from the operator to the payload and the other writes data from the payload to the standard output. Data is encrypted using the RC4 algorithm and the initial key exchange is protected using asymmetric encryption.

Once completed, the tool deletes the remote file and closes the authenticated sessions, effectively removing all the traces of the operation.

The SVCSTAT.EXE payload module launches its copy in the process dllhost.exe and then prepares the corresponding named pipes on the target machine and waits for incoming data. Once the original module connects to the pipe, it sets up the encryption of the pipe communication and waits for the incoming shellcode.

The executable is injected in a new process of dllhost.exe or svchost.exe and executed, with its input and output handles redirected to the remote plugin that initiated the attack. This allows the operator to control the injected module and interact with it.

This module was also developed as a standalone command line utility for computer administration. When run remotely it becomes a powerful backdoor. It is worth noting that the program has full console support and features colored output when run locally. It can even distinguish between consoles that support Windows Console API and TTY-compatible terminals that accept escape codes for coloring.

"Legspin" output in a standard console window with color highlighting

In addition to the compilation timestamp found in the PE headers, there are two references that point to 2003 as its true year of compilation. The program prints out two version labels:

2002-09-A, referenced as "lib version"

2003-03-A

In addition the program uses legacy API functions, like "NetBIOS" that was introduced in Windows 2000 and deprecated in Windows Vista.

Once started and initialized, it provides the operator with an interactive command prompt, waiting for incoming commands. The list of available commands is pretty large and allows the operators to perform many administrative actions. Some of the commands require additional information that is requested from the operator, and the commands provide a text description of the available parameters. The program is actually an administrative shell that is intended to be operated manually by the attacker/user.

CommandDescription
cd
Change current working directory
dir
ls
dirl
dirs
List files and directories
tar
Find files matching a given mask and time range, and write their contents to a XOR-encrypted archive
tree
Print out a directory tree using pseudographics
trash
Read and print out the contents of the Windows "Recycle Bin" directory
get
Retrieve an arbitrary file from the target machine, LZO compressed
put
Upload an arbitrary file to the target machine, LZO compressed
del
Delete a file
ren
mv
copy
cp
Copy or move a file to a new location
gtm
Get file creation, access, write timestamps and remember the values
stm
Set file creation, access, write timestamps to the previously retrieved values
mtm
Modify the previously retrieved file timestamps
scan
strings
Find and print out all readable strings from a given file
more
Print out the contents of an arbitrary file
access
Retrieve and print out DACL entries of files or directories
audit
Retrieve and print out SACL entries of files or directories
finfo
Retrieve and print out version information from a given file
cs
Dump the first 10,000 bytes from an arbitrary file or from several system files:

lnk
Search for LNK files, parse and print their contents
info
Print out general system information:

CPU type

memory status

computer name

Windows and Internet Explorer version numbers

Windows installation path

Codepage

dl
Print information about the disks:

Type

Free/used space

List of partitions, their filesystem types

ps
List all running processes
logdump
Unfinished, only displays the parameter description
reglist
Dump registry information for a local or remote hive
windows
Enumerate all available desktops and all open windows
view
List all visible servers in a domain
domains
List the domain controllers in the network
shares
List all visible network shares
regs
Print additional system information from the registry:

IE version

Outlook Express version

Logon default user name

System installation date

BIOS date

CPU frequency

System root directory

ips
List network adapter information:

DHCP/static IP address

Default gateway's address

times
Obtain the current time from a local or remote machine
who
List the names of current users and the domains accessed by the machine
net
nbtstat
tracert
ipconfig
netstat
ping
Run the corresponding system utility and print the results
tel
Connect to a given TCP port of a host, send a string provided by the operator, print out the response
dns
arps
Resolve a host using DNS or ARP requests
users
List information about all user accounts
admins
List information about user accounts with administrative privileges
groups
List information about user groups
trusts
List information about interdomain trust user accounts
packages
Print the names of installed software packages
sharepw
Run a brute-force login attack trying to obtain the password of a remote share
sharelist
Connect to a remote share
srvinfo
Retrieve current configuration information for the specified server
netuse
Connect, disconnect or list network shares
netshare
Create or remove network shares on the current machine
nbstat
List NetBIOS LAN adapter information
run
Create a process and redirect its output to the operator
system
Run an arbitrary command using WinExec API
exit
Exit the program
set
Set various internal variables used in other shell commands
su
Log on as a different user
kill
Terminate a process by its PID
kpinst
Modify the registry value:[HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon] System
This value should normally point to "lsass.exe".
svc
drv
Create, modify or remove a system service
help
?
Print the list of supported commands

The Legspin module we recovered doesn't have a built-in C&C mechanism. Instead, it relies on the Regin platform to redirect the console input/output to/from the operators.

Conclusions

Unlike most other Regin modules, Legspin and Hopscotch appear to be stand-alone tools developed much earlier. The Legspin backdoor in particular dates back to 2003 and perhaps even 2002. It's worth pointing that not all Regin deployments contain the Legspin module; in most cases, the attackers manage their victims through other Regin platform functions.

This means that Legspin could have been used independently from the Regin platform, as a simple backdoor together with an input/output wrapper.

Although more details about Regin are becoming available, there is still a lot that remains unknown. One thing is already clear – what we know about Regin is probably already retired information that has been replaced by new modules and techniques as time passes.

Microsoft presented a preview of their newest "experience", Windows 10, over a live stream this morning. The release is expected later this year. This isn't envisioned as just an OS for desktops, but it brings support as a truly broad computing platform. They claim to have built Windows 10 with "more personal computing" in mind, and it's an ambitious push into seamlessly bringing together desktop computing, holographic computing (awesome!!!), mobile devices, gaming and IoT, a move to the "Store", productivity applications, big data services and sharing, new hardware partner technologies, and cloud computing for a "mobility of experience". They skimmed over "Trust" only in light of data privacy issues. From what I have seen, pushing aside security is a somewhat disappointing theme for all of the vendors at their previews, not just Microsoft. There is, however, a very long list of enhanced security features developed into this new codebase along with a massive amount of new attack surface introduced with this new platform.

Microsoft is attempting to better tighten down the new version of Windows the operating system by disallowing untrusted applications from installing and verifying their trustworthiness with their digital signature. This trusted signing model is an improvement, however, this active handling is not perfect. APT like Winnti's attacks on major development shops and their multiple, other significant ongoing attack projects demonstrate that digital certificates are readily stolen and re-used in attacks. Not just their core group's winnti attacks, but the certificates are distributed throughout multiple APT actors, sharing these highly valued assets, breaking the trust model itself to further their espionage efforts.

With seamless integration of all these data sharing services across computing resources, authentication and their underlying credentials and tokens cannot be leaked across services, applications, and devices. Pass-the-hash attack techniques frequently used by targeted attackers haunted corporate organizations using Windows for almost a decade. These types of credential theft techniques will have to be better protected against. And Flame introduced a whole new level of credential attack, so we may see Hyper-V and the newest container model for Windows 10 attacked to gain access to and abuse these tokens for lateral movement and data access. Defensive efforts haven't been terribly successful in their responsiveness in the past, and Active Directory continues to see new attacks on organization-wide authentication with "skeleton keys". So, their implementation of credential provisioning and access token handling will deserve security researchers' attention - Hyper-V technologies and components' attack surface will come under a new focus for years to come. And the DLP implementation for sharing corporate data securely is encouraging as well, but how strong can it be across energy constrained mobile hardware?

Considering that 2014 brought with it over 200 patch-worthy vulnerabilities for the various versions of Internet Explorer, a minimalist refresh of this code with the "Project Spartan" browser would be welcome. Simply put, the IE web browser was hammered in 2014 across all Windows platforms, including their latest. Our AEP and other technologies have been protecting against exploitation of these vulnerabilities in high volume this past year. Not only has its model implementing ActiveX components and its design been under heavy review, but the slew of newer code and functionality enabling "use-after-free" vulnerabilities led to critical remote code execution. The new Spartan browser brings with it large amounts of new code for communications and data sharing, which brings with it Microsoft's track record of introducing hundreds of patch-worthy vulnerabilities annually into their browser code. Hopefully their team won't bring that baggage with them, but the load seems pretty heavy with the new functionality. I didn't see any new security features, development practices, or sandboxes described for it and will wait to see what is in store here.

An unusually large amount of time was set aside to present their "intelligent assistant" Cortana, which started with a somewhat disconnected and bizarre conversation between the presenter and the actual Cortana assistant instance onstage. The devil is in the details when implementing security support for access to data across fairly unpredictable services like this one.

Of course, our products will be ready to go. Kaspersky Lab consumer products will support Windows 10 after its official launch. There will be no need for customers to reinstall Kaspersky Lab solutions for migration onto the new platform. All these products will be patched accordingly and will provide the same exceptional level of protection on the new Windows OS.

Microsoft's security team begins 2015 with a minimal set of Security Bulletins, MS15-001 through MS15-008. The set included one critical vulnerability in a service that probably shouldn't be shipped any longer (telnet), and seven bulletins rated "Important" patches for elevation of privilege, DoS, and security bypass issues.

The critical Bulletin effects the telnet service. The telnet service is an ancient piece of software that provides shell access to a system. Only it's over unencrypted, plain text communications, and should not be used. Luckily, this service is not enabled by default on supported windows systems (but it is installed by default on Windows Server 2003). So, this patch effects very few customers. A quick search in shodan shows a pretty reduced set of users, and its presence in our Ksn data is very limited. When installed and enabled, Microsoft's telnet server runs as "Tlntsess.exe" on all Windows systems since Windows Server 2003.

But, if someone didn't install an alternative like OpenSSH, uses the PowerShell facility, WinSCP, or other facilities, and oddly installed this service, they may be running a server vulnerable to remote malformed packet delivery leading to remote code execution. Meaning it's a severe issue that really >shouldn't< effect many users. And it appears to not be exploited on our user base. On a somewhat related note, Ksn shows infected Tlntsess.exe files on systems that need upgrades and cleanup:
Virus.Win32.Virut.ce
Worm.Win32.Mabezat.b
Virus.Win32.Sality.gen
Virus.Win32.Parite.b
Virus.Win32.Nimnul.a
Virus.Win32.Tenga.a
Virus.Win32.Expiro.w
Virus.Win32.Slugin.a

It's always surprising to still see the viral stuff, but it's certainly more prevalent than telnet service exploitation at this point.

The other Security Bulletins are rated "Important", and the escalation of privilege issues are somewhat interesting and the kind of thing businesses should be aware of - they are frequently used as a part of target attack activity.

One of these EoP vulnerabilities was reported privately and exposed publicly by Google's Project Zero. The project maintains a database of exploitable vulnerabilities, each of which has a deadline of 90 days from reporting before the bug goes public: "Deadline exceeded - automatically derestricting". This EoP was fixed and the fix released by Microsoft as MS015-003 two days after Google's bug issue was exposed publicly. It's strange that Google would do such a thing, it's not as if Microsoft doesn't commit to reasonable time frames for fixes and proper testing anymore. Microsoft responded with a lengthy writeup on responsible disclosure and cooperation within the industry, and mentioned Google's approach in particular.

The flawed code has yet to be seen as abused in the wild, but it will likely happen. You can find a set of executive summaries for the Bulletins here.

And one last note, the Advanced Notification Service is coming to an end. Microsoft ended their practice of broadcasting advance notice of security updates to all customers, and offers it only to paying Premiere-level customers. For the most part, it seems that this works out just fine and possibly frustrates people less with security maintenance. However, I think that it would be useful for Microsoft to pre-release forecasted download file sizes and reboot requirements for the updates, along with their ratings of critical or not, etc. For example, knowing that I will have to download over 200mb of critical software updates requiring system reboots would be helpful. That information would be useful to their customers both large and small. Time will tell if they bring it back, but likely, they will not need to.

The new year has started rather badly for the Bitcoin world. On January 4th, a cyber-attack against Bitstamp, one of the biggest bitcoin exchanges in the world, resulted in the loss of almost 19,000 BTC - the equivalent of more than $5 million.

While very little is known at the moment about how the attackers managed to pull off this latest bitcoin heist, Bitstamp is assuring their customers that all of their bitcoins remain safe. The company states that "this breach represents a small fraction of Bitstamp's total bitcoin reserves", so hopefully covering the losses shouldn't be a problem for them.

Because of the irreversible nature of bitcoin transactions, the only thing Bitcoin enthusiasts can do right now is to sit and watch how the attackers are emptying the address used to collect the stolen bitcoins.

Right now, the attackers are most likely trying to move those bitcoins around through as many addresses as possible, and then will proceed to launder the stolen coins by using so-called "mixing" services

Bitstamp seems to have been much better prepared for such an incident compared to Mt. Gox, so while the price of Bitcoin was of course impacted, the impact was not that big. Part of the reason is that bitcoins are currently trading at prices that haven't been seen since the autumn of 2013 anyway, between $250 and $300 for 1 BTC.

Taking into account these cyber attacks, we conclude that in 2015 security will continue to remain the most important thing for Bitcoin exchanges and enthusiasts.

Our advice is to diversify and try and minimize the time in which your bitcoins are hosted by anyone else except yourself. Bitcoin exchanges and third party wallet providers seem to act as a magnet for attackers, so it's better to take the security of your bitcoins in your own hands.

CODE BLUE＠TOKYO, a cutting-edge IT security conference, was held from 18th -19th December. It was the second round, following its first occurrence in February 2014.

More than 400 people came together from all around the world, including one remotely participating in the conference via a drone. Heated discussions took place among researchers and engineers during intervals, lunchtime and coffee breaks - some were too enthusiastic they almost missed the next presentation (I admit I was one of them).

The concept of the meeting is "an international conference where the world's top class information security specialists gather to give cutting edge talks, and is a place for all participants to exchange information and interact beyond borders and languages." As this states, all the presentations were of high-quality technical research selected from topics submitted from researchers around the world. The security topics include: embedded technologies, penetration testing, vulnerabilities, malware, programming and more. It would be perfect if I could cover all the presentations, but to save my time and yours, I would like to pick up five of them.

A security assessment study and trial of Tricore-powered automotive ECU

Dennis Kengo Oka (ETAS) and Takahiro Matsuki (FFRI) analyzed the behavior of ECU software running on TriCore, to attempt to verify the possibilities of attacks against it. Although they were not able to obtain the actual software itself for their testing, they created a test program on their own to show that the control system of TriCore was at risk of attack. There was a return address in a certain part of memory, and it was possible to transfer processing of the program to an arbitrary address if this was successfully overwritten. They proved the vulnerability by means of four demos, using an evaluation board. They said that they would need to obtain the ECU software actually used by TriCore in order to investigate whether or not the vulnerability could be a real threat.

Physical [In]Security: It's not ALL about Cyber

Inbar Raz (Check Point) presented risks in cinema-ticketing machines, PoS machines and TVs in hospitals. Such devices have USB/LAN ports; and inserting USB keyboards or flash drives with LiveOS into those ports and booting them makes it possible to extract data stored on these devices. Since these devices often store credit card information or private keys for communications, this may pose risks. Through the presentation, Raz pointed out that special devices commonly used in public often lack protection against inappropriate access and could give away confidential data to malicious third parties.

The story of IDA Pro

The keynote for Day 2, by Ilfak Guilfanov, was about the history of IDA from ver. 0.1 to IDA Pro. He outlined how IDA was created; which functionalities had been implemented; what issues have been resolved; and the existence of a pirated version of IDA Pro. Besides the future landscape of IDA Pro, the identity of the icon-lady was also revealed.

IDA Pro is widely used among engineers and malware researchers in their analysis of programs; I am not an exception.

Drone attack by malware and network hacking

Dongcheol Hong (SEWORKS) pointed out the inadequate security settings of a drone system and showed that it was easy to hijack a drone. In his video he demonstrated experiments of malware infection via a smartphone app and an attack from an infected drone to a clean drone. At the end of the presentation, he warned that drones could possibly pose threats to other systems, since it may be possible to conduct a remote attack through PC, AP, or smart devices.

Embedded Security in The Land of the Rising Sun

Ben Schmidt (Narf Industries) and Paul Makowski (Narf Industries) focused on routers commonly used in Japan, outlined which part of their code was vulnerable and demonstrated an attack on a router. According to them, there are a lot of home routers worldwide, which allow access to HTTP and UPnP ports from a WAN – Japan was number four on their worldwide list. They further pointed out that at the time of their presentation there were ~200,000 vulnerable routers which allowed HTTP and UPnP access from a WAN in Japan. Schmidt and Makowski sent me some additional comments after their presentation. They said: "Japanese embedded devices are attractive targets because Japanese Internet links are high bandwidth and low latency." They also emphasized the importance of quick patching of embedded devices.

David Jacoby from Kaspersky Lab GReAT was also a speaker at CODE BLUE. His presentation, entitled "How I Hacked My Home" ,was about the results of him hacking his own devices at home. His blog post is available in Securelist.

Kaspersky Lab Japan was Emerald Sponsor of CODE BLUE, as it had been for the first round.

In the fall of 2014, we discovered a new banking Trojan, which caught our attention for two reasons:

First, it is interesting from the technical viewpoint, because it uses a new technique for loading modules.

Second, an analysis of its configuration files has shown that the malware targets a large number of online-banking systems: over 150 different banks and 20 payment systems in 15 countries. Banks in the UK, Spain, the US, Russia, Japan and Italy make up the majority of its potential targets.

Kaspersky Lab products detect the new banking malware as Trojan-Banker.Win32.Chthonic.

The Trojan is apparently an evolution of ZeusVM, although it has undergone a number of significant changes. Chthonic uses the same encryptor as Andromeda bots, the same encryption scheme as Zeus AES and Zeus V2 Trojans, and a virtual machine similar to that used in ZeusVM and KINS malware.

Infection

We have seen several techniques used to infect victim machines with Trojan-Banker.Win32.Chthonic:

sending emails containing exploits;

downloading the malware to victim machines using the Andromeda bot (Backdoor.Win32.Androm in Kaspersky Lab classification).

When sending messages containing an exploit, cybercriminals attached a specially crafted RTF document, designed to exploit the CVE-2014-1761 vulnerability in Microsoft Office products. The file has a .DOC extension to make it look less suspicious.

Sample message with CVE-2014-1761 exploit

In the event of successful vulnerability exploitation, a downloader for the Trojan was downloaded to the victim computer. In the example above, the file is downloaded from a compromised site – hxxp://valtex-guma.com.ua/docs/tasklost.exe.

The Andromeda bot downloaded the downloader from hxxp://globalblinds.org/BATH/lider.exe.

Downloading the Trojan

Once downloaded, the downloader injects its code into the msiexec.exe process. It seems that the downloader is based on the Andromeda bot's source code, although the two use different communication protocols.

Example of common functionality of Andromeda and Chthonic downloaders

Differences in communication protocols used by Andromeda and Chthonic C&C

The Chthonic downloader contains an encrypted configuration file (similar encryption using a virtual machine was used in KINS and ZeusVM). The main data contained in the configuration file includes: a list of С&С servers, a 16-byte key for RC4 encryption, UserAgent, botnet id.

The main procedure of calling virtual machine functions

After decrypting the configuration file, its individual parts are saved in a heap - in the following format:

This is done without passing pointers. The bot finds the necessary values by examining each heap element using the RtlWalkHeap function and matching its initial 4 bytes to the relevant MAGIC VALUE.

The downloader puts together a system data package typical of ZeuS Trojans (local_ip, bot_id, botnet_id, os_info, lang_info, bot_uptime and some others) and encrypts it first using XorWithNextByte and then using RC4. Next, the package is sent to one of the C&C addresses specified in the configuration file.

In response, the malware receives an extended loader – a module in a format typical of ZeuS, i.e., not a standard PE file but a set of sections that are mapped to memory by the loader itself: executable code, relocation table, point of entry, exported functions, import table.

Code with section IDs matching the module structures

It should be noted that the imports section includes only API function hashes. The import table is set up using the Stolen Bytes method, using a disassembler included in the loader for this purpose. Earlier, we saw a similar import setup in Andromeda.

Fragment of the import setup function in Andromeda and Chthonic

Header of a structure with module

The extended loader also contains a configuration file encrypted using the virtual machine. It loads the Trojan's main module, which in turn downloads all the other modules. However, the extended loader itself uses AES for encryption, and some sections are packed using UCL. The main module loads additional modules and sets up import tables in very much the same way as the original Chthonic downloader, i.e. this ZeuS variant has absorbed part of the Andromeda functionality.

The entire sequence in which the malware loads, including the modules that are described below, is as follows:

Modules

Trojan-Banker.Win32.Chthonic has a modular structure. To date, we have discovered the following modules:

The impressive set of functions enables the malware to steal online banking credentials using a variety of techniques. In addition, VNC and cam recorder modules enable attackers to connect to the infected computer remotely and use it to carry out transactions, as well as recording video and sound if the computer has a webcam and microphone.

Injections

Web injections are Chthonic's main weapon: they enable the Trojan to insert its own code and images into the code of pages loaded by the browser. This enables the attackers to obtain the victim's phone number, one-time passwords and PINs, in addition to the login and password entered by the victim.

For example, for one of the Japanese banks the Trojan hides the bank's warnings and injects a script that enables the attackers to carry out various transactions using the victim's account:

Online banking page screenshots before and after the injection

Interesting functions in injected script

The script can also display various fake windows in order to obtain the information needed by the attackers. Below is an example of a window which displays a warning of non-existent identification problems and prompts the user to enter TAN:

Fake TAN entry window

Our analysis of attacks against customers of Russian banks has uncovered an unusual web injection scenario. When opening an online banking web page in the browser, the entire contents of the page is spoofed, not just parts of it as in an ordinary attack. From the technical viewpoint, the Trojan creates an iframe with a phishing copy of the website that has the same size as the original window.

Below is a fragment of injected code, which replaces everything between title and body closing tags with the following text:

And here is the script itself:

Additionally, the bot receives a command to establish a backconnect connection if the injection is successful:

Coverage

There are several botnets with different configuration files. Overall, the botnets we are aware of target online banking systems of over 150 different banks and 20 payment systems in 15 countries. The cybercriminals seem most interested in banks in the UK, Spain, the US, Russia, Japan and Italy.

Chtonic target distribution by country

It is worth noting that, in spite of the large number of targets on the list, many code fragments used by the Trojan to perform web injections can no longer be used, because banks have changed the structure of their pages and, in some cases, the domains as well. It should also be noted that we saw some of these fragments in other bots' config files (e.g., Zeus V2) a few years back.

Conclusion

We can see that the ZeuS Trojan is still actively evolving and its new implementations take advantage of cutting-edge techniques developed by malware writers. This is significantly helped by the ZeuS source code having been leaked. As a result, it has become a kind of framework for malware writers, which can be used by anyone and can easily be adapted to cybercriminals' new needs. The new Trojan – Chthonic – is the next stage in the evolution of ZeuS: it uses Zeus AES encryption, a virtual machine similar to that used by ZeusVM and KINS, and the Andromeda downloader.

What all of this means is that we will undoubtedly see new variants of ZeuS in the future.

Over the past years, Kaspersky's Global Research and Analysis Team (GReAT) has shed light on some of the biggest APT campaigns, including RedOctober, Flame, NetTraveler, Miniduke, Epic Turla, Careto/Mask and others. While studying these campaigns we have also identified a number of 0-day exploits, including the most recent CVE-2014-0546. We were also among the first to report on emerging trends in the APT world, such as cyber mercenaries who can be contracted to launch lightning attacks or more recently, attacks through unusual vectors such as hotel Wi-Fi. Over the past years, Kaspersky Lab's GReAT team has monitoring more than 60 threat actors responsible for cyber-attacks worldwide, organizations which appear to be fluent in many languages such as Russian, Chinese, German, Spanish, Arabic, Persian and others.

By closely observing these threat actors, we put together a list of what appear to be the emerging threats in the APT world. We think these will play an important role in 2015 and deserve special attention, both from an intelligence point of view but also with technologies designed to stop them.

The merger of cyber-crime and APT

For many years, cyber-criminal gangs focused exclusively on stealing money from end users. An explosion of credit card theft, hijacking of electronic payment accounts or online banking connections led to consumer losses in the worth hundreds of millions of dollars. Maybe this market is no longer so lucrative, or maybe the cybercriminal market is simply overcrowded, but it now seems like there is a struggle being waged for 'survival'. And, as usual, that struggle is leading to evolution.

What to expect: In one incident we recently investigated attackers compromised an accountant's computer and used it to initiate a large transfer with their bank. Although it might seem that this is nothing very unusual, we see a more interesting trend: Targeted attacks directly against banks, not their users.

In a number of incidents investigated by Kaspersky Lab experts from the Global Research and Analysis Team, several banks were breached using methods straight out of the APT playbook. Once the attackers got into the banks' networks, they collected enough information to enable them to steal money directly from the bank in several ways:

Remotely commanding ATMs to dispense cash.

Performing SWIFT transfers from various customer accounts,

Manipulating online banking systems to perform transfers in the background.

These attacks are an indication of a new trend that is embracing APT style attacks in the cybercriminal world. As usual, cybercriminals prefer to keep it simple: they now attack the banks directly because that's where they money is. We believe this is a noteworthy trend that will become more prominent in 2015.

Fragmentation of bigger APT groups

2014 saw various sources expose APT groups to the public eye. Perhaps the best-known case is the FBI indictment of five hackers on various computer crimes:

This public "naming and shaming" means we expect some of the bigger and "noisier" APT groups to shatter and break into smaller units, operating independently.

What to expect: This will result in a more widespread attack base, meaning more companies will be hit, as smaller groups diversify their attacks. At the same time, it means that bigger companies that were previously compromised by two or three major APT groups (eg. Comments Crew and Wekby) will see more varied attacks from a wider range of sources.

Evolving malware techniques

As computers become more sophisticated and powerful, operating systems also become more complex. Both Apple and Microsoft have spent a lot of time improving the security posture of their respective operating systems. Additionally, special tools such as Microsoft's EMET are now available to help thwart targeted attacks against software vulnerabilities.

With Windows x64 and Apple Yosemite becoming more popular, we expect APT groups to update their toolsets with more powerful backdoors and technologies to evade security solutions.

What to expect: Today, we are already seeing APT groups constantly deploying malware for 64-bit systems, including 64-bit rookits. In 2015, we expect to see more sophisticated malware implants, enhanced evasion techniques and more use of virtual file systems (such as those from Turla and Regin) to conceal precious tools and stolen data.

While we see these increases in advanced techniques, some attackers are moving in the opposite direction. While minimizing the number of exploits and amount of compiled code they introduce to compromised networks altogether, their work continues to require sophisticated code or exploit introduction at a stable entry into the enterprise, script tools and escalation of privilege of all sorts, and stolen access credentials at victim organizations.

As we saw with BlackEnergy 2 (BE2), attackers will actively defend their own presence and identity within victim networks once discovered. Their persistence techniques are becoming more advanced and expansive. These same groups will step up the amount and aggression of destructive last effort components used to cover their tracks, and they include more *nix support, networking equipment, and embedded OS support. We have already seen some expansion from BE2, Yeti, and Winnti actors.

New methods of data exfiltration

The days when attackers would simply activate a backdoor in a corporate network and start siphoning terabytes of information to FTP servers around the world are long gone. Today, more sophisticated groups use SSL on a regular basis alongside custom communication protocols.

Some of the more advanced groups rely on backdooring networking devices and intercepting traffic directly for commands. Other techniques we have seen include exfiltration of data to cloud services, for instance via the WebDAV protocol (facilitates collaboration between users in editing and managing documents and files stored on web servers).

These in turn have resulted in many corporations banning public cloud services such as Dropbox from their networks. However, this remains an effective method of bypassing intrusion detection systems and DNS blacklists.

What to expect: In 2015, more groups to adopt use of cloud services in order to make exfiltration stealthier and harder to notice.

New APTs from unusual places as more countries join the cyber arms race

In February 2014, we published research into Careto/Mask, an extremely sophisticated threat actor that appears to be fluent in Spanish, a language rarely seen in targeted attacks. In August, we also released a report on Machete, another threat actor using the Spanish language.

Before that, we were accustomed to observing APT actors and operators that are fluent in relatively few languages. Additionally, many professionals do not use their native language, preferring instead to write in perfect English.

In 2014, we observed a lot of nations around the world publicly expressing an interest in developing APT capabilities:

What to expect: Although we haven't yet seen APT attacks in Swedish, we do predict that more nations will join the "cyber-arms" race and develop cyber-espionage capabilities.

Use of false flags in attacks

Attackers make mistakes. In the vast majority of the cases we analyze, we observe artifacts that provide clues about the language spoken by the attackers. For instance, in the case of RedOctober and Epic Turla, we concluded that the attackers were probably fluent in the Russian language. In the case of NetTraveler we came to the conclusion that attackers were fluent in Chinese.

In some cases, experts observe other meta features that could point toward the attackers. For example, performing file timestamp analysis of the files used in an attack may lead to the conclusion in what part of the world most of the samples were compiled.

However attackers are beginning to react to this situation. In 2014 we observed several "false flag" operations where attackers delivered "inactive" malware commonly used by other APT groups. Imagine a threat actor of Western origin dropping a malware commonly used by a "Comment Crew," a known Chinese threat actor. While everyone is familiar with the "Comment Crew" malware implants, few victims could analyze sophisticated new implants. That can easily mislead people into concluding that the victim was hit by the Chinese threat actor.

What to expect: In 2015, with governments increasingly keen to "name and shame" attackers, we believe that APT groups will also carefully adjust their operations and throw false flags into the game.

Threat actors add mobile attacks to their arsenal

Although APT groups have been observed infecting mobile phones, this hasn't yet become a major trend. Perhaps the attackers wish to get data that isn't usually available on mobiles, or maybe not all of them have access to the technologies that can infect Android and iOS devices.

Additionally, during the Hong Kong protests in October 2014, attacks were seen against Android and iOS users which appear to be connected to APT operations.

Although a mobile phone might not have valuable documents and schematics, or geopolitical expansion plans for next 10 years, they can be a valuable source of contacts as well as listening points. We observed this with the RedOctober group, which had the ability to infect mobile phones and turn them into "Zakladka's", mobile bugs.

What to expect: In 2015, we anticipate more mobile-specific malware, with a focus on Android and jailbroken iOS.

APT+Botnet: precise attack + mass surveillance

In general, APT groups are careful to avoid making too much noise with their operations. This is why the malware used in APT attacks is much less widespread than common crimeware such as Zeus, SpyEye and Cryptolocker.

In 2014 we observed two APT groups (Animal Farm and Darkhotel) using botnets in addition to their regular targeted operations. Of course, botnets can prove to be a vital asset in cyberwar and can be used to DDoS hostile countries; this has happened in the past. We can therefore understand why some APT groups might want to build botnets in addition to their targeted operations.

In addition to DDoS operations, botnets can also offer another advantage - mass surveillance apparatus for a "poor country". For instance, Flame and Gauss, which we discovered in 2012, were designed to work as a mass surveillance tool, automatically collecting information from tens of thousands of victims. The information would have to be analyzed by a supercomputer, indexed and clustered by keywords and topics; most of it would probably be useless. However, among those hundreds of thousands of exfiltrated documents, perhaps one provides key intelligence details, that could make a difference in tricky situations.

What to expect: In 2015 more APT groups will embrace this trend of using precise attacks along with noisy operations and deploy their own botnets.

Targeting of hotel networks

The Darkhotel group is one of the APT actors known to have targeted specific visitors during their stay in hotels in some countries. Actually, hotels provide an excellent way of targeting particular categories of people, such as company executives. Targeting hotels is also highly lucrative because it provides intelligence about the movements of high profile individuals around the world.

Compromising a hotel reservation system is an easy way to conduct reconnaissance on a particular target. It also allows the attackers to know the room where the victim is staying, opening up the possibility of physical attacks as well as cyber-attacks.

It isn't always easy to target a hotel. This is why very few groups, the elite APT operators, have done it in the past and will use it as part of their toolset.

What to expect: In 2015, a few other groups might also embrace these techniques, but it will remain beyond the reach of the vast majority of APT players.

Commercialization of APT and the private sector

Over the last few years, we published extensive research into malware created by companies such as HackingTeam or Gamma International, two of the best known vendors of "legal spyware". Although these companies claim to sell their software only to "trusted government entities", public reports from various sources, including Citizen Lab, have repeatedly shown that spyware sales cannot be controlled. Eventually, these dangerous software products end up in the hands of less trustworthy individuals or nations, who can use them for cyber-espionage against other countries or their own people.

The fact is that such activities are highly profitable for the companies developing the cyber-espionage software. They are also low risk because – so far – we have not seen a single case where one of these companies was convicted in a cyber-espionage case. The developers of these tools are usually out of the reach of the law, because the responsibility falls with the tool users, not the company that develops and facilitates the spying.

What to expect: It's a high-reward, low risk business that will lead to the creation of more software companies entering the "legal surveillance tools" market. In turn, these tools will be used for nation-on-nation cyber-espionage operations, domestic surveillance and maybe even sabotage.

Conclusions

In general, 2014 was a rather sophisticated and diverse year for APT incidents. We discovered several zero-days, for instance CVE-2014-0515 which was used by a group we call "Animal Farm". Another zero-day we discovered was CVE-2014-0487, used by the group known as DarkHotel. In addition to these zero-days, we observed several new persistence and stealth techniques, which in turn resulted in the development and deployment of several new defense mechanisms for our users.

If we can call 2014 "sophisticated", the word for 2015 will be "elusive". We believe that more APT groups will become concerned with exposure and they will take more advanced measures to hide from discovery.

Finally, some of them will deploy false flag operations. We anticipate these developments and, as usual, will document them thoroughly in our reports.

Two years ago, we published our research into RedOctober, a complex cyber-espionage operation targeting diplomatic embassies worldwide. We named it RedOctober because we started this investigation in October 2012, an unusually hot month.

After our announcement in January 2013, the RedOctober operation was promptly shut down and the network of C&Cs was dismantled. As usually happens which these big operations, considering the huge investment and number of resources behind it, they don't just "go away" forever. Normally, the group goes underground for a few months, redesigns the tools and the malware and resume operations.

Since January 2013, we've been on the lookout for a possible RedOctober comeback. One possible hit was triggered when we observed Mevade, an unusual piece of malware that appeared late in 2013. The Mevade C&C name styles as well as some other technical similarities indicated a connection to RedOctober, but the link was weak. It wasn't until August 2014 that we observed something which made us wonder if RedOctober is back for good.

Meet Cloud Atlas

In August 2014, some of our users observed targeted attacks with a variation of CVE-2012-0158 and an unusual set of malware. We did a quick analysis of the malware and it immediately stood out because of certain unusual things that are not very common in the APT world.

Some of the filenames used in the attacks included:

FT - Ukraine Russia's new art of war.doc

Катастрофа малайзийского лайнера.doc

Diplomatic Car for Sale.doc

МВКСИ.doc

Organigrama Gobierno Rusia.doc

Фото.doc

Информационное письмо.doc

Форма заявки (25-26.09.14).doc

Информационное письмо.doc

Письмо_Руководителям.doc

Прилож.doc

Car for sale.doc

Af-Pak and Central Asia's security issues.doc

At least one of them immediately reminded us of RedOctober, which used a very similarly named spearphish: "Diplomatic Car for Sale.doc". As we started digging into the operation, more details emerged which supported this theory.

Perhaps the most unusual fact was that the Microsoft Office exploit didn't directly write a Windows PE backdoor on disk. Instead, it writes an encrypted Visual Basic Script and runs it.

Cloud Atlas exploit payload - VBScript

This VBScript drops a pair of files on disk - a loader and an encrypted payload. The loader appears to be different every time and internal strings indicate it is "polymorphically" generated. The payload is always encrypted with a unique key, making it impossible to decrypt unless the DLL is available.

We observed several different spear-phishing documents that drop uniquely named payloads. For instance, the "qPd0aKJu.vbs" file MD5:

The payload includes an encrypted configuration block which contains information about the C&C sever:

The information from the config includes a WebDAV URL which is used for connections, a username and password, two folders on the WebDAV server used to store plugins/modules for the malware and where data from the victim should be uploaded.

C&C communication

The Cloud Atlas implants utilize a rather unusual C&C mechanism. All the malware samples we've seen communicate via HTTPS and WebDav with the same server "cloudme.com", a cloud services provider. According to their website, CloudMe is owned and operated by CloudMe AB, a company based in Linköping, Sweden.

(Important note: we do not believe that CloudMe is in any way related to the Cloud Atlas group - the attackers simply create free accounts on this provider and abuse them for command-and-control).

Each malware set we have observed so far communicates with a different CloudMe account though. The attackers upload data to the account, which is downloaded by the implant, decrypted and interpreted. In turn, the malware uploads the replies back to the server via the same mechanism. Of course, it should be possible to reconfigure the malware to use any Cloud-based storage service that supports WebDAV.

Here's a look at one such account from CloudMe:

The data from the account:

The files stored in the randomly named folder were uploaded by the malware and contain various things, such as system information, running processes and current username. The data is compressed with LZMA and encrypted with AES, however, the keys are stored in the malware body which makes it possible to decrypt the information from the C&C.

We previously observed only one other group using a similar method – ItaDuke – that connected to accounts on the cloud provider mydrive.ch.

Just like with RedOctober, the top target of Cloud Atlas is Russia, followed closely by Kazakhstan, according to data from the Kaspersky Security Network (KSN). Actually, we see an obvious overlap of targets between the two, with subtle differences which closely account for the geopolitical changes in the region that happened during the last two years.

Interestingly, some of the spear-phishing documents between Cloud Atlas and RedOctober seem to exploit the same theme and were used to target the same entity at different times.

Cloud Atlas
RedOctober

Both Cloud Atlas and RedOctober malware implants rely on a similar construct, with a loader and the final payload that is stored encrypted and compressed in an external file. There are some important differences though, especially in the encryption algorithms used – RC4 in RedOctober vs AES in Cloud Atlas.

The usage of the compression algorithms in Cloud Altas and RedOctober is another interesting similarity. Both malicious programs share the code for LZMA compression algorithm. In CloudAtlas it is used to compress the logs and to decompress the decrypted payload from the C&C servers, while in Red October the "scheduler" plugin uses it to decompress executable payloads from the C&C.

It turns out that the implementation of the algorithm is identical in both malicious modules, however the way it is invoked is a bit different, with additional input sanity checks added to the CloudAtlas version.

Another interesting similarity between the malware families is the configuration of the build system used to compile the binaries. Every binary created using the Microsoft Visual Studio toolchain has a special header that contains information about the number of input object files and version information of the compilers used to create them, the "Rich" header called so by the magic string that is used to identify it in the file.

We have been able to identify several RedOctober binaries that have "Rich" headers describing exactly the same layout of VC 2010 + VC 2008 object files. Although this doesn't necessarily mean that the binaries were created on the same development computer, they were definitely compiled using the same version of the Microsoft Visual Studio up to the build number version and using similar project configuration.

Finally, perhaps the strongest connection comes from targeting. Based on observations from KSN, some of the victims of RedOctober are also being targeted by CloudAtlas. In at least one case, the victim's computer was attacked only twice in the last two years, with only two malicious programs – RedOctober and Cloud Atlas.

These and other details make us believe that CloudAtlas represents a rebirth of the RedOctober attacks.

Conclusion

Following big announcements and public exposures of targeted attack operations, APT groups behave in a predictable manner. Most Chinese-speaking attackers simply relocate C&C servers to a different place, recompile the malware and carry on as if nothing happened.

Other groups that are more nervous about exposure go in a hibernation mode for months or years. Some may never return using the same tools and techniques.

However, when a major cyber-espionage operation is exposed, the attackers are unlikely to completely shut down everything. They simply go offline for some time, completely reshuffle their tools and return with rejuvenated forces.

We believe this is also the case of RedOctober, which makes a classy return with Cloud Atlas.

Kaspersky products detect the malware from the Cloud Atlas toolset with the following verdicts: