Phind the Phish - Reducing Phishing Detection from Months to Minutes

Wednesday, March 15, 2017
Every day, attackers tunnel under, sneak through, go around, go over and squeeze past your security technologies. While you’re armed with more


Every day, attackers tunnel under, sneak through, go around, go over and squeeze past your security technologies.

While you’re armed with more security tools than you can count, most of them are hiding a dirty little secret: They actually create more work for people, not less. Security teams are inundated by alerts indicating potential incidents. These products don't come with job requisitions. They do come with alert overload.

Defenders are often unable to quickly validate whether an alert is real or not, mostly because they receive little context – aka useful insight – from each alert. Without context, it’s a challenge to determine the potential impact of an alert. And given the limits of PCAP data, it can often take days or even weeks to retrieve and analyze data about a threat.

But what if you had a secret weapon that provided the visibility and context you need to make a quick decision about the severity of an alert and, more important, understand the context of what was going on before and after that alert?

With metadata, you do. Rich metadata can answer many questions about what’s happening on your network and shift the advantage from the attacker to you.


Possible. And we’ll prove it. In this three-part blog series, we'll use metadata to solve three of your most vexing challenges.

  1. How can I find everyone who received a phishing email?
  2. How do I verify that we haven’t already been compromised by a particular tactic?
  3. How do I detect credentials in the clear?


Phishing emails – A prolific threat …

Attackers have upped the game when it comes to phishing. Classic phishing campaigns used to come with predictable executable attachments disguised as screensavers or an exploit or macro in a Word document. Now, attachments are non-traditional file types, such as Java JAR, Windows Script Files (.wsf) and JavaScript, among others.

Experience tells you that where there's one phishing email, there are many more. To take action, you need to know the full extent of the event – but how do you find all the other emails that you know are out there?

You could call the mail administrator. If you have a good relationship and can reach him, it may be possible to convince him to search for similar subject lines and “from” addresses on the mail server. The problem is that mail administrators lack the tools to easily perform such tasks. Plus, their day job leaves little time to take calls from security analysts. You’re left knowing there’s a problem, but unable to identify which users received the email, clicked on it and may be compromised.

Relax. Rich metadata solves the problem.

Metadata fills in the missing pieces of the puzzle. With metadata, you can easily conduct an incident response exercise to scope the event and gain the context necessary to act on the alert. A glance at the Fidelis Network dashboard indicates a number of malware alerts. Let’s take a look at one of them to see how easy it is to dig through data to find the other emails.

Figure 1. Fidelis Network Threat Life Cycle Dashboard
Figure 1. Fidelis Network Threat Life Cycle Dashboard

Because Fidelis Network captures rich metadata about every event it sees on the network, pivoting from alert to root cause takes only a few clicks. The extensive forensic information provided in the alert detail facilitates and expedites the investigation process.

Figure 2. Alert Detail

Using the one phishing email as a starting point, we begin with the file attachment details. For this event, we find that a .wsf file was inside a zip file and attached to the email. We can also see that the file extension [.doc.wsf] was mangled just enough to possibly convince a user that it's actually a Word document.

Clearly malicious.

image from
Figure 3. File Attachment Details

Moving across the screen, we see details about related alerts, strengthening our suspicions that the email is part of a larger campaign. This information allows us to begin putting context around the alert that will help answer questions such as:

  • Where does the email seem to have come from?
  • What are the dates?
  • When did the user receive them?
Figure 4. Related Alerts Details

Continuing to the right of the screen, the decoding path and channel attributes reveal even more aspects about the event. Here, for example, we see that the sender is masquerading as FedEx.

Figure 5. Decoding Path & Channel Attributes Detail

While we have quickly uncovered a tremendous amount of information about the alert, this is only the beginning. The next step is to pivot from this alert to look for other events in the environment. This is where metadata really shines. Because Fidelis stores rich metadata about every event on the network, it’s a simple matter to perform a search on a component from inside the session.

Let’s revisit that file name. In this case, the attackers intended to fool the user by using a .wsf file with a .doc extension.

