If It Faces the Internet, It Gets MFA. No Exceptions.

Most of the ransomware cases I've worked started the same boring way: somebody logged in. A real username and password, typed into a login page the company put on the internet on purpose. That's the whole "hack."

Passwords alone are dead

A password is one piece of information. Once someone else has it, they are you. Phishing, breach dumps, infostealers, a contractor's old text file. There are a hundred ways it leaks, and attackers don't need to break in when they can just log in. If your login page is reachable from the internet, someone is testing passwords against it right now. MFA changes the math. A stolen password becomes a partial key instead of the whole thing.

"Every network" means every network

Here's where people get lazy. They put MFA on Office 365 because Microsoft nagged them into it and call it done. Meanwhile the SSL VPN has 40 local accounts with no second factor, there's a server with RDP open on a "random" high port (they found it, they always find it), and the firewall admin page is reachable from outside because someone fixed something from home once in 2021.

Every one of those is a front door. RDP and VPN are at the top of the list because they hand an attacker exactly what they want: a foothold inside the perimeter that looks legitimate. If a human can log into it remotely, it gets MFA. VPN, RDP, admin portals, cloud consoles, backup consoles, the hypervisor, the firewall itself. All of it.

The SonicWall case that stuck with me

I worked multiple cases where a client was running a SonicWall firewall with SSL VPN turned on. Patched, reasonably segmented, decent AV. The one thing missing was MFA on the VPN. Local accounts and passwords, that was it.

The Akira ransomware group spent 2024 and 2025 hammering SonicWall SSL VPN. Their playbook was almost boring: get valid VPN creds (brute force, previously harvested credentials, or the SonicWall access control flaw CVE-2024-40766), log in like a normal remote employee, then move fast. Minutes from first login to internal scanning. Encryption not long after.

Nobody calls me because a login looked weird. They call me because files are encrypted or there's a ransom note sitting on a desktop. That's the first indicator almost every time, and by then the attacker has already been in and out.

So you work backwards. And the story in the logs is usually the same: a compromised account authenticating through the VPN, and the machine behind it isn't one of theirs. Sometimes it's a default Windows name like DESKTOP-XXXXXXX. Sometimes it's a hostname that just doesn't match the client's naming convention at all. Either way, a computer nobody in the company owns got handed an IP on the VPN subnet and started acting like an employee.

What still bugs me: the initial login came from a hosting provider IP. Not a residential connection, not a known employee location. Just a valid username and password from somewhere it had no business coming from. A second factor would have stopped it cold. Instead, it was a green light.

How it ends depends entirely on what the client had before the attacker showed up. If they had EDR that actually alerted, backups that were offline or immutable, and a disaster recovery plan someone had read in the last year, recovery is measured in days. If they had none of that, it's weeks, and the ransom note starts looking like a business decision instead of a threat. I've seen both.

What's consistent is what happens after. Every one of these cases ends with a security best practices review, and every client walks out of it in a better spot than they walked in. Not because the incident was good for them, but because they finally had a reason to fix the stuff that had been on the list for years. The review hits the same things almost every time:

MFA enforced on every remote entry point, not just email. Every local VPN account audited and the ones nobody can vouch for deleted. Firewall firmware and everything else patched, and credentials rotated after patching, because a patch doesn't invalidate what was already stolen. EDR on every endpoint and server, with someone actually watching the alerts. Backups that an attacker with domain admin can't touch, and a restore test on the calendar. Logs shipped off the firewall to something with more than a day of retention, because SonicWall VPN logs roll over fast and you can't investigate what you can't see. Account lockout policies tightened. Geo-blocking and blocking logins from hosting provider ranges where the business allows it. And a written incident response plan so the next call isn't "what do we do" but "start step one."

None of that is exotic. It's the baseline. The incident just moves it from "someday" to "this week." MFA on that one interface would have turned a multi-week incident into a failed login in a log nobody reads.

"But MFA can be bypassed"

It can. That same Akira campaign eventually showed successful logins against SonicWall accounts that did have OTP MFA, most likely from stolen seeds or credentials harvested before patching. MFA fatigue and token theft are real too.

That's not an argument against MFA. It's an argument for doing it right: authenticator app or hardware key over SMS, number matching on, and when you patch a device that was vulnerable, rotate the creds and the seeds too. Patching doesn't un-steal what already got stolen. MFA is a lock, not a force field. Locks get picked sometimes. That's not a reason to leave the door open.

Do this week

List everything remotely reachable that takes a username and password. Check the firewall for anything with a WAN-side listener. Put MFA on it or shut it off. There's no third option. Then check your VPN logs. If you see hosting providers, VPS ranges, or countries you don't do business with, you've got a problem right now, not a hypothetical one. Do it before someone does it for you.