Input: Over the last 10 months, Kaspersky Lab researchers have analyzed a massive cyber-espionage operation which we call'' Epic Turla''.


Input: The attackers behind Epic Turla have infected several hundred computers in more than 45 countries, including government institutions, embassies, military, education, research and pharmaceutical companies.


Input: The attacks are known to have used at least two zero-day exploits: We also observed exploits against older (patched) vulnerabilities, social engineering techniques and watering hole strategies in these attacks.


Input: The primary backdoor used in the Epic attacks is also known as'' WorldCupSec'','' TadjMakhal'','' Wipbot'' or'' Tavdig''.

The primary backdoor

the Epic attacks

used

in


Input: When G-Data published on Turla/Uroburos back in February, several questions remained unanswered.


Input: One big unknown was the infection vector for Turla (aka Snake or Uroburos).


Input: Our analysis indicates that victims are infected via a sophisticated multi-stage attack, which begins with the Epic Turla.

victims

a sophisticated multi-stage attack

are infected

via


Input: In time, as the attackers gain confidence, this is upgraded to more sophisticated backdoors, such as the Carbon/Cobra system.

this

more sophisticated backdoors

is upgraded

to


Input: Sometimes, both backdoors are run in tandem, and used to'' rescue'' each other if communications are lost with one of the backdoors.

both backdoors

tandem

are run

in


Input: Once the attackers obtain the necessary credentials without the victim noticing, they deploy the rootkit and other extreme persistence mechanisms.

the attackers

the necessary credentials

the victim noticing

they

the rootkit and other extreme persistence mechanisms

obtain

deploy

without


Input: The attacks are still ongoing as of July 2014, actively targeting users in Europe and the Middle East.


Input: Note: A full analysis of the Epic attacks is available to the Kaspersky Intelligent Services subscribers.


Input: Contact: intelreports @kaspersky.com The attacks in this campaign fall into several different categories depending on the vector used in the initial compromise: The attackers use both direct spearphishing and watering hole attacks to infect their victims.

The attackers

both direct spearphishing and watering hole attacks

infect their victims

use

to


Input: Watering holes (waterholes) are websites of interest to the victims that have been compromised by the attackers and injected to serve malicious code.


Input: So far we haven't been able to locate any e-mail used against the victims, only the attachments.


Input: The PDF attachments do not show any'' lure'' to the victim when opened, however, the SCR packages sometime show a clean PDF upon successful installation.


Input: Some of known attachment names used in the spearphishing attacks are: In some cases, these filenames can provide clues about the type of victims the attackers are targeting.


Input: Currently, the Epic attackers run a vast network of watering holes that target visitors with surgical precision.

the Epic attackers

a vast network of watering holes

visitors

surgical precision

run

target

with


Input: Some of the injected websites include: In total, we observed more than 100 injected websites.


Input: Currently, the largest number of injected sites is in Romania.


Input: Here's a statistic on the injected websites: The distribution is obviously not random, and it reflects some of the interests of the attackers.


Input: For instance, in Romania many of the infected sites are in the Mures region, while many of the Spanish infected sites belong to local governments (City Hall).


Input: Most of the infected sites use the TYPO3 CMS (see: http: //typo3.org/), which could indicate the attackers are abusing a specific vulnerability in this publishing platform.


Input: Injected websites load a remote JavaScript into the victim's browser: The script'' sitenavigatoin.js'' is a Pinlady-style browser and plugin detection script, which in turn, redirects to a PHP script sometimes called main.php or wreq.php.

Injected websites

a remote JavaScript

the victim's browser

load

into


Input: Sometimes, the attackers register the .JPG

the attackers


Input: extension with the PHP handler on the server, using'' JPG'' files to run PHP scripts: The main exploitation script'' wreq.php'','' main.php'' or'' main.jpg'' performs a numbers of tasks.

using

'' JPG'' files

run PHP scripts

to


Input: We have located several versions of this script which attempt various exploitation mechanisms.

several versions of this script

various exploitation mechanisms

attempt


Input: One version of this script attempts to exploit Internet Explorer versions 6, 7 and 8: Unfortunately, the Internet Explorer exploits have not yet been retrieved.

One version of this script

Internet Explorer versions 6, 7 and 8

exploit


Input: Another more recent version attempts to exploit Oracle Sun Java and Adobe Flash Player: Although the Flash Player exploits couldn't be retrieved, we did manage to obtain the Java exploits: The Java files exploit a popular vulnerability, CVE-2012-1723, in various configurations.

Another more recent version

Oracle Sun Java and Adobe Flash Player

The Java files

a popular vulnerability

various configurations

exploit

exploit

in


Input: The payload dropped by these Java exploits is the following: The Java exploit use a special loader that attempts to inject the final Epic backdoor payload into explorer.exe.

The payload

Java exploits

The Java exploit

a special loader

the final Epic backdoor payload

explorer.exe

dropped

use

inject

into


Input: The backdoor extracted from the Java exploits has the following C & C hardcoded inside: This C & C is still online at the moment although it redirects to a currently suspended page at'' hxxp: //busandcoachdirectory.com [.

The backdoor extracted from the Java exploits

the following C & C

has


Input: ] au''.


Input: For a full list of C & C servers, please see the Appendix.


Input: The Epic Turla attackers are extremely dynamic in using exploits or different methods depending on what is available at the moment.


Input: Most recently, we observed them using yet another technique coupled with watering hole attacks.

them

yet another technique coupled with watering hole attacks

using


Input: This takes advantage of social engineering to trick the user into running a fake Flash Player (MD5: 030f5fdb78bfc1ce7b459d3cc2cf1877): In at least one case, they tried to trick the user into downloading and running a fake Microsoft Security Essentials app (MD5: 89b0f1a3a667e5cd43f5670e12dba411): The fake application is signed by a valid digital certificate from Sysprint AG: This file was distributed from the Ministry of Foreign Affairs of Tajikistan's website, at'' hxxp: //mfa [.] tj/upload/security.php''.

takes

trick

trick

was distributed

advantage

social engineering

the user

running a fake Flash Player

they

the user

downloading and running a fake Microsoft Security Essentials app

This file

the Ministry of Foreign Affairs of Tajikistan's website

'' hxxp: //mfa [.] tj/upload/security.php''

of

into

into

from

at


Input: The file is a .NET

The file


Input: application that contains an encrypted resource.

contains

an encrypted resource


Input: This drops the malicious file with the MD5 7731d42b043865559258464fe1c98513.

This

the malicious file with the MD5 7731d42b043865559258464fe1c98513

drops


Input: This is an Epic backdoor which connects to the following C & Cs, with a generic internal ID of 1156fd22- 3443-4344-c4ffff: A full list with all the C & C server URLs that we recovered from the samples can be found in the technical Appendix.

This

an Epic backdoor

the following C & Cs

a generic internal ID of 1156fd22- 3443-4344-c4ffff

is

connects

to

with


Input: The Epic backdoors are commanded by a huge network of hacked servers that deliver command and control functionality.

The Epic backdoors

a huge network of hacked servers

command and control functionality

are commanded

deliver


Input: The huge network commanded by the Epic Turla attackers serves multiple purposes.

The huge network

the Epic Turla attackers

commanded


Input: For instance, the motherships function as both exploitation sites and command and control panels for the malware.

the motherships

exploitation sites

command and control panels

function

as


Input: Here's how the big picture looks like: The first level of command and control proxies generally talk to a second level of proxies, which in turn, talk to the'' mothership'' server.

The first level of command and control proxies

a second level of proxies

the'' mothership'' server

talk

talk

to

to


Input: The mothership server is generally a VPS, which runs the Control panel software used to interact with the victims.

The mothership server

the Control panel software

the victims

runs

interact

with


Input: The attackers operate the mothership using a network of proxies and VPN servers for anonymity reasons.


Input: The mothership also work as the exploitation servers used in the watering hole attacks, delivering Java, IE or fake applications to the victim.

The mothership

the exploitation servers

the watering hole attacks

Java, IE or fake applications

the victim

work

used

delivering

as

in

to


Input: We were able to get a copy of one of the motherships, which provided some insight into the operation.


Input: It runs a control panel which is password protected: Once logged into the Control panel, the attackers can see a general overview of the system including the number of interesting potential targets: A very interesting file on the servers is task.css, where the attackers define the IP ranges they are interested in.

the attackers

the IP ranges they are interested in

define


Input: To change the file, they are using the'' Task editor'' from the menu.


Input: Depending on the'' tasks'', they will decide whether to infect the visitors or not.

they

whether to infect the visitors or not

decide


Input: In this case, we found they targeted two ranges belonging to: It should be noted though, the fact that the attackers were targeting these ranges doesn't necessarily mean they also got infected.

they

two ranges

targeted


Input: Some other unknown IPs were also observed in the targeting schedules.


Input: There is also an'' except.css'' file where attackers log the reasons they didn't try to exploit certain visitors.


Input: There are three possible values: These are the'' don't meet the conditions'' reasons observed in the logs: For this first stage of the attack, the threat actor uses a custom backdoor.

the threat actor

a custom backdoor

uses


Input: In some cases, the backdoor is packaged together with the CVE-2013-5065 EoP exploit and heavily obfuscated.

the backdoor

obfuscated


Input: This makes the analysis more difficult.


Input: The CVE-2013-5065 exploit allows the backdoor to achieve administrator privileges on the system and run unrestricted.

the backdoor

administrator privileges on the system

unrestricted

achieve

run


Input: This exploit only works on unpatched Microsoft Windows XP systems.


Input: Other known detection names for the backdoor is Trojan.Wipbot (Symantec) or Tavdig.


Input: The main backdoor is about 60KB in size and implements a C & C protocol on top of normal HTTP requests.

The main backdoor

a C & C protocol

normal HTTP requests

implements

on top of


Input: The communication protocol uses requests in the C & C replies, which the malware decrypts and processes.

The communication protocol

requests

the C & C replies

the malware

uses

decrypts and processes

in


Input: The replies are sent back to the C & C through the same channel.

The replies

the C & C

the same channel

are sent

back to

through


Input: The malware behavior is defined by a configuration block.


