Unveiling Sirius Backdoor: A Multistage Fileless Campaign Disguised as FedEx Invoices

By Shashikala Piddannavar, Raymond Joseph Alfonso and Sagar Bade · October 26, 2026

Introduction

During a recent priority customer escalation, our “Trellix” Threat Response Team investigated a suspicious alert involving the unexpected execution of a PDF document. What initially appeared to be a routine phishing attempt quickly unfolded into a sophisticated, multistage campaign delivering a previously undocumented variant of the Sirius Backdoor.

While the initial delivery via an email containing a ZIP archive with a PDF appeared routine, the execution flow stood out due to its heavy use of living-off-the-land (LotL) techniques.

Analysis revealed that the PDF abuses /OpenAction and /Launch objects to trigger an embedded Base64-encoded PowerShell command upon opening. Execution relies on social engineering to trick the user into approving the PDF reader's security confirmation prompt.

The PowerShell stager decrypts and reflectively loads a .NET assembly in memory. This loader performs process hollowing into legitimate Windows processes such as msbuild.exe, svchost.exe, etc. allowing the malware to operate under trusted process contexts.

The final payload is a new backdoor, which we named it as SIRIUS BACKDOOR based on the <<<<SIRIUS_STUB_CONFIG>>>> config and a few related patterns; it’s a modern Microsoft Visual C++ based backdoor with extended remote access capabilities.

Infection flow

The Sirius infection chain: High-level overview

This campaign utilizes a sophisticated "Matryoshka doll" execution model, where each stage exists solely to decrypt and reflectively load the next, ensuring the final payload never touches the disk in an unencrypted state.

Phase 1: Initial access (The FedEx lure)

The attack starts with a geo-targeted spear-phishing email (in Korean) masquerading as a FedEx Tax Invoice. To evade email gateway security, the malicious payload is tucked inside a ZIP(Fedex_tax_receipt.zip) archive containing a weaponized PDF(Fedex_tax_receipt.pdf).

Phase 2: The Document trigger (PDF /Launch)

The PDF is visually blank, acting only as a delivery vehicle. It leverages the /OpenAction and /Launch features to automatically execute an obfuscated PowerShell command the moment the document is opened. This transitions the threat from a static file to active code execution.

Phase 3: Fileless staging (PowerShell reflection)

The PowerShell script acts as an in-memory "unpacker." It decrypts an AES-encrypted and GZip-compressed blob using hardcoded keys. Using .NET Reflection, it loads the resulting bytes directly into memory as the Stage 1 Loader, ensuring the malware never touches the physical disk.

Phase 4: The Staging loader (RC4 and reconstruction)

This Stage 1 .NET Assembly provides an extra layer of defense. It derives an RC4 key via SHA256 to decrypt its internal resources. To bypass memory scanners looking for "MZ" headers, it uses a de-interleaving algorithm (extracting every third byte) to reconstruct the Stage 2 Injector before executing it.

Phase 5: The Master injector (EDR blinding and hollowing)

The Stage 2 Injector is the engine of the attack. It proactively patches ETW (Event Tracing for Windows) and HotPatching to "blind" EDR/AV sensors. It then downloads the final payload (zeus.dat) and uses Early Bird APC Injection(CreateProcess(in suspended  state CREATE_SUSPENDED)→VirtualAllocEx→WriteProcessMemory→NtQueueApcThread→ ResumeThread / NtResumeThread) to hide the Sirius Backdoor inside legitimate Windows processes like msbuild.exe or svchost.exe.

Phase 1: Email with zip attachment

The infection begins with a carefully crafted spear-phishing email designed to instill a sense of financial urgency. The threat actors behind this campaign leverage the global reputation of FedEx to bypass the victim's initial suspicion.

Email characteristics

• Subject Line: [FedEx] A tax invoice has been issued.
• Language: Korean
• Theme: Financial compliance / billing
• Bait: A notification for a new tax invoice totaling 217,740 KRW with a specific due date.

Social engineering tactic

The email is designed to mimic legitimate FedEx Billing Online automated notifications. By including specific details such as a convincing invoice number (724156148 >) and a pending payment deadline, the attacker pressures the recipient into opening the attachment to "review the details."

