CVE-2017-10271 Used to Deliver CryptoMiners: An Overview of TechniquesUsed Post-Exploitation and Pre-Mining


FireEye researchers recently observed threat actors abusing
CVE-2017-10271 to deliver various cryptocurrency miners.

CVE-2017-10271 is a known input validation vulnerability that exists
in the WebLogic Server Security Service (WLS Security) in Oracle
WebLogic Server versions and prior, and attackers can
exploit it to remotely execute arbitrary code. Oracle released a Critical
Patch Update
that reportedly fixes this vulnerability. Users who
failed to patch their systems may find themselves mining
cryptocurrency for threat actors.

FireEye observed a high volume of activity associated with the
exploitation of CVE-2017-10271 following the public posting of proof
of concept code in December 2017. Attackers leveraged this
vulnerability to subsequently download cryptocurrency miners in victim
environments. The recent cryptocurrency boom has resulted in a growing
number of operations – employing diverse tactics – aimed at stealing
cryptocurrencies. The idea that these cryptocurrency mining operations
are less risky, along with the potentially nice profits, could lead
cyber criminals to begin shifting away from ransomware campaigns.

Tactic #1: Delivering the miner directly to a vulnerable server

Some tactics we’ve observed involve exploiting CVE-2017-10271,
leveraging PowerShell to download the miner directly onto the victim’s
system (Figure 1), and executing it using ShellExecute().

Figure 1: Downloading the payload directly

Tactic #2: Utilizing PowerShell scripts to deliver the miner

Other tactics involve the exploit delivering a PowerShell script,
instead of downloading the executable directly (Figure 2).

Figure 2: Exploit delivering PowerShell script

This script has the following functionalities:

  • Downloading miners from remote servers

Figure 3: Downloading cryptominers

As shown in Figure 3, the .ps1 script
tries to download the payload from the remote server to a vulnerable server.

  • Creating scheduled tasks for persistence

Figure 4: Creation of scheduled task

  • Deleting scheduled tasks of other known cryptominers

Figure 5: Deletion of scheduled tasks
related to other miners

In Figure 4, the cryptominer creates a
scheduled task with name “Update service for Oracle
”.  In Figure 5, a different variant deletes this task
and other similar tasks after creating its own, “Update service for
Oracle productsa

From this, it’s quite clear that
different attackers are fighting over the resources available in the system.

  • Killing processes matching certain strings associated with other

Figure 6: Terminating processes directly

Figure 7: Terminating processes matching
certain strings

Similar to scheduled tasks deletion,
certain known mining processes are also terminated (Figure 6 and
Figure 7).

  • Connects to mining pools with wallet key

Figure 8: Connection to mining pools

The miner is then executed with
different flags to connect to mining pools (Figure 8). Some of the
other observed flags are: -a for algorithm, -k for keepalive to
prevent timeout, -o for URL of mining server, -u for wallet key, -p
for password of mining server, and -t for limiting the number of miner threads.

  • Limiting CPU usage to avoid suspicion

Figure 9: Limiting CPU Usage

To avoid suspicion, some attackers are
limiting the CPU usage of the miner (Figure 9).

Tactic #3: Lateral movement across Windows environments using
Mimikatz and EternalBlue

Some tactics involve spreading laterally across a victim’s
environment using dumped Windows credentials and the EternalBlue vulnerability

The malware checks whether its running on a 32-bit or 64-bit system
to determine which PowerShell script to grab from the command and
control (C2) server. It looks at every network adapter, aggregating
all destination IPs of established non-loopback network connections.
Every IP address is then tested with extracted credentials and a
credential-based execution of PowerShell is attempted that downloads
and executes the malware from the C2 server on the target machine.
This variant maintains persistence via WMI (Windows Management Instrumentation).

The malware also has the capability to perform a Pass-the-Hash
attack with the NTLM information derived from Mimikatz in order to
download and execute the malware in remote systems.

Additionally, the malware exfiltrates stolen credentials to the
attacker via an HTTP GET request to:

If the lateral movement with credentials fails, then the malware
uses PingCastle MS17-010 scanner (PingCastle is a French Active
Directory security tool) to scan that particular host to determine if
its vulnerable to EternalBlue, and uses it to spread to that host.

After all network derived IPs have been processed, the malware
generates random IPs and uses the same combination of PingCastle and
EternalBlue to spread to that host.

Tactic #4: Scenarios observed in Linux OS

We’ve also observed this vulnerability being exploited to deliver
shell scripts (Figure 10) that have functionality similar to the
PowerShell scripts.

Figure 10: Delivery of shell scripts

The shell script performs the following activities:

  • Attempts to kill already running cryptominers

Figure 11: Terminating processes matching
certain strings

  • Downloads and executes cryptominer malware

Figure 12: Downloading CryptoMiner

  • Creates a cron job to maintain persistence

Figure 13: Cron job for persistence

  • Tries to kill other potential miners to hog the CPU

Figure 14: Terminating other potential miners

The function shown in Figure 14 is used
to find processes that have high CPU usage and terminate them. This
terminates other potential miners and maximizes the utilization of resources.


Use of cryptocurrency mining malware is a popular tactic leveraged
by financially-motivated cyber criminals to make money from victims.
We’ve observed one threat actor mining around 1 XMR/day, demonstrating
the potential profitability and reason behind the recent rise in such
attacks. Additionally, these operations may be perceived as less risky
when compared to ransomware operations, since victims may not even
know the activity is occurring beyond the slowdown in system performance.

Notably, cryptocurrency mining malware is being distributed using
various tactics, typically in an opportunistic and indiscriminate
manner so cyber criminals will maximize their outreach and profits.

FireEye HX, being a behavior-based solution, is not affected by
cryptominer tricks. FireEye HX detects these threats at the initial
level of the attack cycle, when the attackers attempt to deliver the
first stage payload or when the miner tries to connect to mining pools.

At the time of writing, FireEye HX detects this activity with the
following indicators:

Detection Name

Indicators of Compromise

MD5 Name
3421A769308D39D4E9C7E8CAECAF7FC4 cranberry.exe/logic.exe
B3A831BFA590274902C77B6C7D4C31AE xmrig.exe/yam.exe
26404FEDE71F3F713175A3A3CEBC619B 1.ps1
D3D10FAA69A10AC754E3B7DDE9178C22 2.ps1
9C91B5CF6ECED54ABB82D1050C5893F2 info3.ps1
3AAD3FABF29F9DF65DCBD0F308FF0FA8 info6.ps1
933633F2ACFC5909C83F5C73B6FC97CC lower.css
B47DAF937897043745DF81F32B9D7565 lib.css
3542AC729035C0F3DB186DDF2178B6A0 bootstrap.css

Thanks to Dileep Kumar Jallepalli and Charles Carmakal for their
help in the analysis.

Go to Source
Author: Rakesh Sharma

COINHOARDER: Tracking a Ukrainian Bitcoin Phishing Ring DNS Style

This post is authored by Jeremiah O’Connor and Dave Maynor with contributions from Artsiom Holub and Austin McBride. 


Cisco has been tracking a bitcoin theft campaign for over 6 months. The campaign was discovered internally and researched with the aid of an intelligence sharing partnership with Ukraine Cyberpolice. The campaign was very simple and after initial setup the attackers needed only to continue purchasing Google AdWords to ensure a steady stream of victims. This campaign targeted specific geographic regions and allowed the attackers to amass millions in revenue through the theft of cryptocurrency from victims. This campaign demonstrates just how lucrative these sorts of malicious attacks can be for cybercriminals. Additionally, the revenue generated by these sorts of attacks, can then be reinvested into other cybercriminal operations.


On February 24, 2017, Cisco observed a massive phishing campaign hosted in Ukraine targeting the popular Bitcoin wallet site with a client request magnitude of over 200,000 client queries. This campaign was unique in that adversaries leveraged Google Adwords to poison user search results in order to steal users’ wallets. Since Cisco observed this technique, it has become increasingly common in the wild with attackers targeting many different crypto wallets and exchanges via malicious ads.

Cisco identified an attack pattern in which the threat actors behind the operation would establish a “gateway” phishing link that would appear in search results among Google Ads. When searching for crypto-related keywords such as “blockchain” or “bitcoin wallet,” the spoofed links would appear at the top of search results. When clicked, the link would redirect to a “lander” page and serve phishing content in the native language of the geographic region of the victim’s IP address.


The reach of these poisoned ads can be seen when analyzing DNS query data. In February 2017, Cisco observed spikes in DNS queries for the fake cryptocurrency websites where upwards of 200,000 queries per hour can be seen during the time window the ad was displayed. Here are two examples.


DNS Statistics for block-clain[.]info

The domain block-clain[.]info was used as the initial “gateway” victims would first visit. Victims would immediately be redirected to blockchalna[.]info, the landing page where the actual phishing content was hosted. These fraudulent sites are mostly hosted on bulletproof hosting providers based in Europe.

Here is what the actual lander phishing site looked like. Note how similar and convincing it is compared to a real site, with the exception of the URL:


After discovering these domains and the activity on Google Adwords, Cisco implemented a system to flag similar domains as malicious. This resulted in DNS requests being blocked to said domains. Additionally, Cisco researchers were able to track and monitor related networks and info, such as WHOIS registrant data.

This information allowed Cisco to use DNS graph traversal techniques to uncover other phishing domains associated with the initial site. In this example, we can see the registrant dsshvxcnbbu@yandex[.]ru, which is also associated with many other phishing sites:

Cisco also monitored the networks these domains are hosted on. Here is a snapshot of 2 of the recently active IP addresses for this campaign, and, and the ASN associated with these domains, Highload Systems, in Ukraine.

We can see the Second Level Domain (SLD) strings in these domains follow a similar pattern of targeting with many permutations of the string “blockchain”, along with co-occurrences of “http”, “https”, “wallet” in the SLD string. Here is a graph visualization of the domains on these infrastructures:


One of the most interesting facets to these attacks are the geographic regions of the victims. Using data from Umbrella Client Requester Distribution queries to these malicious domains, we can see a significant number of DNS resolution requests coming from countries such as Nigeria, Ghana, Estonia and many more.

