Managed File Transfer (MFT) Security Guide

A managed file transfer platform sits on the internet, holds the most sensitive files an organisation exchanges with partners, and has repeatedly been the single flaw that let one extortion group steal data from hundreds of organisations at once. Managed file transfer security (MFT security) is therefore not a file-sharing question but an internet-facing application, credential and monitoring problem. This guide covers how MFT platforms are built and attacked, the protocols they use (SFTP, FTPS, AS2 and HTTPS web portals), hardening the MFT gateway and SFTP service, partner and service account access, monitoring for exfiltration, and how to respond when an MFT vulnerability is exploited. It is for infrastructure and security engineers who run file transfer software, and for the teams that own partner integrations.

Key takeaways

Treat the MFT platform as an exposed, high-value application. Joint advisories on the 2021 and 2023 mass exploitation campaigns describe SQL injection and web shells in the file transfer web portal, not weak encryption.
Shrink what the internet can reach. Only the protocol listeners partners need, through a gateway in a DMZ, with the admin console and database never exposed.
Retire legacy file transfer protocols. Plain FTP sends credentials and files in clear text; use SFTP, FTPS with protected data channels, AS2 with signed receipts, or HTTPS APIs.
Partner access is non-human access. SSH keys, certificates, API keys and service accounts need owners, restrictions, rotation and a regular SFTP access review.
Log transfers well enough to answer "what left?". When an MFT vulnerability is exploited, transfer logs decide whether you notify ten partners or ten thousand people.

What an MFT platform is and why it is targeted

Managed file transfer (MFT) is file transfer software that adds central control to moving files between systems and organisations: protocol servers, user and partner management, scheduled and event-driven workflows, encryption, audit logs and delivery guarantees. A managed file transfer platform typically includes:

Component	What it does	Exposure	Primary control
Managed file transfer gateway (MFT gateway)	Terminates partner connections and relays them inward, so no inbound connection reaches the internal network	Internet	Gateway only in the DMZ; outbound-initiated link from internal server
Protocol servers	SFTP service, FTPS, AS2, HTTPS endpoints	Internet via gateway	Only required protocols enabled; strong authentication
File transfer web portal (MFT browser client)	Lets people upload and download through a browser	Internet	Patch fastest; WAF; MFA; minimal features
Workflow engine and agents	Pick up, transform and deliver files internally	Internal	Least-privilege service accounts; no shared credentials
Database and storage	Users, keys, transfer metadata, files at rest	Internal or cloud	Never internet-reachable; encrypted; separate credentials
Admin console and APIs	Configuration, user creation, key management	Should be internal only	Privileged access workstation, MFA, allowlisted networks

MFT platforms concentrate three things attackers want: a reachable web application, a queue of sensitive files ready for collection, and partner credentials. Exploitation is cheap to scale: one vulnerability in widely deployed file transfer software reaches every internet-facing instance. That is why these platforms appear in CISA's Known Exploited Vulnerabilities catalogue and in joint advisories, and why an MFT vulnerability should be handled as an emergency. See the Zero-Day and Exploited Vulnerabilities Guide.

Lessons from MFT exploitation campaigns

Two joint advisories describe the pattern in detail. Both are worth reading in full by anyone who runs a file transfer application.

2021, file transfer appliance (CISA AA21-055A): authorities in Australia, New Zealand, Singapore, the UK and the US described exploitation of a legacy Accellion File Transfer Appliance through four CVEs: CVE-2021-27101 (SQL injection via a crafted Host header), CVE-2021-27102 and CVE-2021-27104 (operating system command execution) and CVE-2021-27103 (server-side request forgery). A web shell let the attacker "send commands to targeted devices, exfiltrate data, and clean up logs"; the clean-up modified archived web server access logs. Some victims were then extorted. The product was due to reach end of life on 30 April 2021.
2023, MOVEit Transfer (CISA AA23-158A): the FBI and CISA reported that the CL0P ransomware gang exploited CVE-2023-34362, "a previously unknown SQL injection vulnerability" in the MOVEit Transfer web application, from 27 May 2023 according to open source information. A web shell named LEMURLOOT, initially called human2.aspx to resemble the legitimate human.aspx, stole data from the application database, retrieved Azure Blob Storage account, key and container settings, and created administrator accounts with the RealName "Health Check Service". The advisory's indicators also cover an earlier 2023 campaign against another MFT product.

