Turn Off the Risky Windows Features Attackers Love (Safely)

What attackers actually abuse on Windows

Most successful Windows compromises aren’t “one magical exploit.” They’re a chain:

• Initial access (phish, token theft, exposed RDP, vulnerable VPN, malicious macro).
• Execution (PowerShell, WSH, Office child processes, scheduled tasks).
• Credential access (LSASS dumping, NTLM relays, cached creds, mis-scoped service accounts).
• Lateral movement (SMB, WMI, WinRM, RDP, PsExec-like service creation).
• Persistence (startup items, scheduled tasks, services, GPO abuse).
• Impact (ransomware deployment, data theft, domain controller damage).

The “features attackers love” tend to be: old, widely deployed, and invisible in day-to-day operations. They also tend to be legitimate administrative capabilities. That’s the trap: if you can’t distinguish IT from an intruder in your logs, the attacker already won the stealth game.

Our goal here is to reduce the number of built-in tools an attacker can rely on, shrink the blast radius when they try, and make the environment noisy when they move.

Interesting facts and historical context (because this stuff didn’t happen by accident)

1. SMB1 dates back to the 1980s era of LAN Manager design assumptions: trusted networks, chatty discovery, minimal authentication hygiene.
2. NTLM was built for compatibility across older Windows versions and mixed environments; it stuck around because “works everywhere” is a powerful drug.
3. LLMNR was introduced to make name resolution “just work” when DNS isn’t properly configured. Attackers adore it for credential capture on flat networks.
4. WMI became the Swiss Army knife of Windows management—and later, of lateral movement—because it allows remote process execution with the right rights.
5. PowerShell was designed for automation first; security hardening (logging, constrained language, AMSI) came later as the threat model evolved.
6. Remote Registry exists largely for legacy management tooling. In modern environments it’s frequently dead weight with sharp edges.
7. Autorun/Autoplay were once a UX feature for removable media. They became a malware feature. UX lost that fight.
8. TLS 1.0/1.1 lingered because line-of-business apps and appliances didn’t want to be upgraded. Attackers and compliance auditors both noticed.

How to disable features without self-sabotage

1) Measure usage before removal

Disabling SMB1 is easy. Finding out that one warehouse scanner still speaks SMB1 is the actual work. Before you rip features out, you inventory dependencies.

2) Prefer “fence it in” over “leave it on”

If a feature is required, restrict it. Scope by:

• Network: only from admin subnets, only to management ports, only through a jump host.
• Identity: specific groups, JIT access, separate admin accounts.
• Device: PAWs/SAWs for admins, tiering (workstations can’t admin servers).
• Time: just-in-time elevation, expiring access, change windows.

3) Make reversibility a design requirement

If you can’t roll back quickly, you won’t ship changes. For each change, decide:

• What breaks if we’re wrong?
• How do we detect breakage in under 10 minutes?
• What’s the rollback command or GPO?

4) Log enough to prove you’re safer

Hardening that can’t be validated becomes a religious argument. You want evidence: reduced NTLM events, fewer inbound management ports, fewer script engines available, fewer “remote service created” events.

5) Don’t confuse “disabled” with “unreachable”

Turning off a service helps. Blocking the port at the host firewall is often more reliable. Best is both, when possible.

Paraphrased idea from Gene Kim: small, frequent changes with fast feedback beat big-bang changes, especially when reliability is on the line.

Fast diagnosis playbook (what to check first/second/third)

This is the part you use when you’re mid-incident or mid-change and someone says, “Why did everything break?” You want to find the bottleneck quickly, not win an argument.

First: confirm what changed and where

• GPO / Intune / local policy: did the setting apply? On which OU / device group?
• Feature removal vs config disable: did someone uninstall an optional feature (harder to roll back) or just flip a policy?
• Firewall scope: did we block a port needed for management tooling?

Second: identify the failing path (name resolution, auth, transport)

• Name resolution: DNS vs LLMNR/NBT-NS fallbacks.
• Authentication: Kerberos vs NTLM, certificate-based vs password-based.
• Transport: SMB vs WinRM vs WMI/DCOM vs RDP.

Third: prove it with one clean test from one clean host

