“Adware (004f7c2e1)”: Carving the Suspicious Downloader

By Brendan McGlynn


This past summer, I was lucky to work as a Security Analyst Intern at FireEye Inc.  One of the daily challenges faced was determining which tools to utilize for obtaining the most information about malware samples within the shortest amount of time.  While this process became routine (with me becoming more increasingly familiar with internal tools), I wanted to remain effective in this process when analyzing malware outside the office. 

Having this goal in mind, I obtained a recent malware sample:  

  1. Name: Adware (004f7c2e1)
  2. MD5: b315c590c3ad691604597ea41f8dd84e
  3. Sample Obtained From: https://dasmalwerk.eu/
  4. Virustotal: https://www.virustotal.com/gui/file/f5715822a11648fad7519ace6e634b2f4a4cd2cb1f4003abd2ade32fdf29cf3f/detection  

On Virustotal, this sample is tagged with the categories: adware, downloader, and trojan.  Given this information (and having the constraint of only being able to use publicly available tools), my next goal would be to start carving information.

Testing and Environment

For my sandbox environments, I utilized Windows 10 Home (Version 10.0.18) for my detonation sandbox.  At this point, my first goal was to detonate the malware sample in the Windows sandbox in three separate runs.  For the first trial, I planned on using no monitoring tools while document anything notable.  For the second and third trial, I used FireEye’s Redline and Wireshark for two runs: one run with the network connection set to Host Only, and one run with FakeNet-NG enabled.  The overall goal of having a FakeNet-NG run was to evaluate if any additional information was obtainable in Redline or Wireshark (as sandbox detection is prominent in many malware samples).

My last goal was to evaluate additional malware analysis tools, such as Floss, Cape (a tool which automates Cuckoo analysis), and Hybrid Analysis. 

Dry Run: Host Only

Running the executable prompted a User Account Controller warning for a file labeled downloader.  We are also prompted with a SmartScreen warning, followed by a download window with an error message.  Seeing that sample detonation is possible in the sandbox, it was then time to repeat the detonation with analysis tools running.

WireShark and Redline: Host Only

One prediction I have made prior to detonating the sample is that I would be unlikely to capture any noteworthy information on Wireshark without a simulated network.  With the Windows 10 VM set to host only, this assumption was correct.  Having repeated this step multiple times with Wireshark open, the only information found in packet captures was ARPs, none relating to the malware sample.

Considering that the sample is identified as a downloader (and that there was going to be no network simulation in this trial), I had low expectations for Redline’s ability to provide us with useful information.  As for success with Redline, the following table consists of the only artifacts relevant to the sample’s detonation.

As seen above, Redline only captured information that was either known to us or not highly useful: Prefetches relating to SECURITYHEALTHHOST.EXE and SECHEALTHUI.EXE, the sample being visited (via a URL history log), and Windows defender firing off.

Despite the little success from these two trials, I went into using FakeNet-NG with higher expectations.

WireShark and Redline: FakeNet-NG

Luckily, utilizing FakeNet-NG did the trick! Not only was Wireshark populated with traffic, but FakeNet was able to listen to and capture multiple POST requests.  The following requests were made to ocsp1.wosign[.]com and api.baizhu[.]cc:

Within the WireShark capture below, we can see the POST request being routed to FakeNet.  Following the HTTP stream of the highlighted entry below, we are shown the POST request being made to the FakeNet listener.  This capture is further evidence of FakeNet allowing for additional information to be captured. 

Despite Network traffic massively improving with the usage of FakeNet, Redline appeared mainly unchanged from the previous trial.  The only notable changes are that process events exist for FakeNet (obviously expected since we created that process), and a prefetch for CHXSMARTSCREEN.EXE.  While I’ve had great success using Redline in the past for various investigations, it did not prove nearly as useful as Wireshark and FakeNet in capturing info for this sample.


Getting Floss to properly function was easy to do, and it led to an output of over 13,000 strings.  Grepping through this list with “http” as an argument led to many subdomains of wosign[.]com and startssl[.]com.  Within the list of returned strings, api.baizhu[.]cc (discovered in FakeNet’s POST requests) was nowhere to be found. 

While Floss might have not been most effective for identifying C2 information, there are lots of potential artifacts to be discovered within the sample’s obfuscated strings.  Requiring little pre-configuration (and having taken only 0.156 seconds to output a list of de-obfuscated strings), Floss is one of the fastest ways to quickly obtain information about the sample.

Automated Analysis

When looking at various automated analysis utilities, I came in with relatively high expectations.  Having used internal automated analysis tools during my time as a SOC Analyst, it was my experience that processing can be situationally time consuming (depending on which tests are ran with the sample, alongside the sample’s complexity).  It was also my experience that the largest amount of useful information can easily be extracted from utilizing such tools.  For this sample, I utilized both Cape and Hybrid Analysis for my automated tools.


Cape URL: https://cape.contextis.com/analysis/96897/#

As I expected, Cape provided more information than previously obtained Redline and Wireshark samples.  In Cape’s quick overview section, we are given list of signatures:

Each listed signature can be expanded to show additional information can be unpacked here.  The api.baizhu[.]cc, wosign[.]com, and additional previously seen domains reappear in the HTTP requests section.  A large list of loaded DLLs is also provided here, alongside packing information. 

In the quick overview network section, we are given extra context towards referenced hosts and DNS information:

Further information on the sample was broken down by the Static, Behavior, and Network Analysis sections. 

