/ MALWARE, JS

SSLoad

MalwareBazzar: 092962bc268390debf17cd148d03147cd919e42e61c92de01eac3bdb34b1c

Analysis of SSLoad JS Malware

SSLoad emerges as a recent addition to the malware landscape, originating from a Rust-based architecture. Its nomenclature is derived from its early Command and Control (C2) infrastructure, which utilized a first-stage DLL connecting to a Telegram channel named ‘SSLoad’ to retrieve additional URLs. Upon retrieval, a compressed PE file is downloaded via HTTP, employing a hardcoded User-Agent (SSLoad/1.x) and Content-Type . For a broader understanding of its operational scope, an examination of the FROZEN#SHADOW campaign, as discussed by Den Iyzvyk, Oleg Kolesnikov, and Tim Peck, is recommended.

Commentary on Code Structure

SSLoad Upon reviewing the code associated with SSLoad, a significant amount of it is comment-heavy sections. The code exhibits a pattern for every 19 lines follows are a space or eight forward slashes devoid of spacing. This pattern extends across 1177 lines until encountering the first variable declaration invoking a function. Initial efforts involved the systematic removal of lines prefixed with “// {word}”. My approach to spotting this patern came through the instantiation of “var network = new ActiveXObject…”, which stood out beyond the wall of comments. This culling process reduced the codebase from 2,000 to 410 lines, with no notable obfuscation in variable naming or other elements. This malware only works through obsfucation by reader fatigue or gulability.

Initial Penetration Analysis

Unveiling the Facade

SSLoad Two distinct sections of code emerge after culling the file: one delineated by active code and the other inundated with commented-out segments. The active code segment entails variable declaration, including function instantiation, ActiveXObject for FileSystemObjects, retrieval of script identity, and the creation of an empty content string. Three functions are defined:

  1. Function “e” verifies its existence, accesses itself, and retrieves lines containing multiple forward slashes, storing them in variable “d” before closing the file stream.
  2. Function “h” dissects commented-out code and executes it as a function, circumventing the conventional employment of an eval statement.
  3. Function “j” orchestrates the invocation of functions “e” and “h” within a try-catch block, facilitating silent error handling. The execution culminates in invoking “j” and parsing the JavaScript file itself.

Delving Deeper

SSLoad SSLoad The subsequent code sections exhibit improved naming conventions compared to the prior segment. Notable features encompass an ActiveXObject for network connectivity, alongside variables tracking connection status, attempts, and drive letters pertinent to the network. A function assesses mapped drive status, followed by a for loop iterating from the letter “z” downwards, attempting to establish connectivity to “${letter}:\krd6.com@80\share". Subsequent steps involve drive connection via winmgmt and unobtrusive installation of the “avp.msi” file using msiexec upon successful network drive connection. A final phase entails attempted disconnection of the network drive, precipitating the initiation of the second-stage payload.

Concluding Remarks

The analysis of SSLoad reveals a cacophony of Code comments both relavant and not. Notably, the evasion of eval statements in favor of alternate execution pathways underscores a strategic departure from conventional malware approaches. Despite the encumbrance posed by copious code comments, the deciphering process was streamlined through systematic pruning. Furthermore, the file ends with an extraction of malicious payloads from the krd6 server in Russia. For further technical insight into subsequent payload behavior, reference to Joe Sandbox ID: 1427450 is recommended.