• From a known-good admin workstation, test the specific protocol/port.
• From the target server, inspect listener state, service status, and firewall rules.
• Check event logs for the relevant subsystem (SMBClient, WinRM, Security, Schannel).

Fast “triage map”

• Can’t access file shares → check SMB dialects, firewall 445, SMB signing, guest access.
• Remote commands fail → check WinRM service, listener, firewall, TrustedHosts misuse.
• Old app can’t connect → check TLS versions/ciphers, .NET settings, Schannel logs.
• Login delays → check name resolution fallbacks and domain controller reachability.

High-risk Windows features to turn off (or fence in)

SMB1 (disable it; no nostalgia allowed)

SMB1 is a compatibility tax with a security interest rate. If you still have SMB1 clients or servers, you need a plan: identify them, isolate them, and retire them. The safe default is: SMB1 off everywhere.

Fence-in fallback: if a truly immovable device requires SMB1, put it on a dedicated VLAN, restrict SMB to a single file server, and prevent it from talking to anything else.

LLMNR and NBT-NS (turn them off to stop easy credential capture)

LLMNR and NBT-NS are “helpful” when DNS fails. Attackers abuse them for spoofing (poisoning) and capturing NTLM hashes via responder-style attacks. If DNS isn’t reliable, fix DNS. Don’t keep the foot-gun.

NTLM (reduce; then kill where you can)

Kerberos is the preferred protocol in a healthy domain. NTLM is the messy fallback that attackers can relay, downgrade into, or harvest. You don’t have to flip “disable NTLM” globally on day one. You do need a reduction plan, backed by event data and exceptions that expire.

PowerShell remoting and WinRM (restrict, don’t blanket-disable)

WinRM/PowerShell Remoting are legitimately useful. They’re also high-value for adversaries because they blend in as “admin traffic.” Best practice is to restrict who can use it, from where, and to log it well. If you don’t need it on endpoints, disable it there.

WMI/DCOM remote administration (restrict hard)

Remote WMI is another classic lateral movement path. Many orgs can shift common tasks to WinRM with constrained endpoints and better auditing. If you keep WMI remote, scope it to admin hosts and admin groups.

Remote Registry (usually: disable)

If you’re not using a tool that requires Remote Registry, turn it off. This is one of those services that quietly expands what’s possible during an intrusion without providing much modern value.

Windows Script Host (WSH) and legacy script engines (often: disable)

VBScript and JScript through WSH are frequent payload carriers. Many environments can disable WSH without breaking core Windows functionality. If a legacy app needs it, scope it to that app’s hosts only.

Office macros and “child process” behavior (control aggressively)

Macros aren’t evil. Uncontrolled macros are. Set macro policy, block internet-sourced macros, and reduce Office spawning child processes where feasible via ASR rules. In corporate reality, you will have exceptions. Make them explicit and reviewed.

RDP exposure (reduce the surface area, then reduce the privilege)

RDP is not the villain. RDP exposed to the world, or broadly enabled internally with weak controls, absolutely is. Use gateway/jump hosts, MFA, network-level authentication, and host firewall restrictions. Also: don’t use domain admins for routine RDP.

Legacy TLS and weak crypto (turn off old protocols on servers first)

Attackers don’t need to break crypto if you keep offering outdated protocols. Disabling TLS 1.0/1.1 and weak ciphers can break old integrations, so approach it like an SRE change: detect, stage, and roll out with monitoring.

Autorun/Autoplay (disable; there is no business case)

Removable media is still a thing in plenty of industries. Autorun should not be. If you want to auto-open something when a device is inserted, you want a managed enterprise tool, not a 2000s-era feature with malware history.

Joke #1: SMB1 is like keeping a rotary phone because it “still works.” Sure—until someone uses it to call long-distance on your dime.

Practical tasks: commands, outputs, and the decision you make

These tasks are meant to be runnable from an admin shell (PowerShell) on Windows. The prompt format below is standardized; don’t overthink the username. The important part is what you learn from the output and what you do next.

Task 1: Check whether SMB1 is enabled (server component)

