Fidelis Cybersecurity is proud to support the Wall of Sheep (WoS) at Def Con 2016, but this Wall needs to come down.

Over the past several years, it's been standing-room only for WoS participants. This year's event promises to be even more spectacular. For those who need background, the'sheep' on this wall are users whose internet traffic reveals their credentials (user names and passwords) passed in the clear, for prying eyes to see.

The exercise starts as users sign on to the conference’s free wireless network. A copy of that traffic is given to participants whose job is to analyze that traffic, spot those credentials and report them to WoS organizers. When they're satisfied with the data presented, the credentials (with the passwords obscured) are posted to the 'Wall' - a giant screen in the Packet Hacking Village.

Aries Security runs this much-anticipated annual event. For the past four years, we have had the honor to sponsor 'Packet Detective', an exercise focused on network forensics techniques. Each year, we host a friendly team that competes using Fidelis Network™ to look at and analyze traffic.

It's been very interesting to see what traverses over the Wi-Fi network. Here are some key findings:

1. Protocols that inherently transfer credentials in the clear, like POP3, IMAP and telnet, continue to be used in volume. The practice appears to be trending downwards, mostly thanks to more awareness around this activity.
2. Some applications that use these protocols, particularly those built into mobile devices, have forced the adoption of SSL, supporting the positive downward trend cited above.
3. However, lots of users continue to use insecure applications to access sensitive data.
4. Users are often oblivious to the risks associated with such exposure, often using what are clearly credentials from their professional lives to connect on what should be considered a hostile network. Many professionals clearly transfer sensitive data --their own as well as data belonging to others-- using insecure applications.
5. The proliferation of applications on mobile devices, as well as Internet-of-Things (IoT) devices, like wearables, is leading to massive data and credential leakage. Citizen Lab reported on this quite extensively and it's certainly been noticed by our researchers.
6. Applications on mainstream devices also exfiltrate data, as we recently highlighted with the Maxthon browser.

While a user whose credentials are captured and displayed at the Wall might feel somewhat embarrassed, the exercise is aimed at drawing attention to the fact that this could happen to anyone, on any network – Wi-Fi at the coffee shop or airport, the university, businesses you visit and even on your home ISP.

The WoS event helps drive awareness of the dangers of credentials in the clear. It’s important to us, to get this message out. Our goal is to inform every user and secure every application so that all credentials and sensitive information are hidden from people intent on causing you harm. We look forward to the day when the systems and applications we use are safe. Our personal information and privacy is protected when transferring data. When that happens, and not a day before, we can take that wall down. Dear Internet, Let’s Tear Down This Wall!

Fidelis Cybersecurity will be at DEF CON 2016 and the Wall of Sheep! Come by and say hello. Meet our threat experts at the following sessions:

To Catch an APT: YARA
Saturday, 8/6, 10:10 am, Packet Hacking Village, 26th floor, Bally's Indigo Tower

Jay Dimartino, senior threat research engineer, shows how to hunt for APT armed with the pattern matching Swiss knife called YARA. Learn how to author YARA rule signatures with techniques used by malware researchers to mercilessly hunt down elusive adversaries, and discover patterns in their code.

Mining Virus Total for Operational Data and Applying a Quality Control
Saturday, 8/6, 5:10 pm, Packet Hacking Village, 26th Floor, Bally's Indigo Tower

Gita Ziabari, senior threat research engineer, will discuss techniques to achieve improved and actionable threat intelligence with VirusTotal. Her talk will cover how operational data sets can be obtained using specific APIs, algorithms and source code.

OPSEC Concerns in Using Encryption
Sunday, 8/7, 12:00 pm, Crypto & Privacy Village, Bally's Bronze 2

John Bambenek, Fidelis Manager of Threat System, will cover OPSEC concerns with using crypto (and when not to use it). The talk will also provide an overview of a no-cost tool available to security researchers for random generation of self-signed certs.

See you at DEF CON!

- Fidelis VP of Threat Research Hardik Modi

For several years now, the Vawtrak trojan has been targeting banking and financial institutions, most recently in Canada as reported last week. The Fidelis Threat Research team recently analyzed a new variant to Vawtrak using HTTPS for C2 communications. Given what we've seen previously with Vawtrak, simply switching to HTTPS is not a major update in terms of development -- but it does show that the threat actors are interested in protecting their C2 communications.

Here are some significant updates to Vawtrak:

• The malware now includes a DGA. Interestingly, it utilizes a pseudorandom number generator (PRNG) used in Vawtrak's loader.
• The DGA hosted site further serves up a list of domains that are cycled through for C2. In this respect, Vawtrak now has a 2-tier C2 discovery infrastructure.
• It also includes SSL certificate checking (aka SSL pinning), allowing it to evade scenarios in which an SSL man-in-the-middle is present. These solutions are typical in enterprise environments.

Vawtrak has been a very successful banking trojan delivered via both mass spam campaigns as well as through exploit kits. Considering this, it's not surprising that actors are adding new features. While the use of DGAs and TLS is widespread across various crime families, SSL pinning is still rare.

PhishLabs recently discussed their observations around Vawtrak's DGA. This blog post covers our reversing of the DGA algorithm and the SSL pinning implementation.

The samples analyzed in this post are:

28July2016

Packed:

SHA256: 6f9727385d3bf55e1d57fe7606999db2bc29f21b7f9d1d3fa7073218d73ac28d

Unpacked:

SHA256: 721b673777b927146b1a62fd2079f726624b3e7c789d6f04e5ccd6f122d44e2d

1Aug2016

Packed:

SHA256: a513fc3dd36d24ea9fd17596607278aa47a03b67a3c09aff72fc2a8b8a9e0636

Unpacked:

SHA256: 37cf565b8ee6db67b11f2a084a11e30e14bfc8439c462270d01d50bdbae0ea61

Loader

The loader for Vawtrak, which has been updated numerous times over the years has one purpose:  To load the injected code that it keeps encoded and compressed in its RCDATA named resource. This data is decoded in a manner consistent with what we would expect from Vawtrak, using a PRNG known as Linear Congruential Generator (LCG) after which the data is then LZMAT decompressed to give us what you might call the initial inject. This inject contains just about everything needed by Vawtrak: The header, which historically has had a number of flags; the URI and domains to use; and, along with the header data, code for handling the injection process for the DLL (which is also included in this initial inject in both 32-bit and 64-bit form).

DGA

A broad overview of this new Vawtrak initial C2 system shows that a domain is generated, and then connected to and certificate validated, by the bot. If this fails, then the bot sleeps and continues N number of times:

The first action taken is a domain generation. This is done by using a seed found in the initial inject header and a tld which has, until now, been static - always ‘.ru’.

Figure 1: Vawtrak Generate Domain

The routine takes a seed and passes it through the LCG once, dividing the result by 5 and using the remainder + 7 as the length of the domain to be generated -- which means our domain lengths fall within the range of [7,12] in length (not counting the TLD). Once the length is determined, the result of the previous PRNG is passed into another. The result is converted to a character using the formula ((result % 26) + 97). Some example python code follows:

    seed_mask = 0x7FFFFFFF

    seed = PRNG(init_seed)

    rem = (seed & seed_mask) % 5

    rem += 7

    out = ""

    for i in range(rem):

        seed = PRNG(seed)

        tmp = (seed & seed_mask) % 0x1a

        out += chr(tmp + 0x61)

    print(out+'.ru')

SSL Pinning

This new Vawtrak DLL contains code for performing an HTTPS connection as well, but it also performs some checks on the certificate it receives from the C2 server. It adds up all the characters in the Common Name and then divides the byte by 0x1a and adds 0x61, which should match the first character (Figure 5). It also uses a public key from the aforementioned initial inject header to verify the signature hash that was passed in the SubjectKeyIdentifier field of the certificate.

Figure 2: Connect over 443

Figure 3: Vawtrak Request setup

Figure 4: Vawtrak turn off cert validation and send request

In Figure 2 and Figure 3, we can see the bot setting up the HTTPS request; it is very particular to turn off as many certificate validations as possible in the options. The flags for HTTPOpenRequest are:

 (INTERNET_FLAG_SECURE | INTERNET_FLAG_NO_CACHE_WRITE | INTERNET_FLAG_IGNORE_CERT_DATE_INVALID | INTERNET_FLAG_IGNORE_CERT_CN_INVALID) while the flags for the InternetSetOptionA in Figure 4 are (SECURITY_FLAG_IGNORE_CERT_DATE_INVALID | SECURITY_FLAG_IGNORE_CERT_CN_INVALID | SECURITY_FLAG_IGNORE_REVOCATION | SECURITY_FLAG_IGNORE_UNKNOWN_CA | SECURITY_FLAG_IGNORE_WRONG_USAGE).

After the request is sent, the bot goes into checking the certificate along with decoding the RSA public key from the initial inject header.

Figure 5: Vawtrak CN check

Decoding the header

We’ve talked a lot about a header on the initial inject, because it contains a lot of information that we are now interested in. After mapping out how these values are parsed, and then subsequently used, we can discern the following structure of this updated Vawtrak.

struct Vawtrak_Hdr {

  int total_length;

  int header_length;

  int offset_to_first_mz;

  int offset_to_second_mz;

  int project_id;

  short unknown;

  unsigned char exe_or_dll_flag;

  int rsa_seed;

  char rsapubkey_block[148];

  int dga_seed;

  int num_domains;

};

There are other data and flags that have yet to be discerned from this header, but this allows us to accomplish a number of things -- such as pulling out the embedded DLLs, tracking the project ID, harvesting the RSA public keys and generating the DGA domains the bot uses for initial communications. This entire process can be seen in python code on our github.

