Understanding the SmokeLoader Downloader

Thursday, February 9, 2017
Downloaders and droppers (aka malware that delivers other malware) have been forced to live in the shadow of more famous stages of the exploit kit


Downloaders and droppers (aka malware that delivers other malware) have been forced to live in the shadow of more famous stages of the exploit kit chain, like landing pages or the malware that's eventually dropped. One reason they are often overlooked and not analyzed as often is because they typically (and conveniently) wipe themselves from compromised hosts once they completely deliver their malicious payload.

But don't mistake the lack of attention for lack of importance. Downloaders and droppers play a vital role in the web exploitation ecosystem. They're often used across multiple exploit kits and they are effective at delivering a broad menu of malware including ransomware, banking trojans, credential stealers etc.

SmokeLoader is an older downloader that continues to be actively developed and utilized to deliver other malware. Fidelis Threat Research observed a SmokeLoader sample delivered through the Sundown Exploit Kit. We're sharing our findings with the security community to keep them updated on this evolving threat.

This blog post covers four key points:

  • The delivery method we've observed using SmokeLoader and the delivery method that we used to track this and other threats.
  • An overview of the crypter that continues to be actively used.
  • The process a malware researcher could use to investigate a similar sample, including string decryption and C&C (command and control) traffic decryption.
  • Overview of IOCs that an be used to detect SmokeLoader.



This SmokeLoader sample was delivered from the Sundown Exploit Kit. This sample has been consistently delivered by this exploit kit as noted by researchers at Malwarebytes in late 2016.

A number of chains related to the Sundown Exploit Kit have been analyzed after it began including CVE-2016-0189, coupled with either their own or an affiliate's consistent usage of SmokeLoader. Then in January 2017 we began tracking what appeared to be two distinct instances of Sundown traffic similar to what we saw in the Malwarebytes post.

One exploit kit thread using minimal obfuscation was delivered through malvertising campaigns and pretended to be affiliated with EmpowerNetwork, a popular blogging and webhosting platform. While the EmpowerNetwork thread was largely in the clear with minimal obfuscation, the second exploit kit  thread had an obfuscated landing page and favored .mobi registered domains for a period of time during our observation. Both threads delivered SmokeLoader, which in turn downloaded a diverse range of malware.



The crypter is one that has been showing up recently using NSIS with an encrypted payload. The crypter normally works in three stages.   

  1. A DLL is called that will set up proper memory permissions.
  2. The code will decode out the function names that will be used and find the next code to run, which is typically also in a DLL.
  3. This next DLL will then be used to decode the encoded payload. Following this, the first DLL will load the next stage DLL, which will then take over reading the encoded payload. In this case, it included the encoded payload and all the needed encoded function names.

After decoding the function names and allocating memory with VirtualAlloc, the crypter decodes a small section of bytecode that basically performs a sleep by looping 0x18f06 * 0x1644a times. As analysis continued, we found many instances of useless code such as this one. After decoding out the payload, the malware is injected into a new process of itself. Then the current thread is hijacked using GetThreadContext/SetThreadContext before finally resuming the program. There are a variety of methods for breaking into a child process. In this example, the entry pointer was overwritten with custom code to gain control of execution.


Entry point of hijacked thread




Modified entry point



Custom Sleep routine



After breaking in with the debugger, the bytes can be easily changed back to their original version.

Fix entry point back










Initial Code

After the new unpacked code is run, the bot begins XORing sections of its code, leading to a few debugger checks almost immediately after. The bot takes the isbeingdebugged flag and uses it to XOR a byte of its next code section -- so if it is being debugged then the bot will break.

Debugged flag check


The same check is then performed using the NtGlobalFlag:





Upon successfully passing these checks, the bot decodes a large section of itself, which is then decompressed using APLIB. Once this section is decompressed, the final stage of the bot is revealed.

The final stage has two noticeable sections of encoded data. Both RC4 encrypted sections are decrypted using a hardcoded 4 byte key that is passed to the routines (“zVsO”).

RC4 key for strings



This next stage, ultimately, has two paths that it can take. The first performs a bunch of system checks looking to see if it’s being analyzed or running in a virtual environment before injecting itself into a new explorer.exe process. The second is intended to be run after it has been injected into Explorer. This is where the malware performs the following tasks:

  • Harvests system information, such as version
  • Creates a hash based on computer name and other data
  • Checks for system connectivity using an onboard URL (for example, bing.com)
  • Constructs and encrypts the data to be POSTed to the C2 (command and control)



As previously mentioned, the strings are obfuscating using a 4 byte key. They are then split using a separator value, which in this case was ‘\x01’. The bot has a routine designed to pass any number in the block of decoded strings that it wants to be used for decoding.

String Decrypt













This routine is only called twice, and does so with different blocks of data. This means there are two blocks of strings to be decoded.

String Decrypt Cross References






Here is the address and size being passed in to the string decryption routine.

String Decrypt function calls


At first glance, it seems this information is used to write a string decoder, but after checking the results, the URLs are not decoded. A little digging and pivoting off referenced addresses (found near the two blocks of data) result in the discovery of another decoding routine.

A quick overview of this additional routine shows that each block of encoded data is prepended with a crc32 hash that is checked against the decoded data.

URL Decode overview













The decoding routine looks confusing at first, but by taking small pieces and verifying that the decoded data is the same as the data in the bot, the decoding function can be understood quickly:

























We know that the first 4 bytes are the CRC32 hash, but glancing at the code shows that the beginning of the data block addressis used to XOR each byte pulled out of the other register. We can see that the first byte of the CRC32 hash is used as an XOR key against every two bytes independently, followed by a subtraction of the output of that calculation.