cr0x@server:~$ powershell -NoProfile -Command "Get-WindowsOptionalFeature -Online -FeatureName SMB1Protocol | Format-List FeatureName,State"
FeatureName : SMB1Protocol
State       : Enabled

What the output means: SMB1 is installed and enabled on this machine.

Decision: If this is anything except an isolated legacy island, schedule disable/removal. Before changing, identify any SMB1-dependent clients (see Task 3).

Task 2: Disable SMB1 safely (feature removal) and confirm

cr0x@server:~$ powershell -NoProfile -Command "Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol -NoRestart"
Path          :
Online        : True
RestartNeeded : True

What the output means: SMB1 is disabled; a reboot is required to complete.

Decision: Plan the reboot. If this is a file server, coordinate with users and monitor share access errors after restart.

Task 3: Detect SMB1 usage via event logs (SMB server)

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -LogName 'Microsoft-Windows-SMBServer/Audit' -MaxEvents 20 | Select-Object TimeCreated,Id,Message | Format-Table -AutoSize"
TimeCreated           Id Message
-----------           -- -------
2/5/2026 10:12:41 AM 3000 SMB1 negotiation detected from client 10.20.5.44.
2/5/2026 10:05:09 AM 3000 SMB1 negotiation detected from client 10.20.5.44.

What the output means: A client at 10.20.5.44 is trying to use SMB1.

Decision: Find the device owner. If it’s a legacy device, isolate it or upgrade it. Don’t keep SMB1 enabled globally to protect one dusty corner.

Task 4: Check SMB signing status (client and server)

cr0x@server:~$ powershell -NoProfile -Command "Get-SmbServerConfiguration | Select-Object EnableSecuritySignature,RequireSecuritySignature | Format-List"
EnableSecuritySignature  : True
RequireSecuritySignature : False

What the output means: SMB signing is supported but not required.

Decision: In most enterprise networks, require SMB signing on servers (especially DCs and file servers). Validate compatibility with older clients first.

Task 5: Identify if LLMNR is enabled via registry (local check)

cr0x@server:~$ powershell -NoProfile -Command "Get-ItemProperty -Path 'HKLM:\Software\Policies\Microsoft\Windows NT\DNSClient' -Name EnableMulticast -ErrorAction SilentlyContinue | Format-List"
EnableMulticast : 1

What the output means: LLMNR is explicitly enabled by policy (1).

Decision: Set this to 0 via GPO for domain-joined systems, then validate that DNS is reliable on the affected subnets.

Task 6: Disable LLMNR (local remediation for testing)

cr0x@server:~$ powershell -NoProfile -Command "New-Item -Path 'HKLM:\Software\Policies\Microsoft\Windows NT\DNSClient' -Force | Out-Null; Set-ItemProperty -Path 'HKLM:\Software\Policies\Microsoft\Windows NT\DNSClient' -Name EnableMulticast -Type DWord -Value 0; Get-ItemProperty -Path 'HKLM:\Software\Policies\Microsoft\Windows NT\DNSClient' -Name EnableMulticast"
EnableMulticast : 0

What the output means: LLMNR is now disabled by policy on this host.

Decision: Roll into centralized policy (GPO/Intune). Also consider disabling NBT-NS where feasible (Task 7).

Task 7: Check NetBIOS over TCP/IP setting (per interface)

cr0x@server:~$ powershell -NoProfile -Command "Get-WmiObject -Class Win32_NetworkAdapterConfiguration -Filter 'IPEnabled=TRUE' | Select-Object Description,TcpipNetbiosOptions | Format-Table -AutoSize"
Description                          TcpipNetbiosOptions
-----------                          -------------------
Intel(R) Ethernet Connection         0

What the output means: TcpipNetbiosOptions 0 usually means “Default” (DHCP-controlled). 1 enables, 2 disables.

Decision: If you don’t need NetBIOS, set to 2 via DHCP options or local config standards. Validate legacy dependencies first (old systems, old discovery tooling).

Task 8: Check if WinRM is enabled and listening

cr0x@server:~$ powershell -NoProfile -Command "winrm enumerate winrm/config/listener"
Listener
    Address = *
    Transport = HTTP
    Port = 5985
    Hostname
    Enabled = true