Stage	What happened	ATT&CK v20	Control that changes the outcome
Initial access	Injection or command execution in the web tier	T1190 Exploit Public-Facing Application	Reduce exposure, patch within hours, WAF virtual patching while waiting
Persistence	Web shell dropped in the web root with a near-legitimate name	T1505.003 Web Shell	File integrity monitoring of web directories, application allowlisting
Privilege and access	Rogue administrator accounts; cloud storage keys read from settings	Account creation and credential access	Alert on new admin accounts; keep storage keys out of application settings or rotate them on compromise
Collection and exfiltration	Files and database contents pulled out in bulk	T1048 Exfiltration Over Alternative Protocol, or over the portal itself	Volume baselines per account, egress limits, short file retention
Defence impairment	Access logs edited to hide activity	Log tampering	Forward logs off the host in real time

The common thread is that files stayed on the platform long after delivery. A short retention period on the MFT platform limits what any future exploit can take.

File transfer protocols compared

File transfer security starts with the protocol: "secure file transfer" covers several protocols with different security properties. Choose by what the partner can support, then harden that choice.

Protocol	Default port	Security properties	Watch for
FTP (File Transfer Protocol)	21 control, separate data connections	None: credentials and files in clear text	Legacy partners and devices; retire or confine to isolated networks
FTPS (File Transfer Protocol Secure, RFC 4217)	21 explicit (AUTH TLS); implicit FTPS conventionally 990	TLS on control and, with PROT P, data connections	Data channel left in clear (PROT C is the initial state); CCC returning control to plaintext; firewall complexity
SFTP (SSH File Transfer Protocol)	22	Runs as the "sftp" subsystem inside SSH, which provides server authentication, encryption and integrity	Unverified host keys, unrestricted keys, shell and forwarding left enabled
SCP	22	SSH-protected copy without SFTP's file operations	Same SSH key risks; fewer server-side controls than SFTP
AS2 (RFC 4130)	HTTP or HTTPS ports	S/MIME signing and encryption, signed receipts (MDNs) for non-repudiation	Unsigned MDNs, weak algorithms agreed years ago, expired partner certificates
HTTPS web portal or API	443	TLS plus application authentication	The web application is the attack surface: patching and MFA dominate

SFTP is not FTP over SSH: the SSH file transfer protocol is a separate protocol. Version 3, the version OpenSSH implements, is defined only in an expired Internet-Draft, which states that "It is the responsibility of the server implementation to enforce any access controls". The protocol itself gives you none.
FTPS needs both channels protected: RFC 4217 defines only two protection levels, Clear (PROT C) and Private (PROT P), and the data connection starts as Clear. Require PROT P, refuse CCC, and allow only TLS 1.2 or later (RFC 8996 deprecated TLS 1.0 and 1.1 and updates RFC 4217).
AS2 file transfer depends on certificates: RFC 4130 requires X.509 certificates, allows self-signed ones exchanged when the trading relationship is set up, and warns that unsigned receipts weaken non-repudiation. The RFC dates from 2005 and recommends SHA-1; agree stronger algorithms with partners where both products support them. See the Machine Identity, PKI and Certificate Lifecycle Guide.
Cloud based file transfer: SaaS MFT and cloud storage transfer services move patching to the provider, but partner accounts, API keys, sharing links, retention and logging remain yours. Confirm log export and data residency before migrating sensitive file transfer flows.

Hardening the MFT platform and gateway

Reduce exposure: publish only the protocol listeners partners use, through the MFT gateway. Keep the admin console, APIs and database off the internet. CISA's MOVEit advisory lists "Disable unused ports" and network segmentation among its mitigations.
Restrict by source where you can: most B2B partners connect from fixed addresses. Allowlist them per account; reserve open access for the web portal, which then needs MFA.
Patch on an emergency track: subscribe to the vendor's security advisories and CISA KEV, and pre-agree a maintenance window that can be invoked the same day. Keep the platform on a supported version; AA21-055A concerned a product approaching end of life.
Virtual patch while waiting: a web application firewall in front of the file transfer web portal can block known exploit patterns for the days between disclosure and patching. See the Web Application Firewall Guide.
Lock down the web tier: application allowlisting and file integrity monitoring on web directories, so a new .aspx or .php file is an alert, not a discovery months later.
Separate data from the application: encrypt files at rest with keys the application cannot export, keep cloud storage credentials out of application settings (prefer managed identities or roles), and run the database under its own account.
Delete after delivery: set retention per flow (hours or days, not indefinitely). The less the platform holds, the less an exploit can take.
Disable what you do not use: legacy file transfer protocols, anonymous access, guest or self-registration, ad hoc sharing features and unused connectors.