A python script for use in IDA to decode out the URLs in the sample is included in this report.


Command and Control (C2)

This variant of SmokeLoader performs a POST containing RC4 encrypted data to one of its C2 URLs that it keeps onboard. 

C2 Data Encryption Overview
























As long as a response is received after the POST (even a 404), then the data will attempt to be read. As can be seen in the figure above, the 4 byte RC4 key is generated using the rdtsc command. After encrypting the data, the 4 byte key is loaded onto the front of the encrypted data. Decryption then becomes straightforward:

key = posted_data[:4]
rc4 = ARC4.new(key)
decoded_data = rc4.decrypt(posted_data[4:])



Downloaders and other delivery systems seek to obscure their payloads using a variety of techniques. This post explored techniques used by SmokeLoader, a downloader currently deployed via Sundown Exploit Kit, to confuse analysts and deter detection. In our estimation, these techniques will be observed with greater frequency in the coming years, which calls out the need for more thorough detection capabilities across the entire chain of events at multiple levels.

Fidelis customers are protected from SmokeLoader and Sundown Exploit Kit by a variety of mechanisms designed to detect malware throughout the infection chain. Learn more at www.fidelissecurity.com.



Sundown EK:























































-- Fidelis Threat Team Researcher Jason Reaves

Revenge of the DevOps Gangster: Open Hadoop Installs Wiped Worldwide

Wednesday, January 18, 2017
Earlier this month, security news media reported attackers holding internet-exposed MongoDB and Elasticsearch databases for ransom. Attackers said

Earlier this month, security news media reported attackers holding internet-exposed MongoDB and Elasticsearch databases for ransom. Attackers said they’d return the data if they got paid -- otherwise, the data would be erased. In many reported instances, attackers simply deleted the data. Unfortunately, more attacks are underway.

Last week, Fidelis Cybersecurity Threat Research observed similar attacks on Internet-facing Hadoop Distributed File System (HDFS) installations. Like the MongoDB and Elasticsearch incidents, attackers would erase all the data on the system. To make matters worse, we confirmed additional attacks on HDFS instances worldwide.

For these events, attackers are leveraging a logical blend of key technology trends:

  • Minimal security. Many new "big-data" database solutions introduced over the past decade include minimal native authentication and security. It's expected that implementers will handle these vital security functions separately. But many times they do not.
  • Mandatory internet access. A number of these solutions are available within the platform-as-a-service (PaaS) model, which must be accessed via the internet. Undoubtedly, numerous managed instances are also directly exposed to the internet. Researchers such as John Matherly have been talking about the risks of such exposed installations for some time.
  • Denial of access. A few years ago, the consequences of exposed data included theft and resale on the underground. We're now seeing ransomware and outright deletion – a 'denial of access' to the user's data. While attackers are targeting end users with ransomware, it's also being effectively deployed against enterprises and their services in the past 18 months.

These factors have combined in attacks against Mongo and Elasticsearch instances in the past few weeks. The purpose of this post is to make the security community aware of similar incidents involving Hadoop delivered by service providers.


Example HDFS Site where data has been wiped


In this case, we observed an attacker erasing most of the directories and creating a single directory called “NODATA4U_SECUREYOURSHIT”.  There was no attempt to claim a ransom or any other communication -- the data was simply deleted and that directory name was left as a calling card. We estimate that the potential exposure of this attack is around 8,000-10,000 HDFS installations worldwide, but precise numbers are difficult to determine.

A core issue is similar to MongoDB, namely the default configuration can allow “access without authentication.” This means an attacker with basic proficiency in HDFS can start deleting files. On or around January 5 to January 6, traffic to port 50070 soared as attackers scanned for open HDFS installations to target: 


  Port 50070 traffic from the SANS Internet Storm Center


Port 50070 Traffic Graph from Qihoo 360

Port statistics from the SANS Internet Storm Center (above) and the Qihoo 360’s Netlab (below) show a significant spike in traffic when this attack occurred on January 5-6. Qihoo shows this almost exclusively from a single Chinese IP of However, it's important not to jump to conclusions about the attacker's location simply by looking at an IP address. Attackers use infrastructure all over the world to hide their identities. Coincidently, the second highest scanner  is adjacent to our suspect,

A quick scan using Shodan shows just how prevalent exposed HDFS installations are. In many cases, installations also lack authentication. In researching this post, the screen capture was taken  from the initial few hits showing those sites had been wiped.  It’s unclear what the motivation of the attacker is, but it seems like this was an intentional “security awareness training” exercise, albeit a criminal one.

So what can you do to prevent these attacks?

  • First, avoid having HDFS on internet-facing connections. If that's not possible, use built-in methods that require authentication and only use the HTTPS versions of these web services.
  • Second, remember that no authentication is required by default, so if anything running HDFS connects to the internet, the entire world has access to your data.
  • Third, brush up on attacker tools. Check out some of the freely available Hadoop attack tools, like the Hadoop-attack-library, that make these kinds of attacks easy (note, we found no evidence this specific tool was used in this case).


"Big data" databases are often consumed as a service from third parties or installed and managed from cloud assets. Any database service directly exposed to the internet without adequate authentication is at risk. Exposed data will be stolen, encrypted and/or erased.

Service providers should implement strong authentication and access isolation. Users of such services should assess these protective measures before entrusting their data to these services. Always back up data using a robust monitoring program to detect and respond to instances in the event unauthorized access occurs.

 -- Fidelis Threat Research Team

TrickBot: We Missed you, Dyre

Saturday, October 15, 2016
In November 2015, the Dyre banking trojan seemingly disappeared overnight surprising security researchers worldwide. Months later it was announced

