Securing Windows Server Against Ransomware Attacks

I've walked into three ransomware incidents over the past few years, and every single one had the same root cause: not a sophisticated exploit, but a boring combination of flat network access, reused local admin credentials, and backups that were reachable from the same domain as the infected host. Once the attacker gets a foothold, encrypting a Windows Server fleet is almost mechanical if nothing stands in the way. This runbook is what I actually deploy on Windows Server 2019/2022 boxes before I consider them production-ready, not a theoretical checklist.

Prerequisites

Before you start locking things down, get an honest inventory of what you're protecting. You need local admin access on the target servers, domain admin or at least delegated rights in Active Directory if the servers are domain-joined, and a backup target that is physically or logically separate from your primary domain. In my experience, teams skip that last part and then wonder why the backup repository got encrypted along with everything else.

You'll also want:

• Windows Server 2019 or later (2016 works but lacks some Defender Exploit Guard features)
• PowerShell 5.1+ with an execution policy that allows signed scripts
• A separate backup host, in this runbook

  sw-infrarunbook-01

  , ideally on its own subnet
• An account inventory — service accounts, local admins, and anything with domain admin rights
• A maintenance window, because some of these changes (especially SMBv1 removal and LSA protection) can break legacy applications if you haven't checked dependencies first

Step-by-step setup

I break this into five phases: reduce the attack surface, isolate backups, segment the network, harden credentials, and turn on detection. Do them roughly in that order — there's no point hardening credentials on a server that still has SMBv1 exposed to the internet.

1. Reduce the attack surface

Remove SMBv1 first. It's still the single most common lateral-movement vector I see in incident reviews, mostly because someone left it on for an ancient printer driver or a legacy file share nobody remembers configuring.

Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol -NoRestart
Set-SmbServerConfiguration -EnableSMB1Protocol $false -Force

Next, enable SMB signing and require encryption where possible. This stops a large class of relay and man-in-the-middle attacks that ransomware crews use to pivot between hosts.

Set-SmbServerConfiguration -RequireSecuritySignature $true -Force
Set-SmbServerConfiguration -EncryptData $true -Force

Then disable unused RDP if the server doesn't need interactive logon, and if it does need RDP, put it behind a jump host rather than exposing 3389 directly.

Set-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\Terminal Server' -Name "fDenyTSConnections" -Value 1

2. Isolate backups

This is the step that actually determines whether a ransomware incident is a bad afternoon or a company-ending event. Your backup target needs to be unreachable using the same credentials as your production domain, and ideally it should be immutable for some retention window.

On

sw-infrarunbook-01

, I set up a dedicated backup share with a local account that isn't part of the domain at all:

wbadmin enable backup -addtarget:\\sw-infrarunbook-01\backup -schedule:22:00 -include:C:,D:
net use Z: \\sw-infrarunbook-01\backup /user:infrarunbook-admin *

If your backup solution supports object lock or WORM storage, use it. Veeam, for example, supports immutability windows on repositories — set that to at least 7 days so a compromised backup server can't just delete history the moment it's popped. I've seen attackers specifically hunt for backup jobs and delete them before triggering encryption; immutability is the one control that reliably defeats that.

3. Segment the network

Flat networks are ransomware's best friend. Put your servers into VLANs by function — domain controllers, file servers, application tiers, backup infrastructure — and use host-based firewall rules to restrict east-west SMB and RPC traffic to only what's needed.

New-NetFirewallRule -DisplayName "Block-SMB-Inbound-Except-Admin" -Direction Inbound -Protocol TCP -LocalPort 445 -RemoteAddress 192.168.10.0/24 -Action Allow
New-NetFirewallRule -DisplayName "Block-SMB-Inbound-Default" -Direction Inbound -Protocol TCP -LocalPort 445 -Action Block

Adjust the allowed subnet to match your actual admin or management VLAN. The point is that a compromised workstation in a general user VLAN shouldn't be able to open an SMB session to your file servers at all.

4. Harden credentials and privilege

Enable LSA protection so credential dumping tools like Mimikatz can't easily lift secrets from LSASS memory.

Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa' -Name "RunAsPPL" -Value 1

Enforce a tiered admin model. Domain admins should never log into a workstation or a Tier 2 server directly — use a jump host or PAW (privileged access workstation) instead. This is the control most organizations resist because it's operationally inconvenient, but it's also the one that stops a single phished workstation from turning into full domain compromise.

Also disable NTLM where you can and force Kerberos, since NTLM relay is still a common technique for privilege escalation inside a compromised network:

Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa' -Name "LmCompatibilityLevel" -Value 5

5. Turn on detection and prevention

Windows Defender's Controlled Folder Access and Exploit Guard are underrated. Controlled Folder Access specifically blocks unauthorized processes from modifying files in protected directories, which is exactly what ransomware encryptors try to do.

Set-MpPreference -EnableControlledFolderAccess Enabled
Add-MpPreference -ControlledFolderAccessProtectedFolders "D:\Shares","D:\Data"
Set-MpPreference -DisableRealtimeMonitoring $false