Figure 6. Use of .doc.wsf Extension as Attack Tactic

 Using the tactic as search criteria, we perform a search over a one-week period.

Figure 7. Filename as Search Criteria

And what do we find? Subject lines on multiple messages and attachments, all of which, while unique, conform to the same tactic. We can conclude that this is a campaign!

Figure 8. Search Results Reveal Full Scope of Campaign

Without Fidelis, and the rich metadata it captures, it’s a safe bet that you’re relying on the mail administrator to help find the nefarious emails. And it’s equally likely you won't find them. All you’d have is that one email. With Fidelis, it takes a couple of pivots and quick searches. In less than two minutes you're able to find all the phishing emails.

What could be easier?

Did you know Fidelis automates the collection, analysis and storage of your network data so it’s ready for you to investigate immediately? The rich metadata that Fidelis Network captures about every session on your network makes it possible to investigate suspected incidents in seconds – and put the adversary on the ropes.

Ready to cut your detection time down to minutes with metadata? Read our white paper, Talk Metadata To Me: How to Decode Your Network’s Deepest and Darkest Secrets and contact Fidelis today.

This is part one of a three-part blog series about ways to reduce detection time from months to minutes. Coming up: Part 2: Applying New Threat Intel to the Past.

 -- Fidelis Cybersecurity CMO Michael Evans 

Widespread Exploitation Attempts Using CVE-2017-5638

Saturday, March 11, 2017
Many research teams have reported on their observations of exploits involving the use of the Apache Struts vulnerability CVE-2017-5638 since Cisco


Many research teams have reported on their observations of exploits involving the use of the Apache Struts vulnerability CVE-2017-5638 since Cisco Talos published their post on Wednesday March 8. Fidelis Cybersecurity Threat Research is also seeing widespread activity and contrary to some reporting, we're not seeing any reduction in scanning over the course of the day. 

Apache Struts 2 is an open-source development framework for Java web applications. It uses and extends the Java Servlet API to encourage developers to adopt a model–view–controller (MVC) architecture. Apache Struts2 is used to build websites by a wide variety of organizations. Even as the patch was made available earlier in the week, it's a fair assumption that a large number of systems are yet to be updated.

This post captures some of the exploit code we're seeing. Our expectation is that we'll build on the post as more implementations are discovered.



The activity is very reminiscent of Shellshock, in that Apache Struts is open source, mature, widely deployed and often embedded in other packages, both commercial and open-source. Many environments only discover the presence of these packages when they discover exploited systems.

We have two general observations around the activity we've seen:

  1. Mass scanners are typically trying to install downloaders that lead to Windows and Linux versions of DDoS software, typically the BillGates Botnet.
  2. There is more targeted activity clearly going on, often involving reconnaissance of some nature.


Observed Exploits

Building off the original proof-of-concept code

Numerous botnets are adapting code from the proof-of-concept code that was published earlier this week. In each of these instances, there is an attempt to immediately disable firewall functionality followed by the download and immediate execution of a binary.



Update 3/17:



Original Implementations

1. In this one, it looks like the code is printing the root path directory from the exploited server


2. We don't have a good theory for this one other than it represents test code that could eventually be adapted




The wave of threat activity involving CVE-2017-5638 is only just beginning and we're seeing variants that diverge from the original proof-of-concept code starting to emerge. As we see more activity, we intend to share these observations with the community by updating this post.

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,
  • 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 =
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



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

Vawtrak DGA Round 2

Saturday, November 12, 2016
Vawtrak, a.k.a. Neverquest, has been a prominent trojan in the banking world and numerous researchers have reported their findings about this

Vawtrak, a.k.a. Neverquest, has been a prominent trojan in the banking world and numerous researchers have reported their findings about this malware. In August 2016, we blogged about the addition of a DGA to the banking trojan known as Vawtrak. The actors behind Vawtrak reacted to this attention by adjusting their tactics - enough to warrant a change in their DGA implementation. On November 9, 2016 the Threat Research Team at Fidelis Cybersecurity noticed a Vawtrak sample that appeared to be using an updated implementation of the DGA routine.