In November 2015, the Dyre banking trojan seemingly disappeared overnight surprising security researchers worldwide.  Months later it was announced that Russian authorities had arrested most of the gang responsible for its operations.  Prior to that, it was a relatively rare act for Russian authorities to take action in such matters.  Since then, nothing has been heard from those actors but the speculation was that some of programmers and other elements of the criminal operation would be subsumed into other cybercriminal operations.

In September 2016, Fidelis Cybersecurity was alerted to a new malware bot calling itself TrickBot that we believe has a strong connection to the Dyre banking trojan. From first glance at the loader, called TrickLoader, there are some striking similarities between it and the loader that Dyre commonly used. It isn’t until you decode out the bot, however, that the similarities become staggering.

This would suggest, but is far from conclusive, that some individuals related to the development of Dyre have found their way into resuming criminal operations.

The campaign we have observed involving TrickBot includes webinjects that target banks in Australia. A full list of hashes, IOCs and targets is available at the end of this blog post.

With regards to TrickBot, while the version of the bot has been reset and quite a lot of code has been removed we don’t believe this is an old version but is instead a rewrite, since the coding style is not conclusively that of old Dyre. While the bot performs very similar functions and activities, the code style is quite a bit different than the older Dyre code in a few respects

  • Instead of running commands directly the bot interfaces with TaskScheduler through COM for persistence
  • Instead of running an onboard SHA256 hashing routine or AES routine the bot utilizes Microsoft CryptoAPI
  • There is considerably more code in the C++ programming language versus the original Dyre that used C for the most part.

Based on these observations, it is our assessment with strong confidence that there is a clear link between Dyre and TrickBot but that there is considerable new development that has been invested into TrickBot. With moderate confidence, we assess that one of more of the original developers of Dyre is involved with TrickBot.

This blog post details our technical analysis of TrickBot.


The first thing we noticed is the custom crypter which after careful analysis was found to be used for both TrickLoader along with Vawtrak, Pushdo and Cutwail malware. This is interesting because Cutwail spambot was a favorite of old Dyre crew for use in their spam campaigns.


Next we take a look at the loader which from first glance appears to be similarly constructed as Dyre's loader, including a x86 and x64 bot version and another section named x64 loader(Figure 1).









Figure 1 TrickLoader resources

The loader simply checks if it is running on a 32 or 64bit system before decoding the appropriate resource section(s). The bit check is performed using GetNativeSystemInfo (Figure 2). The decoding routine is a LCG(Linear Congruential Generator) based routine using a hardcoded seed of 12345 (Figure 3).


Figure 2 TrickLoader Bit Check






















Figure 3 TrickLoader resource decode








Figure 4 TrickBot resource sections


The Bot

The bot shows a number of similarities to Dyre but appears to have been rewritten. This assumption is made based on old Dyre code, which would primarily use built-in functions for doing things such as AES and SHA256 hashing. In the recent samples identifying themselves as TrickBot, the code appears to be based on that old code but rewritten to use things such as Microsoft CryptoAPI and COM.

Similar to old Dyre the bot comes with an onboard config in its resource section along with an ECC cert (Figure 4). The bot also uses a very similar but slightly modified version of the old Dyre C2 decryption, this routine is then used for encrypting/decrypting all data respectively. The algorithm used by Dyre for generating the AES and IV from the first 48 bytes of data based on a rehashing scheme was commonly referred to as Dyre's derive_key function, this function was slightly changed in the new bot.

Image5Figure 5 TrickBot Derive Key















Figure 6 TrickBot Decrypt

For starters, both the AES key and IV are derived using 128 rounds of SHA256, the key is derived from the first 32 bytes of data and the IV from bytes 16 through 48(Figure 5). Another slight modification is the hash data instead of being continually rehashed, the data is now appended to each subsequent hash and that data is then hashed to get the next hash, ultimately ending after 128 iterations with the key based on the hash of all the accumulated data. Knowing this is enough to modify the old Dyre decrypt and derive key functions to work for TrickBot(Figure 6). This routine is used to decode the onboard config(Figure 5), the C2 traffic and the modules.


















Figure 7 Onboard Bot Config









Figure 8 Onboard Module Config


The first bots pushed for testing of TrickBot came with a single module called GetSystemInfo. This module comes in both 32bit and 64bit version and includes an interesting pdb path(C:\Users\The trick\YandexDisk\Projects\Bot\Bot_(1006)_08.12.2016\Bot\GetSystemInfo_solution\x86\Release\GetSystemInfo.pdb). As the name suggests the module appears to be entirely geared towards harvesting system information, probably to give the developers a better understanding of their test bots. The modules also come with their own embedded moduleconfig(Figure 6) and are stored on disk in a ‘/modules/’ folder at the same location that the bot runs out of. Also, as was the case with Dyre the modules are downloaded from the mod server which has been renamed in the initial config for TrickBot to plugin server or psrv. 

On October 13, 2016 a new bot was found that contained the injectDll which is the browser inject module for TrickBot, the webinject config filenames are stored in the moduleconfig of the injectDll module as sinj, dinj and dpost. It would appear as though the injects are still being tested and possibly added as they convert them over to the new structure. This setup does fall in line with how Dyre had its config separated out though. 

While the bot is still missing quite a lot from what was previously seen in Dyre it is obvious that there is correlation between the code used in this bot and that from Dyre. As the bot appears in development they are pushing to rebuild their Cutwail botnet in preparation for future spam runs. It’ll be interesting to see if TrickBot can reach or pass its predecessor.



TrickLoader Hashes:
Pushdo with same crypter:
Trickbot C2s:    

Config Targets:








-- Fidelis Threat Researcher Jason Reaves

Understanding the Web Shell Game

