A growing share of extortion skips the ransomware entirely. Nothing is locked, nothing breaks, and the first sign is an email naming files you recognise. Backups do not help with this one.
Every ransomware plan ever written rests on one assumption. You will know it happened, because things will stop working.
That assumption is now optional for the attacker.
A substantial and growing share of extortion involves no encryption at all. Data is quietly copied out over days or weeks, and the first indication is an email describing your own files back to you with a deadline attached. Nothing crashed. No workstation displayed a ransom note. Every system is running normally, which is precisely the problem, because every detection and every recovery process you built keys off disruption that never came.
Groups behind several of the largest incidents in recent years have moved this way deliberately, and the logic is sound from their side. Encryption is noisy, it triggers endpoint protection, it takes engineering effort, and it gives the victim something to detect. Exfiltration alone is quieter, cheaper to run, and removes the one defence that actually worked.
Ten years of ransomware guidance produced a genuine improvement in backup practice. Offline copies, immutable storage, tested restores. That work was worth doing and organisations are meaningfully better at it.
It also addressed exactly one of the two threats, and the other one is now the more common.
A restore returns your operations. It does nothing about a copy of your data sitting on somebody else's infrastructure. You cannot restore your way out of disclosure, and there is no technical remedy at all once the data has left. Every option remaining is a business decision about consequence, which is a far worse place to be.
Paying to prevent publication buys a promise from somebody who has already demonstrated what their promises are worth.
The encryption case had a clean recovery path. Restore, investigate, notify where required, move on. Unpleasant, expensive, survivable, and the decision about paying was at least about restoring service.
The exfiltration case has no such path.
The regulatory clock starts regardless. Under most data protection regimes, unauthorised access to personal data is a notifiable event whether or not anything was published, and paying does not make it not have happened. Organisations who pay to suppress publication still have to notify, and have now also made a payment that may itself require explanation.
The deletion promise is unverifiable in principle. No evidence exists that a copy was destroyed. Organisations have been extorted a second time over the same dataset.
And the pressure arrives from outside. Attackers contact customers, partners, journalists and regulators directly, which means the disclosure decision is frequently taken out of your hands while you are still assembling facts.
If disruption is not coming, detection has to key off the data movement itself.
Know what matters and where it is. You cannot alert on unusual access to sensitive data without knowing which data is sensitive and where it sits. This is the asset inventory problem again, the same one underneath every control framework including PISF, and it remains the single most common missing prerequisite.
Watch volume, not just permission. The access is usually authorised. An account that legitimately reads customer records reading all of them over a weekend is the signal, and it is invisible to any control that only asks whether access was permitted.
Watch egress. Large transfers to cloud storage, file sharing services and newly registered domains. Attackers deliberately use services your staff use legitimately, which is why the volume and the destination together matter more than either alone.
Watch the staging. Exfiltration is usually preceded by collection. Archives appearing in unusual locations, compression activity on a file server, a service account suddenly enumerating shares. This is the most detectable phase and the one most teams are not instrumented for.
Cover machine identities. The account doing this is frequently not a person. It is a service account with broad standing access that nobody has a behavioural baseline for, which is the population we wrote about in your machine identities outnumber your people.
The strongest control here is unfashionable and it is not a product.
Hold less. Data you deleted on schedule cannot be exfiltrated. Most organisations retain far beyond any legal requirement because deletion requires a decision and retention does not. Enforcing your own retention policy is the highest return control available against this threat and it usually costs nothing but political effort.
Then reduce standing access to what remains. Most large exfiltrations run through accounts that held broad access continuously for reasons that made sense once. Access on request, scoped and time limited, changes the worst case substantially.
Take your incident response plan and read it against this scenario. Nothing is down. Nothing is encrypted. An email has arrived naming files that are genuinely yours.
Most plans do not survive the first hour of that reading. They assume a technical recovery workstream that does not exist here, and they are usually silent on the questions that actually arise. Who verifies the sample is real. Who decides whether to engage. Who talks to the regulator, and when does the clock start. Who talks to customers if the attacker gets there first. What is the position on payment, decided in advance, by somebody with authority to decide it.
Run it as a tabletop exercise with legal and communications present rather than only the technical team. Ninety minutes will find more gaps than a year of plan revisions, because the gaps are in the decisions rather than in the document.
We think most organisations have a recovery plan and not an extortion plan, and that the difference will be discovered at the worst possible time.
We also think the honest advice here is mostly about holding less data and granting less standing access, neither of which requires buying anything. Any vendor telling you a product prevents this is describing detection, not prevention, and the distinction matters when you are deciding what to spend.
Our DFIR practice works these incidents, where the central question is scope rather than recovery, meaning what actually left and what was in it. Answering that well is the difference between a precise notification and an alarming one. Our SOC design and monitoring work builds the egress and volume detections that give you a chance of noticing beforehand, and our GRC practice handles the retention and notification side, which is where the real cost lands.
CyberNexus keeps the record of what was decided and by whom, which matters enormously in the months afterwards, and ControlGraph answers the question every one of these incidents produces within the first hour. What did that account reach, and who needs to be told today.
Ask one question about your most sensitive dataset. If somebody copied all of it out this weekend using a valid account, what would tell you.
If the honest answer is nothing, that is your finding, and it did not take an assessment to reach.
An attack where data is stolen and the victim is threatened with publication, without any ransomware being deployed. Systems keep working normally, so the first sign is usually contact from the attacker.
No. Backups restore availability. They do nothing about a copy of your data held by somebody else. Once data has left, there is no technical remedy, only business and regulatory decisions.
That is a legal and business decision, and it should be made in advance rather than during an incident. Payment cannot be verified to result in deletion, notification obligations usually apply regardless, and repeat extortion over the same dataset has been documented.
Baseline normal access volume for sensitive data and alert on deviation rather than on permission alone, monitor egress to cloud storage and file sharing services, and watch for collection activity such as archives appearing on file servers before transfer.
Under most data protection regimes, unauthorised access to personal data is notifiable whether or not it was published. Paying an attacker does not remove the obligation. Confirm the specific requirement with your legal counsel for each jurisdiction you operate in.
Continuous threat exposure management is the phrase of the year and most implementations of it are a scanner on a schedule. What separates the version that changes decisions from the version that produces a longer list.
Read the article
Security stacks grew by accumulation rather than design. The result costs a fortune, produces more alerts than anyone can read, and leaves gaps between products that nobody owns. How to consolidate without losing coverage.
Read the article
Some of the most effective intrusions of the last two years used no malware at all. Somebody rang the help desk, sounded convincing, and got a password reset. Cloned voices have made that conversation harder to win.
Read the articleIf this raises a question about your own compliance position or your security operations, the quickest route is a direct conversation.
