ANY.RUN’s team conducted an extensive malware analysis of CastleLoader, the first link in the chain of attacks impacting various industries, including government agencies and critical infrastructures. 

It’s a unique walkthrough of its entire execution path, from a packaged installer to C2 server connection, as well as an overview of a parser developed to extract initialized local variables and automatically decode indicators of compromise (IOCs) featured in them. 

Key Takeways 

• CastleLoader is a stealthy malware loader used as the first stage in attacks against government entities and multiple industries. 

• It relies on a multi-stage execution chain (Inno Setup → AutoIt → process hollowing) to evade detection. 

• The final malicious payload only manifests in memory after the controlled process has been altered, making traditional static detection ineffective. 

• CastleLoader delivers information stealers and RATs, enabling credential theft and persistent access. 

• A full-cycle analysis allowed us to extract runtime configuration, C2 infrastructure, and high-confidence IOCs. 

CastleLoader as an Initial Access Threat 

CastleLoader is a malicious loader malware built to deliver and install other malicious components. It lays the groundwork for the attack, becoming its starting point. 

This loader has commonly occurred in cyber attacks since early 2025. It gained popularity due to its high infection rate and universal nature, making it a powerful yet evasive tool. 

One of CastleLoader’s malicious campaigns is known to impact a total of 469 devices. It became a significant threat to organizations, especially US-based government entities. Its broader scope includes industries like IT, logistics, travel, and critical infrastructures across Europe. 

CastleLoader is dangerous as a link in the chain delivering information stealers and  RATs, making credential theft and persistent network access a high risk. 

The loader’s popularity has inspired ANY.RUN’s malware analysis team to break down its malicious sample in order to uncover what it’s made of, retrieve signatures, and retrieve  malware configurations. 

Detect CastleLoader and More with Threat Intelligence Feeds 

Modern malware like CastleLoader is designed to evade traditional detection. To keep up with the pace of adversaries, security teams need threat intelligence that reflects what attackers are using right now. 

ANY.RUN’s Threat Intelligence Feeds provide real-time indicators extracted from live malware executions performed by thousands of SOC teams worldwide. With TI Feeds, they achieve: 

• Faster threat detection: Identify active loaders, stealers, and RATs as soon as they appear in real-world attacks thanks to 99% unique data extracted from the latest sandbox analyses by 15K SOCs and 500K analysts. 

• Higher confidence decisions: Indicators are backed by execution context, not guesswork or outdated reports. 

• Improved SOC efficiency: Fewer false positives mean less alert fatigue and better use of analyst time. 

• Stronger risk management: Early visibility into emerging malware families helps prevent business disruption. 

By combining real-time sandbox intelligence with immediate IOC delivery, ANY.RUN TI Feeds help organizations stay ahead of fast-evolving threats like CastleLoader. 

Initial Analysis: Sandbox Telemetry 

The analysis started with ANY.RUN’s Interactive Sandbox detonation.  

View analysis 

What instantly grabs our attention here is a system process chain, at the end of which a request to 94[.]159[.]113[.]32:80 was sent. To understand this activity better, we switched to the binary analysis. 

Static analysis: Inspecting Inno Setup Installer  

To get a basic overview of the binary, let’s process it via DIE (Detect It Easy).  

It reveals that the binary consists of Object Pascal (Delphi) and Inno Setup Module (installer). 

The next stage of the analysis requires the use of innoextract, a tool to unpack installers. We used a fork that allows you to unpack password-protected archives, which came in handy. 

Archive extraction reveals several executables. At this point, it’s Autolt3.exe and the compiled script freely.a3x that grab our attention most. These are the files that directly participate in the calling chain. Other files, as it turned out later, aren’t related to the malware execution, and their role is unclear. 

Next, let’s use Autolt-Ripper to extract compiled Autolt scripts from A3X containers. As a result of this, we get a file script.au3 containing 24,402 code lines. The majority of this code, which is responsible for the malicious chain, is unreadable: 