To further complicate this new C2 hand off, the developers have added another section -- near the top of the module URLs in the Vawtrak config -- which when decoded will have a list of C2 domains that the bot will also use for C2 communications. To accommodate this new section, the developers added a command to the C2 data parsing section. This command is 41, which is the highest-numbered command at the moment.

struct CMD_41 {

  int total_length;

  char signature[0x80];

  int seed;

  int length;

  char c2s[length];

}

Once decoded, the C2s are a collection of structures with length and C2 string. Creating a Vawtrak config parser now just becomes a matter of parsing the sections and looking for the commands we are interested in -- such as the webinject config (CMD 2), the C2 domains (CMD 41) and the modules  (CMD 3). To help demonstrate this, we have supplied python code on our github.

Conclusion

Vawtrak has been a very successful banking trojan, delivered via both mass-spam campaigns as well as through exploit kits. Keeping this in consideration, it's not surprising that new features and techniques are being introduced. The use of DGAs and TLS is widespread across various crime families, but SSL pinning is still rare.

To access the python scripts referenced in this post, please visit our Github repository. Decoders created as part of this analysis have been added to Fidelis Barncat.

-- Jason Reaves, Fidelis Threat Research

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.

Crypter

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.

Loader

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.

Figure 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

Modules 

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.

References:

• http://www.kernelmode.info/forum/viewtopic.php?f=16&t=3381&hilit=dyre
• https://blog.malwarebytes.com/threat-analysis/2015/11/a-technical-look-at-dyreza/
• https://www.blueliv.com/downloads/documentation/reports/Network_insights_of_Dyre_and_Dridex_Trojan_bankers.pdf

Indicators:

TrickLoader Hashes:
a4dfd173610d318acb4784645cf5e712d552b51d0c8cf10b2c4414d0486af27d
f26649fc31ede7594b18f8cd7cdbbc15
aef4293a36fd3538ff1986a27fec8d7461ec9ced76fb035ae85f53e178109570
80833a25e57130a8e0be9bb5debde7ae
721cc1bbe4a6ebd1a417a064f95743568e8992028340c070dd5f159fe79f8ddf
6250e7bff472fd184819b976a5953b8d
4c5bdb9dcf1348e3263e03d1f0da8db7a37c9f9deddd845a02e49481c01ccd74
d94d858859408f8ab82e2b9a42d00700
198efe2f386515ba82e72d09081f0336114b128ee1d617484f0577388b62c219
ad62ee05f8691706be1f4b5a672731ac
65084d73b23728c2f3f3401769cc1f905ec26506b63886dd530a5a554156e90d
ab4d591d294673ce7ea1c1517dc0a54f
9f8e1cdd9542f31833318d966109a29f9798e051a7f8887f140a37ca909442d4
d28be15020d54647023a75ba5f2845af
6eccaf6e907693976b4f99a3c44b7066a4df9cce4d1775f686dbb62bae29f8be
e4a8dc8fd08d4f65a68d0a40e2190c70
cb5ec9a3e30a50f8eecc65c88948446a7f0c1a7cb633483596738f15c2f399c3
0804499dba4090c439e580f5693660e0
919660bd3ff450996744dbacf1730762e5ab998223883030f157f5a84902c56d
bf621ef7e98047fea8c221e17c1837b8
edcfa1ebba218fef31113b6ce16724ec4d8836439e26899ec11cddee848436bd
38503c00be6b7f7eeb5076c0bd071b4c
 
 
Pushdo with same crypter:
a2424ac280ba8c9344ed37e254394cd21014e0c027b4f1932421717b8255dbf2
829708246ef66e4fc16fdc5f184dea2e
158e1a57aaec3bba92e16995a00a1627c5194a90d980a1caf0f5b8c38c4d15b9
f12fb808815a36f768028238101e5916
 
Trickbot C2s:
188.138.1.53:8082
27.208.131.97:443
37.109.52.75:443
91.219.28.77:443
193.9.28.24:443
37.1.209.51:443
138.201.44.28:443
188.116.23.98:443
104.250.138.194:443
46.22.211.34:443             
68.179.234.69:443
5.12.28.0:443
36.37.176.6:443

91.219.28.103/response.php

Config Targets:

cibconline.cibc.com

anz.com

banking.westpac.com.au

ib.nab.com.au

ibanking.stgeorge.com.au

/onlineserv/CM

-- Fidelis Threat Researcher Jason Reaves

Quick! What do you do when you think you’ve been compromised?

It’s not a trick question (or the beginning of a bad joke). To investigate, you’d probably look for historical information that you could easily put your hands on. Usually that means pulling logs and NetFlow data to try and understand what’s going on. While these can be helpful, they are simply not enough. You need more contextual information about what was going on before and after event. And that data doesn’t exist in logs and NetFlow. So where can you turn?

The answer? Metadata. Metadata is data that describes other data. And while it may not sound sexy, metadata gathered from your network can be a powerful ally in the battle against cyberattacks. Now, when “metadata” comes up in a security conversation, nine out of ten people will assume you’re talking about NetFlow. But we’re not. We’re talking about rich metadata that’s so rich you can use it to ask – and answer – detailed questions you could never imagine.

In fact, you can do seemingly impossible things with the right metadata. And if these examples sound interesting, consider the webinar I recently did with Hardik Modi, our VP of Threat Research: 3 Ways to Reduce Detection Time from Months to Minutes.

Impossible Task #1. Find everyone who received a phishing email in 2 minutes instead of 2 days.

You’ve received an alert about a phishing email – and where there is one, there are likely many more. You must move fast before users start opening and clicking on emails. But how do you find all the other emails? You could call the mail administrator and get them to search the server for a similar subject line or “from” address. Yet they often lack the tools to easily perform searches and they’re busy. You’re left knowing there’s a problem, but can’t identify which users received the email, clicked on it and may be compromised.

With rich metadata, it’s easy to quickly locate similar messages. With one search, you can understand the full scope of the problem. Now when you reach your mail administrator, you’ll have the contextual details required to resolve the issue.

Impossible Task #2. See if a new vulnerability was exploited in under a minute.

What if a high-profile data breach generates headlines and a new zero-day exploit, campaign or malware is uncovered. Your CEO wants to know, “Can it happen to us? Are we covered?” You can't help but hear the theme song from Mission Impossible playing in your head as you promise to look into it. Your security team subscribes to myriad threat intelligence feeds that help you detect future events. When you get fresh intel, how do you verify that you haven’t already been compromised by a particular tactic?

Metadata can help. By leveraging stored metadata, it’s easy to do a backward search on specified criteria and get a handle on the events that have already taken place in your environment.

Impossible Task #3. Find “man-in-the-middle” attacks.

Your organization’s data transmissions are confidential. Are you sure? Think again. Just because data is encrypted using SSL and HTTPS doesn't mean that it can't be spied on. 

Using a man-in-the-middle attack, malicious actors slip between you and the server. You think you’re talking to a secure server, but you’re actually talking to a spy computer that’s intercepting the transmissions. With full access, the malicious actor can capture, send, restrict or alter confidential data meant for someone else.

Metadata can come to the rescue. Leverage metadata to zero-in on these attacks and identify instances where network traffic is being diverted from its intended path.

Impossible Task #4. Find everywhere that weak encryption is used in the network.

Your organization encrypts all network traffic to protect the privacy and confidentiality of data as it travels from the source to its destination. But encryption keys have a shelf life. You know that you’re going to have to change them at some point. If you thought keeping up with the Kardashians was difficult, try keeping up with expired SSL certificates.

Metadata makes it easy. By monitoring every SSL transaction and storing the metadata, you can easily search for SSL headers to locate weak and expired certificates.

Impossible Task #5. Know where all of your sensitive data is going – both inside and outside your organization.

Just like the dog that manages to squeeze under the fence, data seems to have an uncanny ability to sneak past the guards. You have to worry about sensitive data that’s leaving the organization as well as the data travelling across your internal network.  

With a quick metadata search, you can find and analyze all sensitive data traveling across the network, including who sent the data, where it went and how it was sent.

Coming up: Ten Impossible Things You Can Do with Metadata, Part 2.

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 gives you answers to questions that were previously impossible to know.

Ready to do impossible things with metadata? Read our white paper, Talk Metadata To Me: How to Decode Your Network’s Deepest and Darkest Secrets and contact Fidelis today.

-- Fidelis Cybersecurity CMO Michael Evans

Deception and crime go hand in hand. But knowing when you’re being deceived means you need to think like the bad guys and know what to look for.

There are three elements of deception. To see these elements in action, we need look no further than a few notable cases -- including the alleged Russian state actors behind the DNC and DCCC breaches as they continue to dump documents intended to influence the upcoming U.S. election.

Let’s take a look at the three elements of effective deception.

1. Plan and Prepare

The key is to create a storyline that’s mostly true – and that requires research. Research makes it possible to understand both the target of the deception and its target audience. Before fabricating communication between two parties (perhaps with the intent to leak information), your research must indicate they are likely in contact in the first place. All of the other elements of style must match too, or the deception will be revealed. 

As an example, I use Domain Generation Algorithm-based malware to track command-and control-servers.  Attackers know this kind of surveillance is done, so some of them try to camouflage their C2s to look like sinkholes and security researchers. They research what headers or fingerprints are used, what malware families they are interested in, and other data so they can craft an operational plan to make their C2 look like a security researcher.

2. Craft a Narrative That Is Credible -- but False

You need a carefully crafted narrative that’s believable. A plausible narrative will play into the biases of your target audience. It also involves finding an environment where deception can thrive. For example, rumors about politicians are so effective because people are already predisposed to think poorly of politicians.