Input: The configuration block usually contains two hard-coded C & C URLs.


Input: He have also seen one case where the configuration block contains just one URL.


Input: The configuration can also be updated on the fly by the attackers, via the C & C.

The configuration

the attackers

the C & C

be updated

via


Input: The backdoor attempts to identify the following processes and, if found, it will terminate itself: It contains an internal unique ID, which is used to identify the victim to the C & C.

The backdoor

the following processes

it

itself

an internal unique ID

the victim

the C & C

identify

terminate

identify

to


Input: Most samples, especially old ones, have the ID 1156fd22-3443-4344-c4ffff.


Input: Once a victim is confirmed as'' interesting'', the attackers upload another Epic backdoor which has a unique ID used to control this specific victim.

a victim

'' interesting''

the attackers

another Epic backdoor

this specific victim

is confirmed

upload

control

as


Input: During the first C & C call, the backdoor sends a pack with the victim's system information.

During

the first C & C call

the backdoor

a pack with the victim's system information

sends


Input: All further information sent to the C & C is encrypted with a public key framework, making decryption impossible.

All further information

the C & C

a public key framework

sent

is encrypted

to

with


Input: The commands from the C & C are encrypted in a simpler manner and can be decrypted if intercepted because the secret key is hardcoded in the malware.

The commands from the C & C

are encrypted


Input: Through monitoring, we were able to capture a large amount of commands sent to the victims by the attackers, providing an unique view into this operation.

a large amount of commands

the victims

the attackers

sent

to


Input: Here's a look at one of the encrypted server replies: Once a victim is infected and'' checks in'' with the server, the attackers send a template of commands: Next, the attackers try to move through the victim's network using pre-defined or collected passwords: Listing all .doc

a victim

the server

the attackers

a template of commands

the attackers

the victim's network

pre-defined or collected passwords

is infected

'' checks in''

send

move

with

through

using


Input: files recursively is also a common'' theme'': In total, we have decoded several hundreds of these command packages delivered to the victims, providing an unique insight into the inner workings of the attackers.


Input: In addition to generic searches, some very specific lookups have been observed as well.


Input: These include searches for: In this case, the attackers were interested to find e-mails related to'' NATO'','' Energy Dialogue within European Unition'' and so on.

the attackers

e-mails related to'' NATO'','' Energy Dialogue within European Unition'' and so on

find


Input: For some of the C & C servers, the attackers implemented RSA encryption for the C & C logs, which makes it impossible to decrypt them.

the attackers

RSA encryption

the C & C logs

implemented

for


Input: This scheme was implemented in April 2014.


Input: Once a victim is compromised, the attackers upload several tools that are used for lateral movement.

a victim

the attackers

several tools that are used for lateral movement

is compromised

upload


Input: One such tool observed in the attacks and saved as'' C: \Documents and Settings\All users\Start Menu\Programs\Startup\winsvclg.exe'' is: This is a keylogger tool that creates% temp% \~DFD3O8.tmp.

This

a keylogger tool

is


Input: Note: the filename can change across victims.


Input: On one Central Asian government's Ministry of Foreign Affairs victim system, the filename used was'' adobe32updt.exe''.


Input: In addition to these custom tools, we observed the usage of standard administration utilities.


Input: For instance, another tool often uploaded by the attackers to the victim's machine is'' winrs.exe'': This is an UPX packed binary, which contains the genuine'' dnsquery.exe'' tool from Microsoft, unpacked MD5: c0c03b71684eb0545ef9182f5f9928ca.

another tool

the attackers

the victim's machine

'' winrs.exe''

uploaded

to


Input: In several cases, an interesting update has been observed -- a malware from a different, yet related family.


Input: This backdoor is more sophisticated and belongs to the next level of cyber-espionage tools called the'' Carbon system'' or Cobra by the Turla attackers.

This backdoor

the'' Carbon system'' or Cobra

the Turla attackers

called


Input: Several plugins for the'' Carbon system'' are known to exist.


Input: Note: the command and control servers www.losguayaberos [.


Input: ] com and thebesttothbrushes [.


Input: ] com have been sinkholed by Kaspersky Lab.


Input: Other packages delivered to the victims include: These top level packages deploy both updated Epic backdoors and Turla Carbon system backdoors to confirmed victims, effectively linking the Epic and Turla Carbon operations together.

These top level packages

both updated Epic backdoors and Turla Carbon system backdoors

confirmed victims

deploy

to


Input: The Turla Carbon dropper from these packages has the following properties: This is called internally by the authors'' Carbon System'', part of the'' Cobra'' project, as it can be seen from the debug path inside: This acts as a dropper for the following modules, both 32 and 64 bit: The Carbon system is in essence an extensible platform, very similar to other attack platforms such as the Tilded platform or the Flame platform.

This

a dropper for the following modules

acts

as


Input: The plugins for the Carbon system can be easily recognized as they always feature at least two exports named: Several Epic backdoors appear to have been designed to work as Carbon system plugins as well-they require a specialized loader to start in victim systems that do not have the Carbon system deployed.


Input: Some modules have artifacts which indicate the Carbon system is already at version 3.x, although the exact Carbon system version is very rarely seen in samples: The author of the Carbon module above can be also seen in the code, as'' gilg'', which also authored several other Turla modules.


Input: We are planning to cover the Turla Carbon system with more details in a future report.


Input: The payload recovered from one of the mothership servers (at newsforum.servehttp [.

The payload


Input: ] com/wordpress/wp-includes/css/img/upload.php, MD5: 4dc22c1695d1f275c3b6e503a1b171f5, Compiled: Thu Sep 06 14:09:55 2012) contains two modules, a loader/injector and a backdoor.

contains

a loader/injector

a backdoor


Input: Internally, the backdoor is named'' Zagruzchick.dll'': The word'' Zagruzchick'' means'' boot loader'' in Russian.


Input: The Control panel for the Epic motherships also sets the language to codepage'' 1251'': Codepage 1251 is commonly used to render Cyrillic characters.


Input: There are other indications that the attackers are not native English language speakers: The sample e9580b6b13822090db018c320e80865f that was delivered to several Epic victims as an upgraded backdoor, has the compilation code page language set to'' LANGRUSSIAN''.

The sample e9580b6b13822090db018c320e80865f

several Epic victims

an upgraded backdoor

was delivered

to

as


Input: The threat actor behind the'' Epic'' operation uses mainly hacked servers to host their proxies.


Input: The hacked servers are controlled through the use of a PHP webshell.


Input: This shell is password protected; the password is checked against an MD5 hash: The MD5'' af3e8be26c63c4dd066935629cf9bac8'' has been solved by Kaspersky Lab as the password'' kenpachi''.


Input: In February 2014 we observed the Miniduke threat actor using the same backdoor on their hacked servers, although using a much stronger password.

the Miniduke threat actor

the same backdoor

their hacked servers

using

on


Input: Once again, it is also interesting to point out the usage of Codepage 1251 in the webshell, which is used to render Cyrillic characters.


Input: There appears to be several links between Turla and Miniduke, but we will leave that for a future blogpost.


Input: On some of the C & C servers used in the Epic attacks, we were able to identify detailed victim statistics, which were saved for debugging purposes by the attackers.

detailed victim statistics

debugging purposes

the attackers

were saved

for


Input: This is the country distribution for the top 20 affected countries by victim's IP: According to the public information available for the victims' IPs, targets of'' Epic'' belong to the following categories: When G-Data published their Turla paper, there were few details publicly available on how victims get infected with this malware campaign.


Input: Our analysis indicates this is a sophisticated multi-stage infection; which begins with Epic Turla.


Input: This is used to gain a foothold and validate the high profile victim.

This

the high profile victim

validate


Input: If the victim is interesting, they get upgraded to the Turla Carbon system.

they

the Turla Carbon system

upgraded

to


Input: Most recently, we observed this attack against a Kaspersky Lab user on August 5, 2014, indicating the operation remains fresh and ongoing.


Input: Note: A full analysis of the Epic attacks is available to the Kaspersky Intelligent Services customers.


Input: Contact: intelreports @kaspersky.com We would like to add the following at the end of the blogpost, right before the detection names: If you'd like to read more about Turla/Uroburos, here's a few recommendations:


Input: In this day and age of interconnected cloud services and distributed content delivery networks (CDNs), it is important for both CDN service providers and security professionals alike to recognize and understand the risks that these systems can introduce within an modern enterprise.


Input: For organizations within both public and private sectors that leverage CDN platforms to dynamically deliver web content, it is important that the content is also routinely monitored.


Input: Otherwise, malicious third-party content can be loaded into a target organization's website without their knowledge, delivering untold risks to unwitting visitors.


Input: The ThreatConnect Intelligence Research Team (TCIRT) recently observed a targeted cross-site scripting (XSS)'' drive-by'' attack that leveraged a single content delivery network resource to distribute a malicious Java applet via nearly all of the major official Government of Afghanistan websites.

a targeted cross-site scripting (XSS)'' drive-by'' attack

a single content delivery network resource

distribute a malicious Java applet via nearly all of the major official Government of Afghanistan websites

leveraged

to


Input: The compromised CDN resource in question is a JavaScript file hosted at [http:] //cdn.afghanistan [.


Input: ] af/scripts/gop-script.js The domain cdn.afghanistan [.


Input: ] af is a legitimate CDN site used by the Afghan Ministry of Communications and IT (MCIT) to host web content that is displayed and used on many official gov.af websites.


Input: The javascript URL ([http:] //cdn.afghanistan [.


Input: ] af/scripts/gop-script.js) is called from numerous official Afghan Government websites, including the following: It is likely that this javascript URL itself is normally legitimate, but the attackers obtained access to the file and prepended the following malicious JavaScript functions to the beginning of the script: Note that the gov.af websites would not need to be compromised individually for this attack to be delivered to visitors of the sites, because it is the backend CDN infrastructure that is serving up the malicious script.


Input: Judging by the last modified timestamp on the HTTP response of gop-script.js, which is Tue, 16 Dec 2014 08:07:06 GMT, this malicious CDN compromise was very recent in nature.