// A function’s minimal listing 

Func FUNC_38 ( $XGOHK_KNZJTRNG , $FRNQQSFKMV_ONCPFFG_IUESI , $OYJVN ) 

  Local $VAR_2745 [ 5 ] = [ ( $FOCOFQYNAZZDTMNK [ 0 ] [ 0 ] <= $VAR_1884 ? $APITY_TTXPNVODYF_UOFBAYSHE : 51205 ) , 51215 , ( $DCZH1PQYFZ0_9_S_KG8_Q3 < $WGCOD_JPCLUUNAEM [ 1 ] ? 51217 : $HQBFEELFMG_MKBEGBLQI ( ) ) , ( $XCEAEI_JVVDYWYNZG_VYLLS >= $G_HGLSAQTEAFZZZONMJ [ 6 ] ? $GVNKFKFUPA_XKWCWRP_GQDKXPY ( ) : 51193 ) , ( $UNPBEN < $G_HGLSAQTEAFZZZONMJ [ 8 ] ? 51205 : $VAR_1654 [ 1 ] [ 7 ] ) ] 

  Local $NWBSM 

  Local $JIQBD 

  For $JIQBD = ( $MON_GLZO__BPDFZTL [ 3 ] > $MON_GLZO__BPDFZTL [ 9 ] ? 0 : $VAR_364 [ 0 ] [ 0 ] ) To ( $G_HGLSAQTEAFZZZONMJ [ 6 ] <= $FOCOFQYNAZZDTMNK [ 0 ] [ 3 ] ? $VBTVZVORQTC : 4 ) 

    $NWBSM = $VAR_2745 [ $JIQBD ] 

    $NWBSM -= $JIQBD 

    $NWBSM += 14431 

    $NWBSM = $IGFABA_UFUGKAMKV ( $NWBSM , $JIQBD ) 

    $NWBSM = $RM_I2U_3RPS4_I5Y0IIHAZ1_6 ( $NWBSM , 65535 ) 

    $VAR_2745 [ $JIQBD ] = $IDBABKRDVSBFUNLRSLIOXWAD ( $NWBSM ) 

  Next 

  $VAR_2745 = $WWXHKDX ( $VAR_2745 , "" ) 

  Return $VAR_2745 

EndFunc

Still, we are able to learn about the loaded modules and WinAPI wrappers: 

// Some of the kernel32.dll module’s wrappers

Func _WINAPI_ASSIGNPROCESSTOJOBOBJECT ( $HJOB , $HPROCESS ) 

  Local $ACALL = DllCall ( "kernel32.dll" , "bool" , "AssignProcessToJobObject" , "handle" , $HJOB , "handle" , $HPROCESS ) 

  If @error Then Return SetError ( @error , @extended , False ) 

  Return $ACALL [ 0 ] 

EndFunc 

Func _WINAPI_ATTACHCONSOLE ( $IPID = + 4294967295 ) 

  Local $ACALL = DllCall ( "kernel32.dll" , "bool" , "AttachConsole" , "dword" , $IPID ) 

  If @error Then Return SetError ( @error , @extended , False ) 

  Return $ACALL [ 0 ] 

EndFunc 

Func _WINAPI_ATTACHTHREADINPUT ( $IATTACH , $IATTACHTO , $BATTACH ) 

  Local $ACALL = DllCall ( "user32.dll" , "bool" , "AttachThreadInput" , "dword" , $IATTACH , "dword" , $IATTACHTO , "bool" , $BATTACH ) 

  If @error Then Return SetError ( @error , @extended , False ) 

  Return $ACALL [ 0 ] 

EndFunc 