Most deception can be detected easily when there is readily available information to verify its authenticity. For example, the Syrian Electronic Army once hacked the Associated Press Twitter account and planted a false story about an explosion at the White House. Hilarity did not ensue. This graph of the Dow Jones index (from The Washington Post) shows the immediate impact of this one tweet.

The markets saw a precipitous drop for 5-10 minutes. Trading returned to normal almost immediately once the hoax quickly came to light. After all, the “explosion” could immediately and easily be deemed a hoax with no lasting impact.

3. Deceive in Moderation

Use deception only when it counts. Dump lots of false narratives and the source will eventually (and quickly) lose credibility. Once we spot a pathological liar, we never trust anything from them again – even when it’s true. For example, if the Podesta emails that mention extraterrestrial intelligence were obviously false, the entire document dump would be discarded.

These three elements can be helpful in figuring out what will happen in the wake of the alleged state-sponsored document dumps. Assuming the leaks are from Russians and this is, in fact, a propaganda operation, the adversary knows how to deceive and does it well. They’ve done the research, they’ll choose a narrative that is mostly true and hard to disprove. Then, they’ll lie only when it really counts and the deception will be contained in a dump of mostly real information.

So what would the ramifications be? Time will tell, but if the actors are potentially trying to affect the outcome of the election, they’ll know the retaliation for the attack could be severe if the target, Secretary Clinton, becomes president.

-- John Bambenek, Manager, Threat Systems

Network Intrusion Prevention Systems have been a mainstay of the network security stack for well over a decade. When they first entered the mainstream in the early 2000s, the iPhone hadn't been invented. We were still in the age of the PalmPilot (anyone remember using that stylus?). But, at the time, IPSs represented real innovation. They were a welcome departure from the classic firewall, which was limited by its primitive accept-and-deny rules that were inadequate for the more sophisticated attacks to come.

IPSs were a breath of fresh air. They came with new detection languages, like Snort. They could operate on high-speed networks, apply rules to provide visibility on the network and, eventually, they could even block sessions that matched those rules. It was great at the time. So what went wrong?

Complacency.

Much like the rapid innovation of the iPhone, there’s also been tremendous innovation in the security industry, and attackers have been evolving their tactics to keep pace.  But the IPS lives on, largely unchanged in scope or capability for five years or more. You could say it’s stuck in a time warp.

It’s actually pretty stunning when you consider these major shifts over the past decade in the cat-and-mouse game that is security:

• Protocol and application stacks have hardened, so the deep-packet inspection techniques that traditional IPSs use to identify exploits against these layers have become less relevant.
• With a few simple tweaks to their exploits, adversaries can bypass signatures that are often written for proof-of-concept exploits rather than addressing the underlying vulnerability. Signatures for both Heartbleed and Shellshock vulnerabilities were endlessly updated to map to the latest exploits that were observed. Clearly, the research teams involved deserve kudos for their vigilance, but it points to underlying issues with the packet inspection engine.
• The exploits attackers use have shifted from servers to clients. Enterprise intrusions more often involve web exploit kits and documents delivered by email to users. Security professionals have faced an ongoing struggle to cover the breadth and variations of these tactics.
• Your biggest vulnerabilities aren't unpatched applications -- they’re humans. And humans can't be patched. Ransomware, as well as breaches involving users accessing sites spoofing their OWA or VPN login page, are legion. Likewise, most ransomware has been delivered via email over the past few months and hasn't even involved exploits. They rely on unusual file types like hta or wsf bypassing classic email protection layers and tricking unsuspecting users to click on a file or enable a macro.
• Traditional IPSs continue to ingest threat intelligence in the form of Snort rules, Or, in a best- case scenario (with great labor), they may also use reputation lists for basic fields, such as IP addresses and URLs. But experts have long recognized the sheer futility of this. Today’s most valuable threat intelligence is shared in modern formats, like Yara rules that can be applied against content and less easily morphed fields like certificate hashes.
• While "preventing intrusions" was the core value of the original IPS, a secondary benefit was often the visibility it provided into activity on the network (though skeptics might argue that this was just a way to justify the large volume of alerts IPSs generate). Traditional IPS solutions generated limited flow data. And, as enterprise networks have evolved, that data, which they archive in the SIEM, has become increasingly less interesting. What's far more interesting (and relevant) are content flows. Why is that self-signed executable on its way to my Domain Controller? Why do I have so many documents marked 'confidential' leaving a specific remote office? Answers to these types of questions are essential to situational awareness, and today the IPS simply cannot answer them.

Which brings us back to the title of this blog. Would you re-hire your IPS today? Why do thousands of organizations continue to deploy and maintain their legacy IPSs at great expense, even as the value it offers continues to shrink in the face of innovation? The only answer I can think of is: habit. We've always done it. So we continue to do it. Sure, IPSs are incorporated into standards such as PCI and there may be compliance-driven reasons to deploy them. But if you ask most security practitioners what role traditional IPSs play in actually securing their enterprise, the answer would be "little to none". While there are a few classes of threat activity where packet inspection continues to be a useful approach, the reality is that other products in the network stack have absorbed this trivial function.

So, if the traditional IPS isn't pulling its weight in your security stack, what should you do about it? That's exactly what we'll be exploring over the coming weeks. Up next are specific examples of how some organizations are evolving their approaches.

-- Hardik Modi, VP, Threat Research

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.

Metadata gathered from your network can be a powerful ally in the battle against cyberattacks. In fact, you can do seemingly impossible things with the right metadata. In Part 1, we explored how metadata can help you spot phishing emails, find man-in-the-middle attacks, locate weak encryption and more. In Part 2, we take a look at five more seemingly impossible tasks.

If these examples sound interesting, watch the webinar I recently did with Hardik Modi, our VP of Threat Research: 3 Ways to Reduce Detection Time from Months to Minutes.

Impossible Task #6. See lateral movement within the network.

If there ever was an asymmetric fight, it’s between cyber bad actors and security pros. Not only does the attacker have to succeed only once at getting a foot in the door, but they also have all the time in the world to establish a foothold and move laterally throughout your network. They can be in your environment days, weeks or even months before you know you’ve been compromised.

Meanwhile, you’re left playing whack-a-mole with way too many alerts. When you do get time to hunt for threats, you’re left to rely on high-level Netflow information, which lacks context and is often hampered by encryption. At best, you can make an inference about lateral movement activities. You have a better chance of finding Dory.

What you need is the granular visibility into what’s happening on the network and the endpoint. With rich metadata, you can track attackers through the network, reconstruct their activities and remediate the intrusion.

Impossible Task #7. Contextualize and prioritize an alert.

Question: What’s worse than getting an alert that your network is under attack?

Answer: Jumping into action without the necessary context about the alert and its severity.

It’s human nature to want to take action when you get an alert. But without context, how do you know what action to take?

Discovering the root-cause of an alert is critically important to prioritizing actions so you can take a proactive defense posture. Without understanding the “why” of an alert -- including what occurred before and after -- it’s likely that you’ll find yourself detecting the same issue day after day on numerous machines. This increases the time spent on detection and remediation.

How can you get deep visibility into what’s happening and context around the alert? The answer, once again, is metadata. Rich metadata provides a historical view of all network communication – protocols, applications and content – providing the context required to understand events taking place on your network.

Impossible Task #8. See a historical view of remote desktop sessions.

They say it’s impossible to love and hate something at the same time, but with Remote Desktop Protocol (RDP), you might make an exception. While RDP serves a variety of purposes ranging from remote systems management to administrative support, in the wrong hands it becomes a remote-control weapon enabling bad actors to step in and take control of your network. Once hackers locate remote desktop applications on a victim’s computer, brute-force entry becomes a simple matter.

Figuring out who exactly is going through your network using RDP (or Chrome Remote Desktop, TeamViewer or any other remote protocol) can be a tedious task requiring tools, examining multiple logs and reviewing past events. If the server has been re-imaged, you can say goodbye to any record of access.

The hero, yet again, is metadata. More nimble that full packet capture, rich metadata containing details about every network session makes it possible to easily analyze activity and trace threats back to their source.

Impossible Task #9. Know when your applications are lying to you.

It’s Halloween, so here’s a freaky thought. Programs that seem to be legitimate – but aren’t.

Users install software onto endpoints at home and work, but we’re not always verifying the code is doing what’s purported to do. (Remember all the problems with rogue security software?) Now you’ve gotten wind of malicious data capture happening through installed applications. Case in point is the Maxthon web browser, developed by a company in China, which on the sly wraps up your entire browsing history into an encrypted DAT file, zips it up and sends it back to China in real-time.

Here’s a scarier thought: Maxthon was found to be transmitting information about the user’s operating system, installed applications and browsing habits. Essentially, it captured almost everything an attacker needs to know to create a perfectly crafted spearphish campaign or watering hole attack.

Visibility into both the network and endpoints can be a challenge, but you have metadata. Much richer than network packet captures or traditional Netflow data, metadata has the power to reveal the indicators and attributes about transport and protocol applications as well as file objects in transit on the wire. This detailed information contains all the necessary descriptors to quickly identify and react to malicious traffic and objects during an investigation.

Impossible Task #10. Detect credentials in the clear.

If an attacker is going to break into your system and steal your credentials, they should have to work really, really (and we mean really) hard to succeed. That’s why credentials in the clear are so frustrating.

Protocols that transfer credentials in the clear, like POP3, IMAP and telnet, continue to be used. Oblivious to the risks associated with such exposure, users continue to jump on unsecured Wi-Fi -- at the coffee shop, airport, business or even on a home ISP -- and log in with personal and professional credentials. In many cases, it’s easy pickings for attackers to pluck usernames and passwords in the clear.

