## RIT Information Security

Online headquarters of Kaspersky Lab security experts.
Updated: 1 hour 52 min ago

### Animals in the APT Farm

2 hours 47 min ago

In 2014, researchers at Kaspersky Lab discovered and reported on three zero-days that were being used in cyberattacks in the wild.

Two of these zero-day vulnerabilities are associated with an advanced threat actor we call Animal Farm. Over the past few years, Animal Farm has targeted a wide range of global organizations. Victims include:

• Government organizations
• Military contractors
• Humanitarian aid organizations
• Private companies
• Journalists and media organizations
• Activists

Our colleagues at Cyphort, G-DATA and ESET have recently published blogs about Bunny, Casper and Babar, some of the Trojans used by the Animal Farm group.

The Farm includes several Trojans, which we have grouped into six major families:

Here's a brief description of the animals in the farm:

• Bunny - an old "validator"-style Trojan used with a PDF zero-day attack in 2011.
• Dino - a full-featured espionage platform.
• Babar - the most sophisticated espionage platform from the Animal Farm group.
• NBot - malware used in a botnet-style operation by the group. It has DDoS capabilities.
• Tafacalou - a validator-style Trojan used by the attackers in recent years. Confirmed victims get upgraded to Dino or Babar.
• Casper – the most recent "validator"-style implant from the Animal Farm group.

The group has been active since at least 2009 and there are signs that earlier malware versions  were developed as far back as 2007.

Over the years we have tracked multiple campaigns by the Animal Farm group. These can be identified by a specific code found either in the malware configuration or extracted from the C&C logs.

Most recently, the group deployed the Casper Trojan via a watering-hole attack in Syria. A full description of this zero-day attack can be found in this blog post by Kaspersky Lab's Vyacheslav Zakorzhevsky.

In addition to these, the Animal Farm attackers used at least one unknown, mysterious malware during an operation targeting computer users in Burkina Faso.

KSN & Sinkholing statistics

During the investigation we sinkholed a large number of C&C servers used by the Animal Farm group. This allowed us to compile a comprehensive picture of both targets and victims.

The malware known as Tafacalou (aka "TFC", "Transporter") is perhaps of greatest interest here, because it acts as an entry point for the more sophisticated spy platforms Babar and Dino. Based on the Tafacalou infection logs, we observed that most of the victims are in the following countries: Syria, Iran, Malaysia, USA, China, Turkey, Netherlands, Germany, Great Britain, Russia, Sweden, Austria, Algeria, Israel, Iraq, Morocco, New Zealand, Ukraine.

What does "Tafacalou" mean?

"Tafacalou" is the attacker's internal name for one of the validator (1st stage) Trojans. We tried various spellings of this word to see if it means anything in a specific language, and the most interesting option is one with its origins in the Occitan language: "Ta Fa Calou."