Func _WINAPI_CREATEEVENT ( $TATTRIBUTES = 0 , $BMANUALRESET = True , $BINITIALSTATE = True , $SNAME = "" ) 

  If $SNAME = "" Then $SNAME = Null 

  Local $ACALL = DllCall ( "kernel32.dll" , "handle" , "CreateEventW" , "struct*" , $TATTRIBUTES , "bool" , $BMANUALRESET , "bool" , $BINITIALSTATE , "wstr" , $SNAME ) 

  If @error Then Return SetError ( @error , @extended , 0 ) 

  Local $ILASTERROR = _WINAPI_GETLASTERROR ( ) 

  If $ILASTERROR Then Return SetExtended ( $ILASTERROR , 0 ) 

  Return $ACALL [ 0 ] 

EndFunc 

Func _WINAPI_CREATEJOBOBJECT ( $SNAME = "" , $TSECURITY = 0 ) 

  If Not StringStripWS ( $SNAME , $STR_STRIPLEADING + $STR_STRIPTRAILING ) Then $SNAME = Null 

  Local $ACALL = DllCall ( "kernel32.dll" , "handle" , "CreateJobObjectW" , "struct*" , $TSECURITY , "wstr" , $SNAME ) 

  If @error Then Return SetError ( @error , @extended , 0 ) 

  Return $ACALL [ 0 ] 

EndFunc 

Func _WINAPI_CREATEMUTEX ( $SMUTEX , $BINITIAL = True , $TSECURITY = 0 ) 

  Local $ACALL = DllCall ( "kernel32.dll" , "handle" , "CreateMutexW" , "struct*" , $TSECURITY , "bool" , $BINITIAL , "wstr" , $SMUTEX ) 

  If @error Then Return SetError ( @error , @extended , 0 ) 

  Return $ACALL [ 0 ] 

EndFunc 

Several WinAPI wrappers may potentially participate in attacks for further system infection, because it’s the Autolt scrip that prepares the environment and control handover. 

Key function calls 

This combination of functions looks suspicious and hints at cross-process manipulations: 

kernel32.GetProcAddress — Dynamic function resolution 

kernel32.CreateFileW — Working with files 

kernel32.CreateProcessW — Creating processes 

kernel32.CreateMutextW — Creating mutexes 

kernel32.OpenProcess — Opening process descriptors 

kernerl32.ReadProcessMemory — Reading the memory of other processes 

kernerl32.DuplicateTokenEx — Duplicating security tokens 

kernelbased.AdjustTokenPriviliges — Manipulating the privileges 

kernel32.WriteFile — Writing into files

Since full-scale deobfuscation would take up too much time, let’s switch to dynamic analysis for now. 

Dynamic Analysis: Tracing Execution 

Let’s launch Autolt3.exe in x32dbg with breakpoints at functions that we’ve listed above, with the compiled script freely.a3x as a parameter. 

Soon after the initialization of Autolt3.exe, we see a kernel32.CreateProcessW call, where jsc.exe, the final link of our chain, is located. 

Note: this is a JScript.NET compilator, a part of an older .NET Framework. What’s unusual is that no extra data is transmitted to lpCommanLine. 

Also, there’s a CREATE_SUSPENDED flag in dwCreationFlags, which points to an uncommon use of jsc.exe. But how does it get the payload? 

The next string of calls reveals this: 

• kernel32.CreateProcessW creates the jsc.exe process flagged as CREATE_SUSPENDED. 

• kernel32.GetThreadContext delivers registries — the context of the main flow. This is typical for the preparation to process hollowing. 

• kernel32.VirtualAllocEX allocates a 0x3B000-sized memory area in jsc.exe process with MEM_COMMIT | MEM_RESERVE flags and PAGE_EXECUTE_READWRITE protection. This allows you to place and launch any code. 

To confirm this and extract the key module, let’s keep tracing the malware. The next critical call is kernel32.WriteProcessMemory. Among its arguments is a pointer to a buffer with loaded data, featuring familiar PE Magic and DOS Stub signatures. This clearly means that a PE file is injected into the jsc.exe process. 