Impossible to detect credentials in the clear? Not so with metadata. Visibility is exactly what you get when you capture rich metadata. And with that visibility comes peace of mind that not only do you know what’s happening on your network, but you also have the context to do something about it.

Historically, the only way organizations could come close to capturing high-fidelity data about what’s happening on their network was to invest in a packet capture system.

That’s so yesterday.

Full packet capture systems were never designed to facilitate the detection or investigation of advanced threat actors. Metadata is a game-changer in the security space. Think of it as Netflow on steroids and you’ll begin to understand the power of metadata in making all your impossible tasks possible.

-- Fidelis Cybersecurity CMO Michael Evans

Ready to do impossible things with metadata? Read our white paper, Talk Metadata To Me: How to Decode Your Network’s Deepest and Darkest Secrets and contact Fidelis today.

Commodity Remote Access Trojans (RATs) -- which are designed, productized and sold to the casual and experienced hacker alike -- put powerful remote access capabilities into the hands of criminals. RATs, such as H-W0rm, njRAT, KilerRAT, DarkComet, Netwire, XtremeRAT, JSocket/AlienSpy/Adwind and others, hold special interest for the Threat Research Team at Fidelis Cybersecurity. We're constantly following, detecting and monitoring the lifecycle of these RATs as they appear, disappear and often reappear under a new moniker.

There have been recent reports ^{1, 2} about a new version of one such commodity RAT, H-W0rm (Hworm), and the various campaigns it is being used in. Our telemetry shows that H-W0rm is one of the most active RATs we've seen, with infections observed across virtually all enterprise verticals and geographies in which Fidelis Cybersecurity products are deployed.

In this blog post, the Threat Research Team at Fidelis Cybersecurity is supplementing these recent reports by providing the security community with the following:

• Technical descriptions of the payload behavior when installed on the victim machine.
• Domains observed in active infections over the past six months. We also make a larger mined dataset available through Fidelis Barncat, a malware configuration intelligence database shared at no cost with trusted third parties.
• Artifacts correlating Hworm C2 domains with njRAT, XtremeRAT and DarkComet.
• Yara rules that can be used to detect the VBS and PE versions of H-W0rm.

The following is a screenshot of the Hworm v.1.3 panel and the builder tab:

 Hworm 1.3 builder panel

Hworm 1.3 server builder window

A Worm That's Really a RAT

It is worth clarifying that even though the malware is known as H-W0rm/Hworm, this version is not a typical worm. Specifically, it features classic Remote Access Trojan capabilities that allow the adversary to fully control the infected system. Here is rundown of some of these capabilities:

• Collect system information: hardware ID, client name/campaign code, computer name, operating system, worm/RAT version, information about AV installed, webcam presence, etc.
• File Manager: download, rename, delete, execute
• Remote Desktop capture/screenshot
• Keylogger
• Collect password filled in forms from web browsers, such as Mozilla Firefox, Google Chrome, and Opera
• Webcam
• Microphone
• Run remote application or script from disk or internet, or load it in memory via RunPE
• Update RAT from disk or internet
• Close connection
• Uninstall RAT

Let's Go to the Videotape

A YouTube video shows an Hworm version that is referred to as version 2. The following is a screenshot from one of the windows presented in the video:

The Exploit panel, under the Builder tab, looks interesting. At the moment, it is unclear how this feature works, but its mere presence suggests the potential for creating and integrating future exploits into the malware. The following is a screenshot of the panel:

Our analysis found that one of the samples saved keystroke data into the %TEMP% directory using the filename [malware_name.dat]. In this instance, the malware was configured from the builder to be installed in the %TEMP% directory, but based on the builder settings, it can be installed in the following directories:

• %APPDATA%
• %USERPROFILE%
• %PROGRAMDATA% (Windows 7)
• %TEMP%

The malware also created the following hidden folder in the attached USB drive: $RECYCLE.BIN.

The Link to Houdini

There has been speculation in the research community ^{3, 4,5}  that "Houdini" (aka ‘Mohamed Benabdellah’) is believed to have connection with “njq8” (aka ‘Naser Al Mutairi’), the initial developer of “njRAT” and “njw0rm”.  It has further been speculated that "Houdini" is based in Algeria and “njq8” in Kuwait. It is also said that “njq8” has a connection with “Black Mafia” on the development on “Black Worm”, indicating potential collaboration between these RAT developers.

AV Information in the Network Traffic

The network traffic of some versions of the Hworm malware contain information about the antivirus tool installed in the victim system. This data indicates that some of the infected systems appeared to have been running antivirus tools like:

• Microsoft Security Essentials
• Symantec Endpoint Protection
• McAfee VirusScan Enterprise
• ESET Smart Security
• Windows Defender

Normally, those tools will detected the malware, but for some unknown reason it looks like the AV tools didn’t remove those versions of the Hworm malware running in memory. Without a copy of the specific Hworm version in the victim system and a Forensics investigation, it is difficult to confirm why those AV tools didn’t remove the sample from those victim system.

Protect Yourself

These findings are another validation of how a layered approach to secure the network enterprise is needed to protect your endpoints from these cyber threats.

In order to aid the security community with indicators of the Hworm RAT, the following is a list of C2 domains we have seen in the past six months:

From the above domains, the following one quickly stands out: “njrat2012.no-ip[dot]biz”. The last Hworm activity observed at a client site with this domain was on Oct 2016. pDNS data shows that in June 2016 this domain was associated with Xtreme RAT activity. We also found samples of njRAT v.0.7d and v.0.4.1a beaconing to this domain. The following table shows some of the C2 correlations:

To aid the security community, we're constantly enriching Fidelis Barncat with newer Hworm configurations using our mining techniques.

The following Yara rules can also be used to detect this threat:

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.

DGA

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]

            else:

                dom += vowels[tmp % 5]

                seed = PRNG(seed)

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

        print(dom+tld)

Conclusion

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.

References:

1) https://info.phishlabs.com/blog/vawtrak-/-neverquest2-adopts-new-methods-to-increase-persistence

2) http://www.threatgeek.com/2016/08/vawtrak-trojan-variant-https-c2.html

3) http://researchcenter.paloaltonetworks.com/2016/08/unit42-vb-dropper-and-shellcode-for-hancitor-reveal-new-techniques-behind-uptick/

4) https://isc.sans.edu/diary/Hancitor%2BMaldoc%2BBypasses%2BApplication%2BWhitelisting/21683

5) https://www.proofpoint.com/us/threat-insight/post/hancitor-ruckguv-reappear

IOC data:

MacroDoc:

88d60c264a9c3426c081a2cb56e3a879

2e97ef42f24d6d8d53012c42029554061a7ab2537919e234f678c57fd4eccfd6

Hancitor:

d663b29237f954ff694b69ee31797095

8c3f4d16d09eeeab6feeab50ae82f928f2ff0b34f0a126c359f37d269f3f4214

Vawtrak:

19f8bc63e882fbe7affccd814602638b

edc45d14797e496726c2e27f127ac3e6b49efc5e6fc38e7459b651bcf173ecaf

Pony:

7378b75f2fe85f3eaad925d743d86543

7d4234e487eb5513e3dfcdfb00c90afa375af6a350e6f3232adcc40731b09365

Pony:

hxxp://tofrentaleft.ru/zapoy/gate.php

hxxp://lighfaransit.ru/zapoy/gate.php

hxxp://rendingrolhem.com/zapoy/gate.php

Hancitor:

hxxp://rendingrolhem.com/ls5/gate.php

hxxp://tofrentaleft.ru/ls5/gate.php

hxxp://lighfaransit.ru/ls5/gate.php

Hancitor downloads:

hxxp://www.lupaprod.com/wp-content/themes/invictus_3.3.3/pm.dll

hxxp://internetbudi.com.br/wp-content/plugins/googleanalytics/pm.dll

hxxp://triozift.nl/wp-admin/pm.dll

hxxp://timesessions.com.kosmos.ch-meta.net/wp-includes/pm.dll

hxxp://www.mindadv.com/wp-content/plugins/ninja-forms/pm.dll

hxxp://gailrobinsonconsulting.net/wp-content/themes/avamys/pm.dll

hxxp://www.lupaprod.com/wp-content/themes/invictus_3.3.3/inst.exe

hxxp://internetbudi.com.br/wp-content/plugins/googleanalytics/inst.exe

hxxp://triozift.nl/wp-admin/inst.exe

hxxp://timesessions.com.kosmos.ch-meta.net/wp-includes/inst.exe

hxxp://www.mindadv.com/wp-content/plugins/ninja-forms/inst.exe

hxxp://gailrobinsonconsulting.net/wp-content/themes/avamys/inst.exe

--- Fidelis Cybersecurity Threat Team researcher Jason Reaves

In Part 1 of this series we asked the question: Would you re-hire your IPS if you interviewed it today? But it’s not a totally fair question. Because, before you hire someone (or in this case buy something) it’s pretty obvious that you need a deep and thorough understanding of what the job entails. Otherwise, frustration, handwringing, and assorted HR crises will emerge.

So, we pose this question to you: Can you even remember why you bought your IPS in the first place? It seems like a self-answering question for a product whose name, after all, is an Intrusion Prevention System.

Perhaps you got it for perimeter threat detection when protocol exploits were all the rage. Or maybe you wanted visibility into packet activity across the enterprise. Whatever your original rationale was for buying your IPS, the job description for an IPS has radically and forever changed.

Here’s why.

