Join our Newsletter — 33% off our NHI Course
Home› Guides› Data Extortion Without Encryption Guide: Theft-Only Attacks and…
Guide Attack Techniques & Malware

Data Extortion Without Encryption Guide: Theft-Only Attacks and Response

PDF for newsletter subscribers · free to read online

← All guides
By Lalit Choda, NHI Mgmt Group Updated 24 October 2026 13 min read
On this page

A growing share of extortion attacks never encrypt anything: the attacker copies data, leaves systems running and threatens to publish or sell what was taken. Backups do not help against this, and the first sign of the incident is often an email to an executive or a listing on a leak site weeks after the theft. This guide explains how theft-only extortion works, where it shows up (managed file transfer, SaaS and cloud data platforms), what it costs, how to detect exfiltration before the demand arrives, and how to harden and respond. It is written for security operations, incident response and data protection teams. Payment, negotiation and sanctions questions are covered only briefly here and in depth in the linked guides.

Key takeaways

  • Backups do not answer theft. Recovery from immutable backups solves encryption; it does nothing about copied data, so exfiltration detection and data minimisation carry the weight.
  • The big campaigns were mass theft through one weakness. Cl0p exploited a single MOVEit Transfer zero-day, and UNC5537 used infostealer passwords on Snowflake accounts without MFA, each reaching many organisations at once.
  • Extortion can lag the theft by months. Google reported that ShinyHunters-branded demands sometimes arrived months after the Salesforce data was stolen, so detection must not depend on the ransom note.
  • Payment buys a promise, not deletion. The NCSC warns that a promise to delete data cannot be trusted and that victims have been re-extorted; regulators do not treat payment as mitigation.
  • Notification clocks run regardless. GDPR, US state laws and SEC Item 1.05 apply to stolen data whether or not anything was encrypted.

How the attack works

Theft-only extortion keeps the first half of a double-extortion ransomware attack and drops the encryptor. CISA's #StopRansomware Guide notes that some actors skip encryption entirely and rely on data theft and release threats. Removing the encryptor removes the noisiest, most detectable step and avoids the work of building and running ransomware across a network.

  1. Initial access: exploitation of an internet-facing application (ATT&CK T1190 Exploit Public-Facing Application), valid accounts from infostealer logs (T1078 Valid Accounts, T1078.004 Cloud Accounts), or voice phishing of help desks and users (T1566.004 Spearphishing Voice).
  2. Collection: bulk queries against databases, CRM and cloud storage (T1530 Data from Cloud Storage, T1213.004 Customer Relationship Management Software), often scripted (T1119 Automated Collection).
  3. Exfiltration: transfer to attacker cloud storage or file sharing services (T1567.002 Exfiltration to Cloud Storage), FTP or other non-C2 protocols (T1048 Exfiltration Over Alternative Protocol), or copying to an attacker tenant in the same cloud (T1537 Transfer Data to Cloud Account).
  4. Extortion: emails or calls to executives and staff, a deadline, a sample of stolen records as proof, then a leak site listing, sale on a forum or contact with the victim's customers.

Variants defenders meet

VariantWhat happensDefensive implication
Theft-only extortionData copied, systems untouched, demand to prevent publicationExfiltration detection and data minimisation are the main controls
Double extortionTheft plus encryptionBackups restore operations; the theft still needs the response in this guide
Multi or triple extortionAdds DDoS, contact with customers, partners or regulators to raise pressurePrepare DDoS response and customer communications in advance
Re-extortionA second demand for the same data after payment, or by a different groupPlan as if stolen data will eventually be published
Extortion hoaxClaim of a breach with recycled, scraped or fabricated dataValidate samples against your own records before reacting

Where it shows up

  • Managed file transfer (MFT): CISA's advisory AA23-158A describes how Cl0p (also tracked as TA505) exploited CVE-2023-34362, a SQL injection zero-day in Progress MOVEit Transfer, from 27 May 2023, installing the LEMURLOOT web shell (first seen as human2.aspx) to read the database and pull files. CISA notes that Cl0p's campaigns since 2021 have relied mostly on data theft rather than encryption, as in the 2023 GoAnywhere MFT campaign. The same group later extorted Oracle E-Business Suite customers: see the Oracle E-Business Suite Cl0p campaign.
  • Cloud data platforms: Mandiant tracked UNC5537 using infostealer credentials against Snowflake customer accounts that had no MFA, no credential rotation and no network allow lists; around 165 organisations were notified, and at least 79.7% of the accounts used had prior credential exposure. Data was staged with COPY INTO to temporary stages and pulled with GET. See the Snowflake breach and the Snowflake Security Guide.
  • SaaS CRM: Google Threat Intelligence Group described UNC6040 phoning employees, posing as IT support, and getting them to authorise a modified Salesforce Data Loader connected app; extortion followed, sometimes months later, from actors claiming to be ShinyHunters with 72-hour bitcoin deadlines. See the ShinyHunters Salesforce campaign and the Salesforce Security Guide.
  • Exposed cloud secrets: leaked keys in .env files gave one operation access to cloud storage that it emptied and held to ransom; see the 230 million AWS environments campaign.
  • Traditional networks: the FBI and partners reported that BianLian moved to primarily exfiltration-based extortion around January 2023, leaving victims' systems intact, using FTP, Rclone and Mega to move data out (CISA advisory AA23-136A).