At this stage, we can safely dump a clean binary from the memory. 

The payload is revealed, but we continue unraveling the entire chain until the final call — kernel32.ResumeThreat. This will help us make sure that the malware doesn’t do anything extra, like embedding another hidden process, before the control handover.  

The next critical step is the call of kernel32.ReadProcessMemory. At this stage, the threat obtains a pointer to the PEB (Process Environment Block) structure, from which it extracts a PEB.ImageBaseAddress (base load address). This address is further rewritten to the injected PE module. That’s crucial for standard loading mechanisms of Windows, including early ntdll.LdrInintializeThunk initialization, as this allows for the correct processing of import tables, relocating, and restoring of the image’s data. 

After this, kernel32.WriteProcessMemory is called, which completes the stage of replacing the base address in the PEB structure. 

Next, kernel32.SetThreadContext is invoked, almost finalizing the process hollowing. At this stage, the malware writes a pointer to the entry point of the injected module into the EAX register. 

After the call to kernel32.ResumeThread, control is handed over to ntdll.LdrInitializeThunk, which performs loader initialization and prepares the process execution environment. 

Once initialization is complete, ntdll.LdrInitializeThunk calls ntdll.NtContinue, restoring the execution context. 

As a result, the execution continues from the address stored in the EIP register. This is the beginning of the ntdll.RtlUserThreadStart procedure, which places the entry point from the EAX register onto the stack in accordance with the __stdcall calling convention and then hands over control to ntdll.__RtlUserThreadStart. 

Notably, this is not a common process hollowing. The regular method includes the extraction of the original memory area via NtUnmapViewOfSection. But in CastleLoader’s case, the malware dismisses this step intentionally. 

To monitoring tools like System Informed, the process doesn’t look off. It’s also not a part of an event chain known to EDR. 

This decreases the probability of detection without disrupting the processing of all tables and structures, ensuring normal functioning of the injected module. 

Preliminary Results 

The original Inno Setup installer turned out to be a container with a set of auxiliary files, among which the AutoIt3.exe + freely.a3x combination played a key role. We were able to extract and partially decompile the AutoIt script; however, most of its logic was heavily obfuscated and consisted of numerous wrappers around the WinAPI. 

Static analysis showed that the script prepares the environment and launches the next stage, while dynamic analysis confirmed that after jsc.exe is started, one of the process hollowing techniques is executed: another executable module is injected into the process’s address space. 

As a result, we discovered a fully functional PE file — the main CastleLoader module —  inside the process and successfully dumped it for further analysis. 

Such a sophisticated multi-stage execution chain was not implemented merely to complicate analysis, but specifically as an attempt to conceal the execution of the main payload from detection mechanisms. Using Inno Setup as a container, an AutoIt script as an intermediate layer, and process hollowing over jsc.exe, allows CastleLoader to distribute across several components that appearbenign at first glance. 

After the loader completes its execution, the files extracted by the Inno Setup installer remain on the disk. This may either be a deliberate attempt to mimic the normal behavior of legitimate software, which often leaves installation artifacts behind, or simply an implementation flaw. Given the relative novelty of the malware family, it’s probably the latter.  

This execution model reduces the likelihood of detection, as each individual stage appears legitimate, and the final payload only manifests in memory after the controlled process has been altered. As a result, static signatures, simple behavioral heuristics, and process monitoring systems become ineffective. A fully functional malicious module exists only at runtime, and only within an already modified process. 

Static signatures, simple behavioral heuristics, and process monitoring systems become ineffective 

Going Back to Static Analysis 

After uploading the memory dump to Ghidra, let’s start the analysis of its execution context. Right after opening the dump we see a kernel32.MessageBoxW call, which displays a fake error message: “System Error. The program can’t start because VCRUNTIME140.dll is missing from your computer. Try reinstalling the program to fix this problem.” 

After that, the execution of malicious code continues. 