The sample we analyzed was delivered by using Hancitor embedded in a Word Document with a recently documented technique of being loaded in memory.



While the differences between the DGA algorithms aren't significant, the changes are just enough to throw off our previous analysis.

What stayed the same:

  • Domain length calculation
  • Use of LCG
  • Data locations in inject header

What changed:

  • In the second PRNG call before entering the loop, the routine now uses a parity flag to determine whether it will start with a vowel or a consonant. This is a common trick employed by DGA writers to attempt to make their domains look less like a DGA. The current implementation of this routine uses a weight on the parity. Whenever it hits the block to add a vowel, it makes the next character add 1 or 2 consonants.
  • Another slight update is that for every iteration of the inner loop, it increments the seed. In the case of the sample analyzed here, it does so by a static value of 2.

A side by side comparison makes these differences clear:


Figure 1 Vawtrak DGA new (left) and old (right) comparison

To demonstrate this updated algorithm, we have the supplied Python snippet:

def PRNG(seed):

    seed = (seed * 0x41c64e6d) + 0x3039

    return (seed & 0xFFFFFFFF)

def vawtrak_dga_new(seed, tld, num_domains):

    #Generate domains

    seed_mask = 0x7fffffff

    cons = "cdfghlmnrstw"

    vowels = "aeiou"

    for i in range(num_domains):

        seed = PRNG(seed)

        rem = (seed & seed_mask) % 5

        seed = PRNG(seed)

        parity = (seed & seed_mask) & 1

        rem += 7

        dom = ""

        for j in range(rem):

            seed = (seed + 2) & 0xFFFFFFFF

            seed = PRNG(seed)

            tmp = seed & seed_mask

            if parity>0:

                parity -= 1

                dom += cons[tmp % 12]


                dom += vowels[tmp % 5]

                seed = PRNG(seed)

                parity = ((seed & seed_mask) & 1) + 1



Vawtrak has been a very successful banking trojan delivered via both mass spam campaigns as well as through exploit kits. The developers appear willing to invest time and resources into protecting their bots and C2 infrastructure -- and security teams, researchers and the banking industry should take note.

Decoders created as part of this analysis have been added to Fidelis Barncat.







IOC data:





















Hancitor downloads:














--- Fidelis Cybersecurity Threat Team researcher Jason Reaves

Podcast: How Experts Traced the DNC Hack to Russian Spies

Thursday, October 27, 2016
Bloomberg reporter Jordan Robertson recently sat down with Fidelis Cybersecurity Senior VP Mike Buratowski to discuss the malware and other data that

Bloomberg reporter Jordan Robertson recently sat down with Fidelis Cybersecurity Senior VP Mike Buratowski to discuss the malware and other data that attackers used to pull off the breach of the Democratic National Committee’s (DNC) servers. By examining the clues the attackers left behind, Mike explains how it's possible to attribute the attacks to a specific group of nation-state actors. 

Listen to Bloomberg Technology’s Decrypted Podcast and get the full story.

Want to learn more? Read our analysis of the DNC intrusion malware.


Me and Mr. Robot: Tracking the Actor Behind the MAN1 Crypter

Tuesday, July 12, 2016
With season two of Mr. Robot approaching, the storyline follows a hacker group that takes down an evil global corporation and collapses the financial

With season two of Mr. Robot approaching, the storyline follows a hacker group that takes down an evil global corporation and collapses the financial market. Led by the mysterious Mr. Robot, the hackers use a variety of tricks to evade detection, and seem to cover their tracks at every turn. There are similarities shared by the show's hackers and real-life attackers.

Hackers are human. Like the rest of us, they are creatures of habit, turning to familiar tools and techniques time and time again. As they hone their craft, attackers develop their skills and accumulate knowledge. And while they go to great lengths to hide from view and keep their actions under the radar, they leave tracks if you know where to look. By examining subtle clues attackers leave behind, it’s possible for threat researchers to track malware back to a specific actor.