Input: In fact, it occurred on the very same day that China's Prime Minister Li Keqiang would meet with Abdullah Abdullah, the Chief Executive Officer of Afghanistan in Astana Kazakhstan, they would discuss infrastructure development and bilateral cooperation issues.


Input: Looking at the EXIF metadata of the image of Keqiang meeting with Abdullah that is hosted on the Chinese embassy website we note a Tue, 16 December 2014 07:43:31 modify time as well as the www.news [.


Input: ] cn watermark in the bottom righthand corner.


Input: This indicates that the image of Keqiang and Abdullah was likely taken and edited sometime prior to 07:43:31.


Input: While it is ambiguous as to which timezone the edits actually took place in (Kazakhstan or China) we assume the date timestamp references GMT because the press release states'' In the afternoon of December 15 local time…'' If we assume the photograph and afternoon meeting took place sometime prior to 13:43 Alma-Ata standard time (+0600) this would closely correspond with a 07:43 GMT time stamp.


Input: The modification of the gop-script.js by the attackers at 08:07:06 GMT likely tracks extremely close to a window of a few hours in which Keqiang met with Abdullah.


Input: It is worth mentioning that a similar scenario occurred on June 20th when security researcher PhysicalDrive0 observed a malicious Java file hosted on the Embassy of Greece in Beijing.


Input: At the time, a Chinese delegation led by Keqiang was visiting Greek Prime Minister Antonis Samaras in Athens.


Input: Security researcher R136a1 aka'' thegoldenmessenger'' released a followup blog with detailed analysis of the Greek embassy compromise.


Input: While these two separate events are not directly related, additional research into the status of ministerial and official government websites on or around the dates of notable Chinese delegations and or bilateral meetings may yield additional patterns of interest.


Input: Upon closer inspection of the prepended malicious JavaScript code, one will notice the similarity in the update.javaplug-in [.


Input: ] com naming convention and URL structure to the C2 domain java-se [.


Input: ] com found in the Palo Alto Networks blog post Attacks on East Asia using Google Code for Command and Control and associated with Operation Poisoned Hurricane.


Input: However, the malicious document.write driveby URLs listed above both result in 403 Forbidden errors as of December 18, 2014.


Input: While the 403 Forbidden errors may seem like an analytic dead end, the TCIRT also identified a malicious Java applet submission to VirusTotal that confirms the nature of this malicious activity.


Input: This Java applet, SHA1: 388E6F41462774268491D1F121F333618C6A2C9A, has no antivirus detections as of December 21st.


Input: The applet contains its malicious class file at the path'' jre7u61windows/x86/Update.class''.


Input: This class file downloads and decodes an XOR 0xC8 encoded Windows PE executable payload from [http:] //mfa.gov [.] af/content/images/icon35.png, hosted on the official Afghan Ministry of Foreign Affairs site, which was also affected by the gop-script XSS.

This class file

an XOR 0xC8 encoded Windows PE executable payload

[http:] //mfa.gov [.] af/content/images/icon35.png

downloads and decodes

from


Input: Using historic context archived within ThreatConnect, the TCIRT concluded that this Java applet is from the same source code as the applet SHA1: ADC162DD909283097E72FC50B7AB0E04AB8A2BCC, which was previously observed by the TCIRT at the Operation Poisoned Hurricane related URL [http:] //jre7.java-se [.


Input: ] com/java.jar on August 15, 2014.


Input: This applet has the same class path, and downloads an XOR 0xFF encoded payload executable from the URL [https:] //amco- triton.co [.] jp/js/dl/in.jpg.

This applet

an XOR 0xFF encoded payload executable

the URL [https:] //amco- triton.co [.] jp/js/dl/in.jpg

downloads

from


Input: Additional indicators and context associated with this particular Java driveby activity can be found in the ThreatConnect Common Community Incident 20140815A: The XOR 0xC8 encoded payload downloaded from [http:] //mfa.gov [.] af/content/images/icon35.png decodes into the Windows PE executable SHA1: This executable is a self-extracting (SFX) Microsoft Cabinet executable that is digitally signed with a valid certificate from'' OnAndOn Information System Co., Ltd.'', serial number'' 1F F7 D8 64 18 1C 55 5E 70 CF DD 3A 59 34 C4 7D''.

The XOR 0xC8 encoded payload

[http:] //mfa.gov [.] af/content/images/icon35.png

downloaded

from


Input: This same certificate was also used to sign the Java applet that downloaded this malware.


Input: This executable drops the following files: Malicious DLL that loads into the above dllhost.exe, using a similar DLL sideloading technique to that most commonly associated with the PlugX backdoor.

This executable

the following files

Malicious DLL

the above dllhost.exe

a similar DLL sideloading technique to that most commonly associated with the PlugX backdoor

drops

loads

using

into


Input: This backdoor connects to the faux Oracle Java themed command and control (C2) domain oracle0876634.javaplug-in [.] com.

This backdoor

the faux Oracle Java themed command and control (C2) domain oracle0876634.javaplug-in [.] com

connects

to


Input: Note that javaplug-in [.


Input: ] com is the same root domain found in the compromised version of [http:] //cdn.afghanistan [.


Input: ] af/scripts/gop-script.js as [http:] //update.javaplug- in [.


Input: ] com/o/j.js, confirming that this Java malware is in fact directly associated with the Afghan MCIT CDN XSS compromise.


Input: Full indicators of this activity and a YARA rule to detect the malware certificate can be found in the ThreatConnect Common Community under Incident 20141217A: Afghan Government Java Driveby and signature APTOnAndOncert.yara.


Input: As the US and NATO reduce their troop levels in Afghanistan, China is posturing to fill the gap of influence that the west is leaving behind.


Input: With plans to facilitate multilateral peace talks with the Taliban and establish major transportation projects which aim to bolster the Afghan economy, Beijing has been eyeing Afghanistan as part of its broader South Asian strategy.


Input: By exploiting and co-opting Afghan network infrastructure that is used by multiple ministerial level websites, Chinese intelligence services would be able to widely distribute malicious payloads to a variety of global targets using Afghanistan's government websites as a topical and trusted distribution platform, exploiting a single hidden entry point.

Chinese intelligence services

malicious payloads

a variety of global targets

Afghanistan's government websites as a topical and trusted distribution platform

distribute

to

using


Input: This being a variant of a typical'' watering-hole'' attack, the attackers will most likely infect victims outside the Afghan government who happened to be browsing any one of the CDN client systems, specifically, partner states involved in the planned troop reduction.

This

a variant of a typical'' watering-hole'' attack

being


Input: It is important to consider that corporate enterprises are not immune to this tactic, and this is not just a technique that is used by APT threat actors.


Input: If an enterprise's website leverages a CDN to speed up content delivery, unintended consequences must be anticipated.


Input: Fortunately, modern browsers now implement a security concept called'' Content Security Policy''.


Input: As long as the server's response headers are configured properly, third party content may be restricted to originating from a narrow whitelist.


Input: Just as attackers distribute malicious content to users en masse or CDN services distribute web content to users, security professionals must be able to quickly distribute actionable Threat Intelligence in formats readable by both humans and machines.


Input: ThreatConnect is the industry's first comprehensive Threat Intelligence Platform that enables enterprises to orchestrate the aggregation of Threat Intelligence from multiple sources, use integrated analytics and a robust API that gives enterprises the control to action their own Threat Intelligence, in the cloud and on premises.


Input: Register for a free account now to view the Common Community shares and more.


Input: Two years ago, we published our research into RedOctober, a complex cyber-espionage operation targeting diplomatic embassies worldwide.


Input: We named it RedOctober because we started this investigation in October 2012, an unusually hot month.


Input: After our announcement in January 2013, the RedOctober operation was promptly shut down and the network of C & Cs was dismantled.


Input: As usually happens with these big operations, considering the huge investment and number of resources behind it, they don't just'' go away'' forever.


Input: Normally, the group goes underground for a few months, redesigns the tools and the malware and resume operations.


Input: See: Since January 2013, we've been on the lookout for a possible RedOctober comeback.


Input: One possible hit was triggered when we observed Mevade, an unusual piece of malware that appeared late in 2013.


Input: The Mevade C & C name styles as well as some other technical similarities indicated a connection to RedOctober, but the link was weak.


Input: It wasn't until August 2014 that we observed something which made us wonder if RedOctober is back for good.


Input: In August 2014, some of our users observed targeted attacks with a variation of CVE-2012-0158 and an unusual set of malware.


Input: We did a quick analysis of the malware and it immediately stood out because of certain unusual things that are not very common in the APT world.


Input: Some of the filenames used in the attacks included: At least one of them immediately reminded us of RedOctober, which used a very similarly named spearphish:'' Diplomatic Car for Sale.doc''.

RedOctober

a very similarly named spearphish:'' Diplomatic Car for Sale.doc''

used


Input: As we started digging into the operation, more details emerged which supported this theory.


Input: Perhaps the most unusual fact was that the Microsoft Office exploit didn't directly write a Windows PE backdoor on disk.


Input: Instead, it writes an encrypted Visual Basic Script and runs it.

it

an encrypted Visual Basic Script

it

writes

runs


Input: This VBScript drops a pair of files on disk-a loader and an encrypted payload.

This VBScript

a pair of files

disk

drops

on


Input: The loader appears to be different every time and internal strings indicate it is'' polymorphically'' generated.


Input: The payload is always encrypted with a unique key, making it impossible to decrypt unless the DLL is available.

The payload

a unique key

is always encrypted

with


Input: We observed several different spear-phishing documents that drop uniquely named payloads.

several different spear-phishing documents

uniquely named payloads

drop


Input: For instance, the'' qPd0aKJu.vbs'' file MD5: E211C2BAD9A83A6A4247EC3959E2A730 drops the following files: The VBS also adds a registry key: HKEYCURRENTUSER\Software\Microsoft\Windows\CurrentVersion\Run\ setting the key'' bookstore'' to the value'' regsvr32% path% \ctfmonrn.dll /s'', which ensures the malware runs every time at system boot.

the following files

The VBS

a registry key: HKEYCURRENTUSER\Software\Microsoft\Windows\CurrentVersion\Run\

the key'' bookstore''

