Beyond FTP Banners: How Dead Drop Resolvers Are Reshaping Malware Command and Control

Security researchers  disclosed an active malware-delivery technique in which attackers place malicious instructions inside FTP server banners.

An FTP banner is the short greeting returned when a computer first connects to an FTP server. Instead of displaying only a normal message such as “FTP server ready,” the malicious servers return commands that start the next stage of an infection.

The activity has been observed since early July 2026, with related infrastructure continuing to appear during August 2026. Further investigation led to two previously undocumented Remote Access Trojans named E4del and PINHOLE. The available evidence does not currently support attribution to a known threat actor.

Key Highlights

• Technique: FTP server banners abused as external command-delivery points

• Initial access: Malicious Windows .lnk shortcut files, likely delivered through phishing archives

• Observed lure: Spanish-language voucher-themed content

• Infrastructure research: Related servers identified through FOFA searches

• Malware families: E4del and PINHOLE

• E4del disguise: Malicious Electron code executed under a signed Discord binary

• E4del capabilities: Command execution, reverse shell, screenshots, live desktop streaming and additional payload delivery

• E4del communication: AES-256-CBC-encrypted HTTP requests with tiered jitter

• PINHOLE delivery: PowerShell, certutil, Cabinet archives and temporary scripts

• PINHOLE evasion: Sandbox checks, Halo’s Gate, shellcode fluctuation and Early Bird APC Injection

• PINHOLE configuration: Hidden inside NTFS Alternate Data Streams

• C2 resolution: Pinterest and SurveyMonkey content used to recover C2 information

• Proxy layer: Cloudflare Workers placed between infected systems and the primary C2

• PINHOLE capabilities: File operations, process control, screenshots, PowerShell access and support for retrieving a separate browser-stealer module

• Severity: High because both RATs can provide persistent remote control and support further compromise

When an FTP Greeting Becomes an Instruction Channel

FTP normally begins with a server response similar to:

220 FTP server ready

The three-digit code has a protocol meaning, while the text after it is controlled by the server administrator.

In this campaign, attackers use the same response area to return malicious instructions. The shortcut file connects to the FTP service, reads the banner and passes the returned command into the next stage of the attack.

The simplified behavior is:

Malicious Shortcut → FTP Connection → Banner Command → PowerShell or WebDAV → Payload Download → RAT Execution

The victim system does not need to complete a normal FTP login or transfer a file through FTP. The attacker only needs the opening response.

This makes the banner function as a Dead Drop Resolver, or DDR. A DDR is an external location that malware checks to retrieve a C2 address, command, payload location or configuration value instead of storing that information directly inside the malware.

Keeping the instruction outside the original attachment gives attackers several advantages:

• The first-stage file can remain small.

• Static analysis may not reveal the active payload location.

• The server-side command can be changed without rebuilding the malicious shortcut.

• Because the banner is controlled remotely, the same launcher could potentially be redirected to a different payload or second-stage location.

• The design could allow an operator to replace inactive second-stage infrastructure while continuing to use the original lure.

• An operator could replace the malicious banner content with harmless text when pausing or ending a campaign.

FTP-banner abuse is creative, but it is not completely invisible. Direct FTP traffic from a normal employee workstation to an unknown internet server may be unusual in many organizations and can provide defenders with a valuable detection opportunity.

How the Infection Starts and How the Infrastructure Trail Was Expanded

The observed activity uses malicious Windows shortcut files, likely placed inside compressed phishing attachments.

Some samples used Spanish-language voucher themes to convince the victim that the shortcut represented a legitimate document or claim form.

When opened, the shortcut contacts an attacker-controlled FTP server over TCP port 21 and reads the command contained in the server banner.

One documented chain used the returned command to connect to a WebDAV location, retrieve a DLL and execute an exported function through rundll32.exe.

The original infrastructure was no longer active when researchers began deeper analysis. STRU therefore searched for similar command text exposed through other FTP banners using FOFA.

This internet-wide search identified related infrastructure and helped researchers connect the banner technique to E4del and PINHOLE.

How E4del Reaches the Endpoint

The E4del infection chain begins with one FTP banner directing the victim toward another FTP server.

