Intelligence Blogs

FirstWatch Threat Spotlight: Unraveling SSLoad – A Multi-Stage Malware Menace

Author: Rajas Save

Published on: Wednesday, August 21, 2024

Executive Summary

SSLOAD, also known as ‘win.ssload,’ has emerged as sophisticated malware with capabilities extending from a simple loader to a robust information stealer. It is designed to infiltrate systems through phishing emails and contact forms, gather reconnaissance data, and transmit it back to its operators while delivering various payloads such as Cobalt Strike and ConnectWise ScreenConnect remote desktop software. This malware has rapidly gained notoriety due to its advanced capabilities and diverse delivery methods, highlighting its role in modern cyber espionage campaigns.

This comprehensive analysis identified SSLOAD’s key tactics, techniques, and procedures, providing detailed insights from multiple recent campaigns. SSLOAD was first detected in April 2024 and has since been involved in notable campaigns like Contact Forms and Frozen Shadow, targeting organizations across Asia, Europe, and the Americas. It uses phishing emails and compromised contact forms to deliver its malicious payloads, often leading to secondary infections with tools like Cobalt Strike, Latrodectus (a potential successor to IcedID), and the Pupy RAT.

NetWitness has developed specific detection mechanisms to identify and mitigate SSLOAD threats. Five Application Rules, available on NW Live, detect SSLOAD activities, including registration, module downloads, secondary payload requests, and task beaconing. Additionally, rules for outbound IP checker traffic and updated DynDNS Lua Parser enhance detection. IOCs from this research are added to Malware C2 feeds on NW Live, improving threat intelligence and detection capabilities.

Key Findings

• Sophisticated Attack Chain: SSLOAD employs a multi-stage infection process, from initial phishing emails to sophisticated payload delivery, including fake Azure login pages and malicious JavaScript files.
• Versatile Payload Delivery: The malware delivers various secondary payloads, enhancing its ability to conduct post-exploitation activities and lateral movement within compromised networks.
• Advanced Evasion Techniques: SSLOAD communicates with its Command-and-Control (C2) server using encrypted payloads and specific user-agent strings, making detection and analysis challenging.
• Global Targeting: SSLOAD has been observed targeting organizations worldwide, focusing on Asia, Europe, and the Americas.

Analysis of SSLoad with NetWitness

Initial Infection Vector

SSLoad typically enters systems through phishing emails. These emails may contain decoy documents exploiting known vulnerabilities or prompting users to enable macros to execute the malicious payload. In other cases, links in the email direct users to malicious websites that download the malware.

A common infection chain begins with the execution of msiexec.exe to install a malicious MSI package (sharepoint.msi).

This process triggers the following sequence of actions:

• msiexec.exe is initiated to install sharepoint.msi.
• msiexec.exe runs with elevated privileges.
• MsiExec.exe operates in embedding mode to continue the installation.
• srtasks.exe is executed to create a system restore point.
• A temporary MSI file (MSI7AF0.tmp) runs regsvr32.exe with the /S flag to silently register MenuEx.dll, a legitimate-looking DLL carrying the following stages of the SSLoad payload.

Second Stage: Loader

The loader is a lightweight DLL written in C/C++. It loads the SSLoad payload and sets its execution point. The loader is added to a legitimate DLL, usually from EDR or AV products, by binary patching the file and employing self-modifying techniques to evade detection. Analysis of its metadata reveals that the loader attempts to disguise itself as a legitimate DLL named ‘MenuEx.dll,’ associated with 360 Total Security, a Chinese antivirus program. This loader uses several anti-analysis techniques to evade detection, such as checking the Process-Environment-Block (PEB) for the BeingDebugged flag. This technique helps malware avoid execution in environments where security researchers might analyze it.

Once the initial payload is executed, the loader attempts to gather information about the infected system. One of the early steps involves using a legitimate IP lookup service to find the infected system’s external IP address. This lookup helps the malware prepare for further stages of its operation, including communication with its Command-and-Control (C2) server and targeting additional payloads based on the system’s location and network configuration.

This activity can be identified in Netwitness using query – analysis.service = ‘ip checker service’ or boc = ‘host traffic to external ip checker’.

Third Stage: SSLoad Downloader

The SSLoad Downloader’s primary function is to download and execute additional malicious components. A notable feature of SSLoad is its unique method for decrypting strings. Each string’s decryption key is derived from specific bytes of the encrypted blob. The malware uses a custom function to determine the length of the encrypted string, applying Base64 decoding followed by RC4 decryption.

This SSLoad variant begins by decrypting a URL and a user agent. The URL directs to a Telegram channel named SSLoad, which serves as a dead-drop site. This channel contains another encrypted string that indicates the Command-and-Control (C2) server responsible for delivering the final payload.

Address with the corresponding user agent:

• hxxps[:]//t[.]me/+st2YadnCIU1iNmQy
• Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36

