| CERT

DETECTION BACKGROUND

  1. HUNTING FOR SUSPICIOUS EVENT

 

In the scope of our SOC/CSIRT activities, our security analysts are continuously hunting for suspicious events. Based on their knowledge and skills our team is analyzing the logs or assets under security monitoring.  This report is a real case analysis of a threat that has been detected during a hunting stage. The Security analyst was looking on the AV logs to detect any suspicious activity on the LAN RANGE which contains only normal users (no admin neither development engineer).

Executed query: index=AV source_address= LAN-RANGE | chart count by caller_process order by count

NB: C:/Program Files (x86)/XXXXXXXXXX are anonymized process. All of them are legit.

Due to the nature of the park, the more suspected process are highlighted in red. The process cmd.exe and taskhost.exe were analyzed and they are legit . Their execution is related to normal administration activities confirmed with local IT team.

 

  1. ANALYSIS OF THE WSCRIPT EXECUTION

 

Executed Query

index=AV source_address= LAN-RANGE caller_process= »C:/Windows/System32/wscript.exe » |chart count by parameter,workstation,user

NB: Names of users and workstation were modified.

NB: The files under C:/windows/scripts are legit. They are used by the local IT team which does some administration task using Windows Scripting Host.

The suspected files are highlighted in red. The IT analyst suspect them due to their extension and their names (facture is billing in french). The fact that all the executions are done on the same machine using the same account in a short time range seems to prove a relation between the files. The real script seems to be facture.js (It is the only file executed on the 22 and the 28 of March). The IT analyst suspect that this file is fetched from an USB device. The workstation was infected at least 2 times (on the 22 of March and on the 28 of March).

Executed Query

index=AV source_address= LAN-RANGE parameter= »*facture.js » workstation= »WORK-1000″ user=”JOHN-DOW »  caller_process= »C:/Windows/System32/wscript.exe » | chart count by device_id

The intuition of the IT analyst was correct. Based on this information, he asked the local IT engineer if he can dump the script. He gave the names of the suspect USB drivers (name here are modified for privacy reasons). The file was dumped a new analysis stage can start: Reverse Engineering.

OBFUSCATION

It can be seen very quickly that the JScript was obfuscated :

The “var s” string is derived from these CharCodes, and then is evaluated through the function eval(str) .

The sample was really easy to desobfuscate, we just had to convert the data from ordinal integers back to it’s raw form.

The operation was carried out with an easy-to-use tool : https://gchq.github.io/CyberChef/

(screenshot below)

The output is now human readable which is really easier to read, and analyze ;).

ANALYSIS

  1. CONTEXT

 

Since some months, we can observe a little rise of worms (Spora is a good example ). A well coded worm can be very dangerous, it can be a nightmare to clean all the infected machine, a worm can pop back into your IT due to a simple forgotten USB key.

Here, we’ll discuss the case of vjw0rm, a full JScript worm spread via USB key.

CNC Screenshot used in the malware ads.

 

Vjw0rm seems to be released in november 2016 and was caught in the wild in January 2017 by ZaufanaTrzeciaStrona.

Early in April 2017, a sample was found embedded in a CCleaner setup, and a lot of samples are available in Virustotal.

To be clear, this malware is not an “advanced” malware, anybody can use it. If we look at Twitter, we can find some script kiddies asking for help with Vjw0rm.

Vjw0rm, developped by v_B01 (Sliemerez), is the JScript version of vw0rm (a vbs worm)

In our case, the malware seems to come from a fake invoice email campaign targeting french users with a payload named “facture.js”. We caught it quickly due to the “noise”, the massive amount of system events generated when it tries to infect USB keys.

 

  1.  INSTALLATION

 

First of all, the JScript code check from where it is run

It checks if it is being run from the root directory of the partition “:\ScriptName”. It maybe want to know if it is being run from a USB key or from the first attack vector.

If it is being run from USB key, the malware writes “TRUE” in the registry key “HKCU\vjw0rm”, otherwise it writes “FALSE”.

The variable U is used below for construction the User Agent and can allow the bot master to do some statistics.

This is a first easy fingerprint for finding if a computer is compromised by vjw0rm.

After that, some persistence mechanisms are executed:

The sample is copied into “%TEMP%\[ScriptName].js and a scheduled tasks named “Skype” is created via schtasks.exe.

During our analysis we’ve seen other sample that used “HKCU\\Software\\Microsoft\\Windows\\CurrentVersion\\Run\\L6H7KT4R26″” too for persistence.

 

  1. PAYLOAD

 

Finally, every 7 seconds, the main payload is executed:

  • A POST request is send to the CNC.
  • Depending the response, the bot do some things.
  • Malware checks if there is plugged USB keys and if so, it infects them.

    Phoning home

 

For contacting the CNC, vjw0rm sends an empty HTTP POST request to a page named “Vre”.

The request uses a specific user agent easily catchable composed of different informations:

[campaignName][_][VolumeSerialNumber]\[%COMPUTERNAME%]\[%USERNAME%]\[OsVersion]\[AntiVirusInstalled]\\[NetFramework]\[U]\

In our case, the campaign name is “bot’s”

 

The CNC respond with a string composed of 3 parts :

Command|V|Arg1|V|Arg2|

Where the supported commands are:

  • “Cl”: Stop the bot.
  • “Sc”: drop and launch a JScript(Arg1) into %TEMP%\Arg2
  • “Ex”: Execute ( eval() ) a command
  • “Rn”: Change campaign name (this feature doesn’t works if the malware is obfuscated)
  • “Up”: Update bot.
  • “Un”: Uninstall bot.
  • “RF”: It’s exactly the same code as “Sc” command.

As you can see, the bot itself is just a dropper, it allows attackers to easily drop any other malware he want.

W0rm feature

For the worm feature, vjw0rm uses WMI to list logical disk plugged, and target only drive with DriveType 1 (« Removable », for USB keys).

If a USB key is connected, the worm infects it as:

  • Copying itself at the root of the key as “system hidden” file.
  • Setting every existing files and directories as “system hidden”.
  • Creating a shortcut (lnk) with the name and the icon of an existing file or directory (by reading the registry key HKLM\\software\\classes\\folder\\defaulticon\\).
  • Setting the shortcut to execute:

“cmd.exe /c start  ScriptName.js &start explorer ExistingFileOrDirectory &exit”

The JScript is executed and the real file/directory is open.

It’s trivial but sufficient for quickly infect a lot of computers in a company.

 

  1. IOC
  1. REMEDIATION

You can clean an infected USB key using these 3 commands:

 

::del malicious JScript

del /AS *.js

::del malicious shortcut

del *.lnk

::remove hidden+system attributes

for /f « delims= » %%i in (‘dir /ad /ah /b’) do @attrib -r -s -h -a « %%i »

CONCLUSION

This malware is quite young and not mature, there is some tests code and bugs. But this is enough to damage many computers. It’s important to quickly clean your USB Key and computer to avoid a mass infection by this kind of dropper.

Some actions can be done to limit such threat :

  1. Disabling the use of Windows Scripting host (cscript, wscript and mshta). All the needed actions can be done using more secure scripting languages like Powershell. However, due to the heterogeneity of the IT environment a such action can be difficult to deploy immediately
  2. Forcing the AV to scan any removable device before mounting it.
  3. Blocking the execution of some specific file extension (.js, .exe, .bat, etc.) directly from a removable device.