MOVEit Transfer Hardening Guide: Admin Access, Patching and Exposure

Progress MOVEit Transfer is built to accept files from the internet, which means its web tier, its accounts and its database are permanently exposed to whoever finds the next flaw. In 2023 the CL0P group exploited a SQL injection vulnerability (CVE-2023-34362) to plant a web shell, create rogue administrator accounts and steal data from MOVEit Transfer servers, and CISA's advisory warned that rebuilding the web server without cleaning the database left the attacker's accounts in place. This guide covers MOVEit Transfer specifically: permission levels, remote access rules, multi-factor authentication, interface policies, service accounts and API clients, auditing, a hardening baseline and response. It is written for MFT administrators and security engineers. Protocol choice and general MFT practice are in the Managed File Transfer (MFT) Security Guide, which this page does not repeat. Settings were checked against the MOVEit Transfer 2023 administrator help on 27 October 2026; menu names can differ in later releases, so confirm against the help for your version.

Key takeaways

• Default deny is built in, keep it. MOVEit Transfer remote access rules are processed top to bottom, first match wins, and anything unmatched is denied; administrators can sign on only from the local console until remote access is expanded.
• Separate admin access from user access. Administrators and FileAdmins have their own remote access list, and SysAdmin access is set separately in System Settings, so admin sign-on can be limited to a management network while partners reach the user interface.
• Know what MFA does not cover. MOVEit MFA protects web sign-on only: it does not apply to direct FTPS or SFTP sessions, is never required on the server itself, and SAML users are outside its enforcement.
• The database is part of the incident. CISA's AA23-158A notes that LEMURLOOT created administrator accounts named "Health Check Service" and that rebuilding the web server alone left those accounts in the database.
• Logs must leave the server. MOVEit writes audit entries to its own database; send them to syslog or the Windows Event Log and forward from there so evidence survives a compromise of the host.

How identity and access work in MOVEit Transfer

MOVEit Transfer runs as a web application with HTTPS, FTP and SSH interfaces in front of a database that stores users, folders, settings and the audit trail. Each organisation in a MOVEit site has its own users, policies and remote access rules.

The interface settings under SETTINGS, Security Policies, Interface are defaults for new users and can be applied to existing users; individual users can be overridden under USERS, then the username, then User Authentication. Review those overrides: they are where exceptions accumulate.

Admin roles and privileged access

• Admin remote access list: set the Administrators and FileAdmins list to allow only management subnets or a jump host, with no catch-all at the bottom. Set SysAdmin remote access in System Settings the same way.
• Trusted Hosts: a trusted host bypasses IP lockout and session IP consistency checks and is given the same privileges as localhost. Keep the list empty or limited to specific internal hosts; the all-addresses mask is not allowed, and you should not approximate it with broad ranges.
• Server access is admin access: console sessions are not checked against remote access rules and never require MFA. Treat RDP or console access to the MOVEit server as SysAdmin-equivalent and protect it through PAM. See the PAM Maturity Model.
• Audit administrator accounts: CISA advised auditing active administrator accounts in the database; do it routinely, not only after an incident, and alert on any new SysAdmin or Admin.

Integrations, API tokens and service accounts

Most MOVEit traffic is machine to machine: partner SFTP accounts, MOVEit Automation jobs, scripts using the MOVEit Transfer API and line-of-business systems dropping files. These are non-human identities with direct access to sensitive data.

• One account per integration: give each partner system and script its own MOVEit user with access only to its folders. Shared integration accounts make revocation and investigation impossible.
• Keys over passwords for SFTP: under the SSH interface policy, set Require an SSH client key for system accounts, and Require a password in addition to a valid SSH key where the partner can support it. This is the practical MFA for SFTP, since web MFA does not apply.
• Client certificates for HTTPS automation: for API and MOVEit Automation clients, require an SSL client certificate, and match certificate CN to the username so a stolen password alone is not enough.
• Disable unused interfaces: if no client uses the API or MOVEit Wizard, turn off HTTPS access via other HTTP clients; turn off insecure plain-text FTP everywhere.
• Restrict by source: add partner and integration source addresses to the Users remote access list explicitly, specific addresses at the top, ranges in the middle, and no catch-all if the user base allows.
• Vault and rotate: store integration passwords and private keys in a secrets manager, rotate them on a schedule, and rotate all of them after any MOVEit security advisory that you could not patch before exploitation began. See the Secrets Management Guide.
• Cloud storage keys: AA23-158A reports that LEMURLOOT could retrieve Azure storage settings. If MOVEit stores files in cloud storage, scope the storage key to that use and include it in rotation.

See the NHI Offboarding and Decommissioning Guide for retiring partner accounts when contracts end.

Logging and detection

MOVEit Transfer writes every audit entry to its audit database, with successful actions at Information level and failures at Error level; failed sign-ons are logged by default. Under System, Auditing, enable Syslog Logging (default UDP port 514, facility FTP) and the Windows Event Log (Application or MOVEit log). Syslog over UDP is best effort, so also forward the Windows Event Log with your standard agent to the SIEM.

The IP lockout policy (default 15 bad attempts in 5 minutes, set by SysAdmins) throttles password attacks; lockout events are a useful signal, but check that Trusted Hosts are not exempting the addresses an attacker would use. See the Cl0p Threat Actor Profile for the group's wider pattern of MFT campaigns.