The second response triggers PowerShell to download and extract a ZIP archive before launching a legitimate Discord executable with an --init argument and the victim’s username.

Discord is built with Electron. Electron applications combine Chromium, Node.js and packaged application resources.

The attackers included a legitimate, digitally signed Discord.exe file but replaced the application logic stored inside the Electron resource package.

The malicious Node.js entry point was located at:

app_bootstrap/index.js

This creates a misleading trust relationship:

Signed Discord Executable + Modified Electron Resources = Malicious E4del Activity

The valid signature applies to the Discord executable itself. It does not validate the modified Electron resources or JavaScript files loaded alongside that executable. It does not prove that every application resource loaded beside it is safe.

How E4del Hides and Returns After Login

E4del checks its command-line arguments immediately after launch.

It expects an --init flag followed by a username and compares that value with the Windows user currently logged into the system.

If the values do not match, the malware exits. This can prevent automated sandboxes from observing the complete behavior when they do not reproduce the original username or launch parameters.

E4del also uses Chromium switches including:

• headless

• disable-gpu

• mute-audio

These options stop the normal Discord interface from appearing and allow the malware to work quietly in the background.

For persistence, E4del uses Electron’s login-item settings to start the executable automatically when the user signs in.

What E4del Learns About the Victim

Before fully registering with the attacker, E4del collects information about the infected computer.

Observed information includes:

• Windows username

• Computer name

• CPU model

• Network-interface MAC addresses

• Generated hardware identifier

• Installed antivirus and endpoint-security products

The hardware identifier is created by hashing the MAC-address information together with the CPU model using SHA-256.

E4del can query Windows Management Instrumentation or the registry to identify products such as Windows Defender, CrowdStrike, Kaspersky, ESET, Avast, McAfee, Sophos and Symantec.

E4del Command and Control

E4del communicates with its command server through HTTP POST requests.

The beacon data is encrypted using AES-256-CBC. The malware contains a static passphrase and creates a new initialization vector for each request.

Its requests use a Chrome-style User-Agent and common HTTP headers, making an isolated request appear similar to ordinary browser traffic.

E4del also changes how often it checks for tasks:

• Active: approximately 200 milliseconds to 2 seconds

• Semi-Active: approximately 2 to 5 seconds

• Inactive: approximately 5 to 9 seconds

This tiered jitter keeps the malware responsive when the attacker is active while reducing a fixed and easily recognized communication pattern during idle periods.

E4del Capabilities

E4del provides the attacker with several remote-control functions:

• Start a hidden command shell

• Execute arbitrary Windows commands

• Capture screenshots

• Stream the desktop through WebSockets

• Download individual files

• Download and extract additional packages

• Launch secondary payloads

• Attempt privilege escalation

The live desktop function captures repeated JPEG images and sends them to the attacker, creating a basic hidden monitoring channel.

The privilege-elevation function refers to a component named:

crypto32.node

That module was unavailable during the original investigation. E4del clearly attempts to use it for privilege elevation or UAC bypass, but the exact method was not fully confirmed.

PINHOLE Delivery

PINHOLE uses a separate and more complex infection chain.

An FTP banner returns a PowerShell command that uses the MSXML2.XMLHTTP COM object to retrieve another script.

The downloaded script is saved as:

%TEMP%\u.cmd

It is executed and then removed to reduce the evidence left on the endpoint.

The dropper writes a large Base64-encoded payload into:

%TEMP%\calc

The encoded content is wrapped in certificate-style headers so that it appears to be certificate data.

A temporary script named:

%TEMP%\calc_runner.cmd

uses certutil -decode to transform the Base64 content into:

%TEMP%\calc.cab

The Windows expand utility then extracts:

%TEMP%\calc.exe

The temporary decoding files are removed shortly after execution.

The chain can be summarized as:

FTP Banner → PowerShell → u.cmd → Base64 Certificate Disguise → certutil → Cabinet Archive → expand.exe → calc.exe

PINHOLE Operator Panel

The PINHOLE operators maintained an FTP statistics panel that recorded information such as:

• Script executions

• Total connections

• Unique active IP addresses

• Blocked IP addresses

The panel showed 11 script executions when researchers examined it.