The expression "Fa Calou" is the French interpretation of the Occitane "Fa Calor" which means "it's getting hot" (see http://ejournaux.blogspot.com/2008/07/la-langue-occitane-et-ses-quelques.html). 'Ta Fa Calou" could therefore be taken to mean "so it's getting hot" based on the Occitan language.

According to Wikipedia: 'Occitan is a Romance language spoken in southern France, Italy's Occitan Valleys, Monaco, and Spain's Val d'Aran; collectively, these regions are sometimes referred to unofficially as "Occitania".

Note: A detailed technical report on Animal Farm is available to customers of Kaspersky Intelligent Services.  For more information, contact intelreports@kaspersky.com

### Who's Really Spreading through the Bright Star?

Wed, 03/04/2015 - 12:14

Security researchers recently announced that that the official website for the Korean Central News Agency of the Democratic People's Republic of Korea has been serving malware disguised as a Flash Player update. The immediately conspicuous code is still active on the KCNA front page. The javascript variables at the top of the front page source code are part of an interwoven js mechanism meant to check for specific requirements before redirecting the visitor to a relative location, /download/FlashPlayer10.zip.

The malware delivery site has been live, although response to connection attempts is intermittent at best. The zip file contains two executables with the common Flash installer names.This malware has been around since the end of 2012.

What appears to be rushed attribution and pretty faux-intelligence diagrams proposes the standard hypothesis that the malware was placed there by the site's developers in an attempt to infect the endpoints of those outsiders interested in the goings-on of the DPRK. This may not be the case, because incidents are usually more complex than they seem. And clearly, this is a significant piece of the puzzle - there was human involvement in adding this web page filtering. It is not a part of the viral routines in its handful of components. Instead, the malware's trigger, system requirements, and technical and operational similarities with the more recent DarkHotel campaigns point in the direction of an external actor, possibly looking to keep tabs on the geographically dispersed DPRK internet-enabled elite.

The larger spread of victims include telecommunications network engineering staff, wealth management and trading staff, a pharmaceutical's electrical engineering staff, distributed software development teams, business management and related school faculty and IT, and many, many more.

One of the most notable characteristics is that the malware isn't being delivered to every site visitor. The delivery trigger is contingent on the absence of the legitimate Flash Player 10 or newer being present on the target's Windows system. If a user attempts to view the videos or picture slideshows linked on the bottom right pane of the front page, the user is presented with a gif in place of the desired content indicating that flash player is required. Naturally, clicking on the gif will redirect to the malicious zip file. It's also interesting that this malware has no Linux or OS X variant, deliverables are exclusively Windows executables. It's also interesting that the malware components were first detected in Nov of 2012, two months prior to the first known appearance of the Flashplayer bundle on the kcna.kp website. While we don't know definitively the exact origin of these infections, at this point, we suspect it was in fact the kcna website. There are no other known sources.

KSN data also includes few select cases where Firefox users were served up the malware while visiting a page known for cross-site scripting, described in the following section "Potential XSS-Enabled Watering Hole". Basically, the timing and resource location of this vulnerability presents the definite possibility of an external actor's intrusion.

The delivery of a zip file dependent on user interaction and self-infection initially implies a fairly low level of attack sophistication, but let's go farther than the social engineering elements of the attack and consider the victim profiling too. From this web site in particular, the attackers are initially targeting users with not only a low-level of technical expertise and general knowledge, but also tragically outdated Windows systems. Flash Player version 10 was released on October 2008, and newer browsers like Google Chrome include a more recent flash plug-in out of the box. These attacks took place in the third quarter of 2012 at the earliest.

Most likely, the intended victims are known to use outdated systems that fit these specifications. This is the case in North Korea, where Global Stats places nearly half of desktop computers systems still running Windows XP. In comparison, South Korea has a steady Windows 7 adoption rate of nearly 80% over the past year.

So what is the actual geographic spread of the malware? Well, the two main associated components mscaps.exe and wtime32.dll were detected on systems mostly in China, followed by South Korea, and Russia. We can infer that these systems were infected at some point and were victim systems of the kcna.kp spread malware:

China 450 Korea, Republic of 43 Russian Federation 25 Malaysia 20 Italy 11 India 10 Korea, Democratic People's Republic of 7 Germany 7 Hong Kong 6 Iran, Islamic Republic of 4

However, reading into the geolocation of the top hits is not as straightforward as it may seem. Reports suggest that NK elites have access to various internet providers that may geolocate their ip in Chinese, Russian, and Hong Kong IP ranges.

Potential XSS-Enabled Watering Hole

Given the recent branding of NK threat actor as the culprit of the Sony hack, original reporting has had no difficulty accepting the idea that this is an attack perpetrated from within the DPRK in order to keep track of those people interested in the official state media. Let's examine the difficulties in arriving at that conclusion.

First, the site itself was vulnerable to XSS in the early 2013 time frame, when the Flashplayer installer bundle first appeared on the site. The site's vulnerability is recorded here by "Hexspirit"  on XSSed in April 2013. As a matter of fact, the first pages we are aware of that referred to the flashplayer bundle on kcna.kp by the exact same XSS-vulnerable page were seen in Jan 2013:

hxxp://www.kcna.kp/kcna.user.home.photo.retrievePhotoList.kcmsf;jsessionid=xxx

So, the flashplayer bundle may have been delivered by any APT actor and not simply the site's governmental sponsor. Coupling that possibility with the Darkhotel APT's penchant for delivering Flashplayer installers from compromised resources, this scenario holds weight. Also, the strong possibility that the site's developers unknowingly maintained infected machines is present.

The operational angle of placing malware on the state's official news site is dependent on who is most likely to view this site or directed to it and be interested in its content -- to the point of arriving at the download trigger deep in the media section. Sure, we can consider that key elements in the international community, like dissidents, think tanks, and foreign institutions are likely to keep an eye on NK state news but their systems are unlikely to fit the Flash player requirements for the infection. We also have seen forums maintaining emotionally charged discussions containing links to photo images redirecting to the Flash installer malware. Perhaps forum participants were targeted actively in this way as well. So this watering hole attack may be focused inward, intentionally targeting the geographically-spread North Korean internet-enabled elite and other interested readers by an external threat actor.

Malware Similarities to Darkhotel APT Toolset

The original finding includes a preliminary analysis of the quirky inner workings of the malware dropper, delving into the two executables masquerading as Flash Player 10 updates. Let's go a step further and discuss the following similarities between the viral code hosted on kcna.kp and the previously documented Darkhotel malware in the following categories:

• Social engineering
• Distribution
• Data collection
• Network configuration and simple obfuscation
• Infection and injection behavior
• Timestamps and timelines

A referent for these malware similarities can be found in descriptions of the malware distributed during the DarkHotel campaigns. Comparisons follow.

Social engineering

The most blatant and obvious similarity between these campaigns is the approach of delivering spoofed FlashPlayer installers bound with backdoors from compromised server resources. This is the first page out of the Darkhotel playbook and one of its most distinct qualities now replicated in the KCNA attack. The benefits of this approach are significant, especially when considering that the malware in the case of KCNA is not digitally signed and requires express user interaction for execution.

Data Collection

On a technical level, it's interesting to recall the Darkhotel information stealer from 2012. Its purpose is to collect identifying data points from victim systems. The data points of interest to the DH information stealer are very similar to that of its KCNA equivalent (shown below):

Coincidentally, the KCNA dropper collects much the same identifying data points from victim systems. The Darkhotel item missing from this list is the 'CPU Name and Identifier', supplanted by 'time of infection'.

The Darkhotel stealer maintained the stolen data in a specific internal format of label-colon-value as follows:

The KCNA stealer maintained the stolen data in the following internal format, very similar to the Darkhotel format (label-colon-value):

Network configuration and simple obfuscation

This package's network callback includes several unusual Fully Qualified Domain Names (FQDNs). This network configuration is specifically hardcoded within wtime32.dll:

a.gwas.perl.sh
a-gwas-01.dyndns.org
a-gwas-01.slyip.net

It's interesting that the malware is configured with three connectback command & control servers, just like the network configuration of tens of the Darkhotel backdoors. Also, a very simple routine locates these strings within the wtime32.dll component's .data section and decodes them as global variables. Those strings are obfuscated within the binary with a simple XOR 0x12 loop. The later Darkhotel samples maintain a somewhat more complicated approach, but not by much. Here are strangely obfuscated strings:

Software\Microsoft\Active Setup\Installed Components
{ef2b00e3-19da-4e78-b118-6b6451b719f2}
Software\Microsoft\Windows\CurrentVersion\Run
JREUpdate
mscaps.exe
a.gwas.perl.sh
a-gwas-01.slyip.net
a-gwas-01.dyndns.org
update.microsoft.com
20
%SystemRoot%\system32
%APPDATA%\Microsoft\Protect\SETUP
%SystemRoot%\system32\gdi32.dll

Targeting Specificity

The Darkhotel actor is unusual in the varying degrees of specificity it uses to spread its malware: "This APT precisely drives its campaigns by spear-phishing targets with highly advanced Flash zero-day exploits that effectively evade the latest Windows and Adobe defenses, and yet they also imprecisely spread among large numbers of vague targets with peer-to-peer spreading tactics."

In other words, the group is surprisingly open to their worms spreading indiscriminately across entire countries, hitting tens of thousands of systems. This is also the case in the KCNA campaign wherein malware is positioned in a way meant to attract a specific target audience with uncommon system requirements and yet the malware itself is designed to spread indiscriminately (via a mechanism described below).

Infection and Injection Behaviors

Much like the Darkhotel toolset, the KCNA malware includes viral code. The routine is maintained in the fil.dll code. After sleeping for a couple of minute intervals, the code repeatedly looks through attached network drives for executables to infect. It infects these files with its explorer shellcode and the @AE1.tmp dropper itself. It's a strange infection strategy --notably, the shellcode blob does not transfer control back into the original file.

The injection behavior is both intricate and indiscriminate as the malware not only infects executables on network shares but also locally. As an example, the size of an infected Skype installer on a network drive increased in size from its original 1,513 kb to 3,221 kb.

Great strides, however inelegant, were taken in adding to the malware's injection capabilities beyond simple executables. For this purpose, the malware drops a copy of command-line WinRar version 4.1.0 (released January 2012) in %USERS%\AppData\Roaming\Microsoft\Identities\\Rar.exe. This Winrar software is used in order to access ZIP, RAR, ISO, and 7Z files in search of any executable contents to infect. Archives in the aforementioned formats containing executables are infected and then repackaged under their original filenames but with their new executable contents under the Daws.awfy scheme.

All resultant infected files are detected by our products as Trojan-Dropper.Win32.Daws.awfy. Several networks were affected by this viral code, and almost one thousand unique md5s representing related infected files across various systems were recorded as "Trojan-Dropper.Win32.Daws.awfy".

Viral Victimology

Given the malware's viral propagation capabilities, we can distinguish the infection spread data above, which relates directly to the Flashplayer hosted on KCNA, from the malware's viral spread through network shares and removable drives. While each count in this list represents a unique organization or system that detected a set of KCNA-viral infected files on their drives, the total infected file detection count is almost 20,000 files. Focusing on the Daws.awfy spread, we get a different picture of the malware's reach:

Country Systems and organzations encountering infected files China 481 Malaysia 51 Russia 47 Korea, Republic of 34 Taiwan 14 Senegal 14 Korea, Democratic People's Republic of 11* India 9 Mexico 9 Qatar 9

It's important to note the different conditions that apply to North Korea. First of all, the limited IP space means that multiple unique systems share IP addresses --in the case of DPRK victims above, the number is based on unique systems instead of unique IP addresses. Next, we attribute the relatively low number of network-based infections to the restrictive policies that keep many users from connecting to the larger Internet from KP ip ranges in the first place. A network- and usb-based viral infector is a great tool for a malicious actor to use the few front-facing systems in order to infect computers on an isolated intranet, like the one connecting most machines inside NK. However, that very isolation makes it impossible to precisely quantify the malware's success inside that intranet at this time.

Timestamps and timelines

KCNA malware dropper compilation timestamp: Tue, 13 Mar 2012 02:24:49 GMT.
Darkhotel information stealer compilation timestamp: Mon, 30 Apr 2012 00:25:59 GMT.

Also interesting is that mostly all of the additional KCNA malware related components were compiled in mid-March 2012.

The first Darkhotel APT spoofed flashplayer installer incidents recorded in our KSN data began in 2012 and peaked in 2013. This KCNA incident would fall in the peak timeframe for this type of offensive activity for Darkhotel.

Noteworthy Components

In addition to the legitimate flash player upgrade that this archive maintains, the backdoor components that it drops to disk and executes seem to be clustered as Windows Live components (i.e.: Defender, IM Messenger). The two most interesting dropped files are the following:

78d3c8705f8baf7d34e6a6737d1cfa18,c:\windows\system32\mscaps.exe
978888892a1ed13e94d2fcb832a2a6b5,c:\windows\system32\wtime32.dll

The mscaps.exe component's reboot persistence setting is added to the registry here: HKLM\SOFTWARE\Microsoft\Active Setup\Installed Components\{a96adc11-e20e-4e21-bfac-3e483c40906e}, where its stubpath is set to '"C:\WINDOWS\system32\mscaps.exe"  /s /n /i:U shell32.dll'. This setting ensures that every time the explorer.exe shell is started or restarted on the system, this executable injects its code.

Other analyses of this malware failed to mention the presence of Madshi's madCodeHook. It is a legitimate commercial DLL injection and api hooking framework, in this case used to inject the att.dll spyware component specifically into the following communications applications:

• Internet Explorer -- iexplore.exe, ieuser.exe
• Mozilla Firefox, firefox.exe
• Microsoft Outlook Express, msimn.exe
• Microsoft Outlook, outlook.exe
• Windows Mail, winmail.exe
• Windows Live Mail, wlmail.exe
• MSN Messenger, msnmsgr.exe
• Yahoo! Messenger, yahoomessenger.exe
• Windows FTP Client, ftp.exe

The LoadLibraryExW hook is placed here:

The hook jmp listed here:

Related string parsing loop here:

Other analysis notes that ws2_32.dll, or the winsock2 library, is dropped to disk and copied to mydll.dll. The reason for this is most likely to maintain stable Winsock2 hooks across Windows OS. In the past, some madCodeHooks set on Winsock2 api proved to be unstable, so these guys just include one that they know works.

This implementation throws a wrench in the works, it is certainly a dissimilarity. The madCodeHook library was not observed in Darkhotel malware.

The wtime32.dll component is dropped to disk and loaded at startup into explorer.exe. It is then injected into each of the listed "interesting" processes. It is a very interesting bot component, communicating with its three c2 domains and listening for further commands. It maintains 13 primitive interactive bot commands:

Command Command Description cmd run provided cmd and output to file as a part of newly created and killed process, i.e. "cmd /c tree > file 2>&1" inf collect system information - operating system version, username, computername, system drive, local time, all connected drives and properties, network adapter properties, disk free space, enumerate all installed programs as per-user or per-machine cap capture screenshot and send to c2 dlu incomplete function dll open a process with all access, write a dll to memory and remotely create thread (load a dll into a remote process) put receive, decrypt, and write specified file to disk got report status on retrieved file get collect, encrypt, and retrieve specified file exe run provided executable name with WinExec del record file attributes to specified c2 and delete specified file dir record and report to c2 all files in current directory tree and their attributes: filename, file size, last write time, archive or directory, hidden, system quit exit thread prc process request

Its functionality includes older technologies used here that we just don't see anymore. Not only does it provide for NTFS, FAT32, FAT16, and FAT filesystem I/O routines, but it implements the older FAT12 I/O routines as well. Low level Windows95 raw disk access is enabled with CreateFileA on \\.\vwin32 through the vwin32 virtual driver.

Finally, the KCNA malware does have a unique trick up its sleeve. Its dropped components' ability to scan connected drives and network shares to copy their contents and deliver a special something to further its spread. So in its own crude way, this malware could hop across usb-enabled air-gapped networks by infecting both executables and archives on usb sticks.

Conclusions

The KCNA incident and the related viral bot's spread leaves more questions than solid answers. Chalking this campaign up to DPRK operations is certainly a simplistic thing to do and unsupported here. The possibility for the spread of an internal network virus or the possibility of an XSS-enabled website compromise are both high. Some similarities with the Darkhotel toolset are present, including the network configuration, spoofing technique, as well as the format and selection of stolen data. Were these to be related campaigns, particularities of the KCNA malware show that the Darkhotel actor may still have some tricks up its sleeve.

Appendix

Components Dropped by the KCNA Malware

78d3c8705f8baf7d34e6a6737d1cfa18, mscaps.exe, Tue, 12 Apr 2011 09:15:59 GMT
978888892a1ed13e94d2fcb832a2a6b5, wtime32.dll, 213kb, Trojan.Win32.Agent.hwgw, CompiledOn:Wed, 29 Feb 2012 00:50:36 GMT
2d9df706d1857434fcaa014df70d1c66, arc.dll, 1029kb, Trojan.Win32.Agent.hwgw, CompiledOn:Tue, 13 Mar 2012 02:34:00 GMT
fffa05401511ad2a89283c52d0c86472, att.dll, 229KB, Trojan.Win32.Agent.hwgw, CompiledOn:Tue, 13 Mar 2012 02:24:32 GMT
1fcc5b3ed6bc76d70cfa49d051e0dff6, dis.dll, 120.kb, Trojan.Win32.Agent.hwgw, CompiledOn:Tue, 13 Mar 2012 02:24:36 GMT
d0c9ada173da923efabb53d5a9b28d54, fil.dll, 126kb, UDS:DangerousObject.Multi.Generic, CompiledOn:Tue, 13 Mar 2012 02:24:41 GMT
daac1781c9d22f5743ade0cb41feaebf, launch.exe, 172KB, HEUR:Trojan.Win32.Generic, CompiledOn:Tue, 13 Mar 2012 02:24:52 GMT
6a9461f260ebb2556b8ae1d0ba93858a, sha.dll, 89KB, Trojan.Win32.Agent.hwgw, CompiledOn:Tue, 13 Mar 2012 02:24:43 GMT
f1c9f4a1f92588aeb82be5d2d4c2c730, usd.dll, 99KB, Trojan.Win32.Agent.hwgw, CompiledOn:Tue, 13 Mar 2012 02:24:46 GMT
59ee2ff6dbac2b6cd3e98cb0ff581bdb, WdExt.exe, 1.66MB, Trojan.Win32.Agent.hwgw, CompiledOn:Tue, 13 Mar 2012 02:24:49 GMT
f415ea8f2435d6c9656cc6525c65bd3c, wtmps.exe, 1.94MB, Trojan-Dropper.Win32.Daws.awfy, CompiledOn:Mon, 05 Mar 2012 08:37:55 GMT

Related MD5s, Domains, and Detections

Trojan.Win32.Agent.hwgw
78d3c8705f8baf7d34e6a6737d1cfa18, mscaps.exe
2d9df706d1857434fcaa014df70d1c66, arc.dll
1e7c6907b63c4a485e7616aa04351da7, @aedf66.tmp.exe
1fcc5b3ed6bc76d70cfa49d051e0dff6, dis.dll
523b4b169dde3bcab81311cfdee68e92, wdext.exe
541989816355fd606838260f5b49d931, wdext.exe
5e34f85278bf3504fc1b9a59d2e7479b, wdext.exe
6a9461f260ebb2556b8ae1d0ba93858a, sha.dll
78ba5b642df336009812a0b52827e1de, wdexe.exe
7f15d9149736966f1df03fc60e87b8ac, wdext.exe
7f3a38093bd60da04d0fa5f50867d24f
82206de94db9fb9413e7b90c2923d674
a59d9476cfe51597129d5aec64a8e422, @ae465f.tmp.exe
f1c9f4a1f92588aeb82be5d2d4c2c730, usd.dll

Trojan-Dropper.Win32.Daws.awfy
2f7b96b196a1ebd7b4ab4a6e131aac58
8948f967b61fecf1017f620f51ab737d
...and almost 800 other executables that were infected on network shares and attached drives

c2 Domains
a.gwas.perl.sh,211.233.75.83
a-gwas-01.dyndns.org
a-gwas-01.slyip.net

### Skyfall Meets Skype

Wed, 03/04/2015 - 10:14

The portmanteau-named SKYPEFALL.EXE is the latest, very active, malware-spamming campaign spreading through Skype. We first registered this attack on March 3 using both Spanish and English to lure victims. How does this attack work?

The victim receives a Skype message in the following format:

Dios Mio! [user name in Skype] video: http://********skype.info/video/?n=[user name in Skype]

Oh, My God ! [user name in Skype] video: http://********skype.info/video/?n=[user name in Skype]

If they click on the link and use Internet Explorer, it leads them to a fake video Website full of fabricated comments meant to peak the users interest while inviting the victim to download a plugin in order to watch the video itself:

Again, the URL used in the malicious message sent through Skype is available only if the browser referrer points to Internet Explorer. If the victim uses any other browser, the URL is simply unavailable.

The initial setup.exe is a RAR auto-extractible file with embedded instructions. It includes a full GUI installation package.

The victim receives both Adware-like functionality as well as Backdoor capabilities. Once it is installed on the victim's machine, it abuses the new victim's Skype friends list to continue spamming the aforementioned messages. The instructions for its behavior are downloaded from another server and look like this:

{
"skype_restart_mins": 120,
"old_friend_hours": 48,
"del_msgs_limit": 5,
"send_strategy": 1,
"max_loc_msgs": 60}

The malware also includes an embedded SMTP client that would potentially allow the attackers to send spam through the victim's machine.
The attackers leading this campaign are changing this binary on the Web every few hours. In this way, they are trying to evade any consistent AV detection.

### Dating Lisa for 1 Euro

Wed, 03/04/2015 - 10:11

Last night I got a unexpected SMS in German language on one of my phones. A message from "Lisa", pretending to know me, including an url luring the reader to a picture of her.

The short-url points to the domain "m.bensbumsblog.com", which is already known for being used in SMS-spam for dating-websites, redirecting to a dating website. As there was no preregistration or request for this SMS, this clearly belongs into the category unsolicited bulk message.

The final target of the link is "daily-date.de". This website requires registration (username, password, mail-address and several personal questions). Finally it offers premium access to the system, which means searching, meeting and texting people as well as watching pictures, not for free though. This campaign offers a 14-day trail for 1€.

The domain "bensbumsblog.com" is protected by an anonymizing service to avoid identifying the owner. Although the IP-address is owned by a cloud service (according to RIPE lookup) and rented by some marketing company (IP reverse lookup).
The final website "daily-date.de" belongs to a German company, located in Berlin.
A look at the click-statistics from "bit.ly" shows that this campaign started on 03.03.2015 and got more than 10,000 clicks within 18 hours, most of them from Germany. Most clicks appeared in the first 3 hours of the campaign (started around 18:00 CET).

The "bit.ly"-user "benbu", who setup this Link, already created 15 Bitlinks/Short-URLs (active since 2nd of march 2015).

Amount of Bitlinks Target/Campaign 6 DailyDates (this campaign) 1 Easy money/credit cards 8 Coupons

Spam is a common problem, not only via email. Although SMS-Spam is more common in Asia but less common in Europe.

Having a look at other campaigns by this user, not all were successful. Besides this campaign, 6 others got some clicks. All mostly targeting Germany.

Created Target/Campaign Clicks 02.03.2015 Coupons 2630 02.03.2015 Coupons 1764 02.03.2015 Coupons 250 02.03.2015 DailyDates 993 03.03.2015 Coupons 1878 03.03.2015 Coupons 1004

In general make sure that you don't just click on any link you get as there might also be malicious content behind. To improve protection of your mobile (smartphone/tablet) always ensure you install updates. Further you should have security software installed to be protected against mobile malware.

### Threats to Children Online: The Danger is Real

Wed, 03/04/2015 - 06:00

The Internet has long ceased to be the preserve of grown-ups. Children today are often far more active Internet users than their parents. But is it safe enough for children to use without fear of facing inappropriate content? To find out we decided to investigate potential online threats to children.

The research is based on data processed by our Kaspersky Security Network. We analyzed data from more than a million Kaspersky Lab customers. Each of them had encountered dangerous content at least once in the last year.

The results show that more than half (59.5%) of users encountered pornography; over a quarter (26.6%) landed on websites dedicated to gambling; every fifth user stumbled across sites featuring weapons; and almost the same number were confronted by strong language.

Percentage of users worldwide encountered dangerous content in 2014

Two thirds (67.29%) came across chat services. Only a small proportion of these services, such as those with anonymity functions or predominately adult subscribers, represent a potential threat to children. As a result it is difficult to take overall chat service encounters as an accurate indication of the level of risk to young people.  However, the data does confirm the popularity of chat; and the greater the popularity of chat services in any given country, the greater the probability that children might occasionally or even intentionally enter into an unsafe chat environment. So, if nothing else, evidence of frequent encounters with chat services could be a sign for parents to pay more attention to the nature of these services and the likelihood of their child being drawn in.

Websites carrying these kinds of inappropriate content (adult, chat, gambling and weapons), along with others featuring drugs, tobacco and alcohol, were the ones blocked most often by Kaspersky Lab protection solutions. The frequency of detections demonstrates just how easy it is for users to encounter such content online. The higher the frequency: the greater the probability.

The most frequent use of parental controls were from China, USA, German, the UK and Russia #KLReport

In geographical terms, the countries with the most frequent Parental Control detections were China, the USA, Germany, the UK and Russia. France, Vietnam, Brazil and Algeria also ranked in the top ten in terms of inappropriate content detection – but were relatively safer due to a lower frequency of detection.

Each of the top ten most affected countries has its own distinct characteristics when it comes to the prevailing online threats for children. For instance, adult content was the biggest threat to users in Germany (with 172 detections per user), China (144.18 detections per user), and the US (126.16 detections). Content about alcohol, tobacco and drugs was a major threat to users from Russia, Germany, the USA and France. The frequency of detection was especially high in these countries. This kind of content also proved popular in Brazil and the UK.

Parents should choose parental control solutions to help protect their children #KLReport

The fact that the threat landscape for children changes significantly from country to country is one of the most remarkable findings to emerge from the research. It is a clear sign for parents around the world to pay special attention to what their children are doing online in their own country, as every situation will be different. To protect young people, we recommend that adults choose protection solutions with Parental Control technologies and make full use of safe "children" modes in search engines and applications that allow access to multimedia content and which are used by children.

However, although Parental Control technologies can block access to web sites with content that is dangerous or distressing for children, they cannot offer reliable protection in situations where safe-by-default web services like social networks or chats are misused by predators or users conducting cyberbullying campaigns.

Internet security deserves to be taken as seriously as real-life physical security #KLReport

Internet security deserves to be taken as seriously as real-life physical security. That's why we urge parents to take an active part in their children's real and digital lives.  Only then can they be sure that they won't miss the moment when their child might need their support.

Read more about online threats to children in the full text of the research.

### The Enemy on your Phone

Thu, 02/26/2015 - 05:00

Many people believe that there are no malware programs on smartphones. There was a time when there was some truth in this. A few years ago mobile platform operators originally designed their products with very high security levels. Mobile operating systems did not allow malicious programs to easily seize control and make themselves at home on devices.

Sadly that's no longer the case. Mobile devices are fundamentally different, they can do much more. A modern smartphone is a full-blown working tool, an entertainment center and a tool to manage your personal finances. The more it can do, the more attractive it is to cybercriminals. They want to steal a slice of that pie and the more tempting the prize, the more they create malicious applications, and invent methods to infect computers and to distribute malware.

Since Q1 2012, the number of malicious programs has grown more than tenfold, to exceed 12,000,000 in Q4 2014

The evidence for this is clear when we look at the rapid growth in the numbers of mobile Trojans. The rate of growth is impressive: since Q1 2012, the number of malicious programs has grown more than tenfold, to exceed 12,000,000 in Q4 2014.

The number of detected malicious installation packages

Looking at the types of malicious programs is also revealing. It is easy to see that SMS Trojans and multi-purpose backdoors are giving way to malicious adware and Trojan bankers. However, just because a specific type of malware is losing its market share, this doesn't mean it is disappearing: it should be also remembered that the overall number of malware programs targeting mobile devices keeps growing.

Distribution of mobile malware by function (files from Kaspersky Lab's collection)

Malware writers don't create tons of malicious programs to build up a private collection or show off on some forum. All malware programs find their victims, and it is at times surprising to see how a seemingly innocuous loophole can allow them onto users' mobile devices.

Do it yourself

Believe it or not, users often infect their mobile devices with their own hands.

The ways to get malicious code on a regular computer without any user involvement are well known. Cybercriminals hack websites, users visit the sites and a hidden frame is opened in their browsers to download malware on to the victim machine using an arsenal of exploits.

On mobile platforms, everything is different. The underlying principles behind these platforms mean there are almost no vulnerabilities that would enable cybercriminals to attack a device without the user's knowledge and consent. So criminals need some help from users: Trojans must be installed and launched by their intended victims. It's like the old joke about the first, primitive virus: 'please delete all your important data and reformat your hard drive'.

A classic method to make money with mobile malware is to send premium-rate SMS messages from your phone

Installing programs is one of the weakest places in mobile platforms, especially Android. Under iOS, you have to spend time fiddling around before you can install a program from anywhere other than App Store; however, Android allows users to do that by checking just one box in the settings. Once that's done, the system will check the digital signature of any installation package, and theoretically that should protect your device against malicious programs. But here's the snag: there are no Android certification centers, so anyone can create their own signature. Of course cybercriminals just sign off their own security confirmation and the installation goes ahead without a hitch when the user clicks 'OK'.

And many users do click 'OK'. After all, it's often easier than investigating everything about the app you're allowing onto your device.

Information security is usually far from the thoughts of a regular user. People love a bargain and find it hard to resist a free download of a useful program or a favorite game from some helpful-looking website. Often the application, once installed, will work as expected, except that money is drained from the phone's account at an alarming rate, and the user's credit card will soon get empty… Or, if users are invited to watch an exclusive video on an interesting site, perhaps they'd take a minute to update their Flash Players?

Fake Adobe Flash Player update page. Users are told to update an outdated version of Flash Player on their devices

Inexperienced users do not know that the update process for software on smartphones is different than on computers, so cybercriminals can trick them into installing anything under the guise of a useful upgrade.

Cybercriminals are extremely aggressive and astute when pursuing their targets: malicious applications are typically distributed in the form of various tempting software programs, games, porn clips or players for watching porn.

Where to find malware

Since users have to install malicious programs on their smartphones with their own hands, cybercriminals need to somehow entice them to a web resource where the malware is available. "Black SEO" is one of the methods used to do that. Black SEO is a type of search optimization that encourages search engines to display a link to the preferred malicious resource at the top of the search results. As soon as the site receives a top position in the search results, a harvest of unwitting users can be reaped.

A bored user types "Android games download" in a search engine and receives a link to web-site in the first or second line at the top of search results. That site may indeed contain games, but they come with some unpleasant extras. People tend to trust the sites from the top lines of search results. Users think that since thousands of people visit a web-site, it will also have the game or program they are looking for. Users do not think about security. That's a big mistake.

To bring the malicious site to the top of the search results, cybercriminals often use botnets: thousands of bots send search requests to Google and Yandex and visit the cybercriminals' site, boosting its ranking. Links to the cybercriminals' site are also published on all types of forums, bulletin boards, and in comments on news sites. The crawler bots of search engines find them there, so the rankings grow even faster.

Of course search engines try to stop this abuse of their services. They block hundreds of malicious sites. But that's not a big problem for cybercriminals: they keep creating and promoting new sites with the help of automatic tools.

SMS spam is yet another means of enticing users to sites containing malicious applications. It could be a simple, non-targeted mass-mailing of messages containing a link to the site: at least some of the recipients will follow the link. As soon as such program lands on somebody's smartphone, it will start to send SMS messages containing the malicious link to the owner's entire contact list. A message from a person you know raises few suspicions, especially if the text looks natural, so many do indeed follow the link they received, hoping to see some photos or jokes that their friend is sharing. But once opened, the site actually hosts malware samples from the cybercriminal.

Another method allows cybercriminals to exploit the popularity of legitimate resources. Cybercriminals hack popular online resources high visitor traffic, such as news sites, online stores, specialized portals. If the site's software contains known vulnerabilities, a code is embedded to the page and redirects the users to another site containing malware. If no vulnerabilities could be found, cybercriminals can still try to steal the site admin's credentials by using phishing and social engineering. If they succeed they can do anything to the site, including posting malware on the site itself.

Fake Android Market

In addition mobile malicious applications are distributed "almost honestly" – via app stores. This might be a legitimate program containing embedded malicious code; a specially created application which imitates some useful functionalities; or a bare-bones malicious program, with just a name and an icon as a camouflage.

Such programs are usually uploaded to unofficial app stores which either neglect security measures altogether or only take a cursory look at the content that gets published. However, there have been cases when dangerous programs got uploaded to official app stores – Google Play and even Apple App Store, which is historically more secure. Naturally, the manufacturers promptly clean their stores, but cybercriminals never sit on their hands either.

How cybercriminals make money

Once malware lands on your smartphone, it starts its mission of making money for its owner, naturally at your expense. A modern mobile device is a real goldmine for a cybercriminal; it only takes the appropriate mining skills.

Mobile malware: methods of making money

Expensive tricks

The least damaging money-spinner used by cybercriminals is obtrusive adware. It doesn't do much harm, but it doesn't take long for all those pop-up ads to get annoying. Getting rid of them is often more of a challenge: it takes quite an effort to find out which program is actually producing the banners. It could be Angry Birds HD, or it could be that something that has a name you cannot read aloud and masquerades as a system application.

There is also a curious category of fake apps that do nothing at all – neither good nor bad – but still cost good money. Some of these are clear dummies on offer in paid-apps sections of application stores, like a program that promises to make you rich but only displays an image of a diamond on the smartphone's screen. Others pretend to be useful applications, such as antivirus programs, and demand payments from the user for protection against Trojans that have supposedly overrun the device.

A classical method to make illegal money with mobile malware is to send SMS to premium-rate numbers. A Trojan running on your phone simply sends several premium-rate SMS messages and drains your account. Your phone service provider sends money from your account to the renter of the premium-rate number (the cybercriminal) without asking any questions, since premium-rate numbers are still a popular way to pay for different types of online services.

Ransomware Trojans for PCs are abundant. Recently, they've started emerging on mobile devices. The scam is simple: once installed on your mobile device, the Trojan displays a screen making threats and demanding a ransom. You can no longer work with your device. All you can do is to enter the special code that they promise to send you as soon as you pay them a specified amount of money.

Message displayed by this ransomware sample: "Your phone has been blocked for viewing banned porn (Pedophilia, Zoophilia)! All photo and video materials have been sent for further investigation. To unblock your phone and delete this material, you must pay a 1,000-ruble fine within 24 hours. To do this, top up number XXXX at the nearest payment kiosk. Warning! If the fine is not paid, all data will be made public"

It is impossible to delete the Trojan unless you hard reset the settings and the contents of the device's flash memory. For many the value of the data on the device makes it worth paying the ransom. However, the cybercriminals do not always send the unblock code even after the ransom is paid.

However, none of the above scams are anything like as costly as this relatively new way of stealing from mobile device owners. In recent years mobile banking services have become increasingly popular. Every major bank has developed an app that allows clients to manage their money from their smartphone or, at the very least, use SMS banking services.

Mobile banking #malware threats increased since 2013 - from less than 100 to 13,000 by Oct. 2014

Suddenly many smartphones are the key to bank accounts – often to several accounts at the same time. This offers many opportunities to make illegal profits – and promises greater rewards than the traditional SMS and ransomware scams of old. Not surprisingly, cybercriminals have been quick to embrace this new opportunity.

The statistics clearly show how much interest mobile virus writers have in users' bank accounts. At the start of 2013, there were less than a hundred Trojan bankers in Kaspersky Lab's collection; at the October 2014, there are more than 13,000 of them.

The number of detected banking malware programs

Banking Trojans are enjoying a surge in popularity all over the world but Russia is facing the brunt of this boom. Russia is a place where malware writers test-run their creations before using them in other countries.

Geography of mobile banking threats. January – October 2014
(Number of attempted installations of banking Trojans)

For cybercriminals, SMS banking is the easiest path to other people's money. It doesn't even require new tools – existing SMS Trojans work just fine. Banks often assume the client's phone is a trusted environment and follow SMS instructions without query.. Clients can send money from their bank accounts to their own or somebody else's mobile phone account. Using that feature, the cybercriminals send an appropriate SMS and send money from the victim to their phone number. After that it is easy to withdraw the money using advanced mobile payment systems.

Quite often, banking Trojans work in partnership with computer Trojans; Faketoken is one example. When the user's computer is infected with a banking Trojan it waits until they visit their online banking account. Then the malware program becomes active and displays a window to the user, asking them to download an Android application which is allegedly required to securely confirm the transaction. Gullible users obediently install Faketoken on their smartphones. After that it is only a matter of time: the malware on the computer steals the credentials, and the cybercriminals gain access to the user's banking account. They make a transaction and Faketoken intercepts the one-time confirmation code (mTAN) sent by the bank in an SMS. In the end some Vasily P. collects a hefty sum of money divested from the user's account, and cashes it immediately at an ATM. We saw this piece of malware attacking users in 55 countries, including Germany, Sweden, France, Italy, the UK and the USA.

A third method is to use independent mobile banking Trojans which can masquerade as a mobile banking applications or simply spoof the banking application's interface. The Trojan gets hold of the users' credentials and sends the information to its C&C server. The cybercriminal uses the intercepted data to make a transaction. Svpeng is a good example of this tactic. This mobile Trojan opens a window on top of a legitimate application window, imitating the banking applications of the largest Russian and Ukrainian banks.

Phishing window imitating the bank's own application

Using these programs, cybercriminals can strip you of all your savings in an instant, drain your accounts and close your deposits. They can also put you in debt by running up your entire available credit.

Don't dig a hole for yourself

The proportion of malicious applications among all applications installed by users varies from country to country. Here are the figures for some countries for January – October 2014 (according to Kaspersky Security Network data):

Vietnam 2.34% Switzerland 0.36% Poland 1.88% India 0.34% Chezh 1.02% Canada 0.23% France 0.84% Germany 0.18% Belgium 0.74% Brazil 0.17% China 0.73% Italy 0.09% Ukraine 0.70% Austria 0.07% Russia 0.69% USA 0.07% Mexico 0.62% Hong Kong 0.05% Spain 0.54% New Zeland 0.05% Belarus 0.50% Norway 0.04% Iran 0.38% Japan 0.01%

The fact is it's fairly easy to protect yourself against all these sophisticated mobile threats. Mobile platform developers have taken good care of security and the user is often the weakest link in the security chain. This is good and bad at the same time. It's a problem because many users don't pay much attention to their security. But the plus side is that you only need to follow a few simple recommendations to safeguard yourself against all the above threats.

We recommend that you follow the following simple rules.

• Do not jailbreak / root your smartphone. While it will give you extra opportunities on your phone, it will also give the green light to cybercriminals.
• On an Android phone, disable the option of installing software from untrusted sources.
• Install a mobile security product on your phone. It will analyze all applications before installation.
• Try not to follow any links arriving in SMS, even if they come from people you know.

### Equation Group: from Houston with love

Thu, 02/19/2015 - 04:00

In 2009, an international scientific conference on Energy and Space technologies was held in Houston, USA. Leading scientists from several countries were invited to attend. As is traditional for such events, the organizers sent out a post-meeting CDROM containing a presentation with the best photos from the event. It is unlikely that any of the recipients expected that while they were enjoying the beautiful pictures and memories a nation-state sponsored Trojan Horse was activating silently in the background.

Photo slideshow played from the CD

Interestingly, it looks as if most of the attendees brought pens and paper instead of laptops.

Self-elevating Autorun

The disk contains two files in the root folder, an autorun.inf and autorun.exe. This is typical of many CDROMs. The autorun.inf simply executes the main EXE from root.  Here's what it looks like:

[AutoRun]
open=Autorun.exe
icon=Presentation\Show.exe,0

More interesting is the autorun.exe binary, which has the following attributes:

Date of compilation 2009.12.23 13:37:33 (GMT) Size 62464 bytes MD5 6fe6c03b938580ebf9b82f3b9cd4c4aa

The program starts by checking the current user's privileges. If the current user has no administrative rights, it tries to elevate privileges using three different exploits for vulnerabilities in the Windows kernel. These vulnerabilities were patched by the following Microsoft patches:

• MS09-025
• MS12-034
• MS13-081

Considering the date the CDROM was shipped, it means that two of the exploits were zero-days. It's notable that the code attempts different variants of kernel exploits, and does so in a loop, one by one, until one of them succeeds. The exploit set from the sample on the CDROM includes only three exploits, but this exploitation package supports the running of up to 10 different exploits, one after another. It's not clear whether this means that there is also a malware with 10 EoP exploits in it, or whether it's just a logical limitation.

The code has separate payloads for Windows NT 4.0, 2000, XP, Vista and Windows 2008, including variations for certain service pack versions. In fact, it runs twice: firstly, to temporarily elevate privileges, then to add the current user to the local administrators group on the machine, for privilege elevation persistence.

Such attacks were crafted only for important victims who couldn't otherwise be reached #EquationAPT #TheSAS2015

If these actions are successful, the module starts another executable from the disk, rendering the photo slideshow with pictures from the Houston conference.

At the end, just before exiting, the code runs an additional procedure that does some special tests. If the date of execution fell before 1 July 2010 and it detects no presence of Bitdefender Total Security 2009/2010 or any Comodo products, it loads an additional DLL file from the disk named "show.dll", waits for seven seconds, unloads the DLL and exits.

If the date fell after 1 July 2010, or any of the above products are installed, it drops execution immediately.

The "Show" Begins – introducing DoubleFantasy

The main loader and privilege escalation tool, "autorun.exe" fires up a special dropper, which is actually an Equation Group DoubleFantasy implant installer. The installer is stored as "show.dll" in the "Presentation" folder of the CDROM.

The DLL file has the following attributes:

Date of compilation 2009.03.20 17:42:21 (GMT) Size 151'552 bytes MD5 ef40fcf419954226d8c029aac8540d5a Filename show.dll Short Description DoubleFantasy installer

First it locates data in the resource section, unpacks (UCL) and XOR-decrypts configuration data from one of the resources.

Next it creates the following registry keys:

• HKEY_LOCAL_MACHINE\Software\Classes\CLSID\{6AF33D21-9BC5-4f65-8654-B8059B822D91}
• HKEY_LOCAL_MACHINE\Software\Classes\CLSID\{6AF33D21-9BC5-4f65-8654-B8059B822D91}\Version

After that it sets the (Default) value for "Version" subkey as "008.002.000.003", which identifies the implant version.

It also attempts to self-delete on the next reboot, which fails if it's started from the CD.

When run by the exploitation package "Autorun.exe", the program already has administrative privileges from one of the three exploits. However, the code checks again if it's running with administrative privileges, and attempts to elevate using just two kernel vulnerabilities:

• MS09-025
• MS12-034

This indicates that the DoubleFantasy installer has been designed to run independently from the disk from Houston with its "Autorun.exe".  In fact, we've observed the independent use of the DoubleFantasy installer in other cases as well.

The installer checks for security software using a list of registry keys and values stored in the resource section. The keys are checked in quite a delicate "non-alarming" way using key enumeration instead of direct key access. List of top level keys checked:

• HKLM\Software\KasperskyLab\protected\AVP7\profiles\Behavior_Blocking\profiles\pdm\settings
• HKLM\Software\KasperskyLab\AVP6\profiles\Behavior_Blocking\profiles\pdm\settings
• HKLM\Software\Agnitum\Outpost Firewall
• HKLM\Software\PWI, Inc.
• HKLM\Software\Network Ice\BlackIce
• HKLM\Software\S.N.Safe&Software
• HKLM\Software\PCTools\ThreatFire
• HKLM\Software\ProSecurity
• HKLM\Software\Diamond Computer Systems
• HKLM\Software\GentleSecurity\GeSWall

If any of them exist, the installer will mark the system by setting a special registry key:  HKEY_LOCAL_MACHINE\Software\Classes\CLSID\{6AF33D21-9BC5-4f65-8654-B8059B822D91}\MiscStatus

The mark will be in the form of {CE0F7387-0BB5-E60B-xxxx-xxxxxxxxxxxx} for the (Default) value data and will then exit.

If no security software is identified, it will unpack (UCL) and XOR-decrypt the main payload, which is extracted into %system%\ee.dll.

The module looks as if it was built using a set of components or libraries that perform:

• Privilege escalation (it seems to be an early version of the same lib used in autorun.exe)
• Security software detection
• Resource parsing and unpacking

This library code supports Win9x and the Windows NT family from NT4.0 to NT6.x. It should be mentioned that these libraries are not very well merged together. For instance, some parts of the code are unused.

Here's what the DoubleFantasy decoded configuration block looks like:

Decoded DoubleFantasy configuration block

Some of the C&Cs from DoubleFantasy configuration:

• 81.31.34.175 (Czech Republic)
• 195.128.235.231 (Italy)

The DoubleFantasy malware copied into the victim's machine has the following properties:

Date of compilation 2009.03.31 15:32:42 (GMT) Size 69'632 bytes MD5 b8c0eb946de83fe8440fefbacf7de4a2 Filename ee.dll Short Description DoubleFantasy implant

It should be noted that both the installer and the malware appear to have been compiled several months before "autorun.exe" from the CDROM, suggesting that they are more or less generic implants. It also suggests that the "autorun.exe" was probably compiled specially for the CDROM-based attack.

The DoubleFantasy Malware is the first step in the infection of a victim by the #EquationAPT Group #TheSAS2015

The Equation Group's DoubleFantasy implant is a validator-style Trojan which sends basic information about the system to the attackers. It also allows them to upload a more sophisticated Trojan platform, such as EquationDrug or GrayFish. In general, after one of these sophisticated platforms are installed, the attackers remove the DoubleFantasy implant. In case the victim doesn't check out, for example, if they are a researcher analysing the malware, the attackers can simply choose to uninstall the DoubleFantasy implant and clean up the victim's machine.

In fact, there are several known versions of the DoubleFantasy payload. The disk from Houston used version 8.2.0.3; while other versions were mostly delivered using web-exploits.

Decrypting configuration blocks from all known DoubleFantasy samples, we obtained the following internal version numbers:

• 8.1.0.4 (MSREGSTR.EXE)
• 008.002.000.006
• 008.002.001.001
• 008.002.001.004
• 008.002.001.04A (subversion "IMIL3.4.0-IMB1.8.0")
• 008.002.002.000
• 008.002.003.000
• 008.002.005.000
• 008.002.006.000
• 011.000.001.001
• 012.001.000.000
• 012.001.001.000
• 012.002.000.001
• 012.003.001.000
• 012.003.004.000
• 012.003.004.001
• 013.000.000.000

Interestingly, the most popular versions are 8 and 12:

We will describe some of the versions that we managed to discover including 8.2.0.3, 8.1.0.4 and 12.2.0.1.

DoubleFantasy Payload v.8.2.0.3 Md5 b8c0eb946de83fe8440fefbacf7de4a2 Size 69'632 bytes Type Win32 GUI DLL Timestamp Tue Mar 31 14:32:42 2009 (GMT) Filenames ee.dll, actxprxy32.dll

This module uses a technique known as DLL COM hijacking which provides a capability to load the code in different processes.

Initialization

First of all, it checks if the running module is named "ee.dll" and, if so, will undertake the final installation steps:

• Try to find configuration settings in registry key HKEY_LOCAL_MACHINE\Software\Classes\CLSID\{6AF33D21-9BC5-4f65-8654-B8059B822D91}\TypeLib, in value "DigitalProductId". If this value exists it decodes it using base64 and decrypts using RC5 (with a 16-bytes HEX key: 66 39 71 3C 0F 85 99 81 20 19 35 43 FE 9A 84 11).
• It copies itself to one of the two variants of filenames. Then it substitutes one of the system components by renaming and replacing the original.
Original File Registry Key Registry Value New Value
(Variant 1)
New Value
(Variant 2)
linkinfo.dll HKLM\System\CurrentControlSet\ Control\SessionManager\KnownDLLs LINKINFO LI.DLL LINK32.DLL hgfs1.dll HKLM\SYSTEM\CurrentControlSet\ Services\hgfs\networkprovider ProviderPath hgfs32.dll hgfspath.dll midimap.dll HKLM\SOFTWARE\Microsoft\ Windows NT\CurrentVersion\Drivers32 midimapper midimapper.dll midimap32.dll actxprxy.dll HKCR\CLSID\ {C90250F3-4D7D-4991-9B69-A5C5BC1C2AE6}\ InProcServer32 (Default) actxprxy32.dll actxprxyserv.dll
• Set 64-bit value from config to (Default) value of HKEY_LOCAL_MACHINE\Software\Classes\CLSID\{6AF33D21-9BC5-4f65-8654-B8059B822D91}\TypeLib key in form of {8C936AF9-243D-11D0-xxxx-xxxxxxxxxxxx}, it seems to be used later as victim ID when connecting to C&C server.
• Set (Default) value of HKEY_LOCAL_MACHINE\Software\Classes\CLSID\{6AF33D21-9BC5-4f65-8654-B8059B822D91}\Version to "008.002.000.003" string.
• Upon the creation of a key it performs additional steps to set KEY_ALL_ACCESS rights for Everyone.
• Update start time, encode and write back config to registry value HKEY_LOCAL_MACHINE\Software\Classes\CLSID\{6AF33D21-9BC5-4f65-8654-B8059B822D91}\DigitalProductId

If an error occurs, it sets HKEY_LOCAL_MACHINE\Software\Classes\CLSID\{6AF33D21-9BC5-4f65-8654-B8059B822D91}\MiscStatus\(Default) value to "0". Registry value {CE0F7387-0BB5-E60B-8B4E-xxxxxxxxxxxx} then contains xor-encrypted error code.

If there is an initialization error, if the hosting process is "explorer.exe" or "avp.exe", it supresses any exceptions and continues execution. This could indicate that if there were any errors in these processes they must not be shut down because of them.

To correctly hijack the replaced COM objects, the code exports a set of functions bound to original DLL files.

DllGetClassObject = actxprxy.DllGetClassObject
DllRegisterServer = actxprxy.DllRegisterServer
DllUnregisterServer = actxprxy.DllUnregisterServer
DriverProc = midimap.DriverProc
GetProxyDllInfo = actxprxy.GetProxyDllInfo
NPCancelConncection = hgfs1.NPCancelConncection
NPCloseEnum = hgfs1.NPCloseEnum
NPEnumResource = hgfs1.NPEnumResource
NPFormatNetworkName = hgfs1.NPFormatNetworkName
NPGetCaps = hgfs1.NPGetCaps
NPGetConnection = hgfs1.NPGetConnection
NPGetResourceInformation = hgfs1.NPGetResourceInformation
NPGetResourceParent = hgfs1.NPGetResourceParent
NPOpenEnum = hgfs1.NPOpenEnum
modMessage = midimap.modMessage
modmCallback = midimap.modmCallback

The implants periodically run checks against a special file defined in config. If that file has changed since the last check, or at least a week has passed since the last check, it does the following:

• Perform a connectivity check via public domains (specified in config, i.e. "www.microsoft.com" and "www.yahoo.com") using HTTP POST requests.
• If Internet access is available, connect to one of two C&C IPs or hostnames (specified in config: i.e. 81.31.34.175 and 195.128.235.23). Standard HTTP/HTTPS ports 80 and 443 are probed.
• Send a POST request to the C&C with additional headers "EIag: 0d1975bfXXXXXXXX9c:eac',0Dh,0Ah" – where XXXX XXXX – is part of ClientID
• Request additional data: victim ID, version, MAC address. The data is encrypted using RC5 and encoded using Base64. (RC5 key: 8B 4C 25 04 56 85 C9 75 06 33 C0 5E C2 08 31 F6).

The C&C communication code performs the following:

• Received data is decoded using Base64 and decrypted using RC5. The result is interpreted as a backdoor command.
• Results of the command execution are sent back to the C&C. It then attempts to fetch the next command from the server.
• Uninstalls itself if it can't connect to the C&C server within 180 days (configurable).

The following commands are supported by the backdoor:

Cmd code Command Name Description Download&Run Group J (0x4a) Create File Create an empty file; if file already exists get its size. D (0x44) Append File Append chunk of data to a file (created by the "J" cmd). V (0x56) Run or Copy

Check CRC16 of file received via D command, delete it if the check fails.
Depending on the commands flag:

• Copy file to a new location
• Load file as a DLL
• Start file as a new process
Upload Group K (0x4b) Get File Size Get file size. S (0x53) Read File Read file specified by 'K' command, send it to C&C. It can delete the file after transfer (under some condition). Service Group ` (0x60) Get Info Collect info (IP and MAC addresses, implant version, system proxy server, Windows Registered Owner and Organization, Windows version and ProductID, Locale/Language and Country, Windows directory path, connection type, list of all HKLM\Software subkeys). p (0x70) Set Victim ID Prepare to change Victim ID. u (0x75) Set Interval Change C&C connection interval (seven days by default). v (0x76) Set C&C IP Change primary C&C IP address. x (0x78) Set File Path Change path and name of File-under-inspection. (0x80) Read File Delete file specified in command. B (0x42) Reset Victim ID Change Victim ID to the one set by Set Victim ID command:
Subcmd 0 – reconnect to C&C
Subcmd 1 – reset RC5 context
Subcmd 2 – uninstall DoubleFantasy Payload v.8.1.0.4 Location %System%\MSREGSTR.EXE MD5 9245184228af33d3d97863daecc8597e Size 31'089 Type Win32 GUI EXE Timestamp Wed Mar 22 18:25:55 2006 (GMT) Version Info FileDescription  Registration Software
CompanyName  Microsoft Corporation
FileVersion        4.00.950
InternalName    MSREGSTR
OriginalFilename  MSREGSTR.EXE

Compared to version 8.2, version 8.1 implements the same tasks slightly differently.

Differences:

• This is an EXE file running as a service process.
• Configuration data stored in the overlay of the file, instead of in resources.
• Other registry keys are used as a config storage – set of subkeys under HKLM\Software\Microsoft\Windows\CurrentVersion\Setup\Common
• RC6 encryption and Base64 encoding is not used. The network traffic data is sent in plaintext or simply XOR-encrypted.
• The number of supported remote commands is only four.
• The command encoding type is different.
• Supports Windows 9x family.
DoubleFantasy Payload v.12.2.0.1 Location %System%\actxprxy32.dll MD5 562be0b1930fe5de684c2c530619d659
769d099781220004540a8f6697a9cef1 Size 151552 Type Win32 GUI DLL Timestamp Wed Aug 04 07:55:07 2004 (GMT), probably fake

The implementation of version 12.2 is similar to version 8.2, although it is twice the size due to the addition of a big new library.

The main purpose of this new library to steal user names and passwords from:

• live running Internet Explorer or Firefox browser memory
• Internet Explorer proxy configuration, stored in the Windows registry
• Windows protected storage (up to Windows XP)
• Windows authentication subsystem (Vista+)

In addition to browsers, the library can also inject malicious code and read the memory of other processes in order to obtain and decrypt users' passwords. The same library is also used inside the main EQUATIONDRUG orchestrator and TRIPLEFANTASY modules.

The library gathers stolen credentials and then probes them when accessing proxy server while connecting to the Internet, and, if a probe was successful, the valid credentials are encrypted with RC6 and encoded with BASE64 to be used later.

In this version the data encryption RC6 key is:
66 39 71 3C 0F 85 99 81 20 19 35 43 FE 9A 84 11

The traffic encryption RC6 key is:
32 EC 89 D8 0A 78 47 22 BD 58 2B A9 7F 12 AB 0C

The stolen user data is stored in the Windows registry as @WriteHeader value, inside two random keys in the   HKLM\SOFTWARE\Classes\CLSID\{77032DAA-B7F2-101B-A1F0-01C29183BCA1}\Containers node

Summary

The disk used in the Houston attack represents a rare and unusual operation for the Equation Group. We presume that such attacks were crafted only for important victims who couldn't otherwise be reached, for instance, through a web-based attack vector. This is confirmed by the fact that the exploitation library had three exploits inside, two of which were zero-days at the time.

The DoubleFantasy Malware is usually the first step in the infection of a victim by the Equation Group. Once the victim has been confirmed by communicating with the backdoor and checking various system parameters, a more sophisticated malware system is deployed, such as EquationDrug or Grayfish.

During the upcoming blogposts, we will continue to describe the more sophisticated malware families used by the Equation Group: EquationDrug and GrayFish.

### BE2 Extraordinary Plugins, Siemens Targeting, Dev Fails

Tue, 02/17/2015 - 18:37

Our November post introducing our BlackEnergy2 (BE2) research described new findings on the group's activity. We presented both details on their plugins and significant findings about some of their targets and victims. In this post, let's examine several additional plugins more closely, targeting details around BE2 Siemens exploitation, and some of their unusual coding failures.

We previously introduced an unknown set of plugins and functionality for the linux platform, six in total. For the windows platform, we collected 17 plugins. The last post noted the difficulty in collecting on this group. We finish descriptions for our set in this post.

bs
cert
dstr
fs
grc
jn
kl
prx
ps
rd
scan
sn
ss
tv
upd
usb
vsnet

We also collected plugins for the MIPS/ARM architectures, as noted in the previous BE2 post.

weap
ps
nm
snif
hook
uper

Extraordinary Functionality

Let's first examine some of the newest and most surprising Windows plugins. It's interesting that all of these plugins use a custom "FindByHash" function to evade detection schemes and to slow analysis...

The "Destroy" plugin, dstr

8a0a9166cd1bc665d965575d32dfa972
dstr.dll, 26,474 bytes
CompiledOn: 2014.06.17 08:42:43

The most troubling plugin in the list is the "dstr" plugin. It is a Windows-only plugin. It was used to overwrite data by the BE2 actor, destroying data stored on hard drives by overwriting file contents. While its use may be intended to cover their tracks, it is heavy handed to use this type of tool to cover one's tracks in a network. Most likely it is a tool of sabotage, much like the Destover wiper seen on Sony Pictures Entertainment's networks. However, it's interesting that the BE2 developers created wiper code different from the Destover and Shamoon wiper malware we saw in the Saudi Aramco and SPE attacks. Instead of re-using the commercial EldoS RawDisk drivers in their malware, the BE2 developers wrote their own low-level disk and file destruction routines. It's also a much more chilling deployment of wipers - instead of a poorly defended media studio, it was delivered to ICS environments.

In order to overwrite stored data on all Windows versions, the dstr plugin supports both user-mode and kernel-mode wiper functionality, which is somewhat surprising. The component maintains both an embedded win32 library and win64 driver modules for its kernel mode functionality. They are rc4 encrypted.

User-mode functionality

The plugin identifies device id's for the system's HDD and creates a handle to the system's physical drive, with "GENERIC_READ or GENERIC_WRITE" access. Several calls to DeviceIoControl collects data on the physical location of the volume, and the size and properties of this disk. It uses DeviceIoControl with the IOCTL_DISK_GET_DRIVE_GEOMETRY control code in order to retrieve Bytes Per Sector value. dstr then wipes out all open handles to the disk by dismounting it with the FSCTL_DISMOUNT_VOLUME control code.

This routine prepares the system for overwrite and ensures no conflicts for plugin file I/O. Then it makes multiple WriteFile calls to write a zeroed out buffer to disk.

The dstr plugin maintains code for unlocking and deleting the BE2 driver from disk, furthering the group's goal of keeping their traces hidden from researchers. And notice the FindByHash set of calls above, this sfc_os call disables Windows File Protection for a minute while an application can delete or modify the locked file. So this plugin and its call can proceed and delete the driver.

The plugin looks over all the services in the %system32%\drivers folder and checks the write permission. If access is provided, it unlocks the file, rewrites the embedded driver under the existing driver name and launches it.

Drivers and kernel mode functionality

Decrypted 32-bit driver

c4426555b1f04ea7f2e71cf18b0e5b6c
driver.sys, 5,120 bytes
2014.06.10 13:12:22 GMT

Decrypted 64-bit driver

2cde6f8423e5c01da27316a9d1fe8510
driver.sys, 9,136 bytes
2014.06.10 13:12:04 GMT

The 32-bit and 64-bit drivers are identical and compiled from the same source code. These small Windows drivers are supposed to support FAT32 and NTFS file systems, and contain two large code implementation mistakes. In spite of these flaws, it is clear that the author's goal was to parse a file system and then write random data across files.

Extraordinary Fails

These coding fails are unique to this dstr plugin, suggesting a development team effort behind the plugin set code.

Fail #1: The authors reversed the routines for FAT32 and NTFS data wiping when checking the presence of the "FAT32" string in the first 1024-bytes of the system drive.

Fail #2: In the FAT32 routine the Root Directory Sector Number is calculated and is dealt as the absolute offset inside the file rather than next multiplying this number by the bytes per sector

In comparison, there is no such mistake in the NTFS routine and the calculation of the MFT offset is implemented properly:

Goal - File Content Corruption

Apart from that, it is interesting that the authors implement NTFS wiping in an unusual way with strange logic compared to FAT32 'straightforward' wiping. The plugin accomplishes checks for FILE records and at first skips them. Then under certain conditions it rewrites non-FILE record sectors with random buffer which probably corresponds to some file contents and proceeds looping. Then it ends up rewriting the first sectors of MFT and MFT mirror.

ee735c244a22b4308ea5d36afee026ab
grc.dll, 15,873 bytes
2013.09.25 07:19:31

This plugin creates a backup communications channel to yet another legitimate service. Most likely this backup channel is used to cloak outbound communications on monitored networks. We have seen APT using everything from Twitter to Google Docs to hide communications in plain sight, and this time the abused service is Google Plus.

This plugin implements the standard Windows HTTP services to interact with Google Plus over https, seeking to find a png file.

The plugin is provided with a specific Google Plus id to connect with, and uses the OLE stream Windows structured storage API along with the GDI+ bitmap functions to handle and parse this png file. This png file content is actually encrypted data containing the new BE configuration file just as it was obtained using 'normal' C&C communication.  It is encrypted with RC4, just like the embedded dstr drivers. But unlike to the 'typical' RC4 BE decryption scheme that uses RC4 once, here it uses RC4 three times: once with hardcoded key found in the grc binary, the second time using the key extracted from the previous decrypted result, and the third time using the 'id' machine's identifier that is normally served as the encryption key during the C&C communication.

Universal serial bus data collection plugin, usb

0d4de21a2140f0ca3670e406c4a3b6a9
usb.dll, 34,816 bytes
2014.03.21 07:02:48

The usb plugin collects all available information on connected USB drives, and writes out all of these details to a text file, packs it, provides to the main BlackEnergy code, which communicates to a c2.

It uses multiple api calls to collect information on multiple types of connected usb storage devices. It enumerates all usb storage devices connected to the system and retrieves data from all, including SCSI mass storage devices. And, most interestingly, it may be the first implementation of BadUSB-related techniques in APT re-purposed COTS malware that we have seen in the wild.

The code queries scsi devices directly and sends them two types of SCSI commands. The first command with the opcode 0x1A which corresponds to MODE SENSE may result just in the logging of the failed call ('SendSCSICommand return false' message).

The second type of SCSI command remains mysterious. It uses undefined opcode 0xf0 and there is no direct evidence of its purpose as it is stated to be vendor specific. This mysterious opcode is referenced around the same time frame of the plugin development in BadUSB offensive research http://algorithmics.bu.edu/twiki/bin/view/EC521/SectionA1/Group5FinalReport. Here, it is noticed in the USB traffic generated by an SMI controller tool. To be specific, there are two calls with the opcode 0xf0 in the code, each passed its own parameters. One of the parameters, 0x2A, is mentioned in the paper to return the string containing the firmware version, NAND flash ID, and controller part number. But this returned information is not logged anywhere.

Also the code loops to retrieve detailed physical data about every attached storage device:

• number of cylinders
• media type (floppy, fixed hard drive, removable media, etc)
• number of tracks per cylinder
• sectors per track
• number of bytes per sector
• physical disk size in bytes
• Device Instance ID

Motherboard and firmware data collection plugin, bios

4747376b00a5dd2a787ba4e926f901f4
bs.dll, 210,432 bytes
2014.07.29 00:40:53

The bios plugin gathers low level host system information:

• BIOS
• motherboard
• processor
• OS

It uses several techniques to gather this information:

• WMI
• CPUID
• win32 api

As a Windows Management Instrumentation (WMI) client application, it initializes COM and connects to the \\root\cimv2 namespace to use the IWbemServices pointer and make WMI requests. The code executes wql queries ("wql" is "sql for wmi", a subset of sql) to gather victim host details, like the query "SELECT Description, Manufacturer, Name, ProcessorId FROM Win32_Processor". Here are several queries from the BlackEnergy2 plugin code:

• SELECT Description, Manufacturer, Name, ProcessorId FROM Win32_Processor
• SELECT Product, Manufacturer, Version FROM Win32_BaseBoard
• SELECT Name, OSArchitecture, Version, BuildNumber FROM Win32_OperatingSystem
• SELECT SerialNumber, Description, Manufacturer, SMBIOSBIOSVersion FROM Win32_BIOS

These wql calls provide the attacker with the data like the lines below:

Description=Intel64 Family 6 Model 60 Stepping 3
Manufacturer=GenuineIntel
Name=Intel(R) Core(TM) i7-4710MQ CPU @ 2.50GHz
ProcessorId=1FEAFBCF000116A9

Product=7MPXM1
Manufacturer=AsusTek
Version=??

Name=Microsoft Windows 8.1 Pro
OSArchitecture=64-bit
Version=6.3.9600
BuildNumber=9600

SerialNumber=7DTLG45
Description=A12
Manufacturer=AsusTek
SMBIOSBIOSVersion=A12

This selectivity is fairly usual. And the plugin does not modify its own behavior based the collected values. What can we infer about the selection of only these values, as they are only being collected and sent back to the attackers? Here are some possibilities:

• the attackers want to evade sandbox and honeypot/decoy environments, and use this collected data to id the host system.
• the attackers have prior knowledge of the environment they are attempting to penetrate, down to the equipment make. Or, they have an idea of the types of hardware they would expect or want to see. In ICS and SCADA environments, these details could be very valuable for an attacker setting up shop. These details could aid in establishing persistence, evaluating true resource capacity and capabilities, tracking down the source of the equipment, or aiding further lateral movement
• the attackers know nothing about the network they are penetrating. They are collecting this information to better understand where this plugin really is running in the victim environment and planning their next moves

When using standard win32 api, the application implements calls to retrieve information on system locales. Oddly, there is special handling for one nordic locale in this particular plugin, "Norwegian-Nynorsk".

The CPU data collection functionality first calls the Intel cpuid instruction directly. It also directly handles multi-cpu systems and each of their feature sets. This SMP support is hard coded into the plugin.

Targeting details for BE2 actor events are interesting. When focusing on research sites and energy engineering facilities, the group remotely exploited Siemens' Simatic WinCC systems. In these events, the attackers attempted to force the ccprojectmgr.exe process to download and execute a specific BlackEnergy2 payload. Let's examine a couple of example targets here. Based on the different delays for return, the attacks were possibly not automated.

Target A:

The first exploit attempt ksn recorded was March 2014. The attackers returned with a second failed attempt to exploit that same research system on April 2014, approximately 30 days, 2 hours later.

Target B:

The BE2 actor then attacked a new target system in May 2014 and failed, and returned with an exploit attempt on that same system in July 2014.

So it looks like there may be a timing cycle to their visits, but the volumes here are too low to be significant.

In all four of these attempts on two different targets, the attackers tried to download their payload from hxxp://94.185.85(dot)122/favicon.ico. The payload changed slightly from March 2014 to the very end of July 2014, presenting the following md5(s). All of these droppers are BE2 malware, modify an existing kernel driver service like "ACPIEC" and start it to load the BE2 kernel module. Note that the attackers planned on re-using the same c2 for the first target, but changed the callback c2 for the second target. None of these components are signed:

fda6f18cf72e479570e8205b0103a0d3 → drops df84ff928709401c8ad44f322ec91392, driver, debug string:"xxxxxxxx.pdb". C2: 144.76.119.48 (DE, Hetzner Online AG, AS24940)
fe6295c647e40f8481a16a14c1dfb222 → drops 39835e790f8d9421d0a6279398bb76dc, driver, debug string:"xxxxxxxx.pdb". C2: 144.76.119.48 (DE, Hetzner Online AG, AS24940)
ac1a265be63be7122b94c63aabcc9a66 → drops b973daa1510b6d8e4adea3fb7af05870, driver. C2: 95.143.193.131 (SE, Internetport Sweden AB, AS49770)
8e42fd3f9d5aac43d69ca740feb38f97 → drops f4b9eb3ddcab6fd5d88d188bc682d21d, driver. C2: 46.165.222.6 (DE, Leaseweb Germany GmbH, AS16265)

### The Desert Falcons targeted attacks

Tue, 02/17/2015 - 12:50

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

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.

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

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:

Below is a sample request issued by the malware:

User-Agent: Mozilla/4.0 (compatible;)

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.

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.

### Equation: The Death Star of Malware Galaxy

Mon, 02/16/2015 - 13:55

"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

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.

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
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
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
newip427.changeip[.]net - SINKHOLED BY KASPERSKY LAB
ad-servicestats[.]net - SINKHOLED BY KASPERSKY LAB
subad-server[.]com - SINKHOLED BY KASPERSKY LAB
aynachatsrv[.]com
damavandkuh[.]com
fnlpic[.]com
nowruzbakher[.]com
sherkhundi[.]com
quik-serv[.]com
arabtechmessenger[.]net
amazinggreentechshop[.]com
foroushi[.]net
technicserv[.]com
honarkhaneh[.]net
parskabab[.]com
technicupdate[.]com
customerscreensavers[.]com
darakht[.]com
ghalibaft[.]com
247adbiz[.]net - SINKHOLED BY KASPERSKY LAB
webbizwild[.]com
roshanavar[.]com
afkarehroshan[.]com
thesuperdeliciousnews[.]com
goodbizez[.]com
meevehdar[.]com
xlivehost[.]com
gar-tech[.]com - SINKHOLED BY KASPERSKY LAB
honarkhabar[.]com
techsupportpwr[.]com
webbizwild[.]com
zhalehziba[.]com
wangluoruanjian[.]com
islamicmarketing[.]net
noticiasftpsrv[.]com
coffeehausblog[.]com
havakhosh[.]com
bazandegan[.]com
sherkatkonandeh[.]com
mashinkhabar[.]com
charmedno1[.]com
cribdare2no[.]com
dowelsobject[.]com
following-technology[.]com
forgotten-deals[.]com
housedman[.]com
industry-deals[.]com
listennewsnetwork[.]com
phoneysoap[.]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
• 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.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 - 11:20

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. ### Financial cyber threats in 2014: things changed Thu, 02/12/2015 - 06: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 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 and Trojan-Banker) 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 - 04: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 - 05: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 - 07: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:

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.

### Why You Shouldn't Completely Trust Files Signed with Digital Certificates

Thu, 01/29/2015 - 05:00

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:

1. The software developer compiles the file.
2. A hash sum (MD5, SHA1, or SHA2) is calculated for the file.
3. That hash sum is encrypted with the software developer's private key.
4. 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:

1. Only allow the launch of software programs signed by a reputable manufacturer.
2. 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.

3. Only allow programs to be launched after they are identified by their unique digital signature attributes.
4. 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.

5. Activate the MS13-098 security update.
6. 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.

7. Do not install certificates from unknown CAs into your security storage.
8. 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.

9. Use a trusted certificates database from a security software manufacturer.
10. 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.

### Comparing the Regin module 50251 and the "Qwerty" keylogger

Tue, 01/27/2015 - 06:00

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.

### The Syrian malware part 2: Who is The Joe?

Tue, 01/27/2015 - 03:00
Introduction

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.

Reports that mention "the Joe"
https://citizenlab.org/2013/06/a-call-to-harm/
https://www.eff.org/files/2013/12/28/quantum_of_surveillance4d.pdf

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.

Folder paths recovered from the malware files:

• C:\Users\joe\Desktop\2014\WindowsApplication1\WindowsApplication1\obj\Debug\WindowsApplication1.pdb
• C:\Users\joe\Desktop\Desktop\Syriatel\Syriatel\obj\Debug\Syriatel.pdb
• C:\Users\joe\Desktop\NJServer\NJServer\obj\Debug\NJServer.pdb

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.

6 new stories:

1. Let us fix your SSL vulnerability
2. Now Let us clean your Skype!
3. Did you update to the latest VPN version?
4. Let's Check if your phone number is among the monitored numbers
5. The Facebook account encryption application
6. What's your favourite security product?

1 - Let us fix your SSL vulnerability

MD5 Hash: dc6166005db7487c9a8b32d938fec846
Filename: TheSSL.exe, SSL Cleaner.rar

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.

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?

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

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

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

Indicators of compromise MD5 Hash Name(s) used for the malware file First Seen f62cfd2484ff8c5b1a4751366e914613 Adobe.exe
Card.exe Sept 2013 012f25d09fd53aeeddc11c23902770a7
89e6ae33b170ee712b47449bbbd84784 قائمة الأرهاب .zip ("list of terrorism") file extracts to .JPG and malicious .SCR files Jan 2014 dc6166005db7487c9a8b32d938fec846
62023eb959a79bbdecd5aa167b51541f TheSSL.exe (to "remove SSL weaknesses")
SSL Cleaner.rar April 2014 cc694b1f8f0cd901f65856e419233044 Desktop.exe
Empty.exe
Host.exe Mar 2014 d6ab8ca6406fefe29e91c0604c812ff9 Skype.exe
Setup.exe Nov 2014 a238f8ab946516b6153816c5fb4307be tdskiler.exe (to "remove malware") Jan 2015 6379afd35285e16df4cb81803fde382c Locker.exe (to "encrypt/decrypt" files) Jan 2015

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.

### An analysis of Regin's Hopscotch and Legspin

Thu, 01/22/2015 - 04:00

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.

The Hopscotch module MD5 6c34031d7a5fc2b091b623981a8ae61c Size 36864 bytes Type Win32 EXE Compiled 2006.03.22 19:09:29 (GMT)

This module has another binary inside, stored as resource 103:

MD5 42eaf2ab25c9ead201f25ecbdc96fb60 Size 18432 bytes Type Win32 EXE Compiled 2006.03.22 19:09:29 (GMT)

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.

\\%target%\pipe\{66fbe87a-4372-1f51-101d-1aaf0043127a}
\\%target%\pipe\{44fdg23a-1522-6f9e-d05d-1aaf0176138a}

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.

The Legspin module MD5 29105f46e4d33f66fee346cfd099d1cc Size 67584 bytes Type Win32 EXE Compiled 2003.03.17 08:33:50 (GMT)

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.

Command Description 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:

kernel32.dll
msvcrt.dll
ntdll.dll
ntoskrnl.exe
win32k.sys
cmd.exe
ping.exe
ipconfig.exe
tracert.exe
netstat.exe
net.exe
user32.dll
gdi32.dll
shell32.dll

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