FTP Banners: The New Dead Drop Resolver Delivering Novel RATs

STRU found threat actors using FTP banners as Dead Drop Resolvers – legitimate services or protocols abused to host C2 addresses and commands, so the stager never carries them itself. Live since early July 2026 and still active. The infrastructure led to two previously undocumented RATs: E4del, an Electron implant hiding under a signed Discord binary, and PINHOLE, a multi-stage RAT pulling its C2 from Pinterest and SurveyMonkey behind Cloudflare Workers.

Security products have become increasingly effective at detecting suspicious commands used for malware delivery. Consequently, threat actors are adopting more creative methods to bypass these defenses, such as utilizing Dead Drop Resolvers (DDRs): alternative locations, including legitimate web services or protocols, used to acquire malicious strings, Command and Control (C2) configurations, or commands.

During an investigation, the SOCRadar Threat Research Unit (STRU) identified the active abuse of FTP banners as DDRs to distribute malicious commands, a technique observed in the wild since early July 2026. Further infrastructure analysis led to the discovery of two previously undocumented Remote Access Trojans (RATs), which we have named E4del and PINHOLE.

Key Points

• STRU discovered active abuse of FTP banners as DDRs, allowing malware stagers to fetch commands directly from the protocol’s initial response.
• While currently observed in malicious LNK files, this technique is highly versatile and easily adaptable for “ClickFix” social engineering campaigns.
• FTP-based DDRs were found delivering two previously undocumented RATs: E4del and PINHOLE, tracked as separate clusters.
• E4del is a modular, Electron-based RAT offering eight specialized commands, such as live desktop streaming, screenshot capture, and privilege escalation.
• E4del’s beaconing mechanism implements a tiered jitter system, dynamically transitioning between three distinct states (Active, Semi-Active, Inactive) based on the elapsed time since its last received task.
• PINHOLE is a sophisticated multi-stage RAT with fourteen distinct command types, including browser credential theft, file upload/download, and screenshot capture.
• To evade detection, PINHOLE employs Halo’s Gate and Early Bird APC Injection. Additionally, it leverages legitimate platforms like Pinterest and SurveyMonkey to resolve its C2 while proxying its traffic through Cloudflare Workers.
• PINHOLE operators also maintain an “FTP Stats Panel” to track script execution and IP addresses connected to their infrastructure.

FTP Banners as a DDR

Based on a hunt, a post from MalwareHunterTeam was identified. The post was the first to document the capability of LNK files (likely spread through phishing) to use FTP banners as a DDR for fetching commands. While threat actors typically utilize legitimate web services, such as X, GitHub, or YouTube, to provide cover through high-volume, expected network traffic, FTP banners represent a novel alternative. However, this method is less stealthy than traditional web-based DDRs, as security teams are more likely to flag FTP connections to unknown servers as anomalous.

The following figure illustrates the delivery chain of the identified sample. The actors utilized Spanish-language lures, such as a “Voucher” claim, to entice users into executing a shortcut file that retrieves commands from an FTP banner. These commands subsequently connect to a WebDAV server to download and execute a DLL export function via rundll32.exe.

Since the infrastructure described in the original post was no longer active at the time of our analysis, we expanded our search for similar commands stored as FTP banners. By utilizing FOFA searches, we determined that this technique has been weaponized since early July 2026 and remains operational, with new infrastructure observed as recently as August 2026.

Investigation into this live infrastructure revealed two previously undocumented RATs, designated E4del and PINHOLE. We assess these as separate clusters using the same delivery technique. Due to their novelty, evidence is currently insufficient for actor attribution.

E4del: An Electron-based RAT Impersonating Discord

Analysis of the FTP banner at 157.254.194[.]31:21 revealed a multi-stage delivery chain. The initial commands fetch a second FTP banner from 167.148.41[.]164:21, which triggers a PowerShell script to download, extract, and execute a binary from a ZIP archive. The chain launches a legitimate Discord binary with the –init argument and the victim’s username.

