CL0P

Executive summary

CL0P differs from classic ransomware groups because its most visible campaigns strongly revolve around scalable data theft through vulnerable enterprise applications. The MOVEit Transfer campaign around CVE-2023-34362 is the key example: CISA and FBI described how the group abused a SQL-injection zero-day and deployed the LEMURLOOT webshell on MOVEit Transfer web applications.

For leadership, this profile matters because impact often arises through chains. An organisation can be hit directly through its own vulnerable installation or indirectly because data was held by a supplier, HR provider, education partner, healthcare partner or transfer platform.

CL0P-like incidents require a different crisis approach than network-wide encryption. The technical focus is application forensics, data flows, patch windows, webshell activity, log retention and data classification.

Group and development

CL0P, also written as Clop or Cl0p, has been visible for years in ransomware and extortion reporting. Public analysis more often links the group to large-scale exploitation of data-rich software than to purely opportunistic endpoint encryption.

The group is campaign-driven. IOCs, vulnerabilities, webshells and victims must therefore be separated per campaign. A CL0P mention without context says little; investigators must record which vulnerability or application was involved, which exploitation window matters and which data was accessible in that window.

For organisations, CL0P is an important exposure-management profile. A single internet-facing application or supplier can be enough for a major data breach.

Methods and attack chain

The attack chain starts at an internet-facing application. Investigate webserver logs, application logs, database events, upload and download history, API calls, temporary files and webroot changes.

After exploitation, the actor can use webshell functionality for reconnaissance and data access. The forensic question is which data was reachable through the application process, which can differ sharply from what normal users see.

Exfiltration must be reconstructed through application and network data. Look for download spikes, atypical user agents, foreign IP addresses, long sessions, large response sizes, unknown files and activity outside normal transfer processes.

Extortion often follows later. The actor may cluster victims and only make contact after analysis or publication preparation. The timeline must separate exploitation, data theft and communication.

Attack pattern from public cases

CL0P is best known for data-theft campaigns against data-rich enterprise platforms. The MOVEit campaign around CVE-2023-34362 is the best-known example: not classic domain-wide encryption as first signal, but exploitation of an internet-facing transfer application, webshell use and rapid data collection.

The attack starts at the application layer. The actor abuses a vulnerability, reaches files or databases through the application process and removes data normally exchanged by customers, suppliers or internal departments.

CL0P shows that ransomware extortion does not always need encryption. If sensitive data is stolen from a transfer platform, notification duties, reputation risk and supply-chain impact can arise without endpoints being hit.

The main defensive lesson is asset and data knowledge. Organisations must know which file-transfer platforms they use, which data is stored there, how long it remains, which suppliers have access and which logs are available when a zero-day becomes known.

Known IOCs and artefacts

CISA AA23-158A links the MOVEit campaign to CVE-2023-34362 and the LEMURLOOT webshell. This combination is a core artefact for CL0P investigation around MOVEit Transfer.

For MOVEit-like investigations, suspicious files in web directories, abnormal SQL errors, unknown requests to vulnerable endpoints and unusual download volumes matter more than one endpoint hash.

A concrete defensive artefact is the exploitation window: was the MOVEit server publicly reachable before patch or mitigation, and do webserver and application logs from that period still exist?

CL0P IOCs are campaign-bound. A LEMURLOOT or MOVEit indicator is not automatically applicable to every CL0P claim. First identify the platform involved, then apply indicators.

Victims and historical context

The MOVEit campaign affected governments, education, financial institutions, healthcare organisations, suppliers and large enterprises worldwide. The pattern is supply-chain oriented: data from many organisations can pass through a limited number of software or service nodes.

Record per victim claim whether it concerns a direct installation, supplier impact, data processor or downstream customer. Add claim date, source, involved platform, data types, exploitation window and publication status.

Detection and follow-up

Defensive priorities are asset inventory for file-transfer platforms, rapid patching, internet-exposure control, WAF and proxy logging, application auditing, data classification, least privilege for service accounts and supplier contracts with concrete logging and notification terms.

When a CL0P signal appears, an organisation must quickly determine whether customers use the named software, whether exploitation windows overlap exposure, whether suppliers were affected and which data was in transfer.

Deep forensic dossier

CL0P investigation differs fundamentally from classic ransomware forensics. The first question is not which endpoints are encrypted, but which application made data available to the actor.

Application context determines impact. A file-transfer platform often contains temporary files, but those temporary files can be the most sensitive data in the organisation: payroll files, medical data, customer lists, legal documents, contracts or exports from core systems.

Webshell investigation must be careful. Look for unknown files, abnormal timestamps, suspicious parameters, unusual response sizes and processes that do not match normal application behaviour.

Supply-chain analysis is essential. Ask suppliers whether they used the vulnerable software, when they patched, which customer data was present and which logging they can share.

Data-breach validation requires evidence discipline. Combine samples, transfer logs, application permissions, database queries, file lists and network data. Report in categories: confirmed leaked, probably accessed, possibly present and not demonstrated.

For prevention, CL0P should lead to structural questions about software supply chain and application management: which internet-facing data platforms exist, who owns them, how quickly zero-days are handled and how long logs are available.

What to watch for

CL0P differs from many classic ransomware groups because damage often starts at a data-rich application. Watch vulnerable file-transfer platforms, web applications, upload/download portals, database links and supplier systems that temporarily or structurally handle sensitive data.

Important signals are suspicious web requests, SQL errors, unknown files in web directories, abnormal download volumes, unusual API calls, unexpected service-account activity and data flows outside normal transfer patterns.

With CL0P, the question is not only whether your network is encrypted. The question is which data was reachable through a vulnerable application, whether a supplier processed that data and whether logs exist long enough to reconstruct exfiltration.

How to defend against CL0P

Create a current inventory of all file-transfer and data platforms. Record owner, internet exposure, version, patch process, logging, service accounts and data types.

Limit data in transfer environments. Remove old files, restrict retention, apply least privilege for service accounts and monitor large downloads.

Put supplier agreements in writing. Ask which software suppliers use, how quickly they patch, which logs they keep and how they report data breaches.

Victim pattern and lessons

CL0P campaigns such as MOVEit affected many organisations at once through shared software. Victims included government, education, healthcare, financial services, HR services and large enterprises.

The main lesson is that extortion without encryption can be just as serious. When personal data, contracts, payroll data or healthcare information is stolen, the crisis is real even if no server is encrypted.

Use CL0P to review data governance and software supply chain together: which sensitive data is where, which suppliers process it, which logs exist and who can prove within 24 hours what was downloaded?

A practical check is to determine today which transfer portals are publicly reachable and which sensitive files were present there in the past thirty days.

Indicators of compromise (IOCs)

Indicators are historical observations, not proof of a current infection. Validate source, age and context before hunting or blocking; legitimate administrative tools can produce false positives.

Sources

• CISA #StopRansomware: CL0P exploits MOVEit CVE-2023-34362
• CISA news release on CL0P and MOVEit
• Ransomware.live — CL0P

Evidence and limitations

Attribution describes the source assessment, not a verified identity. A leak-site listing alone does not prove encryption, data theft, a particular vulnerability or an affiliate relationship. Missing information is left explicit.