What the output means: WinRM is enabled and listening on HTTP 5985.

Decision: For servers, keep WinRM but restrict inbound to admin subnets and enforce proper auth. For endpoints, consider disabling entirely unless needed.

Task 9: Disable PowerShell remoting on endpoints (targeted)

cr0x@server:~$ powershell -NoProfile -Command "Disable-PSRemoting -Force; Get-Service WinRM | Select-Object Name,Status,StartType | Format-Table -AutoSize"
Name Status StartType
---- ------ ---------
WinRM Stopped Disabled

What the output means: WinRM service is stopped and disabled; PS Remoting is off.

Decision: Apply to workstation OU/device group, not your management servers. Keep a break-glass path (e.g., your EDR remote shell, or on-network management tooling).

Task 10: Check Remote Registry service status

cr0x@server:~$ powershell -NoProfile -Command "Get-Service RemoteRegistry | Select-Object Name,Status,StartType | Format-Table -AutoSize"
Name           Status  StartType
----           ------  ---------
RemoteRegistry Running Automatic

What the output means: Remote Registry is running and set to start automatically.

Decision: If you can’t name the tool that needs this, disable it (Task 11). If a tool needs it, scope that tool to a management VLAN and limit who can reach it.

Task 11: Disable Remote Registry and block inbound with firewall defense-in-depth

cr0x@server:~$ powershell -NoProfile -Command "Stop-Service RemoteRegistry -Force; Set-Service RemoteRegistry -StartupType Disabled; Get-Service RemoteRegistry | Format-Table -AutoSize"
Status  Name           DisplayName
------  ----           -----------
Stopped RemoteRegistry Remote Registry

What the output means: The service is stopped and won’t start on boot.

Decision: Verify your systems management still works. If something breaks, it should be a known dependency—if it’s a surprise, you just found undocumented risk.

Task 12: Check whether WSH (cscript/wscript) is enabled

cr0x@server:~$ powershell -NoProfile -Command "Get-ItemProperty -Path 'HKLM:\Software\Microsoft\Windows Script Host\Settings' -Name Enabled -ErrorAction SilentlyContinue | Format-List"
Enabled : 1

What the output means: Windows Script Host is enabled.

Decision: If you don’t have sanctioned VBScript logon scripts or legacy admin scripts, disable WSH via policy and migrate automation to PowerShell with logging.

Task 13: Disable WSH (targeted pilot) and verify behavior

cr0x@server:~$ powershell -NoProfile -Command "New-Item -Path 'HKLM:\Software\Microsoft\Windows Script Host\Settings' -Force | Out-Null; Set-ItemProperty -Path 'HKLM:\Software\Microsoft\Windows Script Host\Settings' -Name Enabled -Type DWord -Value 0; Get-ItemProperty -Path 'HKLM:\Software\Microsoft\Windows Script Host\Settings' -Name Enabled"
Enabled : 0

What the output means: WSH is now disabled on this host.

Decision: Pilot in a department first (finance often has “mystery macros/scripts”). Track helpdesk tickets; you’re mapping hidden dependencies.

Task 14: Check RDP exposure (service + firewall rule group)

cr0x@server:~$ powershell -NoProfile -Command "Get-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\Terminal Server' -Name fDenyTSConnections | Select-Object fDenyTSConnections; Get-NetFirewallRule -DisplayGroup 'Remote Desktop' | Select-Object DisplayName,Enabled,Direction,Action | Format-Table -AutoSize"
fDenyTSConnections
------------------
0

DisplayName                             Enabled Direction Action
-----------                             ------- -------- ------
Remote Desktop - User Mode (TCP-In)      True    Inbound  Allow
Remote Desktop - User Mode (UDP-In)      True    Inbound  Allow

What the output means: RDP is allowed and firewall rules are enabled.

Decision: If this is not a jump host or terminal server, disable RDP or restrict firewall scope to admin subnets. Don’t leave it broadly reachable “just in case.”