This may indicate an early or limited operation, but it should not be treated as a complete victim count because the panel may not contain every server or historical event.

PINHOLE Anti-Analysis and EDR Evasion

The first PINHOLE executable presents itself as an update utility from a fictitious company named Weston Computing Systems Ltd.

The binary avoids storing many Windows API names in clear text. It resolves the required functions while running by inspecting loaded modules and comparing hashed names.

PINHOLE also checks Windows DLL structures for patterns associated with simplified emulators and automated malware-analysis environments.

If the system appears artificial, the malware can exit before exposing its full behavior.

PINHOLE also uses a direct-system-call method associated with Halo’s Gate. This is intended to reduce dependence on user-mode Windows functions that may be monitored or modified by endpoint-security products.

PINHOLE Persistence and Hidden Configuration

PINHOLE copies itself into a randomly named location under:

C:\Users\{Username}\AppData\Local\Packages\{random_name}\{random_name}.exe

It then creates a Load registry value under:

HKCU\Software\Microsoft\Windows NT\CurrentVersion\Windows

This causes the malware to start when the user logs into Windows.

PINHOLE stores important configuration information inside NTFS Alternate Data Streams attached to desktop.ini files.

The hidden information includes:

• Build token

• Encryption-related values

• Pinterest resolver locations

• SurveyMonkey resolver location

• Malware installation path

Alternate Data Streams make the extra information less visible during normal file browsing because the main desktop.ini file can still appear ordinary.

Pinterest, SurveyMonkey and Cloudflare Workers

PINHOLE does not depend only on a C2 address stored directly inside the executable.

It uses curl to retrieve attacker-controlled content from Pinterest pins and a SurveyMonkey survey.

The returned content contains information needed to identify:

• The primary PINHOLE C2 server

• A Cloudflare Worker used as an intermediary

The communication path becomes:

Infected Endpoint → Cloudflare Worker → Primary PINHOLE C2

Pinterest, SurveyMonkey and Cloudflare are legitimate services. The attackers abused specific content and infrastructure hosted through those platforms.

For defenders, the important question is not only whether Pinterest or Cloudflare was accessed. The process making the request, the exact URL, the response content and the connection that follows are more useful indicators.

PINHOLE Multi-Layer Protection

After resolving its C2, PINHOLE performs a health check and retrieves another payload.

The later stage is protected by several layers:

1. A fake JPEG header makes the payload appear like an image.

2. Junk instructions add noise to the loader.

3. XOR is used to decrypt another stage.

4. Shellcode fluctuation keeps most memory pages encrypted.

5. A Donut-based configuration controls the next loading stage.

6. aPLib decompression restores the final native Windows executable.

Shellcode fluctuation is particularly important because only a small memory page remains decrypted and executable at one time. A normal memory dump may therefore capture only part of the payload.

Early Bird APC Injection

PINHOLE injects its final payload into:

ApplicationFrameHost.exe

The malware creates the legitimate Windows process in a suspended state, writes the payload into its memory, queues an Asynchronous Procedure Call and then resumes the process.

This technique is known as Early Bird APC Injection because the malicious code can run early in the process lifecycle.

PINHOLE Capabilities

PINHOLE supports 14 command types covering:

• File and directory listing

• Changing and displaying the current directory

• Uploading files from the victim

• Downloading files to the victim

• Executing programs

• Deleting files

• Searching available drives

• Listing running processes

• Terminating processes

• Capturing screenshots

• Starting a persistent PowerShell session

• Executing PowerShell commands

• Retrieving an additional browser-stealing module

The separate browser-stealer module was unavailable during the investigation. PINHOLE contains the function required to retrieve it, but the exact collection behavior was not fully examined.

Attack Chain

The E4del chain can be summarized as:

Phishing Archive → Malicious LNK → FTP Banner → Second FTP Banner → PowerShell → ZIP Archive → Signed Discord.exe + Modified Electron Resources → E4del RAT → Encrypted C2 → Remote Access

The PINHOLE chain can be summarized as:

Phishing Archive → Malicious LNK → FTP Banner → PowerShell → u.cmd → Certificate-Style Base64 Data → certutil → Cabinet Archive → calc.exe → Pinterest/SurveyMonkey Resolver → Cloudflare Worker → Multi-Layer Payload → ApplicationFrameHost.exe Injection → PINHOLE RAT

