How to Use Interactive Malware Analysis with VMRay AnalyzerAugust 21, 2018 | Malware AnalysisProduct Features
[Editor’s Note: This post was updated on May 19th, 2020]
In the daily war against malware authors, incident response teams (CIRTs) need a comprehensive yet versatile sandbox as part of their automated malware analysis process. This provides the performance, scalability, and accuracy needed to handle the onslaught of malware-related threats.
In addition, manual analysis is an essential complement to automated analysis. Manual interaction allows incident response teams to scrutinize suspect files, URLs, and snippets of code that have either raised a cautionary flag or completely evaded detection by automated methods. In manual mode, analysts can directly interact with suspicious samples to identify IOCs and fully reveal harmful behavior. They can then take corrective action to protect users, applications, and IT infrastructure.
How to Use Interactive Malware Analysis with VMRay Analyzer
Within the universe of sandbox solutions for malware analysis, VMRay provides both approaches in a single, integrated platform—VMRay Analyzer. Equally important, in an era of open yet opaque solutions and state-sponsored hacking threats, VMRay’s end-to-end malware analysis process is isolated within our secure, GDPR-compliant data center in Germany and protected by some of the most stringent data privacy and confidentiality laws in the world.
We asked our VMRay Reverse Engineering team to identify some scenarios where interactive manual analysis can enhance insight into the threat environment and prevent malware attacks from successfully executing. Three examples are highlighted here.
When You Can’t Wait (or Don’t Want to)
Analysts with prior knowledge about a sample can leverage manual interaction to save time during an investigation. For example: verifying an anti-virus vendor’s classification or identifying the variant of the malware family.
An analyst with knowledge about a malware family will know what to look for: they may know that a registry key will be created at a specific path, or that files will be encrypted with a specific extension.
This comes up often with ransomware. Ransomware doesn’t try to be stealthy after it starts encrypting, and is easily identifiable from the file extension and ransom note (Figure 2 highlights an example of Gandcrab v3 with the ransom note and encrypted files with the extension .KRAB). Manual interaction allows analysts to take appropriate action as soon as a harmful characteristic or behavior is revealed.
This contrasts with automated methods, where the analyst has to wait for the analysis to be completed before taking action. Analyzing a sample manually can help the analyst save time with a better user experience.
Manually Browsing Suspicious Websites During URL Analysis
A similar dynamic can occur with website links that are submitted to a sandbox for automated analysis. A favorite tactic used in targeted phishing attacks (spear-phishing) is to embed malicious links within emails or documents sent to senior executives or other individuals with access to high-value information. By clicking the link, the recipient unknowingly triggers processes designed to steal credentials, exfiltrate sensitive business documents, or gain access to confidential resources.
If the analyst just wants to open a suspicious URL in a secure environment, then the manual analysis is a convenient option. On a phishing page, a victim is presented with a login screen that is designed to mimic a familiar website: for example, a login page of a bank or a tool like Office 365. The analyst can submit the suspicious URL to the sandbox, view the contents, explore features of the phishing application or look for an open directory. If the analyst finds an executable, they can download and execute it, and view the analysis report after the analysis is finished.
Applications with Uncommon Dialog Boxes
In the great majority of cases—where dialog box prompts only allow for standard responses (yes, no, cancel) — automated malware analysis can rightly determine whether a sample being examined is safe. However, in a very small number of samples, a malware author may try to evade detection by hiding malicious code behind a dialog box that requires a nonstandard response. Unable to interpret what input is required or whether a nonstandard option is legitimate, an automated analysis engine may be blocked by the prompt, leaving the malware unanalyzed until a real user responds to the rogue prompt and sets malicious behavior in motion in the production environment.
By “clicking around,” he or she can quickly reveal any suspicious behavior that is triggered by a non-standard response and act accordingly to mitigate the threat.
Launching malware often requires some user interaction from the victim (clicking something in a PDF, moving the cursor at a certain speed, entering a password that came in an email). When malware authors come up with a new method, it may not yet be covered by automation routines. Manual analysis can close the gap: the analyst can manually do what automation can’t.
Having the flexibility to pivot from automated to manual analysis gives digital forensics specialists and incident responders (DFIR) more options in the fight against an adversary that will use every option they have to evade and infect their intended victims. With VMRay Analyzer we’ve built this capability in with defenders in mind.