SFTP server security and SFTP access control

Most MFT products embed their own SFTP service; where you run OpenSSH directly, or need to judge a product's equivalent settings, these are the controls that matter.

Transfer-only accounts: use a Match Group block for transfer users with ForceCommand internal-sftp (an in-process SFTP server that "requires no support files when used with ChrootDirectory"), ChrootDirectory (every path component must be root-owned and not writable by group or others), and AllowTcpForwarding no, X11Forwarding no and PermitTunnel no, so a transfer account cannot become a shell or a network pivot.
Authentication: public keys or certificates for automated partners, PasswordAuthentication no for those accounts, PermitRootLogin no, and a low MaxAuthTries. NIST IR 7966 calls public key authentication "the recommended authentication mechanism for automated access with SSH".
Restrict every key: NIST IR 7966 says automated keys "should be configured with command restrictions unless special approval is given", particularly for file transfers, and restricted by source address, which "prevents an attacker who compromises an identity key from using it elsewhere on the network".
Least privilege inside the chroot: sftp-server -R makes a session read-only; -p and -P allow or deny specific SFTP requests (for example, removing delete or rename for download-only partners).
Host keys and algorithms: give partners your host key fingerprints out of band. RFC 4253 warns that accepting a host key without verification "will render the protocol insecure against active attacks". Keep algorithms current with the updates to RFC 4253 (RFC 8332, 8709 and 9142, among others) and drop SHA-1 based ones.

SFTP access review

Review every transfer account each quarter: owner, partner, business flow, key fingerprint, source restriction, last successful login and last file moved. NIST IR 7966 recommends finding unused keys by monitoring logs over "6 to 12 months" and removing orphan authorized keys, which "may represent backdoor keys". Disable accounts with no transfer in 90 days and delete them after confirmation. See the SSH Key Management Guide.

Where identity fits

An MFT platform is mostly operated by non-human identities: partner SSH keys and certificates, API keys for cloud based file transfer, workflow service accounts that read internal shares, and storage credentials. Each one moves sensitive files without a person present.

Give each partner and flow its own identity: never share one account or key across partners, so one can be revoked without stopping all others.
Vault the platform's own secrets: database passwords, storage keys and outbound partner credentials belong in a secrets manager, not in configuration. The GoDaddy managed WordPress breach showed how access to one system can expose customers' sFTP and database credentials at once. See the Secrets Management Guide.
Treat MFT administrators as privileged: MFA, separate admin accounts and alerts on account creation, which is exactly what LEMURLOOT abused.
Govern partner access as third-party access: joiner and leaver processes on the partner side, contract end dates and periodic attestation. See the Third-Party Access Guide.

SFTP monitoring and exfiltration detection

MFT logs serve two purposes: detecting misuse early and proving what was taken. Forward them off the platform in real time, because both campaigns above involved access to logs or databases on the compromised host.

Signal	Source	Why it matters
File operations per session	MFT audit log; OpenSSH `sftp-server -l INFO`, which logs "transactions that sftp-server performs on behalf of the client" (default is ERROR)	Reconstructs exactly which files each account read
Key fingerprint per login	SSH server logs (NIST IR 7966: log key fingerprints)	Ties transfers to a specific key, not just an account
Logins from new sources	Gateway and SSH logs	A valid key used from an unauthorised host
New or elevated admin accounts	Application audit log and database	Mirrors the rogue "Health Check Service" accounts in AA23-158A
New files in web directories; web server spawning shells	File integrity monitoring, EDR (ATT&CK DET0394 analytics for T1505.003)	Web shell persistence
Download volume per account and in total	MFT logs, gateway, firewall egress	Bulk collection looks like a spike against a stable baseline
Exploit patterns in requests	WAF and web server logs	AA21-055A describes injection traces in web server rewrite logs

Measure the programme with a few numbers: internet-facing MFT listeners versus approved (target equal); days from vendor security fix to production for the MFT platform; transfer accounts without an owner or with no activity in 90 days (target zero); share of flows on encrypted protocols with verified host keys or certificates; median file retention on the platform; and share of MFT servers forwarding audit logs to the SIEM within five minutes. See the Data Exfiltration Guide for wider egress detection.

MFT breach response