the value'' regsvr32% path% \ctfmonrn.dll /s''

the malware runs every time at system boot

drops

adds

setting

ensures

to


Input: Some of the DLL names we observed include: Some of the payload names include: The payload includes an encrypted configuration block which contains information about the C & C sever: The information from the config includes a WebDAV URL which is used for connections, a username and password, two folders on the WebDAV server used to store plugins/modules for the malware and where data from the victim should be uploaded.

an encrypted configuration block

information about the C & C sever

a WebDAV URL

connections

data from the victim

contains

is used

be uploaded

for


Input: The Cloud Atlas implants utilize a rather unusual C & C mechanism.

The Cloud Atlas implants

a rather unusual C & C mechanism

utilize


Input: All the malware samples we've seen communicate via HTTPS and WebDav with the same server'' cloudme.com'', a cloud services provider.

All the malware samples we've seen

HTTPS and WebDav

the same server'' cloudme.com'', a cloud services provider

communicate

via

with


Input: According to their website, CloudMe is owned and operated by CloudMe AB, a company based in Linköping, Sweden.


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


Input: Each malware set we have observed so far communicates with a different CloudMe account though.

Each malware set we have observed so far

a different CloudMe account

communicates

with


Input: The attackers upload data to the account, which is downloaded by the implant, decrypted and interpreted.

data

the implant

is downloaded


Input: In turn, the malware uploads the replies back to the server via the same mechanism.

the malware

the replies

the server

the same mechanism

uploads

back to

via


Input: Of course, it should be possible to reconfigure the malware to use any Cloud-based storage service that supports WebDAV.


Input: Here's a look at one such account from CloudMe: The data from the account: The files stored in the randomly named folder were uploaded by the malware and contain various things, such as system information, running processes and current username.

The files stored in the randomly named folder

the malware

various things, such as system information, running processes and current username

were uploaded

contain


Input: The data is compressed with LZMA and encrypted with AES, however, the keys are stored in the malware body which makes it possible to decrypt the information from the C & C.

The data

LZMA

AES

is compressed

encrypted

with

with


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

only one other group

accounts on the cloud provider mydrive.ch

connected

to


Input: Just like with RedOctober, the top target of Cloud Atlas is Russia, followed closely by Kazakhstan, according to data from the Kaspersky Security Network (KSN).


Input: Actually, we see an obvious overlap of targets between the two, with subtle differences which closely account for the geopolitical changes in the region that happened during the last two years.


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

some of the spear-phishing documents between Cloud Atlas and RedOctober

the same theme

the same entity

different times

exploit

target

at


Input: Both Cloud Atlas and RedOctober malware implants rely on a similar construct, with a loader and the final payload that is stored encrypted and compressed in an external file.


Input: There are some important differences though, especially in the encryption algorithms used–RC4 in RedOctober vs AES in Cloud Atlas.


Input: The usage of the compression algorithms in Cloud Altas and RedOctober is another interesting similarity.


Input: Both malicious programs share the code for LZMA compression algorithm.


Input: In CloudAtlas it is used to compress the logs and to decompress the decrypted payload from the C & C servers, while in Red October the'' scheduler'' plugin uses it to decompress executable payloads from the C & C.


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


Input: Another interesting similarity between the malware families is the configuration of the build system used to compile the binaries.


Input: Every binary created using the Microsoft Visual Studio toolchain has a special header that contains information about the number of input object files and version information of the compilers used to create them, the'' Rich'' header called so by the magic string that is used to identify it in the file.


Input: We have been able to identify several RedOctober binaries that have'' Rich'' headers describing exactly the same layout of VC 2010 + VC 2008 object files.


Input: Although this doesn't necessarily mean that the binaries were created on the same development computer, they were definitely compiled using the same version of the Microsoft Visual Studio up to the build number version and using similar project configuration.


Input: To summarize the similarities between the two: Finally, perhaps the strongest connection comes from targeting.


Input: Based on observations from KSN, some of the victims of RedOctober are also being targeted by CloudAtlas.

some of the victims of RedOctober

CloudAtlas

being targeted


Input: In at least one case, the victim's computer was attacked only twice in the last two years, with only two malicious programs–RedOctober and Cloud Atlas.


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


Input: Following big announcements and public exposures of targeted attack operations, APT groups behave in a predictable manner.


Input: Most Chinese-speaking attackers simply relocate C & C servers to a different place, recompile the malware and carry on as if nothing happened.

Most Chinese-speaking attackers

C & C servers

a different place

relocate

to


Input: Other groups that are more nervous about exposure go in a hibernation mode for months or years.


Input: Some may never return using the same tools and techniques.


Input: However, when a major cyber-espionage operation is exposed, the attackers are unlikely to completely shut down everything.


Input: They simply go offline for some time, completely reshuffle their tools and return with rejuvenated forces.


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


Input: Kaspersky products detect the malware from the Cloud Atlas toolset with the following verdicts: Blue Coat Exposes Inception Framework


Input: The attackers behind the breach of the New York Times' computer network late last year appear to be mounting fresh assaults that leverage new and improved versions of malware.


Input: The new campaigns mark the first significant stirrings from the group since it went silent in January in the wake of a detailed expose of the group and its exploits-and a retooling of what security researchers believe is a massive spying operation based in China.


Input: The newest campaign uses updated versions of Aumlib and Ixeshe.


Input: Aumlib, which for years has been used in targeted attacks, now encodes certain HTTP communications.

Aumlib

certain HTTP communications

encodes


Input: FireEye researchers spotted the malware when analyzing a recent attempted attack on an organization involved in shaping economic policy.


Input: And a new version of Ixeshe, which has been in service since 2009 to attack targets in East Asia, uses new network traffic patterns, possibly to evade traditional network security systems.

a new version of Ixeshe

new network traffic patterns

evade traditional network security systems

uses

to


Input: The updates are significant for both of the longstanding malware families; before this year, Aumlib had not changed since at least May 2011, and Ixeshe had not evolved since at least December 2011.


Input: Cybercriminals are constantly evolving and adapting in their attempts to bypass computer network defenses.


Input: But, larger, more successful threat actors tend to evolve at a slower rate.


Input: As long as these actors regularly achieve their objective (stealing sensitive data), they are not motivated to update or rethink their techniques, tactics, or procedures (TTPs).


Input: These threat actors' tactics follow the same principles of evolution–successful techniques propagate, and unsuccessful ones are abandoned.


Input: Attackers do not change their approach unless an external force or environmental shift compels them to.


Input: As the old saying goes: If it ain't broke, don't fix it.


Input: So when a larger, successful threat actor changes up tactics, the move always piques our attention.


Input: Naturally, our first priority is ensuring that we detect the new or altered TTPs.


Input: But we also attempt to figure out why the adversary changed-what broke?-so that we can predict if and when they will change again in the future.


Input: We observed an example of this phenomenon around May.


Input: About four months after The New York Times publicized an attack on its network, the attackers behind the intrusion deployed updated versions of their Backdoor.APT.Aumlib and Backdoor.APT.Ixeshe malware families.

the attackers behind the intrusion

updated versions of their Backdoor.APT.Aumlib and Backdoor.APT.Ixeshe malware families

deployed


Input: The previous versions of Aumlib had not changed since at least May 2011, and Ixeshe had not evolved since at least December 2011.


Input: We can not say for sure whether the attackers were responding to the scrutiny they received in the wake of the episode.


Input: But we do know the change was sudden.


Input: Akin to turning a battleship, retooling TTPs of large threat actors is formidable.


Input: Such a move requires recoding malware, updating infrastructure, and possibly retraining workers on new processes.


Input: The following sections detail the changes to Backdoor.APT.Aumlib and Backdoor.APT.Ixeshe.


Input: Aumlib has been used in targeted attacks for years.


Input: Older variants of this malware family generated the following POST request: Data sent via this POST request transmitted in clear text in the following structure: A recently observed malware sample (hash value 832f5e01be536da71d5b3f7e41938cfb) appears to be a modified variant of Aumlib.

Older variants of this malware family

the following POST request

Data

this POST request

generated

sent

via


Input: The sample, which was deployed against an organization involved in shaping economic policy, was downloaded from the following URL: The sample generated the following traffic: This output reveals the following changes when compared with earlier variants: The POST URI is changed to /bbs/search.asp (as mentioned, earlier Aumlib variants used a POST URI of /bbs/info.asp.


Input: ) The POST body is now encoded.

The POST body

is now encoded


Input: Additional requests from the sample generated the following traffic: These subtle changes may be enough to circumvent existing IDS signatures designed to detect older variants of the Aumlib family.


Input: The sample 832f5e01be536da71d5b3f7e41938cfb shares code with an older Aumlib variant with the hash cb3dcde34fd9ff0e19381d99b02f9692.


Input: The sample cb3dcde34fd9ff0e19381d99b02f9692 connected to documents [.] myPicture [.] info and www [.] documents [.] myPicture [.] info and as expected generated the a POST request to /bbs/info.asp.

The sample cb3dcde34fd9ff0e19381d99b02f9692

documents [.] myPicture [.] info and www [.] documents [.] myPicture [.] info

a POST request

connected

generated

to

to


Input: Ixeshe has been used in targeted attacks since 2009, often against entities in East Asia.


Input: Although the network traffic is encoded with a custom Base64 alphabet, the URI pattern has been largely consistent: We analyzed a recent sample that appears to have targeted entities in Taiwan, a target consistent with previous Ixeshe activity.

the network traffic

a custom Base64 alphabet

is encoded

with


Input: This sample (aa873ed803ca800ce92a39d9a683c644) exhibited network traffic that does not match the earlier pattern and therefore may evade existing network traffic signatures designed to detect Ixeshe related infections.

This sample (aa873ed803ca800ce92a39d9a683c644)

existing network traffic signatures designed to detect Ixeshe related infections

evade


Input: The Base64-encoded data still contains information including the victim's hostname and IP address but also a'' mark'' or'' campaign tag/code'' that the threat actors use to keep track of their various attacks.

The Base64-encoded data

information including the victim's hostname and IP address

contains


Input: The mark for this particular attack was [ll65].


Input: Based on our observations, the most successful threat actors evolve slowly and deliberately.