During the analysis, we can see functions with unclear values. By studying their references, we see that they are actively called throughout the program’s execution. 

In FUN_00e469f0, the first argument of the function is a pointer to the start of the PE module. At first, the value is dereferenced and checked for a DOS heading 0x5A4D (“MZ”). This is followed by NT heading’s validation and decomposition of PE’s key structures. 

The function manually gets access to the export table, allowing for a rewrite of the basic module address (IMAGE_DOC_HEADER*). Then each exported character goes through an embedded hash function, while the calculated hash is compared to the initial value.  

Since we now know the origin of each digest and the way the function resolves the required APIs by hash, we can gather a set of potentially used network functions, run them through the hashing algorithm, and generate an enumeration (enum) for Ghidra. 

Using the script, we automatically replaced all hashes with their corresponding function names — the result can be seen in the Equates Table. Each hash is now tied with a readable API name, along with the number of cross-references to it. 

This also makes it easy to track all calls of these functions via the References section, where for each usage point there’s a reference to the corresponding API address. 

After generating the enum and substituting API names in the Equates Table, we see that the binary uses WINHTTP.WinHttpOpen. Cross-references to the corresponding hash prove that. We annotated a function with this call to make it easier to follow the logic. Then, by examining the cross-references to this function, we can move to its caller — the point where the HTTP session setup begins. 

While examining the HTTP connection’s initialization stage, we identified a function that returns a pointer to the data structure used as the initial configuration for the network logic. The format of this structure isn’t clear; but the fact that it’s there suggests the presence of a dedicated procedure responsible for creating and populating the configuration structure. 

We annotated several references around the returned pointer and proceeded to analyze the function that forms the configuration structure. This is done to restore its components and understand which parameters are used for network connection. 

Several nested functions lead us to a large-scale procedure, during which the configuration data is prepared. Its values aren’t static strings, but a mass of encrypted bytes packaged into DWORDs with two UTF-16LE characters and placed right on the stack. This data is postprocessed with a simple bit-by-bit transformation into string buffers. 

The temporary buffers are then passed to UniStr::Copy and pasted into fixed global addresses. All of these addresses are laid out sequentially in .data sections, effectively forming a single contiguous configuration block. 

At the end, the function returns the address of the first element (0xE67830), allowing the entire data set to be used as an array or a structure with fixed offsets. 

An example of a decryption algorithm 

input[8] = 0x67; 

input[9] = 0x4a; 

input[10] = 0xda; 

input[0xb] = 0xb6; 

step = 0; 

input[0xc] = 99; 

input[0xd] = 0x7d; 

input[0xe] = 0xa0; 

input[0xf] = 0xe4; 

input[0x10] = 0x31; 

input[0x11] = 0x62; 

input[0x12] = 0x87; 

input[0x13] = 0xa7; 

input[0x14] = 0x62; 

input[0x15] = 0x49; 

input[0x16] = 0x98; 

input[0x17] = 0x98; 

input[0x18] = 0x6c; 

input[0x19] = 0x6d; 

input[0x1a] = 0xbf; 

input[0x1b] = 0xaa; 

input[0x1c] = 0; 

do { 

  output[step + 8] = (ushort)(byte)(&key)[step & 3] ^ input[step + 8]; 

  output[step + 9] = (ushort)(byte)(&key)[step + 1 & 3] ^ input[step + 9]; 

  output[step + 10] = (ushort)(byte)(&key)[step + 2 & 3] ^ input[step + 10]; 

  step = step + 3; 

} while (step < 0x15); 

UniStr::Copy(&DAT_00e67848,(short *)(output + 8)); 

// In this fragment, there’s a small static block of data (byte array) formed. 

// Then, bit-by-bit, it’s decrypted by undergoing XOR operation with a cyclic one-table key. 

// Decrypted bytes are extended to UTF-16LE characters and written into an exit buffer, which is then pasted into the global memory region 

