Regin Malware: Architecture of a Nation-State Stage-1 Loader and Virtual Filesystems

Initial context:

Executive Summary

This report analyzes a suspected Regin Stage 1 kernel-mode loader, a highly stealthy component associated with long-term advanced persistent threat (APT) espionage operations. The sample is a small (11.4 KB), 32-bit native Windows driver compiled in 2007 using Microsoft Visual C++ tooling. Its lack of version metadata, minimal static imports, and deliberate obfuscation indicate a strong emphasis on stealth, stability, and long-term persistence.

The driver’s DriverEntry routine initializes structured exception handling, disables unloading, and decrypts an embedded configuration stored in the .data section using a custom XOR-based routine. This configuration includes a registry path under HKLM\SYSTEM\CurrentControlSet\Control\RestoreList, which is decrypted only once using a runtime control flag to limit execution artifacts. Additional data elements include preallocated buffers, benign-looking Windows directory strings, and registry value names used during early-stage environment preparation.

The malware dynamically resolves critical kernel components by locating loaded modules such as ntoskrnl.exe and hal.dll, and adapts its behavior based on the operating system version using NtBuildNumber. Access to kernel internals, including the System Service Descriptor Table (SSDT), enables OS-independent execution without relying on static imports. Overall, the findings confirm this sample functions as a first-stage Regin kernel loader, focused on secure initialization, environment validation, and preparation for subsequent payload stages, reflecting a level of sophistication consistent with highly targeted espionage activity.

Description

The analyzed sample is a small Win32 PE executable (11.41 KB) compiled for 32-bit Windows systems. The file was built using Microsoft Macro Assembler (MASM) and linked with Microsoft Visual C++ 7.1, suggesting deliberate low-level development rather than standard high-level application code. Multiple cryptographic hashes were generated to uniquely identify the sample. The executable exhibits characteristics consistent with a lightweight loader component, including its minimal size and lack of overt functionality. These traits align with the behavior expected from the first-stage loader of the Regin malware platform, which is designed to operate stealthily and facilitate the decryption and in-memory loading of subsequent stages.

File

Findings

PE Metadata

File Identification and Basic Properties:

PE Headers

Entry Point Information

Sections

Compilation and Time Stamp Information

Description:

When we look at the parts of the program we see that it is put together in an organized way. The part that has the code is pretty mixed up which is what we usually see in code that someone wrote by hand or tried to make very small. This kind of code is often used in the parts of the program that load things. The part that stores data is more mixed up which makes us think that it might have secret or packed up information like settings or another hidden program. There is also a part that starts things up which is not typical and it means that the bad program has its own way of getting started. The part that helps the program move to places on the computer is pretty simple, which is what we expect to see. The program and the bad program are the thing in this case the malware. The malware has its lifecycle. The parts of the malware, like the.text section and the.data section and the INIT section and the.reloc section are all important to understand how the malware works. Overall, the section layout and entropy distribution support the assessment that this sample functions as a minimal first-stage loader designed for stealth and controlled execution rather than direct malicious activity.

Static Analysis

Imports /Resolved / Referenced Kernel APIs

Hex editor

Figure: Fig 1 - MZ header in the beginning Click to zoom ↗

Fig 1 - MZ header in the beginning

IDA Analysis

IDA recognized the entry point as DriverEntry.

Figure: Fig 2 - Entry point Click to zoom ↗

Fig 2 - Entry point

DriverEntry function (mcd.h) - The DriverEntry miniport driver routine is called when the miniport driver is loaded.

Figure: Fig 3 - msdn DriverEntry Click to zoom ↗

Fig 3 - msdn DriverEntry

Beginning of the code goes immediately goes into loop. XORing some bytes that IDA renamed as SourceString.

Figure: Fig 4 - xor SourceString Click to zoom ↗

Fig 4 - xor SourceString

Following SourceString Encrypted data followed by more encrypted data.

Figure: Fig 5 - Encrypted data conversion to Array Click to zoom ↗

Fig 5 - Encrypted data conversion to Array

Going into sub_106C0 next call is using another buffer.

.text:000106E0 push offset unk_12663 at this address

.data:00012663 unk_12663 db 0D3h ; DATA XREF: sub_106C0+20↑o

Figure: Fig 6 - address 0x106E0 calling buffer. Click to zoom ↗