Tuesday, June 14, 2016
What can bad guys use to launch a ransomware attack, facilitate an email spamming platform, or ensure persistent access to an enterprise? Compiled

What can bad guys use to launch a ransomware attack, facilitate an email spamming platform, or ensure persistent access to an enterprise?
Compiled malware and compromised credentials could work. But web shells provide an even more stealthy way to establish a beachhead and quietly hide on the network for future operations.

Web shells are not a new tactic. But they have been used in a number of recent attacks. We saw them in the ransomware attack that hit MedStar, which operates hospitals and healthcare facilities throughout the Washington D.C. metro area. Web shells have also recently been uncovered on a Facebook server, found on a popular software tool used by websites to process user-submitted photos, and discovered within a compromised commercial bank.

What makes them such a popular tactic in the attacker’s toolkit? One reason is that they are hard to detect. Attackers typically install web shells on Internet-facing web servers where they take advantage of installed applications. Depending on configuration and installed applications, internally facing servers could be targeted as well.

An attacker can introduce a web shell by exploiting a web application vulnerability or even a feature, such as content upload. The web shell can be as simple as a piece of code that provides a command shell on the targeted system. Or it can be as complex as an executable file that installs a full-blown Remote Administration Tools (RAT). The web shell code runs on the targeted server using existing resident applications.

Recently, the Los Angeles Times was hit when attackers leveraged a subdomain page using WordPress, a popular Content Management System (CMS) used for blogging and serving content. Many times, CMS targeting is associated with email spam campaigns.

While web shells are a favorite tool for email spammers, we have also witnessed numerous nation state actors employ web shells as part of cyber espionage campaigns.

Despite the seemingly ubiquitous nature of web shells, defenders and system owners can take preemptive actions to reduce the likelihood of being compromised by them. In parallel, defenders and administrators can also use web shell footprints and artifacts to detect their presence. Here are a few recommendations to get you started:

  • Review anomalies in access and error logs regularly.
  • Ensure server software and web applications are updated regularly.
  • Prevent your web server from divulging specific details/information about itself.

Fidelis’ white paper, Understanding Web Shells, contains additional preemptive considerations, artifacts useful in detecting many web shells and additional recommendations. Download the complimentary paper to learn more.

-- David Gilbert, Manager, Security Consulting Services

New Ursnif Variant Targeting Italy and U.S.

Tuesday, June 7, 2016
Fidelis Cybersecurity has been investigating a new variant of Ursnif, a family of trojans that captures and reports information about user activity

Fidelis Cybersecurity has been investigating a new variant of Ursnif, a family of trojans that captures and reports information about user activity back to the attacker. We recently observed the variant distributed in phishing runs designed to appear as legitimate banking-related emails. On infected hosts, it attempts to perform webinjects to capture credentials for major U.S. banking sites, including Citibank, JPMorgan Chase, USAA and Capital One. Interestingly, it takes screenshots when victims visit a variety of Italian sites, such as Unicredit, Poste and Relax Banking. To evade detection, it also blocks access to a surprisingly large number of security-related websites. What specifically grabbed our attention was the change in command-and-control traffic that distinguishes it from standard Ursnif.

Even as ransomware dominates the headlines, banking trojans are a profitable mainstay of the criminal domain. As recently reported, ransomware like CryptXXX has acquired credential-theft capabilities, signaling a marriage of sorts within the crime family. Banking trojans have been the vehicle for numerous innovations in malware over the years. These developments in Ursnif show us that technical investment across the crime domain continues. The targeting of Italian and U.S. financial institutions also points to the global scope of opportunity for such criminal actors.

This post covers our analysis of these changes and how we reversed them. Further, we share configuration details as well as IOCs.

Infection Chain

The campaign we observed involves a javascript downloader spammed out in zip files. By using file names ending in .doc.jsIt, it disguises itself by pretending to be a document. The javascript downloader we analyzed included over 400 links that mostly appeared randomized -- except for one in particular, (fuchsias[.]net/New_Folder/icq[.]scr). The large number of random links were likely inserted as an attempt to hide the payload from researchers.

Once launched, it then downloads Andromeda, which is commonly used to deliver other malware. Using RC4 encryption, Andromeda will check in with its panel to retrieve a list of modules, or payloads, to  download. In this case, Andromeda downloaded a variant of Ursnif, along with Pony malware. This variant has been tracked by other researchers and is notable in that it uses a /images/ structure in its C2 communications, as seen in the example traffic later in this post.

After being unpacked and decoded, it's clear that this variant contains strings commonly associated with Ursnif. It also contains the strings associated with Rovnix and Gozi. This is likely why many researchers have been calling it Ursnif/ISFB/Gozi. There appears to be, at the very least, two versions of Ursnif in use for different purposes. One has been heavily reported as a fileless Ursnif variant delivering POS malware and has also recently been called PowerSniff. This variant, however, doesn’t appear to have the same C2 traffic, as the string appears almost base64-ish in nature and the strings allude to it being more focused on form-grabbing and web-injection.


As it turns out, this variant actually has the normal Ursnif traffic – except that it is encrypted and encoded to hide. After unpacking the DLL, we can either decode the strings section -- or as luck would have it, the malware will do it for us -- and copy the decoded section right over the old one. After that, looking at it in IDA becomes significantly easier.

Now that we can see the decoded strings and we can even see where the version number is passed in, finding the point where the traffic is created becomes a little easier.


After being generated, Ursnif will then generate a random url variable that's prepended to the previously generated traffic string. The reason it prepends this will become apparent later, as the string will be encrypted in CBC (Cipher Block Chaining) mode and so the random data at the beginning will cause the traffic string to differ every time.


