Lazarus, DPAPI, and the art of leaving nothing behind in RemotePE
Most incident response playbooks share a foundational assumption: the attacker left something on disk. A binary, a script, a configuration file, a registry key, a prefetch artifact, something with a modification timestamp and a hash you can run through VirusTotal. The entire discipline of disk forensics rests on this premise, and for most of the threat landscape it holds. Lazarus has decided it prefers the other scenario.

On May 22, 2026, researchers Yun Zheng Hu and Mick Koomen at Fox-IT, an NCC Group subsidiary, published the technical breakdown of a three-stage toolchain they encountered during multiple incident response engagements at financial and cryptocurrency organizations. The toolset, composed of DPAPILoader, RemotePELoader, and RemotePE, forms a chain specifically engineered to give disk forensics as little as possible to work with. The final stage, RemotePE itself, never touches the filesystem at any point in its execution. Neither sample appeared on VirusTotal prior to publication, a detail that speaks directly to the operational security philosophy behind the toolset’s design.
The DPAPILoader, RemotePELoader, and RemotePE toolset represents a deliberate effort to minimize forensic footprint, according to Fox-IT. The actor uses this more sophisticated RAT for high-value targets that require a higher degree of operational security, with the toolset’s environmental keying, memory-only execution, EDR evasion, and low forensic footprint suggesting it is purpose-built for long-term observation campaigns. Lazarus is not in a hurry. The idea is to be present, undetected, for as long as it takes to understand the target well enough to execute a high-impact financial operation.
The entry point through Telegram meeting lures
The intrusion path begins less like a cinematic breach than a routine business interaction. Lazarus operators pose as trading firm employees on Telegram, then use fake versions of Calendly and Picktime to arrange meetings and make the lure feel ordinary. Once the target approves a meeting, the first malware component is installed and the chain starts moving. The human-in-the-loop approach works precisely because it does not feel like an attack. The victim is responding to a staged professional exchange, not clicking a suspicious attachment.
This social engineering model is consistent with what Fox-IT documented in its September 2025 research on this Lazarus subgroup, which at that point was deploying PondRAT and ThemeForestRAT. In the incidents that led to the RemotePE discovery, the actor had replaced ThemeForestRAT and PondRAT with a more sophisticated memory-only toolset. The earlier tools were noisier, more detectable, and apparently considered adequate only for lower-priority targets. When the target is worth the effort, the operator switches to RemotePE.
The Lazarus Group has already stolen about 577 million dollars in cryptocurrency in the first four months of 2026 alone, accounting for 76% of all crypto thefts worldwide according to blockchain analytics firm TRM Labs. Their total recorded theft since 2017 now stands at six billion dollars. These are not opportunistic intrusions. They are deliberate, patient operations that finance a state-level strategic program. The quality of the tooling matches the objective.
DPAPILoader and operating system abuse
The first stage of the chain is where the design philosophy becomes apparent. DPAPILoader is implemented as a DLL with a single job: decrypt and load the next stage from disk using the Windows Data Protection API.
In the incident response case, it was found as C:\Windows\System32\Iassvc.dll, installed under the service name “Internet Authentication Service.” The filename and service name are chosen to mimic the legitimate Windows Server Internet Authentication Service and its accompanying DLL C:\Windows\System32\iassvcs.dll, note the extra ‘s’ in the filename. Three samples were identified across roughly nine months of development: Iassvc.dll (PE timestamp November 2023), sspicli.dll (February 2024), and wmiclnt.dll (August 2024), each using a different loading mechanism but the same core behavior.
The payload itself is stored in C:\ProgramData\Microsoft\Windows\DeviceMetadataStore\en-US\*.*, a directory normally used for Windows device metadata Cabinet files. DPAPILoader scans for any file in that path that does not begin with the Cabinet magic bytes (MSCF / 4D 53 43 46) and is larger than 50 KB. When found, it decrypts the content using DPAPI, then additionally XORs every byte with 0x8D before loading the result in memory via libpeconv, a reflective PE loading library.
The DPAPI choice is elegant in ways that matter specifically to defenders and analysts. DPAPI ties its cryptographic keys to a specific user account on a specific machine, managed entirely by the operating system. The caller simply invokes encrypt or decrypt. This gives the attacker two things at once: the encrypted payload on disk is completely useless without the victim’s keys, so uploading the sample to VirusTotal yields nothing analyzable; and because each deployment encrypts the payload fresh on the target machine, the ciphertext hash differs across every victim, defeating hash-based detection entirely. By combining environmental keying via DPAPI with fully in-memory execution of the final payload, the actor ensures that forensic imaging of the disk will not yield recoverable artifacts of RemotePE.
The only way to recover the decrypted payload is what Fox-IT actually did: acquire a full forensic image of the compromised machine, extract the DPAPI master keys from it, and use them to decrypt the blob. The analysts were able to recover the malware only through complete forensic images containing the compromised system’s DPAPI keys, which drastically reduces the value of uploading encrypted artifacts to VirusTotal. The forensic image is not just useful here, it is the only path to analysis. This is worth noting for IR teams that default to triage collection: in a RemotePE engagement, partial collection is close to useless.
RemotePELoader, EDR unhooking, and ETW suppression
The second stage, decrypted from the DPAPI-protected blob, handles EDR evasion and C2 communication. RemotePELoader spawns a thread that first applies evasion techniques, reads the configuration, and then enters a C2 polling loop. It has no RAT functionality of its own; its sole purpose is to load the next stage.
The evasion begins before anything else happens. RemotePELoader implements the TartarusGate variant of the HellsGate technique, dynamically resolving Windows syscall numbers at runtime by scanning ntdll.dll for syscall stubs. It collects the SSNs for NtOpenSection, NtMapViewOfSection, NtUnmapViewOfSection, NtProtectVirtualMemory, and NtClose, then uses those direct syscalls to iterate the Process Environment Block’s module list and remap each DLL from its \KnownDlls section object. The result is that every in-memory copy of a system DLL hooked by an endpoint security product gets replaced with a clean one. Userland API hooks, the mechanism most EDR solutions use to intercept API calls and detect suspicious behavior, are effectively removed.
The second evasion technique patches Event Tracing for Windows. ETW is the Windows telemetry substrate that security products use to receive runtime behavioral signals from processes. RemotePELoader overwrites the EtwEventWrite function with four bytes:
48 33 C0 ; XOR RAX, RAX
C3 ; RET
This causes EtwEventWrite to return immediately with a zero result, suppressing all ETW event generation for the process. Any security tooling that relies on ETW telemetry goes blind.
The configuration is stored in the same DeviceMetadataStore\en-US\ path as the DPAPI payload, also encrypted with DPAPI and XORed with 0x8D. The configuration structure defines up to three C2 URLs, sleep intervals, proxy settings, and a configurable HTTP User-Agent string. After reading configuration, RemotePELoader enters a polling loop: it checks in with the C2 server via HTTP POST using a cookie-based protocol designed to mimic Microsoft telemetry traffic, with fields named MSCC, MicrosoftApplicationsTelemetryDeviceId, MSFPC, and others that fit naturally into the noise of a Windows environment communicating with Microsoft services.
In tests, the server did not immediately return a payload, suggesting an actor-in-the-loop model where the operator manually decides when to deliver it. Once the operator decides the target is worth activating, the server returns RemotePE encrypted with AES-GCM, Base64-encoded, inside a JSON object at the odata.metadata key.
RemotePE in memory and RAT behavior
The final stage is a fully-featured RAT written in C++, sharing infrastructure code with RemotePELoader: the same C2 communication logic, the same AES-GCM encryption using SplitMix64-derived keys, the same configuration file on disk. RemotePELoader and RemotePE each verify they were loaded by the previous stage by checking that lpReserved == 0x1000 in DllMain, enforcing the integrity of the chain.
RemotePE runs two threads. IChannelController manages C2 communications, polling the server at randomized intervals. IMiddleController processes incoming commands and queues responses. The RAT supports six command classes: IConfigProfile for C2 configuration management, IConsole for command execution and DLL module management, IFileExplorer for filesystem operations, IProcess for process enumeration and creation, ITimer for sleep and self-termination, and IPing as a no-op. One notable detail: the file deletion command overwrites each target file with constant bytes in seven passes before renaming and deleting, a secure deletion pattern consistent with PondRAT and POOLRAT, two earlier Lazarus malware families. The operator, it seems, is careful about leaving artifacts.
RemotePE also implements a plugin system. The operator can register additional DLL payloads at runtime as “shellcodified DLLs,” valid both as Windows DLLs and as reflective shellcode. Multiple plugins can coexist simultaneously. The attacker can extend the RAT’s capabilities dynamically without ever writing a new binary to disk.
While sleeping between C2 polls, RemotePE monitors for the existence of a specific Windows event named 554D5C1F-AABE-49E4-AB57-994D22ECED28. If the event exists, RemotePE wakes immediately. The event is never created by the malware itself, pointing to an external out-of-band signaling mechanism that allows the operator to wake the RAT on demand.
The C2 infrastructure is hosted on Namecheap shared hosting, consistent with what was observed in earlier campaigns involving ThemeForestRAT and PondRAT. The use of shared hosting makes IP-based blocking ineffective, since the same server hosts legitimate domains.
Hunting RemotePE with IOCs, YARA rules, and memory evidence
The absence of disk artifacts does not mean the infection is undetectable. It means detection requires shifting the focus from disk forensics to memory forensics, behavioral analysis, and network telemetry.
For SOC and IR teams, a practical first-hour triage workflow can significantly improve outcomes:
- Acquire a full memory image before rebooting or containment actions that could destroy volatile evidence.
- Capture suspicious service entries and
ServiceDllvalues underHKLM\SYSTEM\CurrentControlSet\Services. - Collect all files from
C:\ProgramData\Microsoft\Windows\DeviceMetadataStore\en-US\and preserve original metadata. - Prioritize process-memory inspection for anonymous executable regions and thread start addresses in private VAD ranges.
- Hunt for ETW suppression and unhooking behavior in telemetry gaps around suspicious processes.
- Correlate outbound HTTP POST traffic that combines Microsoft-like cookie names with unusual server fingerprints.
On disk, several artifacts remain. The DLL service itself, whichever masquerade name is used, appears in the service registry. Defenders should alert on service creation where ServiceDll points to a DLL in System32 with a name closely resembling a legitimate Windows DLL but with minor differences. The encrypted payload files in C:\ProgramData\Microsoft\Windows\DeviceMetadataStore\en-US\ that are larger than 50 KB and do not begin with MSCF magic bytes are anomalous and detectable with file integrity monitoring. The DPAPI-encrypted configuration file in the same path, smaller than 20 KB, is equally anomalous.
In memory, the VAD tree of the host process will show private executable regions with no associated file on disk: the canonical signature of reflective PE loading, whether that is DPAPILoader mapping RemotePELoader, or RemotePELoader mapping RemotePE. As covered in detail in Volatility cheatsheets and process memory analysis, private VAD nodes with PAGE_EXECUTE_READWRITE or PAGE_EXECUTE_WRITECOPY protection and no backing file are the first thing to examine in a svchost or any host process that has been used as the DPAPILoader carrier. The thread start addresses pointing into these anonymous regions complete the picture.
On the network, organizations with TLS inspection can look for the characteristic cookie field patterns in HTTP POST requests: the combination of MSCC, MicrosoftApplicationsTelemetryDeviceId, MSFPC, at_check, and ai_session fields in the same cookie header is unusual for legitimate Microsoft telemetry traffic. The JSON key odata.metadata appearing in C2 responses, combined with Base64-encoded AES-GCM content, is a strong indicator. The confirmed C2 domain from the Fox-IT investigation is aes-secure[.]net, hosted on Namecheap shared infrastructure.
Fox-IT also published YARA rules and IOCs in the same report. The following YARA rule, derived from the described DPAPILoader behavioral indicators, can be used for hunting:
rule Lazarus_DPAPILoader_Masquerade {
meta:
description = "Detects DPAPILoader masquerading as Windows IAS service DLL"
author = "Based on Fox-IT research by Yun Zheng Hu and Mick Koomen"
reference = "https://blog.fox-it.com/2026/05/22/remotepe-the-lazarus-rat-that-lives-in-memory/"
tlp = "WHITE"
strings:
// XOR 0x8D obfuscation key applied to strings (Iassvc.dll samples)
$xor_key = { 8D }
// DeviceMetadataStore staging path (wide string, partially deobfuscated)
$dms_path_w = "DeviceMetadataStore" wide
$dms_path = "DeviceMetadataStore"
// Cabinet magic bytes check (the loader skips files starting with MSCF)
$mscf_check = "MSCF" ascii
// libpeconv loading artifact
$libpeconv = "libpeconv" ascii nocase
// ServiceMain export present in first observed sample
$export_svc = "ServiceMain" ascii
condition:
uint16(0) == 0x5A4D // MZ header
and filesize < 500KB
and (
($dms_path or $dms_path_w)
and $mscf_check
)
and ($export_svc or $libpeconv)
}
rule Lazarus_ETW_Patch_Sequence {
meta:
description = "Detects ETW EtwEventWrite patch bytes used by RemotePELoader"
author = "Based on Fox-IT research"
reference = "https://blog.fox-it.com/2026/05/22/remotepe-the-lazarus-rat-that-lives-in-memory/"
tlp = "WHITE"
strings:
// XOR RAX, RAX ; RET (minimal ETW patch)
$etw_patch = { 48 33 C0 C3 }
// EtwEventWrite target function name
$etw_func = "EtwEventWrite" ascii
condition:
uint16(0) == 0x5A4D
and $etw_patch
and $etw_func
}
For SIEM-based detection, the following Sigma rule targets the service creation event that establishes DPAPILoader’s persistence:
title: Lazarus DPAPILoader service masquerade
id: a3f17c82-9e4d-4b2a-8c01-df6e4a5b9921
status: experimental
description: >
Detects creation of a Windows service with a name and DLL path closely
mimicking the legitimate Windows IAS service, consistent with the
DPAPILoader persistence technique documented by Fox-IT in May 2026.
references:
- https://blog.fox-it.com/2026/05/22/remotepe-the-lazarus-rat-that-lives-in-memory/
author: Based on Fox-IT research
date: 2026/05/27
tags:
- attack.persistence
- attack.t1543.003
- attack.defense_evasion
- attack.t1036.004
logsource:
product: windows
category: registry_set
detection:
selection_service_dll:
TargetObject|contains: 'SYSTEM\CurrentControlSet\Services\'
TargetObject|endswith: '\Parameters\ServiceDll'
Details|contains:
- 'Iassvc.dll'
- 'sspicli.dll'
- 'wmiclnt.dll'
selection_service_name:
TargetObject|contains:
- '\Services\Ias\'
condition: selection_service_dll or selection_service_name
falsepositives:
- Legitimate IAS service (verify DLL path ends with iassvcs.dll, not Iassvc.dll)
level: high
---
title: Suspicious non-Cabinet file in DeviceMetadataStore
id: b7c29d14-1f3e-4c8b-9a02-ec7f3b6d8034
status: experimental
description: >
Detects creation of a large non-Cabinet file in the Windows
DeviceMetadataStore directory, consistent with DPAPILoader payload staging.
references:
- https://blog.fox-it.com/2026/05/22/remotepe-the-lazarus-rat-that-lives-in-memory/
author: Based on Fox-IT research
date: 2026/05/27
tags:
- attack.defense_evasion
- attack.t1027
logsource:
product: windows
category: file_event
detection:
selection:
TargetFilename|contains: '\ProgramData\Microsoft\Windows\DeviceMetadataStore\en-US\'
TargetFilename|endswith:
- '.dll'
- '.dat'
- '.bin'
filter_cabinet:
# Legitimate Cabinet files begin with MSCF magic bytes; this rule
# fires on creation events and requires follow-up verification
TargetFilename|endswith: '.devicemetadata-ms'
condition: selection and not filter_cabinet
falsepositives:
- Legitimate device metadata packages (verify file begins with MSCF magic bytes)
level: medium
The confirmed network IOC is aes-secure[.]net, used as a RemotePELoader C2 endpoint. Through fingerprinting of C2 server characteristics, Fox-IT identified additional domains and servers beyond those found during the initial incident response engagement. At the time of writing, several C2 servers never returned a payload during emulated sessions, though some remain live. The full IOC list, including additional domains identified through infrastructure pivoting, is published in the Fox-IT report. Additional C2 hunting can be performed by searching for Namecheap-hosted servers presenting the same HTTP response fingerprint, as the shared hosting infrastructure has been used consistently across this Lazarus subgroup’s campaigns.
For memory forensics investigations, the recovery path on a compromised host requires a full physical memory image, not a triage collection. Volatility 3 plugins windows.malfind and windows.vadinfo will surface the anonymous executable private regions in the host process VAD tree where RemotePELoader and RemotePE reside. The Fox-IT team used their own open-source tool Dissect to extract DPAPI master keys directly from the forensic image and decrypt the staged payloads, which is the only viable recovery path for the DPAPILoader-protected blobs. Without those keys, the encrypted files on disk will remain opaque regardless of the analysis tools applied to them.
The Windows named event 554D5C1F-AABE-49E4-AB57-994D22ECED28 can be monitored as an additional behavioral indicator: its creation by any process other than a known legitimate application is a strong signal of RemotePE activity.
The broader implication for defenders is one that the memory forensics community has been pressing for years. Lazarus has quietly been refining its approach, trading noisy intrusions for something far more surgical, and that refinement specifically targets the gap between what disk-focused detection covers and what it does not. The answer is not to abandon disk forensics, which remains relevant for the persistence artifacts that DPAPILoader does leave behind, but to treat memory forensics and network telemetry as first-class evidence sources rather than supplementary steps. RemotePE cannot hide from a well-instrumented memory image. It can hide from almost everything else.