Ransomware is not primarily a malware problem. It is an infrastructure access problem. The malware is the final step in an attack chain that starts much earlier — with an exposed port, an unpatched service, a weak credential, or a flat network that offers no resistance to lateral movement. Fix the infrastructure, and ransomware either fails to get in or fails to spread far enough to matter.
At Solvanta, a meaningful share of the security work we do is with organisations that called us after a ransomware incident, or organisations that decided they would rather not find out what that experience feels like. The patterns are consistent enough to be predictable — and preventable.
How Ransomware Actually Enters
The three most common entry points we see are exposed remote access, phishing-delivered credentials, and unpatched public-facing services. Each of these is an infrastructure failure before it is anything else.
Exposed RDP and remote access services. Remote Desktop Protocol on port 3389 is one of the most scanned ports on the internet. Brute-force tooling runs continuously against any exposed RDP service, and credential stuffing attacks use previously leaked password databases. An organisation that exposes RDP to the public internet without MFA, IP allowlisting, and account lockout policies is operating a permanently contested entry point. The same applies to unprotected SSH, VNC, and web-based admin panels.
Phishing and credential theft. Most enterprise ransomware campaigns begin with a phishing email that delivers either malware or a credential harvester. Once an attacker has a valid set of credentials, they authenticate legitimately — which means no malware signature to detect, no exploit to block. They are simply a user who logged in. The infrastructure defence here is making stolen credentials as useless as possible: MFA on all remote access, short session lifetimes, and network segmentation that limits what any single credential can reach.
Unpatched services. High-profile ransomware campaigns have repeatedly weaponised known vulnerabilities in VPN appliances, firewall management interfaces, and web-facing applications. These are not zero-day exploits — they are vulnerabilities with public CVEs and available patches. The organisations that got hit simply had not patched them. Maintaining a patched, minimal attack surface is unglamorous work, but it eliminates entire attack categories.
Why Ransomware Spreads: The Flat Network Problem
Getting ransomware onto one machine is serious. Getting it onto every machine in an organisation is catastrophic. The difference is almost entirely determined by network architecture.
In a flat network — where every system can reach every other system on the same subnet — ransomware can enumerate and encrypt accessible file shares, database servers, and backup systems from a single compromised host. This is not a theoretical risk; it is exactly what happens in most major incidents.
Network segmentation changes this equation. When workstations cannot directly reach database servers, when the backup network is isolated from the production network, when administrative access requires jumping through a hardened bastion host, a compromise on one segment stays on that segment. The attacker has to break through additional controls to move laterally — and those additional steps generate additional detection opportunities.
DMZ architecture, VLAN segmentation, and strict inter-segment firewall rules are not exotic security measures. They are standard infrastructure practice that most organisations simply have not implemented because nobody prioritised it until after an incident.
Backups Are Only a Recovery Plan If They Are Isolated
The ransomware groups that maximise their leverage do one thing before they detonate their payload: they find and destroy the backups. If your backup system is reachable from the same network as your production systems — mounted as a network share, accessible with the same credentials, running the same backup agent that can be targeted — it will be encrypted along with everything else.
An effective backup architecture for ransomware resilience requires three things:
- Isolation: Backup storage must be on a network segment that production systems cannot write to or delete from. The backup system pulls from production; production does not push to backups.
- Immutability: Object storage with object lock (S3-compatible with WORM policy) or append-only backup targets prevent modification or deletion of existing backups even if the backup agent is compromised.
- Tested restores: A backup that has never been restored from is an untested hypothesis. Monthly verified restore tests confirm that your backups actually work — before you need them at 3am after an incident.
With isolated, verified backups in place, a ransomware incident becomes a recovery exercise rather than a business-ending event. RTO and RPO targets that seemed abstract become the actual numbers your team executes against.
The Infrastructure Hardening Checklist
Most ransomware incidents we investigate could have been prevented by a combination of the following controls, none of which require exotic tooling:
- No RDP, SSH, or admin panels exposed directly to the internet without MFA and IP restrictions
- Firewall rules with deny-all defaults and explicit allow rules per service and source
- Network segmentation separating workstations, servers, databases, and backup infrastructure
- Patch management with tested, automated deployment of security updates
- Privileged access limited to dedicated admin accounts, not day-to-day user credentials
- Backup infrastructure isolated from production with verified restore testing
- Centralised logging and alerting on authentication anomalies and lateral movement indicators
This is not a complete security programme. It is the infrastructure baseline that makes a ransomware attack significantly harder to execute and significantly less damaging if it partially succeeds.
What We Do After an Incident
When we are engaged after a ransomware incident, the first priority is containment and evidence preservation, not immediate recovery. Rushing to rebuild without understanding the attack path usually results in a second incident within weeks because the initial entry point was never identified and closed.
Post-incident work at Solvanta covers forensic analysis of the attack chain, identification and closure of the entry point, architecture remediation to prevent lateral movement, and recovery from isolated backups where available. We also document what happened and what was changed, so the organisation has a clear record for any regulatory or contractual obligations.
If you want to understand your current exposure before an incident happens, request a security audit. We will map your actual attack surface and give you a prioritised remediation plan.