Input: So when they do change, pay close attention.


Input: Knowing how attackers' strategy is shifting is crucial to detecting and defending against today's advanced threats.


Input: But knowing the'' why'' is equally important.


Input: That additional degree of understanding can help organizations forecast when and how a threat actor might change their behavior-because if you successfully foil their attacks, they probably will.


Input: This entry was posted in Threat Intelligence, Threat Research by Ned Moran and Nart Villeneuve.


Input: Bookmark the permalink.


Input: At the end of April Microsoft announced that a vulnerability in Word was actively being exploited.


Input: This vulnerability occurred in parsing RTF files and was assigned CVE-2014-1761, a thorough analysis of which can be found on the HP Security Research blog.


Input: We have since seen multiple cases where this exploit is used to deliver malware and one was particularly interesting as it contained a new variant of MiniDuke (also known as Win32/SandyEva).

this exploit

malware

deliver


Input: MiniDuke was first discussed by Kaspersky in March 2013 in their paper The MiniDuke Mystery: PDF 0- day Government Spy Assembler 0x29A Micro Backdoorand shortly after in a paper by Bitdefender.


Input: Some of the characteristics of MiniDuke-such as its small size (20 KB), its crafty use of assembly programming, and the use of zero-day exploits for distribution-made it an intriguing threat.

MiniDuke

zero-day exploits

distribution

use

for


Input: Although the backdoor is still quite similar to its previous versions, some important changes were made since last year, the most notable being the introduction of a secondary component written in JScript to contact a C & C server via Twitter.

a secondary component written in JScript

a C & C server

Twitter

contact

via


Input: The exploit document was named Proposal-Cover-Sheet-English.rtf and is quite bland when compared to the documents that were used in 2013, which were of a political nature.


Input: We received the document on April 8th, only three days after the compilation of the MiniDuke payload, dated April 5th in the PE header.


Input: The payload remains quite small at only 24 KB.


Input: The functionality of the shellcode which is executed by triggering the vulnerability is rather simple and straightforward.

the shellcode

triggering the vulnerability

is executed

by


Input: After decrypting itself and obtaining the addresses of some functions exported by kernel32.dll, it decrypts and drops the payload in the% TEMP% directory in a file named'' a.l'' which is subsequently loaded by calling kernel32! LoadLibraryA.

it

the payload

the% TEMP% directory in a file named'' a.l''

calling kernel32! LoadLibraryA

decrypts and drops

is subsequently loaded

in

by


Input: An interesting thing about the shellcode is that before transferring control to any API function it checks the first bytes of the function in order to detect hooks and debugger breakpoints which may be set by security software and monitoring tools.

it

hooks and debugger breakpoints which may be set by security software and monitoring tools

detect


Input: If any of these are found the shellcode skips the first 5 bytes of the function being called by manually executing prologue instructions (mov edi, edi; push ebp; mov ebp, esp) and then jumping to the function code as illustrated below.


Input: The next graph presents the execution flow of this malware when the exploitation is successful.


Input: As mentioned previously this version of the MiniDuke payload comes with two modules which we refer to as the main module and the TwitterJS module.


Input: Once MiniDuke receives control it checks that the host process is not rundll32.exe and whether the current directory is% TEMP%.


Input: If either of those conditions is met the malware assumes it is run for the first time and it proceeds with its installation onto the system.

it

its installation onto the system

proceeds

with


Input: MiniDuke gathers information about the system and encrypts its configuration based on that information, a method also used by OSX/Flashback (this process is called watermarking by Bitdefender).

MiniDuke

information about the system

its configuration

that information

gathers

encrypts

based on


Input: The end result is that it is impossible to retrieve the configuration of an encrypted payload if analyzing it on a different computer.

impossible to retrieve

the configuration of an encrypted payload

analyzing it on a different computer

if


Input: The information collected on infection has not changed since the previous version and consists of the following values: Once the encrypted version of the malware is created, it is written into a file in the% ALLUSERSPROFILE% \Application Data directory.

the encrypted version of the malware

it

a file in the% ALLUSERSPROFILE% \Application Data directory

is created

is written

into


Input: The name of the file is randomly picked from the following values (you can find this listing and those of the next screenshots on the VirusRadar description: The filename extension is also picked randomly from the following list: To persist on the infected system after reboots, the malware creates a hidden .LNK file in the'' Startup'' directory pointing to the modified main module.

persist

creates

on

after

in

the infected system

reboots

the malware

a hidden .LNK file

the'' Startup'' directory


Input: The name of the .LNK


Input: file is randomly drawn from the following values: The .LNKfile

The .LNKfile


Input: is created using a COM object with the IShellLinkA interface and contains the following command:'' C: \Windows\system32\rundll32.exe% pathtomainmodule%, exportfunction'' Which gives something like:'' C: \Windows\system32\rundll32.exe C: \DOCUME~1\ALLUSE~1\APPLIC~1\data.cat, IlqUenn''.

is created

using

with

a COM object

the IShellLinkA interface


Input: When the malware is loaded by rundll32.exe and the current directory isn't% TEMP%, the malware starts with gathering the same system information as described in the'' Installation'' section to decrypt configuration information.

the malware

the malware

the same system information as described in the'' Installation'' section

decrypt configuration information

is loaded

gathering

to


Input: As with the previous version of MiniDuke, it checks for the presence of the following processes in the system: If any of these are found in the system the configuration information will be decrypted incorrectly, i.e.


Input: the malware will run on the system without any communication to C & C servers.


Input: If the configuration data is decrypted correctly, MiniDuke retrieves the Twitter page of @FloydLSchwartz in search of URLs by which to reach C & C server.

MiniDuke

the Twitter page of @FloydLSchwartz

search of URLs by which to reach C & C server

retrieves

in


Input: It looks for the tag'' X)))'' on the page (MiniDuke was searching for'' uri!'' in previous samples) and if the tag is found it decrypts a URL from the data that follows it.


Input: The Twitter account @FloydLSchwartz does exist but has only retweets and no strings with the special tag.


Input: As the next step, MiniDuke gathers the following information from the infected systems: This information is then sent to the C & C server along with the request to download a payload.

MiniDuke

the following information

the infected systems

This information

the C & C server

download a payload

gathers

is then sent

request

from

to

to


Input: The final URL used to communicate with the C & C server looks like this: < urlstart > /create.php? < rndparam > = < systeminfo > Those tokens are derived as follows: An example of such a URL is given below: The payload is downloaded in the file named'' fdbywu'' using the urlmon! URLDownloadToFileA API: The downloaded payload is a fake GIF8 file containing encrypted executable.

The final URL

communicate with the C & C server

The payload

the file named'' fdbywu''

the urlmon! URLDownloadToFileA API

used

is downloaded

to

in

using


Input: The malware processes the downloaded file in the same way as previous samples of MiniDuke: it verifies the integrity of the file using RSA-2048, then decrypts it, stores in a file and finally executes it.

it

the integrity of the file

it

verifies

executes

using


Input: The RSA-2048 public key to verify integrity of the executable inside the GIF file is the same as in the previous version of MiniDuke.

The RSA-2048 public key

integrity of the executable inside the GIF file

verify


Input: In the event that MiniDuke is unable to retrieve a C & C URL from this account, it generates a username to search for based on the current date.


Input: The search query changes roughly every seven days and is similar to the backup mechanism in previous versions that was using Google searches.


Input: A Python implementation of the algorithm can be found in Appendix B.


Input: The TwitterJS module is extracted by creating a copy of the Windows DLL cryptdll.dll, injecting a block of code into it and redirecting the exported functions to this code.

creating

a copy of the Windows DLL cryptdll.dll


Input: Here is how the export address table of the patched binary looks after modifications.


Input: This file is then stored in an Alternate Data Stream (ADS) in NTUSER.DAT in the% USERPROFILE% folder.

This file

an Alternate Data Stream (ADS) in NTUSER.DAT in the% USERPROFILE% folder

is then stored

in


Input: Finally this DLL is registered as the Open command when a drive is open, which has the effect of starting the bot every time the user opens a disk drive.

this DLL

the Open command when a drive is open

the bot

the user opens a disk drive

is registered

starting

as

every time


Input: Below you can find the content of the init.cmd script used by MiniDuke to install TwitterJS module onto the system.

MiniDuke

TwitterJS module

the system

install

onto


Input: When loaded, TwitterJS instantiates the JScript COM object and decrypts a JScript file containing the core logic of the module.


Input: Prior to executing it, MiniDuke applies a light encoding to the script: The next images show the result of two separate obfuscations, we can see that the variables have different values.

MiniDuke

a light encoding

the script

applies

to


Input: This is probably done to thwart security systems that scan at the entry points of the JScript engine.

This

security systems that scan at the entry points of the JScript engine

thwart


Input: The purpose of this script is to use Twitter to find a C & C and retrieve JScript code to execute.

this script

Twitter

find a C & C

JScript code to execute

use

retrieve

to


Input: It first generates a Twitter user to search for; this search term changes every 7 days and is actually a match to the real account name, not the Twitter account name.


Input: The bot then visits the Twitter profiles returned by the search and looks for links that end with'' .xhtml


Input: When one is found, it replaces'' .xhtml


Input: '' with'' .php


Input: '' and fetches that link.


Input: Information about the computer is embedded in the Accept HTTP header.


Input: The first link on the retrieved page should contain base64 data; the name attribute of the link is used as a rolling XOR key to decrypt the JScript code.


Input: Finally, MiniDuke calculates a hash of the fetched script and compares it with a hardcoded hash in the TwitterJS script.


Input: If they match, the fetched script is executed by calling eval ().