As an Electron-based application, Discord requires a bundled Chromium and Node.js runtime environment to function. The threat actors exploit this architecture by including the necessary Electron environment files (i.e., d3dcompiler_47.dll and libEGL.dll) and replacing the application’s core logic within the resources/app.asar archive (responsible for bundling the source code and assets of the application).

Upon execution, the operating system identifies a digitally signed Discord.exe loading trusted dependencies, effectively masking the malicious code residing in app_bootstrap/index.js. The final payload is E4del, a Node.js-based RAT that provides extensive capabilities including evasion, persistence, system fingerprinting, and encrypted C2 communication.

Execution & Evasion

Upon execution, E4del immediately evaluates its command-line arguments to dictate its behavior and verify its environment. It looks for the –init flag followed by a username, checking that the current Windows user matches the provided argument. If the username does not match, the RAT terminates immediately. This serves as an anti-sandbox technique, ensuring the payload only detonates on the intended victim’s machine rather than in an automated analysis environment without the required arguments.

To maintain a zero-visibility profile, E4del dynamically appends several Chromium command-line switches to the underlying Electron application. By invoking switches such as headless, disable-gpu, and mute-audio, the RAT ensures no graphical user interface is ever rendered to the victim, reducing the application to a silent background process.

Persistence

Furthermore, it establishes persistence by utilizing Electron’s native login item settings (setLoginItemSettings), configuring the host executable (Discord.exe) to launch automatically upon user login with the necessary –init parameters.

System Profiling and Fingerprinting

Before reaching out to the attacker’s infrastructure, E4del conducts a localized fingerprinting phase to profile the infected machine. It generates a unique hardware identifier (HWID) by SHA256-hashing the MAC addresses of the system’s network interfaces alongside the CPU model. This ensures the attacker can uniquely track the infected host across varying network environments.

Following this hardware profiling, the RAT queries Windows Management Instrumentation (WMI) or the system registry to enumerate installed antivirus products, specifically hunting for security solutions like Windows Defender, Symantec, ESET, Avast, McAfee, Sophos, CrowdStrike, and Kaspersky.

Command and Control (C2)