This threat actors appears to be standing up phishing pages to target potential victims African countries and other developing nations where banking can be more difficult, and local currencies much more unstable compared to the digital asset. Additionally, attackers have taken notice that targeting users in countries whose first language is not English make for potentially easier targets. Based on the number of queries, this campaign is one of the biggest targeting to date. has been very proactive in supporting users. Kristov Atlas, a security and privacy engineer at, has even gone so far to say “phishing is one of our top areas of concern in protecting our users.”


Cisco has evidence the COINHOARDER group has been actively pilfering Bitcoin since at least 2015. Based on our findings, we estimate this group has stolen tens of millions of USD in cryptocurrency. While working with Ukraine law enforcement, we were able to identify the attackers’ Bitcoin wallet addresses and thus, we could track their activity for the period of time between September 2017 to December 2017. In this period alone, we quantified around $10M was stolen.In one specific run, they made $2M within 3.5 week period. Here we have a screenshot of one of the wallets, 19yAR4yvGcKV3SXUQhKnhi43m4bCUhSPc, related to this actor group, which has received a total of $1,894,433.09.

While identifying the individual who owns a specific wallet is extremely difficult, we still can look for open source intelligence surrounding the wallet. In December 2017, Cisco found posts on Reddit and Stack Exchange with addresses associated with stolen funds from this campaign, 13wahvu3FP8LK8P51UmEkhBUhyC7mzkrn3.

The wallet address in the screenshot above was also mentioned in a Reddit post in October 2017.

Based on our findings associated with this syndicate, we estimate the COINHOARDER group to have netted over $50M dollars over the past three years. It is important to note that the price of Bitcoin has shot up drastically over 2017, starting around $1,000 in January and hitting a high point just under $20,000 in December. While criminals were able to profit from this, it also adds a new level of complexity for criminals to convert their cryptocurrency funds to a fiat currency like US dollars. The historic price of Bitcoin during the height of this campaign would have made it very difficult to move these ill-gotten finances easily.


Ukraine is a hotbed for many types of attacks and a home for known bulletproof hosting providers. In the past year, Cisco has witnessed a substantial rise in financial motivated campaigns coming from and targeting this region. One of Cisco’s goals is to collaborate with countries worldwide and use our global visibility on attacks to asses their security posture and help improve it.

Some other observed IPs are and, which host domains targeting many currencies using IDN and SSL certs and are hosted on VServer in Ukraine. We also observed AS 58271 hosting multiple search engine poisoning attacks on Google and Bing:


Cisco has observed this threat actor evolve over time. Not only have we seen the COINHOARDER group abuse Google Adwords to generate traffic to their phishing servers, but we have also observed this group evolve to make their sites appear more legitimate. A few months after we began tracking this particular group, we observed them starting to use SSL certs issued by Cloudflare and Let’s Encrypt. SSL certificate abuse has been a rising trend among phishing campaigns in general. Below is an example of a wildcard SSL certificate issued by Cloudflare for the domain bockchain[.]info.

Here is an example of one of these SSL certificates issued by Let’s Encrypt associated with this campaign and the site blockcharin[.]info.

The COINHOARDER group has made heavy use of typosquatting and brand spoofing in conjunction SSL signed phishing sites in order to appear convincing. We have also observed the threat actors using internationalized domain names. These domains are used in what are called homograph attacks, where an international letter or symbol looks very similar to one in English. Here are some examples from this campaign.

The Punycode (internationalized) version is on the left, the translated (homographic) version on the right:

xn--blockchan-d5a[.]com → blockchaìn[.]com

xn--blokchan-i2a[.]info → blokchaín[.]info

These attacks can be nearly impossible to spot with the human eye, especially when delivered on a mobile platform and using these techniques helps coax users into handing over their funds.


Crypto assets have proven to be a new, valuable financial commodity targeted by varying degrees of cyber criminals. In 2017, we observed phishers advance their tactics by utilizing new attack vectors such as Google Adwords combined with the use of IDNs and rogue SSL certificates to improve their probability of success, and generate millions in profit.

What is clear from the COINHOARDER campaign is that cryptocurrency phishing via Google Adwords is a lucrative attack on users worldwide. Phishers are significantly improving their attack techniques by moving to SSL and employing the use of IDNs to fool victims into handing over their credentials. We can expect to see more of these realistic looking phishes with Let’s Encrypt releasing full wildcard certificate support at the end of this month. Cisco will continue to monitor the landscape and coordinate with international law enforcement teams in 2018 to help protect users and organizations.


The following IP address are known to have been used in these phishing attacks:


Go to Source
Author: Talos Group

ReelPhish: A Real-Time Two-Factor Phishing Tool

Social Engineering and Two-Factor Authentication

Social engineering campaigns are a constant threat to businesses
because they target the weakest chain in security: people. A typical
attack would capture a victim’s username and password and store it for
an attacker to reuse later. Two-Factor Authentication (2FA) or
Multi-Factor Authentication (MFA) is commonly seen as a solution to
these threats.

2FA adds an extra layer of authentication on top of the typical
username and password. Two common 2FA implementations are one-time
passwords and push notifications. One-time passwords are generated by
a secondary device, such as a hard token, and tied to a specific user.
These passwords typically expire within 30 to 60 seconds and cannot be
reused. Push notifications involve sending a prompt to a user’s mobile
device and requiring the user to confirm their login attempt. Both of
these implementations protect users from traditional phishing
campaigns that only capture username and password combinations.

Real-Time Phishing

While 2FA has been strongly recommended by security professionals
for both personal and commercial applications, it is not an infallible
solution. 2FA implementations have been successfully defeated using real-time
phishing techniques
. These phishing attacks involve interaction
between the attacker and victims in real time.

A simple example would be a phishing website that prompts a user for
their one-time password in addition to their username and password.
Once a user completes authentication on the phishing website, they are
presented with a generic “Login Successful” page and the one-time
password remains unused but captured. At this point, the attacker has
a brief window of time to reuse the victim’s credentials before expiration.

Social engineering campaigns utilizing these techniques are not new.
There have been reports of real-time
phishing in the wild
as early as 2010. However, these types of
attacks have been largely ignored due to the perceived difficulty of
launching such attacks. This article aims to change that perception,
bring awareness to the problem, and incite new solutions.

Explanation of Tool

To improve social engineering assessments, we developed a tool –
named ReelPhish – that simplifies the real-time phishing technique.
The primary component of the phishing tool is designed to be run on
the attacker’s system. It consists of a Python script that listens for
data from the attacker’s phishing site and drives a locally installed
web browser using the Selenium
. The tool is able to control the attacker’s web browser
by navigating to specified web pages, interacting with HTML objects,
and scraping content.

The secondary component of ReelPhish resides on the phishing site
itself. Code embedded in the phishing site sends data, such as the
captured username and password, to the phishing tool running on the
attacker’s machine. Once the phishing tool receives information, it
uses Selenium to launch a browser and authenticate to the legitimate
website. All communication between the phishing web server and the
attacker’s system is performed over an encrypted SSH tunnel.

Victims are tracked via session tokens, which are included in all
communications between the phishing site and ReelPhish. This token
allows the phishing tool to maintain states for authentication
workflows that involve multiple pages with unique challenges. Because
the phishing tool is state-aware, it is able to send information from
the victim to the legitimate web authentication portal and vice versa.


We have successfully used ReelPhish and this methodology on numerous
Red Team
engagements. The most common scenario we have come
across is an externally facing VPN portal with two-factor
authentication. To perform the social engineering attack, we make a
copy of the real VPN portal’s HTML, JavaScript, and CSS. We use this
code to create a phishing site that appears to function like the original.

To facilitate our real-time phishing tool, we embed server-side code
on the phishing site that communicates with the tool running on the
attacker machine. We also set up a SSH tunnel to the phishing server.
When the authentication form on the phishing site is submitted, all
submitted credentials are sent over the tunnel to the tool on the
attacker’s system. The tool then starts a new web browser instance on
the attacker’s system and submits credentials on the real VPN portal.
Figure 1 shows this process in action.

Figure 1: ReelPhish Flow Diagram

We have seen numerous variations of two-factor authentication on VPN
portals. In some instances, a token is passed in a “secondary
password” field of the authentication form itself. In other cases, the
user must respond to a push request on a mobile phone. A user is
likely to accept an incoming push request after submitting credentials
if the phishing site behaved identically to the real site.

In some situations, we have had to develop more advanced phishing
sites that can handle multiple authentication pages and also pass
information back and forth between the phishing web server and the
tool running on the attacking machine. Our script is capable of
handling these scenarios by tracking a victim’s session on the
phishing site and associating it with a particular web browser
instance running on the attacker’s system. Figure 1 shows a general
overview of how our tool would function within an attack scenario.

We are publicly releasing the tool on the FireEye GitHub
. Feedback, pull requests, and issues can also be
submitted to the Git repository.


Do not abandon 2FA; it is not a perfect solution, but it does add a
layer of security. 2FA is a security mechanism that may fail like any
other, and organizations must be prepared to mitigate the impact of
such a failure.

Configure all services protected by 2FA to minimize attacker impact
if the attacker successfully bypasses the 2FA protections. Lowering
maximum session duration will limit how much time an attacker has to
compromise assets. Enforcing a maximum of one concurrent session per
user account will prevent attackers from being active at the same time
as the victim. If the service in question is a VPN, implement strict
network segmentation. VPN users should only be able to access the
resources necessary for their respective roles and responsibilities.
Lastly, educate users to recognize, avoid, and report social
engineering attempts.

By releasing ReelPhish, we at Mandiant hope to highlight the need
for multiple layers of security and discourage the reliance on any
single security mechanism. This tool is meant to aid security
professionals in performing a thorough penetration test from beginning
to end.

During our Red Team engagements at Mandiant, getting into an
organization’s internal network is only the first step. The tool
introduced here aids in the success of this first step. However, the
overall success of the engagement varies widely based on the target’s
internal security measures. Always work to assess and improve your
security posture as a whole. Mandiant provides a variety of services
that can assist all types of organizations in both of these activities.

Go to Source
Author: Pan Chan

Targeted Attacks In The Middle East

