Applied Cybernetics Group
T1071.002 — File Transfer Protocols
coverage gap
- Technique
T1071.002- Tactics
- Command and Control
- MISP citations
- 0
- KEV CVEs mapped
- 1
- Community rules
- 0
- thrunt rules
- 0
- Upstream
- https://attack.mitre.org/techniques/T1071/002
MITRE description
Adversaries may communicate using application layer protocols associated with transferring files to avoid detection/network filtering by blending in with existing traffic. Commands to the remote system, and often the results of those commands, will be embedded within the protocol traffic between the client and server. Protocols such as SMB(Citation: US-CERT TA18-074A), FTP(Citation: ESET Machete July 2019), FTPS, and TFTP that transfer files may be very common in environments. Packets produced from these protocols may have many fields and headers in which data can be concealed. Data could also be concealed within the transferred files. An adversary may abuse these protocols to communicate with systems under their control within a victim network while also mimicking normal, expected traffic.
KEV CVEs mapped to this technique
Per MITRE CTID's hand-curated KEV→ATT&CK mappings — these are the actively-exploited vulnerabilities behind this technique's KEV signal.
Detection coverage
FTP-as-C2 has no honest generic single-event signal over standard telemetry; KEV evidence is FTP-server exploitation (T1190 class), not a channel fingerprint; zeek ftp.log would enable an honest design but is a minority logsource
T1071.002's live signal in our corpus is CVE-2023-40044, a deserialization RCE in Progress WS_FTP Server with ransomware attribution. That is inbound exploitation of a file-transfer product, not a fingerprint of FTP used as a command-and-control channel — and the exploitation side is already the province of T1190-style rules (SigmaHQ covers the equivalent pattern for CrushFTP and vsftpd). For the technique itself — commands and results embedded in FTP, SMB, or TFTP traffic — base Sigma over standard telemetry offers no honest single-event assertion. Proxy logs rarely carry FTP at all; firewall and flow telemetry see port and byte counts but no protocol content; and zeek's ftp.log, where a STOR/RETR-to-unknown-external design would be defensible, is a minority logsource we cannot assume our consumers run. What remains is either a policy claim ('any outbound FTP from client subnets'), which fires on routine business transfers in precisely the estates that still operate FTP, or per-family C2 server IOC lists, which decay on infrastructure rotation. The process layer is already covered under other technique tags — WinSCP FTP session opens under T1048, ftp.exe scripting abuse under T1059/T1202. The honest control here is architectural: default-deny egress for FTP/TFTP ports and SMB 445 at the perimeter with deny-logging, which converts the channel into a high-signal blocked-connection event rather than an unwritable detection.
Compensating controls
- Perimeter egress default-deny for 20/21/tcp, 69/udp, and 445/tcp with firewall deny-logging — converts attempted FTP/SMB C2 into a blocked-connection signal.
- Proxy-enforced egress (explicit proxy, no direct outbound) removes raw FTP as a viable channel entirely.
- Process-layer SigmaHQ coverage under other tags catches common tooling: WinSCP FTP open (T1048), ftp.exe/renamed-ftp.exe abuse (T1059/T1202).
Revisit when: A corpus family lands with a concrete FTP-C2 fingerprint (command sequence, banner string, or filename pattern) supporting an emerging-threats-style rule; or thrunt adds zeek (service: ftp) to its supported logsource tiers, enabling an honest single-event STOR/RETR-to-external design.