Fig 6 - address 0x106E0 calling buffer.

Almost every important information in the code is using one or another buffer that looks like encrypted strings.

Decryption

decryption program template:

#!/usr/bin/python3

from decoder_core import *
from Crypto.Cipher import *

class Decoder(TrainingDecoder):
    def __init__(self):
        # MD5 hash of the correctly decrypted file
        super().__init__()

    def decode(self):
        # self.data is a bytearray with the contents of the file
    
        # 1. Set the proper file offset of the encrypted block
        encrypted_block_offset = REPLACE_WITH_THE_SOLUTION
        # 2. Set the proper length of the encrypted block
        encrypted_block_len = REPLACE_WITH_THE_SOLUTION
        # 3. Set the proper file offset of the decryption key
        key_offset = REPLACE_WITH_THE_SOLUTION
        # 4. Set the proper length of the decryption key
        key_len = REPLACE_WITH_THE_SOLUTION

        key = self.data[key_offset:key_offset+key_len]
        for i in range(0,encrypted_block_len):
            self.data[encrypted_block_offset+i] = ( self.data[encrypted_block_offset+i] ^ key[i%key_len] ^ i ) & 0xFF

        # Check if the results are correct
        self.check_results()

# Create the decryptor object. Automation happens in __init__()
Decoder()

Figure: Fig 7 - Counter loop Click to zoom ↗

Fig 7 - Counter loop

The register ESI is used as the loop counter, initialized to zero and incremented on each iteration until it reaches the upper bound of 0x2EE, defining the size of the decrypted buffer.

encrypted_block_len = 0x2EE

Convert Virtual address to the file offset

IDA

Figure: Fig 8 - encrypted block offset Click to zoom ↗

Fig 8 - encrypted block offset

encrypted_block_offset = 0x2569

The XOR key in this routine is a small rolling key stored at byte_1080A, combined with the loop counter (ESI).

Figure: Fig 9 - byte_1080A Click to zoom ↗

Fig 9 - byte_1080A

Figure: Fig 10 - key offset Click to zoom ↗

Fig 10 - key offset

key_offset = 0x80A

Figure: Fig 11 - Converting 7 to binaryis 111b Click to zoom ↗

Fig 11 - Converting 7 to binaryis 111b

We’re going to have values starting from 0 and ending in 7, including 7.

So the length of the key is 8.

Figure: Fig 12 - Successfully decrypted Click to zoom ↗

Fig 12 - Successfully decrypted

File Differences

Figure: Fig 13 - First difference Click to zoom ↗

Fig 13 - First difference

Figure: Fig 14 - Second difference Click to zoom ↗

Fig 14 - Second difference

Decrypted File Analysis

Basic Properties

Sections

MITRE ATT&CK Tactics and Techniques

Figure: Fig 15 - MITRE Click to zoom ↗

Fig 15 - MITRE

Sample Comparison – File Metadata and Hashes

Imported Kernel Functions

IDA Analysis of Decrypted file

Figure: Fig 16 - Loading decrypted binary in IDA Click to zoom ↗

Fig 16 - Loading decrypted binary in IDA

Same Function DriverEntry , First block of data that was encrypted is now a readable registry location

Figure: Fig 17 - Registry location Click to zoom ↗

Fig 17 - Registry location

We have two folders name supposedly two folder’s name

Figure: Fig 18 - recognizable strings Click to zoom ↗

Fig 18 - recognizable strings

Both strings are used as an arguments to function

Figure: Fig 19 - arguments Click to zoom ↗

Fig 19 - arguments

Several templates like temp, windows

Figure: Fig 20 - templates(temp,windows) Click to zoom ↗

Fig 20 - templates(temp,windows)

This routine dynamically resolves kernel system call addresses by locating the base of ntoskrnl.exe and inspecting the System Service Descriptor Table. Execution is guarded to occur only once and includes explicit operating system version checks using NtBuildNumber, allowing the malware to adapt to different kernel layouts. By resolving system calls such as extended attribute handlers at runtime rather than importing them statically, the loader avoids detection and maintains compatibility across Windows versions. This behavior is characteristic of Regin’s highly defensive kernel-level architecture, where low-level system interaction is carefully abstracted and controlled.

Figure: Fig 21 - Function call Click to zoom ↗

Fig 21 - Function call