This blog post is authored by Paul Rascagneres with assistance of Martin Lee.


Talos has identified a targeted attacks affecting the Middle East. This campaign contains the following elements, which are described in detail in this article.

  • The use of allegedly confidential decoy documents purported to be written by the Jordanian publishing and research house, Dar El-Jaleel. This institute is known for their research of the Palestinian-Israeli conflict and the Sunni-Shia conflict within Iran.
  • The attacker extensively used scripting languages (VBScript, PowerShell, VBA) as part of their attack. These scripts are used to dynamically load and execute VBScript functions retrieved from a Command & Control server.
  • The attacker demonstrates excellent operational security (OPSEC). The attacker was particularly careful to camouflage their infrastructure. During our investigation, the attacker deployed several reconnaissance scripts in order to check the validity of victim machine, blocking systems that don’t meet their criteria. The attacker uses the reputable CloudFlare system to hide the nature and location of their infrastructure. Additionally, the attacker filters connections based on their User-Agent strings, and only enables their infrastructure for short periods of time before blocking all connections.

This is not the first targeted campaign against the region that uses Dar El-Jaleel decoy documents which we have investigated. However, we have no indication that the previous campaigns are related.


Stage 1: VBScript

The campaign starts with a VBScript named من داخل حرب ايران السرية في سوريا.vbs (“From inside Iran’s secret war in Syria.vbs”). Here are the script contents:

The purpose of this script is to create the second stage PowerShell script described in the next section.

Stage 2: PowerShell Script

The goal of the generated PowerShell script is to create a Microsoft Office document named Report.doc and to open it.

Stage 3: Office Document With Macros

Here is a screenshot of the Office document:

This document purports to be written by Dar El-Jaleel. Dar El-Jaleel is a publishing and studies house based in Amman, Jordan. This institute is well-known for their research concerning the Palestinian-Israeli conflict and the Sunni-Shia conflict in Iran. Tagged as confidential, the document is an analysis report on Iranian activities within the Syrian civil war.

This document contains a Macro:

The purpose of this Macro in to create a WSF (Windows Script File) file and to execute it.

Stage 4: WSF Script

The created WSF script is the main part of the infection:

The top of the script contains configuration information:

  • the hostname of the Command & Control – office-update[.]services,
  • the port – 2095,
  • the User-Agent – iq.46-|-377312201708161011591678891211899134718141815539111937189811

The User-Agent is used to identify the targets. The CC filters network connections based on this string, only allowing through connections made with authorised User-Agent strings.

The first task of the script is to register the infected system by performing an HTTP request to http://office-update[.]services:2095/store. Next, the script executes an infinite loop, attempting to contact the /search URI every 5 seconds in order to download and execute additional payloads.

Additional Payloads

The WSF script receives payloads of three types, named s0, s1, s2. The payloads are VBScript functions loaded and executed on the fly with the ExecuteGlobal() and GetRef() APIs. The only differences between s0,s1 and s2 type payloads are the number of arguments supplied to the executing function. s0 does not require any arguments, s1 accepts one argument, and s2 two arguments.

The downloaded payload functions are obfuscated, here is an example of the raw data:

The first element is the function type (s0), followed by a separator ‘-|-‘. The second element is the obfuscated function; this consists of ASCII values, separated by ‘*’. For example the above data decodes as:

  • 45: –
  • 54: 6
  • 53: 5
  • 43: +
  • 49: 1
  • 52: 4
  • 56: 8
  • 42: *
  • 53: 5
  • 51: 3
  • 53: 5
  • 45: –
  • 52: 4
  • 49: 1
  • 56: 8
  • 42: *

Hence, the decoded data is “-65+148*535-418*”. Then follows a second step, again using ‘*’ as a separator. Each mathematical operation is resolved to obtain a new ASCII value:

  • -65+148 = 83 -> “S”
  • 535-419 = 117 -> “u”

This technique is used to construct a new VBScript function.
During our investigation we received 5 different functions.


During our investigation we received a reconnaissance function a few minutes after the initial compromise. The purpose of the function was to retrieve several pieces of information from the infected system, presumably in order to check if the target is valuable or not (or a sandbox system).

First, the attacker retrieves the disk volume serial number:

Secondly, the payload retrieves any installed anti-virus software:

