Magic number used in Sauron Loader
This blog post provides a technical analysis of a novel malware we have encountered in multiple recent customer engagements. Sold in the underground as “Sauron Loader”, and undocumented as of now, it offers loader-type functionality exclusively to Russian cybercriminals.
We detail its inner workings and offer tools and detection content to the cybersecurity community.
Key Takeaways
- Multiple real-world incidents in Germany with novel malware family
- Sold as Malware-as-a-Service (MaaS) in the Russian underground
- Exclusively sold to Russian-speaking cybercriminals
You can find indicators and tooling on our GitHub.
Background
During several recent campaigns targeting multiple organizations in Germany, we encountered a previously unknown malware family. In the cases we supported, Sauron Loader was the final stage of these attacks. It was delivered in various attack chains that all started with social engineering techniques: The attackers used both, ClickFix-style attacks as well as the recently popular voice phishing (vishing) technique. In the vishing attacks users were flooded with spam emails and then contacted by attackers posing as IT support.
As part of the investigation, DCSO observed a post in an underground forum by a user operating under the alias “S4ur0n” (“leetspeak” for “Sauron”). In the post, the user advertised a loader called “Sauron Loader” for sale, whose functionality and settings match those of the malware analyzed by DCSO. The forum advertisement described multiple execution methods that were also subsequently observed during malware analysis, including support for various payload formats and execution mechanisms.
In the advertisement, the developer emphasized that the loader was intended exclusively for Russian-speaking customers and would not be sold for use against public sector organizations, or is allowed to be used against post-Soviet states.
In one instance Sauron Loader was distributed in an MSI installer which we have analyzed in-depth.
Malware Analysis
DCSO analyzed the MSI malware sample (SHA265: ee727d639eaa4ee2e0d7cafbe496e14aaac8df0955d9fb599f2c11dfa1d0f8f2) and identified it as “Sauron Loader”, a loader-type malware family primarily designed to retrieve and execute additional payloads from attacker-controlled infrastructure. This assessment is based on extracted artifacts, observed functionality, and embedded identifiers, including the presence of the string “Sauron” within the analyzed binary. The malware, embedded within the MSI package, is written in C++ and exhibits characteristics of a professionally developed component, potentially indicating that it was created by a dedicated malware development team or component developer.
Figure 1: Sauron string in the binaryChain of Execution
On execution, the MSI installer extracts and drops three files to the hardcoded directory C:\ProgramData\keyroll:
- rnpkeys.exe (194d7e8870ff783ce1e4e4e3015c895cc67ae52fd5e063c89dd1c069400d3991)
Legitimate — Executable used for DLL side-loading (likely part of Mozilla’s RNPGP suite) - rnp.dll
(5606afdc5191d42f38d3c4f1692eda0a629c88810e29bfe78528733284ad1bf8)
Malicious: Loader — DLL side-loaded by rnpkeys.exe. This component contains the primary loader functionality for this malware in an encrypted form. - tdwp.dll
(6551293e996d19755ba497f50b30a18c178f0d6e2a73b29ae742b8171e2985b7)
Malicious: Decrypter and Scheduler — DLL responsible for persistence and decryption of the code within rnp.dll.
As illustrated below, execution begins with the legitimate rnpkeys.exe binary, which is abused to side-load the malicious rnp.dll library. During initialization, rnp.dll loads tdwp.dll, which is responsible for decrypting encrypted sections of rnp.dll directly in memory. Once decryption is complete, execution is transferred to the decrypted code, which implements the loader’s primary functionality.
During the decryption phase, the malware deliberately delays execution, likely to evade antivirus detection and automated sandbox analysis.
Persistence is implemented via a scheduled task named keyroll, which executes the loader at regular intervals. The scheduled task is created by the component responsible for decryption.
Figure 2: Execution FlowMalware Capabilities
The primary functionality of Sauron Loader is to retrieve and execute additional payloads on the victim’s system as well as retrieve additional data from the system and send it to the command-and-control (C2) server.
Various configuration settings are stored within an encrypted configuration embedded in the loader. During execution, the loader decrypts this configuration data and uses the extracted parameters to direct the malware’s behavior.
Communication Flow Overview
Figure 3: Communication flowAll of these protocol messages are ultimately carried through the same HTTPS transport and encryption/signing layer. As a result, the visible network traffic primarily consists of HTTPS POST requests to dynamically generated paths, while the actual registration data, tasking, payload references, and task results remain inside the encrypted binary protocol.
Config Extraction
The embedded config is protected using a custom decryption routine implemented by the malware. This routine is responsible for recovering the config data as well as decrypting strings referenced throughout the binary. The decrypted config contains various execution parameters, cryptographic material, and C2 details used by the malware during operation. The config extracted from the analyzed sample is shown below:
| Offset | Name | Value
| ------ | -------------------- | ------------------------------
|0x00| CIS Check | False
|0x04| flags | True
|0x08| Version number | 1
|0x0c| Version number | 0
|0x10| Version number | 0
|0x14| rsa_private_key_len | 1192
|0x18| rsa_private_key | rsa_private.der
|0x20| rsa_public_key_len | 294
|0x24| padding | 0
|0x28| rsa_public_key | rsa_public.der
|0x30| group_id | test_bot_group_uid
|0x38| build_id | test_build_tag_uid
|0x40| c2_array | [
“https[://]api[.]namsb-show[.]com”,
“https[://]api[.]quinlantours[.]com”,
“https[://]api[.]virtual-magic[.]com”,
“https[://]api[.]lahaina-shores[.]com”
]
The config also contains parameters that influence additional execution logic; this includes checking whether the victim is located in the Commonwealth of Independent States (CIS) using the victim’s keyboard layout and a second targeting check for public sector organizations.
Another notable observation is the presence of the values “test_bot_group_uid” and “test_build_tag_uid” within the config data. These identifiers could indicate that the analyzed sample originated from a testing or development build. However, the incident itself was a real one and not a “test” — at least not for the victim experiencing it.
C2 Communication
The malware communicates with the C2 infrastructure defined in the decrypted config over HTTPS with a randomized request path that is generated at runtime. The resulting paths follow a structure similar to:
/<prefix>/v<1–9>/<action><resource>?<parameters>
where the prefix is api, webhook, metrics, public, or internal; the action is either set or get; and the resource is Config, Status, Profile, Settings, Preferences, Token, Metadata, Connection, Timeout, and Features. The malware additionally generates between zero and three query parameters, selected from names including request_id, timestamp, api_key, user_id, session_token, client_version, platform, redirect_url, device_type, and encryption_key.
The malware uses HTTP POST requests for C2 communication and has a specific UserAgent depending on the windows version. (%d is filled with Windows major and minor version numbers)
# Windows 10+
Mozilla/5.0 (Windows NT %d.%d; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/143.0.0.0 Safari/537.36 Edg/143.0.3650.96
# Windows 8
Mozilla/5.0 (Windows NT %d.%d; Trident/7.0; rv:11.0) like Gecko
Application-layer protection
Every client request is Salsa20 encrypted and signed with RSA:
<salsa_key[16]><nonce[8]>
<signature_len><signature>
<ciphertext_len><ciphertext>
<random_padding[1111..9999]>
The malware generates a fresh 16-byte Salsa key and 8-byte nonce for each request. It signs the ciphertext using the private key from the config, signs the bytes for transmission, and appends between 1111 and 9999 random bytes.
The server response has a 32-byte Salsa key:
<salsa_key[32]><nonce[8]>
<signature_len><signature>
<ciphertext_len><ciphertext>
[optional trailing bytes]
The malware verifies the server ciphertext with the public key before decrypting it. The key and nonce are transmitted in clear inside the response body. The signature covers only the ciphertext, not the key, nonce, lengths, or random padding.
Binary message format
The plaintext protocol uses a custom Type-Length-Value (TLV) format. It is similar to Protobuf in some aspects. Each field starts with:
{
id,
type,
element_count
}Known field types are:
| Type | Encoding
|------| --------------------------------
| 1 | Boolean or one byte value
| 2 | 8-bit integer
| 3 | 16-bit integer
| 4 | 32-bit integer
| 6 | Length delimited value or collection
Registration: Message Type 1
The first client message registers the bot and begins with 0x01. The remainder of the plaintext consists of typed fields containing information about the infected system. Each field starts with a field identifier and a type/length descriptor. The registration message includes the malware’s bot ID, joined domain, computer name, username, Windows version, privilege level, malware versions, installed products, group ID, and build ID.
A simplified representation is:
Figure 4: Registration payload hexdump (before encryption)where the bytes map to the following:
<01 00> Message type: Registration
<01 06 01 00><len><bot_id>
<02 06 01 00><len><joined_domain> (optional)
<03 06 01 00><len><computer_name>
<04 06 01 00><len><username>
<05 04 01 00><windows_major>
<06 04 01 00><windows_minor>
<07 04 01 00><windows_build>
<08 01 01 00><server_product_flag>
<09 02 01 00><privilege_class>
<0A 03 01 00><malware_major>
<0B 03 01 00><malware_minor>
<0C 03 01 00><malware_build>
<0D 06 NN 00><product_1_len><product_1> (optional)
<product_2_len><product_2>
…
<0E 06 01 00><group_id_len><group_id>
<0F 06 01 00><build_id_len><build_id>
The bot ID is the lowercase MD5 hexadecimal digest of:
<COMPUTERNAME><USERNAME><volume_serial>
After verification and decryption, the registration response contains a top-level server message and a registration status:
<01 06 01 00><server_text_len><server_text>
<02 01 01 00><registration_accepted>
Task Retrieval: Message Type 2
After registration, the malware periodically polls the C2 for tasking. Task requests use message type 0x02 and contain a smaller set of host identifying fields:
<02 00>
<01 06 01 00><bot_id_len><bot_id>
<02 03 01 00><malware_major>
<03 03 01 00><malware_minor>
<04 03 01 00><malware_build>
<05 02 01 00><privilege_class>
The request is then placed inside the same encrypted and signed HTTP body used for registration.
The decrypted response contains a top-level server message followed by one or more task records:
<01 06 01 00><server_text_len><server_text>
<02 06 NN 00><task_record_1_len><task_record_1>
…
<task_record_N_len><task_record_N>
<03 06 NN 00><aux_record_1_len><aux_record_1>
…
Each task record contains a task ID, a task category, and category specific data:
<record_len:u16>
<01 06 01 00><task_id_len><task_id>
<02 03 01 00><task_category>
<03 06 01 00><payload_len><category_payload>
The task category determines how the payload is interpreted and which execution routine is subsequently invoked.
Task Types
The analysis identified three task categories. Category 1 represents command execution, category 2 represents screenshot capture, and category 3 represents a secondary task type.
Command tasks contain several parameters controlling how the requested payload is obtained and executed:
<01 02 01 00><task_type>
<02 06 01 00><direct_url_len><direct_url>
<03 06 01 00><reference_len><payload_reference>
<04 02 01 00><execution_mode>
<05 06 01 00><len><parameter_1>
<06 06 01 00><len><parameter_2>
<07 02 01 00><option>
parameter_1 supplies EXE arguments, parameter_2 can contain a DLL export name, and option selects the shellcode injection target.
The presence of both a direct URL and a payload reference is significant because it gives the malware two distinct mechanisms for obtaining an additional payload.
Payload Retrieval: Message Type 4
For direct downloads, the malware retrieves the file from the supplied URL and streams the response directly to either a file or an in-memory buffer, depending on the task handler.
The C2 payload retrieval uses a separate GetFile message, identified by message type 0x04:
<04 00>
<01 06 01 00><bot_id_len><bot_id>
<02 06 01 00><reference_len><payload_reference>
This message is encrypted and signed using the same as the other C2 requests.
When a payload needs to be staged on disk, the malware creates a temporary filename resembling:
%TEMP%<random 6..16 character name>.<extension>
Payload Execution
The command handlers support a broad set of payload formats, with the task type and execution mode supplied by the C2 determining how each payload is staged and executed.
The handlers cover several common Windows scripting and installer formats:
| Type | Handler | Summary
|------|------------|-----------------------------------------
| 1 | EXE | Stages and launches .exe via CreateProcessW.
| 2 | DLL | Stages .dll; uses rundll32/regsvr32 or manual PE loader.
| 3 | Driver | Stages .sys; installs/opens and starts driver service.
| 4 | Shellcode | Fetches to memory; executes or injects into attrib.exe.
| 5 | MSI | Stages .msi; installs silently via MsiInstallProductW.
| 6 | ZIP | Fetches, extracts to %TEMP%, and launches contained .exe.
| 7 | CMD | Stages .cmd and executes via cmd.exe /c.
| 8 | PowerShell | Stages .ps1 and executes with ExecutionPolicy Bypass.
| 9 | VBS | Stages .vbs and executes via wscript.exe.
| 10 | JavaScript | Stages .js and executes via wscript.exe.
Task Results: Message Type 3
After processing a task, the malware reports the result back to the C2 using message type 0x03:
<03 00>
<01 06 01 00><bot_id_len><bot_id>
<02 06 01 00><task_id_len><task_id>
<03 01 01 00><success>
<04 04 01 00><total_data_length>
[<05 06 01 00><chunk_len><chunk[chunk_len]>]
Ordinary command results set total_data_length to zero and omit field 5. The malware sends this request to another randomized C2 path and considers it successful when the server returns HTTP status 200.
Screenshot Collection
Screenshot tasks are represented by category 2 and contain a single capture parameter that determines if the malware should capture the entire virtual desktop or just the primary monitor:
<01 01 01 00><primary_only>
The corresponding handler captures the victim’s desktop as a PNG image. Rather than sending the entire image as one large result, the malware divides the PNG into chunks of up to 0x4000 bytes.
Each chunk is transmitted using a separate TaskResult message. Every request retains the same bot ID and task ID and specifies the total PNG size, while the result-data field contains the current portion of the image.
The screenshot traffic therefore follows the same encrypted and signed C2 protocol as ordinary task results, but uses the protocol’s chunking mechanism to transfer a larger result:
<03 00>
<01 06 01 00><bot_id_len><bot_id>
<02 06 01 00><task_id_len><task_id>
<03 01 01 00><success = 1>
<04 04 01 00><complete_png_size>
<05 06 01 00><current_chunk_size><current_png_chunk>
Secondary task category
The observed worker does not retrieve or execute a payload for this category. It sends an empty result with the success value set to zero. The precise purpose of these records remains unconfirmed.
Timing and C2 rotation
The malware rotates to another configured C2 after registration or polling failure and sleeps 160 seconds. After a successful poll and task dispatch cycle, it sleeps for 600 seconds.
Additional Samples
DCSO was able to find additional samples of Sauron Loader. These samples showed similar characteristics to the analyzed sample, including matching loader functionality and implementation details, but contained different C2 infrastructure in their embedded configurations.
Attribution and Context
This section provides additional information about the malware’s known associations, operational use, and role within the broader threat landscape.
Attribution
The loader’s restrictive targeting, outlined by the author and reinforced in the code, has been frequently observed in campaigns associated with cybercriminals operating in the Russia-nexus. Due to tacit agreements with the cybercrime ecosystem, the Russian government often “overlooks” cybercriminal activities if the targeting aligns with general Russian government objectives, namely not targeting countries that are members of the Commonwealth of Independent States (CIS). Hence, many suspected or attributed Russian cybercriminal malware (such as LockBit, Qilin, Cl0p, and Medusa) also contained geolocation, language, or keyboard checks for CIS countries. However, this restriction is well-known to be associated with Russia- or CIS-based malware and should not be used alone to confirm or attribute activity to Russia-nexus actors.
It is important to distinguish between the developer of the malware and the operators responsible for the observed campaigns. While the forum post provides insight into the likely origin of the malware family and the developer’s intended customer base, it does not directly attribute the campaign activities to the malware author. Based on the seller’s stated restrictions and the available forum information, DCSO assesses that more likely than not, the campaign operator may also be Russian-speaking. This assessment is based on the available circumstantial evidence.
Similarities to Other Campaigns
Beyond the malware, the tactics seen in these campaign have been frequently observed in use by other threat actors. Email bombing is a common and increasingly popular tactic used by cybercriminals across the geographic spectrum. Often, after an initial email bombing attack, threat actors will then reach out to the victims, posing as IT helpdesk employees and offering to “help” victims resolve the issue. The onslaught of emails can create a sense of frustration and urgency, leading victims to be more likely to accept the “help” that the threat actors offer. The email flooding and impersonated IT support tactic has been used over the years to deliver DarkGate malware in 2024 and by Black Basta affiliates in 2024 and 2025. Within the last year, several cybercriminal groups have been observed taking advantage of this technique, such as Payouts King, Scattered Spider, suspected former Black Basta affiliates, and UNC6692. While often similar, the campaigns sometimes use different tools — in one of the DCSO-observed incidents, the threat actor instructed the victim to initiate a Microsoft Quick Assist remote assistance session. Usage of Microsoft’s Quick Assist software for the purpose of remote access was also observed in the majority of aforementioned voice phishing (vishing) campaigns, although other remote access tools were also used, such as AnyDesk.
As in the case of the ClickFix technique and its myriad of variations, threat actors are likely to begin using similar social engineering techniques for initial access when they prove to be sufficiently successful, flexible, and easy to replicate. This seems to be becoming the case for this tactic as well, as in their 2026 threat report, eSentire reported a year-over-year increase of 1,450% in observed cases of email bombing attacks followed by IT impersonation, with the attacks boasting a 72% success rate. As the technique continues to soar in popularity and maintains a high success rate, it is likely that we will continue to see more threat actors making use of this technique for initial access in various campaigns in the near future.
This is further amplified by the fact that some related campaigns are suspected to use automated communication in order to target a high number of victims quickly, meaning threat actors could conduct this activity at an even faster pace with less manual interaction necessary.
Our Threat Intelligence customers got early-access to this report’s findings. Indicators and detection content is continuously integrated into our Managed Detection and Response service.
- Interested? Contact us to learn more
- Ongoing Incident? 24/7 Emergency Incident Support
APPENDIX
TTP Mapping
| Tactic | Technique | Technique Name |
|-----------------------------------------|------------|-----------------------------------------------------------------------|
| Initial Access | T1667 | Email Bombing |
| Initial Access | T1566.004 | Phishing: Spearphishing Voice |
| Initial Access / Command and Control | T1219 | Remote Access Tools |
| Initial Access / Command and Control | T1105 | Ingress Tool Transfer |
| Initial Access / Command and Control | T1071.001 | Application Layer Protocol: Web Protocols |
| Defense Evasion / Execution | T1218.007 | System Binary Proxy Execution: Msiexec |
| Defense Evasion | T1574.002 | Hijack Execution Flow: DLL Side-Loading |
| Defense Evasion | T1036.005 | Masquerading: Match Legitimate Resource Name or Location |
| Defense Evasion | T1027.013 | Obfuscated Files or Information: Encrypted/Encoded File |
| Defense Evasion | T1140 | Deobfuscate/Decode Files or Information |
| Defense Evasion | T1027.007 | Dynamic API Resolution |
| Defense Evasion | T1480.001 | Execution Guardrails: Environmental Keying |
| Persistence | T1053.005 | Scheduled Task/Job: Scheduled Task |
| Discovery | T1082 | System Information Discovery |
| Discovery | T1033 | System Owner/User Discovery |
| Discovery | T1057 | Process Discovery |
| Discovery | T1518.001 | Software Discovery: Security Software Discovery |
| Discovery | T1016 | System Network Configuration Discovery |
| Discovery | T1614.001 | System Location Discovery: System Language Discovery |
| Command and Control | T1071.001 | Application Layer Protocol: Web Protocols |
| Command and Control | T1573.001 | Encrypted Channel: Symmetric Cryptography |
| Command and Control | T1573.002 | Encrypted Channel: Asymmetric Cryptography |
| Command and Control | T1105 | Ingress Tool Transfer |
| Execution | T1059.003 | Command and Scripting Interpreter: Windows Command Shell |
| Execution | T1059.001 | Command and Scripting Interpreter: PowerShell |
| Execution | T1059.005 | Command and Scripting Interpreter: Visual Basic |
| Execution | T1059.007 | Command and Scripting Interpreter: JavaScript/JScript |
| Execution / Defense Evasion | T1218.011 | System Binary Proxy Execution: Rundll32 |
| Execution / Defense Evasion | T1218.010 | System Binary Proxy Execution: Regsvr32 |
| Execution / Persistence | T1543.003 | Create or Modify System Process: Windows Service |
| Defense Evasion | T1055.012 | Process Injection: Process Hollowing |
| Defense Evasion / Execution | T1620 | Reflective Code Loading |
| Execution | T1106 | Native API |
| Collection | T1113 | Screen Capture |
| Exfiltration | T1041 | Exfiltration Over C2 Channel |
Indicators of Compromise
All IoCs as well as a config extraction tool are available on our GitHub: https://github.com/DCSO/Blog_CyTec/tree/main/2026_09__sauron_loader
Introduction to Malware Binary Triage (IMBT) Course
Looking to level up your skills? Get 10% off using coupon code: MWNEWS10 for any flavor.
Enroll Now and Save 10%: Coupon Code MWNEWS10
Note: Affiliate link – your enrollment helps support this platform at no extra cost to you.