All solutions Solution · Ransomware

Ransomware: the chain, not the single tool

Between the first alert and disconnecting the affected machine lies the time in which the damage is decided. This page shows which steps have to interlock, and where they sit in isidaten.

Request a demo
Close-up of a patch panel: numbered ports, blue and grey network cables
Background

What Ransomware requires

An encryption attack rarely fails because of a single product and rarely succeeds because of a single omission. It runs in phases, and each phase has its own window: access is established days or weeks before encryption, lateral movement takes hours, the encryption itself minutes. Anyone looking only at the last phase always arrives too late. The four steps below are therefore not a product list but a checklist: for each step it should be answerable who performs it, with what, and how long it takes.

Detect early, before encryption starts: an attacker moves through the network before striking. That is the largest usable window.Detect where no Windows events occur: encrypting files in SharePoint or OneDrive leaves no trace on your own network.Contain in minutes, not hours: the path from alert to a disconnected host must not run through three consoles and a callback.Control the intervention itself: disconnecting a machine or locking an account interferes with people’s work. That needs a second person and a log.Preserve evidence before it is overwritten: what is needed for notification and for filing a report arises in the first hours or not at all.Verify the recovery instead of hoping: systems go back online because operations are pressing. Only afterwards does it show whether the backup was clean.Be able to notify while the deadline runs: NIS2 and GDPR count in hours, not days.
How isidaten helps

How isidaten maps Ransomware

Each requirement meets a module that runs on the same object base as the risk register, so the evidence stays connected instead of copied across tools.

Early warning without false positives

Decoy files in shares and user profiles, honeytoken accounts in the directory and decoy hosts with emulated services. A decoy has no operational purpose, so the question of whether the alert means anything does not arise.

View module: Deception – Early Warning

Detect mass encryption

The file activity watch evaluates how many files change in what time, and reacts to the patterns an encryption wave leaves behind. Governance comes first: the module stays locked until a legal basis is documented.

View module: UEBA

Correlate events, including from the cloud

File events from the Windows log and the unified audit log from Microsoft 365 feed the same metrics. Without the second source, detection stops at the edge of your own network.

View module: SIEM Integration

Isolate a host, lock an account, end a session

The intervention is created on the incident, waits for a second person’s approval and is logged. It is executed via your own agent or through connectors to the directory service and endpoint protection.

View module: Containment Actions

From alert to action, without a phone call

A rule chain connects the decoy alert to the incident and the containment action. Automated requests are throttled and still require an approver: the rule and the human are the two pairs of eyes.

View module: Security Automation

Act on the device

Quarantine via the local firewall leaves only the connection to the platform, so the machine can be released remotely later. The harder mode disables the network adapter and requires an on-site visit.

View module: Client Management

Emergency operation and recovery

The business impact analysis provides how long each process may be unavailable, and the recovery plans the order. Without those figures, the question of what returns first is a question of who shouts loudest.

View module: Emergency Management (BCM)
FAQ

Frequently asked questions

Does this replace endpoint protection?

No, and it does not try to. isidaten does not detect on the endpoint but through decoys, file activity and logs, and it orchestrates the intervention. Defender, CrowdStrike and SentinelOne are connected as the executing hand, not replaced: isidaten issues the isolation through their API and lifts it there again. Their own detections are not evaluated by isidaten; those stay in the respective console.

How fast does an account lockout actually take effect?

More honestly than the marketing: a lockout in Active Directory does not revoke Kerberos tickets; an active session continues until they expire, typically up to ten hours. Entra ID takes several minutes to apply everywhere. Anyone who has to cut immediately additionally isolates the host or ends the session.

What happens if the wrong machine is isolated?

Two safeguards come first. If the device lookup finds no match or more than one, the action aborts and states the number instead of guessing. And every action can be reverted; the reversal needs its own approval and only counts as done once the device has acknowledged it.

Do we need every module in this chain?

No. The chain works in stages. Having only early warning and incident documentation already buys the most important time. Containment is the step that brings response time from hours to minutes, and recovery the one that prevents the second outage.

What about the notification duty?

It hangs on the same incident. The notification chains for NIS2 and for a personal data breach under GDPR draw on its data, and the containment timestamp set by the containment action is one of the details that gets asked for.

Ready to simplify your compliance?

Schedule a no-obligation demo and experience isidaten with your own use cases – personally and without commitment.