What This Analysis Adds

• The discovery of E4del, PINHOLE and FTP-banner command delivery originates from STRU’s investigation. This article extends those findings through a defender-focused interpretation of how the technique can be detected and how similar resolver designs may evolve.
• First, the FTP banner can be viewed as a protocol-response resolver. Unlike traditional Dead Drop Resolvers that place information inside a webpage, repository or public post, this technique places the instruction inside an automatic network-service response.
• Second, the article proposes hunting for banner-only FTP sessions. In this pattern, an endpoint receives the opening FTP response but performs no normal authentication, directory listing or file transfer before launching PowerShell, CMD, rundll32 or another downloader.
• Third, the article considers a future split-information resolver model in which several external locations hold incomplete parts of the final configuration. No single resolver would reveal the complete Cth2 destination. This is a defensive research hypothesis and was not observed in the E4del or PINHOLE campaigns.

How Dead Drop Resolvers Are Expanding

The exact FTP-banner implementation is newly documented, but the broader DDR idea is not new.

Attackers have already used trusted online services to hide or update C2 information.

Drokbk used a GitHub repository and a README.md file to recover its active C2 domain. The operator could change the repository content without rebuilding the malware.

ACR Stealer has used services including Steam, Google Docs and Telegra.ph as resolver locations.

Kamasers uses several fallback DDR channels, including GitHub Gist, Telegram, Dropbox and Bitbucket. If one location fails, the malware tries another.

The Operation Muck and Load campaign showed how a malicious development package can launch PowerShell, retrieve resolver material from public services and continue toward RAT and infostealer payloads.

Recent malware has also used public blockchain infrastructure as a resolver. In these cases, the loader reads a smart contract or transaction field through a public blockchain RPC service and decodes the returned value into a C2 address or another stage.

These examples show that the important change is not only the service being abused. The stronger trend is the separation of malware execution from infrastructure discovery.

Possible Future Evolution

The following possibilities were not confirmed in the E4del or PINHOLE campaign. They are defensive scenarios that security teams should consider when designing future hunting rules.

Multi-Hop Resolver Chains

Instead of retrieving the final C2 from one location, malware could use several resolver stages:

Malware → Resolver A → Resolver B → Proxy → C2

Each stage would reveal only the next location, making the complete infrastructure harder to reconstruct.

Split-Information Resolvers

Several resolver locations could each provide only part of the final configuration.

One service might contain part of a hostname, another a decoding value and another a port or route selector.

No single location would expose the complete C2 information by itself.

Conditional or Time-Based Responses

An attacker-controlled resolver could return different content based on time, campaign token, source network or victim identifier.

A real victim could receive an active command while an automated scanner or later investigator receives a normal response.

Protocol-Response Resolvers

The FTP-banner campaign shows that the resolver does not need to be a web page or hosted file.

Any externally controlled protocol response that can carry a small amount of data may become relevant to future threat research.

DDR as a Malware Control Layer

A resolver may provide more than a C2 address.

It could influence:

• Payload location

• Backup infrastructure

• Malware version

• Campaign identifier

• Polling interval

• Activation or pause state

• Next resolver location

This changes the DDR from a simple address book into a lightweight control layer for the malware operation.

Detection and Hunting Opportunities

Security teams should monitor for:

• Compressed email attachments containing unexpected .lnk files

• Voucher, invoice or document-themed shortcut files

• Shortcut execution followed by an outbound TCP port 21 connection

• FTP traffic initiated by PowerShell, CMD, rundll32.exe or another unusual process

• FTP banners containing PowerShell commands, URLs or script syntax

• Unusually long, encoded or high-entropy FTP greeting text

• FTP protocol traffic on unexpected ports

• Very short FTP sessions that receive only the opening banner

• FTP sessions with no normal USER, PASS, LIST, RETR or STOR commands

• PowerShell or WebDAV activity immediately after a banner-only FTP session

• Discord.exe running from an unusual directory

• Discord.exe launched with an --init username argument

• Electron processes using headless, disable-gpu or mute-audio unexpectedly