Thirdly, it obtains the Internet IP address of the infected system by querying (the code includes a hint that the attacker previously used

Thirdly, it retrieves the computer name, the username, the Operating System and the architecture:

All these data are sent to the previously mentioned CC using the /is-return URI. The data are stored in the User-Agent separated by “-|-“.

Subsequently, we received a second reconnaissance function:

The function acts to list the drives of the infected system and their type (internal drive, usb driver etc.)


In addition to the reconnaissance functions we received 2 functions linked to the persistence of the WSF script. The first script is used to persist, the second is used to clean the infected system. Our machine was served this after taking too much time to send a request to the C2 Presumably the attacker determined we were examining their systems and decided to remove the malware to prevent further analysis:


Finally, we received a pivot function. The function is the only non-s0 function we obtained during our research. This is a s1 function that takes one argument:

Here is the argument:

The purpose is to execute a powershell script:

The PowerShell script executes a second base64 encoded script. The attacker forces the the system to use the 32 bit version of Powershell even if the operating system architecture is 64 bits.

Finally we obtain the last PowerShell script:

The purpose of this script is to download shellcode from 176[.]107[.]185[.]246 IP, to map it in memory and to execute it. The attacker takes many precautions before delivering the shellcode, these will be explained in the next chapter. Unfortunately during our investigation we weren’t served the anticipated shellcode.

Attackers OPSEC

The attacker behind this campaign put a lot of effort into protecting its infrastructure and to avoid leaking code to analysts. The first Command & Control server is protected by CloudFlare. This choice complicates the analysis and tracking of the campaign. Additionally, the attacker filters on the User-Agent; if your web requests do not fit a specific pattern, your request will be ignored. During our analysis the attacker was only active during the morning (Central European Timezone), similarly the various different payloads were only sent during mornings (Central European Time). When an infected system receives the pivot function, the attacker disables their firewall for a few minutes to allow this unique IP to download the shellcode. Afterwards, the server becomes unreachable. Here is a schema of this workflow:

Additionally, we saw that the attackers blacklisted some of our specific User-Agent strings and IP addresses used during our investigation

This high level of OPSEC is exceptional even among presumed state sponsored threat actors…

Links with Jenxcus (a.k.a. Houdini/H-Worm)?

If you are familiar with Jenxcus (a.k.a. Houdini/H-Worm) you should see some similarities between the VBScript used during this campaign and this well-known malware: usage of the user-agent to exfiltrate data, reconnaissance techniques etc…

We cannot tell if the attacker used a new version of Jenxcus or if this malware served as the inspiration for their own malicious code. The source code of Jenxcus can be easily found on the Internet. However, the adaptation used in this campaign is more advanced: the features/functions are loaded on demand and the initial script does not include all the malicious code unlike Jenxcus.

Additional Targets

We can identify different targets based on the User-Agent used by the attacker to identify victims. These are a few examples:

c = "U.15.7"
a = "738142201756240710471556115716122461214187935862381799187598"

c = "1X.134"
a = "130427201706151111209123451288122413771234715862388136654339"

c = "Fb-20.9"
a = "585010201750201110021112344661899112271619123139116684543113"


This is not the first time Talos has investigated targeted campaigns using Dar El-Jaleel decoy documents. During 2017, we identified several campaigns using the same decoy documents:

This document is a weekly report about the major events occuring during the 1st week of November 2017, talking about the most important events happening in Jordan, Iraq, Syria, Lebanon, Palestine, Israel, Russia, ISIS and the ongoing Gulf Countries conflict with Qatar.

We encountered this document in campaigns using .NET malware (with the CC: foxlive[.]life) and C++ malware (with the CC: download[.]share2file[.]pro). The purpose of the malwares was to retrieve information relating to the targeted systems and to download an additional payload. Moreover, we identified another campaign using a share2file[.]pro subdomain. Here is the decoy document in this campaign:

This document is a pension list of military personnel dated June 2017, containing names of individuals which we have redacted, alongside a military rank.

We don’t know if these campaigns are performed by the same actor or different groups interested in this region. These campaigns are still under investigation.


These campaigns show us that at least one threat actor is interested in and targeting the Middle East. Due to the nature of the decoy documents, we can conclude that the intended targets have an interest in the geopolitical context of the region. The attackers used an analysis report alleged to be written by Dar El-Jaleel, a Jordanian institute specialising in studies of the region. Some of these documents are tagged as confidential.

During the VBS Campaign, we were surprised by the level of OPSEC demonstrated by the attacker and their infrastructure. Legitimate service such as CloudFlare were used to hide malicious activities. Additionally the attacker used user-agent filtering and firewall rules in order to grant access to specific infected systems for only a few minutes in order to deliver shellcode. Following this, the server became unreachable. Another notable observation is the fact that the attacker was active only during the morning (Central European timezone) during our investigation.

The usage of script languages is an interesting approach from the attackers’ point of view. These languages are natively available on Windows system, provide a high degree of flexibility, and can easily stay under the radar.


Additional ways our customers can detect and block this threat are listed below.

Advanced Malware Protection (AMP) is ideally suited to prevent the execution of the malware used by these threat actors.

CWS or WSA web scanning prevents access to malicious websites and detects malware used in these attacks.

Email Security can block malicious emails sent by threat actors as part of their campaign.

Network Security appliances such as NGFW, NGIPS, andMeraki MX can detect malicious activity associated with this threat.

AMP Threat Grid helps identify malicious binaries and build protection into all Cisco Security products.

Umbrella, our secure internet gateway (SIG), blocks users from connecting to malicious domains, IPs, and URLs, whether users are on or off the corporate network.

Open Source Snort Subscriber Rule Set customers can stay up to date by downloading the latest rule pack available for purchase on


VBS Campaign:
Initial script: 15f5aaa71bfa3d62fd558a3e88dd5ba26f7638bf2ac653b8d6b8d54dc7e5926b
Domain #1: office-update[.]services
IP #2: 176[.]107[.]185[.]246

.NET Campaign:
Initial dropper: 4b03bea6817f0d5060a1beb8f6ec2297dc4358199d4d203ba18ddfcca9520b48
.NET #1: d49e9fdfdce1e93615c406ae13ac5f6f68fb7e321ed4f275f328ac8146dd0fc1
.NET #2: e66af059f37bdd35056d1bb6a1ba3695fc5ce333dc96b5a7d7cc9167e32571c5
Domain #1: jo[.]foxlove[.]life
Domain #2: eg[.]foxlove[.]life
Domain #3: fox[.]foxlove[.]life

Campaign #3:
Initial Dropper: af7a4f04435f9b6ba3d8905e4e67cfa19ec5c3c32e9d35937ec0546cce2dd1ff
Payload: 76a9b603f1f901020f65358f1cbf94c1a427d9019f004a99aa8bff1dea01a881
Domain: download[.]share2file[.]pro

Campaign #4:
Initial Dropper: 88e4f306f126ce4f2cd7941cb5d8fcd41bf7d6a54cf01b4a6a4057ed4810d2b6
Payload #1: c5bfb5118a999d21e9f445ad6ccb08eb71bc7bd4de9e88a41be9cf732156c525
Payload #2: 1176642841762b3bc1f401a5987dc55ae4b007367e98740188468642ffbd474e
Domain: update[.]share2file[.]pro

Go to Source
Author: Talos Group

Powered by WPeMatico

Trojan.APT.Seinup Hitting ASEAN

1. Executive Summary

The FireEye research team has recently identified a number of spear
phishing activities targeting Asia and ASEAN. Of these, one of the
spear phishing documents was suspected to have used a potentially
stolen document as a decoy. The rich and contextual details (body and
metadata) which are not available online lead us to believe this was
stolen. This decoy document mentioned countries such as Brunei,
Cambodia, Indonesia, Laos, Malaysia, Myanmar, Philippines, Singapore,
Thailand, and Vietnam, which leads us to suspect that these countries
are targeted. As the content of this decoy document is suspected to be
a stolen sensitive document, the details will not be published.

This malware was found to have used a number of advance techniques
which makes it interesting:

  1. The malware leverages Google Docs to perform redirection to
    evade callback detection. This technique was also found in the
    malware dubbed “Backdoor.Makadocs” reported by Takashi
    Katsuki (Katsuki, 2012).
  2. It is heavily equipped with a
    variety of cryptographic functions to perform some of its functions
  3. The malicious DLL is manually loaded into memory
    which hides from DLL listing.

As depicted in the diagram below, the spear phishing document (which
exploits CVE-2012-0158) creates a decoy document and a malware dropper
named exp1ore.exe. This dropper will then drop wab.exe (Address Book
Application) and wab32res.dll (malicious DLL) inside the temp folder.
By running wab.exe, the malicious DLL named wab32res.dll (located
within the same folder) will be loaded using DLL side-loading
technique. This will in turn install a copy of wab32res.dll as
msnetrsvw.exe inside the windows directory to be registered as Windows
service. By registering as a Windows service, it allows the malware to
survive every reboot and persist on the network.


Figure 1 Infection Flow

This malware is named “Trojan.APT.Seinup” because one of its export
functions is named “seinup”. This malware was analysed to be a
backdoor that allows the attacker to remote control the infected system.


Figure 2 Exported Functions

2. Related APT Domain and MD5

Based on our threat intelligence and reverse-engineering effort,
below are some related domain and MD5 sums. Please note that some of
the domain/IP association may change.

2.1. Related Domain

Domain/URL IP Country Comments

Registrar: XIN NET

Registrar: XIN NET

Registrar: XIN NET


Registrar: SHANGHAI







2.2. Associated Files

Name MD5 Comments

Spear-phishing document and decoy
Spear-phishing document and
decoy document






Benign Address Book Application
Benign Address Book



Malware to be side loaded when wab.exe is
Malware to be side loaded
when wab.exe is launched.



Malware to be installed as a service. Note: This is
the same as wab32res.dll.
Malware to be installed as
a service. Note: This is the same as wab32res.dll.


Calls to
Calls to


Calls to

Calls to


Calls to
Calls to


Calls to
Calls to


Calls to
Calls to


Calls to

Calls to

3. Interesting Technical Observations

3.1. Redirection Using Google Docs

By connecting the malicious server via Google Docs, the malicious
communication is protected by the legitimate SSL provided by Google
Docs (see Figure below). One possible way to examine the SSL traffic
is to make use of a hardware SSL decrypter within an organisation.
Alternatively, you may want to examine the usage pattern of the users.
Suppose a particular user accesses Google Docs multiple times a day,
the organization’s Incident Response team may want to dig deeper to
find out if the traffic is triggered by a human or by malware.

Retrieve Command

Figure 3 Retrieve Command via Google Docs

Below is the code that is used to construct a URL that retrieves
command via Google Docs. First, the malicious URL is constructed and
then encoded. Next, the malware simply leverages the Google Docs
viewer to retrieve the command from the malicious server (see Figure
below). 4.GoogleDocs

Figure 4 View Command via GoogleDocs

3.2. Zero-Skipping XOR Encryption

The shellcode encryption technique is fairly standard. The shellcode
has a decryption stub which decrypts its body using the XOR key 0x9E,
and this shellcode is used to extract exp1ore.exe(malware) and Wor.doc
(benign document).

The exp1ore.exe and Wor.doc were found within the spear phishing
document encrypted using the same key (0xFC) and technique. The XOR
key decrypts only a non-zero byte (see Figure 5). This prevents
statistical methods of recovering the XOR key. The encrypted
executable file and benign document were identified to be located
inside the spear phishing document at offsets 0x2509 and 0x43509 respectively.


Figure 5 Zero Skipping XOR Encryption

Even though statistical methods may not be useful in identifying the
XOR key as the zero bytes are not encrypted, we could use some of the
“known” strings below to hunt for the XOR key in this situation. By
sliding the known string across the array of bytes to perform a
windowed XOR, the key would be revealed when the encoded data is XORed
with the known string.

  • “This program cannot be run in DOS mode”
  • “KERNEL32.dll”
  • “LoadLibraryA”

3.3. Deployment of Various Cryptographic Functions

3.3.1. Secure Callback

The malware performs the callback in a secure manner. It uses a
custom Base64 map to encode its data, and creates a salted digital
thumbprint to allow validation of data.

Below describes the steps to validate a callback using an example of
the following URL:









The URL could be generalised as follows:


The definition of A’, B’, C’ and D’ are as follows:

Let H be the function which encodes binary into hexadecimal
characters prepend with “%”, if it is not alphanumeric, dash,
underscore or dot

Let B64 be the base 64 encoder using the following custom map, “URPBnCF1GuJwH2vbkLN6OQ/5S9TVxXKZaMc8defgiWjmo7pqrAstyz0D+El3I4hY”.

Let PT be the plain text which is in the form of
where HostName and IPAddress are string, and RunType is a character.

Let A be the random of 3 to 7 characters, and A’ = H(A)

Let B be B64 (PT), and B’ = H(B)

Let C be 32 char deliminator, and C’ = H(C)

Let D be H( MD5 ( salt  + MD5 ( B64(PT) + A + C )  )   ), salt =
“%^^*HFH)*$FJK)234sd2N@C(JGl2z94cg23”  , and D’ = H(D)

Hence, in this case, the specific malicious URL could be applied as follows:

Domain/  =

A’ = “5Pb

B’ = “6QeZky42OCQOLQuZ6dC2LQ7F56iAv6GpH6S%2Bw8npH5oAZk==

C’ = “cc3237bc79192a096440faca0fdae107

D’ = “


(This is the digital signature)

The hash could be verified as follow:

B64(PT) + A + C =
“6QeZky42OCQOLQuZ6dC2LQ7F56iAv6GpH6S+w8npH5oAZk==” +  “5Pb” + “cc3237bc79192a096440faca0fdae107”

MD5 (B64(PT) + A + C) = “766cf9e96c1a508c59f7ade1c50ecd28”

MD5 (salt + MD5(B64(PT) + A + C))   = MD5 (
“%^^*HFH)*$FJK)234sd2N@C(JGl2z94cg23” + “766cf9e96c1a508c59f7ade1c50ecd28”)

= 349118df672db38f9e65659874b60b27
(This equals to D’, which means verified)

The encoded plain text (B) could be recovered:

B64(PT) = “6QeZky42OCQOLQuZ6dC2LQ7F56iAv6GpH6S+w8npH5oAZk==”;

is the hostname, ‘F’ is the run type, “” is the IP address.

Note: This example is mocked up using a dummy computer name and IP address.

The python code below could be used to decode the custom encoded
string (see Figure below).


Figure 6 Python to Decode a Custom Base 64

3.3.2. Random Generator Using Mersenne Twister Algorithm

The malware was found to perform a callback at random intervals so
as to evade network investigation when looking for network connections
that are performed in a regular interval. Additionally, even the name
of the parameters in the get string have a random length and name,
which makes it hard to create a fix signature to detect such callbacks
(see ‎3.3.1 to understand how a callback is created).


Figure 7 Mersenne Twister Algorithm Seeding function

 3.4. In-Memory Only Malicious Code

On the disk, the malicious code is either encrypted or compressed to
evade scanning using signature rules. Only upon being loaded into
memory, does the malicious code (that appears to be in the form of a
DLL) get manually loaded without the use of Windows 32 API. In this
way, when an investigation is performed, the malicious DLL is not
revealed. Additionally, it makes it much harder for analysis to be performed.


Figure 8 Segments in the memory which contains the malicious code

Taking a deeper look at the decrypted malicious code, this malware
was found to contain at least the following functions:

  • Download file
  • Download and execute or load
  • Change sleep duration
  • Open and close
    interactive sessions

4. Conclusion

Malware is increasingly becoming more contextually advanced. It
attempts to appear as much as possible like legitimate software or
documents. In this example, we would conclude the following.

  1. A potentially stolen document was used as a decoy document to
    increase its credibility. It is also a sign that the compromised
    organisations could be used as a soft target to compromise their
    business partners and allies.
  2. It is important to put a stop
    to the malware infection at the very beginning, which is the
    exploitation phase. Once a network is compromised, it is
    increasingly harder to detect such threats.
  3. Anti-incident
    response/forensic techniques are increasingly used to evade
    detection. It would require a keen eye on details and a wealth of
    experience to identify all these advance techniques.