The use of the Korean language and South Korean currency (KRW) suggests a geo-targeted campaign, specifically aimed at corporate users or accounting departments within the region.

The attachment (The technical pivot)

The email contains a ZIP archive (to evade simple email gateway scanners). Inside this archive lies the weaponized document Fedex_tax_receipt.pdf.

Opening this PDF is the "Point of No Return," as it utilizes the Adobe /Launch action to move the infection from a document-based lure to active code execution via PowerShell.

Phase 2: The weaponized PDF (The silent trigger)

When a user opens Fedex_tax_receipt.pdf, they see a blank page. This is by design. The malware author isn't interested in providing content; they only need the PDF reader to parse the file's internal objects to trigger the execution.

1. Why is the page blank?

Looking at Object 5 in the raw code:

Code snippet:
5 0 obj
<< /Length 27 >>
stream
BT /F1 1 Tf 0 0 Td ( )Tj ET
endstream
endobj

• The BT (Begin Text) and ET (End Text) tags define the visible content.
• The command ( )Tj tells the PDF reader to render a single space character.
• There are no images, no invoice details, and no actual text. The "document" is effectively an empty shell used as a transport vehicle.

2. The execution engine: /OpenAction & /Launch

The real danger lies in how the PDF handles its startup sequence.

• The Hook (Object 1): The entry point of the PDF contains /OpenAction 8 0 R. This instruction tells the PDF reader: "As soon as this file is opened, immediately execute the instructions found in Object 8."
• The Payload (Object 8): This is where the /Launch action is defined.