The job of stopping intrusions is now about much more than just securing the front door (or the network perimeter). Yes, you have to do that. But most security teams realize that no matter how secure, how Fort Knox, your front door is, we live in a world where some attacks will still get through. Given this reality, the definition of an “intrusion” must change. The proverbial goal posts have moved down the field. Today, stopping intrusions means preventing attackers from stealing or destroying your data.

Attackers use evolving techniques like exploits and malware embedded in content that target users’ applications. That means your IPS needs to give you full-stage visibility as attackers move throughout your network – and not just when they barge in through the front door. It also means your IPS has to be able to look into content so that when your IPS gives you an alert, it can also give you enough information for you to DO something about it…in minutes…not days.

Also consider the seemingly endless array of “complementary” security components we’ve collected. We have firewalls, antivirus, IPSs, secure web gateways, DLP, full packet capture systems, security analytics, mail hygiene products, and the list goes on...and on…and on. We’ve bought SIEMs to help us interpret all that data, yet breaches keep happening at an alarming rate. We’ve acquired so many of them, in fact, that we spend most of our time managing them instead of using them.

To make ourselves feel good about all this, we’ve even developed a term – “Defense in Depth” – to rationalize all of these purchases (a term which Rick Holland, formerly an analyst at Forrester rightly threw cold water on in his Expense in Depth blog post back in 2012). The reality is that – far from being “failsafe” – in many cases these products are all using the same technique (i.e. signatures) to spot the bad guys. And unfortunately, most of them – including your IPS – end up being alert generating machines that feed your SIEM. They create more work for you but don’t let you do anything about them.

Expense in Depth (including your legacy IPS) has brought us a world of superficial security. Do any of these situations sound familiar?

• You’re Out of Money and Out of Time. Deploying, maintaining and operating large security stacks doesn’t come cheap. Beyond initial licensing costs and ongoing annual maintenance, the operating experience comes with hidden costs, including training and ongoing customization to match desired workflows.
• You’re Alert Rich, but Information Starved.Alert triage hell is not security. Security pros are overwhelmed by oceans of alert data – but it often lacks the information needed to immediately validate a threat. To determine if a threat is real – and how dangerous it is – you must correlate information from one security product to another. That’s grunt work for security pros who should be spending their time ferreting out weaknesses on the network.
• You’ve Got an Alert. Now What?The current defense in depth approach has largely ignored the validation, response and remediation aspects that are core to the security workflow. Many security products are oriented toward detection – leaving security pros overwhelmed with alerts.
• You’ve Got Threat Intel. Now What? The reality is that even as organizations have acquired multiple analysis platforms and sometimes more for managing threat intelligence, it’s still difficult to apply that intel. Yara rules are powerful. But few are able to actually apply it at scale in their enterprise.

With this reality in mind, what’s the new job description for an IPS? An example will help us think this through. A major U.S. healthcare company was evaluating a Next-Gen Intrusion Prevention System (NGIPS). Their mission was to lock down their sensitive data – including patient information – without piling more work onto the plate of their already-burdened security analysts. While prevention was important to them, they operated with the assumption that they were already compromised. So they knew they needed an approach that would enable them to rapidly respond to threats and identify compromised systems to prevent data theft.

So they looked for a solution that would help them automate their way out of the problem. While they ultimately selected Fidelis as their Next-Gen IPS, their requirements are instructive for anyone with limited security resources who’s rethinking their approach to IPS.

They wanted an NGIPS that could:

• Do Their Work for Them. Their top requirement was that it had to reduce the total amount of work in their operation. That meant they wanted it to automatically validate network-based alerts using endpoint activity so they would only see real, confirmed problems. They also wanted enrichment activity to happen without their security team logging into multiple products. For example, if a HTTP malware alert was generated in the system they wanted to know if it was the result of a user clicking on a URL received in an email. They also wanted to know if that user machine was actively compromised.
• Optimize Their “Expense in Depth” Stack.Next, they were focused on optimizing their investment in their network security stack, without adding to it. That meant doing more within a single product. For example, when they get an alert they wanted to be able to quickly get context about what was happening before and after the alert fired. They also want to see what type of content was involved. For example, an alert involving patient data would be much more important than a generic phishing email. And they wanted to do this and act immediately without having to swivel from one product to another and another.
• Eliminate Their Dependence on IT. They needed a solution that would allow them to break free of their dependence on IT. Specifically, they wanted to be able to take action without having to call in favors IT to track down a log file (wait about a day), find out that IT gave them the wrong log files and request them again (and wait another day), only to do a deep AV scan and decide to just re-image the box because results were inconclusive (and wait for IT to reimage that box). In short, they wanted to take control of their own security program with a solution that could remotely investigate an endpoint (on or off network), determine if a potential threat actually compromised an endpoint, and immediately take remediation actions when it did. They chose to automatically quarantine suspected endpoints to a vlan until an investigator could terminate malware processes and delete malware objects.

To sum up: a changing landscape means that we demand much more from an IPS than we ever did before. So it’s time to take a hard, fresh look at what your IPS needs to do, and then assess whether the one you have measures up.

So, whether you are buying a new next-gen IPS solution for the first time (like the healthcare organization we described) or looking to optimize your existing security stack, Step 1 is to define the job you are hiring it to do.

Next up in Part 3 of our series, we’ll move to a review of other technologies that organizations are using within their next-generation security stack, including next-gen firewalls, and explain how a next-gen complements them.

-- Jared Phipps, West Coast Manager

There are two types of runners: long-distance runners and sprinters. Everything about them is different. Sprinters are built for power while marathoners are built for endurance. But what if you could break the mold and find all of those capabilities in a single athlete?

Endpoint detection and response (EDR) tools have faced a similar conundrum. Vendors have historically forced users to choose between architectures that were optimized for one activity at the expense of others. In short, the choices have been:

• Optimize for Speed: These tools generally use a peer-to-peer architecture that enable endpoints to communicate with each other. The net result is fast results. When you want to ask a question of your endpoints you can get results in seconds across tens of thousands of endpoints.
• Optimize for Detection: These tools typically stream events back from each endpoint to a centralized repository. This enables rapid real-time detection because events for every endpoint can be searched in a single repository.

• Optimize for Forensics: These tools are architected to perform deep on-endpoint forensics.

With today’s release of Fidelis Endpoint 6.1, we’ve eliminated that forced choice. The addition of centralized events monitoring to our existing peer-to-peer query capability and rich forensics capabilities in the Fidelis agent mean users can “get it all” in a single product.

Let’s see how this plays out in a typical use case.

Step 1: Detection
Like most traditional endpoint detection and response (EDR) solutions, Fidelis Endpoint now records and stores event data in a central location. In addition to rapid detections, this accelerates the triage and validation of alerts because key event data such as files, processes, registries, network connections, URLs and DNS lookups are preserved in a centralized repository.  This historical data is untouched and can provide valuable clues to trace an alert back to its original source, whereas data on the endpoint might be erased or altered by an attacker. By tracing an attacker’s activity back to the root cause an organization is able to treat the core problem, instead of playing a constant game of whack-a-mole.

Step 2: Response
But event data only tells part of the story. Sometimes you need to reach out to your endpoints to further investigate and respond. For example, maybe you identified a vulnerability that an attacker exploited and you want to search all of your endpoints to see which ones need to be patched. Or perhaps you identified a suspicious process and you want to see what other endpoints are running it. Or maybe you want to pull a file from the Autorun directory. What if you have determined the scope of an incident and need to isolate a group of endpoints?

All of these are time consuming tasks. And endpoint solutions that stream endpoint events to a centralized repository universally fall down when it comes time for these because they are optimized for detection at the expense of rapid response. They were not built to scale and when it comes to actions they are sluggish, costly and overly complex.

With today’s release of Fidelis Endpoint 6.1, Fidelis is now the only endpoint detection and response vendor that is optimized for both detection and response. We solve this by offering a hybrid architecture that also includes peer-to-peer querying capability that is designed to quickly ingest and aggregate data.  Using this method, users get answers to their questions, like those above, in seconds (vs. days or never).

Let’s look at an example of how this plays out in real life at a U.S.-based resort. They were facing a few challenges. First, they knew attackers were in their environment but they had no visibility into how the attackers were getting in and they felt like they were chasing ghosts. They relied on a manual process for retrieving and investigating endpoints when they suspected they were compromised. And to minimize disruption to their users they had to maintain a pool of “standby machines” with their gold image loaded on them so they could swap out machines when they suspected a laptop might be compromised. The entire process was slow, ineffective and costly.

Using Fidelis Endpoint they were able to quickly validate alerts and see what other systems were compromised with a single click.  With another click they created a rule to detect if the process executes in the future and automatically isolate the endpoint.  Next, they were able to see how the attack unfolded using the process tree and determined that the root cause what due to a Java exploit.  They queried all of the endpoints to determine which machines were vulnerable.  Then, they pushed a patch down to all of the vulnerable the machines. 

Going back to where we started…I’m pretty sure that if we found an individual that was both a great sprinter and a great long distance runner they’d have a lot of medals in their closet. Here at Fidelis, now that we have the industry’s first EDR product that is architected to both detect and respond faster than any other product we’re not looking to win any medals. But we’ll be happy knowing that there are more attackers on the outside looking in than on the inside looking out.

Curious to learn more? Or just don’t believe it could be possible? Schedule a demo and we’ll show you what Fidelis Endpoint looks like in action.

-- Fidelis Cybersecurity Product Marketing Manager Jennifer Bielski

Security got the boring end of the stick when names for the generations were handed out. Instead of Millennials, Gen X, Baby Boomers or the Greatest Generation, we're stuck with "Next Gen."  What comes after "Next Gen"? And where were the creative minds hiding when we needed them most?