// via UniStr::Copy. 

// Basically, this is a simple custom decryption of strings using fixed bytes arrays and cyclic XOR masking by index with transformation to Unicode.

Building a Custom Parser 

After manually decrypting several strings, we realized that the process could be automated. The extraction logic used by CastleLoader is known: it has a single UTF-16LE DWORD pattern, loop construct, and fixed addresses, from which the XOR bytes are taken. That’s enough to identify the repeating code fragments and write a Python script that extracts all strings from the dump in a single pass. 

Parser’s results 

E32E6D: %s/settings/%s  

E33F4C: windows_version  

E3417F: machine_id  

E33D70: access_key  

E35E40: %s/tasks/complete/id/%lu  

E37732: http://94[.]159[.]113[.]32/service (C2)  

E377D2: gM7dczM61ejubNuJljRx (UserAgent)  

E378A8: N3sBJNQKOyBSqzOgQSQVf9 (Mutex)  

E3F4E9: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/133.0.0.0 Safari/537.36

… and so on. 

The analysis of the configuration function was the right call. We ended up with the entire strings array used by CastleLoader. As a result, we get the published script. 

Most importantly, the resulting strings feature the very C2 address which we saw in the sandbox analysis. Now it’s extracted not as a secondary effect of network activity, but as a part of malware configuration. This decisively confirms its role and proves that retrieved IOCs are reliable for detection and analysis. 

This decisively confirms its role and proves that retrieved [sandbox] IOCs are reliable for detection and analysis. 

Final Observations 

Since we wanted to demonstrate the entire analysis process from start to finish, we deliberately followed the extended analysis path, from coming up with hypotheses to testing and adjusting them. In practice, many of these stages could have been skipped. 

ANY.RUN provides sufficiently detailed telemetry to significantly shorten the analysis. 

ANY.RUN provides sufficiently detailed telemetry to significantly shorten the analysis. For example, we didn’t have to investigate the Inno Setup module, since the sample did not remove the extracted files afterwards. 

The final process could have been dumped immediately, too, to bypass the intermediate stages, as it was the only one that actually interacted with the network and generated traffic. 

Nevertheless, the full walkthrough proved valuable: it allowed us to reconstruct the entire execution chain, understand the loader’s internal logic, and verify that the extracted data really indicatesCastleLoader’s presence. This approach gave us not only the final set of IOCs, but also an understanding of the mechanisms behind them. 

About ANY.RUN 

ANY.RUN is a leading provider of interactive malware analysis and threat intelligence solutions trusted by security teams worldwide. The platform combines real-time sandboxing with a comprehensive intelligence ecosystem, including Threat Intelligence Feeds, TI Lookup, and public malware submissions. 

More than 500,000 security analysts and 15,000 organizations rely on ANY.RUN to accelerate investigations, validate TTPs, collect fresh IOCs, and track emerging threats through live, behavior-driven analysis. 

By giving defenders an interactive, second-by-second view of malware execution, ANY.RUN enables faster detection, better-informed decisions, and a stronger overall security posture. 

Discover how ANY.RUN can enhance your SOC — start your 14-day trial today. 

Appendix 1: IOCs 

Analyzed Files 

Network Indicators 

C2 Server 

• 94[.]159[.]113[.]32 

HTTP Request 

• http://94[.]159[.]113[.]32/service 

Mutex 

• N3sBJNQKOyBSqzOgQSQVf9 

User-Agents 

• gM7dczM61ejubNuJljRx 

• Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/133.0.0.0 Safari/537.36 

YARA Rules 