After it is concatenated onto the newly generated random URL variable, the string is passed off to a function to be encrypted and base64 encoded. In this case, the encryption used was Serpent, a runner-up for AES. We can identify this algorithm by narrowing in on a particular loop in the code where it uses the magic number 0x9e3779b9 and loops 0x84 times (when going by DWORD values).


This can be seen in a C implementation of this algorithm below.


Unlike most of the implementations found online, the one in Ursnif involves CBC. After finding a good implementation of the algorithm using the ECB (Electronic Codebook) written by Bjorn Edstrom and studying the description of CBC, we can turn this Python code into a CBC mode for testing fairly easily, as the bot uses an IV of 16 NULL bytes.



After encrypting the URL, the bot then Base64 encodes the string and trims off any newlines or base64 padding ‘=’ characters. Blog6

Next, the bot passes the string to a function that will enumerate all characters in the string, looking for ‘/’ and ‘+’ characters. When found, they will be converted into their hex form preceded by an underscore such as ‘_2F’.


Next, the string is passed off to a function that will add random slashes to the string in order to make it look more like a URL string.

























The URL string is finished by adding either a .bmp or .gif extension to the end and appending the entire string to /images/ and then appending the combined string to the domain or domain-and-URL combination in the bot.

After finally checking in, the bot will get a fairly large U.S. config and the targets are included below. This run of Ursnif appears to be spammed to both the U.S. and Italy, which makes sense, given the targets are primarily businesses based in these countries. However, Ursnif itself has basic form-grabbing capabilities, so any site or application that an infected user logs into could potentially be compromised. Attackers are stealing log-in credentials and, in some instances, screenshots.


Ursnif continues to see investments and remains a potent banking trojan. As with other banking trojans, the use of multi-factor access (MFA) controls is the best countermeasure to protect against such man-in-the-browser attacks. Small businesses as well as individuals with significant assets should try to separate their at-risk activities like email and casual browsing from access to online banking accounts.

IOCs on github

Ursnif C2 traffic:



Ursnif C2s:
















Webinject targets:














Screenshot Targets:









VNC Targets:



Blocks Access to:
















































*defenx. [.]nl*










































































































































































-- Fidelis Threat Research Team researcher Jason Reaves

The Many Paths to Angler

Wednesday, December 23, 2015
Over the past few months, we have seen Angler Exploit Kit activity increase across our observed telemetry. In some instances, Angler EK relies on

Over the past few months, we have seen Angler Exploit Kit activity increase across our observed telemetry. In some instances, Angler EK relies on redirects (also known as “gates”) to funnel victim traffic to its landing pages. In others, Angler EK does not use redirect techniques but instead sends victims directly from a compromised site to the landing page. 

Redirects are URLs or specifically crafted websites that forward victims to the Angler EK landing page. They could provide Angler EK operators the functionality to:

  • Obscure the source compromised site
  • Prevent more than one redirect from a single IP
  • Target specific regions
  • Make automated analysis and tracking more difficult

There are four redirect methods in active use today. Most of these methods have been discussed in varying detail elsewhere. In this post, we will consolidate the knowledge and share additional details of each method used. And because Angler continues to send victims directly from a compromised site to landing pages, we will also explore that infection path and provide recent landing page IPs.

Angler Exploit Kit Activity

Angler EK activity decreased in October (hat-tip to Cisco) but rebounded in November based on our telemetry. Figure 1: Observed Angler landing page detections by month

EITest Redirect

Status: Active as of December 2015

 Current IP(s)
31.184.192[.]206 31.184.192[.]197 31.184.192[.]216
31.184.192[.]202  85.93.0[.]32  

URL Format: /page.php? id=4646BCDD83AB2C1F3AAE14BA34C1622E0EB31BE3B5E1632E19710D

Example of code on compromised site:

Angler-2Figure 2: EITest redirect method compromised site code example

Called “EITest” by Malwarebytes due to the static id value in the html, this redirect method uses an Adobe flash file to filter victims based on certain criteria. If met, the victim is redirected to the Angler EK landing page.

The obfuscation function format embedded within the flash file recently analyzed (354206353ee3d4e7b279bc66a0727bcf) is different than the one from 2014. However, the criteria for Angler EK redirection (browser version) remains the same.

Below is the obfuscated ActionScript as well as the decoded iframe output.


Figure 3: Obfuscated ActionScript embedded in flash file

Figure 4: Deobfuscated ActionScript embedded iframe

As shown, if the criteria within the flash file is met, the victim will be redirected to the Angler EK landing page.


Figure 5: Redirect to Angler Exploit Kit

This method relies heavily on the use of non-standard TLDs:

















Figure 6: Observed TLDs associated with this method in use since October 2015


Shadowed Redirect

Status: Active as of December 2015

 Current IP(s)
85.143.220[.]153 85.143.217[.]31 85.143.219[.]167
85.143.217[.]31 85.143.220[.]95 85.143.216[.]253
85.143.220[.]44 85.143.220[.]18 85.143.219[.]200
85.143.220[.]109 85.143.217[.]50 85.143.219[.]77
85.143.219[.]65 85.143.219[.]232 85.143.219[.]163
178.33.200[.]161 188.227.74[.]75 188.227.19[.]86
85.143.217[.]191 212.116.121[.]51 188[.]227[.]72[.]137 

URL Format: attendance.workforthis[.]com/law/lang.js

Example code on compromised site:


Figure 7: Shadowed Redirect method compromised site code example

As discussed here, this method relies on the initial iframe on the compromised site to send the victim to the redirect intermediary server. This server will respond with either an HTTP 200 and no content, HTTP 200 and an iframe redirecting to the Angler EK landing page, or HTTP 404 “Not Found” depending on a variety of circumstances.


Figure 8: Response if criteria not met for landing page redirect