In this post, I’m going to focus on a sliver of the next-gen security stack that we get asked about every day. Specifically, where do next-gen firewalls stop and where do next-gen IPSs pick up the baton. 

But first, to understand next-gen security we need to take a quick trip down memory lane back to the mid-2000s. That will help us understand what went wrong with "Last Gen" security and get smarter about the future. The mid-2000s was a bleak time for enterprise network security. Remember those port-centric firewalls that couldn't break out of the ACCEPT/DENY paradigm, and completely ignored the fact that most applications were beginning to run over HTTP?

Back then, there were deep-packet inspection-based IPS devices with primitive matching languages that (at best) could look into protocol headers for exploits targeting application servers. Full packet capture systems were in their infancy, filling large arrays of spinning disks with terrabytes of packets. It was an awesome sight to behold but it delivered little practical benefit.

Enter "Next Gen" Security
As the industry began to get smarter and more focused on the nature of the threats it faced, next-generation firewalls (NGFW) were the first and most compelling solution to emerge. Better known in their infancy as application-aware firewalls, application-specific packets were added to their accept/deny paradigm so you could sort out when your employees were working in Salesforce and block them when they were working in the World of Warcraft.

It wasn't long before next-gen firewalls gobbled up other firewall functions like VPNs, basic routing, URL filtering and even some malware analysis. As the capabilities of next-gen firewalls grew, the next logical step was to incorporate the packet-focused IPS engine and its associated ruleset.

This next step in the Great Gobble, however, is where next-gen firewalls ran into some problems. Sure, NGFW is as good a place as any to park those packet-based signatures if it makes you feel good. But real problems can emerge when you take that step.

First, it turns out that all of the additional features in NGFWs don't come for free. Each incremental feature increases the load on the NGFW, to the point that it risks creating a bottleneck that slows down the network. More important, as we pointed out in the first blog post in this series ("Would You Re-Hire Your IPS Today?") those IPS signatures aren't doing much to stop modern attacks, wherever they reside. So, adding them to the NGFW doesn't really solve the problem of the day: stopping intrusions.

Next-Gen Intrusion Prevention
That's where next-generation intrusion prevention systems (NGIPS) come in. They pick up where NGFWs leave off. All next gen-firewalls can do is block known bad threats (think...signatures). By contrast, next-gen intrusion prevention systems are far more muscular. They find and stop the (more dangerous) unknown threats that push right through your next-gen firewall. They help you truly understand what is happening and has happened in your environment so you can respond quickly and resolve incidents.

Think of the offense on a football team to understand the different roles a NGFW and NGIPS play. Your next-generation firewall is the offensive line. Its job is keep the defense at bay and out of the offensive backfield. Meanwhile, the quarterback is your next generation IPS. They call the plays, read the defense, make audibles and need to be ready to quickly react to a wide variety of situations in the moment.

With that analogy in mind, let's take a hard look at how next-gen firewalls differ from next-gen IPSs to understand the division of labor between them and what it means to your security operation.

• It’s a totally Black and White World: The job of the NGFW is to either block traffic or allow it. It lives in a binary in-or-out world. There are no grays and no color. It doesn't give you the nuanced visibility you need to understand what is happening on your network. That constant flow of PGP-encrypted objects flowing out of the accounting department might be worth looking at. But the NGFW can’t make that distinction.
• Alerts But No Actions: The NGFW remains a here-and-now alerting device. It makes a decision on activity in the moment, or soon after the activity is observed. But its alerts are forensic poor. That has historically been a problem for firewalls, which put the burden on incident response teams to look elsewhere for related artifacts. And while some NGFW solutions have incorporated malware sandboxes, they remain light when it comes to exploit and malware detection.
• Application Aware But Content Blind: While your NGFW might be application-aware, it is also content-blind. It doesn’t look deeply at the content of the packets so it can't tell you when unsigned driver files are headed toward your domain controller, let alone stop them.
• Network Amnesia: The NGFW doesn't have any memory. It lives in the moment. It can't apply new intelligence to historic activity because it doesn't have any. It also can't run analytics or identify the low-and-slow attacks that unfold over a longer period of time, which is increasingly the nature of today’s more advanced attacks. 
• Blind to Endpoints: While some NGFWs have light tie-ins with endpoint solutions, the emphasis is on "light." They can't do real forensic and investigative use cases. In the absence of real forensic information about network activity (see Alerts But No Actions) what does the NGFW ask of the endpoint to validate and enrich alerts?
• Old-Gen Rules: While a NGFW might take IP lists and even Snort rules and apply them in the here-and-now, they stop there. They can't handle rich and contemporary expressions of user-supplied threat intelligence like YARA rules and apply them to network activity. Why subscribe to all those CERT alerts and ISAC feeds if you can't actually use them?

You might be thinking “Hold on a second. It’s unfair to expect the NGFW to do all of this in addition to the classic firewall, proxy and basic IPS functions that it handles.” I’m glad you’re thinking that. Because that’s the entire point. Each player on a team has a different role. But if you don't have the right players in the right roles, you're less likely to have successful outcomes on the field.

So here's a quick reference guide for what a next-gen firewall does and what a next-gen IPS can and must do in your security stack.

You can take a look at the second blog post in this series ("Did You Hire Your IPS for a Job of the Past?") to see how Fidelis customers are implementing next gen IPSs. Meanwhile, stay tuned for our next post in this series where we'll take a look at the market and explain how Fidelis’ next-generation intrusion prevention solution is unique from other next-gen IPS offerings. 

-- Hardik Modi, VP, Threat Research

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.

Incident

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 125.64.94.201. 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, 126.64.94.200.

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).

Summary

"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

What does 2017 hold for security professionals and the industry as a whole?

To answer this question, let’s take a quick look at what has not changed. For one, ransomware continues to be an effective extortion tool for attackers. They’re constantly honing their ability to use backdoors and rootkits to gain access. Across the board, attackers continue to create new variants of the same malware family. When they find an effective approach, they will continue to exploit it until security experts stop them. Only then do attackers move on to something different. 

Yet the new year also brings new challenges and trends. Now let’s take a look what will change. Here are my top predictions:

Prediction 1: The exploitation of misinformation will emerge. The 2016 U.S. election saw the emergence of fake news that exploited the Google Ad pay system. Without any political motivation, exploiters used popular social medial technology for financial gain. Viewers would read the article, some would click on the advertisements, and the exploiters would make money – in some cases, a lot of money. While this technique did not attack a specific organization, it did bombard the public with misinformation. From a cybersecurity perspective, this technique presents a huge problem in terms of mitigating indirect threats against organizations. The threat is very real and hacktivists – such as Anonymous – have been using campaigns spreading information through social media to bring awareness. Up until 2016, most of these campaigns have been based on awareness of known information. In the second half of 2016, the emergence of fake information became a new threat.

Prediction 2: Hacking will be used to sway public opinion. The effectiveness of hacktivists and nation states during the U.S. election will be copied – potentially in Europe given the elections in France and Germany this year. In 2017, we are going to see ‘tests’ of misinformation using social media that will show how effective misinformation can be to sway public opinions. While Google and Facebook both committed to fighting fake news, the reach of social media goes beyond those two organizations. Fighting misinformation on the internet on a large scale is something that has never been done and will be a challenge in 2017

Prediction 3: Video exploitation will grow in 2017. The volume of video-based monitoring, capture and storage continues to increase year over year. It’s difficult to find a new video system that is not connected to the internet and, as we saw with the botnet attack that temporarily took down Twitter, Netflix and Spotify in November 2016, new IoT technology will have vulnerabilities. As companies push their video monitoring equipment to the consumer market as fast as possible, the security of these devices will be vulnerable. In 2017, there will be attacks on vulnerabilities identified in consumer video monitoring equipment. Attackers could use these systems for extortion, intelligence and hopping into internal networks for more sensitive information, such as passwords, financial data and personal information

Prediction 4: There will be regulatory purgatory. In 2017, many organizations will only implement the minimum needed to be compliant. The reasons are varied, but it mostly comes down to money and time. If deregulation begins in 2017, and cybersecurity compliance falls victim to lesser standards, then the organizations that only do the bare minimum will be more vulnerable to attacks. It will only be a matter of months before these organizations could be breached. The lack of cybersecurity compliance would not be felt until 12-18 months after the downshift. I predict no tangible effects will be seen until 2018 at the earliest.

Prediction 5: Ransomware will continue to be a significant threat in 2017. The attackers of 2015 were the same attackers of 2016. Their motivations remain unchanged – whether it’s for financial gain, intelligence, or hacktivism. While it’s emerged only about two years ago, ransomware has proved to be exceedingly effective because it relies on a vulnerability that cannot be fixed: people. The only mitigation for this vulnerability is awareness and training. As long as people continue to click on ransomware links in email, the threat will always be there. Organizations must embrace best practices to lessen the blow of a ransomware attack: Regular backups, network segmentation, continuous updates of security detection software, and email threat scanners are the minimum organizations can implement.

-- Ryan Vela, Regional Vice President, Security Consulting

Producers of the 1995 James Bond film “GoldenEye” packed the plot with all the signature elements fans expect from the successful franchise. Over-the-top supervillain – check. Cool spy gadgets – check. Exotic locations – check. And, of course, 007 saves the day.

The film was also slightly ahead of its time. The internet, computers and cyberespionage all factor into the plot. In the movie, a criminal element called Janus conspires to steal vast sums of money from the Bank of England. To cover their tracks and spark a global financial meltdown, they plan to knock out the planet’s electronics and communications with a devastating electromagnetic pulse using two nuclear-armed satellites dubbed Petya and Misha.

