Threat actors have found a new place to hide their command-and-control addresses: inside the welcome banners of public FTP servers. A newly reported campaign uses FTP banners as dead drop resolvers (DDRs) to deliver two previously unreported remote access trojans, tracked as E4del and PINHOLE. Because the resolver stage rides on a legitimate, decades-old protocol that many organizations barely monitor, this campaign can slip past proxy categories, URL filters, and even some TLS-inspection stacks that focus on HTTP/S while ignoring control-channel text on port 21. Defenders need to treat outbound FTP control-channel traffic as a first-class detection surface — now.

What Happened

Researchers disclosed a campaign in which the malware's first stage does not hardcode its C2 address or fetch it from a paste site or social media profile — the classic DDR pattern. Instead, the implants connect to attacker-controlled FTP servers and parse the FTP banner (the greeting string the server sends on connection) to extract the address of the real C2 infrastructure. The banner is, from the network's perspective, just a line of text in a legitimate protocol exchange. From the malware's perspective, it is a dynamically updatable pointer that the operator can rotate at will without recompiling or redistributing the implant.

This is a meaningful evolution of DDR tradecraft. Past campaigns abused GitHub gists, YouTube descriptions, and DNS TXT records; those services are now commonly watched. FTP banners sit in a monitoring blind spot: many SOCs log connection metadata (5-tuple, bytes) but never capture or alert on banner content, and most environments have no business reason for endpoints to initiate outbound FTP at all.

Why Defenders Need to Act

The risk is twofold. First, E4del and PINHOLE are functional RATs — once the real C2 address is resolved, operators gain remote access capabilities consistent with post-exploitation, lateral movement staging, and data theft. Second, the delivery mechanism is deliberately engineered to blend in. If your egress policy permits outbound TCP/21, you have a clean, unmonitored channel for resolver traffic. If your network detection is built entirely around HTTP/S beaconing analytics, you will not see this stage at all.

Exploitation status: This is an active, in-the-wild campaign with working implants — not a proof of concept. No CVE is associated with this activity; it is technique abuse, not vulnerability exploitation, which means no patch will fix it. Defense is entirely behavioral and architectural.

Technical Analysis