E4del’s communication protocol is built on encrypted HTTP POST requests directed at a hardcoded C2 server (http[://]157.254.194[.]31). All traffic is secured using AES-256-CBC encryption, relying on a static, hardcoded passphrase (protected!) and a randomly generated Initialization Vector (IV) for each request. To evade basic network detection, the HTTP requests spoof a legitimate Google Chrome User-Agent (Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.0.0 Safari/537.36) and utilize standard browser headers.

The beaconing mechanism is highly dynamic, implementing a tiered jitter system to blend in with normal network traffic. The RAT dynamically transitions between three distinct states based on the elapsed time since its last received task. Within the first 20 seconds of receiving a command, E4del operates in “Active“ mode, rapidly checking in with random sleep delays between 200 milliseconds and 2 seconds. If no new tasks arrive within 20 to 40 seconds, it enters a ”Semi-Active“ state, lengthening its sleep interval to between 2 and 5 seconds. Beyond 40 seconds of inactivity, the RAT drops into a full ”Inactive“ mode, scaling back check-ins to random delays between 5 and 9 seconds.

When transmitting data back to the server, the RAT employs a unique string replacement technique, swapping standard pipe characters with the custom %e4del% delimiter. This prevents shell command outputs from accidentally breaking the attacker’s server-side output parser. Encrypted beaconing requests are sent via HTTP POST in the /beacon endpoint and contain the following structure: “H|${hostId}|${hwid}|${avInfo.name}|${Date.now()}”.

Once the encrypted heartbeat is dispatched, the C2 server responds with encrypted tasks that dictate the RAT’s next actions. E4del supports a robust suite of post-exploitation commands:

PINHOLE: A Stealthy RAT Leveraging Pinterest & SurveyMonkey as DDRs

In a separate instance of FTP banner abuse, the STRU uncovered a more sophisticated multi-stage delivery chain culminating in the deployment of another novel RAT, which we have designated PINHOLE. This RAT exhibits stealthy capabilities, including the storage of configuration data in Alternate Data Streams, the implementation of the Halo’s Gate and Early Bird APC Injection to bypass Endpoint Detection and Response (EDR) solutions, and the utilization of Pinterest pins and SurveyMonkey questions as DDRs to acquire its C2 and proxy it behind Cloudflare Workers.

Delivery Chain

The FTP banner at 209.99.185[.]38:21 was found to contain commands that utilize the MSXML2.XMLHTTP COM object within PowerShell to retrieve a secondary command script from hxxps[://]cloudflare.milicare[.]in/app/c. This script is saved as %TEMP%u.cmd, executed, and subsequently deleted to minimize the forensic footprint.

The downloaded script functions as a dropper for the final payload. It employs echo commands to write a large block of Base64-encoded data into a file named %TEMP%calc. To evade detection, the data is wrapped in —–BEGIN CERTIFICATE—– and —–END CERTIFICATE—– headers, masquerading as a legitimate certificate file.

The dropper then creates a temporary batch script, %TEMP%calc_runner.cmd, which contains the logic to unpack and execute the smuggled binary. This temporary script leverages certutil -decode to transform the Base64 “certificate” file into a Cabinet archive (%TEMP%calc.cab) and then uses the expand utility to extract and run the final executable, %TEMP%calc.exe. Interestingly, error messages were identified in Spanish. Following execution, the script waits three seconds before deleting all temporary files to maintain operational stealth.

The actors behind PINHOLE also maintain a dedicated “FTP Stats Panel” at hxxp[://]69.48.228[.]126:5000/. This interface allows them to monitor the efficacy of their campaigns by tracking script executions, total connections, and unique active or blocked IP addresses interacting with their FTP infrastructure. Interestingly, the script had only run 11 times at the time of analysis, suggesting the campaign was in its early stages.

First Stage: An Evasive Wrapper

The executed 64-bit binary masquerades as an update utility from a fictitious entity, Weston Computing Systems Ltd. It maintains its stealth by importing only three functions directly and obfuscating the remainder. All strings reside encoded in the .rdata section and are decoded on demand into .bss at runtime using individual 32-bit keys. The binary avoids storing Win32 API string names entirely. Instead, it dynamically resolves APIs at runtime by walking the PEB loader data and matching 32-bit function hashes against module export tables.

The very first action of the PINHOLE binary is to call a guard that resolves the names of core Windows components like KERNEL32.DLL, kernelbase.dll and ntdll.dll and inspects their Export Address Tables for wildcard templates (xxxx/xxxxx). It specifically looks for synthetic, hollowed-out “stub” DLLs that emulators and analysis environments use to fake a real operating system. If the guard detects these artificial structures, it forces the executable to immediately exit.

Next, it implements the Halo’s Gate evasion technique to dynamically retrieve System Service Numbers (SSNs) for direct system calls, bypassing user-mode EDR hooks. Security tools often monitor software by placing ‘hooks’ inside key system libraries like ntdll.dll.

While earlier techniques like Hell’s Gate fail when an EDR hooks the target function and overwrites its SSN bytes, Halo’s Gate overcomes this by exploiting the fact that Windows assigns SSNs sequentially in memory: if the target function is hooked, it scans neighboring unhooked functions immediately above or below it in memory, extracts their SSNs, and uses simple arithmetic offsets to calculate the target’s actual SSN. SSNs serve as the unique index numbers Windows uses to route low-level kernel requests. Once retrieved, PINHOLE executes system calls directly from its own code to run malicious operations undetected.

Persistence

For persistence, PINHOLE creates a copy of itself in C:\Users\{user}\AppData\Local\Packages\{random_name}\{random_name}.exe and registers it via the registry. It creates a “Load” value located at HKCUSoftwareMicrosoftWindows NTCurrentVersionWindows, which is a legacy Windows feature designed to automatically load programs upon user login.

Alternate Data Streams & C2 Retrieval

Another notable feature of the RAT is its use of host files with NTFS Alternate Data Streams (ADS) as its configuration datastore. PINHOLE stores its build token and C2 DDR encryption key in the ADS of two local desktop.ini files. To conceal its C2 DDRs, the RAT encodes them using a custom base-41 alphabet (0123456789abcdefghijklmnopqrstuvwxyz.-_:/) before encrypting them with a SplitMix64-based PRNG algorithm.

The algorithm seeds its internal state using three rounds of SplitMix64, producing an 8-byte keystream per round. Once decrypted, streams 1, 2, and 3 reveal specific URLs used to fetch C2 infrastructure hosted on legitimate platforms like Pinterest pins and SurveyMonkey survey questions:

To obtain its C2, PINHOLE uses curl to fetch content from Pinterest pins or SurveyMonkey survey questions.

The HTML response contains hidden C2 settings bounded by the delimiters ====D5===D6==== and ====D7===D8====, which store two colon-separated domains. The first field (D5/D6) represents the actual C2 server (nokierojotiarmx[.]com), while the second (D7/D8) specifies a Cloudflare Worker domain (worker-1785198984-xsekhi[.]api-62c3cac6[.]workers[.]dev) used for proxying.

By leveraging trusted Cloudflare services, the operators conceal traffic from network security controls. PINHOLE constructs its primary request using the format https://<D7/D8 field>/https://<D5/D6 field>, falling back to direct communication (https://<D5/D6 field>) if proxying fails.

Second Stage Retrieval & Unpacking

Once C2 resolution is complete, PINHOLE verifies server availability by issuing a GET request to {C2}/api/health, validating that it receives an HTTP 200 response containing the string yes. Upon successful validation, the RAT makes a second GET request to {C2}/api/bc to retrieve its next-stage payload, which it then hands off to an Early Bird APC Injection routine into a legitimate process (detailed next). Notably, six layers of unpacking are executed across these steps before final stage execution occurs.

Layer 1 – Dressing as an Image

The C2 response disguises its payload as a JPEG by prefixing it with an SOI/APP0 header (FF D8 FF E0). PINHOLE strips this 4-byte header and decrements every subsequent byte by one to restore the original content. These fake magic bytes camouflage the traffic against content inspection defenses and set the loader’s expected length offset.

Layer 2 – Reading the Container

The recovered payload is actually shellcode which is padded with multi-byte NOPs and benign junk instructions that modify CPU flags without altering registers or the memory state. The actual payload execution begins at offset 0x38 with a call to 0xEB20. This transfers control to an XOR decryption stub and pushes the return address of 0x3D onto the stack, which is the start of the embedded configuration.

Container layout:

Layer 3 – The Throwaway Stub

The stub routine decrypts the 4 KB loader at 0xF000 using a repeating 4-byte XOR key (1F 3B 39 27) and immediately jumps to it.

Layer 4 – Shellcode Fluctuation

Control now passes to the 4 KB loader, whose purpose is to execute the next-stage payload at 0x10000 without ever exposing it entirely in plaintext.

First, the loader dynamically resolves VirtualProtect, RtlAddVectoredExceptionHandler, and RtlRemoveVectoredExceptionHandler from stack strings encrypted with XOR 0xA1. It then strips execution permissions from the stage payload region (marking it as PAGE_READWRITE via VirtualProtect) and intentionally executes code within that protected boundary.

Attempting to run code from a non-executable page triggers a Data Execution Prevention (DEP) EXCEPTION_ACCESS_VIOLATION (0xC0000005, ExceptionInformation[0] == 8). The loader anticipates this crash, having previously registered a Vectored Exception Handler (VEH) to trap the fault.

Upon intercepting the exception, the VEH validates that the faulting address resides within the payload region, and then:

• Re-encrypts the previously active 4 KB page using a static 64-bit XOR cipher derived from a hardcoded key (0x014D6302A361A315) and the page index.
• Decrypts the target page requested by the CPU.
• Upgrades the target page’s permissions to PAGE_EXECUTE_READ.
• Returns EXCEPTION_CONTINUE_EXECUTION to resume execution seamlessly.

This flow ensures that only a single 4 KB page of the payload remains decrypted and executable at any given time (a mechanism commonly referred to as shellcode fluctuation). A full process memory dump captured at an arbitrary moment yields only one readable page, leaving the remaining ~11 KB fully encrypted.

Statically decrypting all four pages uncovers the underlying payload: a 15.5 KB position-independent loader compiled with MinGW-w64 that resolves API imports via PEB traversal and hash matching. This marks the end of the RAT developer’s custom wrapper code. The remaining payload stages rely on Donut (an open-source shellcode generator) executing its standard initialization, driven by the configuration stored at offset 0x3D since Layer 2.

Layer 5 – Configuration Blob

The configuration blob matches Donut’s native Donut Instance structure: a self-contained header detailing execution targets, compression parameters, required API imports, and decryption keys. The instance is encrypted via Chaskey in Counter (CTR) mode, with its key and initial counter stored in cleartext at the head of the structure.

Donut’s configuration fields:

Layer 6 – aPLib Decompression

Preceded by a header detailing its packed and unpacked sizes, the final payload is compressed using the aPLib algorithm. Decompressing the stream yields an exact size match, confirming that all preceding layers were correctly reversed. The extracted final payload is a 119 KB native x86-64 PE executable compiled with MinGW-w64.

Early Bird APC Injection

After retrieving the final stage, PINHOLE injects it into ApplicationFrameHost.exe via Early Bird APC Injection. This is an evasion technique that injects code into legitimate, suspended processes and executes it before the target process’s main entry point or security hooks are initialized. It works by creating a signed Windows process in a suspended state, writing the payload into the allocated memory space of that process, and queuing an Asynchronous Procedure Call (APC) to its main thread. When the process resumes, the APC runs the injected payload before executing the application’s actual code.

Final Stage: PINHOLE RAT

The final injected executable contains the core RAT functionality of PINHOLE, communicating with its C2 server over HTTP GET and POST requests. The RAT resolves its C2 using the same DDR infrastructure mentioned in the earlier dropping stages.

C2 Endpoints

PINHOLE utilizes five primary HTTP endpoints for beaconing, registration, tasking, and exfiltration:

C2 Commands

PINHOLE supports 14 command IDs covering system reconnaissance, file manipulation, execution, screenshot capture, and interactive shell access:

Conclusion

The identification of FTP banners as DDRs presents a creative, albeit less stealthy, evolution in malware delivery, allowing threat actors to embed malicious commands directly within the protocol’s banner. Although initial access methods point to shortcut-file phishing, attackers could easily adapt FTP banner abuse for ClickFix campaigns as well. Further exploration of this trend led to the discovery of E4del and PINHOLE, two previously undocumented RATs with distinct operational frameworks. E4del distinguishes itself as a modular, Electron-based RAT that masquerades as legitimate Discord processes while employing a dynamic tiered jitter system for its C2.

In contrast, PINHOLE demonstrates advanced evasion through multi-stage delivery chains that leverage high-reputation platforms like Pinterest and SurveyMonkey for C2 resolution and proxying through Cloudflare Workers, loading additional modules and injecting into legitimate processes via Early Bird APC. Together, these campaigns highlight the persistent trend of actors weaponizing legitimate services and protocols to maintain stealth and operational security.

To defend against these tactics, security teams should restrict unapproved software through application controls, and inspect network traffic for stealthy abuse of trusted platforms and standard services. SOCRadar tracks emerging delivery techniques like FTP banner abuse across its XTI platform, correlating novel infrastructure with the malware families it delivers. To see how your organization’s external exposure and stolen credentials appear to an attacker, request a demo or start with the Free Edition.

MITRE ATT&CK TTPs

IoCs

The indicators below can be checked against your environment using IOC Radar, SOCRadar’s free threat intelligence lookup for IPs, domains, hashes, and URLs.

Network Indicators

Host Indicators