Malware artifacts provide these valuable clues, serving as tools, techniques and procedures (TTPs) in tracking the ongoing operations of a specific threat actor. In this case, we focus on MAN1, a sophisticated crypter dating back to 2014 that's still used today.

We hope that presenting this research publicly will help researchers pursue similar avenues when following threat actors.


The Actor

Associating an actor to a string of campaigns is never an easy task. Crimeware operates like an underground business -- multiple players may be involved in one project, pieces of an operation may be outsourced to various entities, and elements can be handled by multiple groups over time. In these instances, it becomes harder to prove that the same criminal group is behind a string of malware campaigns.

However, subtle tricks and routines found in packers and crypters provide valuable clues for threat researchers. A crypter, in its basic form, is designed to obfuscate code. In some cases, it's possible to associate actors with their payloads, which allows threat researchers to track the movement of specific actors over time. Given the utility of these obfuscation techniques, actors often keep their tricks of the trade private and do not sell them to the masses on the underground.

One actor, or group, using such tricks is MAN1. We've associated MAN1 with Dyre, a trojan first used in large-scale campaigns targeting customers of major financial institutions and later used to target organizations in additional sectors that include technology, petrochemical and others. The MAN1 moniker comes from the binaries the Dyre malware downloads from compromised websites. These downloaded files usually included a man1.exe file, which was typically an older version of Dyre.


Tracking MAN1

To link MAN1 to Dyre, we had to take a look at earlier campaigns. Before Dyre, these actors used Chanitor to download Vawtrak, a banking trojan. The server delivering Chanitor used “bulletproof hosting,” which are hosting services permitting extreme leniency in their terms of service. Later, this actor gradually began delivering both Vawtrak and Dyre. Eventually, the actor began delivering Dyre exclusively. The servers used at the beginning of this transition hold an important clue to uncover the identity of the actor: These same few servers were also used to deliver Vawtrak using Chanitor.

As with most long-established actors, MAN1 exhibits distinct TTPs in performing their ongoing malicious activities. The crypter discussed here is one such tool used by this actor since its involvement in Vawtrak in 2014, and possibly earlier. While crypters are relatively common, really good crypters -- designed to prevent detection through various methods -- can sell for a lot of money on the underground, where they typically remain private and used for a very long time.

The uniqueness and complexity of the crypter, coupled with the other TTPs used by this group, provides another valuable clue and paints a clearer picture of the actor. Over time, the research community picked up on this actor's subtleties, such as its consistent use of ‘feedweb_data’ or ‘cached_data’ folders on compromised websites. These characteristics made it possible for researchers to track this actor's involvement across multiple malware families over time.


A Timeline of Exploits

Let's take a look at MAN1's activities beginning in March 2015.



March 2015: Chanitor, Vawtrak: By tracing the IP range by naming schemes and crypter usage, we find the actor's first involvement with Vawtrak, when it spammed out Chanitor as a flight confirmation (1) to deliver Vawtrak from

April 2015: Chanitor → Vawtrak, Dyre: In April 2015, we spotted a glaring association with this actor's involvement in both Dyre and the old Vawtrak in a spam campaign (2) that used a macro to download a text file that contained the url to the payload. This technique provides the actor flexibility, in that they can use the same spam campaign to deliver multiple payloads. This technique has one drawback: It needs to burn through extra compromised websites. This campaign had two payloads – one from using Chanitor (delivering Vawtrak) and one from delivering Dyre. The Dyre sample used in this campaign was named ‘man1’. This IP range used can be traced back further -- to Chanitor delivering old Vawtrak -- and was also used for testing the newer Vawtrak seen today.

May 2015: Rovnix, Pony → ReactorBot: This actor has shown interest in using the newest malware within the crimeware domain. In May 2015, a new banker emerged and was distributed using Rovnix as a dropper. The downloaded and loaded dll was named ReactorDemo.dll, eventually known as ReactorBot (3). This actor was involved in a spam run delivering CVE-2014-1761 that exploited RTFs delivering Pony, which would then download ReactorBot from locations such as:


