The doors have not changed

Ransomware coverage tends to focus on what happens after the intrusion — the encryption, the negotiation, the recovery. For a defender, the more useful question sits earlier: how did they get in? Strip away the branding of individual crews and the answer is remarkably stable. Year after year, the overwhelming majority of ransomware incidents begin with one of five initial-access paths, none of which is new and none of which requires a zero-day.

That stability is good news, if you treat it correctly. Five doors is a defensible perimeter. But each door stays open for a specific, structural reason — and closing it takes more than a policy line saying it is closed. This guide walks through each path: why it still works in 2026, what breaking it actually costs, and how to know — rather than hope — that it is shut.

Path 1: Exposed remote access services

Remote desktop, SSH, VNC, and remote-support tools reachable directly from the internet remain the bluntest way in, and they remain everywhere. Access brokers scan the entire address space continuously; anything answering on a remote-access port gets a login attempt within hours of appearing, and a working credential for it has resale value.

Why it still works: exposure is rarely a decision anyone made. It is a firewall rule opened for a contractor and never closed, a server restored from backup with an old configuration, a cloud instance whose security group was copied from a template. The organisation's diagram says nothing is exposed; the internet says otherwise. And because the exposure appeared without a decision, no review process ever looks at it.

What breaking it takes: an outside-in inventory — what an attacker's scanner sees, not what your asset register claims. Remove direct exposure entirely: remote access goes behind a gateway that requires strong authentication, with account lockout and logging at the front door. Then accept that exposure recurs. A port closed today can reappear next quarter with one change ticket, so the outside-in check has to repeat, not run once.

Path 2: Phished credentials without phishing-resistant MFA

Credential phishing did not die when organisations rolled out multi-factor authentication. It adapted. Modern phishing kits proxy the real login page in real time, capturing the password and the one-time code together, or they simply trigger push prompts until a tired employee approves one. A factor that a user can read out, type in, or approve can be phished along with the password.

Why it still works: "we have MFA" usually means "we have MFA on some systems, for some users, in some form". The gaps are predictable: a legacy protocol that bypasses it, a service desk that resets it over the phone with soft identity checks, an application that was excluded during rollout and never revisited. Attackers do not attack your MFA; they route around it through the exceptions.

What breaking it takes: phishing-resistant factors — hardware-bound passkeys or security keys — on the accounts that matter most: remote entry points, administrative access, and email. Disable legacy authentication paths that skip MFA entirely. Harden the reset process, because a factor that a helpdesk will replace for a convincing caller is only as strong as the call script. Awareness training helps at the margins, but readiness means assuming some credentials will be phished and making the stolen credential useless on its own.

Path 3: Unpatched edge appliances

VPN concentrators, firewalls, mail gateways, and file-transfer appliances have become a favourite way in, for a simple reason: they sit on the perimeter by design, they authenticate everyone, and when a vulnerability in one is published, working exploitation typically follows within days. The window between advisory and exploitation is now shorter than most organisations' standard patch cycle.

Why it still works: appliances live outside the normal patching machinery. They are not covered by the endpoint management that patches workstations, they cannot run the agents that would detect compromise, and ownership is often split between a network team that operates them and a security team that reads the advisories. An appliance can be missed for months precisely because it belongs to everyone and no one.

What breaking it takes: treat edge devices as their own patch class with an emergency lane measured in hours, not weeks. That requires an exact inventory — every appliance, model, and firmware version — a subscription to each vendor's advisories with a named owner, and pre-agreed maintenance authority so an out-of-cycle reboot does not need a committee. Restrict management interfaces so they are never internet-reachable, and retire end-of-life appliances rather than leaving them running because they still route packets.

Path 4: Trusted vendor and third-party access

Every organisation of size has standing remote access for suppliers — a software vendor, a facilities contractor, a managed service provider. That access is a door with your trust already attached to it, and when the vendor is compromised, the attacker inherits the trust. Increasingly, crews do not attack the target at all; they attack whoever already has a tunnel into the target.

Why it still works: vendor access is provisioned for convenience and reviewed by nobody. The connection frequently lands on a network segment that can reach far more than the vendor's own system. The account is often shared among the vendor's staff, exempt from MFA "because their tooling doesn't support it", and permanent because removing it might break a support contract. The result is an employee-grade foothold with no employee accountable for it.

What breaking it takes: segmentation first — vendor entry points should reach the systems the vendor services and nothing else, enforced by rules, not assumption. Then identity: named accounts per person, strong authentication at the seam, access that is enabled for a support window and disabled after it, and session logging you actually review. Finally, offboarding: when a contract ends, the tunnel ends the same week, in the same ticket.

Path 5: Re-used and sprayed credentials

The least sophisticated path remains one of the most reliable. People re-use passwords between personal and corporate accounts, breach corpuses circulate freely, and password spraying — a handful of seasonal guesses tried gently across every account to stay under lockout thresholds — still lands hits against any sizeable user base.

Why it still works: defences are built around the single noisy attacker hammering one account, while spraying is quiet and wide. Lockout policies protect the primary login portal but not the forgotten authentication endpoint — the legacy webmail path, the API that accepts basic credentials, the appliance login nobody monitors. And service accounts, whose passwords predate the current policy by years, are exempt from all of it.

What breaking it takes: screen passwords against known-breached lists at creation and on a cycle, not just at onboarding. Give every internet-facing authentication endpoint — including the obscure ones — the same throttling, lockout, and monitoring as the main portal; attackers inventory your login surfaces more thoroughly than most defenders do. Vault service-account credentials, make them unique per system, and rotate them. And once more, a second factor at the entry seam turns a correctly guessed password from a foothold into a log entry.

Readiness is a test result, not a policy

Every organisation that suffered a ransomware incident through one of these five paths had a policy that said the path was closed. The exposure survived anyway, because environments drift: a rule gets added, an appliance gets stood up, an exception gets granted, an offboarding gets missed. Paper describes intent. Attackers test reality.

So readiness should be established the way an attacker would establish it — by attempting the paths and recording what happens. In practical terms, that means being able to answer five questions with evidence rather than assurance:

  • What remote access is actually reachable from the internet right now — and does any of it accept a password alone?
  • If a user's credentials are phished today, what do they open? Which entry points would a stolen password plus a relayed code get through?
  • Which edge appliances are running exploitable firmware, and how long has that been true?
  • From each vendor's entry point, what can be reached beyond the system the vendor is contracted to touch?
  • Which accounts accept a known-breached or sprayable password, on which endpoints?

These are testable claims, and testing them safely against production is exactly what continuous assessment is for. FireShield's CloudShark engine attempts these routes the way an attacker would — from the outside, with evidence recorded at every hop — and when a path is found, the fix is re-tested until the route demonstrably no longer works. That converts "we believe the door is closed" into a timestamped result, and because the checks run continuously, a door that drifts open again is found by your assessment, not by an access broker.

Ransomware readiness is not a binder, a tabletop, or a renewal questionnaire. It is the current, verified state of five doors. Know that state, keep knowing it, and the most common way this story starts becomes a story about somebody else.