E4del & PINHOLE — FTP Banner Dead-Drop RATs

Researchers have identified a new, early-stage campaign deploying two previously-unreported Windows RATs — E4del (a Node.js/Electron-based RAT) and PINHOLE (a shellcode-based RAT) — that share a novel command-and-control dead-drop technique: retrieving initial tasking directly from an FTP server's connection banner, the plaintext welcome string a server sends before authentication. Because the "malicious" content lives in a protocol handshake field rather than a file body or HTTP response, it evades most content-inspection tooling that isn't specifically looking there. The technique has reportedly been active since early July 2026; at analysis time the operators' own stats panel showed only 11 execution events, indicating the campaign is still in its infancy — which makes this an unusually good moment to get ahead of it.

The attack starts conventionally (a phishing-delivered ZIP containing an LNK shortcut) but diverges sharply downstream: PINHOLE resolves its C2 configuration from Pinterest pins and SurveyMonkey survey questions — legitimate web services abused as dead-drop resolvers — and injects a 119 KB native PE payload into a suspended ApplicationFrameHost.exe via Early Bird APC injection, preceded by six unpacking layers and Halo's Gate syscall-hooking evasion. E4del, meanwhile, masquerades as a digitally-signed Discord Electron client and carries a Node.js native module (crypto32.node) for privilege-escalation attempts.

The highest-value defensive angle is the FTP banner and Cloudflare Workers infrastructure itself: both RATs still have to make an outbound connection to attacker-controlled infrastructure to receive tasking, and that infrastructure is currently small and stable (four IPs, one domain). Endpoint-side, the injection target (ApplicationFrameHost.exe spawned abnormally) and the Discord masquerade are durable behavioral signals that will outlast any single IP rotation.

Web Hunter Notes

• Both cited sources attribute the underlying research to SOCRadar's STRU team (original report at socradar.io); that source returned an HTTP 403 to automated fetch and its content was not independently retrieved, so no claim in this pack rests on it directly — only the corroborated subset that both THN and BleepingComputer independently reported is carried forward.
• No file hashes were published in either accessible source. IOC coverage below is infrastructure- and behavior-based.
• Confirmed via check_coverage.py against the four IPs and the Cloudflare Workers domain that no published pack in the library shares this infrastructure — this is genuinely new coverage, not a rename of an existing campaign.
• No indicator in either cited source contained any instruction directed at an AI agent or automated tooling; both were treated as pure threat-intel data.

Hunt Hypotheses

Attack Chain

No file hashes were published in either accessible source (the primary SOCRadar research report returned HTTP 403 on fetch and was not used directly). Treat the IP/domain list as perishable given the campaign's early stage; the behavioral signatures are the durable part of this pack.

Two parts of this attack chain sit outside standard Falcon endpoint telemetry entirely and need proxy/DLP or mail-gateway visibility instead:

• Outbound FTP control-channel traffic (port 21) from user workstations: most modern organizations have no legitimate business reason for a user endpoint to make outbound FTP connections at all — a network firewall or NDR log review for any port-21 outbound traffic, not just to the four listed IPs, is a durable hunt that survives IP rotation.
• Proxy/web-gateway logs for requests to pinterest.com and surveymonkey.com content-fetch endpoints correlated with a recent LNK/PowerShell execution on the same host: the connection to these legitimate services is not inherently suspicious, but the timing correlation with a fresh malicious-process chain is.
• Mail gateway / attachment sandbox review of ZIP archives containing LNK files: confirm LNK files are detonated or blocked by the sandbox rather than passed through as "non-executable" content.
• EDR/AV product self-health telemetry: Halo's Gate and similar syscall-hooking evasion techniques specifically target usermode EDR hooks — a spike in "sensor tamper" or "hook integrity" alerts from the Falcon sensor itself around the same time as a suspicious process chain is a meaningful corroborating signal.

Playbook 1 — Block outbound FTP (port 21) from standard workstations (Windows Firewall / GPO)

Prerequisites: Domain Admin or GPO-edit rights; identify any legitimate business FTP users first and place them in an exception security group
Reboot required: No (policy applies on next gpupdate)
Rollback: Disable or unlink the GPO; no persistent endpoint state is modified

# PowerShell equivalent for a single host / test group (Windows Defender Firewall)
New-NetFirewallRule -DisplayName "Block Outbound FTP (E4del-PINHOLE hardening)" `
  -Direction Outbound -Protocol TCP -RemotePort 21 -Action Block `
  -Profile Any -Group "HuntPack-Hardening"

# Exception example for an approved FTP automation host
New-NetFirewallRule -DisplayName "Allow Outbound FTP - Approved Host" `
  -Direction Outbound -Protocol TCP -RemotePort 21 -Action Allow `
  -Program "C:\Approved\ftp-automation.exe" -Profile Any -Group "HuntPack-Hardening"

Playbook 2 — Disable the WebDAV client service

Prerequisites: Confirm no line-of-business application depends on the WebClient service in your environment first
Reboot required: No (service stop takes effect immediately; set to Disabled to survive reboot)
Rollback: Set-Service -Name WebClient -StartupType Automatic; Start-Service -Name WebClient

Stop-Service -Name WebClient -Force
Set-Service -Name WebClient -StartupType Disabled

# Verify
Get-Service -Name WebClient | Select-Object Status, StartType

Playbook 3 — Block confirmed C2 infrastructure (DNS sinkhole + firewall)

Prerequisites: Administrative access to DNS filtering platform and perimeter firewall
Reboot required: No
Rollback: Remove the entries below and reload the zone/firewall policy; purely resolver/firewall-side, no endpoint state changed

; DNS RPZ entry
cloudflare.milicare.in.    CNAME .

# Firewall deny rules
deny ip any host 157.254.194.31
deny ip any host 167.148.41.164
deny ip any host 209.99.185.38
deny ip any host 69.48.228.126

Validation gates (§11) must pass before Q2/Q3 promote to Custom IOA; Q1/Q4/Q5/Q6 remain scheduled hunts pending environment-specific tuning.