FTP banner dead drop: analyzing E4del and PINHOLE RAT

FTP banner dead drop: analyzing E4del and PINHOLE RAT

An FTP banner dead drop is a command-and-control technique in which malware reads the welcome message returned by an FTP server and interprets it as operational content, instead of using the server only to transfer files. The banner, normally displayed right after connecting to port 21, becomes a receiving channel for commands, configuration or indicators that the implant checks periodically.

The technique associated with malware such as E4del and PINHOLE RAT is interesting because it abuses an element the FTP protocol already provides for, and can easily blend in with administrative or file-transfer traffic. It doesn't necessarily need a dedicated web panel or an HTTP response with an obvious format. For an analyst, the key is to look at the relationship between FTP connections, banner content, request frequency and endpoint behavior.

How the mechanism works

When a client opens an FTP session, the server normally sends a response like this:

220 ftp.example.net FTP server ready

The code 220 indicates the service is ready to accept a new connection. In a legitimate configuration, the text that follows contains descriptive information, such as the product name or an administrative message.

An implant, instead, can:

1. open a connection to an FTP server;
2. read the initial response;
3. extract the banner text;
4. check for a prefix, a delimiter or a signature;
5. interpret the content as a command or configuration;
6. send any result back through a second connection or a separate mechanism.

In this scheme the FTP server plays the role of the dead drop: it publishes content the malware can read, while whoever runs the infrastructure changes the banner to push new data to compromised endpoints.

The channel can be implemented in different forms. The command can be embedded directly in the banner text, encoded in Base64, or preceded by a string that lets the malware tell a malicious banner apart from an ordinary response. It isn't correct, though, to assume that every unusual piece of text automatically represents a command: confirmation requires correlating it with the process that opened the session and with what happens afterward.

E4del and PINHOLE RAT

In public analyses of E4del and PINHOLE RAT, the use of FTP as communication infrastructure shows an important detail: the content useful to the malware can live in the server's response, not in a file downloaded with RETR.

This changes the detection strategy. A check based only on:

• suspicious file uploads;
• executable downloads;
• known file names;
• FTP commands such as STOR and RETR;

can miss a session where the implant only reads the initial banner.

The elements to correlate instead are:

Element	Useful observation
Connection	external destination, port 21 or an alternative FTP port
Banner	text inconsistent with the declared service, encoded strings or recurring delimiters
Frequency	short, periodic connections, often at regular intervals
Endpoint	a process that wouldn't normally need to use FTP
Sequence	FTP connection followed by execution, configuration changes or credential access
Response	subsequent use of DNS, HTTP or HTTPS channels to exfiltrate results

The presence of a banner alone doesn't prove compromise. A legacy appliance or a lab service can use custom messages. The indicator's value grows when the text is stable, encoded, and tied to an unauthorized client.

Indicators of compromise

Indicators can be grouped into three categories.

Network indicators

In firewall logs and NetFlow data, look for:

• outbound connections to public FTP servers not present in the inventory;
• sessions from the server network or from workstations with no operational need for FTP;
• short-duration connections at regular intervals;
• destinations resolved through recently created domains;
• unencrypted FTP traffic heading to the internet.

The banner should be preserved in session logs whenever the sensor or proxy supports it. A plain log with just IP address and port isn't enough to analyze the application layer.

Endpoint indicators

A non-interactive FTP client can be legitimate, but it needs to be tied back to the responsible process. Relevant signals include:

• unknown processes opening sockets to port 21;
• binaries running from temporary directories or user profiles;
• scheduled tasks that launch a program with network access;
• new persistence keys and unexpected services;
• a process making an FTP connection without going through an approved corporate client.

On Linux, active connections can be observed with:

ss -tpn | grep ':21'

For a focused investigation, it's also worth capturing the binary's path and the process tree with EDR tooling or with:

ps -eo pid,ppid,user,cmd --forest

Content indicators

The banner may contain:

• Base64 or hex strings with no operational justification;
• long sequences with no spaces;
• repeated delimiters;
• command names that don't map to the FTP product itself;
• values that change in sync across multiple endpoints.

Encoding is not the same as encryption. Base64 content can be decoded to check whether it contains commands, identifiers or configuration. That analysis should be done on a copy of the PCAP or the log, without sending the content to external services.

Analyzing a PCAP with Wireshark

In an incident response context, the first Wireshark filter can narrow the view down to FTP sessions:

ftp || tcp.port == 21

To find the server's initial response, look for FTP packets with code 220. A useful filter is:

ftp.response.code == 220

If the dissector doesn't correctly identify the traffic, you can follow the TCP conversation with Follow > TCP Stream. The banner will generally appear at the start of the flow, before the authentication sequence.

To quickly extract endpoints and FTP responses with tshark:

tshark -r suspicious.pcapng \
  -Y 'ftp.response.code == 220' \
  -T fields \
  -e frame.time \
  -e ip.src \
  -e ip.dst \
  -e tcp.dstport \
  -e ftp.response.arg