If you’ve never seen the movie, parts of the story may still seem familiar. GoldenEye is the latest iteration of James-Bond themed ransomware. As Avast noted, the ransomware previously went by the name Petya-Mischa. And the creators of the ransomware – you guessed it – call themselves Janus in homage to the spy flick.

GoldenEye is a 'Ransomware as a Service' (RaaS) with a profit-sharing affiliation model based on the amount of money affiliates bring in on a weekly basis. Late in 2016, the threat community observed GoldenEye offered as an RaaS targeting victims with German-themed lures.

Fidelis Cybersecurity Threat Research observed GoldenEye in a recent campaign and analyzed samples of this ransomware. We’re sharing our findings to inform security professionals of this evolving threat.

Campaign

Fidelis recently observed a wave of GoldenEye deliveries via email starting on December 1, 2016. While the lures themselves all have German themes, such as the use of 'Bewerbung' (“application”) in the title, we saw scattered messages delivered to users elsewhere in Europe, the Middle East and North America.

The delivery tactic typically involves an Excel file with an embedded macro. It is sometimes accompanied by a benign decoy document, possibly to reassure the recipient that all the files attached to the email are safe to open and everything is business as usual. However, once opened, a pop-up window appears asking the user to enable macros – which enables the ransomware.

Later in December, we saw instances of GoldenEye involving higher volumes of emails, indicative that the adversary’s initial trial runs went smoothly and it was time to shift production into high gear.

Delivery

From our observations, Microsoft Office documents are the primary source of delivery for GoldenEye ransomware. The ransomware uses malicious macro code as a dropper, i.e. it has the next-stage deliverable object already onboard and does not need to download anything. Once it gets through the victim’s firewalls and makes its way into the victim’s inbox, all that separates the victim from a full-on ransomware attack is the user’s judgement to not open the email and its toxic contents.

After pulling out the macro code, we can see pieces or chunks of a next-layer script that has been put into multiple variables and shuffled:

Embedded VBA Macro Code

Once we put the pieces together, we have a new script -- but this time in JavaScript. After changing a few things around, we can have the script dump the next layer to a file instead of ‘eval’ or executing it:

Second Stage Script

This script is pretty simplistic in that it just collects all the data up and then base64 decodes it before running it. So all we need to do is mimic the script without executing the payload. Doing this confirms that this is a dropper. Here, we see the PE header of our newly dumped executable:

Dropped PE File

Payload

After getting through the packer, one of the first things the bot does is check if it’s running from %APPDATA% or not - this is a customary location for applications to store data on a Windows system. If it finds that it isn't, it will copy itself to that location and launch:

                                                                              AppData Check

After unpacking all its components, the malware then begins its normal file encryption process, which was previously referred to as Mischa. A ransomware note is placed on the desktop:

GoldenEye Ransom Note

The malware then begins building a list of all files that have an extension that matches one in its list of extensions that will then be encrypted:

The File encryption piece is performed using AES with the key that’s based on part of a SHA512 hash. Both the AES and the SHA512 routines are onboard the malware, but random data is generated using the Microsoft CryptoAPI.

Decrypter

After encryption, the files are given a random extension. Upon examining the decrypter interface it's safe to say that the extensions are not stored anywhere, that is, they’re probably randomly unique per infection:

 Mischa Decrypter

MBR

For the Master Boot Record (MBR) ransom piece, if the malware has the access, it will XOR encode the old bootloader and move it to another segment and then install its own 16 bit bootloader, which will encrypt the hard drive while pretending to be CHKDSK:

Fake CHKDSK Message from bootloader code

The encryption performed is Salsa20, which originally had a few design flaws. But the newer versions have been fixed and the previous techniques for recovering from the hard drive encryption no longer work.

Actor

The actor behind this ransomware goes by the moniker “Janus” on the underground and uses a photo of a character from the movie as a profile picture. Like many colleagues, Janus has been very vocal on social media in attempts to generate interest in their products. One such twitter handle --@JanusSecretary -- posts news and updates related to the malware, while boasting that they have a large and successful German-based distributor:

Summary

The cybercrime ecosystem is thriving and criminals are continuing to cash in with ransomware attacks. Ransomware-as-a-service gives actors yet another revenue channel and motivates them to innovate and protect their revenue streams. Even as new technical protections are put in place, we expect this ransomware to evolve to evade detection -- and scam as many users as possible.

GoldenEye is a great example of how even complex and innovative malware relies on social engineering and manual clicking – in this case, enabling macros in Microsoft Office files – to infect the user’s computer. It also stands in contrast to more traditional types of server-centric exploits that can be patched against. As actors continue to update their tactics, it’s not very surprising that we’ve observed similar instances of embedded malware in many other recent campaigns.

Administrators should pay close attention to these tactics and continually remind their users to never open suspicious attachments delivered via typical spam lures. Use available administrative controls (e.g. lock down the use of macros delivered from outside the organization) to help prevent your organization from becoming a victim.

-- Fidelis Threat Research Team

We're counting down the last few days to RSA 2017. As you pack your suitcase and map out your schedule, plan on joining us for a demo at Booth #933. Stop by and say hello and grab your limited edition t-shirt.

Here’s a quick rundown on where you can find us:

RSA 2017 EXPO: Join Fidelis Cybersecurity at Booth #933, South Hall, at San Francisco’s Moscone Center, February 14 - 16. See a full listing of Fidelis’ RSA activities.

AGC’s 2017 INFORMATION SECURITY & BROADER TECHNOLOGY GROWTH CONFERENCE: At 2:00 pm on February 13, Fidelis President and CEO Peter George will highlight how Fidelis helps leading global organizations prevent intrusions.

TECHNOLOGY DEMOS: See how Fidelis helps shrink your detection and response time from hours to minutes by detecting intrusions on your network and endpoints and automating incident response at the Fidelis booth. Schedule your demo.

GIGAMON PARTNER SESSIONS:Fidelis West Coast Director Jared Phipps will co-present“Pervasive Visibility Enables Comprehensive Security.”

WHEN: 2:00 pm on Tuesday, Wednesday and Thursday
WHERE: Gigamon Booth, #1523, South Hall.

A10 PARTNER PRESENTATION: Fidelis CTO Kurt Bertone will present“Preventing Modern Intrusions at the Session Level with Encrypted Traffic Visibility.”

WHEN: 5:15 pm on Tuesday February 14
WHERE: A10 Booth, #533, South Hall.

FIDELIS RECEPTION:Fidelis is hosting a reception for cybersecurity professionals, media and industry analysts at the Press Club restaurant. Pre-registration is required.

WHEN: 5 - 8 pm on Wednesday February 15
WHERE: 20 Yerba Buena Lane. 

See you in San Francisco!

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 or 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.

Delivery

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.

Crypter

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

Inject

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)

Strings

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:])

Conclusion

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.

IOCs

Sundown EK:

zs.2490.mobi/index.php?zXbjY2v-mNAA=53q3YzvzhaNRTCnZ2qNJ9VnS0Jph-Rg8_VX6nFY3IlmjksmxkOMlRTlJ​​​

zs.2490.mobi/4325/5421.swf​​​

zs.2490.mobi/4325/542.swf​​​

zs.2490.mobi/4325/235.swf​​​

glh.2104.mobi/43526876827345687356872456.php?id=235​​​

zs.2490.mobi/4325/iguhfskrf.xap​​​

website.empowernetworkaffiliate1.us/jiorei34/index.php

website1.empowernetworksolutions.biz/jiorei34/index.php

website1090.empowernetworkview.us/jiorei34/index.php

website1320.empowernetworkview.us/jiorei34/index.php

website1376.empowernetworkpackage.biz/jiorei34/index.php

website1477.empowernetworkview.us/jiorei34/index.php

website1482.empowernetworkpackage.biz/jiorei34/index.php

website1509.empowernetworkview.us/jiorei34/index.php

website1608.empowernetworkview.us/jiorei34/index.php

website1677.empowernetworkpackage.biz/jiorei34/index.php

website1701.empowernetworkview.us/jiorei34/index.php

website177.empowernetworkpackage.biz/jiorei34/index.php

website1860.empowernetworkpackage.biz/jiorei34/index.php

website1944.empowernetworkview.us/jiorei34/index.php

website2.empowernetworksolutions.biz/jiorei34/index.php

website3.empowernetworksolutions.biz/jiorei34/index.php

website300.empowernetworkview.us/jiorei34/index.php

website310.empowernetworkview.us/jiorei34/index.php

website382.empowernetworkpackage.biz/jiorei34/index.php

website4.empowernetworksolutions.biz/jiorei34/index.php

website479.empowernetworkview.us/jiorei34/index.php

website480.empowernetworkpackage.biz/jiorei34/index.php

website5.empowernetworkpackage.biz/jiorei34/index.php

website5.empowernetworksolutions.biz/jiorei34/index.php

website50.empowernetworkpackage.biz/jiorei34/index.php

website556.empowernetworkpackage.biz/jiorei34/index.php

website6.empowernetworksolutions.biz/jiorei34/index.php

website613.empowernetworkview.us/jiorei34/index.php

website639.empowernetworkview.us/jiorei34/index.php

website7.empowernetworksolutions.biz/jiorei34/index.php

website791.empowernetworkpackage.biz/jiorei34/index.php

website8.empowernetworksolutions.biz/jiorei34/index.php

website84.empowernetworkpackage.biz/jiorei34/index.php

website841.empowernetworkview.us/jiorei34/index.php

website941.empowernetworkview.us/jiorei34/index.php

www.empowernetwork1.biz/jiorei34/index.php

www.empowernetwork2.biz/jiorei34/index.php