After deciphering the C2 address, the malware unveils a second user agent string, ‘SSLoad/1.1,’ along with the “/api/g” string. It then performs an HTTP GET request to generate a URL to download the subsequent payload from the C2 server. In this case, the server responds by sending the file as an attachment named “crypted_dll.bin.” This network traffic can be identified using an NW query attachment = ‘crypted_dll.bin.’ This file is a crucial part of the SSLoad infection process, containing the encrypted payload that will be decrypted and executed on the compromised system.

Several interesting indicators are highlighted during network traffic analysis, which is crucial for threat hunting. The Content-Type field in the HTTP headers contains unique values such as “Los Angeles” and “Cosmos.” These values are not typically associated with standard HTTP traffic, making them exciting parameters to examine during threat hunting.

A network-based application rule, ‘SSLoad Secondary Payload Request,’ has been created to identify outbound HTTP requests that match a specific pattern associated with SSLoad’s attempt to fetch additional payloads. The request is characterized by the client user-agent string ‘ssload/1.1’ and a directory path of ‘/api/g’.

Detecting these criteria helps identify when SSLoad is trying to download secondary payloads after the initial infection.

After creating an incident and visualizing it as a nodal graph in NetWitness Respond, shared files and directory structures among different samples are highlighted.

Fourth Stage: SSLoad Payload

The primary payload is a 32-bit DLL written in Rust. SSLoad employs sophisticated C2 communication methods, making it difficult for analysts to extract the malware’s configuration. After decrypting the C2 address, SSLoad retrieves additional payloads or commands. These interactions typically involve sending system information to the C2 server, helping attackers understand the compromised environment and plan further actions.

SSLoad incorporates several anti-analysis and evasion techniques to avoid detection and analysis:

• Mutex Creation: The malware creates a mutex to check if the system is already infected, ceasing execution if it detects an existing infection.
• Dynamic Library Loading: It dynamically loads libraries like Advapi32.dll to locate specific functions such as RtlGenRandom, which generates unique names for its operational folders.
• Unique XOR Keys: Each string decrypted by SSLoad uses a unique XOR key generated through complex arithmetic operations, complicating static analysis.

SSLoad enumerates connected drives, attempting to read the root path of hard drives other than the default C: drive, highlighting its capabilities in peripheral devices and system information discovery.

Variables are initialized to manage the number of connection attempts and the connection status to a network share. The script then checks for available drive letters ranging from A to Z and tries to map a selected drive letter to a network share controlled by the attacker in a loop.

Post Exploitation Command-and-Control Interactions

Once the primary payload is executed, the malware interacts with the Command-and-Control (C2) server. The DLL starts by fingerprinting the infected system and preparing to send a registration beacon to the C2 server. The fingerprinting process gathers various details about the system, which are compiled into a JSON object with the following fields:

• version: The version of the loader is hardcoded into the binary.
• ip: The public IP address obtained using api.ipify.org.
• domain: The Windows network domain.
• hostname: The computer’s hostname, taken from the environment variable.
• arch: The architecture of the infected machine, taken from the environment variable.
• os_version: The version of the Windows operating system retrieved using GetVersionExW.
• cur_user: A string indicating whether the current user is an administrator.
• owner: Appears to indicate the campaign name.

This JSON fingerprint is sent to the C2 server in plaintext via an HTTP POST request. If the registration is successful, the C2 server responds with a JSON object containing a “key” and an “ID.” The “key” field is a Base64 string used as an RC4 key in later communications, while the “ID” is a unique identifier for the infected host. The malware uses this identifier to identify itself to the C2 server during subsequent HTTP requests.

NetWitness employs a regex-based application rule named ‘SSLoad Registration Request’ to detect SSLoad registration requests within network communication. This rule targets explicitly outbound HTTP POST requests to ‘/api/gateway’ with an ‘application/json’ content type. It uses a regex pattern to identify JSON objects that include fields like ‘version,’ ‘ip,’ ‘domain,’ hostname, ‘arch,’ ‘os_version, ‘cur_user,’ and ‘owner.’

These criteria indicate SSLoad’s registration process with its C2 server. By detecting these unique query strings, NetWitness can effectively identify and flag SSLoad registration activities, providing early detection of the malware’s presence in the network.

After registration, SSLoad enters a task beaconing loop, where it periodically sends HTTP POST requests to the C2 server, using the unique identifier as part of the URL path (/api/[unique_identifier]/tasks). No data is sent in the initial POST request. If the C2 server has a task for the infected host, it responds with a JSON structure containing a “job” and another unique identifier for the job. The job is an RC4-encrypted struct encoded as a Base64 string containing two fields: a “command” and an array of arguments.

NetWitness has developed the ‘SSLoad Task Beacon Attempt’ application rule to detect these task beacon attempts. This rule is designed to catch outbound HTTP POST requests to API endpoints like ‘result’ or ‘tasks.’ The client user-agent string mimics a standard web browser, and the directory path follows a specific regex pattern indicating a UUID. These criteria help identify SSLoad’s task beacon attempts to its C2 server, allowing for effective monitoring and interception of task communications.