The Static Analysis section provided a list of deobfuscated strings (as seen earlier in our usage of Floss), as well as the sample’s PE information, sections, overlay and various library imports.

The Behavioral Analysis provided us with a process tree to observe.  While it’s unfortunate that I couldn’t replicate a similar process tree in Redline, Cape was successful and doing so. 

Many filters exist for the process tree above, including default, registry, and filesystem.  Utilizing the registry filter, we can see our sample opening, closing, and enumerating various keys. 

Lastly, the Network Analysis sections provides us a list of hosts, DNS information, TCP, UDP, and HTTP information.  A PCAP (very similar to that from FakeNet) is also available.  There are also sections available for SMTP, IRC, ICMP, and JA3 traffic, but our sample does not cause this type of traffic to be generated.


Hybrid Analysis URL: https://www.hybrid-analysis.com/sample/37ea273266aa2d28430194fca27849170d609d338abc9c6c43c4e6be1bcf51f9?environmentId=100

Very much like Cape, Hybrid-Analysis provided interesting and new information to unpack.  Once the analysis finished, various malicious and suspicious indicators were shown.  Of the malicious indicators, one of the most noteworthy findings was additional detail towards the sample’s sandbox-detection capabilities.  What’s happening here is that a CPUID instruction is executed with an EAX=1 input parameter.  Many malware samples examine certain bits of the returned processor info and feature bits, and these indicate 0 for a legitimate CPU and 1 for a VM. 

Other malicious indicators include the sample being identified as malicious by various antivirus engines, as well as a list of artifact hashes seen via the contacted IP: 39.108.27[.]173:

One surprise from the Hybrid-Analysis was the overlap of information which I have discovered using Floss and FakeNet.  Hybrid-Analysis provides us a section for HTTP traffic (as seen in my FakeNet usage), alongside lists of deobfuscated strings (as seen in my Floss usage).   

Two highly valuable sections provided by Hybrid-Analysis are Risk Assessment and MITRE ATT&CK Techniques Detection.  Here, our sample has been attributed to potential spyware, fingerprinting, being evasive (as seen with the CPUID trick), as well as contacting an external domain: api.baizhu[.]cc.

Overall Findings

After our testing, there is a ton of information to unpack on behalf of our ‘Adware (004f7c2e1)’ sample.  In doing so, we were also able to allow for a proper trial run of a variety of malware analysis tools along the way.  Our primary goal throughout was to evaluate which tools can allow for the most amount of information to be extracted from the sample within a timely manner, and we came across interesting findings for sandbox and automated environments. 

From the sandbox tests, it is apparent that some tools provided more useful than others.  Redline was disappointing as it did not provide us with any useful during analysis sessions.  I have used Redline in scenarios where many malicious indicators are discovered, so further experimenting with other samples may be needed to get a better understanding for its shortcomings for our sample. 

Wireshark, on the other hand, provided us with more insight on the value of certain analysis tools.  Wireshark on its own didn’t provide us with any useful information but used in conjunction with FakeNet provided us with POST requests to an identified domain, as well as a populated PCAP file.  As a last bit of sandbox success, Floss succeeded at extracting many obfuscated strings, many of which were later discovered by Cape and Hybrid-Analysis.

Both automated analysis tools were, as expected, highly capable at capturing information about the adware sample.  Together, Cape and Hybrid-Analysis captured large amounts of information regarding file information, sample behavior, network activity, as well as malicious indicators.  Both tools did not take long to run (Cape identified the session duration at 53 seconds), and the amount of captured information exceeded that of my sandbox testing.  Despite this, getting hands on with the sample could situationally provide more useful than using an automated tool.  In an incident response scenario, it is likely that more than one malware sample would have detonated on the host at once.  Given these types of scenarios, forensic tools (such as Redline) would need to be utilized in conjunction with automated tools and Wireshark captures on network devices to capture as much information as possible..  Having a ready-to-use sandbox analysis environment in conjunction with automated tools can provide most useful for extracting sample information.

Final Attributions

As a final part of analyzing our adware sample, our last task is to consolidate our findings and see if we’re able to attribute our sample towards any malware families.  Our noteworthy indicators thus far have been the multiple POST requests made to api.baizhu[.]cc, the registry enumeration (as seen in Cape), as well as the CPUID anti-VM trick.  Given these findings, there are lots of possibilities for what the sample is capable of.  According to Virustotal (https://www.virustotal.com/gui/domain/api.baizhu.cc/relations), the domain api.baizhu[.]cc is referred to in a Win32 executable labeled “downloader“ (which we have seen in our previous analysis).  Virustotal labels the sample and api.baizhu[.]cc as malicious without too much further of a description, so it’s difficult to 100% pinpoint what the sample is doing. 

Going back to Hybrid-Analysis, the Risk Assessment section attributes our sample to Spyware (consistent with POST requests being made to a remote server).  Hybrid-Analysis also helped confirm to us that various keys are opened, enumerated, and closed.  Looking at the order of processes in Hybrid-Analysis, registry information is parsed prior to POST requests being made (indicating that such information is sent to the remote host).

With everything we have uncovered, spyware is a highly potential attribution for out sample. Given our various findings, it is difficult to give an exact approximation for our sample, but the POST request and registry enumeration is highly suspicious.  One option for further investigation would be to create a new testing environment with network access (likely with usage of an upstream pfSense router and a VPN).  If Redline and Wireshark are used to monitor the system with legitimate network access (sorry FakeNet), then we would potentially have more to look at.  Regardless, this sample provided a great use case for experimenting with various publicly available analysis tools.







Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s