Microsoft Xbox One 10.0.14393.2152 – Code Execution (PoC)
Linux/ARM – execve(“/bin/sh”, NULL, 0) Shellcode (34 bytes)
Mandiant has observed Russian nation-state attackers APT29 employing
domain fronting techniques for stealthy backdoor access to victim
environments for at least two years. There has been considerable
discussion about domain fronting following the release of a paper
detailing these techniques. Domain fronting provides outbound
network connections that are indistinguishable from legitimate
requests for popular websites.
APT29 has used The Onion Router (TOR) and the TOR domain fronting
plugin meek to create a hidden, encrypted network tunnel that appeared
to connect to Google services over TLS. This tunnel provided the
attacker remote access to the host system using the Terminal Services
(TS), NetBIOS, and Server Message Block (SMB) services, while
appearing to be traffic to legitimate websites. The attackers also
leveraged a common Windows exploit to access a privileged command
shell without authenticating.
We first discussed APT29’s use of these techniques as part of our
“No Easy Breach” talk at DerbyCon 6.0. For additional details on how
we first identified this backdoor, and the epic investigation it was
part of, see the slides
Router (TOR) is a network of proxy nodes that attempts to
provide anonymity to users accessing the Internet. TOR transfers
internet traffic through a series of proxy points on the Internet,
with each node knowing only the previous and next node in the path.
This proxy network, combined with pervasive encryption, makes tracking
the source of TOR Internet activity extremely difficult. A TOR client
can also use the TOR network to host services that are not accessible
from the open Internet. These services are commonly used to host “dark
web” sites such as the defunct Silk Road.
Typically network analysts can identify normal TOR traffic through
signature analysis or the identification of communication with TOR
is a publicly available obfuscation plugin for TOR and an
implementation of the domain fronting technique. To hide TOR traffic,
meek takes advantage of the way that Google and other Internet content
delivery networks (CDNs) route traffic. CDNs often route traffic from
IP addresses associated with one service to servers associated with
another service hosted on the same network. By hosting a meek
reflection server in one of these CDNs, meek can hide TOR traffic in
legitimate HTTPS connections to well-known services.
Meek obfuscates traffic in several stages. First, it encodes TOR
traffic into HTTP specifying the host name of the reflection server
(for example, the default server meek-reflect.appspot.com). It then
wraps that HTTP traffic in a legitimate TLS connection to a server
hosted in the same CDN cloud as the reflection server (in this
example, Google). When the CDN server receives the connection, it
decrypts the TLS traffic, identifies the hostname specified in the
HTTP header and redirects the traffic to the reflection server. The
reflection server then reconstructs the original TOR traffic from the
HTTP stream and sends the traffic to the TOR network, which routes it
to its destination. This process creates an outbound network
connection that appears to contain normal HTTPS POST requests for
google.com on a Google-owned IP address,
while discretely passing the traffic through the reflection server to
the TOR network. Meek can also use the TLS service and cipher suites
used by Firefox to further obfuscate traffic. Differentiating this
traffic from legitimate connections is extremely difficult, and
encryption of both on the initial TLS connection and the TOR traffic
makes meaningful analysis of the traffic impossible. Note: Google
suspended the reflection server meek-reflect.appspot.com, but other
servers, in the Google cloud or other supported CDNs, can fulfill the
Figure 1 displays the traffic flow when using meek.
Figure 1: Meek traffic flow
Mandiant discovered that APT29 enabled a TOR hidden service that
forwarded traffic from the TOR client to local ports 139, 445 and 3389
(NetBIOS, SMB and TS, respectively). This provided the attackers full
remote access to the system from outside of the local network using
the hidden TOR (.onion) address of the system.
The attackers created the following files and directories during the
installation and execution of the backdoor:
The file googleService.exe is the primary
TOR executable, responsible for establishing and maintaining encrypted
proxy connections. GoogleUpdate.exe is the
meek-client plugin, which obfuscates the TOR connection. These files
are publicly available and have the following hashes:
The file C:\Program Files
(x86)\Google\core contains configuration information for the
TOR service googleService.exe. The service
was configured to:
Figure 2 displays the contents of the TOR configuration file core.
Figure 2: Contents of TOR configuration file
The C:\Program Files
(x86)\Google\data\00\hostname” file contained a single line
with the TOR hostname for the system. This hostname was a
pseudorandomly-generated 16 character alpha-numeric name, with the
top-level domain (TLD) .onion.
Files(x86)\Google\data\00\private_key file contained the TOR
client RSA private key. Figure 3 displays the redacted contents of a
sample private_key file.
Figure 3: Redacted contents of sample private_key
The attackers used the scripts start.ps1
and install.bat to install the TOR service.
After installation, the attackers deleted these scripts from the
system. Additional files in the directory C:\Program Files(x86)\Google contained cached
data and logs from the operation of TOR.
Additional information on increasing visibility into PowerShell
activity through enhanced logging is available here.
The attacker executed the PowerShell script C:\Program Files(x86)\Google\start.ps1 to
install the TOR services and implement the “Sticky Keys” exploit. This
script was deleted after execution, and was not recovered.
By replacing the “Sticky Keys” binary, C:\Windows\System32\sethc.exe, with the Windows
Command Processor cmd.exe, the attackers
then accessed a privileged Windows console session without
authenticating to the system. “Sticky Keys” is an accessibility
feature that allows users to activate Windows modifier keys without
pressing more than one key at a time. Pressing the shift key five
times activates “Sticky Keys” and executes sethc.exe, which, when replaced with cmd.exe, opens a System-level command shell. From
this shell, the attackers can execute arbitrary Windows commands,
including adding or modifying accounts on the system, even from the
logon screen (pre-authentication). By tunneling RDP traffic to the
system, the attackers could gain both persistent access and privilege
escalation using this simple and well-known exploit.
The installation script start.ps1 created
a Windows service named Google Update to
maintain persistence after a system reboot. Table 1 contains registry
details for the “Google Update” service.
Table 1: Registry details for the TOR Google
Update Windows service
The script also modified the Terminal Server registry values fSingleSessionPerUser to allow multiple
simultaneous Windows sessions using the same account, and fDenyTSConnections to allow Terminal Services
connections. Table 2 shows the modified values for these registry keys.
Table 2: Registry modifications performed by start.ps1
APT29 adopted domain fronting long before these techniques were
widely known. By employing a publicly available implementation, they
were able to hide their network traffic, with minimal research or
development, and with tools that are difficult to attribute. Detecting
this activity on the network requires visibility into TLS connections
and effective network signatures. However, when dealing with advanced
threat groups who rapidly develop capabilities and invest in hiding
network traffic, effective endpoint visibility is vital. Monitoring
for potentially interesting events and attacker methodologies, like
lateral movement and new persistence creation, can allow defenders to
identify these stealthy methodologies.
Just over one year ago (November 2015), I released WMIOps, a PowerShell
script that enables a user to carry out different actions via Windows
Management Instrumentation (WMI) on the local machine or a remote
machine. WMIOps can:
As I continued to develop WMIOps and use it during Mandiant
Red Team Operations, I realized that it has some of the same
capabilities that are in Remote Access Tools (RATs). WMIOps’s
capabilities were in a state of disparate functions, but if I wove
what existed along with new functionality, I could create a RAT. After
months of development and internal testing, I’m happy to publicly
WMImplant leverages WMI for the command and control channel, the
means for executing actions (gathering data, issuing commands, etc.)
on the targeted system, and data storage. It is designed to run both
interactively and non-interactively. When using WMImplant
interactively, it’s designed to have a menu of commands reminiscent of
Meterpreter, as shown in Figure 1.
Figure 1: WMImplant main menu
After spending some time developing WMImplant, I ran into issues
storing data on systems that used Device
Guard, a Microsoft security feature added in Windows 10 and Server
2016. Even though this feature and these operating systems are not
widely deployed today, I wanted WMImplant to support these systems
since I expect Device Guard protected systems to become more common,
especially at security-conscious organizations. Device Guard helps
protect systems by employing (among other capabilities not detailed here):
On a Device Guard protected system, attackers cannot run custom
executables, and the available PowerShell cmdlets are severely
restricted. For example, simple functionality such as base64 encoding
a string is not permitted within Constrained Language mode, as shown
in Figure 2.
Figure 2: PowerShell Constrained Language mode
blocking base64 encoding
At first, I designed WMImplant to use the Windows Registry for data
storage, as described in Matt
Graeber’s WMI research. However, after discussing using the
Windows Registry for data storage with Matt Dunwoody (a Mandiant
coworker), he suggested, “Why not also use WMI itself for storage?”
This conversation led me to research using WMI for data storage. I
found a proof-of-concept for creating custom WMI properties (Figure 3)
in FireEye’s report on WMI
Offense, Defense, and Forensics.
Figure 3: Sample code from FireEye report on WMI
Offense, Defense, and Forensics
However, after testing this code on a Device Guard protected system,
I discovered that this wasn’t permitted within Constrained Language
mode, as shown in Figure 4.
Figure 4: Constrained Language mode blocking WMI
After some additional research, I found that within Constrained
Language mode, users are able to create custom WMI classes. But, as
evidenced by Figure 4, WMI property creation is not allowed, so this
wouldn’t work for data storage. Therefore, my next thought was to
store data in an existing WMI property. In order to leverage an
existing WMI property, a few conditions would need to be present:
I modified an existing PowerShell script to enumerate all WMI
classes, find the properties of each class, check if each property is
a string type, and determine if it is writable (the script is available here).
The script identified a list of candidate WMI properties, but for
one reason or another, modifications to those that I initially tested
resulted in “general failures”. Then, I came across a class I have not
previously used: Win32_OSRecoveryConfiguration. This class has
a property named “DebugFilePath”, which is the file path where Windows
will place a memory dump after a computer failure, as shown in Figure 5.
Figure 5: Win32_OSRecoveryConfiguration’s
The DebugFilePath appears to only accept a file path, and the
property should be limited to the length of a valid Windows paths (260
characters by default or 32k with LongPathsEnabled). In testing,
however, I discovered that I could write an arbitrary string to the
DebugFilePath property within Constrained Language mode without
adversely affecting the targeted system. The final test was to
determine how much data could be placed in the DebugFilePath property.
Figure 6: Data storage test within DebugFilePath
Figure 6 shows that the DebugFilePath property can store over 57
megabytes of data. This satisfied the data storage requirement for
WMImplant, and future testing showed that the DebugFilePath property
could store more than 250 megabytes of data. Additionally, using the
DebugFilePath WMI property for data storage provides the side-benefits
that it is easily retrievable and modifiable remotely.
This discovery shaped WMImplant’s command and control communications
methodology. For commands issued by WMImplant that require data
storage, the communication process is as follows:
This methodology for command and control communications minimizes
the amount of time that the WMI property is modified from its original state.
I’ve developed WMImplant for both interactive and non-interactive
use. Users also have the ability to change the user account that is
authenticating to the targeted machine. As shown in Figure 7, users
can issue the “change_user” command, provide the username and password
to use, and then all future commands through WMImplant will
authenticate with the provided credentials.
Figure 7: Changing the current user context
The easiest way to use WMImplant is interactively; however, that
isn’t always possible. RATs such as Meterpreter or Cobalt Strike’s
Beacon allow users to load and execute PowerShell scripts, but both of
those tools require non-interactive use. That is, the tools accept a
command to run, execute it, and return the results. They do not allow
the user to interact with the command while running, however.
WMImplant includes a built-in command-line generating feature
specifically for this use case. To generate a command-line, start
WMImplant and specify the “gen_cli” command.
After issuing the “gen_cli” command, the user will be presented with
the normal WMImplant menu and asked for the command to be run.
WMImplant will then ask for any required information for the command
specified. Once the user has provided everything that’s required,
WMImplant will display the command-line command to run in a
non-interactive manner, as shown in Figure 8.
Figure 8: “gen_cli” output
At this point, the user can load WMImplant within the RAT of choice,
and copy and paste the command to run WMImplant non-interactively.
Another of WMImplant’s capabilities is the ability to run a
PowerShell script on a remote machine and receive script output. This
is performed through a multi-step process:
This multi-step process is demonstrated in Figure 9.
Figure 9: Remote PowerShell execution
While I’ve only talked about a limited number of WMImplant’s
features, others include:
I hope that WMImplant can help others as it has helped us on
multiple assessments. If you notice any bugs, please let me know and
I’ll be happy to get a fix pushed!
WMImplant can be downloaded here.
I want to state that I wouldn’t have been inspired to work on this
without the previous
work of Matt Graeber, Willi Ballenthin, and Claudiu Teodorescu.
Their work gave me a lot of great ideas that I was able to build upon
when developing WMImplant.
Oracle Knowledge Management 12.1.1
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 126.96.36.199. 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 188.8.131.52 (first redirect
after legitimate ad) and 184.108.40.206 (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 220.127.116.11. 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 18.104.22.168
and 22.214.171.124. 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 126.96.36.199
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 188.8.131.52
Figure 12: Domains with iframe load to Sundown
EK hosted on IP 184.108.40.206
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: 220.127.116.11 or 18.104.22.168.
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 22.214.171.124, which is further redirected
to domains hosted on 126.96.36.199 / 188.8.131.52 / 184.108.40.206.
against domains hosted on 220.127.116.11 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 18.104.22.168), 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.