5. Works Cited

Carnegie Mellon University. (n.d.). Retrieved from

Katsuki, T. (19 Nov, 2012). Malware Targeting Windows 8 Uses
Google Docs.
Retrieved from

I would like to thank several colleagues for their significant
contributions on this post: Darien Kindlund, Ned Moran, Nart
Villeneuve, and Thoufique Haq.

Go to Source
Author: Chong Rong Hwa

Malware Callbacks

Today we released our first-ever analysis of malware callbacks. Our
report can be accessed here:

FireEye monitored more than 12 million malware communications seeking
instructions—or callbacks—across hundreds of thousands of infected
enterprise hosts, capturing details of advanced attacks as well as
more generic varieties during the course of 2012. Callback activity
reveals a great deal about an attacker’s intentions, interests and
geographic location. Cyber attacks are a widespread global activity.
We’ve built interactive maps that highlight the presence of malware

Our key findings:

  • Malware has become a multinational activity. Over the past
    year, callbacks were sent to command and control (CnC) servers in 184
    countries—a 42 percent increase when compared to 130 countries in 2010.
  • Two key regions stand out as hotspots driving advanced cyber
    attacks: Asia and Eastern Europe.
    Looking at the average
    callbacks per company by country, the Asian nations of China, South
    Korea, India, Japan, and Hong Kong accounted for 24 percent. Not far
    behind, the Eastern European countries of Russia, Poland, Romania,
    Ukraine, Kazhakstan, and Latvia comprised 22 percent. (North America
    represented 44 percent but this is due to CnC servers residing in the
    United States to help attackers with evasion.)
  • The majority of Advanced Persistent Threat (APT) callback
    activities are associated with APT tools that are made in China or
    that originated from Chinese hacker groups
    . By mapping the DNA
    of known APT malware families against callbacks, FireEye Malware
    Intelligence Lab discovered that the majority of APT callback
    activities—89 percent—are associated with APT tools that are made in
    China or that originated from Chinese hacker groups. The main tool is
    Gh0st RAT.
  • Attackers are increasingly sending initial callbacks to servers
    within the same nation in which the target resides
    . To improve
    evasion, hackers are increasingly placing CnC servers within target
    nations. At the same time, this fact gives a strong indicator of which
    countries are most interesting to attackers.
  • Technology organizations are experiencing the highest rate of APT
    callback activity
    . With a high volume of intellectual property,
    technology firms are natural targets for attackers and are
    experiencing heavy APT malware activity.
  • For APT attacks, CnC servers were hosted in the United States 66
    percent of the time, a strong indicator that the U.S. is still the
    top target country for attacks
    . As previously mentioned,
    attackers increasingly put CnC servers in the target country to help
    avoid detection. With such a high proportion of CnC servers, by a wide
    margin, the U.S. is subject to the highest rate of malware attacks.
    This is likely, due to a very high concentration of intellectual
    property and digitized data that resides in the U.S.
  • Techniques for disguising callback communications are evolving.
    To evade detection, CnC servers are leveraging social networking sites
    like Facebook and Twitter for communicating with infected machines.
    Also, to mask exfiltrated content, attackers embed information inside
    common files, such as JPGs, to give network scanning tools the
    impression of normal traffic.
  • Attack patterns vary substantially globally:
  • South Korean firms experience the highest level of callback
    communications per organization
    . Due to a robust internet
    infrastructure, South Korea has emerged as a fertile location for
    cybercriminals to host their CnC infrastructure. For example, FireEye
    found that callbacks from technology firms are most likely to go to
    South Korea.
  • In Japan, 87 percent of callbacks originated and stayed in
    . This may give an indication of the high value of Japanese
    intellectual property.
  • In Canada, 99 percent of callbacks exited the country. In the U.K.,
    exit rates were 90 percent
    . High exit rates indicate attackers
    are unconcerned about detection. In Canada and the U.K., attackers
    appear to be unconcerned about detection and pursue low-hanging fruit opportunistically.

Go to Source
Author: Rob Rachwald

SamSam – The Evolution Continues Netting Over $325,000 in 4 Weeks


Talos has been working in conjunction with Cisco IR Services on what we believe to be a new variant of the SamSam ransomware. This ransomware has been observed across multiple industries including Government, Healthcare and ICS. These attacks do not appear to be highly targeted, and appear to be more opportunistic in nature.
Given SamSam’s victimology, its impacts are not just felt within the business world, they are also impacting people, especially if we consider the Healthcare sector. Non-urgent surgeries can always be rescheduled but if we take as an example patients where the medical history and former medical treatment are crucial the impact may be more severe. Furthermore, many critical life savings medical devices are now highly computerized. Ransomware can impact the operation of these devices making it very difficult for medical personnel to diagnose and treat patients leading to potentially life threatening situations. Equipment that might be needed in time-sensitive operations may be made unavailable due to the computer used to operate the equipment being unavailable.
The initial infection vector for these ongoing attacks is currently unknown and Talos is investigating this in order to identify it. The history of SamSam indicates that attackers may follow their previous modus operandi of exploiting a host and then laterally moving within their target environment to plant and later run the SamSam ransomware. Previously, we observed the adversaries attacking vulnerable JBoss hosts during a previous wave of SamSam attacks in 2016. Although the infection vector for the new variant is not yet confirmed, there is a possibility that compromised RDP/VNC servers have played a part in allowing the attackers to obtain an initial foothold.
There are no differences between the encryption mechanism used by this current SamSam variant compared to older versions. However, this time the adversaries have added some string obfuscation and improved the anti-analysis techniques used to make detection and analysis marginally more difficult.
This new variant is deployed using a loader which decrypts and executes an encrypted ransomware payload, this loader/payload model represents an improvement in the anti-forensic methods used by the malware. Samples containing this loader mechanism have been found as far back as October 2017. The wallet used by SamSam for this wave is shared by multiple infected victims as observed by monitoring the wallet at 1MddNhqRCJe825ywjdbjbAQpstWBpKHmFR. We are also able to confirm the first payment into this wallet was received on 25th December 2017 – a nice holiday gift for this adversary. This can be confirmed by observing the first wallet transaction found on the Bitcoin blockchain here. There is a possibility that other Bitcoin wallets are also used but currently Talos is currently unaware of any others.
Similar to the previous variants, we believe the deployment of this SamSam variant to be highly manual, meaning an adversary must take manual action in order to execute the malware. The symmetric encryption keys are randomly generated for each file. The Tor onion service and the Bitcoin wallet address are hardcoded into the payload whilst the public key is stored in an external file with the extension .keyxml.
Additionally, code analysis didn’t find any kind of automated mechanism for contacting the Tor Service address which means that the victim identification with the associated RSA private key must be done either manually or by another adversary tool.
Ransom note displayed by SamSam new variant

In most ransomware the attackers try to convince affected users that they have the ability to decrypt the data after the payment is made. SamSam is no different here and even displays a disclaimer as seen in the above screenshot, stating ‘we don’t want to damage our reliability’ and ‘we are honest’.

To this end SamSam adversaries offer free decryption of two files and an additional free key to decrypt one server. Once again SamSam actors show their ability to monitor and laterally move through the network by pointing out they will only provide a key if they believe the server is not an important piece of infrastructure. As with previous versions of SamSam they are advising that messaging the attackers can be performed via their site.


The adversary has changed their deployment methodology and now they use a loader mechanism called “runner” to execute the payload. Upon execution, the loader will search for files with the extension .stubbin in its execution directory, this file contains the SamSam encrypted .NET Assembly payload. Upon reading the file, the loader decrypts the payload with the password supplied as the first argument and executes it, passing the remaining arguments.
The loader is a very simple .NET assembly with no obfuscation. Comparing both the Initialization Vector (IV) and the code structure it seems like it may have been derived from an example posted on the website.
As you can seen in the images below, the IV used for the Rijndael encryption is the same in both implementations (posted code in hexadecimal, reversed code in decimal due to decompiler implementation).
Posted code Reversed code
At the code level looking specifically at the function ‘Decrypt’, it is obvious that the code structure in the Codeproject source and the latest SamSam runner sample is the same (comments from the posted code were removed).
Encryption routine source code comparison


Previous versions of SamSam put some effort into the obfuscation of the malware code by encrypting strings with AES. The new version also obfuscates functions, class names and strings, including the list of targeted file extensions, the help file contents and environment variables, this time using DES encryption with a fixed hard-coded key and the IV.
Once again, the adversary has put more effort into preventing the forensic recovery of the malware sample itself rather than only relying on the obfuscation the running malware code, which allowed us to reverse engineer this sample.
As mentioned before, the password to decrypt the payload is passed as a parameter to the loader, which reduces the chances of obtaining the payload for analysis.
Previous versions of SamSam had an equivalent method for making payload access difficult by launching a thread that would wait 1 second before deleting itself from the hard disk.
The comparison of the main encryption routines between the old and the new samples indicates that this version of SamSam is similar enough to have high confidence that it belongs to the same malware family.
Encryption Routine Comparison
While previous SamSam versions used the API call DriveInfo.GetDrives() to obtain the list of available drives, this new version has the drive letters hardcoded. After checking that a drive is ready it starts a search for targeted files on the non-blacklisted folder paths.
The new variant keeps the same list of targeted file extensions as some of the previous ones. It adds a few new entries to the list of paths not to encrypt, which includes user profiles “All Users”, “default” and the boot directory.
This is in tune with most ransomware which attempt to preserve the operability of the victim’s machine. If the machine operation is so damaged that the system cannot be booted then the victim will be unable to pay, whereas if they keep the machine able to function, with limited access to files/folders, then they have a greater chance of a victim paying for recovering their important files and documents.
Just like previous versions of SamSam the new version is especially careful to make sure that there is enough space on the current drive to create the encrypted document, thus avoiding any corruption that would lead to irrecoverable encryption.
Unlike most ransomware, SamSam does not delete Volume Shadow Copies and creates an encrypted version of the original file which is then deleted using the regular Windows API. Although unlikely, due to block overwriting, recovery of the original files from the versions of affected folders saved by the operating system may be possible.