Input: The code hashing algorithm used by the component looks very much like SHA-1 but outputs different hashes (you can find the complete implementation in Appendix B.


Input: We decided to search for what was changed in the algorithm; one of our working hypotheses was that the algorithm might have been altered to make collisions feasible.


Input: We couldn't find an obvious difference; all the constants and the steps of the algorithm were as expected.


Input: Then we noticed that for short messages only the second 32-bit word was different when compared to the original SHA-1.


Input: By examining how this 2nd word was generated we finally discovered that this was caused by a scope issue.


Input: As shown below the SHA-1 function used a variable named f: the function Z () is then called which also uses a variable named f without the var keyword, causing it to be treated as a global variable rather than local to the function.


Input: The end result is that the value of f is also changed in the SHA-1 function which affects the value of the 2nd word for that round and ultimately the whole hash for long messages.


Input: A likely explanation of how this problem came to be is that the variable names were changed to single letters using an automated tool prior to embedding it in the payload.


Input: The 2 f variables probably had different names in the original script which avoided the issue.


Input: So this leaves us with two takeaways: 1) The difference in the hashing algorithm was unintentional and 2) Always declare your local variables with the var keyword.


Input: ;-) We generated the list of Twitter search terms for 2013-2014 and checked if any of those were registered.


Input: At the moment only one exists, @AA2ADcAOAA, which is the TwitterJS account that was generated between August 21st and 27th 2013.


Input: This account has no tweets.


Input: In an effort to discover potential victims, we registered the Twitter accounts corresponding to the current week both for the main and TwitterJS components and set up tweets with encrypted URLs so that an infected computer would reach out to our server.


Input: So far we have received connections via the TwitterJS accounts from four computers located in Belgium, France and the UK.


Input: We have contacted national CERTs to notify the affected parties.


Input: We detect the RTF exploit document as Win32/Exploit.CVE-2014-1761.D and the MiniDuke components as Win32/SandyEva.G.


Input: In the world of malware threats, only a few rare examples can truly be considered groundbreaking and almost peerless.


Input: What we have seen in Regin is just such a class of malware.


Input: Regin is an extremely complex piece of software that can be customized with a wide range of different capabilities which can be deployed depending on the target.

Regin


Input: It is built on a framework that is designed to sustain long-term intelligence-gathering operations by remaining under the radar.

It

long-term intelligence-gathering operations

the radar

sustain

remaining

under


Input: It goes to extraordinary lengths to conceal itself and its activities on compromised computers.

It

itself and its activities on compromised computers

conceal


Input: Its stealth combines many of the most advanced techniques that we have ever seen in use.


Input: The main purpose of Regin is intelligence gathering and it has been implicated in data collection operations against government organizations, infrastructure operators, businesses, academics, and private individuals.

The main purpose of Regin

intelligence gathering

it

data collection operations against government organizations, infrastructure operators, businesses, academics, and private individuals

is

implicated

in


Input: The level of sophistication and complexity of Regin suggests that the development of this threat could have taken well-resourced teams of developers many months or years to develop and maintain.


Input: Regin is a multi-staged, modular threat, meaning that it has a number of components, each depending on others, to perform attack operations.


Input: This modular approach gives flexibility to the threat operators as they can load custom features tailored to individual targets when required.


Input: Some custom payloads are very advanced and exhibit a high degree of expertise in specialist sectors.


Input: The modular design also makes analysis of the threat difficult, as all components must be available in order to fully understand it.

The modular design

analysis of the threat difficult

makes


Input: This modular approach has been seen in other sophisticated malware families such as Flamer and Weevil (The Mask), while the multi-stage loading architecture is similar to that seen in the Duqu/Stuxnet family of threats.


Input: Regin is different to what are commonly referred to as'' traditional'' advanced persistent threats (APTs), both in its techniques and ultimate purpose.


Input: APTs typically seek specific information, usually intellectual property.

APTs

specific information, usually intellectual property

seek


Input: Regin's purpose is different.


Input: It is used for the collection of data and continuous monitoring of targeted organizations or individuals.

It

the collection of data

targeted organizations or individuals

is used

monitoring

for

of


Input: This report provides a technical analysis of Regin based on a number of identified samples and components.


Input: This analysis illustrates Regin's architecture and the many payloads at its disposal.


Input: Regin is a multi-purpose data collection tool which dates back several years.


Input: Symantec first began looking into this threat in the fall of 2013.


Input: Multiple versions of Regin were found in the wild, targeting several corporations, institutions, academics, and individuals.


Input: Regin has a wide range of standard capabilities, particularly around monitoring targets and stealing data.

Regin

targets

data

monitoring

stealing


Input: It also has the ability to load custom features tailored to individual targets.


Input: Some of Regin's custom payloads point to a high level of specialist knowledge in particular sectors, such as telecoms infrastructure software, on the part of the developers.


Input: Regin is capable of installing a large number of additional payloads, some highly customized for the targeted computer.

Regin

a large number of additional payloads

installing


Input: The threat's standard capabilities include several remote access Trojan (RAT) features, such as capturing screenshots and taking control of the mouse's point-and-click functions.

The threat's standard capabilities

several remote access Trojan (RAT) features

screenshots

control of the mouse's point-and-click functions

include

capturing

taking


Input: Regin is also configured to steal passwords, monitor network traffic, and gather information on processes and memory utilization.

Regin

passwords

network traffic

information on processes and memory utilization

steal

monitor

gather


Input: It can also scan for deleted files on an infected computer and retrieve them.

It

deleted files on an infected computer

them

scan

retrieve

for


Input: More advanced payload modules designed with specific goals in mind were also found in our investigations.


Input: For example, one module was designed to monitor network traffic to Microsoft Internet Information Services (IIS) web servers, another was designed to collect administration traffic for mobile telephony base station controllers, while another was created specifically for parsing mail from Exchange databases.

one module

network traffic to Microsoft Internet Information Services (IIS) web servers

another

administration traffic for mobile telephony base station controllers

another

mail from Exchange databases

monitor

collect

parsing


Input: Regin goes to some lengths to hide the data it is stealing.

Regin

the data

it

hide

is stealing


Input: Valuable target data is often not written to disk.

Valuable target data

disk

is often not written

to


Input: In some cases, Symantec was only able to retrieve the threat samples but not the files containing stolen data.


Input: Symantec is aware of two distinct versions of Regin.


Input: Version 1.0 appears to have been used from at least 2008 to 2011.


Input: Version 2.0 has been used from 2013 onwards, though it may have possibly been used earlier.


Input: Version 1.0 appears to have been abruptly withdrawn from circulation in 2011.


Input: Version 1.0 samples found after this date seem to have been improperly removed or were no longer accessible to the attackers for removal.


Input: This report is based primarily on our analysis of Regin version 1.0.


Input: We also touch on version 2.0, for which we only recovered 64-bit files.


Input: Symantec has assigned these version identifiers as they are the only two versions that have been acquired.


Input: Regin likely has more than two versions.


Input: There may be versions prior to 1.0 and versions between 1.0 and 2.0.


Input: The Regin operators do not appear to focus on any specific industry sector.


Input: Regin infections have been observed in a variety of organizations, including private companies, government entities, and research institutes.


Input: Infections are also geographically diverse, having been identified mainly in 10 different regions.


Input: The infection vector varies among targets.


Input: A reproducible infection vector is unconfirmed at time of writing.


Input: Targets may be tricked into visiting spoofed versions of well- known websites and the threat may be installed through a web browser or by exploiting an application.

the threat

a web browser

exploiting an application

be installed

through

by


Input: On one computer, log files show that Regin originated from Yahoo! Instant Messenger through an unconfirmed exploit.

Regin

Yahoo! Instant Messenger

an unconfirmed exploit

originated

from

through


Input: Regin has a six-stage architecture.


Input: The initial stages involve the installation and configuration of the threat's internal services.

The initial stages

the installation and configuration of the threat's internal services

involve


Input: The later stages bring Regin's main payloads into play.


Input: This section presents a brief overview of the format and purpose of each stage.


Input: The most interesting stages are the executables and data files stored in Stages 4 and 5.


Input: The initial Stage 1 driver is the only plainly visible code on the computer.


Input: All other stages are stored as encrypted data blobs, as a file or within a non-traditional file storage area such as the registry, extended attributes, or raw sectors at the end of disk.

All other stages

encrypted data blobs

are stored

as


Input: Symantec Security Response has not obtained the Regin dropper at the time of writing.


Input: Symantec believes that once the dropper is executed on the target's computer, it will install and execute Stage 1.

the dropper

it

Stage 1

install

execute


Input: It's likely that Stage 0 is responsible for setting up various extended attributes and/or registry keys and values that hold encoded versions of stages 2, 3, and potentially stages 4 and onwards.

Stage 0

various extended attributes and/or registry keys and values that hold encoded versions of stages 2, 3, and potentially stages 4 and onwards

setting up


Input: The dropper could be transient rather than acting as an executable file and may possibly be part of the infection vector exploit code.


Input: Stage 1 is the initial load point for the threat.

Stage 1

the initial load point for the threat

is


Input: There are two known Stage 1 file names: These are kernel drivers that load and execute Stage 2.

kernel drivers

Stage 2

load and execute


Input: These kernel drivers may be registered as a system service or may have an associated registry key to load the driver while the computer is starting up.

kernel drivers

the driver

load


Input: Stage 1 simply reads and executes Stage 2 from a set of NTFS extended attributes.

Stage 1

Stage 2

a set of NTFS extended attributes

reads and executes

from


Input: If no extended attributes are found, Stage 2 is executed from a set of registry keys.

Stage 2

a set of registry keys

is executed

from


Input: Stage 2 is a kernel driver that simply extracts, installs and runs Stage 3.

Stage 2

kernel driver

Stage 3

extracts, installs and runs


Input: Stage 2 is not stored in the traditional file system, but is encrypted within an extended attribute or a registry key blob.

Stage 2

an extended attribute or a registry key blob

is encrypted

within


Input: Stage 2 can be found encrypted in: This stage can also hide running instances of Stage 1.

Stage 2

This stage

running instances of Stage 1

be found encrypted

hide


Input: Once this happens, there are no remaining plainly visible code artifacts.


Input: Similar to previous stages, Stage 2 finds and loads an encrypted version of Stage 3 from either NTFS extended attributes or a registry key blob.

Stage 2

an encrypted version of Stage 3

either NTFS extended attributes or a registry key blob

finds and loads

from


Input: Stage 2 can also monitor the state of the threat.

Stage 2

the state of the threat

monitor


Input: This stage drops the file msrdc64.dat, which appears to always be 512 bytes in size.

