Why do we keep getting hit by ransomware, and how do we stop it for good?

Recovery answers "is the data back?". Incident response has to answer "is the attacker out, and can they get back in?". Environments that keep getting hit are almost always stuck on one or more of the following.

The entry point was never found - or the wrong one was. The route reused is usually the same one: remote desktop and database ports exposed to the internet, VPNs without MFA, and edge devices or public applications left unpatched; the full list is under "most common entry points" in our FAQ. Subtler is closing the wrong door: the case is closed as a weak password and the password changed, while the real way in was a flaw in business software or an edge device. The Guanjiapo port 211 attack chain published in 2026, for example, leaves no anomalous logon in SQL Server's login audit (see Guanjiapo or Suda account sets encrypted).

Persistence was not fully removed. An attacker's first priority after getting in is often not encryption but making sure they can come back. Microsoft lists new backdoor accounts, local or in Active Directory, and legitimate remote management tools such as AnyDesk, TeamViewer and Splashtop among common persistence methods, and 360's April 2026 report documents some Weaxor builds brute-forcing a database, planting AnyDesk, and then deploying ransomware by hand. A joint advisory from CISA, the NSA and MS-ISAC notes that actors from cybercriminals to state-sponsored groups use legitimate remote monitoring and management software as a backdoor for persistence and control - and because it is not malware, antivirus will not flag it. The same goes for scheduled tasks, services, Group Policy scripts and web shells in site directories; long-dwelling remote access trojans such as Silver Fox can also be used to drop ransomware later.

Credentials were not all rotated. Attackers routinely harvest credentials from memory and dump password hashes, taking far more than the password of the machine that was encrypted. Change only the administrator password, and service accounts, the database sa account, VPN logins, third-party support accounts and browser-saved passwords are all still the old ones. In a domain where the attacker held domain administrator rights and krbtgt was not rotated properly, forged Kerberos tickets remain valid.

Systems were restored from backdoored backups. There is usually a dwell period between entry and encryption, and full-system backups, VM snapshots and images taken during it contain the backdoor accounts, scheduled tasks and remote-access tools. Rolling back to "the latest" full backup restores the foothold along with everything else.

Either is possible, and it does not have to be one or the other.

The same crew returning. An organisation that has been attacked - and especially one that paid - has already shown it can be entered and will pay. Public surveys point the same way:

These are questionnaire surveys of respondents outside China and cannot be mapped directly onto any one organisation, but the conclusion is plain: paying does not buy safety - see should we pay the ransom.

Access resold or shared. The ransomware economy is highly specialised. Microsoft describes access brokers who compromise exposed weak-password RDP and unpatched systems en masse and "bank" them for later sale, and ransomware-as-a-service affiliates who switch between payloads and, if not successfully evicted, sometimes monetise the same network again with different malware or ransomware. The FBI's September 2023 industry notification documented "dual ransomware attacks": two different ransomware variants deployed against the same victim within 10 days, most of them within 48 hours of each other.

So a different ransom note the second time does not mean the original problem was solved, and an identical one does not mean it is merely the first attack finishing. For the defender the conclusion is the same: until the entry point, persistence and credentials are dealt with, anyone can come back in.

When the first investigation missed the entry point, the usual reasons are that hosts were reinstalled before evidence was taken, logging was off or retention too short, only the encrypted machine was examined, or the most plausible entry point was written up as fact. A second incident is, perversely, an opportunity: what the two attacks have in common is often the real way in.

Three things matter most:

• Trace the timeline back from the second incident. Find the earliest anomalous logon or exploit request and establish whether it came before or after the previous recovery. Before means the attacker never left; after means the entry point stayed open or credentials had leaked.
• Line up network and host evidence. Align firewall port-forwarding and VPN logs, remote logon events in the Windows security log (4624 / 4625), web access logs, database error logs and EDR alerts by time to pin down the first account and source.
• Inventory every path to the machine. Not only internet-facing ports but third-party support channels, remote-access tools, compromised endpoints on the same segment and vendor accounts.

Where evidence is insufficient, the report should say "undetermined" and every plausible entry point should be dealt with, rather than closing the case on the likeliest one. That is how our forensics work is written up: conclusions are labelled confirmed, highly likely or undetermined.

The deciding question is what privileges the attacker held, and whether cleanliness can be proven - not how inconvenient a rebuild would be.

When restoring, restore data rather than systems wherever possible: load databases, files and necessary configuration onto freshly built systems instead of rolling back full-system backups or VM snapshots taken after the intrusion began. Where a full rollback is unavoidable, use the forensic timeline to confirm the backup predates the first intrusion, then inspect its accounts, scheduled tasks, services and remote-access tools in an isolated segment.

For recovery order and route selection when domain controllers fell, see domain-wide encryption.

Two preconditions. Change credentials only after the entry point is closed and persistence removed, or the new passwords will simply be stolen again. And work from a device confirmed to be clean, never from a machine that may still be watched. CISA's #StopRansomware Guide likewise advises resetting passwords for all affected systems once the environment has been fully cleaned and rebuilt.

Suggested order:

1. Top-privilege accounts: domain administrators, enterprise administrators and break-glass accounts, removing unexpected members from administrative groups at the same time.
2. krbtgt: reset twice per Microsoft's forest recovery guidance, waiting longer than the maximum ticket lifetime between resets (10 hours by default), so tickets the attacker forged or stole stop working.
3. Service accounts: those used by databases, backup software, virtualisation platforms, ERP and application connection strings - verifying each business function after the change.
4. Local administrators: random and unique per machine (a LAPS-style solution works), with no reuse.
5. Remote access and edge devices: VPN, remote desktop, firewall and switch management passwords, plus accounts and device authorisations for remote-access tools.
6. Third parties and external platforms: outsourced support and vendor accounts, cloud consoles, corporate mail, domain registrar and DNS management.
7. Every user: forced password change with MFA enabled, and departed or dormant accounts disabled.

A small business without a domain can compress this to: Windows administrator, database sa, remote desktop and remote-access tool accounts, router and firewall, business software admin, then mail and online banking. The principle does not change.

The five things to finish shortly after recovery - rotate every credential, close unnecessary internet exposure, enforce MFA on remote access, confirm backdoors are gone, rebuild an offline backup and test-restore it - and how to tell whether hardening really took effect are already covered in our FAQ, so they are not repeated here. An environment that keeps getting hit needs three things on top:

• Verification, not "it was configured". Confirm from the internet that ports are genuinely closed, test MFA channel by channel, and spot-check patch versions and service restart times. Many second incidents trace back to something everyone believed was already shut.
• Watching for the return. Attackers who come back usually log in before they encrypt. Alert on, and name someone to review daily: new accounts or administrator group changes, remote logons out of hours or from unfamiliar sources, new services and scheduled tasks, remote-access tool installs or outbound connections, shadow copy deletion, security software being disabled, and unusual bulk outbound traffic.
• Backups designed for a next time. At least one offline or immutable copy, backup credentials isolated from production, and restore points reaching back far enough - to before the first intrusion.

Structured exposure reduction, account governance and item-by-item verification are what security hardening delivers. We report each item's status and test result; we do not promise hardening makes you immune, but it means a next incident does not leave you without options.