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.
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
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.
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:
A user enabling macros, after which the document downloads and execute additional malware.
Because I do not want to open the e-mail and extract the attachment manually, I can just upload the e-mail sample and have VMRay analyze both the e-mail and the attachment.
(Figure 1: Upload the e-mail sample and have VMRay analyze both the e-mail and the attachment)
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.
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.
(Figure 2: VMRay Threat Identifiers recognize outgoing network connections and a known malicious URL)
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.
(Figure 3: Visual identification of the document)
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.
(Figure 4: MITRE ATT&CK 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
(Figure 5: Further examination of relevant VMRay Threat Identifiers)
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.
(Figure 6: Examining known malicious VMRay Threat Identifiers, network connection & reputation)
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
I can already dispatch these indicators to the network team to take the blocking actions.
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.
(Figure 7: The malware attempts to create and write to a file. The analysis shows the function to create and write 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.
(Figure 8: VMRay suggests the type of malware. It’s ransomware, more specifically, 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.
(Figure 9: The threat identifiers explain that 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.
(Figure 10: VMRay Analyzer reporting Indicators of Compromise also known as IOCs)
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.
(Figure 11: Further Details explaining the nature of nslookup and the domain Carder.bit)
This is only a short overview on how you can use a sandbox to quickly extract indicators during the triage and analysis phases of incident response. A sandbox is great technology for staff with limited resources and time to quickly extract indicators to block and log malicious activity.