Sing Malware Sandboxes for Initial Triage and Incident Response
By Koen Van Impe
Learn from this practical case study how VMRay Analyzer helped with getting an accurate and noise-free analysis for initial triage and obtaining the relevant indicators of compromise for faster incident response.
Computer security is a fast moving industry. There is a lot of new technology on the market for organizations to catch the bad guys. Unfortunately, not all organizations can keep up with these changes. Many struggle to get the basics right and have difficulties finding sufficient staff to resource their security operation center (SOC), let alone provide them a toolset to analyze the threats they face on a daily basis.
Setting the Scene
In this post I cover a case where I supported the SOC of an organization. The SOC could only rely on a SIEM with the anti-virus logs, the web proxy logs and the e-mail server logs. This case starts with two separate users of the HR department opening a ticket with the service desk complaining that their computers are slow and unresponsive. Both users report that this behavior started relatively short after receiving an e-mail from a job applicant responding to a job opening. This job opening -coincidentally for a security analyst- was just recently published and they were expecting applications to come in rapidly. The e-mail in question contained the resume of the applicant and the HR employees unsuspiciously opened the benign looking Word document. They found it a bit unusual that the document was protected with a password but considering this was a job as a security analyst they didn’t think too much of it at the time.
The script for the service desk in such cases involves that they ask the reporter for a copy of the e-mail. Once the service desk received the e-mail, they completed the ticket, categorized it as a potential security incident and passed it on to the SOC for further analysis.
The playbook for the SOC involves these basic steps
Understand if the e-mail is a risk to the organization
Analyze the attachment and understand its purpose
Check that the system and anti-virus is up-to-date, identify related events in the SIEM and collect evidences from the users’ workstations
Confirm (or deny) it’s a security incident. Understand the impact, how far spread the incident is within the organization, identify initial access vectors and potential lateral movement indications
In essence, the goal of the SOC in this stage is to compile a set of indicators to detect other users impacted, propose filtering options to minimize infections and subsequent limit further impact to the organization.
Quick Triage
Unfortunately, the SOC did not had a separate lab for analyzing the attachment. Collecting the evidences from the users’ workstations takes time and in the meantime there’s a risk that other users get infected. Because the e-mail, or at least the Word attachment, can potentially contain personal information (at this time, it’s not confirmed this attachment is indeed the cause of the behavior) they cannot just upload the file to VirusTotal for analysis. Note that uploading the file would not only be problematic from a data privacy point of view. If this document would be part of an attack campaign, uploading the sample to VirusTotal could also potentially hint the attackers that their activities are under investigation. A query for the hash of the file also did not return any usable results.
This type of situations sounds all too familiar. And although there are multiple ways for improving the capabilities of the SOC, one of the solutions that works pretty well in this type of cases is a malware sandbox. There are open source solutions such as CAPE or Cuckoo but these require more knowledge and time to use and maintain. An alternative is the malware analysis and detection sandbox from VMRay.
To demonstrate how a sandbox can be used in this situation I use a sample already analyzed by Malware-Traffic-Analysis.net with similar characteristics as this case:
An e-mail with a Word document as attachment;
A password protected document, with the password in the e-mail body;
A user unlocking the document with that password;
A user enabling macros, after which the document downloads and execute additional malware.
Analyzing the Sample With a Sandbox
Upload the e-mail:
The results of the e-mail (headers, body) are not that interesting for this case. I’m primarily interested in the analysis of the attachment.
Analyze the Word document:
The threat identifiers from VMRay give me already a lot of input for the initial triage of this incident. Outgoing network connections and a known malicious URL. This document is likely going to be something more than just a job application.
In the next step I want to do a visual identification of the document and understand how it tries to lure a user into enabling macros. An analysis involves the creation of screenshots of the desktop of the sandbox machine. These screenshots are a valuable source to understand the purpose of a document. I don’t have to open the documents on a “real” workstation, which limits the risk of an accidental infection.
The screenshots confirm the threat identifiers found earlier: it wants the user to enable macros after which a follow-up action will happen. I already suspect what this type of follow-up action will be but to confirm my suspicion let’s have a look at the MITRE ATT&CK techniques linked to this analysis. If you haven’t heard about ATT&CK, it’s a knowledge base of tactics and techniques observed as being used in real world attacks.
It’s using scripting (T1064) and linked with the threat identifiers from VMRay this means that
The document contains a VBA script (the macro)
It writes “something” to a file. This gives useful artefacts to look for on infected machines
It starts a COM object, responsible for the HTTP request
HTTP requests from a macro are rarely non-malicious, certainly if the document comes from an external source. Because the primary goal of the SOC is to extract indicators to define the impact of the incident and prevent further spreading I first jump to the details of that HTTP query.
Create an indicator package and dispatch them:
Note that in this blog post I’m using an example already analyzed by malware-traffic-analysis.net. At the time of the analysis in VMRay the payload downloaded by the Word macro was no longer available. For the purpose of this article this doesn’t really matter though.
This HTTP GET request to 209[.]141[.]49[.]93 is a useful indicator. It allows me
To query the proxy logs and see if there are requests from other workstations. This gives information on how far spread this incident already is.
To temporarily block or redirect requests to this IP and prevent further damage from taking place.
There’s more useful information to extract from this document. One of the techniques was that it attempts to create and write to a file. The analysis tells me that the function to create and write to a file is in the Office macro. As it happens, VMRay also gives access to the macro.
The file downloaded is “hello.bin”, however the macro code tells me that the actual filename written on disk is “qwerty.exe”. This is an additional indictor. If I search for the presence of the file qwerty.exe in the temp directory (set via the environment variable) on a workstation I can confirm with a high confidence that the Word document had been opened, the user supplied the password, enabled the macros and the additional malware was downloaded and executed.
As said earlier, at the time of this blog post the file qwerty.exe was no longer available for download but as it’s included in the data set of malware-traffic-analysis.net I have -manually- uploaded it to VMRay for analysis.
The initial classification from VMRay hints me on the type of malware. It’s ransomware, more specific GandCrab.
This most probably is the explanation for the complaints for slow systems coming from the users from the HR department. A classification of ransomware also means that the severity of the incident is increased.
There’s more to discover. The threat identifiers tell me some of the content is matched by YARA rules and there’s activity towards malicious domains.
The IOC section marks some indicators as malicious and others as clean. To understand this difference, we need to explain how some malware works. Sometimes samples want to check if they have internet access. In addition, they sometimes want to know the IP address that is used for outgoing network connections. This is exactly the type of behavior you see with the HTTP request to ipv4bot[.]whatismyipaddress[.]com . The WhatIsMyIPAddress service does what the name implies, it returns your IPv4 address and it’s confirming that there is working Internet access. This is an indicator that you can use in combination with other indicators to confirm certain behavior. If you just block (or log) access to it, without additional context, you’re going to generate a lot of false positives. And headaches for the SOC team.
The first two indicators, the DNS names are marked with malicious and are a candidate as reliable indicators of compromise. They represent the execution of nslookup, or DNS queries, for a specific domain. At the time of the analysis no DNS results were returned but this does not mean that I cannot use them for an indicator package.
The nslookup command attempts to resolve carder.bit. This gives two opportunities.
Block traffic to the domain carder.bit;
Redirect the traffic to a host under our control. This is commonly achieved with a Response Policy Zone or RPZ. An RPZ, sometimes called a DNS firewall, blocks DNS resolution to known malicious domains and redirects the queries to a controlled host. This has two advantages. The follow-up infections no-longer take place and you have an immediate log of infected hosts trying to resolve the malicious domain.