Attack Chain (Defender's View)

1. Initial infection: The E4del or PINHOLE implant lands on the endpoint through the campaign's delivery vector (typical for RAT distribution: phishing attachments, trojanized installers, or loader chains). The implant binary itself contains no C2 address — only the address of an FTP server acting as the resolver.
2. Dead drop resolution: The implant opens a control connection to the FTP server on TCP/21. The server's banner — normally something like 220 Welcome to ftp.example.com — instead carries an encoded or obfuscated payload pointing to the true C2 host and port. The implant parses this string, extracts the address, and may never log in at all.
3. C2 establishment: The implant beacons to the resolved C2, which the operator can rotate freely by editing the FTP banner text. Blocking a single IP or domain is ineffective because the resolver layer decouples the implant from the infrastructure.
4. Post-exploitation: Standard RAT capability — command execution, file staging, and likely credential theft and lateral movement staging.

Why This Evades Common Controls

• Proxy and URL filtering: Most secure web gateways inspect HTTP/S. Plain FTP control traffic on TCP/21 frequently bypasses these stacks entirely or is passed through uninspected.
• Reputation-based blocking: Resolver FTP servers can sit on commodity hosting with clean reputations; the banner text is not a scannable URL.
• EDR content inspection: Endpoint tools see a socket connection and a short string read — behaviorally indistinguishable from benign activity unless you are alerting on the process-to-protocol relationship.
• IOC-driven blocking: Rotating C2 addresses behind a stable resolver defeats IP/domain blocklists at the C2 layer. The resolver IPs are the more durable indicator.

Key Defensive Insight

The single strongest chokepoint is this: workstations and servers in most environments have no legitimate reason to initiate outbound FTP. Blocking egress TCP/21 (and explicit FTPS on TCP/990) from endpoint VLANs, with an allowlist for the handful of business processes that genuinely need it, collapses this campaign's resolver stage. Everything in the detection section below is a complement to — not a substitute for — that egress control.

Detection & Response

Sigma Rules

---
title: Outbound FTP Connection from Non-FTP Process
tid: 8b2c4d16-3a91-4e57-bf28-6c9d1e5a7f30
status: experimental
description: Detects processes outside of a known FTP client allowlist initiating outbound connections to TCP/21. E4del and PINHOLE implants connect to FTP servers to parse banners for C2 resolution; endpoints rarely have legitimate FTP client activity.
references:
  - https://thehackernews.com/2026/08/e4del-and-pinhole-rats-turn-ftp-banners.html
  - https://attack.mitre.org/techniques/T1071/
  - https://attack.mitre.org/techniques/T1102/
author: Security Arsenal
date: 2026/08/15
tags:
  - attack.command_and_control
  - attack.t1071
  - attack.t1102
logsource:
  category: network_connection
  product: windows
detection:
  selection:
    DestinationPort: 21
    Initiated: 'true'
  filter_known_clients:
    Image|endswith:
      - '\FileZilla.exe'
      - '\WinSCP.exe'
      - '\ftp.exe'
      - '\psftp.exe'
      - '\CoreFTP.exe'
  condition: selection and not filter_known_clients
falsepositives:
  - Legacy business processes using scripted FTP transfers (allowlist these explicitly)
  - Backup or EDI applications with embedded FTP clients
level: high
---
title: FTP Transfer via Windows Built-in ftp.exe by Script Interpreter
tid: 3f7a9c52-1d84-4b62-ae19-8c4b2d6e9f51
status: experimental
description: Detects script interpreters (cmd, powershell, wscript, cscript, mshta, rundll32) spawning the built-in Windows ftp.exe client. RATs and loaders frequently leverage living-off-the-land FTP for resolver or staging traffic rather than implementing raw sockets.
references:
  - https://thehackernews.com/2026/08/e4del-and-pinhole-rats-turn-ftp-banners.html
  - https://attack.mitre.org/techniques/T1105/
  - https://attack.mitre.org/techniques/T1218/
author: Security Arsenal
date: 2026/08/15
tags:
  - attack.command_and_control
  - attack.t1105
  - attack.t1218
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    Image|endswith: '\ftp.exe'
    ParentImage|endswith:
      - '\cmd.exe'
      - '\powershell.exe'
      - '\powershell_ise.exe'
      - '\pwsh.exe'
      - '\wscript.exe'
      - '\cscript.exe'
      - '\mshta.exe'
      - '\rundll32.exe'
      - '\wmic.exe'
      - '\explorer.exe'
  condition: selection
falsepositives:
  - Legacy administrative scripts performing FTP batch transfers
level: medium

A note on tuning: the first rule is the workhorse. In a mature environment, the allowlist of legitimate FTP clients should be short and stable. If it fires broadly, that is itself a finding — it means you have unmanaged FTP usage to inventory. The second rule catches loader-style tradecraft but will not catch implants that implement FTP natively in their own process; that is what the first rule is for.

KQL — Microsoft Sentinel / Defender

Hunt for outbound FTP control-channel connections from endpoints, excluding sanctioned clients. This works against Defender for Endpoint (DeviceNetworkEvents) and against firewall/Syslog-ingested data (CommonSecurityLog) for coverage of Linux hosts and network appliances.

// Hunt: outbound FTP (TCP/21) connections from endpoints, grouped by process and destination
// Excludes a sanctioned-client allowlist — tune AllowedFtpClients to your environment
let AllowedFtpClients = dynamic(["filezilla.exe", "winscp.exe", "ftp.exe", "psftp.exe", "coreftp.exe"]);
let AllowedFtpServers = dynamic(["10.20.0.15"]); // sanctioned internal FTP destinations
DeviceNetworkEvents
| where TimeGenerated > ago(7d)
| where RemotePort == 21 and ActionType == "ConnectionSuccess"
| where not(tolower(InitiatingProcessFileName) in~ (AllowedFtpClients))
| where not(RemoteIP in~ (AllowedFtpServers))
| summarize ConnectionCount = count(),
            DistinctDevices = dcount(DeviceName),
            Devices = make_set(DeviceName, 20),
            FirstSeen = min(TimeGenerated),
            LastSeen = max(TimeGenerated)
    by InitiatingProcessFileName, InitiatingProcessCommandLine, RemoteIP, RemoteUrl
| order by DistinctDevices desc
// Complement: hunt the same pattern in firewall logs (CEF/Syslog ingestion) for non-Defender hosts
// CommonSecurityLog
// | where TimeGenerated > ago(7d)
// | where DestinationPort == 21 and DeviceAction in~ ("allow", "allowed", "permit")
// | summarize count() by SourceIP, DestinationIP, ApplicationProtocol, DeviceVendor
// | order by count_ desc

Analyst workflow: investigate any InitiatingProcessFileName that is not a known business application. A single endpoint making repeated short-lived TCP/21 connections — especially to IPs with no reverse DNS or recent registration — is the resolver-stage signature. Pivot from the resolver IP to subsequent outbound connections from the same process to identify the resolved C2.

Velociraptor VQL

Hunt for processes holding live connections to TCP/21 endpoints across your fleet. Velociraptor's netstat() gives you the process-to-connection mapping that network telemetry often lacks.

-- Hunt for processes with active or recently closed connections to remote TCP/21 (FTP control channel)
-- E4del/PINHOLE-style DDR resolver connections appear here as non-FTP-client processes on port 21
LET allowed_clients = ("filezilla.exe", "winscp.exe", "ftp.exe", "psftp.exe", "coreftp.exe")

SELECT Pid,
       Name,
       Exe,
       Username,
       netstat().LocalAddr.IP AS LocalIP,
       netstat().RemoteAddr.IP AS RemoteIP,
       netstat().RemoteAddr.Port AS RemotePort,
       netstat().Status AS ConnStatus
FROM pslist()
WHERE netstat().RemoteAddr.Port = 21
  AND NOT lowcase(string=Name) in allowed_clients
  AND NOT netstat().RemoteAddr.IP =~ "^(10\\.|192\\.168\\.|172\\.(1[6-9]|2[0-9]|3[01])\\.)"

For hosts flagged by this hunt, follow up with a second collection: pull the process executable (upload the Exe path), enumerate its persistence mechanisms (run keys, scheduled tasks, services), and review its network history via the Windows Event Log or SRUM where available. A resolver-stage implant must persist to survive reboots — persistence enumeration is usually where you confirm the intrusion.

Remediation / Hardening Script

Use PowerShell to audit current outbound FTP usage and then enforce an egress block at the host firewall as a compensating control while network egress policy is updated centrally.

# E4del/PINHOLE DDR mitigation: audit then block outbound FTP from endpoints
# Run as Administrator. Test in audit mode before enforcing.

# --- STEP 1: Audit — list established outbound TCP/21 connections and owning processes

```powershell
Get-NetTCPConnection -State Established -RemotePort 21 -ErrorAction SilentlyContinue |

ForEach-Object {
    $proc = Get-Process -Id $_.OwningProcess -ErrorAction SilentlyContinue
    [PSCustomObject]@{
        RemoteIP   = $_.RemoteAddress
        Process    = $proc.ProcessName
        Path       = $proc.Path
        PID        = $_.OwningProcess
    }
} | Format-Table -AutoSize

--- STEP 2: Enforce — block outbound TCP/21 and TCP/990 (FTP + implicit FTPS) for all profiles

Create exclusion rules FIRST for any sanctioned FTP clients/destinations identified in Step 1.

Example exclusion for a sanctioned destination (adjust IP as needed):

New-NetFirewallRule -DisplayName "Allow Outbound FTP - Sanctioned EDI Server" `

-Direction Outbound -Protocol TCP -RemotePort 21 -RemoteAddress "203.0.113.10