The 90 days after a ransomware attack are more dangerous than the attack itself.

The most dangerous moment in a ransomware event is not the morning the screens go red. It is roughly 60 days later — when the rebuild is done, the invoices are paid, the insurance claim is closed, and everyone in the company has quietly agreed to stop talking about it.

That is when the second attack hits.

We have walked into this exact pattern more times than we would like to count. A business near Charlotte gets hit, scrambles for help, restores from backup or pays the ransom, gets the lights back on, and then six to ten weeks later something feels off again. Logins from somewhere weird. An account locked out at 3 a.m. A finance person notices a wire that did not match the request. The attackers never left.

Why the post-recovery window is so dangerous

Three things converge after the rebuild, and none of them work in the defender's favor.

1. The hole that let them in is usually still there.

Most ransomware events start with one of a small handful of root causes: a compromised credential, an unpatched edge device (VPN, firewall, RDP), or a phishing-driven session hijack. The incident response team's job is to get you operational, not to permanently fix the root cause. Unless someone explicitly closes the original entry point, the next attacker (or the same one) walks through the same door.

2. Attackers leave persistence behind on purpose.

Modern ransomware crews are not single-skill operators. The group that encrypts your files is often the last team in a chain — the initial access broker who sold the entry, the operator who explored your network for two weeks, the affiliate who deployed the encryptor. By the time you are restoring backups, multiple footholds have already been planted: extra local admin accounts, scheduled tasks, RMM agents, web shells on internet-facing servers, OAuth tokens for cloud apps that survive password resets.

CISA's #StopRansomware advisories repeatedly call out persistence mechanisms as standard tradecraft — not a sophisticated extra (CISA #StopRansomware).

3. Attention drops just as defensive posture should be highest.

In the first two weeks after a breach, everyone is paying attention. By week eight, the CFO wants the consultant invoices to stop and the operations team is back to its normal queue. Logging is on, but nobody is looking at it. Alerts come in, but they get acknowledged, not investigated.

Attackers know this rhythm. The dwell-time data backs it up. IBM's Cost of a Data Breach reports have consistently put average breach identification at over 200 days — and post-recovery reinfections are a meaningful slice of that long tail.

What persistence actually looks like in an SMB

You do not need a state-sponsored threat actor to leave a foothold. The techniques are mundane. The reason they survive is that defenders rarely look for them after the lights are back on.

• Extra local admin accounts. Named something forgettable — svc_backup, helpdesk2, winupdate. Created during the intrusion. Survives the rebuild because IT is focused on user accounts, not service accounts.
• Scheduled tasks and run keys. Calling back to a command-and-control server every few hours, often on a long jitter so they do not look anomalous.
• Legitimate RMM tools. ConnectWise ScreenConnect, AnyDesk, Atera, TeamViewer — installed by attackers because they blend in with normal IT software. The CISA advisory on living-off-the-land techniques calls these out specifically (CISA AA24-038A).
• OAuth and refresh tokens in Microsoft 365 or Google Workspace. Password resets and MFA changes do not revoke these. An attacker who consented to a malicious app or stole a session token can persist in your tenant indefinitely until those grants are explicitly killed.
• Modified firewall and VPN configs. Extra port forwards, a new VPN user, a tweaked ACL allowing inbound from an attacker IP range. Easy to miss in a rebuild because most teams restore configs from the device, not from a clean known-good baseline.
• Backdoored backup or restore scripts. Attackers know you are going to run them. Modifying a recovery script is one of the highest-leverage persistence techniques against an SMB.

The 90-day defense plan most SMBs skip

This is the work that almost never happens after a ransomware event because it is not glamorous and it is not part of the rebuild contract. It is also the difference between a one-time incident and a recurring nightmare.

Days 1–14: stabilize, but assume compromise persists.

• Reset every password and rotate every secret — not just user accounts. Service accounts, API keys, SaaS admin credentials, certificate private keys.
• Revoke all OAuth grants and active sessions in Microsoft 365 / Google Workspace. Use Revoke-AzureADUserAllRefreshToken or the equivalent admin actions.
• Force re-enrollment of MFA. Do not trust existing factors.
• Rebuild domain controllers from clean media. Restoring an infected DC from backup just reinstates the foothold.

Days 15–45: hunt, do not just monitor.

• Deploy or verify EDR on every endpoint and every server — including the ones nobody touches like the conference-room PC.
• Run a structured threat hunt focused on persistence: scheduled tasks, services, run keys, WMI subscriptions, new local accounts, unexpected RMM installs.
• Audit firewall, VPN, and identity-provider configurations against a known-good baseline. Diff line by line.
• Review all conditional-access and sign-in logs for the prior 90 days for anomalous geographies or impossible travel.

Days 46–90: prove it is clean and harden against round two.

• Have a third party do a compromise assessment. The team that did your IR is too close.
• Patch the original entry point and the next one. If it was a phished credential, that means phishing-resistant MFA, not just regular MFA. If it was an unpatched VPN, that means an actual patch process, not just a one-time fix.
• Move backups to an immutable / air-gapped destination. If the attacker comes back, the next encryption attempt should hit a wall.
• Run a tabletop exercise on a different scenario. Most SMBs harden against the last attack and stay open to the next one.

What WHT recommends

If you are inside this 90-day window right now — whether you are 2 weeks out or 8 weeks out — the order of operations matters more than which tools you pick.

1. Assume persistence until proven otherwise. Default position is that the attacker still has at least one foothold. The hunt is to disprove that, not to prove it.
2. Get a second set of eyes that is not your IR firm. IR firms are excellent at containment and recovery. They are less incentivized to find the second backdoor — because finding it extends the engagement and complicates the closeout.
3. Make EDR and 24/7 monitoring non-negotiable for the next 12 months. If the attackers come back, you want them tripping an alarm at 3 a.m. that someone is paid to investigate.
4. Treat insurance renewal like a deadline, not a date. Carriers are going to ask hard questions about what changed. Have documented answers: new MFA, EDR, immutable backups, IR plan, training cadence.
5. Schedule a 90-day-out checkpoint before you exit the incident. Put it on the calendar the week of recovery. The whole point is that nobody remembers to do this on day 89 if nobody booked the meeting on day 5.

The bottom line

The fact that you got the lights back on does not mean you got the attackers out. Those are two different jobs, and the second one is usually skipped because everyone is exhausted by the time it is supposed to start.

If your business was hit in the last 90 days — or you are advising someone whose was — the highest-leverage thing you can do this quarter is hunt for what was left behind. Not patch the last hole. Hunt for the next one.