Human-Operated Ransomware: Why a Person in Your Network Is a Different Problem

Most people picture ransomware as a piece of malware: someone opens a bad attachment, files start encrypting, a note appears. That version exists. It is automated, it is fast, and it is largely a nuisance for a business with working backups.

Human-operated ransomware is a different category of event. The encryption is the last five minutes of an operation that a person has been running against your network for a while. Treating the second thing as if it were the first is the single most expensive misunderstanding I see in this space.

What actually separates the two

Commodity ransomware is a program. It runs where it lands, encrypts what it can reach from that one machine, and asks for money. Its behavior is fixed before it ever arrives. It does not know what your file server is called, it does not know which account your backup software runs as, and it cannot change plans when it hits an obstacle.

Human-operated ransomware is an operation run by people, usually with a division of labor behind it. One group specializes in getting initial access and sells it on. Another buys that access and does the intrusion work. The encryption tooling itself is often rented from a third party that takes a cut. The person inside your network is not a piece of malware executing logic. They are an intruder with a goal, a budget of time, and the ability to improvise when something blocks them.

That improvisation is the whole story. Automated ransomware fails when it meets a control. An operator meets the same control, backs off, and finds another route.

What an operator does once inside

The pattern is remarkably consistent, because the objectives are the same every time.

They get quiet access and make it durable. The way in is usually mundane: valid credentials bought or phished, a remote access service exposed to the internet, an unpatched edge device, a vendor connection. The first priority after arrival is a second way in, so that closing the first one does not end the intrusion. That often means a legitimate remote access tool installed as if IT had deployed it, a new account, or an added authentication method on an account that already exists.

They learn the environment before touching anything. They enumerate domains, shares, admin groups, servers, and what your security tooling is. They are reading your network the way a new systems administrator would, because functionally that is what they are doing. This phase is not noisy in the way malware is noisy.

They go after identity, not data. The target is administrative control. Credentials cached on a compromised machine, a service account with far more privilege than its job requires, a helpdesk workflow that will reset a password for a convincing caller. Once they hold a privileged account, everything after that looks like authorized activity, because it technically is.

They find your backups, and they find them early. This is the part that surprises people. A competent operator treats your recovery capability as the primary obstacle and deals with it deliberately, before anything visible happens. Backup consoles, backup service accounts, snapshot retention settings, and replication targets are among the first things they look for.

They take data out. Copying data before encrypting it converts a recovery problem into a disclosure problem. Restoring cleanly no longer removes the leverage, because the threat has shifted to publishing what they took. This is why "we restored from backup" and "the incident is over" are not the same sentence anymore.

Then, and only then, they encrypt. Usually at a time chosen for minimum staffing, and usually across as many systems at once as they can reach, because a staggered rollout gives you a chance to respond.

Dwell time is the variable that matters

Dwell time is how long an intruder is in your environment before anyone notices. In a human-operated case, the encryption event is the end of the dwell period, not the beginning of the incident.

I am deliberately not giving you an average number here, and the reason is worth more than the number would be. Dwell time is decided by how long it takes the operator to accomplish specific objectives against your specific environment - and, more to the point, by how long your own monitoring lets it run. A business that reviews authentication anomalies daily and a business that discovers intrusions when the ransom note appears do not share a dwell time in any meaningful sense. The figure you should care about is not the industry's; it is yours, and it is set by how long something abnormal could run in your network before a person looked at it.

What is worth internalizing is the shape of the thing rather than the figure. The dwell period is when the damage is actually done - the access is broadened, the backups are dealt with, the data leaves. Every hour of it is an hour where detection was still possible and cheap. By the time you see the ransom note, you are past the point where anything cheap is available.

Living off the land, and why your tools stay quiet

Operators overwhelmingly prefer tools that are already installed and already trusted. Remote management software, PowerShell and the Windows scripting stack, native administrative utilities, scheduled tasks, remote desktop, the administrative shares. Where they bring their own tooling, it is often a commercial remote access product or a legitimate penetration-testing framework rather than anything a signature would flag as malicious.

The reason is simple: none of it is malware, so none of it looks like malware. Antivirus is answering the question "is this file bad?" and the honest answer is no. The file is fine. The administrative account is real. The remote session is properly authenticated.

The question that would catch it is different: is this normal? A domain administrator account authenticating from a workstation it has never used, at an hour that account never works, enumerating shares it has never touched, is not a bad file. It is a bad pattern. Tools that only evaluate files cannot see it.

This is also why "we have antivirus" is not an answer to this threat, and why the extra cost of behavioral detection is not a vendor upsell. They are answering different questions.

Why backups alone do not save you

Backups defeat commodity ransomware convincingly. Against an operator who has had weeks in your environment, three things break the assumption.

They found the backups. Not through luck. They looked, because it is the obvious first move, and if your backup console is reachable with the same domain administrator credentials that unlock everything else, it is not a separate line of defense. It is another system in the blast radius. Backups survive when they cannot be deleted by any credential available inside the production environment - offline, immutable, or in an account with a genuinely separate authentication path.

The clean point may be behind them. If the intrusion started long before encryption, some of your recovery points contain the intruder's access. Restoring blindly can restore the problem. Determining how far back to go requires knowing when they arrived, which requires logs that go back at least that far.

Backups do not address the copy they took. Restoration solves availability. It does nothing about disclosure, about notification obligations, or about what the data being published means for your customers and contracts.

A restore capability is necessary. It stopped being sufficient the moment operators started reading the same recovery documentation your IT team reads.

What detection and response actually has to look like

Everything above points at the same conclusion: the only cheap outcome is the one where you interrupt the operator during the dwell period. That imposes concrete requirements.

Detection has to be behavioral and identity-centric. Watch for authentication that is legitimate but abnormal, privilege changes, new accounts, new authentication methods on existing accounts, remote access tooling appearing where it was never deployed, and administrative enumeration from unusual sources. Endpoint detection that records process behavior, not just file verdicts, is the baseline.

Someone has to be watching outside business hours. Operators choose nights, weekends, and holidays precisely because an alert that no one reads until Monday is not a control.

Logs have to survive and reach back far enough. If retention is shorter than the plausible dwell period, you cannot answer when the intrusion started, which means you cannot pick a safe restore point or bound what was accessed. Logs also have to be somewhere the operator's credentials cannot reach, because clearing them is standard practice.

Containment has to be practiced, and it has to be identity-first. Pulling network cables does not help when the persistence is a valid account and a cloud-hosted remote access tool. Containment means disabling accounts, revoking active sessions and tokens, rotating credentials including service accounts, and isolating systems - decided in advance, because deciding it at two in the morning goes badly. Walking through it once, in a room, before it happens is the highest-return hour in this entire subject.

Recovery has to assume the environment is hostile until proven otherwise. Restore into a known-clean environment, rotate every credential that existed during the intrusion, and verify that the way in is closed before reconnecting anything. Restoring a system while the operator still holds valid administrative credentials simply gives them a fresh copy to encrypt.

The judgement call underneath all of this

The uncomfortable implication is that prevention has a ceiling. Against a motivated operator with time, some initial access is going to succeed eventually - a credential, a vendor, an unpatched edge device. What determines whether that becomes a bad week or an existential event is entirely the middle of the timeline: whether anyone notices during the dwell period, and whether the recovery capability survives contact with an adversary who was specifically looking for it.

Spending that is concentrated at the perimeter and at the restore button leaves the middle unwatched. That middle is where these incidents are actually won or lost. If you want a structured read on which parts of your own middle are uncovered, our security self-check is a reasonable place to start, and the first hour of an incident covers what to do if you are already past the theory.