Also in May, we see this actor using a similar naming structure on compromised websites to deliver Dyre, which was identified as a MAN1 campaign within the research community, from macro docs downloading Pony. In this instance, we see one of the compromised website folder structures exhibit characteristics used by this actor:


The /cached_data/ structure is probably familiar to some from frequent Dyre spamming.  Why use the same naming structure on compromised websites? Our guess is that it’s an automated process as demonstrated when you examine the contents of that folder across multiple servers.







November 2015: Dyre, Vawtrak: In early November 2015, we witnessed one of the Dyre actors  transition from Dyre to the updated version of Vawtrak. This actor continued to deliver both Dyre and Vawtrak during multiple spam campaigns on November 2, 2015 (4, 5). The timing of this transition raises suspicions, as it corresponded with a Dyre takedown event later that same month (6). For the Dyre run, we see the /sliva/ structure for the Pony runs (cd445e52eb7d2ca7359a8513157dd0a9), which is still used today for campaigns delivering Vawtrak.

May 2016: H1N1 → Pony, Vawtrak, Nymaim → Gozi: Earlier, on May 25, 2016, researchers observed a spam campaign delivering Vawtrak and using similar techniques. But instead of Chanitor, the loader was H1N1 downloading Pony as pm.dll and Vawtrak as inst.exe.

Also of note is this actor’s recent use of Nymaim from spammed out macro documents dropping Pony (7). These documents would download Nymaim from places such as:


It would then deliver a Gozi/ISFB module targeting US entities*.  This delivery was later coined GozNym due to the custom work linking the Gozi/ISFB module to Nymaim (8).

* A portion of these targets can be found toward the end of this post.

June 2016: H1N1, Chanitor/Hancitor → Vawtrak: Recently, this actor pushed Vawtrak heavily using a variety of delivery methods. Two methods seen recently are H1N1 and a Chanitor variant (also called Hancitor). These campaigns are noteworthy for the MAN1 crypter and the tactics it uses. One such tactic involves delivering Pony separately from Vawtrak, even though Vawtrak comes with a stealer module component. This actor has also been observed using the same Pony gate structure of  ‘/sl/gate.php’ or ‘/zapoy/gate.php’. A recent campaign on June 7, 2016 utilized a Word document dropper using names that followed a pattern of ‘report_\d{7}.doc’ to deliver a Chanitor variant that would check-in to a gate with the uri ‘/sl/gate.php’ and then download both Pony and Vawtrak.

Also of note on these recent campaigns is the man1.exe file that may show up on compromised websites. This can be seen on a campaign from June 20, 2016, in which H1N1 delivered the usual Pony and Vawtrak malware. However, if we look a little closer at the website, it downloads Pony from ('crr-medvezonok[.]ru/about/pm.dll') and we find a number of other executables residing on that server in that same subfolder ('inst1.exe', 'inst2.exe', 'inst3.exe', 'man1.exe'). The executable man1.exe is actually an old unpacked Dyre malware sample -- further pointing to this actor's previous involvement in Dyre.

Latest: To date, the actor continues using the MAN1 crypter. The actor sticks to the same naming scheme for up to months at a time. These consistent TTPs could be due to a number of reasons: The actor may be using a toolkit or buying mass quantities of shelled servers from the same entity and going through them systematically. Either way, by identifying these key characteristics, we narrowed in on an actor’s use of this custom crypter, which then made it possible for us to trace this actor’s movement across multiple malware families over years. We’ve found other notable malware associated with this actor by following the crypter’s evolution over time. This malware includes a P2P Gozi variant, CTB Locker and Andromeda.


Peeling Back the Layers of the Crypter