www.empowernetwork3.biz/jiorei34/index.php

www.empowernetwork4.biz/jiorei34/index.php

www.empowernetworkaffiliate2.us/jiorei34/index.php

www.empowernetworkbook.us/jiorei34/index.php

www.empowernetworkproject.us/jiorei34/index.php

SmokeLoader:

buildsae.org

bulentisik.com

buildsae.us

31.148.219.232

185.183.96.137

118acc3577e163ced7bcc0811b7ee324

-- Fidelis Threat Team Researcher Jason Reaves

Modern messaging apps, many of which offer end-to-end encryption, are used every day by millions of people. These apps come with the expectation of privacy. However, we recently observed an interesting operational security issue involving one such popular messaging app, Telegram. We're posting our observations to alert users of this app to potential privacy concerns.

Changing Scammer Tactics

Relentless calls from telemarketing scammers are a bane of existence in modern life. Whether it's the "can you hear me now" scam, fake charity scams, or fake tech support scams, the pace of attacks on consumers is relentless.  The problem is particularly bad for cell phone users and businesses.

Despite the Do Not Call registry and other associated telemarketing rules, advances of VoIP mean scammers can launch their attacks from anywhere. Scammers often spoof phone numbers. Despite these tricks, scammers have a problem -- the rise of phone number reputation sites and mobile applications designed to warn of bad phone numbers. Thanks to these websites and consumer education, the adversary is seeing their “success rate” drop.

While Do Not Call rules help reduce unwanted and scam phone calls, these regulations do not apply to encrypted messaging and calling applications. That's why messaging apps are an enticing option for scammers. It's a new way to potentially reach millions of new victims.

Taking a Look a Telegram

Telegram is a popular mobile messaging application with encryption options for Android and iOS. It uses your contact list to prepopulate contacts inside the application. In addition, when someone in your contact list signs up for Telegram, you receive a notification so you know you can contact them using the app. Convenient, huh?

However, the combination of these features made it possible for us to uncover a situation that raises a big privacy flag. Here's the deal:If a scammer signs up for Telegram and already has your phone number in their contact list, it will also notify them that you also have Telegram. So in addition to connecting you to your friends and contacts, the app will also connect scammers directly to you. Likewise, if you have scammers' numbers in your contact list for some reason, you will get push notifications when they join Telegram (like in the image above).

And this didn't happen just once or twice. On multiple occasions, we observed phone numbers associated with telemarketing scammers signed up to use Telegram. To complicate matters, we found no obvious way to prevent people from finding out if you are a Telegram user.

Further, it would not be difficult to create a way to determine if a phone number uses Telegram (or any of the many other, readily available secure mobile messaging/voice applications). There are several uses for this insight by third parties:

• Intelligence agencies consider the use of such services as a "risk factor" when deciding on surveillance targets,
• Border control officials could detect the use of such services during border crossing interviews, and conclude that the user has something to hide, and
• Criminals could use the knowledge that a user is on such a service to target them.

Zeroing in on Scammers

In this case, I already had the number of a suspected scammer number added to a mobile application I use to detect such calls. After a quick visit to one of the various caller reputation sites, I verified this number has a history of calls involving IRS-related scams.

Trust, but Verify

Encrypted messaging and voice applications create a new surface area for attacks to unfold and should not be entirely trusted. While these apps may be a great benefit to privacy, they shouldn’t be trusted any more than unencrypted calls.  These systems do protect against spoofing, but if you have unknown callers on such applications, due caution is still required.

Scammers are eager to use other lures to reel in their targets. Just as privacy-conscious individuals may use burner phones and change phone numbers often, modern communications provide an array of methods to make it possible to send a message to a potential victim. For example, it doesn't take much work to pretend to be a trusted contact and tell the victim that "this is a new phone" to exploit an existing relationship.

Avoid Being a Victim: Tips for Messaging App Users

• Remember that while secure messaging services are great for privacy, default settings (which can't always be changed) will often expose you as a user of such services.
• Telemarketing scammers can use new messaging apps to evade regulations and use “trusted” channels to contact potential victims. Use out-of-band verification methods, such as a phone call, before interacting with new contacts to avoid impersonation attacks.
• Understand that using encrypted apps may cause third parties to believe you are -- at the very least -- privacy conscious, or may suggest you have something to hide.
• Some messaging apps, like Signal, are entirely dependent on capturing your address book. Others, like WhatsApp, make this optional but one can assume that most users enable this feature.
• Know that your messaging app could be vacuuming up your address book into their cloud service, where user matches are made – which means they could have a comprehensive social graph, possibly even for numbers that aren't their users.

 -- By John Bambenek, Threat Systems Manager, Fidelis Cybersecurity

There’s a reason why airport security x-rays your bags. It’s because the only way you can tell if something is a true threat is to actually look at the contents.

It’s the same with network security. The only way to prevent modern intrusions is to actually inspect the content on your network in real time…which brings us to the first requirement for stopping modern intrusions.

Requirement #1: Deep Visibility into Network Content (Not Just Packets) in Real Time

As we pointed out in the first blog post in this series (“Would You Re-Hire Your IPS Today?”), the vast majority of successful intrusions are not packet-level, server-side attacks, but content-level, client-side attacks – like spear-phishing emails followed by document-based exploits that target vulnerabilities in desktop applications. These attacks don’t break down the front door. They exploit human vulnerabilities. And they are nowhere near visible in the packets.

Content is to next generation intrusion prevention what packets were to the traditional IPS. A modern IPS needs to be able to detect deeply embedded, content-level threats in real time, and take a prevention (blocking) action when it sees one, just like traditional IPSs can do with packet-level attacks.

And guess what the only way is to inspect the content on your network? You have to reassemble, decode and analyze those network sessions (not just the packets) on the fly. Fidelis is the only vendor that can do that.

You’re probably thinking “What have you got against packets?” And the answer is: nothing. But it’s important to understand that content and packets are not the same thing – especially when it comes to stopping intrusions. Traditional IPS’s are packet-aware but content-blind.

At Fidelis, we use a patented technology called Deep Session Inspection® that operates on network sessions rather than packets and enables our products to see much deeper into the content that’s flowing over the network in real time than a traditional IPS. This enables us to detect and prevent content-level threats that are invisible to a traditional IPS.

Requirement #2: Visibility, Detection and Prevention at All Phases of an Intrusion

A modern intrusion is a process, not a single event. It is a series of actions that take place over a period of time, and it has multiple phases.  Preventing modern intrusions means stopping the attackers before they complete their ultimate objective: stealing, destroying or encrypting your data.

History has shown us that modern intrusions are difficult to detect and even harder to prevent. Getting fixated on one or two phases of the attack life cycle is a losing proposition. To prevent modern intrusions you must have visibility, detection and prevention capability at all phases of the intrusion, including the data staging and data exfiltration phases. That requires seeing and stopping attackers at all phases of the attack lifecycle – not just the initial infiltration, which is the exclusive focus of traditional IPSs.

Requirement #3: Detecting and Preventing in REAL TIME and in the PAST

If anyone ever tells you they can detect – let alone prevent – all attacks in real time, they’re lying to you.

That’s why next generation intrusion prevention requires the ability “go back in time” so you can apply new threat intelligence to network and endpoint events that occurred in the past. This lets you detect threats (and intrusions) that you didn’t know were malicious when they occurred.

This cyber time travel requires rich non-selective network memory. That means you need to record information (rich metadata) about every single session that traverses the network, whether or not you think the session is bad.

Traditional IPSs are focused on real-time detection and prevention. They have no non-selective memory and no ability to go back in time. That’s a problem when it comes to stopping modern intrusions.

At Fidelis we’ve developed a patent-pending technology that extracts, stores, and analyzes rich protocol, application and content level metadata from every session that traverses the network. As we pointed out in a previous blog post, this enables us to detect certain threats that you can only see if you are looking for a pattern of network behavior that occurs over a period of time and across a number of network sessions. It also gives us a platform for doing what we call “data-driven threat detection” that uses machine learning techniques to detect threats with no a priori threat intelligence at all.

Requirement #4: Automated Alert Enrichment and Validation

Traditional intrusion prevention systems are often criticized for being “noise machines”. They spew out tons of alerts but don’t tell you which ones are the most important. And they don’t give you enough information to act on them. That’s a problem when the scarcest resource for most security teams is people.

Next generation intrusion prevention saves time by automatically validating whether a threat compromised your endpoints and giving your security people all of the information they need about what happened before and after an alert.

Requirement #5: All of the Above on Networks AND Endpoints

One last requirement. No matter how good you are at detecting threats on the network, you will never be able to detect (or prevent) all attacks exclusively by looking at network traffic. You need eyes on the endpoints as well. The data attackers are after lives on endpoints. Exploits happen on endpoints. Malware executes on endpoints, and leaves traces and trails on endpoints. Remediation happens on endpoints.

That’s why next generation intrusion prevention requires the ability to see and stop intrusions on the endpoint. The endpoint capability in the Fidelis next generation IPS solution gives us the same deep visibility, real-time threat detection, non-selective memory and ability to detect attacks in the past that we have on the network. As a bonus, you get endpoint-based investigation and remediation capabilities so you can take action.

While these five requirements aren’t the only things you need to stop intrusions, they are the five most important things that separate next generation intrusion prevention from traditional IPS. Having them together – as part of a single system – will dramatically improve your odds when it comes to preventing intrusions. If you want a longer list of requirements for next generation intrusion prevention, check out Gartner’s recent research paper, Defining Intrusion Detection and Prevention Systems.

-- Fidelis Cybersecurity CTO Kurt Bertone