The available field can vary depending on the Wireshark version and the traffic type. It's worth cross-checking the output against the packet's detailed view.

During analysis it's worth checking:

• whether the same banner is returned to multiple internal addresses;
• whether the text changes between successive connections;
• whether the response contains non-printable or encoded characters;
• whether, right after the 220, the client immediately sends QUIT, USER, or some other unusual sequence;
• whether the endpoint opens other connections after reading the banner.

A PCAP contains potentially sensitive data. It should be stored with access controls, integrity hashes and a chain of custody consistent with internal procedures.

Detection with Suricata

A Suricata rule can flag a specific string in the banner once you have a confirmed indicator:

alert tcp $EXTERNAL_NET 21 -> $HOME_NET any (
    msg:"FTP banner associated with a possible dead drop";
    flow:to_client,established;
    content:"220 ";
    content:"E4D";
    distance:0;
    within:80;
    classtype:trojan-activity;
    sid:4200101;
    rev:1;
)

The signature is just an example. A value like E4D can generate false positives if it appears in legitimate banners. In production, it's better to replace it with a string actually observed in the environment under analysis, add the destination IP or domain only if it's stable, and document the reasoning behind the choice.

Detecting an encoded format takes more than searching for a single word. A more generic rule can flag unusually long banners, but it needs to be tuned against real traffic:

alert tcp $EXTERNAL_NET 21 -> $HOME_NET any (
    msg:"FTP banner with possibly encoded content";
    flow:to_client,established;
    content:"220 ";
    pcre:"/^220\s+[A-Za-z0-9+\/]{40,}={0,2}\r?\n/m";
    classtype:trojan-activity;
    sid:4200102;
    rev:1;
)

This detection doesn't reliably identify Base64 and shouldn't be used as the sole blocking criterion. It's better suited to generating events to correlate with asset, process and destination.

Countermeasures for FTP servers

The first measure is to remove FTP wherever it isn't necessary. For administrative transfers, SFTP over SSH or HTTPS with strong authentication offer better control and visibility. If FTP has to stay active, the banner shouldn't contain operational information, credentials, tokens or dynamic data.

A minimal banner reduces the content available to a potential dead drop:

220 File transfer service ready

The text alone isn't a sufficient defense, because malware can interpret any response. Complementary measures are needed:

• allow connections only from authorized addresses or networks;
• block outbound FTP access from clients that don't need it;
• use FTPS where the product and architecture support it;
• disable anonymous accounts;
• enforce unique passwords and strong authentication where available;
• restrict permissions on FTP directories;
• log banners, authentications, commands and client addresses;
• keep the FTP daemon updated and remove unused components;
• monitor changes to the service configuration;
• separate the FTP server from the internal network with firewalls and VLANs.

Egress control is particularly useful: a compromised endpoint shouldn't be able to freely reach internet FTP servers. Exceptions should be explicit, with documented destinations and time windows.

Operational checklist for administrators

Before considering the review complete, verify:

• the FTP service is inventoried and has an owner;
• there's a documented justification for keeping it;
• the banner doesn't expose sensitive or variable data;
• anonymous access is disabled;
• outbound connections to port 21 are filtered;
• logs include client, destination, authentication and commands;
• Suricata or an equivalent sensor inspects 220 responses;
• alerts are correlated with EDR telemetry;
• FTP credentials are rotated after a suspected incident;
• the server is updated and isolated from unnecessary assets;
• a procedure exists for capturing and analyzing a PCAP;
• suspicious domains and IPs are present in internal threat intelligence systems.

Controlled testing

To validate detection, you can use a lab FTP server configured with a clearly identifiable banner, without embedding any real commands or payloads:

220 LAB-DETECTION-TEST-001

From a test host, open an authorized connection and capture the traffic with Wireshark or tcpdump. The goal is to verify that:

1. the sensor recognizes the 220 code;
2. the banner content gets logged;
3. the Suricata rule generates an alert;
4. the event contains the correct asset and destination;
5. the alert doesn't block unrelated, legitimate FTP traffic.

It's worth repeating the test with normal banners, long strings and encoded data to measure false positives. The test should stay confined to controlled systems and doesn't require running E4del, PINHOLE RAT or any other malware.

Resources

• Wireshark User's Guide
• Suricata documentation
• RFC 959: File Transfer Protocol
• RFC 4217: Securing FTP with TLS
• MITRE ATT&CK: Application layer protocol
• MITRE ATT&CK: Dead drop resolver
• CISA: incident response resources

The FTP banner, then, is an application-layer detail with a possible role in C2. The most effective detection comes from combining response content, connection periodicity, process identity and egress policy. Reducing the FTP attack surface and keeping telemetry on server responses makes it harder to use the service as a dead drop without introducing invasive controls on legitimate traffic.