Task 15: Verify NTLM usage signals in Security logs (local quick check)

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624} -MaxEvents 50 | Where-Object { $_.Message -match 'NTLM' } | Select-Object TimeCreated,Id,Message | Select-Object -First 3 | Format-Table -Wrap"
TimeCreated           Id Message
-----------           -- -------
2/5/2026 9:44:10 AM 4624 ... Authentication Package: NTLM ...
2/5/2026 9:43:58 AM 4624 ... Authentication Package: NTLM ...

What the output means: Recent logons used NTLM on this system.

Decision: You can’t kill NTLM blind. You need to identify which apps/devices are triggering it, then move them to Kerberos or modern auth, or isolate them.

Task 16: Check TLS protocol settings (Schannel) for legacy versions

cr0x@server:~$ powershell -NoProfile -Command "Get-ChildItem 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols' -ErrorAction SilentlyContinue | Select-Object PSChildName | Format-Table -AutoSize"
PSChildName
-----------
TLS 1.0
TLS 1.1
TLS 1.2
TLS 1.3

What the output means: The protocol keys exist. Presence doesn’t equal enabled/disabled; you must check subkeys and values.

Decision: On servers, disable TLS 1.0/1.1 after validating dependencies. Start with non-internet-facing internal services, then move outward.

Joke #2: Turning off legacy TLS is like cleaning under the fridge: unpleasant, overdue, and you will discover something that used to be food.

Three corporate mini-stories (anonymized, plausible, and painfully familiar)

Mini-story 1: The incident caused by a wrong assumption

They assumed “internal network” meant “trusted network.” It was a mid-sized company with a flat-ish campus LAN, a few VLANs, and a lot of faith. LLMNR and NBT-NS were left enabled because sometimes DNS got flaky in one building and nobody wanted to get paged over name resolution again.

An attacker got onto a single user’s laptop via a garden-variety phishing attachment. No kernel exploit. No fireworks. Then they ran a responder-style poisoning setup on the same subnet. The environment happily offered up NTLM authentication attempts whenever a machine tried to resolve a name that DNS didn’t answer quickly enough.

Within hours they had credentials that were useful elsewhere. Not “domain admin” immediately. Something worse: a service account that had local admin on a wide swath of systems because it made software deployment “easy.” From there, remote WMI and SMB did the rest.

The post-incident meeting had the usual suspects: “Why didn’t the firewall stop it?” and “Why wasn’t the antivirus enough?” The uncomfortable answer was simpler: the network itself was participating in the compromise because it was configured to accept insecure fallback behavior as normal.

The fix wasn’t heroic. They fixed DNS properly, disabled LLMNR, reduced NTLM, and stopped giving deployment accounts broad local admin. The biggest change was cultural: “internal” stopped being a synonym for “safe.”

Mini-story 2: The optimization that backfired

A large enterprise wanted faster remote administration. Their patching team had grown tired of RDP being slow and jump boxes being overloaded, so someone “optimized” by enabling WinRM broadly and adding a wide TrustedHosts entry to make connections “less annoying.” It worked. Everything was faster. Tickets went down.

Then an attacker got a foothold on a workstation. With local admin, they could read enough configuration and cached details to start using the same convenient remote management pathways. WinRM made lateral movement cleaner, quieter, and less dependent on older, noisier tools. TrustedHosts reduced friction in ways that also reduced safety.

When the incident response team reviewed logs, it looked like IT. Remote commands, remote sessions, legitimate protocols. The difference was time-of-day and source hosts that didn’t match the usual admin patterns, but that’s subtle when you’re under pressure.

The “optimization” wasn’t WinRM itself. WinRM can be a good idea. The backfire was enabling it everywhere without network scoping, without strict endpoint configuration, and without tight identity controls. They eventually reworked it: WinRM only from hardened admin workstations, only to servers, and heavily logged. For endpoints, it was off unless there was a reason to keep it.

Mini-story 3: The boring but correct practice that saved the day

A financial services shop ran a strict tiering model: admins used dedicated admin workstations; domain admins didn’t browse the web; and management protocols were restricted by firewall rules to a management VLAN. It wasn’t glamorous. New hires complained. Everyone wanted exceptions.

They also had a habit that looks like paperwork until it saves you: change plans with explicit rollback steps. Every hardening change had a “how to undo this at 2 AM” section, and the rollback was tested in a lab that actually resembled production.