In identifying the scope of this SamSam campaign, Talos analyzed the Bitcoin wallet addresses used by the attackers in each of these attacks. As of the time of this writing, the attackers have received approximately 30.4 BTC which equals $325,217.07. As previously mentioned, it is possible that the attackers are leveraging multiple bitcoin wallets, however Talos has not observed any other than the one listed here being used in these attacks.


As the specific initial threat vector is not known at this time, best practices should be implemented to minimize risk to organizations. Talos has outlined several best practices that should be considered in a previous blog related to defending against ransomware related threats. In accordance with best practices protocols like SMB or RDP should never be internet facing.




BTC Wallet


Tor onion service



Go to Source
Author: Talos Group

The Many Tentacles of the Necurs Botnet


Over the past five years the Necurs botnet has established itself as the largest purveyor of spam worldwide. Necurs is responsible for emailing massive amounts of banking malware, ransomware, dating spam, pump-n-dump stock scams, work from home schemes, and even cryptocurrency wallet credential phishing. Necurs sends so much spam that at times Necurs’ spam campaigns can make up more than 90% of the spam seen by Cisco Talos in one day.

To conduct a deeper analysis of Necurs, Talos extracted 32 distinct spam campaigns sent by Necurs between August 2017 and November 2017. The result was a collection of over 2.1 million spam messages, sent from almost 1.2 million distinct sending IP addresses in over 200 countries and territories.

Necurs Recipients

From an email marketing and delivery perspective, Necurs doesn’t appear to be too sophisticated. Necurs’ recipient database includes email addresses that have been harvested online, commonly deployed role-based accounts, as well as email addresses that appear to have been auto-generated. These are among the worst, most unreliable sources for obtaining email addresses, and any legitimate email marketer wouldn’t last a day mailing to addresses such as these. Of course, an illegitimate botnet such as Necurs has no such concerns. For many months the email addresses in Necurs database seemed to be largely static; Necurs hasn’t actively added any new addresses for at least the past year, possibly two years or more. In November of 2017, Necurs stopped mailing to many of the autogenerated accounts.

At one of my personal domains, Necurs has been seen mailing to addresses such as ‘equifax@’ –an email address that was originally stolen from Equifax years before the 2017 breach. Necurs also often mails to ‘thisisatestmessageatall@’, another email address I generated and put into the wild, long ago. There are also variations on other legitimate addresses, for example ‘aeson@’, ’20jaeson@’, and ‘eson@’ which are all variations on my address ‘jaeson@’. The number 20 was present at the beginning of many of Necurs recipients. Hex 20 corresponds with the space character and is used in percent-encoding, etc. This provides further indication of the harvested nature of these addresses.

Other addresses in Necurs’ mailing list appear to have been auto-generated. For example ‘EFgUYsxebG@’, ‘ZhyWaTmu@’, and ‘MTAyOvoYkx@’ have never been aliases at my domain that I’ve ever used, and the only mail these accounts ever receive comes from Necurs.

Necurs email received at an auto-generated email address

From our set of Necurs’ spam messages, Talos extracted only the user alias portion of the To: address. There are numerous email aliases, such as role-based addresses, that appear to be in Necurs’ recipient DB across many different recipient domains. Strangely, the list also included some odd email aliases deployed at multiple domains such as ‘unity_unity[0-9]@’, ‘petgord32truew@’, ‘iamjustsendingthisleter@’, ‘docs[0-9]@’, and others.

Email alias and the number of domains in our data in which that alias was found

Interestingly, some of these same strange aliases can be found on Project Honeypot’s list of the Top Dictionary Attacker Usernames, though it is unclear whether Necurs obtained their aliases from this list, or whether these aliases made Project Honeypot’s list as a result of Necurs’ spamming activity.

Project Honeypot’s Top Dictionary Attacker Usernames

Necurs Sending IPs

Next, Talos extracted the sending IP addresses responsible for transmitting Necurs’ spam emails, and we grouped the data according to geographical location. Rather than being uniformly distributed worldwide, a majority of Necurs’ nodes were concentrated among just a few countries –India (25.7% of total spam), Vietnam (20.3% of total spam), and Iran (7.3% of total spam). More than half (51.3%) of the sending IP addresses in our data came from just these three countries. In contrast, other large industrialized nations were only responsible for tiny fraction of the spam. For example, the United States, was home to 6,314 (less than 1%) of Necurs sending IPs. The country of Russia was only attributed to 38 sending IP addresses out of a nearly 1.2 million total sender IPs!

Number of spam messages sent per country

Talos also analyzed the individual spam campaigns in order to determine how often the sending IP addresses were reused from campaign to campaign. We found very little infrastructure reuse. In fact, none of the sending IP addresses in our data were seen across all thirty-two of the campaigns we extracted. Only three sending IP addresses could be found across thirty of Necurs’ spam campaigns. The vast, vast majority of sending IP addresses, 937,761 (78.6% of the total), were only ever seen in a single Necurs spam campaign! This means that Necurs botnet is large enough to conduct attacks over several months without substantial reuse of most sending nodes –an impressive feat.

Number of unique IP addresses vs. how many campaigns in which they appeared

Necurs Spam Campaigns

Typically email campaigns from Necurs fall into one of two categories: high-volume weekday campaigns, or low volume continuous campaigns. Necurs has occasionally been seen sending high volume campaigns on weekends, but the vast majority of the time high volume campaigns are limited to the business week only. The mailing list database Necurs is using seems to be segmented, such that the high volume campaigns use one subset of email addresses from the DB, and the low volume campaigns use a different set of email addresses.


Below is an example of a pump-n-dump stock spam sent on April 12th, 2017 by Necurs touting the stock symbol QSMG, Quest Management Incorporated. On the following day the price of QSMG peaked at $2.33, probably netting the criminals a tidy gain on their initial investment. QSMG is currently worth less than $0.02.

A message touting the penny stock, QSMG
QSMG was at $2.33 on April 13. Currently it is worth less than $0.02


Necurs also sends dating spam. Recent dating spam have arrived without any URLs in the body, except a mailto: link to an email address. Current dating campaigns have involved the free email provider, but other previous dating campaigns have taken advantage of similar free email services such as Necurs’ dating campaigns have also been known to include HTML links to fast-fluxed domains, or sometimes compromised websites (WordPress, etc.).

Necurs dating spam featuring an email address at

If you respond to one of these dating messages, you may be enrolled in a Russian dating website such as In this case, the criminals are making money by referring new users to these dating sites. Most likely they are being paid on an affiliate model.

Marmeladies is one of the dating sites to which victims who reply are directed


Of course one of Necurs’ most well-known payloads is ransomware. Necurs has been one of the biggest distributors of the Locky ransomware. Locky also works on an affiliate model. Inside of each locky sample, in the metadata, is an affiliate ID, which is always the same (3) for Necurs mailings. Most of the time, very little investment is made in the design of the messages themselves, as in the following example.

A typical ransomware campaign from Necurs


The rise (and fall) in the value of digital currencies such as Bitcoin and Etherium has not escaped the attention of the Necurs criminals. They have been seen conducting attack campaigns using domains designed to look similar to legitimate wallet management websites. In the email below, note the extra word ‘my’ in the domain ‘’.

This domain is registered to appear similar to the real Etherium wallet management site,

Recently, the Necurs attackers have drawn from previous stock pump-n-dump scams to come up with a relatively new tactic related to cryptocurrency. They had a spam campaign pumping Swisscoin (SIC).

A Necurs spam email encouraging recipients to buy Swisscoin (SIC)


Necurs was recently sending a low volume job spam campaign which includes links to freshly registered domains. For example, in the email below, sent October 30th 2017, we can see they are using a link to the domain, ‘’. (The affiliate id in the URL is always the same)

An example of a low volume, job-related spam campaign from Necurs



Checking the whois record for this domains we see the following registration details. Note the registrant email ‘’. This is an attempt by the threat actors to convince the casual observer that the domain is somehow registered through a third party whois privacy protection service. Email accounts are free to the public, and in this instance the attackers have simply generated the alias ‘whois-agent’ for their use in registering domains.

A review of the domains registered to ‘’ yields 399 domains (from DT as of January 17, 2018). The list of domains registered to ‘’ reads like a who’s-who of criminal activity.

Among some of the more notable domains we can see obvious phishing domains:

Typo-squattish domains targeting cryptocoin-related sites:

Fake Flash Player Update domains:

Even domains intended to masquerade as government resources:

A review of some of the domains in passive DNS gives us some other important clues. While most domains are only registered for the minimum of one year, the attackers have chosen to maintain the registration for a longer time on other domains such as ‘’. That domain is home to an online marketplace for buying and selling stolen credit card numbers, stolen ssh account credentials and more.

‘’ is a website dedicated to buying and selling stolen credit card numbers

Passive DNS also reveals instances where the attackers have hosted domains belonging to different registrants on the same IP address. For example, when Talos analyzed the passive DNS records for one of the attacker’s domains: ‘’ we found that this domain was hosted on a single IP address for a couple months in late 2016 before being parked. When we reviewed the other domains living on that same IP address we saw a bit of a pattern, and most importantly, some of these domains were NOT in the list of domains owned by ‘’.


When we check the registration information for one of the above domains ‘’, we find that there is a different registrant. This time the email address used to register the domain was ‘’. Just as with the ‘’ address, this is an attempt to appear to a casual observer that the domain is protected by whois privacy protection when in reality this email account appears to be under the direct control of the attackers themselves.

Reviewing the list of 1103 domains (Domain Tools as of January 17, 2018) associated with the ‘’ email address we see much of the same illicit activity we saw before.

More phishing domains:

More domains targeting cryptocoin-related resources:

Similar themed, fake Flash Player updates:

We even see targeting of government resources, just as we did with the other registrant account:


Checking the registration on some of the domains associated with ‘’, we can find some domains in which there are other registrants and the whois-privacy@ address is simply an Administrative and Technical Contact. This reveals an additional registrant email address employed by the attackers, ‘’.