If the client request meets the redirect criteria, they will be redirected to the Angler EK landing page.


Figure 9: Angler Exploit Kit landing page redirect


Dynamic DNS Redirect

Status: Active as of December 2015

Current IP(s): 46.161.2[.]73

URL Format: /wordpress/?bf7N&utm_source=le

Example code on compromised site:


 Figure 10: Dynamic DNS redirect method compromised site code example

This method relies on an iframe on the compromised host pointing to a dynamic DNS resource. This resource will then send the victim to the Angler EK landing page or respond with a 404 Not Found. Here are a few of the recent domains we’ve seen using this redirect method:

gffpkdhftg.ddnsking[.]com uftbacu.ddnsking[.]com dvusepghqm.ddnsking[.]com
npmmeiuxek.ddnsking[.]com odlbzv.ddnsking[.]com skuuiz.ddnsking[.]com
bgfnloc.ddnsking[.]com koiwjesyz.hopto[.]org naagdoisa.hopto[.]org
onndutoiys.hopto[.]org bfevqjozap.ddnsking[.]com bmlarlfqco.ddnsking[.]com
fevxeta.hopto[.]org fobrsvvqz.ddnsking[.]com mbpskt.ddnsking[.]com
mpfpgjf.ddnsking[.]com oscvkeqg.ddnsking[.]com sagchixhv.hopto[.]org
xebxaidld.hopto[.]org dngtejhj.ddnsking[.]com dosluaxap.hopto[.]org
glxpljmuv.ddnsking[.]com iyzxwcki.ddnsking[.]com krxolxmi.ddnsking[.]com
orahwg.ddnsking[.]com oubboyft.ddnsking[.]com pimdzgov.hopto[.]org
ynftos.hopto[.]org fhouwwwp.hopto[.]org phwanzr.hopto[.]org
qrkehvc.ddnsking[.]com szwpcp.ddnsking[.]com wchszwypr.hopto[.]org
ykdvjvsrb.ddnsking[.]com yskivegvvb.ddnsking[.]com  

Figure 11: Dynamic DNS domain example


301/302 Location Redirect

Status: Active as of December 2015

Current IP(s): 185.104.8[.]50

URL Format: Various. This method uses HTTP 301 or 302 and the Location HTTP header to send the victim to the Angler EK landing page. Below is an example of the request and the 302 found with the Angler EK URL in the Location header.


 Figure 12: GET request and HTTP server response with Angler Exploit Kit landing page


Angler Exploit Kit Landing Page

Status: Active as of December 2015

Current IP(s): Various; see IOCs below

URL Format:

/civis/search.php?keywords=90qs9&fid0=6m.tm0x360w12 /civis/index.php?PHPSESSID=7o&action=0x7.012g1815k447rr05"


/civis/search.php?keywords=36ez&fid0=0meicaot4b4jolntuyg8apov2p0wmvi95c5jasm2nob3z6bfh1s-zstibz1176ecs1tg3c5hey7va464mwmt05_sgl2txuo5 /forums/viewtopic.php?t=833l4&f=st41.285w9309da15577


With this example, victims are redirected to Angler EK landing pages directly from compromised sites. In some cases, the iframe exists on the main page of the compromised site. In others, the main page refers to other site resources that eventually lead to Angler EK as shown below.


Figure 13: The main page of a compromised site pointing to the local “stats” resource


Figure 14: The “stats” resource with iframe to the local “/1/” subdirectory


Figure 15: /1/ directing victims to the Angler Exploit Kit landing page

The recent list of IPs hosting Angler EK landing pages for November and December is available for download to aid analysts in detecting related activity.

Angler Exploit Kit remains one of the most active exploit kits in use. Security analysts can improve their detection success rate by using combined network, analytic, and endpoint response platforms to stay ahead of this fast moving threat.

Fidelis Cybersecurity’s products detect the activity documented in this paper. Additional technical indicators are published to the Fidelis Cybersecurity github.

- The Fidelis Threat Research Team

Year of the Blockbuster: Cyber Wars, The Force Awakens

Tuesday, December 22, 2015
Over the last several months we had the opportunity to engage in many conversations with both customers and IT security leaders about the events

Over the last several months we had the opportunity to engage in many conversations with both customers and IT security leaders about the events happening in the security market. Cyber warfare took new meaning in 2015 and left lethal destruction in its path.  As we wind down and head into the New Year, here are my key observations of the state of cybersecurity and what’s to come. I invite you to comment and share your point of view for an engaging discussion.

  • CISO as Lead Commander.  The role of the CISO has evolved from that of a technologist, focused on the security hygiene of the company, to a critical member of the leadership team. The characteristics that define a world-class CISO are much different today than a couple of years ago. Today’s CISO must not only be a savvy business leader and a great communicator, but also be highly adept at planning and leveraging the organization’s assets to protect their company because – as we saw with Target – failure can cost them their job. They also need to be “ready for the inevitable.” We saw more CISOs implementing a practiced, second-to-none incident response and communications strategy that is integral to handling breaches. CISOs also transformed themselves into becoming better communicators. They now spend 50 percent of their time advising the board and cross functional departments on the company’s security posture. This positive trend insures key c-level executives and boards have the expertise to take appropriate actions in recovering from attacks and building solid security operations.
  • Prepare to Do Battle. The attack surface continues to evolve – and that evolvement is escalating due to the huge growth in cloud, mobility, virtualization and IoT devices. This dramatic change in the attack surface is making it more difficult for companies to prevent their networks and endpoints from being compromised and to protect their data from unknown adversaries. If an attacker wants in, they will get in. What’s important to keep in mind is that the APT is a “who,” not a “what,” and organizations need to be prepared for battle. They need to prevent information theft as well as respond to and remediate breaches quickly. As a result, we’re seeing more organizations shift from spending their security dollars on prevention technologies to investing in early detection and rapid response tools. This trend will continue to accelerate in 2016.
  • Innovation, Automation, Collaboration. Three themes that I keep hearing from customers are that they want best-in-class security, want to reduce the number of security vendors and want talented security professionals (in high demand and short supply). The answer lies in adopting integrated and automated solutions that enable security teams to become better, smarter and more efficient at what they do. It also means deeper collaboration with security vendors and consulting services towards solving common goals and battling adversaries.
  • Encryption Conundrum. As the recent terrorist attacks have sparked fresh debate about the risks of encrypted communications, the issues around encryption will remain in the forefront. More and more traffic is being encrypted to protect data and people’s privacy, but there are risks associated with it. Encryption creates blind spots in network defenses that adversaries use to launch exploits and exfiltrate important data. Policies may change in how we deal with encrypted mobile, voice and data traffic, but until that happens, it’s imperative that organizations seek to implement solutions that detect and respond to hidden threats in encrypted traffic.