Impact

Without encryption there is no outage, but the costs last longer.

Impact areaWhat it involvesWho owns it
Regulatory notificationGDPR Art. 33 (supervisory authority within 72 hours of awareness) and Art. 34 (individuals where risk is high); US state breach laws; SEC Form 8-K Item 1.05 within four business days of determining an incident is materialDPO, legal, disclosure committee
Downstream notificationCISA advises notifying businesses whose data you store when it is stolen; processors trigger their controllers' own obligationsLegal, account management
Data reviewWorking out what was taken, from which systems, and whose records it contains; often the longest workstreamIR lead, eDiscovery provider
Fraud and follow-on attacksStolen contact and account data fuels phishing and fraud against customers and staffFraud, customer service
Litigation and trustClass actions and contractual claims follow mass-theft campaignsLegal, communications

Payment, law and regulators

  • Payment does not delete data: the NCSC's guidance for organisations considering payment states that a promise to delete stolen data cannot be trusted, and that victims found attackers had lied and later sold or re-used it.
  • Regulators: the ICO, with the NCSC, has said it will not treat ransom payment as a mitigating factor in enforcement, but will view early engagement with the NCSC positively.
  • US sanctions: OFAC's updated advisory of 21 September 2021 applies strict civil liability to payments involving sanctioned persons and names insurers, DFIR firms and financial institutions as facilitators; prompt reporting to law enforcement and cooperation are significant mitigating factors, and licences carry a presumption of denial.
  • UK proposals (status checked 24 October 2026): after a consultation from 13 January to 8 April 2025, the Home Office published its response on 22 July 2025 confirming three measures: a targeted ban on ransomware payments by the public sector and critical national infrastructure, a payment prevention regime requiring other victims to notify before paying, and mandatory incident reporting within 72 hours. The gov.uk page shows no update since September 2025 and we found no bill; the measures are proposals, not law, and the response does not say whether theft-only extortion is in scope.

See the Ransomware Payments and Sanctions Guide and the Ransomware Negotiation Guide.

Detection

The goal is to see the copy happen, not to learn about it from the demand. Map detection to the platforms that hold bulk data.