This stage

the file msrdc64.dat

drops


Input: The first two bytes are used and the remaining bytes are set to zero.


Input: The second byte indicates the exclusive maximum number of instances allowed to run, which is set to two.


Input: This means no more than one instance should run at any time.


Input: The first byte indicates how many instances were run or attempted to run.


Input: Therefore, the potential combinations for the first two bytes are: Stage 3 is a kernel mode DLL and is not stored in the traditional file system.


Input: Instead, this file is encrypted within an extended attribute or registry key blob.

this file

an extended attribute or registry key blob

is encrypted

within


Input: Stage 3 can be found in the following locations: The file is six to seven times the size of the driver in Stage 2.


Input: In addition to loading and executing Stage 4, Stage 3 offers a framework for the higher level stages.

loading and executing

Stage 4

Stage 3


Input: Stages 3 and above are based on a modular framework of code modules.


Input: These modules offer functions through a private, custom interface.


Input: Each file in stages 3 and above can'' export'' functionality to other parts of Regin.


Input: In the case of Stage 3, the following primitives are offered: These primitives are provided through a custom export methodology.


Input: The Stage 3 DLL exports a wide range of functionality through a custom export methodology.


Input: The interface used to export functionality does not make use of the traditional Windows DLL export mechanism by name or ordinal.


Input: Exported Regin methods are referenced by a tuple consisting of a major and minor number.


Input: Stage 3 exports hundreds of methods, organized into 12 different major groups.


Input: The numbers used vary across versions.


Input: We acquired artifacts using two different numbering schemes.


Input: Table 2 is an example listing.


Input: With Regin's modular nature, Stage 4 kernel modules and Stage 5 user modules (payloads) can provide functionality and export routines using the same major and minor numbering scheme.


Input: The files for Stage 4, which are loaded by Stage 3, consist of a user-mode orchestrator and multiple kernel payload modules.

The files for Stage 4

Stage 3

are loaded


Input: They are stored in two EVFS containers as files: •% System% \config\SystemAudit.Evt: Contains Stage 4 kernel drivers, which constitute the kernel mode part of Regin's payload.


Input: •% System% \config\SecurityAudit.Evt: Contains a user mode version of Stage 3.


Input: The files are injected into services.exe.


Input: When the attackers who operated Regin cleaned up compromised computers once they were finished with them, they often failed to remove Stage 4 and 5 artifacts from the system.

the attackers who operated Regin

compromised computers

cleaned up


Input: Stage 4 also uses the same export methodology described in Stage 3.


Input: Stage 5 consists of the main Regin payload functionality.


Input: The files for Stage 5 are injected into services.exe by Stage 4.

The files for Stage 5

services.exe

Stage 4

are injected

into


Input: Stage 5 files are EVFS containers containing other files: Regin's payload involves the DLLs contained in the SystemLog.evt EVFS container.


Input: The payload functionality differs depending on the targeted computer.


Input: Custom payload files will likely be delivered for each specific environment.


Input: Example payload functionality seen to date includes: Regin stores data files and payloads on disk in encrypted virtual file system files.

Regin

data files and payloads

disk

encrypted virtual file system files

stores

on

in


Input: Such files are accessed by the major routines 3Dh.


Input: Files stored inside EVFS containers are encrypted with a variant of RC5, using 64-bit blocks and 20 rounds.

Files stored inside EVFS containers

a variant of RC5

64-bit blocks and 20 rounds

are encrypted

with

using


Input: The encryption mode is reverse cipher feedback (CFB).

The encryption mode

reverse cipher feedback (CFB)

is


Input: Known extensions for EVFS containers are *.evt and *.imd.


Input: The structure of a container is similar to the FAT file system.


Input: One major difference is that files do not have a name; instead, they're identified using a binary tag.


Input: The tag itself is the concatenation of a major number and a minor number.


Input: The major number typically indicates the major function group that will handle the file.


Input: A container starts with the header in Table 3 (little-endian ordering).


Input: The header is followed by the file entry table (Table 4).


Input: Each file entry is 13h+taglen bytes long.


Input: The sectors follow (Table 5).


Input: A sector of sectsize bytes starts with a DWORD pointing to the next sector (if the file does not fit within single sector), followed by sectsize-4 bytes of payload data.


Input: As explained above, the files are encrypted.

the files

are encrypted


Input: Other layers of encryption and compression may also be in place, although those would be handled by higher level components.


Input: Regin's C & C operations are extensive.

Regin's C & C operations

extensive

are


Input: These backchannel operations are bidirectional, which means either the attackers can initiate communications with compromised computers on the border network or the compromised computers can initiate communications with the attacker.

backchannel operations

bidirectional

the attackers

communications

compromised computers

the border network

the compromised computers

communications

the attacker

are

initiate

initiate

with

on

with


Input: Furthermore, compromised computers can serve as a proxy for other infections and command and control can also happen in a peer-to-peer fashion.

compromised computers

a proxy for other infections

command and control

a peer-to-peer fashion

serve

happen

as

in


Input: All communications are strongly encrypted and can happen in a two-stage fashion where the attacker may contact a compromised computer using one channel to instruct it to begin communications on a different channel.

All communications

a two-stage fashion

the attacker

a compromised computer

one channel

it

communications

a different channel

are strongly encrypted

happen

contact

instruct

begin

in

using

on


Input: Four transport protocols are available for C & C: • ICMP: Payload information can be encoded and embedded in lieu of legitimate ICMP/ping data.

Payload information

legitimate ICMP/ping data

be encoded and embedded

in lieu of


Input: The string'shit' is scattered in the packet for data validation.


Input: In addition, CRC checks use the seed'31337'.


Input: • HTTP: Payload information can be encoded and embedded within cookie data under the names SESSID, SMSWAP, TW, WINKER, TIMESET, LASTVISIT, AST.NETSessionId, PHPSESSID, or phpAdsd.

Payload information

cookie data

be encoded and embedded

within


Input: This information can be combined with another cookie for validation under the names USERIDTK, UID, GRID, UID=PREF=ID, TM, utma, LM, TMARK, VERSION, or CURRENT.


Input: The C & C operations are undertaken by various modules, including major groups C373h, 19h, 9, as well as Stage 5 payloads, such as C375h and 1Bh.

The C & C operations

various modules

are undertaken


Input: Regin logs data to the ApplicationLog.dat file.

Regin

data

the ApplicationLog.dat file

logs

to


Input: This file is not an encrypted container, but it is encrypted and compressed.

it

is encrypted and compressed


Input: Regin can be distributed with various payload modules or receive payload modules after infection.

Regin

various payload modules

payload modules

infection

be distributed

receive

with

after


Input: The extensible nature of Regin and its custom payloads indicate that many additional payloads are likely to exist in order to enhance Regin's capabilities.


Input: Furthermore, we have found data files accompanying payload modules that have not been recovered.


Input: The following table describes the Stage 4 kernel payload modules and Stage 5 user mode payload modules, which we have seen several variants of Regin use.


Input: The IIS web server log stealing module, 27E9h, is an example of a payload module that was installed after the initial infection and was specifically deployed for a particular target.

The IIS web server log

module

a payload module

the initial infection

stealing

was installed

after


Input: Only a small amount of the 64-bit Regin files have been recovered.


Input: These samples may represent version 2.0 or their differences may possibly be solely specific to 64-bit versions of Regin.


Input: We also recovered files from infected computers that may or may not be associated with 64-bit Regin, including several variants of svcsstat.exe, a file that aims to retrieve binary data over pipes or sockets and execute the data.

svcsstat.exe

a file

binary data

pipes

sockets

the data

retrieve

execute

over


Input: The recovered files do not appear to fundamentally vary from their 32-bit counterparts, apart from a few noteworthy differences.


Input: The 32-bit and 64-bit versions of Regin use different file names.


Input: These differences are shown in the first section of this paper as well as in the appendix.


Input: Most importantly, in the 64-bit version of Regin, the names of containers are changed: The 64-bit version of Regin's Stage 1 (wshnetc.dll) is no longer a kernel mode driver, as drivers under 64-bit Windows must be signed.


Input: Instead, Stage 1 is a user mode DLL loaded as a Winsock helper when the computer is starting up.

Stage 1

a Winsock helper

the computer is starting up

loaded

as

when


Input: Rather than loading Stage 2 from an NTFS extended attribute, Stage 1 looks for the last partition (in terms of physical location) on disk and searches for the payload in the raw sectors in this area of the disk.

Stage 1

the last partition (in terms of physical location) on disk

the payload

the raw sectors in this area of the disk

looks

searches

for

for

in


Input: The 64-bit Regin's Stage 3 has not been recovered.


Input: We believe that it may not exist, as the 32-bit version is a driver.


Input: Stage 4 is an orchestrator just like its 32-bit counterpart and it uses the same major and minor values to export functionality.


Input: No Stage 5 payload modules have been recovered.


Input: Regin is a highly-complex threat which has been used for large-scale data collection or intelligence gathering campaigns.

Regin

large-scale data collection or intelligence gathering campaigns

been used

for


Input: The development and operation of this threat would have required a significant investment of time and resources.


Input: Threats of this nature are rare and are only comparable to the Stuxnet/Duqu family of malware.


Input: The discovery of Regin serves to highlight how significant investments continue to be made into the development of tools for use in intelligence gathering.


Input: Many components of Regin have still gone undiscovered and additional functionality and versions may exist.


Input: Symantec and Norton products detect this threat as Backdoor.Regin.


Input: Regin's data files are classified as Stage 5 components and are contained in an EVFS container.


Input: As the data files are stored in a container, they do not have names.


Input: Just like Stage 5 modules, they are referenced by their filetag, which is the aggregation of the major and minor identifiers.


Input: The major identifier indicates which major routine group likely handles or creates the file.


Input: Not all data files have been recovered, so the information remains incomplete.


Input: Data files associated with Stage 4 kernel modules have not been recovered Table 8 lists recovered data files used by Stage 5 modules.


Input: The associated modules that supposedly manipulate those data files were not recovered.


Input: The following details can be used to help determine whether you have been impacted by this threat.


