WannaCry Kill Switch Sinkholed: Why Infection Halted After MS17-010

If you're staring at a WannaCry alert that says "infection halted" or your AV caught the dropper but nothing encrypted, congratulations — you got lucky. The kill switch domain got sinkholed years ago, and that's the only reason your file server isn't a brick right now. It is not a fix. It's a stay of execution.

The kill switch is a hardcoded domain WannaCry tries to resolve before it does anything else. If the lookup succeeds, the malware assumes it's in a sandbox and exits. If it fails, boom. In May 2017 a researcher registered iuqerfsodp9ifjaposdfjhgosurijfaewrwergwea.com for eleven bucks and that one purchase crippled the whole campaign overnight. Since then, registries, ISPs, and security vendors have kept that domain (and its variants) sinkholed. So on your network, DNS resolves to a sinkhole IP, the worm sees a response, and it quits before the encryption routine fires.

Cause 1: The kill switch domain is sinkholed (this is why it stopped)

This is the number one reason you're seeing "infection halted" instead of a ransom note. WannaCry variant A hits a host, tries to resolve that absurd domain, gets an answer from whatever sinkhole your DNS provider points at, and terminates. No file encryption, no ransom note, no lateral spread.

Wait — lateral spread. That's the part people miss. The kill switch only stops the current instance from executing the payload. The SMB exploit that delivered it already ran. EternalBlue is a memory corruption bug in SMBv1. If you're unpatched, WannaCry already wrote its dropper to C:\Windows\ and probably already tried to spread to every reachable 445/tcp host on your subnet.

What you do about it:

1. Don't celebrate. Treat the host as compromised until proven clean.
2. Pull it off the network. Air gap it. Right now.
3. Check for the dropper artifacts. WannaCry drops tasksche.exe, mssecsvc.exe, and a service named mssecsvc2.0.
4. Check SMBv1 is disabled and 445 isn't exposed internally.
5. Patch. See cause 2.

To verify the kill switch is actually resolving to a sinkhole on your network:

nslookup iuqerfsodp9ifjaposdfjhgosurijfaewrwergwea.com

# Expected: an IP owned by a sinkhole operator, not NXDOMAIN.
# If you get NXDOMAIN, your DNS is filtering it locally, which
# is also fine but you'd better have the patch too.

If you can, nuke and rebuild. WannaCry is sloppy about cleanup and I've seen it resurrect itself on hosts where someone "just deleted the files." The service registration lingers, the registry Run key lingers, and one reboot later you're back to square one.

Cause 2: MS17-010 is missing or only half-installed

Sinkholed domain or not, if MS17-010 isn't on the box, you're a sitting duck. The patch itself is the real fix. Everything else is mitigation.

The patch IDs you're looking for depend on OS:

Half-installed patches are a genuine problem. I've walked into environments where WSUS reported 100% compliance and half the machines were missing the actual SMB driver update because of a pending reboot that had been sitting there for six months. Check the actual file version of srv.sys if you don't trust your patching tool.

Quick check:

# PowerShell — look for the patch by KB number
Get-HotFix | Where-Object {$_.HotFixID -match 'KB4012212|KB4012215|KB4013429'}

# Or check the SMB driver version on the box
(Get-Item C:\Windows\System32\drivers\srv.sys).VersionInfo.FileVersion

And this bears repeating: a reboot is required. MS17-010 changes kernel-mode SMB code. Until you reboot, the old vulnerable binary is still in memory and still reachable. I've seen this trip people up during incident response more times than I want to count.

Cause 3: SMBv1 is still enabled and port 445 is open internally

Even with the patch, SMBv1 is a fossil. It was deprecated, then formally removed in Windows 11 24H2 and Server 2025. If you're still running it internally on a flat network, you're one zero-day away from a repeat of 2017.

Disable SMBv1 on the endpoint:

# PowerShell, on modern Windows
Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol

# Older Windows / Server 2008+ via DISM
DISM /Online /Disable-Feature /FeatureName:SMB1Protocol /NoRestart

# Server 2003-era, if you're somehow still there
# Registry: HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
# Set SMB1 = 0 (DWORD)

Then block 445 at the perimeter and between internal segments. Lateral movement is what made WannaCry so nasty — it wasn't patient, it just hammered every reachable SMB host in seconds. Segment your network. Put file servers in their own VLAN. Don't let workstations talk SMB to each other. Yes, it's work. No, you don't get a pass because "it's been fine for years."

WannaCry was an opportunistic worm. It didn't target you. It just happened to find you. Everything you do from here is about making sure the next opportunistic worm doesn't have the same reach.

Quick reference: symptom → cause → fix

One last thing. If your cleanup strategy relies on the kill switch staying sinkholed forever, you're betting your company on a domain registration that someone else controls. That's not a security posture. Patch the box.