Contain: AA21-055A advises to "Temporarily isolate or block internet access to and from systems hosting the software". Do it at the gateway and keep the host running for evidence.
Preserve evidence: image the servers, export application and database audit tables and web server logs before patching overwrites anything.
Hunt: new files in web directories, unknown administrator accounts, and the advisory's indicators; AA23-158A publishes hunting rules and an audit query for active administrator users.
Rotate everything the platform held: partner passwords and keys, outbound partner credentials, storage account keys (LEMURLOOT read Azure storage keys), database credentials and encryption tokens (AA21-055A says to reset tokens including the "W1" encryption token).
Scope the data: use transfer logs and database records to list every file and partner affected; this drives notification duties.
Patch, rebuild and verify: apply the fix, or rebuild from known-good media, then re-enable partners in waves with monitoring raised.
Notify: partners, regulators and data subjects as required. See the Incident Response Guide.

Implementation roadmap

Inventory (weeks 1 to 2): every file transfer application, SFTP service and FTP server, including shadow servers set up for one partner, with listeners, partners, flows and data classes.
Reduce (weeks 3 to 6): close unused listeners, move admin interfaces inside, put the web portal behind a WAF and MFA, set retention per flow.
Migrate protocols (months 2 to 6): move partners off plain FTP to SFTP, FTPS with PROT P or AS2, in pilot rings starting with internal flows and a few cooperative partners. Run old and new endpoints in parallel per partner and keep the old one disabled but configured for two weeks as rollback.
Govern identities (ongoing): one account per partner flow, restricted keys, vaulted secrets and quarterly SFTP access review.
Monitor and rehearse: forward logs, build the detections above, and run a tabletop of an MFT zero-day once a year.

Decision guidance

SFTP or FTPS: prefer SFTP for new flows: one port, simpler firewalling and mature key controls. Use FTPS when partners or devices only support it, with PROT P enforced.
AS2 or SFTP for EDI: AS2 is preferred where signed receipts and non-repudiation are contractual; SFTP is simpler where they are not.
On-premises MFT or cloud based file transfer: SaaS removes the emergency patching burden, which is the main lesson of both campaigns; on-premises keeps data location and integration under your control. Either way, keep retention short.
Small organisations: avoid running an internet-facing MFT server if a managed service fits; if you must, expose SFTP only, with key-based partner accounts and short retention.
Large organisations: a gateway tier in the DMZ, an emergency patch process with a named owner, central logging and a partner identity process tied to contracts.

Framework mapping

Framework	Reference	MFT relevance
NIST SP 800-53 Rev. 5	AC-4, SC-7, SC-8, CM-7, SI-2, SI-4, AU-12	Information flow, boundary protection, transmission confidentiality, least functionality, flaw remediation, monitoring, audit generation
NIST CSF 2.0	PR.DS-02, PR.PS-02, DE.CM-01	Data in transit protected, software maintained, networks monitored
ISO/IEC 27001:2022 Annex A	A.5.14, A.8.20, A.8.24	Information transfer, network security, use of cryptography
CIS Controls v8.1	3.10, 4.8, 7.7	Encrypt sensitive data in transit, uninstall or disable unnecessary services, remediate detected vulnerabilities
MITRE ATT&CK v20	T1190, T1505.003, T1048	Exploit public-facing application, web shell, exfiltration over alternative protocol

Common failure patterns

Files kept forever: delivered files stay on the platform for years, so one exploit exposes every partner exchange ever made.
Admin console on the internet: configuration and user management reachable from anywhere, often without MFA.
Patching on the normal monthly cycle: mass exploitation happens in days, so a monthly window is too slow for the file transfer web portal.
Shared and unrestricted partner keys: one key used by several partners, with shell access and no source restriction, never rotated.
FTPS with a clear data channel: TLS on the control connection only, so files cross the network unencrypted.
Logs only on the box: the attacker edits or deletes them and the organisation cannot say what was taken.

Practitioner checklist

Inventory every MFT platform, SFTP service and FTP server, with listeners, partners and data flows.
Expose only required protocol listeners through a DMZ gateway; keep admin console, APIs and database internal.
Put MFT on an emergency patch track tied to vendor advisories and CISA KEV.
Retire plain FTP; enforce PROT P on FTPS and signed MDNs on AS2.
Configure SFTP transfer accounts with chroot, forced internal-sftp, no forwarding and key-only authentication.
Restrict every partner key by source and command, one identity per partner flow, reviewed quarterly.
Set file retention per flow and delete after delivery.
Forward transfer, admin and web logs off the platform; alert on new admin accounts, web directory changes and volume spikes.
Keep a tested MFT breach runbook covering isolation, evidence, credential rotation and data scoping.

Managed File Transfer (MFT) Security Guide: Hardening and Monitoring