Researchers commonly have to break through layers of crypters or packers in order to get to the underlying malware code, and it becomes instinctive to experienced researchers. Some crypters used for malware add functions, such as anti-virtualization or anti-sandboxing. The problem with most crypters is that they are a fire-and-forget tool used to bypass antivirus and sandbox detections. Some crypters employ a more drastic technique in which they use multiple layers that involve dynamically generated code. MAN1 is one such advanced crypter.

While it is often tempting to break through all the layers to get to the heart of the malware, our research supports the idea that sometimes these discarded layers can be used to bridge the gap and turn research into intelligence to help profile actors. This proved to be the case with the MAN1 crypter.

In the MAN1 crypter, the first layer is mostly just a bunch of deadcode with limited functionality, but it allows quite a bit of throwaway code to be added. This deadcode can be added for numerous reasons -- from throwing off sandbox reports, to messing with AV heuristics and generally making it a pain to signature off of. Eventually the code will decode the next layer, which is where most of the real work can begin. Usually, this first layer will be XOR decoded, but will be surrounded by a large amount of useless code operating on Windows or fonts that don't exist.






















The second and third layers function roughly the same as the first, with the exception of decoding. The second layer decodes the output of the first layer and the third layer decodes the output of the second.

Each layer shares the following common characteristics:

  • Is numbered
  • Contains variable length, numbered chunks
  • Each chunk may be compressed

To accommodate this setup, each chunk has an attached header as shown in this mock up:

struct DataBlob {

  unsigned short CheckVal1;

  unsigned short CheckVal2;

  unsigned short CheckOffset;

  struct ChunkHeader {

    unsigned int SetNum;

    unsigned int length;

    unsigned int SetIndex;

    unsigned int check;

    unsigned int key;

    unsigned int compressedflag;

    unsigned int uncompressedSize;


