Managed file transfer software is a high-value target by design. It sits at the network edge, it holds credentials for downstream systems, and it stores exactly the files organisations most want to keep private. MOVEit Transfer was not the first product in that category to be exploited, and it won’t be the last.

The Cl0p campaign against CVE-2023-34362 was notable for the speed of exploitation — within days of the patch — and for the scale of the data taken.

The vulnerability

A SQL injection in the MOVEit Transfer web application, reachable without authentication through the MOVEitISAPI endpoint. The vulnerable handler is the human2.aspx page under the ISAPI path, which is where the attacker’s HTTP request lands.

The pre-authentication part is what turns a serious bug into an emergency: no credential, no user interaction, just a POST body.

The exploitation shape

The published exploit chains three capabilities:

  1. SQL injection — arbitrary query execution against the MOVEit database.
  2. Session forgery — the injection is used to write a row into the session table, producing a valid authenticated session without knowing a password.
  3. File write through a legitimate feature — MOVEit has administrative functionality that writes files to disk. With a forged admin session, that becomes an ASPX web shell in the application directory.

The third step is the one worth studying. The attacker did not need a separate file-write vulnerability; they used the product’s own feature after faking elevation to reach it.

Command and control

The web shell used in the campaign was named human2.aspx and referred to as LEMURLOOT. It supported a small set of commands, gated by a hardcoded password header:

X-siLock-Comment: <secret>

Commands let the operator enumerate the file system, exfiltrate archives, and delete their own staging artefacts. It read the connection strings from machine.config and used them to reach the database directly — so the web shell was a staging point, not the primary exfiltration channel.

Timeline that made it bad

  • 2023-05-31 — Exploitation began, reportedly weeks before the vendor published the advisory.
  • 2023-06-02 — Progress published an advisory and patch.
  • 2023-06-05 onwards — Mass exploitation from multiple IP ranges against unpatched instances.

The gap between the start of exploitation and public disclosure is the recurring pattern in this class of incident. It means “patch when the advisory lands” can already be too late.

Hunting for it

For anyone who had a MOVEit instance exposed in that window:

  • Check for human2.aspx and any unexpected .aspx files in the MOVEit web directory.
  • Review ISAPI logs for POSTs to that handler that returned 200 with no preceding authentication.
  • Look for large outbound transfers from the MOVEit server — the data staging was bulk archive creation.
  • Audit the session table for sessions created without a corresponding login event.
  • Treat credentials as compromised. MOVEit stores credentials for its own database and often for connected systems. Rotate all of them.

What generalises

Three things, and none of them are specific to this product:

  1. File transfer products are tier-0 assets. They should be treated with the same paranoia as a domain controller or a CA — network-restricted, monitored, and patched on an emergency cadence.
  2. Pre-auth SQL injection is still being shipped. Parameterised queries are not universally adopted in commercial appliances.
  3. Patch speed is not a substitute for detection. The organisations that came out of this least damaged were the ones who could tell, within a day, which instances had been touched.

The uncomfortable part is the affected-organisation count. A single vulnerable product at the edge of thousands of networks means one exploit turns into thousands of incidents — the same dynamic that made Log4Shell and ProxyLogon so costly.