• Recently modified or unapproved app.asar files

• Unexpected code under app_bootstrap/index.js

• Discord.exe making unfamiliar /beacon or WebSocket connections

• Creation of %TEMP%\u.cmd

• Creation of %TEMP%\calc, %TEMP%\calc_runner.cmd, %TEMP%\calc.cab or %TEMP%\calc.exe

• certutil -decode followed by expand.exe

• Temporary decoding files deleted within seconds of execution

• Randomly named executables created under %LOCALAPPDATA%\Packages

• Changes to HKCU\Software\Microsoft\Windows NT\CurrentVersion\Windows\Load

• Alternate Data Streams attached to desktop.ini

• Non-browser processes accessing Pinterest or SurveyMonkey

• Cloudflare Worker URLs containing another destination inside the request path

• Requests to unfamiliar /api/health, /api/client, /api/tsk, /api/fls or /api/stlbrwsr endpoints

• Suspended creation of ApplicationFrameHost.exe

• Remote-memory writes and APC activity involving ApplicationFrameHost.exe

• A process contacting a trusted service, decoding a small response and immediately connecting to a new destination

• Package-manager or build activity followed by hidden PowerShell and public-service resolver access

• Non-browser processes reading blockchain smart contracts and then connecting to a decoded destination

The following are useful patterns, but they are not exact fixed IoCs.

Do not put them in the IoC panel.

1. E4del WebSocket Pattern

ws://[IP:PORT]/ws/agent?hostId=[hostId]

Why it should not be in the IoC panel:

• [IP:PORT] changes.
• [hostId] changes.
• It is a detection pattern, not one exact URL.

Keep it in the article under:

### Detection and Hunting Opportunities

Suggested sentence:

- WebSocket connections matching the pattern `ws://[IP:PORT]/ws/agent?hostId=[hostId]`, especially when initiated by an unusual Discord or Electron process.

2. E4del Download URL Pattern

