New SolarMarker (Jupyter) Campaign Demonstrates the Malware’s Changing Attack Patterns

The initial stage is an EXE file larger than 250MB (the large file size helps to avoid inspection by an automated sandbox or an AV engine). In this case, the file analysts analyzed was called setup.exe. based on the sample compilation date in February 2022, the demonstrated artifacts belong to a new development in the malware lifecycle.
This file is a .NET-compiled dropper that will drop and execute an installer of a legitimate program to avoid raising the user’s suspicion toward the downloaded binary.

In parallel, the malware runs a PowerShell loader in a new thread to load and execute the SolarMarker backdoor payload.
We can see the loaded script decoded by debugging the PowerShell invoke function.

– showWindowAsync makes PowerShell windows hidden to conceal malicious activity from the plain sight of users.
– Writes the encrypted base64 payload of the SolarMarker backdoor to file with random extension into the TEMP folder.
– Achieves persistence using the lnk file in the startup folder. The target file of the lnk is the encrypted base64 payload of the SolarMarker backdoor with the random extension. (This file cannot be run directly).
– In Windows environments, every file extension is associated with a default program. The associations of extensions with programs are handled through the registry. SolarMarker sets a handler to the custom random extension to run the encrypted payload. This handler is a PowerShell script that decrypts the payload and loads the bytes of the encrypted payload (backdoor) into memory.
The attacker avoids downloading the assembly to disk and subverts it using the ”Load” method, which accepts a byte array instead of a file. The loading technique is called Reflective Code Loading.

In the first execution of the malware on the victim machine, the encrypted payload (backdoor) will load into the first stage of the malware (setup.exe) because, as analysts mentioned earlier, setup.exe opened a new thread in which it ran the PowerShell script.

After the reboot, the encrypted payload will load directly into the PowerShell process due to the lnk file from the startup folder.

When looking at the decompiled code and the names of the classes and functions, one can see that they don’t look right. Instead, they look like they are obfuscated.
The SolarMarker backdoor is a .NET C2 client that will communicate with the C2 server within the encrypted channel.
The protocol communication is HTTP – usually POST requests.
The data is encrypted using RSA encryption with Advanced Encryption Standard (AES) symmetric encryption.

The client performs internal reconnaissance, collects basic information about the victim machine and exfiltrates it over an existing C2 channel.
The client sends a signal to the attacker’s server to check for instructions or additional payloads at regular intervals (60 seconds).

The attacker can run a PowerShell script and transfer files to the victim machine.

The next stage is again a PowerShell encoded script that deploys the SolarMarker final payload (.NET Infostealer) and loads it into memory (this typically occurs about a few hours after the initial infection of the victim machine).
The attackers’ servers and version names vary between the backdoor and infostealer modules.
In terms of its structure, the infostealer module looks very similar to the backdoor module analysts introduced earlier but has extended capabilities.
The SolarMarker infostealer module acquires login data, cookies and web data (auto-fill) from web browsers by reading files specific to the target browser. SolarMarker uses the API function CryptUnprotectData (DPAPI) to decrypt the credentials.