Latrodectus Loader Analysis – Deobfuscation and Detection

This post will dive into a Latrodectus loader that leverages junk comments and wmi commands to obfuscate functionality and download a remote .msi file.

There are three “stages” to this sample, which can be decoded through a combination of regular expressions and CyberChef.

Obtaining Initial Sample

The initial sample can be found on Malware Bazaar and was initially uploaded by pr0xylife

SHA256: 71fb25cc4c05ce9dd94614ed781d85a50dccf69042521abc6782d48df85e6de9

Initial Sample Review

The initial sample is a relatively large 845KB, which is large for a script based file.

A script-based sample of this size is typically an indicator that there is going to be some heavy obfuscation or junk to deal with.

As the file is javascript and text-based, the next step is to open it up inside of a text editor for further review.

A text editor reveals that the script contains a huge number of junk comments, which is further shown by the mini-map on the right-hand side.

The style of the junk comments indicates that they were generated from a wordlist, and were likely added by some form of obfuscator.

By leveraging the highlighting provided by visual-studio code, we can scroll through the file to determine if there is any real functional code.

Every few hundred lines, there is a small piece of functional javascript containing the actual malware functionality.

Cleaning Up the Code and Obtaining Stage 2

At this stage we have identified the obfuscation (junk comments) and determined that there is real code located in the file.

To deal with this, we can use a regular expression to remove the junk comments by specifying that we want to remove any line beginning with double forward slashes.

This regular expression will specify that we want double forward slashes, followed by anything, followed by a newline. We have also added a caret ^ to specify that we only want this at the beginning of a line.

After applying the regular expression, we’re left with only 37 lines of code, which is significantly shorter than the original 1890.

However, 37 lines of code is still quite short. This gives the impression that there is something more interesting and tricky to this script.

If we observe the code more closely, we can see that it is opening and reading its own contents and looking for any lines that begin with 4 forward slashes.

This reveals that the “junk” comments were not all actually junk, some of them contained code which forms the next piece of the malicious script.

If we return to the original script, we can see that there is code on the lines containing four forward slashes.

The remainder of this stage is responsible for executing the “comments” in the original script.

Obtaining Stage 3

At this point we know that there is an additional piece of malware stored inside the comments of the original script.

Luckily, we know that the malicious portions are those that begin with four forward slashes. Hence we can use a regular expression to isolate these lines of code.

To obtain this next stage, we can load the original script (with junk comments) into CyberChef and use a regular expression to extract the lines beginning with four forward slashes.

We can also leverage a capture group and “List capture groups” to display only the malicious code and avoid displaying the forward slashes.

Review of Final Script

The results of the CyberChef operation can be moved into a text editor for final review.

On lines 17 of the new script, we can see that the malware attempts to map to a network drive at sokingscrosshotel[.]com

Once the network drive is mapped to a drive letter, the malware connects the drive using the net use command.

Once the drive is connected, the malware attempts to execute an upd.msi files using msiexec.exe.

Once the file is executed, the network drive is removed using RemoveNetworkDrive from the WScript.Network object.

Detection Opportunities

The malware leverages wmi to execute the net.exe and msiexec.exe commands.

This produces a process tree similar to that below. With the appropriate process creation logs, an analyst could search for wmiprvse.exe spawning net.exe with references to suspicious or unknown drive names.

The below command would produce a similar pattern. This could be hunted by looking for wmiprvse.exe spawning msiexec.exe with references to uncommon share names.

MITRE TTP:

  1. Obfuscated Files or Information (T1027): The use of junk comments to obfuscate the actual malicious code within the JavaScript file aligns with this technique. The obfuscation serves to hinder analysis and detection.
  2. Scripting (T1064): The malware is delivered and executed as a JavaScript file, leveraging scripting to perform its malicious activities.
  3. Resource Hijacking (T1496): Although not explicitly mentioned, the use of a remote .msi file and the mapping to a network drive could potentially be used for resource hijacking, depending on the contents and purpose of the .msi file.
  4. Command and Scripting Interpreter (T1059): The use of Windows Management Instrumentation (WMI) commands and the execution of msiexec.exe fall under this technique, as they are leveraging the command line interpreter to execute commands.
  5. Remote File Copy (T1105): The downloading and execution of a remote .msi file is an example of this technique, as the malware is transferring a file from a remote system to the local system for execution.
  6. Use of Network Shares for Lateral Movement (T1135): The malware attempts to map to a network drive, which could be used for lateral movement within a network.
  7. Execution through API (T1106): The use of WScript.Network object’s RemoveNetworkDrive method to remove the network drive after execution is an example of leveraging API calls for execution.
  8. Exfiltration Over C2 Channel (T1041): While not directly mentioned, the use of a remote .msi file and network drive mapping could potentially be used for exfiltrating data over a command and control channel.

Source: Original Post