Metrics:

• Days from a MOVEit security advisory to patch on every node, against a target of days, not weeks.
• Number of SysAdmin and Admin accounts, and number created in the last quarter without a change ticket (target zero).
• Percentage of web users with MFA enforced, and the number of MFA exemptions.
• Percentage of SFTP system accounts that require an SSH key.
• Number of remote access rules ending in a catch-all allow, and number of Trusted Hosts.
• Audit log forwarding coverage and the gap between MOVEit and SIEM event counts.

Hardening baseline

1. Exposure: publish only the interfaces partners need; put a WAF or reverse proxy in front of HTTPS; keep the MOVEit server and its database in a segmented zone, and do not expose the database or server management ports.
2. Remote access rules: separate, explicit allow lists for Administrators and FileAdmins, Users and Webpost; SysAdmin from the management network only; Trusted Hosts empty unless essential.
3. IPv6: the remote access documentation states IPv6 remote clients are not supported and recommends disabling IPv6 on the server.
4. Session IP binding: leave IP Switching at None (the /32 default) unless a partner's proxy design needs a wider range, to reduce session hijacking.
5. Authentication: Allow and Enforce Multi-Factor Authentication for staff and Admin user classes, keep exemptions to a reviewed list, consider whether Remember this Device suits your risk, and use SAML SSO with MFA at the identity provider for staff, since SAML users are outside MOVEit's own MFA enforcement.
6. Interfaces: disable insecure FTP, require SSH keys for system accounts, require client certificates for automation over HTTPS, and disable API access if unused.
7. Lockout: keep the IP lockout policy on, and set a user lockout policy for each organisation.
8. Retention: delete files and packages after a defined period so a future compromise exposes days of data, not years.
9. Logging: syslog and Windows Event Log enabled and forwarded; file integrity monitoring on the web root.

Testing and rollback: make remote access rule changes in a maintenance window with console access available (localhost is never locked out), pilot MFA enforcement on Admin classes before all staff, and move partners from passwords to SSH keys one partner at a time, keeping the password option until each partner confirms key-based transfers work.

When a MOVEit vulnerability is announced

1. Restrict or block internet access to the HTTP and HTTPS interfaces until patched, as a temporary containment step.
2. Preserve IIS logs, MOVEit audit data and a disk image before cleaning.
3. Hunt for unexpected files in the web root and for Admin accounts you did not create, using CISA's AA23-158A indicators as a model.
4. Remove unauthorised accounts from the application and database, not just the web server.
5. Rotate service account credentials, integration passwords, SSH keys and any cloud storage keys MOVEit uses.
6. Patch every node, then restore access in stages while watching the detections above.
7. Scope which files were downloaded using transfer logs, and start notification analysis.

Small organisations with a single MOVEit server should prioritise patch speed, admin lists restricted to the console or one jump host, SSH keys for partners and file retention. Large deployments with web farms and multiple organisations should add a WAF, central SIEM detections, per-organisation policy reviews and a tested response runbook.

Common misconfigurations

• Catch-all allow rules: an allow entry for every address at the bottom of the Administrators list turns MOVEit's default deny off.
• Relying on MFA for SFTP: MOVEit's MFA does not cover direct SFTP or FTPS, so password-only system accounts remain single-factor.
• Broad Trusted Hosts: large internal ranges added to stop lockouts give those addresses localhost-equivalent treatment.
• Rebuilding without cleaning the database: rogue administrator accounts survive, as CISA warned in 2023.
• Files kept indefinitely: CL0P's 2023 campaign stole whatever was stored, so retention decided the size of each breach.
• Audit trail only in the MOVEit database: an attacker with database access can see and alter the evidence.

Framework mapping

Practitioner checklist

• Patch every MOVEit Transfer node to the current fixed release and subscribe to Progress security notifications.
• Rewrite remote access rules as explicit allow lists, with administrators and SysAdmins limited to management hosts.
• Empty or minimise Trusted Hosts and leave IP Switching at None.
• Enforce MFA for staff and administrators, and SSO with MFA at the identity provider for SAML users.
• Require SSH keys for SFTP system accounts and client certificates for API and automation clients; disable insecure FTP.
• Inventory integration accounts with owners, vault their credentials and rotate them.
• Audit Admin and SysAdmin accounts monthly in both the UI and the database.
• Enable syslog and Windows Event Log, forward to the SIEM, and add file integrity monitoring on the web root.
• Set file and package retention so data is deleted after it has been collected.

Standards and references

• Progress: MOVEit Transfer Security Policies, Remote Access
• Progress: MOVEit Transfer Permissions
• Progress: MOVEit Transfer Multi-Factor Authentication
• Progress: MOVEit Transfer Security Policies, Interface
• Progress: MOVEit Transfer System Auditing
• CISA: Advisory AA23-158A, CL0P exploitation of MOVEit Transfer CVE-2023-34362
• CISA: Known Exploited Vulnerabilities Catalog
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls

Related NHI Mgmt Group resources: Managed File Transfer (MFT) Security Guide · Cl0p Threat Actor Profile · Secure File Transfer Buyers Guide