rule CastleLoader { 

    meta: 

        author = "ANY.RUN" 

        date = "2025-12-02" 

        description = "Identifies CastleLoader malware samples" 

        threat = "CastleLoader" 

    strings: 

        $p1 = { 44 a0 2d 39 } //CreateMutexW 

        $p2 = { 82 06 d7 4e } //WinHttpOpen 

        $p3 = { 81 03 08 6f } //WinHttpConnect 

        $p4 = { 18 7b d4 2e } //WinHttpOpenRequest 

        $p5 = { e4 f4 96 33 } //WinHttpReceiveResponse 

        $p6 = { d8 da 54 96 } //ShellExecuteW 

        $p7 = { 5f 9e 43 16 } //GetUserNameW 

        $p8 = { b4 89 86 1b } //GetComputerNameW 

condition: 

        all of ($p*) 

}

MITRE ATT&CK Techniques 

The post CastleLoader: A Deep Dive into Stealthy Loader Targeting Government Sector  appeared first on ANY.RUN’s Cybersecurity Blog.

ANY.RUN’s Cybersecurity Blog – ​Read More

Our experts have detected a new wave of malicious emails targeting Russian private-sector organizations. The goal of the attack is to infect victims’ computers with an infostealer. This campaign is particularly noteworthy because the attackers tried to disguise their activity as the operations of legitimate software and traffic to the ubiquitously-used state and municipal services website.

How the attack begins

The attackers distribute an email containing a malicious attachment disguised as a regular PDF document. In reality, the file is an executable hiding behind a PDF icon; double-clicking it triggers an infection chain on the victim’s computer. In the campaign we analyzed, the malicious files were named УВЕДОМЛЕНИЕ о возбуждении исполнительного производства (NOTICE of Initiation of Enforcement Proceedings) and Дополнительные выплаты (Additional Payouts), though these are probably not the only document names the attackers employ to trick victims into clicking the files.

Technically, the file disguised as a document is a downloader built with the help of the .NET framework. It downloads a secondary loader that installs itself as a service to establish persistence on the victim’s machine. This other loader then retrieves a JSON string containing encrypted files from the command-and-control server. It saves these files to the compromised computer in C:ProgramDataMicrosoft DiagnosticTasks, and executes them one by one.

Example of the server response

The key feature of this delivery method is its flexibility: the attackers can provide any malicious payload from the command-and-control server for the malware to download and execute. Presently, the attackers are using an infostealer as the final payload, but this attack could potentially be used to deliver even more dangerous threats – such as ransomware, wipers, or tools for deeper lateral movement within the victim’s infrastructure.

Masking malicious activity

The command-and-control server used to download the malicious payload in this attack was hosted on the domain gossuslugi{.}com. The name is visually similar to Russia’s widely used state and municipal services portal. Furthermore, the second-stage loader has the filename NetworkDiagnostic.exe, which installs itself in the system as a Network Diagnostic Service.

Consequently, an analyst doing only a superficial review of network traffic logs or system events might overlook the server communication and malware execution. This can also complicate any subsequent incident investigation efforts.

What the infostealer collects

The attackers start by gathering information about the compromised system: the computer name, OS version, hardware specifications, and the victim’s IP address. Additionally, the malware is capable of capturing screenshots from the victim’s computer, and harvesting files in formats of interest to the attackers (primarily various documents and archives). Files smaller than 100MB, along with the rest of the collected data, are sent to a separate communication server: ants-queen-dev.azurewebsites{.}net.

File formats of interest to the attackers

The final malicious payload currently in use consists of four files: one executable and three DLL libraries. The executable enables screen capture capabilities. One of the libraries is used to add the executable to startup, another is responsible for data collection, while the third handles data exfiltration.

During network communication, the malware adds an AuthKey header to its requests, which contains the victim’s operating system identifier.

Code snippet: a function for sending messages to the attackers’ server

How to stay safe

Our security solutions detect both the malicious code used in this attack and its communication with the attackers’ command-and-control servers. Therefore, we recommend using reliable security solutions on all devices used by your company to access the internet. And to prevent malicious emails from ever reaching your employees, we also advise deploying a security solution at the corporate email gateway level too.

Kaspersky official blog – ​Read More