Code snippet
8 0 obj
<< /Type /Action /S /Launch /Win
  << /F (powershell.exe) /P (-W h -nop -NOni -ep BYPaSS -EncodedCommand ...

3. Decoding the stealth PowerShell command

The /Launch action specifically targets the Windows operating system (/Win) and executes powershell.exe with the following stealth arguments:

• -W h (WindowStyle Hidden): Ensures no blue PowerShell window flashes on the user's screen.
• -nop (NoProfile): Ignores local PowerShell configurations to ensure the script runs predictably.
• -NOni (NonInteractive): Prevents the script from presenting prompts to the user.
• -ep BYPaSS (ExecutionPolicy Bypass): Bypasses the system's script signing security policies.
• -EncodedCommand: The actual malicious script is Base64 encoded. This hides the URL of the .NET Loader and other indicators from simple string-based scanners.

Phase 3: PowerShell reflection and in-memory loading

The Base64-encoded command triggered by the PDF reader is a sophisticated one-liner designed to bypass static file scanners. Instead of downloading an .exe file, it processes an encrypted blob entirely within the PowerShell process memory.

Code snippet:

1. The cryptographic layer (AES-CBC)

The script initializes an AES-256 decryption engine in cipher block chaining (CBC) mode.

• The Key ($yc4KQe1): LfBqaGHMQsA85Ha3pbu7Vg==
• The IV ($1k9vlx): +9aAse9v9VKdKbioQxwNxg==
• The Ciphertext ($f9Pn): This variable contains the large Base64 string found in the PDF.

The script uses TransformFinalBlock to decrypt the raw bytes. By using AES with a specific key and IV, the attacker ensures that the payload remains "junk data" to any network security appliance inspecting the traffic or the file.

2. The compression layer (GZip)

Once decrypted, the data is still not a functional executable. To further reduce the footprint and obfuscate the code, the payload is compressed.

• The script uses the IO.Compression.GZipStream class.
• It streams the decrypted bytes through a decompressor into a new MemoryStream.
• This technique is often used to hide the "MZ" header and other recognizable PE (portable executable) markers from simple memory strings.

3. The execution pivot (Reflection)

The final line is the most critical technical maneuver:

[Reflection.Assembly]::Load($yTu0eb.ToArray()).EntryPoint.Invoke($null,(,[string[]]@()))

• [Reflection.Assembly]::Load: This tells PowerShell to take the decrypted/decompressed byte array and treat it as a .NET executable assembly.
• Reflective Loading: Because the assembly is loaded from an array (memory) rather than a file path (disk), it is "fileless."
• EntryPoint.Invoke: The script automatically finds the Main method of the .NET Loader and executes it immediately.

Why this is effective for the attacker:

1. Antivirus Bypass: Most traditional AV products scan files as they are written to disk. Since this script stays in memory, it bypasses those triggers.
2. AMS Bypass: While modern Windows versions have AMSI (antimalware scan interface), the use of encryption and GZip requires AMSI to catch the payload at the exact moment of the Load call, which is a very narrow window of detection.
3. Efficiency: This small script can deploy any .NET-based malware (in this case, the stage 1 NET Loader) by simply swapping the Base64 blob in the PDF.

Phase 4: The .NET staging loader (RC4 and de-interleaving)

Once active in memory, this loader's sole purpose is to "unpack" the next layer of the malware. It uses a combination of standard cryptography and a custom "junk data" removal technique to bypass pattern-matching security tools.

1. Key derivation (SHA256 and XOR)

The loader doesn't store its decryption key in plain text.

• It clones a hardcoded byte array (array2) and performs an XOR operation using a seed value (b).
• It then generates a SHA256 hash of this XORed result. This hash becomes the final symmetric key for the next step.

Why? This prevents static analysis from identifying the RC4 key by simply looking at the binary's strings or data sections.

2. Custom RC4 decryption

The loader uses the derived SHA256 hash to initialize a standard RC4 (Rivest Cipher 4) stream cipher. It decrypts array12 (the encrypted payload stored in resources).

• The S-Box: The code manually builds the 256-byte S-Box (substitution box), a signature of the RC4 algorithm.
• Stream XOR: It then XORs the encrypted payload with the pseudo-random stream generated by the S-Box.

3. The "anti-sandbox" trick: Data de-interleaving

This is the most unique part of this loader. Even after decryption, the payload is still not a valid executable. The author has "interleaved" the real malware bytes with junk data to hide the "MZ" header from memory scanners.

• The code divides the decrypted buffer by 3 and extracts every third byte.
• The other 66% of the data consists of randomized junk bytes designed to break the "file signature" of the malware.

4. Verification and reflective invocation

After reconstruction, the loader checks the first two bytes for the magic numbers 77 and 90 ('M' and 'Z').

• Assembly.Load: If valid, it uses .NET Reflection to load the bytes as a new assembly.
• entryPoint.Invoke: It dynamically locates the Main method of the Stage 2 Injector and executes it.

Phase 5: The stage 2 injector (Telemetry blinding and final execution)

This stage is responsible for three primary objectives: neutralizing endpoint security, retrieving the final Sirius payload, and executing it using stealthy memory injection.

1. Anti-EDR: Blinding the watchmen

Before the malware performs any "noisy" actions, it calls PatchETW() and PatchNtManageHotPatch().

• ETW Patching: Event Tracing for Windows (ETW) is the primary data source for modern EDR (endpoint detection and response) tools. The injector hooks the EtwEventWrite function in ntdll.dll, replacing it with a "No-Op" (no operation) instruction.
• Impact: Any malicious activity performed after this point—such as process injection or credential theft—will not be logged by Windows, effectively making the malware "invisible" to security sensors.

2. Payload retrieval (zeus.dat)

The method DownloadPayload() is called to fetch the final malware from the C2 server (dubaitechnicalservice.ae).

• Encrypted URL: The download URL is RC4-encrypted within the binary to prevent network scanners from flagging it.
• Robustness: The code is designed to cycle through multiple .NET network libraries (HttpClient, WebClient, and HttpWebRequest) to ensure the download succeeds even if one method is blocked by a local firewall.

3. The execution fork: .NET vs. native

The Main method performs a logic check using isNET() to determine how to run the downloaded zeus.dat bytes:

• Case A: If the Payload is .NET: It uses Reflective Loading (Assembly.Load). The malware remains entirely in memory, and the code finds the EntryPoint (the main method of the stealer) and executes it directly within the current process.
• Case B: If the Payload is Native (VC++): If the payload is not a .NET assembly (which is the case for our VC++ Sirius Backdoor), it pivots to the NativeRunPE.Execute method. This triggers the process hollowing sequence.

4. Execution via process hollowing (NativeRunPE)

The injector identifies the architecture (x86 or x64) and selects a random host process (e.g., msbuild.exe, svchost.exe).

1. Creation: It launches the host process in a suspended state.
2. Hollowing: It unmaps the original code and replaces it with the Sirius Backdoor code.
3. APC Injection: To bypass behavioral detection of "suspended processes," it uses NtQueueApcThread. This queues the malicious code to run as an "asynchronous procedure call," which is a much stealthier method than simply resuming the thread.

The Stage 2 Injector is the “cloaking device” of the infection. By patching ETW and HotPatching mechanisms, it proactively disables the OS's ability to report malicious behavior. It then makes a high-level decision: if the payload is .NET, it loads it reflectively; if it is native VC++, it uses advanced APC-based process hollowing to hide the Sirius Backdoor inside trusted Windows processes.

Payload analysis:

Sirius Backdoor begins by trying to resolve either SetProcessDpiAwarenessContext() or SetProcessDpiAwareness(). This ensures that the screen-capture module works perfectly preventing blurry image and text.

Parsing malware configuration

Sirius Backdoor has two ways to store its malware configuration, either in the .RSRC section or in its static memory. If it's in the resource section, it looks for the resource named Caffee_Config otherwise, it searches for the string <<SIRIUS_STUB_CONFIG>> in its memory as this signifies the start of the stub configuration.

Below is a sample config embedded in the variant analyzed:

00000000:  8C 00 00 00-00 00 31 38-35 2E 31 31-34 2E 32 30  î     185.114.20
00000010:  36 2E 34 35-3A 34 34 34-39 00 00 00-25 41 50 50  6.45:4449   %APP
00000020:  44 41 54 41-25 00 4D 69-63 72 6F 73-6F 66 74 00  DATA% Microsoft
00000030:  73 76 63 68-6F 73 74 2E-65 78 65 00-00 34 34 35  svchost.exe  445
00000040:  62 61 37 38-65 34 63 66-34 62 39 34-30 33 38 38  ba78e4cf4b940388
00000050:  35 36 37 30-63 32 63 39-63 39 37 65-63 62 62 39  5670c2c9c97ecbb9
00000060:  38 30 35 35-34 33 31 62-64 35 32 30-32 31 36 37  8055431bd5202167
00000070:  32 62 31 36-37 37 63 39-64 31 37 34-62 00 00 00  2b1677c9d174b
00000080:  25 54 45 4D-50 25 00 6D-73 75 70 64-61 74 65 00  %TEMP% msupdate
00000090:  00 00 00 00-00 00 00 00-00 00 00 00-00 00 00 00

Behavior switching

The behavior of Sirius Backdoor  is governed by two local variables defined in the main function of itself. Below is a summary of what each bit does:

Flag #1
0x0001
Create a mutex used to check if there's already another instance of the RAT running.

0x0008
Achieve persistence on victim's system by creating an entry in HKCU\Software\Microsoft\Windows\CurrentVersion\Run that points to the path of the malware.

0x0010
Drops a dynamically generated XML task definition and registers it via schtasks.exe. The task is configured with a LogonTrigger, sets the RunLevel to HighestAvailable, and automatically launches the malware payload with elevated privileges upon user logon.

0x0020
Modifies its own extension from .exe to .dll in memory and copies itself into C:\Windows\System32\user32.dll (or a custom name) for DLL sideloading or COM hijacking.

0x0100
Changes its own attribute to FILE_ATTRIBUTE_HIDDEN and FILE_ATTRIBUTE_SYSTEM

0x0400
If disabled, execute the backdoor routine without needing administrator privileges.

0x0800
Terminate itself if it's not running in its target directory.

0x1000
Set shutdown priority for itself to the lowest level and remove the retry dialog.

0x2000
Check if the victim's country code is included in the campaign.

The backdoor validates whether the victim host is located in one of ~88 supported countries (including South Korea, the US, Canada, Australia, and European nations), terminating execution if there is no match

Flag #2: Persistence & Elevation Matrix

The second behavior flag dictates how Sirius establishes persistence across different host privilege levels:

0x01 – Startup Shortcut (COM):
  Uses COM interfaces (IShellLinkA and IPersistFile) to drop a shortcut (.lnk) into the user's Startup folder, defaulting to "WindowsUpdate.lnk" if no custom shortcut name is specified.

0x02 – UserInit Logon Script Hijack:
  Drops a batch script named logon.cmd and registers its path under HKCU\Environment\UserInitMgrLogonScriptName. During user logon, userinit.exe queries this volatile environment variable and automatically executes the script.

0x04 – Session Manager BootExecute Manipulation:
  Appends the malware path to the REG_MULTI_SZ BootExecute value in HKLM\SYSTEM\CurrentControlSet\Control\Session Manager.

 (Note: While the binary includes this bitmask routine, standard Win32 executables cannot run directly in Session 0 native mode without an intermediate native subsystem wrapper binary).

0x08 – Multi-Tier Privilege Persistence:
  If running with Administrator privileges, the malware executes an aggressive multi-vector persistence routine:

1. Default User Profile Poisoning: Mounts C:\Users\Default\NTUSER.DAT under HKEY_USERS\SURV_DEFAULT and writes a persistence entry to Software\Microsoft\Windows\CurrentVersion\Run. This ensures every newly created account on the system automatically inherits the infection.
2. Windows Push-Button Reset Survival (PPKG): Drops a custom provisioning package in C:\Recovery\Customizations\SysConfig_<CRC32_of_mutex>.ppkg. Windows Push-Button Reset automatically restores packages in this directory, allowing the backdoor to reinstall itself even across full system resets.
3. Setup Script Hijacking: Creates C:\Windows\Setup\Scripts\SetupComplete.cmd, ensuring execution with SYSTEM privileges at the conclusion of Windows Setup or OS upgrade workflows.

  Non-Admin Fallback:
  If elevated privileges are unavailable, the malware drops itself into %LOCALAPPDATA%\Microsoft\<custom_dir>\<file> and %USERPROFILE%\Documents\<custom_dir>\<file>. It then writes updater.vbs to the user's Startup folder and registers the ~ RUNASADMIN flag under HKCU\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers to trigger a UAC elevation prompt upon execution.

  Malware installation

- If the four th bit of Flag #1 AND Flag #2 is not set, it will install itself in another directory

- It's customizable; the malware author can specify two directories where it will install itself, making it have a primary and fallback routine if the primary fails.

- Both routines use "svchost.exe" as its default file name is none is set.

Conclusion

The Sirius Backdoor campaign stands out for its zero-disk delivery and deliberate focus on blinding endpoint sensors from start to finish:

• PDF Trigger: Uses a visually blank PDF with /OpenAction and /Launch to directly spawn PowerShell without dropping initial binary files.
• In-memory Unpacking: Chains AES decryption, GZip decompression, and a 3-to-1 byte de-interleaving trick to scrub MZ/PE headers from memory before reflective loading.
• EDR Blinding and Injection: Patches ntdll!EtwEventWrite to silence ETW telemetry, then hollows msbuild.exe or svchost.exe using Early Bird APC injection (NtQueueApcThread).
• Resilient Persistence: Abuses uncommon survival mechanisms, including Windows Provisioning Packages (.ppkg) to survive OS resets, alongside UserInitMgrLogonScriptName and default user hive (NTUSER.DAT) hijacks.

Defensive recommendations

To defend against and detect this infection chain, we recommend implementing the following controls:

• Block PDF Child Processes: Enable Microsoft Defender ASR rule "Block Adobe Reader from creating child processes" (GUID: 7674ba52-37eb-4a4f-a9a1-f0f9a1619a2c
• Enforce PowerShell Constrained Language Mode (CLM): Use AppLocker or WDAC to restrict PowerShell capabilities, including dynamic .NET and reflection operations used by fileless loaders.
• Enable Script Block Logging: Enable PowerShell Script Block Logging and monitor Event ID 4104 to capture script content processed at runtime, including reconstructed or de-obfuscated PowerShell code.
• Monitor Suspicious Process Lineage: Alert on unusual relationships such as PDF applications spawning PowerShell, script engines launching msbuild.exe, or unexpected processes creating svchost.exe.
• Detect Early Bird APC Injection: Monitor for processes created with CREATE_SUSPENDED, followed by cross-process memory operations, NtQueueApcThread, and thread resumption.
• Audit Persistence Locations: Monitor for unexpected .ppkg files under C:\Recovery\Customizations\, UserInitMgrLogonScriptName under HKCU\Environment, SetupComplete.cmd, and suspicious RUNASADMIN entries under AppCompatFlags\Layers.

Host Profiling & Defensive Auditing

Upon initial beaconing, Sirius Backdoor executes a structured host reconnaissance routine to fingerprint the victim machine and assess its defensive posture. The implant generates a persistent Hardware ID (HWID) by combining the system's volume serial number and NetBIOS computer name, while harvesting detailed hardware specifications (CPU, GPU, physical RAM, and display resolution) alongside user integrity levels.

Beyond basic system profiling, the malware deliberately audits the host's security controls—specifically querying Windows Defender status (DisableAntiSpyware and Defender ATP integration). It also tracks user idle time, system uptime, default browser settings, and active foreground window titles, allowing operators to verify whether the infected machine is an active, high-value corporate workstation or a virtualized security sandbox.

Backdoor Capabilities: Beyond Commodity RAT Tradecraft

At its foundation, Sirius Backdoor covers the expected baseline of modern remote access tools—including reverse shell spawning (0x20), file and directory tampering (0x60–0x75), recursive registry manipulation (0x80–0x8A), and full process injection (0xB4, 0xFC, 0xFD).

However, binary analysis revealed that Sirius diverges significantly from typical commodity malware. It integrates a bespoke, multi-tier operational framework designed for covert interactive access, financial theft, deep host surveillance, and active defensive impairment:

Covert Interactive Access & Headless Desktop Control:

• Hidden Virtual Network Computing (HVNC) (0xE0–0xE2): Spawns a fully isolated, parallel desktop session, allowing the operator to silently navigate applications, open browsers, and manipulate internal network sessions without alerting the active user.
• Virtual Display Driver Manipulation (0xE9–0xEA): Programmatically installs and uninstalls custom virtual display drivers to create invisible monitor environments, ensuring seamless desktop streaming even on headless or locked endpoints.
• Embedded SOCKS5 Pivoting (0x0B–0x0D, 0xF5–0xF9): Operates as an internal proxy relay and tunneling node, allowing attackers to route external malicious traffic deeper into internal enterprise segments.

Full-Spectrum Surveillance & Wiretapping:

• Live Multi-Channel Eavesdropping: Streams live webcam video (0x4A–0x4C), captures microphone feeds (0x4D–0x4E), and intercepts system speaker audio via loopback capture (0x53–0x54) to monitor private communications and meetings.
• Targeted Keystroke & Clipboard Synchronization: Combines offline keystroke logging (0x3C) with active window tracking (0x99) and keyword-triggered filters (0xC0). It synchronizes the victim's clipboard in real-time (0x2E–0x32, 0x43), capturing copied credentials, tokens, and sensitive text.

Dynamic Cryptocurrency Clipping & Credential Theft:

• Configurable Clipboard Hijacker (0x33–0x36, 0x3F, 0x45, 0x56–0x5A): Continuously inspects clipboard contents against an operator-updatable regex library of major cryptocurrency wallet formats (Bitcoin, Ethereum, Monero, etc.), instantly substituting the victim’s destination address with an attacker-controlled wallet.
• Chromium Profile Harvesting (0x38, 0xE8): Systematically extracts stored autofill data, authentication cookies, and saved account credentials directly from Chromium-based browsers.

Host Defense Impairment & Operator Disruption:

• Proactive Security Blinding: Adds programmatic exclusions for malicious paths and processes directly into Windows Defender (0xC5, 0xC7), modifies host firewall filtering policies (0x25–0x2A), and deletes Volume Shadow Copies (0xC6) to impede local recovery efforts.
• Active Disruption & Operator "Trolling" Suite (0xB8–0xBE, 0xF0–0xF2): Features native commands for user disruption, including locking user input, forcing BugCheck/BSOD crashes, hiding system taskbars, injecting text-to-speech audio alerts, and launching interactive direct-messaging windows on the victim's screen.

Appendix A – Indicators of compromise (IOC) summary

File hashes

Network indicators

Appendix B – Trellix detection signatures

Appendix C – MITRE ATT&CK technique mapping

Discover the latest cybersecurity research from the Trellix Advanced Research Center.