I (Matthew Haigh) recently contributed to FLARE’s FakeNet-NG
network simulator by adding content-based protocol detection and
configuration. This feature is useful for analyzing malware that uses
a protocol over a non-standard port; for example, …
I (Matthew Haigh) recently contributed to FLARE’s FakeNet-NG
network simulator by adding content-based protocol detection and
configuration. This feature is useful for analyzing malware that uses
a protocol over a non-standard port; for example, …
The “EternalBlue” exploit (MS017-010)
was initially used by WannaCry ransomware and Adylkuzz cryptocurrency
miner. Now more threat actors are leveraging the vulnerability in Microsoft
Server Message Block (SMB) protocol – this time to distribute
Backdoor.Nitol and Trojan Gh0st RAT.
FireEye Dynamic Threat Intelligence (DTI) has historically observed
similar payloads delivered via exploitation of CVE-2014-6332
vulnerability as well as in some email spam campaigns using powershell
commands. Specifically, Backdoor.Nitol has also been linked to
campaigns involving a remote code execution vulnerability using the
ADODB.Stream ActiveX Object that affects older versions of Internet
Explorer. Both payloads have previously been involved in targeted cyber-attacks
against the aerospace and defense industry.
We observed lab machines vulnerable to SMB exploit were attacked by
a threat actor using the EternalBlue exploit to gain shell access to
Figure 1 shows an EternalBlue exploitation attempt.
Figure 1. Network traffic showing EternalBlue
The initial exploit technique used at the SMB
level is similar to what we have been seen in WannaCry
campaigns; however, once a machine is successfully infected, this
particular attack opens a shell to write instructions into a VBScript
file and then executes it to fetch the payload on another server.
We have observed the same EternalBlue and VBScript combination used
to distribute Gh0st RAT in Singapore, as well as Backdoor.Nitol being
delivered in the South Asia region.
Figure 2. VBScript instructions in ‘1.vbs’
The full VBScript instructions can be seen in Figure 2. The attacker
echoes instructions into a new ‘1.vbs’ file to be executed later.
These instructions fetch the payload ‘taskmgr.exe’ from another
server in a synchronous call (as indicated by the second parameter
‘0’). This action creates an ActiveX object ADODB.Stream, which
allows reading the file coming from the server and writes the result
of the binary data in a stream. Mode ‘3’ is used for read/write
permissions while type ‘1’ indicates stream as binary data.
Thereafter, it saves the binary stream to a location at “c:/” with
option ‘2’ in order to overwrite any binary with the same name at that location.
Later, we see that ‘1.vbs’ executes through a command-line version
of the Windows Script Host which deletes the vbs file. Once the
executable is fetched and saved, the attacker uses a shell to launch
the backdoor from the saved location.
Figure 3 shows Backdoor.Nitol being downloaded and infecting the machine.
Figure 3. Network traffic showing Backdoor.Nitol download
The command and control (C2) for the Backdoor.Nitol sample is
hackqz.f3322[.]org (188.8.131.52). See Figure 4.
Figure 4. Backdoor.Nitol C2 communication
The other malware that we’ve observed being deployed in this manner
is Gh0st RAT. The observed dropper downloads the Gh0st RAT binary from
beiyeye.401hk[.]com (Figure 5).
Figure 5. Gh0st RAT C2 communication
The first five bytes in the header of the Gh0st RAT traffic is an
indication of the Gh0st variant used. Historically we have seen
wide-spread usage of variants employing the ‘cb1st’ magic
header against the Education, Energy/Utilities, Manufacturing,
Services/Consulting, and Telecom industries. For more information on
this and other widely used variants of Gh0st RAT, please review GH0ST
in the Machine: GH0ST RAT Remains Active in Financial Services
Sector available on our subscription MySight portal.
The Gh0St RAT sample observed in this attack, as well as other
associated samples identified by FireEye are all signed with a common
digital certificate purporting to be from 北京研创达科技有限公司 (Beijing
Institute of Science and Technology Co., Ltd). Stolen or
illegitimately purchased code signing certificates are increasingly
used to lend legitimacy to malware. See the appendix for full details
on the observed code signing certificate.
The addition of the EternalBlue exploit to Metasploit has made it
easy for threat actors to exploit these vulnerabilities. In the coming
weeks and months, we expect to see more attackers leveraging these
vulnerabilities and to spread such infections with different payloads.
It is critical that Microsoft Windowsusers patch their machines and
update to the latest software versions as soon as possible.
FireEye Labs authors would like to thank Shahzad Ahmad and Kean
Siong Tan for their contributions in this discovery.
184.108.40.206:45988 / taskmgr.exe (Nitol)
beiyeye.401hk[.]com:1541 / systemUpdate.exe (Gh0st)
Dridex and Locky, two prolific malware families that made waves in
2016 after being distributed in several high-volume spam campaigns,
have returned after a brief hiatus. FireEye observed a decline in the
volume of Dridex and Locky in the latter half of 2016, but we recently
observed two new large campaigns.
While the PDF downloader described in this post is responsible for
spreading both Dridex and Locky, for the purposes of this blog, we
will be discussing the PDF downloader and the Dridex binary.
The larger of the two campaigns (Figure 1) involved a “payment
receipt” theme and, according to our telemetry, primarily affected the
insurance industry in the U.S.
Figure 1: Telemetry for the larger campaign
In the smaller of the two campaigns (Figure 2), the attachment was
claimed to be an alert from a printer for a scanned document. This
campaign primarily affected the government sector in the Middle East,
U.S., and Japan.
Figure 2: Telemetry for the smaller campaign
As seen in Figure 3, at a high-level, the execution flow consists of:
Figure 3: Full Execution Flow
We observed two patterns of subject lines used in these campaigns.
One is Payment_XXX, where XXX refers to any random number,
while the other one is Scanned image from MX-2600N. Figure 4
shows sample spam emails from both campaigns.
Figure 4: Spam Email Examples
The PDF attachment contains several objects, but the most relevant
ones are an embedded DOCM file (a macro enabled doc file) and a
shows the embedded DOCM file, and Figure 6 shows a snippet of the
Figure 5: DOCM file header in Object 3
reference to DOCM file to be dropped and executed
When the PDF document is opened, Adobe Reader displays a warning as
shown in Figure 7, clearly stating that the attached file may be harmful.
Figure 7: Security Warning by Adobe
If the user ignores the warning and clicks OK, the DOCM file is
written to %temp% and then launched.
The document file opens in read only or protected mode, which means
the macro inside the document file is not able to execute. To bypass
this mechanism, the document displays a message prompting the user
to “Enable Editing”, as seen in Figure 8.
Figure 8: Protected Document Asking for
Permission to Enable Editing
Once a victim clicks “Enable Editing”, the embedded macro executes.
In Figure 9, we can see that the command to be executed is hidden in
the caption of form1. This macro executes a PowerShell command to
communicate with the C2 server and downloads the next payload.
Figure 9: Embedded Macro
Figure 10 shows how the command is hidden a form.
Figure 10: Command Hidden a Form
The powershell is obfuscated and it can be de-obfuscated with the
algorithm in Figure 11. Once executed, the scripts main function is to
connect with the C2 server to retrieve a payload. The script contains
an array of URIs, and it tries each one until it successfully receives
a valid response from the server.
Figure 11: De-obfuscation routine for the
obfuscated Powershell script
After de-obfuscating the script, it appears to be divided into two parts:
Figure 12: C2 Communication
During a sample run, the script requests the resource “/dfv45” from
220.127.116.11 and 18.104.22.168 and successfully receives a
response from the second host.
The response is XOR encrypted. Figure 13 shows the response header.
Figure 13: C2 Response Header
The PowerShell script decodes the response and writes the decoded
executable into %temp%. A python script to decode the response is
shown in Figure 14.
Figure 14: Decryption Routine Code Snippet
Up to this point, the process for distributing Dridex and Locky
payloads has been the same. The malware that is delivered depends on
the C2 server that is contacted.
In this case, the sample fetched the Dridex payload. When executed,
Dridex unpacks and runs itself within the context of svchost.exe or
spoolsv.exe via process hallowing to evade detection.
Dridex and Locky have been highly active and prolific in the past
several months, and although the delivery mechanism often changes, the
core behavior of the family remains unchanged. Dridex is one of the
most active banking Trojans from the last few years, and Locky is one
of the most active ransomware families. If the past year is any
indication, Dridex and Locky distributors will continue to search for
ways to evade detection. FireEye is committed to remaining vigilant
against these efforts.
URLs seen distributing Dridex
URLs seen distributing Locky
Dridex C2 Servers
Due to the widespread nature of these phishing campaigns,
organizations can better protect themselves by addressing several key areas:
FireEye Multi Vector Execution (MVX) engine is able to
recognize and block this threat.
APT10 (MenuPass Group) is a Chinese cyber espionage group that
FireEye has tracked since 2009. They have historically targeted
construction and engineering, aerospace, and telecom firms, and
governments in the United States, Europe, and Japan. We believe that
the targeting of these industries has been in support of Chinese
national security goals, including acquiring valuable military and
intelligence information as well as the theft of confidential business
data to support Chinese corporations. PwC and BAE recently issued a joint
blog detailing extensive APT10 activity.
In June 2016, FireEye iSIGHT intelligence first reported that APT10
expanded their operations. The group was initially detected targeting
a Japanese university, and more widespread targeting in Japan was
subsequently uncovered. Further collaboration between FireEye as a
Service (FaaS), Mandiant and FireEye iSIGHT intelligence uncovered
additional victims worldwide, a new suite of tools and novel techniques.
Leveraging its global footprint, FireEye has detected APT10 activity
across six continents in 2016 and 2017. APT10 has targeted or
compromised manufacturing companies in India, Japan and Northern
Europe; a mining company in South America; and multiple IT service
providers worldwide. We believe these companies are a mix of final
targets and organizations that could provide a foothold in a final target.
APT10 unveiled new tools in its 2016/2017 activity. In addition to
the continued use of SOGU, the current wave of intrusions has involved
new tools we believe are unique to APT10. HAYMAKER and SNUGRIDE have
been used as first stage backdoors, while BUGJUICE and a customized
version of the open source QUASARRAT have been used as second stage
backdoors. These new pieces of malware show that APT10 is devoting
resources to capability development and innovation.
This recent APT10 activity has included both traditional spear
phishing and access to victim’s networks through service providers.
(For more information on infection via service providers see M-Trends
2016). APT10 spear phishes have been relatively unsophisticated,
leveraging .lnk files within archives, files with double extensions
(e.g. “[Redacted]_Group_Meeting_Document_20170222_doc_.exe) and in
some cases simply identically named decoy documents and malicious
launchers within the same archive.
In addition to the spear phishes, FireEye ISIGHT Intelligence has
observed APT10 accessing victims through global service providers.
Service providers have significant access to customer networks,
enabling an attacker who had compromised a service provider to move
laterally into the network of the service provider’s customer. In
addition, web traffic between a service provider’s customer and a
service provider is likely to be viewed as benign by network defenders
at the customer, allowing the attacker to exfiltrate data stealthily.
A notable instance of this observed by FireEye involved a SOGU
backdoor that was set to communicate with its C2 through a server
belonging to the victim’s service provider.
APT10 actors issued the following commands to a SOGU implant at a victim:
These commands included setting persistence on the victim’s system.
The actor then tested connectivity to an IP managed by the victim’s
service provider. Once connectivity to the service provider IP was
verified, the actor established the service provider IP as a proxy for
the victim’s SOGU backdoor. This effectively routes SOGU malware
traffic through the victim’s service provider, which likely indicates
a foothold on the service provider’s network. The tactic also serves
to mask malicious C2 and exfiltration traffic and make it appear innocuous.
APT10 is a threat to organizations worldwide. Their abuse of access
to service provider networks demonstrates that peripheral
organizations continue to be of interest to a malicious actor –
especially those seeking alternative angles of attack. We believe the
pace of APT10 operations may slow following the public disclosure by
blog; however, we believe they will return to their large-scale
operations, potentially employing new tactics, techniques and procedures.
Mandiant has observed APT29 using a stealthy backdoor that we call
POSHSPY. POSHSPY leverages two of the tools the group frequently uses:
PowerShell and Windows Management Instrumentation (WMI). In the
investigations Mandiant has conducted, it appeared that APT29 deployed
POSHSPY as a secondary backdoor for use if they lost access to their
POSHSPY makes the most of using built-in Windows features –
so-called “living off the land” – to make an especially stealthy
backdoor. POSHSPY’s use of WMI to both store and persist the backdoor
code makes it nearly invisible to anyone not familiar with the
intricacies of WMI. Its use of a PowerShell payload means that only
legitimate system processes are utilized and that the malicious code
execution can only be identified through enhanced
logging or in memory. The backdoor’s infrequent beaconing, traffic
obfuscation, extensive encryption and use of geographically local,
legitimate websites for command and control (C2) make identification
of its network traffic difficult. Every aspect of POSHSPY is efficient
Mandiant initially identified an early variant of the POSHSPY
backdoor deployed as PowerShell scripts during an incident response
engagement in 2015. Later in that same engagement, the attacker
updated the deployment of the backdoor to use WMI for storage and
persistence. Mandiant has since identified POSHSPY in several other
environments compromised by APT29 over the past two years.
We first discussed APT29’s use of this backdoor as part of our “No
Easy Breach” talk. For additional details on how we first identified
this backdoor, and the epic investigation it was part of, see the slides
WMI is an administrative framework that is built into every version
of Windows since 2000. WMI provides many administrative capabilities
on local and remote systems, including querying system information,
starting and stopping processes, and setting conditional triggers. WMI
can be accessed using a variety of tools, including the Windows WMI
Command-line (wmic.exe), or through APIs accessible to programming and
scripting languages such as PowerShell. Windows system WMI data is
stored in the WMI common information model (CIM) repository, which
consists of several files in the System32\wbem\Repository directory.
WMI classes are the primary structure within WMI. WMI classes can
contain methods (code) and properties (data). Users with sufficient
system-level privileges can define custom classes or extend the
functionality of the many default classes.
WMI permanent event subscriptions can be used to trigger actions
when specified conditions are met. Attackers often use this
functionality to persist the execution of backdoors at system start
up. Subscriptions consist of three core WMI classes: a Filter, a
Consumer, and a FilterToConsumerBinding. WMI Consumers specify an
action to be performed, including executing a command, running a
script, adding an entry to a log, or sending an email. WMI Filters
define conditions that will trigger a Consumer, including system
startup, the execution of a program, the passing of a specified time
and many others. A FilterToConsumerBinding associates Consumers to
Filters. Creating a WMI permanent event subscription requires
administrative privileges on a system.
We have observed APT29 use WMI to persist a backdoor and also store
the PowerShell backdoor code. To store the code, APT29 created a new
WMI class and added a text property to it in order to store a string
value. APT29 wrote the encrypted and base64-encoded PowerShell
backdoor code into that property.
APT29 then created a WMI event subscription in order to execute the
backdoor. The subscription was configured to run a PowerShell command
that read, decrypted, and executed the backdoor code directly from the
new WMI property. This allowed them to install a persistent backdoor
without leaving any artifacts on the system’s hard drive, outside of
the WMI repository. This “fileless” backdoor methodology made the
identification of the backdoor much more difficult using standard host
The WMI component of the POSHSPY backdoor leverages a Filter to
execute the PowerShell component of the backdoor on a regular basis.
In one instance, APT29 created a Filter named BfeOnServiceStartTypeChange (Figure 1), which they
configured to execute every Monday, Tuesday, Thursday, Friday, and
Saturday at 11:33 am local time.
Figure 1: “BfeOnServiceStartTypeChange” WMI
Query Language (WQL) filter condition
The BfeOnServiceStartTypeChange Filter was
bound to the CommandLineEventConsumer WindowsParentalControlsMigration. The WindowsParentalControlsMigration consumer was
configured to silently execute a base64-encoded PowerShell command.
Upon execution, this command extracted, decrypted, and executed the
PowerShell backdoor payload stored in the HiveUploadTask text property of the RacTask class. The PowerShell command contained
the payload storage location and encryption keys. Figure 2 displays
the command, called the “CommandLineTemplate”, executed by the WindowsParentalControlsMigration consumer.
Figure 2: WindowsParentalControlsMigration CommandLineTemplate
Figure 3 contains the decoded PowerShell command from the “CommandLineTemplate.”
Figure 3: Decoded CommandLineTemplate PowerShell code
The full code for a POSHSPY sample is available here.
The POSHSPY backdoor is designed to download and execute additional
PowerShell code and Windows binaries. The backdoor contains several
notable capabilities, including:
1. Downloading and executing PowerShell code as an EncodedCommand
2. Writing executables to a randomly-selected directory under Program Files, and naming the EXE to match the
chosen directory name, or, if that fails, writing the executable to a
system-generated temporary file name, using the EXE extension
3. Modifying the Standard Information timestamps (created, modified,
accessed) of every downloaded executable to match a randomly selected
file from the System32 directory that was created prior to 2013
4. Encrypting communications using AES and RSA public key cryptography
5. Deriving C2 URLs from a Domain Generation Algorithm (DGA) using
lists of domain names, subdomains, top-level domains (TLDs), Uniform
Resource Identifiers (URIs), file names, and file extensions
6. Using a custom User Agent string or the system’s User Agent
string derived from urlmon.dll
7. Using either custom cookie names and values or randomly-generated
cookie names and values for each network connection
8. Uploading data in 2048-byte chunks
9. Appending a file signature header to all encrypted data, prior to
upload or download, by randomly selecting from the file types:
in this example used 11 legitimate domains owned by an organization
located near the victim. When combined with the other options in the
DGA, 550 unique C2 URLs could be generated. Infrequent beaconing, use
of DGA and compromised infrastructure for C2, and appended file
headers used to bypass content inspection made this backdoor difficult
to identify using typical network monitoring techniques.
POSHSPY is an excellent example of the skill and craftiness of
APT29. By “living off the land” they were able to make an extremely
discrete backdoor that they can deploy alongside their more
conventional and noisier backdoor families, in order to help ensure
persistence even after remediation. As stealthy as POSHSPY can be, it
comes to light quickly if you know where to look. Enabling and
PowerShell logging can capture malicious code as it executes and
legitimate WMI persistence is so rare that malicious persistence
quickly stands out when enumerating it across an environment. This is
one of several sneaky backdoor families that we have identified,
including an off-the-shelf domain
fronting backdoor and HAMMERTOSS.
When responding to an APT29 breach, it is vital to increase
visibility, fully scope the incident before responding and thoroughly
analyze accessed systems that don’t contain known malware.
logging blog post contains more information on improving
PowerShell visibility in your environment.
whitepaper by William Ballenthin, Matt Graeber and Claudiu
Teodorescu contains additional information on WMI offense, defense and forensics.
by Christopher Glyer and Devon Kerr contains additional information on
attacker use of WMI in past Mandiant investigations.
The FireEye FLARE team released a WMI
repository-parsing tool that allows investigators to extract
embedded data from the WMI repository and identify WMI persistence.
Malvertising occurs when an online advertising network knowingly or
unknowingly serves up malicious advertisements on a website. Malvertisements
are a type of “drive-by” threat that tend to result in users being
infected with malware for simply visiting a website. The victims of
this threat are often compromised when the malvertisement directs them
to an exploit kit (EK) landing page. Depending on the applications
running on the user’s system, the EK can successfully load malware
into a system without user consent and without tipping the victim off
that something suspicious is happening.
It is not uncommon for popular ad servers to redirect to affiliate
networks – organizations that forward traffic to servers supporting
other malicious domains, which are referred to as “Cushion Servers” or
“Shadow Servers”. Under control of EK actors, some cushion servers use
HTTP redirect protocols such as 301/302/303 etc., or simply iframe
redirects. In other cases the visitor receives pages containing a
script that the attacker has injected. This is often the consequence
of an unmitigated vulnerability that attackers may exploit to their
advantage. Some campaigns use the domain
shadowing technique to camouflage rogue ad servers as legitimate advertisers.
In this blog, we will look into some of the prominent malvertising
campaigns that were active during the last four months, as well as the
cushion servers related to different exploit kits.
As seen in Figure 1, Magnitude EK is a popular exploit kit in the
APAC region. Throughout the final quarter of 2016 and first month of
2017, FireEye Dynamic Threat Intelligence (DTI) observed consistent
Magnitude EK hits from several customers, the majority of whom reside
in the APAC region.
Figure 1: Zone distribution for Magnitude EK
activity as seen on DTI in last 4 months
In all cases, Magnitude EK affected web servers with the following
“Apache/2.2.15 (CentOS) DAV/2 mod_fastcgi/2.4.6”.
A successful Magnitude EK infection follows the stages seen in
Figure 2: Typical path for malvertising to
Figure 3: TLD distribution of first layer
domains with injected redirect script
Throughout the last four months, different malvertising campaigns
have been associated with a group of first layer compromise pages (the
TLD distribution is seen in Figure 3), which we will discuss based on
common indicators. These first layer compromise pages use the same
injected script used for redirection to Magnitude EK. Figure 4 shows a
typical injected script used in these campaigns.
Figure 4: Typical malicious injected script used
for redirection to Magnitude domains
In all observed instances, the injected script only appears when the
site is being loaded through the advertisement (many of which have
high Alexa ranking, as we will further explain), and not when those
URLs are accessed directly.
FireEye notifications have resulted in many of these campaigns being
taken down, which are mentioned in their respective sections.
Table 1 shows the domains we observed that acted as first layer
compromise domains with the injected script for redirection to
Magnitude EK being spread from the advertisers, with domains hosted on
the Webzilla B.V domain hosting service.
Table 1: Domains with injected redirect script
involved in this campaign
These domains appear to be from the same actor due to the similar
nature of the URI and domain patterns, and the switching to new
domains after one is used a certain number of times. The current IP
involved in hosting the active domains is 22.214.171.124. Domains seen
in Table 1 were redirected by the following advertisers mentioned in
Table 2: Ads used in this campaign
A typical URI seen in this campaign appears as:
On rare occasions the same campaign also used advertiser poptm[.]com
hosted on Cloudflare, but for the most part the ad networks listed in
Table 2 were used.
Some malvertisements have been leading users to Flash game websites.
In these instances, domains containing the word ‘finance’ in their
domain name are being used as the first layer of compromise for the
injected script, which redirects to domains hosting Magnitude EK.
These Flash sites are registered with ‘AlpNames Limited’ registrar and
have been hosted using a PlusServer AG server ISP in Germany.
Registrant information for all of these sites is similar. The
registrant name is some variation of the name ‘Bill’ and ‘Guil’ (e.g
‘Billii’, ‘Billy’ etc.). Registrant numbers have consistently been
+1.2285161853 or +1.7137015286.
Table 3 shows the names of these Flash game websites and Table 4
shows their malvertising information.
Table 3: Domains with injected redirect script
involved in this campaign
Table 4: Ads used in this campaign
The ads from click.seodollars[.]com appear to be using the domain
shadowing technique, while all others are legitimate advertisers.
AlpNames Limited registrar has taken down domains associated with
this campaign following notification by FireEye.
This category of first layer of compromise is for domains registered
under [.]organisation: TTA ADULTS LIMITED. In all instances, the
registrant information is as follows:
Registrant Name: Andrew Musgrove
TTA ADULTS LIMITED
Registrant Street: FOURTH AVENUE UNIT 1B
Registrant City: LETCHWORTH
Registrant Postal Code: SG6
Registrant Country: GB
Registrant Phone Ext:
Registrant Fax Ext:
Registrant Email: musgroveandrew1@gmail[.]com
Domains with this registry information are being redirected by
advertisers belonging to Adcash group.
Table 5 shows the names of these campaign domains and Table 6 shows
their malvertising information.
Table 5: Domains with injected redirect script
involved in this campaign
Table 6: Ads used in this campaign
Adcash has closed domain accounts associated with this group
following notification from FireEye.
This category of first layer of compromise is for domains registered
under [.]organisation: China Coast. In all cases, the registrant
information is as follows:
Registrant Name: Goran L Deelen
Registrant Street: Davisstraat 27
Registrant State/Province: Noord-Holland
Registrant Postal Code: 1057 TG
Registrant Country: NL
Registrant Phone: +31.645495613
Registrant Phone Ext:
Registrant Fax: Registrant Fax Ext:
The malvertisements can be further categorized by different domain
types. Some of the domain names with traffic from Taiwan are
redirected by ads.adamoads[.]com (a Chinese advertising site).
Additional details are shown in Table 7.
Table 7: Domains and ad services involved in
Some of the malvertisements in this campaign are redirected through
other ad sites, including:
The following rogue ad subdomains in this campaign use the domain
Table 8 shows other malvertisement cases for Magnitude EK.
Table 8: Other domains and ad services involved
in redirection to Magnitude EK
Rig EK emerged as the most prolific exploit kit in the latter half
of 2016. Its use in campaigns such as EITest
Gate is well documented, all of which involve scripts being
injected directly within legitimate sites. However, going with the
theme of this blog, we will be focusing on noteworthy malvertising
campaigns involving redirects to Rig EK domains.
From the final quarter of 2016 to the start of 2017, we have
observed [.]info and [.]pw TLD domains acting as intermediate redirect
domains invoked via legitimate advertisers, which eventually lead to
Rig EK domains. These domains usually have malicious iframes injected
into the content for redirection to Rig EK domains. Figure 5 shows the
normal workflow of the campaign.
Figure 5: Ad networks hosted on Google Cloud ISP
Figure 6 show how the ad loads casino-themed domains via 302
redirect. The ad service loads these sites, which are acting as shadow
servers to redirect users further to exploit kits, as seen in Figure 7
and Figure 8.
Figure 6: 302 redirect to holdem-pokers.info
Figure 7: Malicious iframe from 1st redirect
domain to .pw domain hosted on domain of 2nd IP
Figure 8: Malicious iframe from 2nd layer
redirect domain loading Rig EK
The most recent whois information for domains related to this
campaign is as follows:
Registrant Name: sergei sergeev
Registrant Street: novoselov 44
Registrant Postal Code: 140530
Registrant Phone: +7.9868847677
Admin Name: sergei sergeev
Admin [.]organization: Private
Admin Street: novoselov 44
Admin City: moscow
Admin State/Province: moscow
Admin Postal Code: 140530
Admin Country: RU
Admin Phone: +7.9868847677
The whois information slightly varies in older domains registered
for the same campaign, but the organization name, state and country
remain the same.
Domains are currently active on IP 126.96.36.199 (first redirect
after legitimate ad) and 188.8.131.52 (second redirect after
legitimate ad). Table 9 shows a complete list of the involved domains.
Table 9: Casino themed domains involved as
shadow servers in this campaign
Table 10: Ads used in this campaign
All ad service belong to AdCash ad group, which stopped providing
services to these domains in February 2017.
Later, the same campaign switched to the following new domains:
lifeerotic6[.]info; lifeerotic6[.]pw; spoutgame22[.]info;
spoutgame22[.]pw; lifeerotic[.]info; 100p2[.]pw; 100p0[.]pw;
The IP involved with these new domains (other than two mentioned
earlier) is 184.108.40.206. The new whois information is as follows:
Registrant Name: sergei sergeev
Registrant Street: 64 Vicar Lane
Registrant State/Province: COMMON
Postal Code: WR6 1JY
Registrant Country: GB
This actor’s new set of domains is now leveraging popular ad service
popcash[.]net, which FireEye has notified.
The following are some of the most prominent malvertising campaigns
that are currently active for Sundown EK.
This campaign has been active using domains hosted on 220.127.116.11
and 18.104.22.168. Domains hosted on both neighboring addresses have
their whois information protected by Whois Guard. There are
similarities in domain names and each group of domains under these IP
addresses (with a Netherlands geolocation).
In these instances, legitimate advertisers are redirected to one of
the domains hosted on these IPs, which further redirects to a Sundown
EK domain. Figure 9 and Figure 10 show how an ad redirects to
intermediary domains hosting a malicious iframe to a Sundown EK
Figure 9: poptm[.]com redirecting to
gomedia[.]online hosted on IP 22.214.171.124
Figure 10: Redirect domain leading an iframe to
There are multiple ad services that are currently redirecting to
these domains, as seen in Table 11.
Table 11: Intermediary domains redirecting to
Sundown EK and their advertisers seen in this domain
Figure 11 and Figure 12 show details of domains hosted on each
neighboring IP involved in this campaign.
Figure 11: Domains with iframe load to Sundown
EK hosted on IP 126.96.36.199
Figure 12: Domains with iframe load to Sundown
EK hosted on IP 188.8.131.52
A group of redirect domains has been leveraging advertiser
popcash[.]net (Alexa #165) for 302/303 redirects to Sundown EK landing
pages. In these instances, the advertiser does not directly lead to a
Sundown EK domain, but leads them via a chain of two domains involved
in the campaign.
Table 12 shows domains involved in the campaign where popcash[.]net
usually leads to a domain via 303 redirect, which further leads to
second domain (typically via an iframe or another 303 redirect) and
eventually redirects users to a Sundown EK domain.
Table 12: List of shadow server domains involved
in this campaign
These domains use two IPs, either: 184.108.40.206 or 220.127.116.11.
A typical example of such redirection can be seen in Figure 13 and
Figure 13: Chain of two domains being redirected
Figure 14: Second layer of Shadow server domain
redirects to Sundown EK landing page
popcash[.]net cleaned the malicious ads after notification.
This campaign is related to group of domains with the following
Registrant Name: elise wickson
Registrant Street: 4-4025 Sladeview Crescent
Registrant City: mississauga
Registrant State/Province: QC
Registrant Postal Code: L6L 5Y1
Registrant Country: CA
Registrant Phone: +1.5148852225
Registrant Name: bruno
Registrant [.]organization: None
Street: 8807 PIERRE-BOUCHER
Registrant City: laval
Registrant State/Province: QC
Registrant Postal Code:
Registrant Country: CA
Registrant Phone: +1.5148859965
These domains are being used as shadow servers to Sundown EK domains
after being loaded via legitimate ad sites hosted on Webzilla B.V
hosting services. Table 13 shows a complete list of these domains.
Table 13: Domains involved in this campaign
Table 14: Ads involved in redirection for this campaign
Other malvertisement cases for Sundown EK are shown in Table 15.
Table 15: Other domains and ad services involved
in redirection to Sundown EK
Terror EK is similar to Sundown EK. It has been consistently
leveraging advertiser serve.popads[.]net to redirect traffic to
domains controlled by it. The advertiser is used to redirect traffic
to a domain hosted on IP 18.104.22.168, which is further redirected
to domains hosted on 22.214.171.124 / 126.96.36.199 / 188.8.131.52.
against domains hosted on 184.108.40.206 were seen last year in
December by our colleagues at Trustwave and Malwarebytes.
In January 2017, new domain names appeared in the campaign hosted on
a different IP location. However, as observed in the previous case,
Terror EK continued the campaign to download ccminer payloads.
Figure 15 and Figure 16 show ad services redirecting to domain
onlinesalespromarketing[.]com (hosted on 220.127.116.11), which
further redirects to a landing page domain onlinesalesproaffiliate4[.]us.
Figure 15. serve.popads[.]net redirect to shadow server
Figure 16. Shadow server redirect to Terror EK
Table 16 shows a list of new domains that use the above mentioned
IP’s for hosting landing page:
Table 16: New domains used by Terror EK after
Malvertising and exploit kits continue to be a significant threat to
regular users. While we strongly recommend using ad blockers for all
web browsers, we understand that it’s not always possible. For that
reason, the best approach is to always keep your web browsers and
applications fully updated. Also, regularly check your browser to see
what plugins are being used and disable them if they are not necessary.
In all of the examples we discussed, FireEye customers were
protected from infection by our multi-flow and multi-vector detection engine.
Update (March 17, 2017): We would like to thank PopCash, Adcash,
Propeller Ads, AlpNames Limited and Cloudflare for closing down rogue
accounts linked to shadow servers that were discussed in this blog.
On red team engagements, Mandiant consultants are often tasked with
identifying and obtaining access to critical Unix systems within our
client’s environments. The objectives may include obtaining payment
card data on point of sale terminals or accessing intellectual
property residing on Apple MacBooks.
Since Unix systems are typically not domain-joined, locating and
authenticating to them can be a challenge. In fact, current
methodologies often rely on luck. Typically, this can include:
In this blog, I address a new approach to finding Unix systems using
a small and purely PowerShell tool we created called SessionGopher.
Our thought process was simple: While most Unix systems are
off-domain, they are often accessed and managed by domain-joined
Windows systems. These Windows systems typically have remote access
tools installed on them that would suggest they communicate with Unix
systems, and these tools leave behind valuable artifacts that can help
consultants both discover and exploit the Unix systems. SessionGopher
is designed to identify these remote access tools and extract any
auxiliary information about the hosts to which they connect.
The HKEY_USERS hive is a Windows hive that contains persistent
information about users who have interactively logged on to the
system. For each user that authenticates to the system, Windows
creates a user subkey at location HKEY_USERS\<SID>, where
<SID> is that user’s security identifier. A privileged account,
such as a local or domain administrator, can access the contents of
every user subkey on the system under HKEY_USERS. A non-privileged
account on the same system can only access the user subkey associated
with his or her account.
Amazingly, within these user subkeys reside saved session
information for some of the remote access tools discussed earlier. If
a user creates a session in WinSCP, a file transfer client often used
to communicate with Unix systems, and then saves that session, the
entire saved session gets stored in the Registry under that user’s
HKEY_USERS\<User’s SID>\Software\Martin Prikryl\WinSCP
Using regedit, a graphical interface for the Windows Registry, we
can examine the contents of one of these sessions.
1: A WinSCP saved session in the HKEY_USERS hive
By default, the WinSCP password from Figure 1 is obfuscated by
several bitwise operations, not encrypted, unless the user explicitly
creates a master password to protect these registry values.
Similarly, PuTTY, an SSH client for Windows, stores its session
information as a separate subkey:
While PuTTY does not store passwords, it can store the hostnames to
which the client connects, as seen in Figure 2.
Figure 2: A PuTTY saved session in the
A plethora of remote access tools like these exist which store their
saved session information in the user’s HKEY_USERS subkey. Enumerating
the domain for systems with these artifacts provides an educated guess
as to where Unix systems may be hiding, potentially some credentials,
and the hosts that serve as jump boxes to those Unix systems.
In developing a post-exploitation tool, using WMI’s remote registry
querying functionality to extract these Registry-based saved session
artifacts made sense. Our tool SessionGopher
leverages WMI to query each SID found in the system’s HKEY_USERS hive
for the artifacts discussed earlier.
When a master password is not used, SessionGopher automatically
deobfuscates WinSCP saved session passwords, as shown in Figure 3.
Figure 3: SessionGopher’s built-in WinSCP
On top of WinSCP and PuTTY, SessionGopher extracts saved RDP session
data from each user’s HKEY_USERS subkey. This expands SessionGopher’s
functionality from strictly finding Unix systems to also identifying
systems that may serve as jump boxes to different subnets. Figure 4
demonstrates SessionGopher returning saved RDP sessions on remote host
“WIN7-CLIENT01” when run against a set of domain computers.
Figure 4: SessionGopher discovering saved RDP
sessions when run across a domain
Certain remote access tools such as SuperPuTTY and FileZilla store
saved sessions as files rather than in the Registry, so SessionGopher
also searches remote filesystems for those default file locations and
extracts saved passwords when stored. In -Thorough mode,
SessionGopher searches the entire remote filesystem for PuTTY private
key (.ppk), Remote Desktop Connection (.rdp), and RSA Soft Token
Currently, SessionGopher looks for artifacts from the following
Running SessionGopher across targeted systems on a domain with the
–o flag can nicely synthesize all session data into .csv files,
allowing the user to keep track of the source computer and user
account that led to the session’s discovery. Figure 5 shows
SessionGopher’s output folder when run with –o.
Figure 5: Folder of .csvs created by
SessionGopher’s –o flag
The fallacy in searching for Unix systems is that if they are not
domain-joined, interrogating domain systems for clues provides little
insight. As with any internal resource, Unix systems often require
management and communication with the corporate domain. The Registry
found on each of these domain-joined systems can serve as a trail of
breadcrumbs to the exact location of these Unix systems, and to any
segmented host of interest.
While not as common as Windows malware, there has been a steady
stream of malware discovered over the years that runs on the OS X
operating system, now rebranded as macOS. February saw three
particularly interesting publications on the topic of macOS malware: a
Cocoa application that sends system information including
keychain data back to the attacker, a macOS
version of APT28’s Xagent malware, and a new
In this blog, the FLARE team would like to introduce two small tools
that can aid in the task of reverse engineering Cocoa applications for
macOS. In order to properly introduce these tools, we will lay a bit
of foundation first to introduce the reader to some Apple-specific
topics. Specifically, we will explain how the Objective-C runtime
complicates code analysis in tools such as IDA Pro, and how to find
useful entry points into a Cocoa application’s code where you can
If you find these topics fascinating or if you want to be better
prepared to investigate macOS malware in your own environment, come
join us for a two-day crash course on this topic that we will be
teaching at Black
Hat Asia and Black
Hat USA this year.
When we use the term “Cocoa application”, we are referring to an
application that is built using the AppKit framework, which belongs to
what Apple refers to as the Cocoa Application Layer. In macOS,
applications are distributed in an application bundle, a directory
structure made to appear as a single file containing executable code
and its associated resources, as illustrated in Figure 1.
Figure 1: Directory structure of iTerm
These bundles can contain a variety of different files, but all
bundles must contain at least two critical files: Info.plist and an
executable file residing in the MacOS folder. The executable file can
be any file with execute permissions, even a python or shell script,
but it is typically a native executable. Mach-O is the native
executable file format for macOS and iOS. The Info.plist file
describes the application bundle, containing critical information the
OS needs in order to properly load it. Plist files can be in one of
three possible formats: XML, JSON, or a proprietary binary format
called bplist. A handy utility named plutil is available in macOS that
allows you to convert between formats, or simply pretty-print a plist
file regardless of its format. The most notable key in the Info.plist
file is the CFBundleExecutable key, which designates the name of the
executable in the MacOS folder that will be executed. Figure 2 shows a
snippet of the pretty-printed output from plutil for the iTerm
application’s Info.plist file.
Figure 2: snippet from iTerm application’s
Cocoa applications are typically written in Objective-C or Swift.
Swift, the newer of the two languages, has been quickly catching up to
Objective-C in popularity and appears to have overtaken
it. Despite this, Objective-C has many years over Swift, which
means the majority of malicious Cocoa applications you will run into
will be written in Objective-C for the time being. Additionally, older
Objective-C APIs tend to be encountered during malware analysis. This
can be due to the age of the malware or for the purpose of backwards
compatibility. Objective-C is a dynamic and reflective programming
language and runtime. Roughly 10 years ago, Objective-C version 2.0
was released, which included major changes to both the language and
the runtime. Where details are concerned, this blog is referring to
Programs written in Objective-C are transformed into C as part of
the compilation process, making it at least a somewhat comfortable
transition for most reverse engineers. One of the biggest hurdles to
such a transition comes in how methods are called in Objective-C.
Objective-C methods are conceptually similar to C functions; they are
a unit of code that performs a specific task, optionally taking in
parameters and returning a value. However, due to the dynamic nature
of Objective-C, methods are not normally called directly. Instead, a
message is sent to the target object. The name of a method is called a
selector, while the actual function that is executed is called
an implementation. The message specifies a reference to the
selector that is to be invoked along with any method parameters. This
allows for features like “method swizzling,” in which an application
can change the implementation for a given selector. The most common
way in which messages are sent within Objective-C applications is the
objc_msgSend function. Figure 3 provides a small snippet of
Objective-C code that opens a URL in your browser. Figure 4 shows this
same code represented in C.
Figure 3: Objective-C code snippet
Figure 4: Objective-C code represented in C
As you can see, the Objective-C code between the brackets amounts to
a call to objc_msgSend.
Unfortunately, this message sending mechanism causes problems when
trying to follow cross-references for selectors in IDA Pro. While you
can easily see all the cross-references for a given selector from any
location where it is referenced, the implementations themselves are
not called or referenced directly and so there is no easy way to jump
from a selector reference to its implementation or vice-versa. Figure
5 illustrates this problem by showing that the only cross-reference to
an implementation is in the __objc_const section of the executable,
where the runtime stores class member data.
Figure 5: Cross-reference to an implementation
Of course, the information that links these selector references to
their implementations is stored in the executable, and thankfully IDA
Pro can to parse this data for us. In the __objc_const section, a
structure identified by IDA Pro as __objc2_meth has the definition
illustrated in Figure 6.
Figure 6: __objc2_meth structure
The first field of this structure is the selector for the method.
One of the cross-references to this field brings us to the
__objc_selrefs section of the executable where you can find the
selector reference. Following the cross-references of the
selector reference will reveal to us any locations in the code where
the selector is used. The third field of the structure points to the
implementation of the selector, which is the function we want to
analyze. What is left to do is simply use this data to create the
cross-references. The first of the two tools we are introducing is an
IDAPython script named objc2_xrefs_helper.py that does just that for
x86_64 Mach-O executable files using Objective-C 2.0. This script is
similar to older IDAPython
scripts released by Zynamics, however their scripts do not
support the x86_64 architecture. Our script is available along with
all of our other scripts and plugins for IDA Pro from our Github repo
here. For each
Objective-C method that is defined in the executable,
objc2_xrefs_helper.py patches the instructions that cross-reference
its selector to reference the implementing function itself and creates
a cross-reference from the referencing instruction to the
implementation function. Using this script allows us to easily
transition from a selector’s implementation to its references and
vice-versa, as shown in Figure 7 and Figure 8.
Figure 7: Cross-references added for implementation
Figure 8: View selector’s implementation from
There is a noteworthy shortcoming to this tool, however. If more
than one class defines a method with the same name, there will only be
one selector present in the executable. For now, the tool ignores
these ambiguous selectors.
Another quandary with reverse engineering Cocoa applications, or any
application built with an application framework, is determining where
the framework’s code ends and the author’s code begins. With programs
written in C/C++, the author’s code would typically begin within the
main function of the program. While there are many exceptions to this
rule, this is generally the case. For programs using the Cocoa
Application template in Apple’s IDE, Xcode, the main function simply
performs a tail jump into a function exported by the AppKit framework
named NSApplicationMain, as shown in Figure 9.
Figure 9: A Cocoa application’s main function
So where do we look to find the first lines of code written by the
application’s author that would be executed? The answer to that
question lies within NSApplicationMain. In summary, NSApplicationMain
performs three important steps: constructing the NSApplication object,
loading the main storyboard or nib file, and starting the event loop.
The NSApplication object plays the important role of event and
notification coordinator for the running application.
NSApplicationMain looks for the name of this class in the
NSPrincipalClass key in the Info.plist file of the application bundle.
Xcode simply sets this key to the NSApplication class, but this class
may be subclassed or reimplemented and the key overwritten. A
noteworthy notification that is coordinated by the NSApplication
object is NSApplicationDidFinishLaunchingNotification, which is
designated as the proper time to run any application-specific
initialization code the author may have. To handle this notification,
the application may designate a delegate class that adheres to the
NSApplicationDelegate protocol. In Objective-C, a protocol
fills the role traditionally referred to as an interface in
object-oriented parlance. The relevant method in this protocol for
encapsulating initialization code is the
applicationDidFinishLaunching method. By default, Xcode creates
this delegate class for you and names it AppDelegate. It even defines
an empty applicationDidFinishLaunching method for the application
developer to modify as desired. With all this information in hand, the
best place to look for the initial code of most Cocoa applications is
in a method named applicationDidFinishLaunching, as shown in Figure 10.
Figure 10: Search for
If you find nothing useful, then fall back to analyzing the main
function. It is important to note that all this information is
specific to apps created using the Cocoa Application template in
Xcode. Cocoa applications do not need to use NSApplicationMain. One
can write their own Cocoa application from scratch, implementing his
or her own version of NSApplicationMain.
It was previously mentioned that one of the main responsibilities of
NSApplicationMain is to load the main storyboard or nib file. “Nib”
stands for NeXTSTEP Interface Builder, referring to the Interface
Builder application that is a part of Xcode. Interface Builder allows
developers to easily build graphical user interfaces and even wire
their controls to variables and methods within their code using a
graphical interface. As a developer builds GUIs with Interface
Builder, graphs of objects are formed. An object graph is saved in XML
format in a .xib file in the project folder. When the project is
built, each object graph is serialized using the NSKeyedArchiver class
and stored in Apple’s bplist format in a .nib file within the
application bundle, typically under the Resources folder. Xcode writes
the name of the main nib file to the application’s Info.plist file
under the key NSMainNibFile. When an application loads a nib file,
this object hierarchy is unpacked into memory and all the connections
between various GUI windows, menus, controls, variables, and methods
are established. This list of connections includes the connection
between the application delegate and the NSApplication class.
Storyboards were added to macOS in Yosemite. They enable the developer
to lay out all of the application’s various views that will be shown
to the user and specify their relationships. Under the hood, a
storyboard is a directory containing nib files and an accompanying
Info.plist file. The main storyboard directory is designated under the
key NSMainStoryboardFile in the application’s Info.plist file.
This brings us to the other tool we would like to share,
nib_parse.py, which is available from our Github repo here. nib_parse.py
uses ccl_bplist to
decode and deserialize a nib file and print out the list of
connections defined within it. For each connection, it prints the
label for the connection (typically a method or variable name) and the
source and destination objects’ classes. Each object encoded by
NSKeyedArchiver is assigned a unique numeric identifier value that is
included in the output within enclosed parentheses. For appropriate
GUI elements that have textual data associated with them, such as
button labels, the text is included in the script output within
enclosed brackets. With this information, one can determine the
relationships between the code and the GUI elements. It is even
possible to rewire the application, changing which functions handle
different GUI events. Note that if a nib is not flattened, it will be
represented as a directory that contains nib files and you can run
this tool on the keyedobjects.nib file located within it instead. For
storyboards, you can run this tool on the various nib files present in
the storyboard directory. Figure 11 shows the output of nib_parse.py
when it is used on the MainMenu.nib file from the recently discovered
threat shown in Figure 12. You may notice that the GUI text in the
tool output does not match the GUI text in the screenshot. In this
case, many of the GUI elements are altered at run-time in the code
illustrated in Figure 13.
Figure 11: nib_parse.py output for MacDownloader threat
Figure 12: MacDownloader’s initial window
Figure 13: Code updating the text of buttons
The output from nib_parse.py shows that the author used the default
delegate class AppDelegate provided by Xcode. The AppDelegate class
has two instance variables for NSButton objects along with four
instance variables for NSTextField objects. A selector named
btnSearchAdware is connected to the same button with id (49) as the
instance variable btnAction. This is likely an interesting function to
We hope you have enjoyed this whirlwind tour of reverse engineering
Cocoa applications. If you are interested in getting some more
exposure to macOS internals and analysis tools, reverse engineering
and debugging techniques, and real macOS malware found in the wild,
then come hang out with us at Black Hat this year and learn more!
In late February 2017, FireEye as a Service (FaaS) identified a spear
phishing campaign that appeared to be targeting personnel involved
with United States Securities and Exchange Commission (SEC) filings at
various organizations. Based on multiple identified overlaps in
infrastructure and the use of similar tools, tactics, and procedures
(TTPs), we have high confidence that this campaign is associated with
the financially motivated threat group tracked by FireEye as FIN7.
FIN7 is a financially motivated intrusion set that selectively
targets victims and uses spear phishing to distribute its malware. We
have observed FIN7 attempt to compromise diverse organizations for
malicious operations – usually involving the deployment of
point-of-sale malware – primarily against the retail and hospitality industries.
All of the observed intended recipients of the spear phishing
campaign appeared to be involved with SEC filings for their respective
organizations. Many of the recipients were even listed in their
company’s SEC filings. The sender email address was spoofed as EDGAR
<email@example.com> and the attachment was named
d04b6410dddee19adec75f597c52e386). An example email is shown in
Figure 1: Example of a phishing email sent
during this campaign
We have observed the following TTPs with this campaign:
Thus far, we have directly identified 11 targeted organizations in
the following sectors:
All these organizations are based in the United States, and many
have international presences. As the SEC is a U.S. regulatory
organization, we would expect recipients of these spear phishing
attempts to either work for U.S.-based organizations or be U.S.-based
representatives of organizations located elsewhere. However, it is
possible that the attackers could perform similar activity mimicking
other regulatory organizations in other countries.
We have not yet identified FIN7’s ultimate goal in this campaign, as
we have either blocked the delivery of the malicious emails or our
FaaS team detected and contained the attack early enough in the
lifecycle before we observed any data targeting or theft. However, we
surmise FIN7 can profit from compromised organizations in several
ways. If the attackers are attempting to compromise persons involved
in SEC filings due to their information access, they may ultimately be
pursuing securities fraud or other investment abuse. Alternatively, if
they are tailoring their social engineering to these individuals, but
have other goals once they have established a foothold, they may
intend to pursue one of many other fraud types.
Previous FIN7 operations deployed multiple point-of-sale malware
families for the purpose of collecting and exfiltrating sensitive
financial data. The use of the CARBANAK malware in FIN7 operations
also provides limited evidence that these campaigns are linked to
previously observed CARBANAK operations leading to fraudulent banking
transactions, ATM compromise, and other monetization schemes.
FireEye implemented a Community Protection Event – FaaS, Mandiant,
Intelligence, and Products – to secure all clients affected by this
campaign. In this instance, an incident detected by FaaS led to the
deployment of additional detections by the FireEye Labs team after
FireEye Labs Advanced Reverse Engineering quickly analyzed the
malware. Detections were then quickly deployed to the suite of FireEye products.
The FireEye iSIGHT Intelligence MySIGHT Portal contains additional
information based on our investigations of a variety of topics
discussed in this post, including FIN7 and the POWERSOURCE and
TEXTMATE malware. Click here for
The Veil Framework is a
collection of tools designed for use during offensive security
testing. When the time calls for it, Mandiant’s Red Team will use the Veil-Framework
to help achieve their objective. The most commonly used tool is
Veil-Evasion, which can turn an arbitrary script or piece of shellcode
into a Windows executable that will evade detections by common
Veil 2.0 was made publicly available on June 17, 2013, and the core
framework has remained largely unchanged since that date. There have
been some modifications to the framework itself, but these have
generally been minor in nature, with the majority of modifications
involving the support of new programming languages and new payload modules.\
After spending a few years developing in Python, I revisited the
Veil codebase and identified parts of the backend framework that could
be developed more efficiently. Six months later, after refactoring the
codebase and adding a large number of updates, I am happy to present
Veil 3.0. The
main menu is shown in Figure 1.
Figure 1: Veil 3 main menu
First and foremost, one of the largest overhauls to Veil was
updating the version of Python from Python 2 to Python 3. Python 2 is
scheduled to reach end-of-life (EOL) in 2020, so it did not make much
sense to spend time performing a large update to Veil in a language
that will no longer be supported in three years.
Updating Veil from Python 2 to Python 3 was easily the most
time-consuming part of creating Veil 3. Running the 2to3 tool was
not an option; the conversion process required manual review for
essentially all changes to Veil.
One of the major differences when developing Veil in Python 3 vs.
Python 2 is how shellcode is handled and modified. To illustrates this
issue, Figure 2 shows a Python 2-based stager that includes encrypted
shellcode to be decrypted at runtime.
Figure 2: AES decrypting stager from Veil 2 in
While the code in Figure 2 works in Python 2, it will not work in
Python 3. Specifically, in Python 3, the shellcode no longer needs to
be string escaped into a bytearray after decryption. The output of
Python 3’s decryption is the original clear text data in a bytearray,
which is immediately consumable by the rest of the script. Figure 3
shows the Python 3 version of the same decryption stager.
Figure 3: AES decrypting stager from Veil 3 in
Early versions of Veil relied on the Metasploit Framework’s msfvenom
tool to generate shellcode for Veil payloads. After the initial
release of Veil, however, this caused a problem. The output for
msfvenom changed and it completely broke Veil’s ability to process
msfvenom output. After providing a patch to fix the issue, the Veil
team decided that a different solution would be required instead of
relying on a tool outside of our control.
was developed and released in 2015. Veil-Ordnance is a tool that
generates shellcode for use in Veil-Evasion stagers. Developing
Veil-Ordnance had two main benefits:
Previously, Veil-Evasion and Veil-Ordnance were two separate tools.
With the release of Veil 3.0, that is no longer the case, as shown in
Figure 4: Ordnance included in Veil 3.0
Veil 3.0 users still have the ability to use msfvenom to generate
their shellcode, but they now also have the option to use
Ordnance. Ordnance will be able to immediately generate shellcode
after users provide the IP and Port that the shellcode should connect
to or listen on. Ordnance supports the most popular payload types:
This gives Veil users multiple options to choose from – they can
stick with msfvenom, or use the new built-in tool, Ordnance.
While Veil itself is written in Python, the processed payloads and
output files can be in other programming languages. In Veil 3.0, two
additional languages are now supported:
Lua payloads are only supported in a script format that must be
compiled and run using a lua runtime, but Veil 3.0 running on Linux
can compile AutoIt3 scripts into Windows executables. Veil 3.0 also
supports the seven languages previously supported in version 2.0:
Another new feature in Veil 3.0 is the ability to check information
about the system where the Veil payload is running. This feature is
useful for ensuring that shellcode is only executed on target systems
and during the engagement timeframe. The stager performs these checks
and will only inject and execute the embedded shellcode if the
specified conditions are met. Figure 5 shows the options for this feature.
Figure 5: Environmental detection options
Users can specify one or more of the following checks for Veil stagers:
If specifying more than one check, all checks must be met; otherwise
the stager will cease execution without executing the shellcode.
This covers the major updates with Veil 3.0’s release. If you have
any questions, or encounter an issue, please visit Veil’s Github
repository. I hope that Veil can help further your assessments in
the same way that it has helped us.