One click, fifty days, then ransomware: why long dwell rewrites the response

The ransomware alert fires today. You trace it back and the intrusion started fifty days ago, with one click on a fake software installer. Nearly two months of access sat between the click and the encryption. That gap is the whole story, and it changes what your job actually is.

The reflex when ransomware detonates is to scope from the alert: isolate what is encrypting, kill the encryptor, restore from backup. On a long-dwell intrusion that reflex leaves the attacker inside. The loud event is the end of the intrusion, not the beginning, and everything that lets the actor come back was planted at the start.

How it works

The entry is mundane. A user searching for a common installer clicks a malvertising or SEO-poisoned result and runs a signed-looking loader (T1566, Phishing). A short scripting-interpreter payload executes on the endpoint (T1059, Command and Scripting Interpreter). It looks like a one-off with no immediate impact.

On day zero, before going quiet, the loader does the work that matters. It creates a Windows service and a scheduled task for persistence (T1543, Create or Modify System Process, and T1053, Scheduled Task/Job), and it dumps cached credentials from the host (T1003, OS Credential Dumping). Then the host goes dark. For weeks the implant beacons intermittently and does occasional discovery, blending into normal traffic.

Roughly fifty days later the actor comes back. Using a credential harvested on day zero, they authenticate over remote services to a file server and a domain controller (T1021, Remote Services), stage an encryptor to a share, and detonate it (T1486, Data Encrypted for Impact). The credential is old, so the lateral movement does not look like a fresh compromise. The encryption is the first genuinely loud alert, fifty days after the click that started it.

Why two months changes the response

Dwell time inverts the responder’s job. On a fast intrusion you are stopping activity that is happening now. On a long-dwell intrusion the current activity is the least of it. The persistence and the stolen credentials that will let the actor walk back in were established seven weeks before you ever saw an alert.

Two consequences follow. First, scoping is retrospective. You cannot start from the ransomware and work forward, because the foothold you need to remove predates it by weeks. You have to rebuild the timeline back to day zero and find what was planted then. Second, seven weeks is a long time for a patient actor to branch. Nobody keeps a single foothold live for fifty days and hopes it survives. Expect redundant persistence and credentials staged on more than one host.

And there is a quieter problem that only long dwell exposes. If your EDR keeps thirty days of telemetry and the intrusion is fifty days old, the beginning of the intrusion is already gone from your logs. Retention shorter than the dwell is not a minor inconvenience. It is a critical evidence gap, and how you treat it decides whether your scoping is honest.

How to detect it

The individual events are quiet by design: a short script on day zero, a service and a scheduled task that look like software, sparse beacons, and one aged credential used to log in weeks later. None of them screams.

So the detection that matters is correlation over time, not a single loud alert. A scripting-interpreter payload spawned right after a browser download, followed minutes later by a new service and scheduled task on the same host, is the day-zero signature. Later, a remote logon to a domain controller or file server using a credential that was touched during a prior suspicious event is the tell that an old foothold is waking up. When the ransomware does fire, the first question is not how many hosts are encrypting. It is when the intrusion actually started, because that defines the real blast radius.

How to contain and shut it down

This is where scoping from the alert fails. Isolating the encrypting hosts and deleting the encryptor stops today’s damage and feels like containment. It is not. The service, the scheduled task, and the credentials planted on day zero are still live, and the actor re-enters through them the moment you restore.

Containment on a long-dwell intrusion means removing the beginning, not just the end:

• Stop the current encryption, then sweep the whole estate for the day-zero persistence: the loader’s service and scheduled task, and any redundant footholds a seven-week dwell allowed.
• Rotate every credential the loader could have harvested at the start, not just the phished user’s. Assume the credential set is burned.
• Reconstruct the timeline back to day zero across every source that reaches that far, and where log retention is shorter than the dwell, record it as an evidence gap. Missing telemetry is an unknown, not an all-clear. “Not seen” is not “did not happen” when you lack the logs to have seen it.
• Recover from a backup that predates day zero, or rebuild. The most recent backup is the most likely to contain the loader’s persistence, so restoring the freshest copy just reinstates the intrusion. Reconnect only after eviction and credential rotation are real.

Then scope the business impact honestly. Seven weeks of access to data and credentials, much of it beyond log retention, is exposure you cannot fully prove either way. Obligations follow the plausible reach of a seven-week foothold, not just the encrypted systems, and the retention gap is unquantified risk to disclose and manage conservatively, not to dismiss.

Practice it

We built this as a scenario in GraphLattice Range: a single-click loader that plants persistence and harvests credentials on day zero, goes low-and-slow for weeks, then moves laterally with an aged credential and detonates ransomware. It forces the non-obvious call under time pressure. Scope from the loud alert and feel contained, or recognize the intrusion is fifty days old and scope the whole dwell, remove the early footholds, rotate the burned credentials, and flag the retention gap. Teams that make that call in a drill make it faster when it is real.