  char data[chunk.length];



As the layer performs its decoding routine, it utilizes shellcode that is decoded and reassembled for every chunk in the next layer. This shellcode is then used to decode the data in the found chunk. The same shellcode is used on all layers, but differs from sample to sample. This characteristic leads us to believe it is dynamically generated to perform various types of decoding operations and keys on the layers. By comparing this layer between two different samples delivered on the same day, we can see slight differences. This means the layer is generated when the crypt happens on the payload because it is required to encode the payload.



Here we can see the main loop from one sample employing this technique:





















Getting through the crypter is trivial.  Breaking on kernel32!VirtualAlloc results in returning to the main loop of the layer as each calls VirtualAlloc every time it goes to reconstruct the shellcode layer. Adding a breakpoint to the end of that loop (the instruction just after kernel32!VirtualAlloc) presents the next layer.  From there, execute ‘till return’ twice and then the next call will copy over the reconstructed code segment and a JMP.



Intimate knowledge of the crypter and other techniques have allowed us to tie numerous campaigns over the years to a single actor. We're aware that other researchers have identified some of these threads and our intention behind publishing this body of knowledge is to encourage others to recognize MAN1 and help build a fuller profile. The criminal landscape is vast, but there are often significant volumes of activity spanning campaigns and malware families that tie back to individual actors.

IOCs are available on our Github at


-- Fidelis Threat Research Team researcher Jason Reaves












Nymaim Gozi Module Targets:


Findings from Analysis of DNC Intrusion Malware

Monday, June 20, 2016
The Security Consulting team here at Fidelis specializes in investigations of critical security incidents by advanced threat actors. Last week, after


The Security Consulting team here at Fidelis specializes in investigations of critical security incidents by advanced threat actors. Last week, after Guccifer 2.0 claimed responsibility for the intrusion into the Democratic National Committee’s (DNC) servers, we were provided with the malware samples from the CrowdStrike investigation. We performed an independent review of the malware and other data (filenames, file sizes, IP addresses) in order to validate and provide our perspective on the reporting done by CrowdStrike.  This blog post provides a summary of our findings.

Many of you may be following the recent news related to the compromise of the Democratic National Committee’s servers that was first reported by our colleagues over at CrowdStrike in a blog post published on June 14, 2016. Their post attributed the incident to Advanced Persistent Threat (APT) actors associated with the Russian Government named COZY BEAR and FANCY BEAR. The following day, the story got all the more interesting when an individual using the moniker Guccifer 2.0 claimed that CrowdStrike got it wrong and that he had, in fact, been the one to penetrate the DNC’s servers.

We have helped hundreds of organizations deal with similar situations so we know the latest tactics, techniques, and procedures (TTPs) exceptionally well. Our analysis relies on the intelligence repository we have built through this analysis as well as Open Source Intelligence to substantiate our findings.

Before we proceed to the details of our analysis here’s a quick cheat sheet on different names that security researchers have used to refer to these threat actors. However, it’s important to note that actor mappings between attribution sets aren't precise. Different research methodologies and necessarily separate encounters with these actors lead to unique attribution sets. The overlaps noted here are commonly accepted.




As part of our investigation, we analyzed the same malware files that were used in the DNC incident. Here are a few highlights of our findings from reverse engineering the provided malware:

1. The malware samples matched the description, form and function that was described in the CrowdStrike blog post.

2. The malware samples contained complex coding structures and utilized obfuscation techniques that we have seen advanced adversaries utilize in other investigations we have conducted. This wasn’t “Script Kiddie” stuff.

3. In addition, they were similar and at times identical to malware that other vendors have associated to these actor sets.

a. For instance, in one of their Unit 42 blog posts Palo Alto Networks provides some detailed reversing and analysis on other malware that they attributed to COZY BEAR named “SeaDuke.” The Fidelis Reverse Engineering team noted that in the samples of “SeaDaddy,” that were provided to us from the DNC incident, there were nearly identical code obfuscation techniques and methods. In fact, once decompiled, the two programs were very similar in form and function. They both used identical persistence methods (Powershell, a RUN registry key, and a .lnk file stored in the Startup directory).

b. The SeaDaddy sample had a self-delete function named “seppuku” which was identified in a previous SeaDuke sample described by Symantec and attributed to the COZY BEAR APT group. It’s worth noting that seppuku is a Japanese word for harakiri or self-disembowelment.

c. For the X-Tunnel sample, which is malware associated with FANCY BEAR, our analysis confirmed three distinct features that are of note:

i. A sample component in the code was named “Xtunnel_Http_Method.exe” as was reported by Microsoft and attributed by them to FANCY BEAR (or “Strontium” as they named the group) in their Security Intelligence Report Volume 19.

ii. There was a copy of OpenSSL embedded in the code and it was version 1.0.1e from February 2013 which was reported on by Netzpolitik and attributed to the same attack group in 2015.

iii. The Command and Control (C2) IPs were hardcoded into the provided sample which also matched the Netzpolotik reporting.

iv. The arguments in the sample were also identical to the Netzpolitik reporting.

4. The malware samples were conspicuously large (1.9 MB for X-Tunnel and 3.1 MB for SeaDaddy) and contained all or most of their embedded dependencies and functional code. This is a very specific modus operandi less sophisticated actors do not employ.

So what does this mean? Who is responsible for the DNC hack? Based on our comparative analysis we agree with CrowdStrike and believe that the COZY BEAR and FANCY BEAR APT groups were involved in successful intrusions at the DNC. The malware samples contain data and programing elements that are similar to malware that we have encountered in past incident response investigations and are linked to similar threat actors.

In addition to CrowdStrike, several other security firms have analyzed and published findings on malware samples that were similar and in some cases nearly identical to those used in the DNC incident. Many of these firms attributed the malware to Russian APT groups.

That brings us to the issue about Guccifer 2.0’s claim of responsibility for the attack. Several researchers have raised questions about the allegedly stolen documents posted by Guccifer 2.0. Ars Technica reported similar findings that align with some of our initial analysis on this topic.

While we believe this settles the question of “who was responsible for the DNC attack,” we will continue to watch, along with the rest of the security community, the new twists and turns this story takes as the U.S. presidential elections swings into full gear.

- Michael Buratowski, senior vice president, Security Consulting Services


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