During an incident, a contractor laptop was compromised off-network and later connected on-site. The attacker tried classic lateral movement: scan for 445, attempt SMB sessions, attempt WinRM, attempt RDP. They hit walls quickly. The ports weren’t reachable from that network segment, and the credentials they stole weren’t enough because privileged access required a different account used only from admin workstations.

The attacker still caused trouble on that one endpoint. But the org avoided the “now it’s everywhere” phase. The lesson wasn’t “we’re unhackable.” It was that boring segmentation and disciplined admin hygiene turn a disaster into a ticket.

Common mistakes: symptoms → root cause → fix

1) “After disabling LLMNR, some apps can’t find servers by name”

Symptoms: Users complain that “it used to work” when typing short names; some legacy apps time out; helpdesk sees intermittent failures.

Root cause: DNS is incomplete (missing A records, broken search suffixes), and LLMNR/NBT-NS were acting as duct tape.

Fix: Fix DNS and DHCP options (search suffix list), ensure forward/reverse records exist where needed, and update apps to use FQDNs. Keep LLMNR off.

2) “SMB1 removal broke one critical device”

Symptoms: A scanner/copier/old appliance can’t write to a share; logs show negotiation failures.

Root cause: Device firmware only supports SMB1.

Fix: Upgrade firmware or replace device. Until then: isolate the device to its own VLAN, restrict SMB to a dedicated file drop server, and monitor that server tightly.

3) “Disabling WinRM broke patching”

Symptoms: Patching jobs fail; remote inventory fails; error mentions WSMan or 5985/5986 connectivity.

Root cause: Your tooling relied on WinRM and you disabled it without a replacement path or scope.

Fix: Re-enable WinRM where required, but restrict inbound to management subnets and admin hosts, use HTTPS where appropriate, and remove broad TrustedHosts patterns.

4) “After tightening firewall rules, RDP is ‘randomly’ unavailable”

Symptoms: Some admins can RDP, others can’t. Works from the office but not VPN (or vice versa).

Root cause: Firewall scoping based on IP ranges doesn’t include all admin source networks; VPN pools weren’t included.

Fix: Define admin source networks explicitly, document them, and enforce RDP via gateway/jump host rather than scattered allowlists.

5) “Turning off WSH broke logon scripts”

Symptoms: Drive mappings or printer mappings fail; users complain after login.

Root cause: You still have VBScript-based logon scripts or legacy GPO scripts.

Fix: Migrate to PowerShell scripts with proper signing and logging, or use Group Policy Preferences for mappings where possible. Keep WSH disabled on endpoints once migrated.

6) “Disabling TLS 1.0 broke a vendor integration”

Symptoms: Client fails to connect; server shows Schannel errors; vendor says “it worked yesterday.”

Root cause: The vendor client (or server) only supports legacy TLS or weak ciphers.

Fix: Upgrade the integration. If forced into a temporary exception, isolate that endpoint/service and set an expiration date for the exception with an owner.

7) “We disabled NTLM and authentication started failing all over”

Symptoms: Domain resource access fails; old apps stop authenticating; weird service logon failures.

Root cause: You skipped the measurement phase and didn’t identify NTLM dependencies; likely includes non-domain-joined systems, old NAS devices, or misconfigured SPNs preventing Kerberos.

Fix: Re-enable temporarily, gather NTLM audit events, fix SPNs and DNS, migrate or isolate legacy systems, then re-apply restrictions incrementally.

Checklists / step-by-step plan

Phase 0: Pick your scope (don’t boil the ocean)

• Start with workstations (highest phishing rate) and server management exposure (highest blast radius).
• Define what “done” looks like for a pilot OU/device group.
• Decide your rollback path for each setting.

Phase 1: Inventory and baseline (1–2 weeks)

• Find SMB1 usage (Task 3) on file servers.
• Sample NTLM usage (Task 15) on representative servers and endpoints.
• List where WinRM is required (patching, configuration management, inventory).
• Identify legacy script usage (WSH, logon scripts, scheduled tasks).
• Record current RDP enablement and firewall scope (Task 14).