In 2015 as we saw attacks escalate and nation states and terrorist groups on the rise, the security industry stepped up their game yet much work needs to be done in executing an unified threat defense mentality and strategy. We’ll discuss more on this topic in future blogs and share how we’re innovating, integrating, automating and empowering security operations.

- Peter George, President and CEO

Arming the Boardroom, Part 2: Know Your Enemy

Monday, October 12, 2015
My last post introduced Fidelis Cybersecurity’s effort to empower board members in their battle against cyber attacks by offering real-world

My last post introduced Fidelis Cybersecurity’s effort to empower board members in their battle against cyber attacks by offering real-world counsel regarding the management of incident response via a NYSE-published cybersecurity guide entitled Navigating the Digital Age: The Definitive Cybersecurity Guide for Directors and Officers. We now take a deeper look at understanding the threat actors and threat lifecycle in order to better anticipate, detect, and respond faster to attacks.

Experts predict that cyberattacks will intensify as cyber criminals accelerate their activities. To make matters worse, attackers have sharpened their skills and expanded their techniques over the last couple of years. Now, cybercrime has advanced to include cyber warfare and cyber terrorism as nation-state actors have moved from disruptive to destructive attacks, presenting organizations with new challenges. Board directors and C-level executives are clearly fighting a war against cyber attacks – but exactly who are they battling? Hacktivists? Organized cyber criminals? Or nation-state actors?

Battles are won by understanding the enemy. This is vital, as motivations among the groups may differ:

  • Hacktivists often seek to cause disruption to damage the reputation of an organization.
  • Organized cyber criminals include international crime syndicates targeting organizations largely in the financial services and retail industries for financial gain. Although there are a number of players, this arena is dominated by loosely knit teams of attackers located in Eastern Europe.
  • State-sponsored espionage threat actors deploy targeted malware in stealthy, multi-stage attacks, sometimes called advanced persistent threats (APT), targeting intellectual property.

Blurring lines of attack

Blurring lines of attack make understanding the enemy even more challenging. It used to be that the tactics employed by Eastern European cyber criminals were relatively unique compared with those used by hackers deploying state-sponsored APT attacks to target intellectual property. Cybercrime experts are now seeing a blurring of the lines of attack, which has caused some forensics teams to misidentify the adversary, slowing the progress of incident response efforts. For example, researchers from two forensics firms investigated an attack on a global credit card processor for two months without success, convinced that it was an APT attack. It wasn’t until the firm brought in a new forensics team that they were able to identify the attack as originating from Eastern Europe and stop the breach.

Directors can gain insight into their adversaries and their motives by examining the way in which peer organizations and other firms within the industry are being attacked. As Rick Holland, VP, Principal Analyst at Forrester Research, advises in 10 Questions To Help Differentiate Incident Response Service Providers, this knowledge becomes especially valuable when engaging a forensics and remediation firm.

“Of the cases they have worked, how many of them are from companies that share a similar threat model? This is a critical question; you don’t want to select a vendor that doesn’t have experience working with threat actors operating against your vertical. It is important to know how a candidate’s experience aligns with your threat model. A firm that focuses on cyber criminals might not be the best provider if your vertical has a history of being targeted by nation-state actors.”

Robust, constant monitoring is key to detection

No network is so secure that hackers won’t find their way in. Today’s threat actors conduct detailed reconnaissance and develop custom malware in an effort to penetrate networks. Once in, they can go for months, even years, without detection. Because deeply embedded hackers can be extremely difficult to eradicate, it’s critical that organizations detect these threats as soon as possible.

Unfortunately, organizations jeopardize their ability to detect threats by failing to fully integrate security solutions into the entire network defense infrastructure. Often security technologies are deployed with default settings, resulting in many false- positive alerts, making it more difficult to dig the serious threats out of all the background noise. And all too often, organizations overlook the human element.

Organizations can’t depend on technology alone to defend networks. Detecting advanced threats requires a risk-management program that includes technology, people, and processes. Within this mix, robust, constant network monitoring is vital to uncovering threats. Because the volume of network traffic combined with increasingly complex networks defies manual threat analysis, organizations often rely on the automated threat-detection capabilities of multiple disparate solutions. Equally important in the defense arsenal is threat intelligence. A dynamic threat intelligence capability helps to ensure that organizations more clearly understand threat actors and their tactics. This positions the organization to anticipate the nature of likely attacks before they occur and adjust defensive strategies.

Board members don’t need to be cyber experts, but they should have a solid understanding of the threats their organization faces. Boards that fail to actively measure and continuously monitor cybersecurity as part of the organization’s strategy will leave their firms open to significant financial, reputational, and competitive risk.