hxxps[://]157[.]254[.]194[.]31:21/api/download?token=[token]&clientId=[hwid]

Why it should not be in the IoC panel:

• [token] is variable.
• [hwid] is different for each victim.

Keep it under Detection and Hunting.

Suggested sentence:

- Requests to the E4del `/api/download` route containing `token` and `clientId` parameters.

3. PINHOLE File-Download Template

hxxps[://]worker-1785198984-xsekhi[.]api-62c3cac6[.]workers[.]dev/hxxps[://]nokierojotiarmx[.]com/api/fls?type=1&file_id=%lld&key=%s

Why it should not be in the IoC panel:

• %lld is a changing file identifier.
• %s is a changing key.
• It is a template used by the malware.

Keep it under Detection and Hunting.

Suggested sentence:

- PINHOLE requests to `/api/fls` containing `type=1`, `file_id`, and `key` parameters.

4. API Paths Without a Domain

Do not create separate URL IoCs for:

/api/health
/api/bc
/api/client
/api/tsk
/api/fls
/api/stlbrwsr

They are incomplete paths.

Keep them in the technical analysis and detection section. The complete versions with the Worker and C2 domain are already included in the IoC panel.

A strong FTP-specific correlation is:

LNK Execution → Rare External FTP Destination → Banner-Only Session → PowerShell or rundll32 → New Payload File

A strong general DDR correlation is:

Unusual Process → Trusted Service Request → Small or Encoded Response → Local Decoding → New External Destination 

Host-Based Hunting Artifacts

C:\Users\<Username>\AppData\Local\Packages\<Token_String>
C:\Users\<Username>\AppData\Local\discord\resources\crypto32.node
%TEMP%\u.cmd
%TEMP%\calc
%TEMP%\calc_runner.cmd
%TEMP%\calc.cab
%TEMP%\calc.exe
%TEMP%\{key}dl_{file_id}
C:\Users\{Username}\AppData\Local\Packages\{random_name}\{random_name}.exe
%USERPROFILE%\Downloads\desktop.ini:bt
%USERPROFILE%\Downloads\desktop.ini:ek
%USERPROFILE%\Downloads\desktop.ini:1
%USERPROFILE%\Downloads\desktop.ini:2
%USERPROFILE%\Downloads\desktop.ini:3
%USERPROFILE%\Documents\desktop.ini:ili
HKCU\Software\Microsoft\Windows NT\CurrentVersion\Windows\Load

Indicator Handling Notes

• Do not block all Pinterest, SurveyMonkey, Cloudflare, Ethereum, Polygon, Solana, TON, or public RPC traffic solely because the services appear in this report.
• Use the exact URL, process, wallet, contract, package version, timing, and follow-on connection.
• The GlassWorm sinkhole IP is benign and should be used for infection discovery.
• Blockchain addresses are investigation and enrichment artifacts, not ordinary network blocklist entries.
• Historical Glupteba domains are not added to the active IoC panel because they are old and unrelated to the current FTP-banner infrastructure.
• No MD5 indicators were published for the primary FTP-banner campaign.

Recommended Mitigations

1. Block direct outbound FTP from employee workstations unless there is a documented business requirement.

2. Route approved FTP activity through monitored gateways.

3. Maintain an allowlist of approved FTP clients, destinations and users.

4. Record and inspect the opening FTP response even when no file transfer occurs.

5. Alert on FTP sessions that close before normal authentication or transfer commands.

6. Monitor organization-owned FTP banners for unauthorized changes.

7. Block or quarantine unexpected .lnk files delivered through email.

8. Inspect compressed archives containing shortcut files.

9. Train users not to open unexpected voucher, invoice or document shortcuts.

10. Include ClickFix and fake-verification instructions in security-awareness training.

11. Enable PowerShell Script Block Logging, Module Logging and command-line collection.

12. Monitor certutil.exe, expand.exe, rundll32.exe, curl.exe, CMD and PowerShell when launched from unusual parent processes.

13. Use application control to prevent unauthorized executables and scripts from user-writable folders.

14. Monitor the integrity of Electron resources such as app.asar and application JavaScript.

15. Do not trust an Electron application only because its main executable is digitally signed.

16. Monitor current-user registry persistence locations.

17. Scan user-profile folders for NTFS Alternate Data Streams.

18. Detect suspended process creation followed by remote-memory writes and queued APC activity.

19. Use process-aware proxy, DNS and endpoint telemetry when trusted online services are accessed.

20. Avoid blocking an entire trusted platform because one account or URL was abused.

21. Correlate resolver access with decoding activity and follow-on connections.

22. Review newly introduced software packages and dependencies before use in development or CI/CD environments.

23. Isolate endpoints showing several stages of the described attack chain.

24. Preserve volatile memory before restarting a suspected PINHOLE-infected system.

25. Reset exposed Windows and browser credentials from a clean device.

26. Invalidate active browser, cloud, VPN and source-control sessions when credential theft is suspected.

27. Rebuild the endpoint when the full scope of remote attacker activity cannot be established.

Threat Assessment

This activity should be assessed as High severity.

A successful E4del infection can provide persistent command execution, reverse-shell access, screenshot capture, live desktop monitoring, additional payload delivery and attempted privilege escalation.

A successful PINHOLE infection can provide file discovery, file transfer, process control, screenshots, persistent PowerShell access and support for browser credential theft.

PINHOLE also combines multiple techniques intended to complicate analysis and endpoint detection, including sandbox checks, hidden configuration, direct-system-call logic, encrypted memory pages and process injection.

A Critical rating is not currently supported because public reporting does not establish zero-day exploitation, automatic worm-like spread, confirmed destructive behavior or large-scale critical-infrastructure impact.

Conclusion

The FTP-banner campaign demonstrates that even a normal protocol greeting can become part of a malware-delivery chain.

E4del hides malicious Electron logic behind a signed Discord executable, while PINHOLE combines PowerShell, built-in Windows tools, hidden NTFS streams, trusted-service C2 resolution, Cloudflare proxying, layered payload protection and process injection.

The wider lesson is that defenders should not rely only on the reputation of a domain, platform or signed executable.

A legitimate service becomes suspicious when an unusual process retrieves a small piece of external information, decodes it and immediately uses it to reach a new destination.

Security teams should therefore connect the full sequence of events: how the file arrived, which process opened it, what external response was received, what process started next, what persistence was created and where the endpoint communicated afterward.