Phase 2: Quick wins with low break risk (pilot first)

• Disable Autorun/Autoplay (policy-driven) on all endpoints.
• Disable Remote Registry on endpoints and most servers (Task 10/11).
• Disable LLMNR via policy (Task 6), then fix DNS issues that surface.
• Restrict RDP: remove from endpoints; require jump host for servers.

Phase 3: High-impact changes with dependency management

• Disable SMB1 broadly (Task 1/2), isolate exceptions.
• Harden WinRM: only from admin subnets, consider HTTPS, remove broad TrustedHosts.
• Reduce NTLM: start with auditing, then restrictions on sensitive servers (DCs, file servers).
• Disable WSH on endpoints (Task 13), migrate scripts.
• Disable TLS 1.0/1.1 on servers in waves, validating each integration.

Phase 4: Make it stick (the part most orgs skip)

• Move hardening into standard builds (gold images, configuration management, policy-as-code where possible).
• Require exception tickets with owners and expiry dates.
• Monitor drift: periodic checks for re-enabled services and reopened firewall rules.
• Run tabletop exercises: “What if a workstation is compromised—what can it reach?”

FAQ

1) Should I just disable PowerShell entirely?

No. PowerShell is core to modern Windows administration and security tooling. Harden it: logging, constrained endpoints, limit remoting, and restrict who can run what where.

2) Is disabling SMB1 enough to stop ransomware?

No. It removes a common weak link, but ransomware spreads via multiple paths: stolen creds, remote execution, exposed management protocols, and poor segmentation. Treat SMB1 as a must-do baseline, not a silver bullet.

3) If I disable LLMNR, will anything break?

Things might break if your DNS is sloppy. That’s not a reason to keep LLMNR; it’s a reason to fix DNS. Pilot first, then expand.

4) Why not just block all inbound admin ports everywhere?

You can, and it’s often a good idea, but you still need a management plane. The mature pattern is: admin ports reachable only from hardened admin workstations/jump hosts on a management network.

5) What’s the safest approach to reducing NTLM?

Audit first, then fix Kerberos blockers (DNS/SPNs/time skew), then restrict NTLM on your highest-value servers. Make exceptions explicit and temporary.

6) Is Remote Registry ever justified?

Sometimes, in niche tooling or specific legacy management scenarios. If you keep it, don’t leave it wide open: scope access by firewall, admin groups, and management subnet. Otherwise, disable it.

7) We need RDP for vendor support. What’s the least bad option?

Use a jump host with MFA, time-bound access, and session recording if available. Don’t expose RDP directly to the internet, and don’t give vendors broad accounts.

8) Can I disable WSH if we use Office heavily?

Yes—WSH is not Office macros. WSH is cscript/wscript executing VBScript/JScript. Some organizations still have VBScript logon scripts; migrate them before broad disablement.

9) How do I avoid breaking old apps when disabling TLS 1.0/1.1?

Inventory which services accept inbound TLS and which clients connect outbound. Disable in stages: non-critical services first, then critical ones with a rollback plan. If a vendor can’t support modern TLS, isolate that integration and plan replacement.

10) What’s the biggest “quiet risk” you see in Windows environments?

Overly permissive lateral movement paths combined with admin convenience: broad local admin, WinRM/WMI everywhere, and weak segmentation. Attackers don’t need exotic tricks when the environment is built for frictionless movement.

Conclusion: next steps you can ship this week

If you want practical progress—not a hardening fantasy—do this in a week:

1. Pick one pilot group of workstations and apply: disable LLMNR, disable Remote Registry, disable WSH, and restrict RDP.
2. On file servers, check SMB1 status and SMB1 negotiation events; start isolating or upgrading SMB1-dependent devices.
3. On servers, inventory WinRM usage, then restrict inbound WinRM to management subnets instead of turning it into an everywhere-door.
4. Start measuring NTLM usage and create a reduction backlog. Don’t guess.
5. Write rollback steps for each change and test them once. That’s the difference between a confident rollout and a panic-driven revert.

Turning off risky Windows features isn’t about making your environment “perfect.” It’s about making it boringly hard for attackers to move, and obviously loud when they try.