According to Domain Tools (as of January 17, 2017), that email address is associated with over 2500 domains. Most of the domains belonging to this registrant email appeared to be domainer-style domains located at TLDs such as .bid and .top, but we also see a heavy dose of illegitimate looking domains in the set as well.

Some typical ‘Domainer’-ish domains:

Illegitimate Domains:


We can associate even more registrant email accounts with these same threat actors using similar techniques. While researching passive DNS for one of the domains we found previously, ‘’, we ran across something very interesting. That particular domain was hosted October 21, 2017 on the IP address which belongs to Alibaba as part of their cloud hosting product. When we analyze all the other domains which have been hosted on that same IP we see many domains that belong to the registrant email addresses we already knew about, ‘’ and ‘’. However we also see several domains associated with different registrants.


Looking at the list of domains found on this same Alibaba IP we find the domain ‘’. This domain is registered to the registrant email address, ‘’. This registrant has registered 125 domains (Domain Tools as of January 17, 2018), many of which have been linked to malicious activities. According to these links, domains associated with this registrant email have been used as part of the Rig Exploit Kit infrastructure. The domain, ‘’, was hosted on the Alibaba IP address on October 19, 2017 –only two days before the IP was used to host domains belonging to ‘’.


The domain ‘’ belongs to the registrant email address ‘’. The ‘’ domain was hosted on the IP on October 25th through October 30th, 2017 –also very close to the timeframe in which we saw the IP hosting the other malicious domains.

As of January 16, 2017, DomainTools attributes 918 domains to the registrant email address ‘’. Among some of the domains associated with this address we find gems such as:


The domain ‘’ is registered to ‘’. A Google search for this domain produces this linkat Hybrid Analysis and indicates that this particular domain was contacted as part of a piece of malware. At Virus Total, 50/68 antivirus engines detect this particular sample as malicious.


Searching Google for this registrant email address yields multiple links to malware that reaches out to domains owned by ‘’. Virus Total corroborates this information showing 48 and 53 antivirus detections respectively.


Reaching out through various contacts, Talos was able to confirm that, in fact, a single Alibaba cloud instance was controlling this same IP address for the entire time period from October 19, 2017 through October 30, 2017. Is this IP address some part of a criminal domain hosting service? Or is it that a single nefarious enterprise is behind all of these various registrant email accounts and their associated domains? Only the criminals involved in this enterprise can say for certain. Talos continues to monitor this situation with an eye towards further deciphering the business model deployed by these miscreants.


Now that Necurs is back from their regular holiday break they are attempting to fill our inboxes with junk mail and malware once again. On one hand, the size of the Necurs botnet, and its ability to send from different nodes in every campaign makes it difficult to defend against; Standard IP address blacklists are ineffective against such tactics. Fortunately for network defenders, the fact that Necurs does relatively little to curate their recipient database limits the damage they can do. There are only so many times the same recipients will fall for Necurs’ same, repetitive tricks. We can expect that Necurs will continue to try variations on some of their tried and true attacks, and so user education against these threats remains paramount.

Go to Source
Author: Talos Group

The Service You Can’t Refuse: A Secluded HijackRAT

In Android world, sometimes you can’t stop malware from “serving”
you, especially when the “service” is actually a malicious Android
class running in the background and controlled by a remote access tool
(RAT). Recently, FireEye mobile security researchers have discovered
such a malware that pretends to be a “Google Service Framework” and
kills an anti-virus application as well as takes other malicious actions.

In the past, we’ve seen Android malware that execute privacy leakage,
banking credential theft, or remote access separately, but this sample
takes Android malware to a new level by combining all of those
activities into one app. In addition, we found the hacker has designed
a framework to conduct bank hijacking and is actively developing
towards this goal. We suspect in the near future there will be a batch
of bank hijacking malware once the framework is completed. Right now,
eight Korean banks are recognized by the attacker, yet the hacker can
quickly expand to new banks with just 30 minutes of work.

Although the IP addresses we have captured don’t reveal who the
attacker is, as the computer of the IP might be a victim as well, we
have found from the UI that both the malware developer and the victims
are Korean speakers.

Fig. 1. The structure of the HijackRAT malware.
Fig. 1. The structure of the HijackRAT malware.

The package name of this new RAT malware is “com.ll” and appears as
“Google Service Framework” with the default Android icon. Android
users can’t remove the app unless they deactivate its administrative
privileges in “Settings.” So far, the Virus Total score of the sample
is only five positive detections out of 54 AV vendors [1]. Such new
malware is published quickly partly because the CNC server, which the
hacker uses, changes so rapidly.

Fig. 2. The Virus Total detection of the malware
sample. [1]
Fig. 3. The fake “Google Service Framework” icon
in home screen.

A few seconds after the malicious app is installed, the “Google
Services” icon appears on the home screen. When the icon is clicked,
the app asks for administrative privilege. Once activated, the
uninstallation option is disabled and a new service named “GS” is
started as shown below. The icon will show “App isn’t
installed.” when the user tries to click it again and removes
itself from the home screen.

Fig. 4. The background service of the malware.
Fig. 4. The background service of the malware.

The malware has plenty of malicious actions, which the RAT can
command, as shown below.


Within a few minutes, the app connects with the CNC server and begins
to receive a task list from it:


The content is encoded by Base64 RFC 2045. It is a JSONObject with
content: {“task”: {“0”: 0}}, when decoded. The
server IP,, is located in Hong Kong. We cannot tell if
it’s the hacker’s IP or a victim IP controlled by the RAT, but the URL
is named after the device ID and the UUID generated by the CNC server.

The code below shows how the URL of the HTTP GET request is constructed:



The task list shown above will trigger the first malicious action of
“Upload Phone Detail.” When executed, the user’s private information
will be uploaded to the server using HTTP POST request. The
information contains phone number, device ID, and contact lists as
shown below in the network packet of the request:


When decoded, the content in the red and blue part of the PCap are
shown below respectively:

1. The red part:


2. The blue part:


The contact list shown above is already highly sensitive, yet,
if the user has installed some banking applications, the malware
will scan for them too.

In a testing device, we installed the eight Korean bank apps as
shown below:

Fig. 5. The eight banking apps.
Fig. 5. The eight banking apps.

When this was done,  we found the value of
“banklist” in the PCap is no longer listed as N/A anymore:


The “banklist” entry in the PCap is filled with the short names
of the banks that we installed. There is a map of the short names
and package names of the eight banking apps installed on the phone:


The map of the banks is stored in a database and used in another
malicious action controlled by the CNC server too.


In this malicious action, the CNC server sends a command to
replace the existing bank apps. The eight banking apps require the
installation of “com.ahnlab.v3mobileplus,” which is a popular
anti-virus application available on Google Play. In order evade any
detections, the malware kills the anti-virus application before
manipulating the bank apps. In the code as shown below, Conf.LV is
the “com.ahnlab.v3mobileplus” being killed.


Then, the malware app parses the banking apps that the user has
installed on the Android device and stores them in the database
under /data/data/com.ll/database/simple_pref. The red block below
shows the bank list stored in the database:


Once the corresponding command is sent from the RAT, the
resolvePopWindow() method will be called and the device will pop a
Window with the message: “The new version has been released. Please
use after reinstallation.”


The malware will then try to download an app, named after
“update” and the bank’s short name from the CNC server,
simultaneously uninstalling the real, original bank app.