Enable Attack Surface Reduction (ASR) rules too — the ones targeting Office macro abuse and credential theft from LSASS are especially valuable since phishing is still the most common initial access vector.

Add-MpPreference -AttackSurfaceReductionRules_Ids 9e6c4e1f-7d60-472f-ba1a-a39ef669e4b2 -AttackSurfaceReductionRules_Actions Enabled
Add-MpPreference -AttackSurfaceReductionRules_Ids 75668c1f-73b5-4cf0-bb93-3ecf5cb7cc84 -AttackSurfaceReductionRules_Actions Enabled

Full configuration example

Here's a consolidated hardening script I run on new Windows Server builds before they go into production. It assumes you've already checked for legacy dependencies on SMBv1 and RDP.

# --- Ransomware hardening baseline for sw-infrarunbook-01 ---

# Remove SMBv1
Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol -NoRestart
Set-SmbServerConfiguration -EnableSMB1Protocol $false -Force

# SMB signing and encryption
Set-SmbServerConfiguration -RequireSecuritySignature $true -Force
Set-SmbServerConfiguration -EncryptData $true -Force

# LSA protection
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa' -Name "RunAsPPL" -Value 1

# Force Kerberos over NTLM
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa' -Name "LmCompatibilityLevel" -Value 5

# Defender Controlled Folder Access
Set-MpPreference -EnableControlledFolderAccess Enabled
Add-MpPreference -ControlledFolderAccessProtectedFolders "D:\Shares","D:\Data"

# ASR rules
Add-MpPreference -AttackSurfaceReductionRules_Ids 9e6c4e1f-7d60-472f-ba1a-a39ef669e4b2 -AttackSurfaceReductionRules_Actions Enabled
Add-MpPreference -AttackSurfaceReductionRules_Ids 75668c1f-73b5-4cf0-bb93-3ecf5cb7cc84 -AttackSurfaceReductionRules_Actions Enabled

# Firewall segmentation (adjust to your management subnet)
New-NetFirewallRule -DisplayName "Block-SMB-Inbound-Except-Admin" -Direction Inbound -Protocol TCP -LocalPort 445 -RemoteAddress 192.168.10.0/24 -Action Allow
New-NetFirewallRule -DisplayName "Block-SMB-Inbound-Default" -Direction Inbound -Protocol TCP -LocalPort 445 -Action Block

# Backup job to isolated target
wbadmin enable backup -addtarget:\\sw-infrarunbook-01\backup -schedule:22:00 -include:C:,D:

Reboot after applying LSA and SMB1 changes — some of these settings don't take effect until the next boot, and I've lost time in the past assuming a control was live when it actually wasn't yet.

Verification steps

Don't just trust that the script ran cleanly — verify each control actually took effect.

Confirm SMBv1 is gone:

Get-SmbServerConfiguration | Select EnableSMB1Protocol

Check that signing and encryption are enforced:

Get-SmbServerConfiguration | Select RequireSecuritySignature, EncryptData

Verify LSA protection is running — this needs a reboot to confirm, and you can check it via Task Manager's Details tab (LSASS should show "Protected: Yes, Light") or with:

Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa' -Name RunAsPPL

Confirm Controlled Folder Access and ASR rules are active:

Get-MpPreference | Select EnableControlledFolderAccess, AttackSurfaceReductionRules_Ids, AttackSurfaceReductionRules_Actions

And critically, test your backup isolation by attempting to reach the backup share using domain credentials from a compromised-looking test account. It should fail. If a domain account can browse into

\\sw-infrarunbook-01\backup

, your isolation isn't real — it's theater.

Finally, run a tabletop or actual restore test at least quarterly. A backup you haven't restored from is a backup you don't actually have. I've seen organizations discover their backup jobs had been silently failing for months, only found out during the incident when it mattered most.

Common mistakes

The most common mistake I see is treating backup isolation as a checkbox rather than an actual trust boundary. If your backup server trusts the same Active Directory as production, and an attacker gets domain admin, your backups are gone too. Use a separate authentication domain or at minimum a local-only account for the backup share.

Another one: enabling Controlled Folder Access and then adding so many exclusions that it stops doing anything useful. I've seen environments where every application folder got excluded because something threw an access-denied error once, which defeats the entire purpose of the control.

People also forget that ASR rules and Controlled Folder Access can break legitimate line-of-business applications, especially older ones that write directly to protected folders. Test in audit mode first — Defender lets you set ASR rules and Controlled Folder Access to audit-only so you can see what would have been blocked before you enforce it for real.

Audit mode isn't optional in my process anymore. I got burned once rolling out ASR rules in enforce mode straight to production, and it broke an accounting application's ability to write its own log files at month-end close. Now everything goes through a two-week audit period first.

Finally, don't neglect account hygiene. Even with every technical control in place, a domain admin account with a weak or reused password, logging into random workstations, undoes most of this work. Privilege tiering isn't a nice-to-have — it's the difference between one compromised laptop and total domain takeover.

None of these controls are exotic. They're mostly things Windows Server already supports out of the box. The gap is almost always in actually turning them on, testing them, and verifying they still work after the next patch cycle or the next well-meaning admin loosens a rule to fix an unrelated ticket.