For more information on understanding the threat environment, please download the Fidelis chapter on Detection, analysis and understanding of threat vectors.

Coming next, Arming the Boardroom, Part 3: A Breach Hits, Now What?

-Jim Jaeger

World Leaders Xi and Obama’s Flawed Cybersecurity Agreement

Friday, September 25, 2015
The prevailing opinion, amongst my comrades here atFidelis Cybersecurity, and other notables in the cyberdefense community is thatthis agreementis


The prevailing opinion, amongst my comrades here at Fidelis Cybersecurity, and other notables in the cyberdefense community is that this agreement is flawed, and only a half measure.  This will not stop or slow down the Chinese and their cyberspying campaigns.

Here's my initial take on the agreement below as well as some analysis.

The first, obvious question is "Why should China stop what they have always emphatically denied doing?"  Moving behind this, though, the agreement limits the activities to “intent of providing competitive advantages to companies or commercial sectors”.  This doesn’t prohibit China for conducting cyber-espionage operations to benefit their military and people.  This could include, but not be limited to:

  • Energy exploration and production (particularly if China intends to use the energy on their south) -- think South China Sea.  They could spy on energy companies just to develop a situational awareness of activity around contested regions.
  • Healthcare/drug research particularly since China has an aging populace (that is now increasingly being affected by cancer and related conditions).
  • Transportation and logistics organizations to combat rising traffic and implement new means of moving goods and people across an expanding urbanization effort across China.
  • Higher-education institutions for new research (health, pollution, traffic, etc.) and locations to launch attacks from (which they have done in the past).
  • Military intelligence and theft of IP related to schematics/plans for weaponry.
  • Spying on organizations and companies to understand how they conduct business.  China has conducted these types of "educational reconnaissance" spying operations in the past to understand how to work in a particular industry or field.

I don't expect to see a noticeable slow down of China state-sponsored cyber-espionage. Why would they just close up shop and stop their operations?  They've developed quite a highly-sophisticated methodology and organization to support their missions.  You may even see more of a focus on Asian and European companies.

One thing the agreement doesn't mention is the cybersecurity pledge that China wants foreign businesses to sign?  Are they still going to pursue this?  Time will tell.

One potential scenario if China does choose to slow their espionage operations would be for it to use “proxy” groups, the same way that Iran and Russia operate.  It is easy to hide behind the "Great Firewall". Attribution is difficult with state-sponsored attacks because of the lack of physical evidence connecting the person to the "virtual".  China can always find a patsy within the country, arrest them and claim "mission accomplished" if they're caught by the US on a spying operation.

Another important point to note about this agreement is that even if both sides abided by it, it would never have stopped the OPM breach or their campaigns against health care providers or the defense industrial base.

Actions speak louder than words.  Time will tell if the words spoken in the West Wing are backed up by actions on the front lines of the silent cyber battlefield.

- Justin Harvey

Why are financial services struggling to detect cyber intrusions?

Friday, September 25, 2015
Every major breach targeting financial services organizations involves compromised credentials. Knowing this, one could state that if an organization

Every major breach targeting financial services organizations involves compromised credentials.  Knowing this, one could state that if an organization can ensure that their credentials are not compromised, then they could prevent a breach.  But how do you know if a user’s credentials are not compromised?  The answer is that you can never be 100% sure. So if you cannot prevent breaches you should be prepared to respond to breach activity. Here’s our ebrief and webinar to get you started.

Financial services organizations are especially attractive to attackers because they hold data that enables theft of money.  And this is not only credit card numbers.  In the past ten years, we have seen thieves target databases and point-of-sale terminals to collect mass quantities of credit card data like Jimmy John’s and CVS Pharmacy data breach cases.  As organizations become smarter about securing their PCI data and point-of-sale (POS) terminals, attackers are adjusting their attacks.  Additionally, as banks and credit card companies move to chipped cards, thieves will also adapt to these new layers of security.  The industry needs to be prepared for the next evolution of attack methodologies that will target the financial services industry.

In one example of adaptation, Nigerian “419” scammers have become smarter and adapted to an evolving world.  I remember 10 years ago standing behind a lady at the Western Union counter at the grocery store.  She was upset because she wanted to pull-back a payment she sent to Africa for $2,000.  She said that she had several conversations via email with an individual that promised her money, but she realized too late that they were not trustworthy.  Of course, Western Union was unable to pull the money back.  The lady was distraught and near tears.  I pulled her to the side and told her that she more than likely would never see her money again, but I advised her to contact the local FBI office and report the situation.  Ten years ago, many email users, especially those new to email, were not aware of the threat that existed.

Today, the world (in general) is a little wiser.  So, too, are the thieves.  We all still get the mass money scam emails and I doubt that these will ever go away.  However, the scammers are now using more targeted social engineering campaigns against businesses to get funds wired through multiple banks.  In two cases that happened very recently, a scammer sent an email to an executive of a company complaining that the wire transfer they were supposed to send had not gone through yet – “and what is the hold up!?”  The executive, seeing the spoofed “From” email address as being legitimate, forwarded the emails to their finance department to make the wire transfers pushed through.  In one case, close to $500K was transferred to overseas banks.

As long as money is a motivating factor for hackers, attackers, scammers, and thieves, the financial services industry will continuously be targeted.  New processes and technologies emerge to defend and detect attack attempts, but bad guys will continue to innovate and reengineer their processes and technologies to steal data. Join me on Tuesday, September 29th @ 2:00 pm ET for a Webinar Financial Services: Time to give risk management a voice in cyber security to learn about implementing risk management and defense in-depth strategy to help financial services stay ahead of the adversary.

-Ryan Vela