WhereSignalSource
Network egressUnusually large outbound transfers on any port; SSH tunnelled over 443 (Chisel), Cloudflare tunnels; FTP/SFTP to new destinationsFirewall, proxy, NetFlow (CISA #StopRansomware Guide)
Endpoints and serversRclone, Rsync or portable sync tools, often renamed or placed in odd folders such as programdata\vmwareEDR, application control logs (AA23-136A)
MFT serversUnknown admin accounts (Cl0p created "Health Check Service"), unexpected .aspx files, requests with the X-siLock-Comment headerApp database, web logs (AA23-158A)
SnowflakeLogins from commercial VPNs, unusual client application IDs, CREATE TEMPORARY STAGE, COPY INTO and GET by user accountsLogin and query history (Mandiant UNC5537)
SalesforceNew connected apps, Data Loader or Python clients from unknown IPs, bulk API exportsEvent Monitoring, Transaction Security Policies (GTIG UNC6040)
IdentityCredentials appearing in infostealer logs; MFA registration or connected app consent after a help desk callThreat intelligence, IdP logs

Metrics that show it is working

  • Egress visibility: percentage of crown-jewel data stores (databases, data warehouses, CRM, MFT) whose query or export logs reach the SIEM.
  • Bulk export alerting: number of platforms with a tested alert on bulk export, and time from test export to alert.
  • MFA and allow lists: percentage of data platform accounts, including service users, with MFA or network policy enforcement.
  • Exposed credential response: median time from a credential appearing in infostealer intelligence to rotation.
  • Data minimisation: volume of personal data past its retention period in high-risk stores, trending down.

See the Data Exfiltration Guide for detection engineering detail.

Prevention and hardening

  • Reduce what can be stolen: delete data past retention, tokenise or pseudonymise identifiers in analytics stores, and keep full exports out of MFT drop folders after transfer. Data that does not exist cannot be extorted.
  • Patch and isolate internet-facing transfer tools: treat MFT, file sharing and ERP front ends as top patch priority, especially entries on the CISA KEV catalog, and restrict their admin interfaces to management networks.
  • Close the credential path to data platforms: enforce MFA or key-pair authentication for every human user, network policies for service users, and rotation when credentials appear in infostealer logs.
  • Control SaaS integrations: restrict "API Enabled", "Customize Application" and "Manage Connected Apps" in Salesforce to a small admin group, allowlist connected apps, and set login IP ranges. See the SaaS and OAuth App Governance Guide.
  • Constrain egress: block unapproved file sharing and sync services, and use application control to block portable tools such as Rclone (NIST SP 800-53 SC-7(10) Prevent Exfiltration, AC-4 Information Flow Enforcement).
  • DLP where it fits: DLP rarely sees a SQL export from a cloud warehouse. See the Data Loss Prevention (DLP) Guide.

Implementation sequence

  1. Inventory (weeks 1 to 4): list every store holding bulk personal or confidential data, its owner, its internet exposure and whether its access and export logs are collected.
  2. Quick wins (weeks 2 to 8): MFA and network policies on data platforms, connected app restrictions, MFT patching and admin account audit. Pilot network policies in a test account first; roll back by detaching the policy if legitimate jobs fail.
  3. Detection (months 2 to 4): deploy bulk export and egress alerts in report-only mode, tune thresholds against two weeks of baseline, then route to the SOC. Test with a controlled export.
  4. Response readiness (months 3 to 6): write a theft-only extortion scenario into the incident response plan: who validates samples, who decides on engagement, who notifies whom, and where decisions are recorded offline as the NCSC advises. Exercise it once a year.
  5. Minimisation (ongoing): enforce retention schedules and track deleted volume.

Responding to a demand

  1. Do not reply until the incident lead, legal counsel and, where relevant, insurer are engaged.
  2. Validate the sample: match records to a system and time window to separate a real theft from a hoax or old leak.
  3. Preserve evidence: logs from the affected platform, egress devices and identity provider, before retention expires.
  4. Contain: rotate the credentials, tokens and connected apps involved, and close the exploited vulnerability.
  5. Scope and notify: run the notification assessment in parallel, not after the negotiation decision. See the Breach Notification Laws by Country Guide.
  6. Report to law enforcement (NCSC and Action Fraud in the UK; CISA, FBI or IC3 in the US), which also matters for OFAC mitigation.

Small organisations should focus on the first three hardening items and a retained IR provider; large ones need per-platform detection and a named owner per store. For third-party platforms, see the Vendor SaaS Breach Response Playbook.

Where identity fits

Most theft-only campaigns used a legitimate identity rather than malware: a stolen user password without MFA, a connected app the victim authorised, a leaked cloud key or a service account on a file transfer server. Service users on data warehouses and integration tokens on CRM tenants often have the broadest read access and the weakest monitoring, so inventory them, scope them to the tables or objects they need, and alert when they run from new networks. See the SaaS API Token Security Guide.

Lessons from incidents

  • One shared weakness, many victims: MOVEit, Snowflake and Salesforce campaigns all reached large numbers of organisations through one product or one technique, which means sector peers are often hit in the same week.
  • The help desk is the exploit: UNC6040 needed no vulnerability, only an employee willing to enter a connection code.
  • Destruction can follow theft: in the Gitloker campaign malicious OAuth apps and stolen credentials were used to wipe GitHub repositories as part of an extortion operation, so theft-only response plans still need tested backups.

Framework mapping

FrameworkReferenceRelevance
MITRE ATT&CK v20T1190, T1078.004, T1566.004, T1530, T1213.004, T1567.002, T1048, T1537Access, collection and exfiltration techniques used in theft-only campaigns
NIST SP 800-53 Rev. 5SI-4(4), SI-4(18), SC-7(10), AC-4, IR-4, IR-6, IR-8Egress monitoring, exfiltration prevention, incident handling and reporting
NIST CSF 2.0PR.DS-01, PR.DS-02, DE.CM-01, RS.MA-01, RS.CO-02Data protection, network monitoring, coordinated response, notification
CIS Controls v8.1Control 3 (Data Protection), 13 (Network Monitoring and Defense), 17 (Incident Response Management)Data inventory and retention, egress monitoring, response planning
ISO/IEC 27001:2022A.8.12 Data leakage prevention; A.5.24 to A.5.26 incident managementLeakage controls and incident response process

Practitioner checklist

  • Inventory every bulk data store and confirm its access and export logs reach the SIEM.
  • Enforce MFA or key-based authentication and network policies on data warehouse and CRM accounts, including service users.
  • Rotate any credential that appears in infostealer intelligence within an agreed SLA.
  • Restrict connected app authorisation and API export permissions to a small admin group.
  • Patch internet-facing MFT and file sharing products first and audit their admin accounts in the application database.
  • Block unapproved file sharing services and portable sync tools such as Rclone.
  • Alert on bulk exports and large outbound transfers, and test the alert with a controlled export.
  • Add a theft-only extortion scenario to the incident response plan, including sample validation and offline decision records.
  • Pre-agree legal, insurer and law enforcement contacts and the notification decision process.
  • Enforce retention schedules so less data is available to steal.

Standards and references

Related NHI Mgmt Group resources: Ransomware Response and Recovery Guide · Data Exfiltration Guide · Ransomware Groups Guide · Cyber Insurance Guide · Data Breach Notification Checklist

PDF for subscribers

Take this guide with you

Every section, table and checklist in one PDF, with links to the sources and related guides. Subscribe to our weekly NHI & AI Identity Journal and we’ll email you a download link.

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Written and reviewed by Lalit Choda, NHI Mgmt Group. Last updated 24 October 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org

PDF Downloads for Newsletter Subscribers

Get the guide

Enter your details and we’ll email you a download link.

The full guide is free to read online. The PDF is a thank you for subscribing.

Fill in all fields marked * and tick the PDF box to continue.