Input: Blue Coat researchers have uncovered a previously-undocumented, highly automated, and extremely sophisticated framework for performing targeted attacks.


Input: The framework is notable for a number of reasons, including (but not limited to) its use of a cloud-based infrastructure for command-and-control and its use of the WebDAV protocol to send instructions and receive exfiltrated information from compromised systems.

The framework

a cloud-based infrastructure

command-and-control

the WebDAV protocol

send instructions

receive exfiltrated information from compromised systems

use

use

for

to


Input: Initial malware components were embedded in Rich Text Format (RTF) files.


Input: Exploitation of vulnerabilities in this file format is leveraged to gain remote access to victim's computers.

Exploitation of vulnerabilities in this file format

gain remote access to victim's computers

is leveraged

to


Input: The framework, thus far, has been using the services of a cloud service provider based in Sweden, CloudMe.com, for its main command-and-control infrastructure.

The framework

the services of a cloud service provider based in Sweden, CloudMe.com

its main command-and-control infrastructure

been using

for


Input: Malware payloads designed for a wide array of potential devices, including home routers and mobile devices running iOS, BlackBerryOS or Android, were also recovered during the course of our research.


Input: The framework is designed in such a way that all post-infection communication (i.e. target surveying, configuration updates, malware updates, and data exfiltration) can be performed via the cloud service.

all post-infection communication (i.e. target surveying, configuration updates, malware updates, and data exfiltration)

the cloud service

be performed

via


Input: The malware components of this framework follow a plugin model, where new malware rely on other, previously delivered malware components to interact with the framework.


Input: Initial attacks were largely focused on Russia and a few other Eastern European countries.


Input: However, we have later seen that attackers are interested in targets all over the globe.


Input: The framework is itself target-agnostic, and seems highly automated.


Input: The operational security exhibited by the attackers is very good-among the best we have seen.


Input: Most interaction between attackers and their infrastructure is performed via a convoluted network of router proxies and rented hosts.

Most interaction between attackers and their infrastructure

a convoluted network of router proxies and rented hosts

is performed

via


Input: Although the attackers have left a few clues, we have been unable to provide attribution with any degree of accuracy.


Input: The use of software vulnerabilities in order to execute malicious software on unsuspecting users' computers is an important parameter to monitor.


Input: This method of attack is not only known to have a considerable success rate, it is also often deployed by resourceful attackers and, as such, marks a threat worth paying attention to.


Input: The use of exploits in document formats like PDF, DOC and RTF is in some ways especially noteworthy.


Input: Documents are commonly exchanged via mail, which make them perfect for email-borne targeted attacks; what is otherwise known as spear phishing.


Input: In March, 2014, Microsoft published information about a new vulnerability in Rich Text Format (RTF).


Input: This vulnerability, named CVE-2014-1761 (Microsoft Word RTF Object Confusion), had already been used effectively by attackers at the time of the announcement.


Input: Two previous vulnerabilities in the RTF file format, known as CVE-2010-3333 and CVE-2012-0158, had become, by that time, mainstays of targeted attacks, so we tracked how attackers implemented this new exploit with keen interest.


Input: By late August, we identified a malware espionage operation that used both the CVE-2014-1761 and CVE-2012-0158 vulnerabilities to trigger execution of the malicious payload, and which leveraged a single cloud service as the backbone of its entire visible infrastructure.


Input: When we examined the suspicious documents, it was discovered that they were somewhat anomalous compared to the run-of-the-mill material.


Input: They turned out to belong to a highly advanced and professional targeted attack framework, which utilized a complex series of techniques to survey potential targets.

a highly advanced and professional targeted attack framework

a complex series of techniques

survey potential targets

utilized

to


Input: Due to the many levels of obfuscation and indirection, we named this the Inception framework; but there ends all similarity with the movie by the same name.


Input: Leonardo DiCaprio is not associated with this investigation.


Input: We initially knew little about who the actual targets were; apart from one.


Input: In that particular case we had the actual phishing email, so we knew the apparent recipient–the CEO of a large Russian bank.

we

the actual phishing email

had


Input: The email was apparently sent from'' Mrs. World''; note the Mrs., and not Miss-World.


Input: We soon discovered that our malware repository contained several other, similar documents, but these had come from other sources which did not include the email message, or any identifiable information about the targets.


Input: However, the text of the documents covered a variety of topics mostly revolving around Russian issues relating to a variety of business sectors.


Input: The following pages highlight a representative selection of these documents.


Input: All documents that we have found so far have been rather standard Word documents, of the old 97-2003 compatible format based on OLE2.


Input: Such documents can, and typically do, contain quite a bit of metadata: The name of the document creator; the user who edited it most recently; the name of the company whose copy of Word was used to create the document, et al.


Input: Users can optionally configure Word to remove this metadata when a document is saved, and that's exactly what the creator of these documents did, stripping out this potential source of attribution data.


Input: However, Word documents in this format contain additional information, if you know where to look.


Input: All Word documents of this format contain what's known as a File Information Block (FIB).


Input: The FIB contains information about the file's internal structure, and also–to some extent–data on the program used to create the file.


Input: In the case of the samples we analyzed, all of the documents were saved using the same build of Microsoft Word from Office14 (better known as Office 2010).


Input: In addition, documents can contain slack space in which old data remains.


Input: For example, the decoy that came with the attack named'' Organigrama Gobierno Rusia.doc'' contains Visual Basic leftovers indicating that it originally was created on a computer that was configured to be used by a native Spanish speaker, apparently by an advisor at the Spanish Embassy in Moscow.


Input: This document was presumably obtained by the attackers and repurposed for the attack.

This document

the attackers

the attack

was presumably obtained

repurposed

for


Input: Despite the limited information at our disposal about the targets of these attacks, their content reveals some context about who the possible targets may have been.


Input: First of all, we have the decoy documents which indicate an interest in: We also have a set of phishing mails, which were targeted at: The shellcode used is a pretty standard variant previously used by a number of campaigns typically operating out of China, but with some minor changes.

we

the decoy documents

We

a set of phishing mails

have

have


Input: The malicious content is stored inside the document in encoded form, and the shellcode decodes and writes this to disk.

The malicious content

the document

encoded form

the shellcode

this

disk

is stored

writes

inside

in

to


Input: Upon successful execution this code drops a Word document and a Visual Basic script.

this code

a Word document and a Visual Basic script

drops


Input: The Word document is displayed to the user to avoid arousing any suspicion while the script is executed in the background.

the script

the background

is executed

in


Input: Unusual for many exploit campaigns, the names of the dropped files vary; for example HyHa9AJ.vbs, ewRg.vbs, 0QHdN.vbs, etc.

the names of the dropped files


Input: –clearly randomized in order to avoid detection by name.

randomized

in order to

avoid detection by name


Input: The VBScript dropper code is also a little unusual.


Input: It declares a Windows Management Instrumentation (WMI) object in order to reach components like the registry and file system.


Input: This seems adapted from Microsoft example code, like the one found at http: //msdn.microsoft.com/en-us/library/aa387236 (v=vs.85) .aspx


Input: When the VBSript is run it drops two files to disk.

it

two files

disk

drops

to


Input: One is a polymorphed dll file and the other a binary data file with no obvious internal structure.


Input: This data file turns out to be encrypted using AES-256.

This data file

be encrypted

using


Input: The files will be installed in several locations: These locations will vary some between operating system versions.

The files

several locations

be installed

in


Input: The VBScript then sets a startup key in the'' HKCU\Software\Microsoft\Windows\CurrentVersion\Run'' registry path to execute the DLLs at boot time.

The VBScript

a startup key

the'' HKCU\Software\Microsoft\Windows\CurrentVersion\Run'' registry path

the DLLs

boot time

sets

execute

in

at


Input: Regardless of whether the registry launches the DLL or when another malware executable starts the DLL directly, the DLL is launched using regsrv32.exe with the /s (silent) option.

the DLL

the /s (silent) option

is launched

using

with


Input: The names of these dropped files change from attack to attack.


Input: The one above drops ctfmonrc.dll.

The one above

ctfmonrc.dll

drops


Input: Other names observed were: The encrypted data files are named using random words apparently taken from a dictionary–'' acholias'','' arzner'','' bicorporate'','' crockrell'','' damnatorily'' etc.


Input: Looking at one of the dropped dlls we can see the authors originally called it 95Num3P3gm.dll.polymorphed.dll.


Input: When executed it will rebuild the original dll (95Num3p3gm.dll, presumably), load it from memory and pass over execution.

load

it

memory

from


Input: It is hard to describe the polymorphed dlls with any real depth, as there is little consistency between them.


Input: When two nearly identical dlls are encoded using the polymorphic scheme there is very little code in common.


Input: The call graphs are different and key functions have varying number of arguments.


Input: The polymorphing mechanism also generates, and inserts, unique functions all of which make calls to different floating-point operations–all done just to obfuscate the actual decoding process.

The polymorphing mechanism

the actual decoding process

obfuscate


Input: The sizes of buffers allocated are also randomized to mask their intent.


Input: What is common is that somewhere along the execution cycle is one extremely large function (over 200 kb in length) where early in a large allocation is made where the un-obfuscated binary will be placed.


Input: The binary is then built from de- obfuscating segments of it that have been dispersed through the'.rdata' section.


Input: The order, size, and locations of these segments vary from build to build but somewhere near the end of the large function there will be a call to a subfunction that loads the PE image into memory, followed by a call to free the PE image allocation from memory.

a call to a subfunction

the PE image

memory

a call

the PE image allocation

memory

loads

free

into

from


Input: Simply halting execution before this function call permits a researcher to extract the reconstructed DLL from memory.


Input: Here, pausing execution before the call to'loadpefrommemory' reveals the extracted PE at the memory address pointed to by edx.


Input: This reconstructed DLL, once loaded, will decode a configuration structure from its'.data' section which contains three important details: the name of the encrypted data file dropped by the VBScript; the AES key used to decrypt the file; and the name of a unique global mutex to hold while running to prevent multiple instances.


Input: This configuration information is used to load the encrypted file into memory and decrypt it.

This configuration information

the encrypted file

memory

load

into


Input: This turns out to be yet another dll.