In the code shown above, “mpath” contains the CNC server IP
( and path (determined by the RAT); “mbkname” is the
bank name retrieved from the SQL lite database. The fake APK (e.g.
“updateBH.apk”) is downloaded from the CNC server, however
we don’t know what the fake apps look like because during the research
the command for this malicious action was not executed from the RAT.
Yet the source of the “update*.apk” is definitely not certified by the
banks and might be harmful to the Android user.


When the command to “update” is sent from the RAT, a similar app –
“update.apk” is downloaded from the CNC server and installed in the
Android phone:



When the command to upload SMS is received from the RAT, the SMS of
the Android phone will be uploaded to the CNC server. The SMS has been
stored in the database once received:



Then the SMS is read from the database and uploaded to the CNC server
once the command is received:



Similarly, when the sending SMS command is received, the contact list
is sent through SMS.



Interesting enough, we found a partially finished method called “Bank
Hijack.” The code below partially shows how the BankHijack method
works. The malware reads the short bank name, e.g. “NH”, and then
keeps installing the updateNH.apk from the CNC server until it’s of
the newest version.


So far the part after the installation of the fake app is not
finished yet. We believe the hacker is having some problems finishing
the function temporarily.


As shown above, the hacker has designed and prepared for the
framework of a more malicious command from the CNC server once the
hijack methods are finished. Given the unique nature of how this app
works, including its ability to pull down multiple levels of personal
information and impersonate banking apps, a more robust mobile banking
threat could be on the horizon.




Go to Source
Author: Jinjian Zhai

Darwin’s Favorite APT Group


The attackers referred to as APT12 (also known as IXESHE, DynCalc,
and DNSCALC) recently started a new campaign targeting organizations
in Japan and Taiwan. APT12 is believed to be a cyber espionage group
thought to have links to the Chinese People’s Liberation Army. APT12’s
targets are consistent with larger People’s Republic of China (PRC)
goals. Intrusions and campaigns conducted by this group are in-line
with PRC goals and self-interest in Taiwan. Additionally, the new
campaigns we uncovered further highlight the correlation between APT
groups ceasing and retooling operations after media exposure, as APT12
used the same strategy after compromising the New York Times in Oct
2012. Much like Darwin’s theory of biological evolution, APT12 been
forced to evolve and adapt in order to maintain its mission.

The new campaign marks the first APT12 activity publicly reported
since Arbor Networks released their blog “Illuminating
The Etumbot APT Backdoor.
” FireEye refers to the Etumbot
backdoor as RIPTIDE. Since the release of the Arbor blog post, FireEye
has observed APT12 use a modified RIPTIDE backdoor that we call
is the second time FireEye has discovered APT12 retooling after a
public disclosure
. As such, FireEye believes this to be a common
theme for this APT group, as APT12 will continue to evolve in an
effort to avoid detection and continue its cyber operations.

FireEye researchers also discovered two possibly related campaigns
utilizing two other backdoors known as THREEBYTE and WATERSPOUT. Both
backdoors were dropped from malicious documents built utilizing the
“Tran Duy Linh” exploit kit, which exploited CVE-2012-0158. These
documents were also emailed to organizations in Japan and Taiwan.
While APT12 has previously used THREEBYTE, it is unclear if APT12 was
responsible for the recently discovered campaign utilizing THREEBYTE.
Similarly, WATERSPOUT is a newly discovered backdoor and the threat
actors behind the campaign have not been positively identified.
However, the WATERSPOUT campaign shared several traits with the
RIPTIDE and HIGHTIDE campaign that we have attributed to APT12.


From October 2012 to May 2014, FireEye
observed APT12 utilizing RIPTIDE, a proxy-aware backdoor that
communicates via HTTP to a hard-coded command and control (C2) server.
RIPTIDE’s first communication with its C2 server fetches an encryption
key, and the RC4 encryption key is used to encrypt all further communication.


Figure 1: RIPTIDE HTTP GET Request Example

In June 2014, Arbor
Networks published an article
describing the RIPTIDE backdoor
and its C2 infrastructure in great depth. The blog highlighted that
the backdoor was utilized in campaigns from March 2011 till May 2014.

Following the release of the article, FireEye observed a distinct
change in RIPTIDE’s protocols and strings. We suspect this change was
a direct result of the Arbor blog post in order to decrease detection
of RIPTIDE by security vendors. The changes to RIPTIDE were
significant enough to circumvent existing RIPTIDE detection rules.
FireEye dubbed this new malware family HIGHTIDE.

HIGHTIDE Malware Family

On Sunday August 24, 2014 we observed a
spear phish email sent to a Taiwanese government ministry. Attached to
this email was a malicious Microsoft Word document (MD5:
f6fafb7c30b1114befc93f39d0698560) that exploited CVE-2012-0158. It
is worth noting that this email appeared to have been sent from
another Taiwanese Government employee, implying that the email was
sent from a valid but compromised account.



Figure 2:  APT12 Spearphishing Email

The exploit document dropped the HIGHTIDE backdoor with the
following properties:

MD5 6e59861931fa2796ee107dc27bfdd480
Size 75264 bytes
Complie Time 2014-08-23 08:22:49
Import Hash ead55ef2b18a80c00786c25211981570

The HIGHTIDE backdoor connected directly to If you
compare the HTTP GET request from the RIPTIDE samples (Figure 1) to
the HTTP GET request from the HIGHTIDE samples (Figure 3) you can see
the malware author changed the following items:

  • User Agent
  • Format and structure
    of the HTTP Uniform Resource Identifier (URI)


Figure 3: HIGHTIDE GET Request Example

Similar to RIPTIDE campaigns, APT12 infects target systems with
HIGHTIDE using a Microsoft Word (.doc) document that exploits
CVE-2012-0158. FireEye observed APT12 deliver these exploit documents
via phishing emails in multiple cases. Based on past APT12 activity,
we expect the threat group to continue to utilize phishing as a
malware delivery method.

MD5 File Name Exploit
73f493f6a2b0da23a79b50765c164e88 議程最新修正及注意事項.doc CVE-2012-0158
f6fafb7c30b1114befc93f39d0698560 0824.1.doc CVE-2012-0158
eaa6e03d9dae356481215e3a9d2914dc 簡易名冊0全國各警察機關主官至分局長.doc CVE-2012-0158
06da4eb2ab6412c0dc7f295920eb61c4 附檔.doc CVE-2012-0158
53baedf3765e27fb465057c48387c9b6 103年第3屆通訊錄.doc CVE-2012-0158
00a95fb30be2d6271c491545f6c6a707 2014 09 17 Welcome Reception for Bob
and Jason_invitation.doc
4ab6bf7e6796bb930be2dd0141128d06 產諮會_Y103(2)委員會_從東協新興國家崛起(0825).doc CVE-2012-0158

Figure 4: Identified exploit documents for HIGHTIDE 

When the file is opened, it drops HIGHTIDE in the form of an
executable file onto the infected system.

RIPTIDE and HIGHTIDE differ on several points: executable file
location, image base address, the User-Agent within the GET requests,
and the format of the URI. The RIPTIDE exploit document drops its
executable file into the C:Documents and Settings{user}Application
DataLocation folder while the HIGHTIDE exploit document drops its
executable file into the C:DOCUMENTS and SETTINGS{user}LOCAL
SETTINGSTemp folder. All but one sample that we identified were
written to this folder as word.exe. The one outlier was written as winword.exe.

Research into this HIGHTIDE campaign revealed APT12 targeted
multiple Taiwanese Government organizations between August 22 and 28.

THREEBYTE Malware Family

On Monday August 25, 2014 we observed a different spear phish email
sent from to a technology company located in
Taiwan. This spear phish contained a malicious Word document that
exploited CVE-2012-0158. The MD5 of the exploit document was e009b95ff7b69cbbebc538b2c5728b11.

Similar to the newly discovered HIGHTIDE samples documented above,
this malicious document dropped a backdoor to C:DOCUMENTS and
SETTINGS{user}LOCAL SETTINGSTempword.exe. This backdoor had the
following properties:

MD5 16e627dbe730488b1c3d448bfc9096e2
Size 75776 bytes
Complie Time 2014-08-25 01:22:20
Import Hash dcfaa2650d29ec1bd88e262d11d3236f

This backdoor sent the following callback
traffic to video[.]csmcpr[.]com:


Figure 5:  THREEBYTE GET Request Beacon

The THREEBYTE spear phishing incident (while not yet attributed)
shared the following characteristics with the above HIGHTIDE campaign
attributed to APT12:

  • The THREEBYTE backdoor was compiled two
    days after the HIGHTIDE backdoors.
  • Both the THREEBYTE and
    HIGHTIDE backdoors were used in attacks targeting organizations in
  • Both the THREEBYTE and HIGHTIDE backdoors were
    written to the same filepath of C:DOCUMENTS and
    SETTINGS{user}LOCAL SETTINGSTempword.exe.
  • APT12 has
    previously used the THREEBYTE backdoor.

WATERSPOUT Malware Family

On August 25, 2014, we observed another round of spear phishing
emails targeting a high-technology company in Japan. Attached to this
email was another malicious document that was designed to exploit
CVE-2012-0158. This malicious Word document had an MD5 of
499bec15ac83f2c8998f03917b63652e and dropped a backdoor to
backdoor had the following properties:

MD5 f9cfda6062a8ac9e332186a7ec0e706a
Size 49152 bytes
Complie Time 2014-08-25 02:10:11
Import Hash 864cd776c24a3c653fd89899ca32fe0b

The backdoor connects to a command and control server at icc[.]ignorelist[.]com.

Similar to RIPTIDE and HIGHTIDE, the WATERSPOUT backdoor is an
HTTP-based backdoor that communicates with its C2 server.

//<5 digit number>/<4 character string>.php?_id=<43 character string>= HTTP/1.1Accept: image/jpeg, application/x-ms-application,
image/gif, application/xaml+xml, image/pjpeg,
application/x-ms-xbap, */*

User-Agent: Mozilla/4.0
(compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0; SLCC2;
.NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729;
.NET4.0C; .NET4.0E)


Cache-Control: no-cache

Figure 6: Sample GET request for WATERSPOUT backdoor

Although there are no current infrastructure ties to link this
backdoor to APT12, there are several data points that show a possible
tie to the same actors:

  • Same initial delivery method (spear
    phishing email) with a Microsoft Word Document exploiting

      • The same “Tran Duy Linh” Microsoft
        Word Exploit Kit was used in delivery of this backdoor.

        • Similar Targets were
          observed where the threat actors utilized this

          • Japanese Tech Company
          • Taiwanese Government Organizations
          • Organizations in the Asia-Pacific Region that are of
            Interest to China
        • The
          WATERSPOUT backdoor was written to the same file path as the
          HIGHTIDE backdoors:

          • C:DOCUMENTS and
            SETTINGS{user}LOCAL SETTINGSTempword.exe
          • C:DOCUMENTS and SETTINGS{user}LOCAL
        • WATERSPOUT was compiled within two days of the last
          HIGHTIDE backdoor and on the same day as the THREEBYTE
        • APT12
          closely monitors online media related to its tools and
          operations and reacts when its tools are publicly
        • APT12 has the ability to adapt quickly to
          public exposures with new tools, tactics, and procedures
        • Public disclosures may result in an immediate
          change in APT12’s tools. These changes may be temporary and
          FireEye believes they are aimed at decreasing detection of
          their tools until a more permanent and effective TTP change
          can be implemented (e.g., WATERSPOUT).

    Although these points do not
    definitively tie WATERSPOUT to APT12, they do indicate a
    possible connection between the WATERSPOUT campaign, the
    THREEBYTE campaign, and the HIGHTIDE campaign attributed to


    FireEye believes the change from
    RIPTIDE to HIGHTIDE represents a temporary tool shift to
    decrease malware detection while APT12 developed a completely
    new malware toolset. These development efforts may have resulted
    in the emergence of the WATERSPOUT backdoor.


    Figure 7: Compile dates for all three malware

    APT12’s adaptations to public disclosures
    lead FireEye to make several conclusions about this threat

    Though public disclosures resulted in APT12
    adaptations, FireEye observed only a brief pause in APT12
    activity before the threat actors returned to normal activity
    levels. Similarly, the public disclosure of APT12’s intrusion at
    the New York Times also led to only a brief pause in the threat
    group’s activity and immediate changes in TTPs. The pause and
    retooling by APT12 was covered in the Mandiant
    2014 M-Trends report
    . Currently, APT12 continues to target
    organizations and conduct cyber operations using its new tools.
    Most recently, FireEye observed HIGHTIDE at multiple
    Taiwan-based organizations and the suspected APT12 WATERSPOUT
    backdoor at a Japan-based electronics company. We expect that
    APT12 will continue their trend and evolve and change its
    tactics to stay ahead of network defenders.

    Note: IOCs
    for this campaign can be found here.

Go to Source
Author: Ned Moran