Observed commands include “exe,” which directs the malware to download an additional payload from a specified URL. The structured format of the job field indicates that SSLoad can easily be expanded to support more commands in the future.

A new network detection rule, ‘SSLoad Module Download Request,’ has been developed to identify HTTP GET requests SSLoad uses to download additional modules. This rule explicitly targets patterns including a distinctive query structure such as “GET /download?id=Cosmos&module=2&filename=None HTTP/1.1.” and a client user-agent string mimicking a standard web browser. This detection is crucial for intercepting module download attempts directly to an IP address, helping prevent further compromise.

An interesting finding in the analysis of SSLoad’s behavior is the pattern in the download string “GET /download?id=Cosmos&module=2&filename=None HTTP/1.1.” The value “id=Cosmos” is particularly noteworthy as it matches the unique “Content-Type: Cosmos” observed in the Third Stage: SSLoad Downloader. This correlation is further supported by the user-agent string SSLoad/1.1 found in the “GET /api/g HTTP/1.1” request.

The following identified network traffic could result from the SSLoad malware completing a task assigned by the C2 server. When SSLoad receives a task from the C2 server, it typically includes a job ID and specific encrypted instructions to be executed by the compromised machine.

This indicates that the C2 server assigned the compromised machine a task with a job ID. After completing the task, the compromised machine sends back a beacon to /result to notify the C2 server about the job status using the encrypted result.

A new network detection rule, ‘SSLoad Result Beacon Attempt,’ is designed to detect outbound HTTP POST requests to ‘/result’ endpoints. The requests are characterized by a directory path following a specific regex pattern indicating a UUID and JSON content. The query contains the fields ‘job_id’ and ‘result,’ which indicate SSLoad’s communication back to its Command-and-Control (C2) server.

Conclusion

SSLoad is a highly sophisticated and adaptable malware that poses a significant threat to organizations worldwide. Its multi-stage loading process, encrypted communications, and advanced anti-analysis techniques demonstrate the increasing complexity of modern cyber threats. As SSLoad continues to evolve, understanding its technical details and distribution methods is crucial for developing effective defense strategies.

NetWitness provides comprehensive capabilities to detect and respond to sophisticated threats like SSLoad through advanced analytics and threat intelligence. NetWitness NDR (Network Detection and Response) monitors network traffic. At the same time, NetWitness EDR (Endpoint Detection and Response) secures endpoints, NetWitness SIEM, SOAR, and TIP for threat detection, investigation, and response across the IT infrastructure for real-time insights. Organizations can significantly enhance their defense against complex threats by leveraging these tools. For more information, visit https://www.netwitness.com/products/.

Thank you, Darren McCutchen and Jeanette Miller-Osborn, for valuable feedback and direction.

NetWitness Detection Capabilities and Takeaways

NetWitness has developed specific detection mechanisms to help identify and mitigate the threat SSLoad poses. Five Application Rules have been created to detect SSLoad activity within the network. These rules are available on NW Live and focus on identifying various stages of SSLoad’s operation, including its registration, module downloads, secondary payload requests, and task beaconing activities post-exploitation:

• SSLoad Secondary Payload Request (ioc = ‘ssload secondary payload request’)
• SSLoad Registration Request (ioc = ‘ssload registration request’)
• SSLoad Task Beacon Attempt (ioc = ‘ssload task beacon attempt’)
• SSLoad Module Download Request (ioc = ‘ssload module download request’)
• SSLoad Result Beacon Attempt (ioc = ‘ssload result beacon attempt’)

Another existing rule, boc = ‘host traffic to external ip checker’, looks for any outbound traffic to four IP checker sites used by malware. This rule does not indicate something malicious is happening on its own; however, it can be a data point for further investigation and threat-hunting exercises across NetWitness EDR, SIEM, and NDR. Additionally, the DynDNS Lua Parser registers analysis.service = ‘ip checker service’ meta for traffic to known IP lookup websites. This list has been updated to reflect new services discovered during various FirstWatch research.

IOCs identified during this research have also been added to the Malware C2 feeds available on NW Live. These feeds help enhance threat intelligence and provide updated information for detecting SSLoad-related activities.

References

• https://malpedia.caad.fkie.fraunhofer.de/details/win.ssload
• https://x.com/Unit42_Intel/status/1780021135813337366
• https://intezer.com/blog/research/ssload-technical-malware-analysis/
• https://github.com/PaloAltoNetworks/Unit42-timely-threat-intel/blob/main/2024-04-15-IOC-for-Contact-Forms-campaign-SSLoad-activity.txt
• https://www.securonix.com/blog/securonix-threat-research-security-advisory-frozenshadow-attack-campaign
• https://github.com/executemalware/Malware-IOCs/blob/main/2024-04-17%20SSLoad%20IOCs
• vxintel.io
• https://private.tria.ge/

MITRE Techniques