How to Harden Windows Firewall via GPO to Prevent Lateral Movement
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
The default Windows Firewall configuration for domain-joined machines allows broad inbound and outbound communication within the domain: optimized for connectivity rather than security. This means every workstation can attempt SMB connections to every other workstation, which is exactly what pass-the-hash, PsExec, and ntlmrelayx rely on.
Firewall hardening via GPO creates host-based microsegmentation: workstations can communicate with domain controllers and file servers as needed, but cannot initiate connections to other workstations on lateral movement protocols. This does not require network hardware changes and applies instantly through GPO.
GPO Structure for Workstation Firewall Hardening
Create a new GPO: "Workstation-Firewall-Hardening"
Link to: Workstations OU (not Servers or DCs)
GPO path:
Computer Configuration > Windows Settings > Security Settings >
Windows Firewall with Advanced Security > Windows Firewall with Advanced Security
Step 1: Configure the firewall profiles to be ON and blocking:
Right-click Windows Firewall with Advanced Security > Properties
Domain Profile tab:
Firewall state: On (recommended)
Inbound connections: Block (default behavior with explicit allow rules)
Outbound connections: Allow (default: restrict later if needed)
Settings > Apply local firewall rules: No ← IMPORTANT: prevents local rules overriding GPO
Private Profile and Public Profile: same settings
Default inbound rules to evaluate:
Windows ships with many default inbound rules that allow file sharing, WMI, and other services in the domain profile. Audit what is enabled:
# List all enabled inbound firewall rules (run on a workstation):
Get-NetFirewallRule -Direction Inbound -Enabled True |
Select-Object DisplayName, Profile, LocalPort, Protocol |
Sort-Object Profile
# Identify rules that allow inbound SMB:
Get-NetFirewallRule -Direction Inbound -Enabled True |
Get-NetFirewallPortFilter | Where-Object { $_.LocalPort -eq 445 } |
ForEach-Object { $_.InstanceID } |
ForEach-Object { Get-NetFirewallRule -Name $_ } |
Select-Object DisplayName, Profile, Enabled
# You will likely find: "File and Printer Sharing (SMB-In)" enabled for the Domain profile
# This allows ANY machine in the domain to connect to this workstation on SMB
Block Workstation-to-Workstation Lateral Movement Protocols
Create explicit deny rules in the GPO for lateral movement protocols from all sources except authorized servers:
In GPO: Windows Firewall with Advanced Security > Inbound Rules > New Rule
--- RULE 1: Block inbound SMB from workstations ---
Rule Type: Custom
Program: All programs
Protocol: TCP
Local port: 445
Remote port: Any
Remote IP addresses: [workstation IP ranges]
e.g., 10.1.1.0/24 (your workstation subnet)
Do NOT include server/DC subnets
Action: Block the connection
Profile: Domain
Name: BLOCK-Workstation-SMB-Inbound
This blocks: psexec, pass-the-hash, ntlmrelayx, impacket SMB tools
This allows: DCs and servers (not in the blocked IP range) still reach workstations via SMB
--- RULE 2: Block inbound RDP from workstations ---
Rule Type: Custom
Protocol: TCP
Local port: 3389
Remote IP addresses: [workstation IP ranges]
Action: Block
Profile: Domain
Name: BLOCK-Workstation-RDP-Inbound
This blocks: workstation-to-workstation RDP lateral movement
Exception: IT jump servers and DCs (not in blocked range) can still RDP
--- RULE 3: Block inbound WMI from workstations ---
# WMI uses TCP 135 (endpoint mapper) + dynamic ports 49152-65535
Rule Type: Custom
Protocol: TCP
Local port: 135
Remote IP addresses: [workstation IP ranges]
Action: Block
Profile: Domain
Name: BLOCK-Workstation-WMI-DCOM-Inbound
# Also block WMI over dynamic range from workstations:
Rule Type: Custom
Protocol: TCP
Local port: 49152-65535
Remote IP addresses: [workstation IP ranges]
Action: Block
Profile: Domain
Name: BLOCK-Workstation-WMI-Dynamic-Inbound
This blocks: wmiexec, wmiprvse lateral movement, impacket wmiexec.py
--- RULE 4: Block inbound WinRM from workstations (PowerShell Remoting) ---
Rule Type: Custom
Protocol: TCP
Local port: 5985,5986
Remote IP addresses: [workstation IP ranges]
Action: Block
Profile: Domain
Name: BLOCK-Workstation-WinRM-Inbound
This blocks: Enter-PSSession, Invoke-Command lateral movement between workstations
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Allow Exceptions for Legitimate Management Traffic
Create allow rules BEFORE the block rules (GPO processes allow before block for inbound):
WARNING: Windows Firewall rule order for custom rules:
- Explicit BLOCK rules override ALLOW rules when both match
- Therefore: scope the block rules to workstation IP ranges
and leave server/DC IPs unmatched (they will be allowed by default or by explicit allows)
--- ALLOW: IT jump server RDP ---
Rule Type: Custom
Protocol: TCP
Local port: 3389
Remote IP addresses: [jump server IPs, e.g., 10.0.0.50]
Action: Allow
Profile: Domain
Name: ALLOW-JumpServer-RDP-Inbound
--- ALLOW: Monitoring agent communication (SIEM forwarder, EDR) ---
# Your EDR or Sysmon forwarder may require specific ports
# Example: Splunk UF uses 9997; CrowdStrike uses cloud egress (outbound)
Rule Type: Custom
Protocol: TCP
Local port: [agent-specific port]
Remote IP addresses: [SIEM collector IPs]
Action: Allow
Profile: Domain
Name: ALLOW-SIEM-Collector-Inbound
# Test firewall rule application after GPO deployment:
gpupdate /force
Get-NetFirewallRule -DisplayName "BLOCK-Workstation-SMB-Inbound" |
Select-Object DisplayName, Enabled, Direction, Action
# Test that SMB is blocked workstation-to-workstation:
# From a workstation, attempt to connect to another workstation:
Test-NetConnection -ComputerName 10.1.1.20 -Port 445
# Expected: TcpTestSucceeded : False (blocked)
# Test that DC SMB is still accessible (required for GPO/logon):
Test-NetConnection -ComputerName dc01.corp.local -Port 445
# Expected: TcpTestSucceeded : True (allowed)
Monitor Firewall Rule Violations
Enable firewall audit logging:
GPO: Computer Configuration > Windows Settings > Security Settings >
Advanced Audit Policy Configuration > Object Access >
"Audit Filtering Platform Packet Drop": Failure = Enabled
"Audit Filtering Platform Connection": Success and Failure = Enabled
This generates:
Event 5157: The Windows Filtering Platform blocked a connection
Event 5156: The Windows Filtering Platform permitted a connection
Event 5152: The Windows Filtering Platform blocked a packet
Enable firewall log file (for local review):
GPO: Windows Firewall with Advanced Security > Properties >
Domain Profile > Logging:
Log dropped packets: Yes
Log successful connections: Yes
Log file path: %SystemRoot%\System32\LogFiles\Firewall\pfirewall.log
Max file size: 16384 KB
KQL: detect lateral movement attempts stopped by firewall:
// Alert on firewall-blocked SMB/RDP/WMI attempts between workstations
// (requires Event 5157 forwarded to Sentinel)
SecurityEvent
| where TimeGenerated > ago(24h)
| where EventID == 5157 // WFP blocked connection
| where RenderedDescription has_any ("445", "3389", "135")
| extend
SourceIP = extract(@'Source Address:\s+([\d.]+)', 1, RenderedDescription),
DestIP = extract(@'Destination Address:\s+([\d.]+)', 1, RenderedDescription),
DestPort = extract(@'Destination Port:\s+(\d+)', 1, RenderedDescription)
// Focus on workstation-to-workstation blocked attempts:
| where SourceIP startswith "10.1.1." // Workstation subnet
and DestIP startswith "10.1.1." // Workstation subnet destination
| summarize AttemptCount = count() by SourceIP, DestIP, DestPort, bin(TimeGenerated, 1h)
| where AttemptCount > 5 // Repeated attempts = active lateral movement attempt
| order by AttemptCount desc
The bottom line
Windows Firewall GPO hardening blocks lateral movement by creating inbound BLOCK rules for SMB (445), RDP (3389), WMI (135 + 49152-65535), and WinRM (5985/5986) scoped to workstation subnet source IPs: while leaving server and DC communication unrestricted. Set "Apply local firewall rules: No" in the GPO to prevent local rules from overriding policy. Enable firewall logging (Event 5157 = blocked connection) and forward to Sentinel to detect active lateral movement attempts stopped by the firewall. Test deployment with Test-NetConnection before broad rollout to verify DC communication is preserved.
Frequently asked questions
Will blocking SMB between workstations break anything in a domain environment?
Blocking inbound SMB (port 445) on workstations from other workstation IPs does not break domain operations: domain controller-to-workstation SMB (for GPO, logon scripts, SYSVOL access) is initiated by the workstation outbound, not inbound. File sharing between workstations (if used) would be affected: evaluate whether peer-to-peer file sharing should be allowed. Legitimate workstation-to-workstation SMB is rare in most enterprise environments; any legitimate use cases should be redirected through file servers. Test on a pilot OU before broad deployment using Test-NetConnection to verify DC and file server access is preserved.
How do you prevent Windows Firewall GPO rules from being overridden locally?
In the GPO firewall profile settings (Windows Firewall with Advanced Security > Properties > Domain Profile > Settings), set "Apply local firewall rules: No" and "Apply local connection security rules: No". This blocks local administrators from adding firewall rules that override GPO-deployed rules. Without this setting, a local admin or attacker with admin access can add an inbound Allow rule for port 445 and bypass the workstation isolation policy.
How do I use Windows Firewall to isolate infected workstations remotely?
Windows Firewall GPO can be used for remote isolation without requiring endpoint agent capabilities. Create a 'Quarantine' GPO with firewall rules that: block all inbound connections, block all outbound connections except to your SIEM (for log collection), your management server (for GPO delivery), and the DNS server. Apply this GPO to a dedicated quarantine organizational unit (OU). When a workstation needs isolation: move its computer account to the quarantine OU in Active Directory. The GPO applies at the next group policy refresh (up to 90 minutes, or immediately with gpupdate /force if management connection remains open). This method works without MDE or any EDR agent but is slower than agent-based isolation.
How do I configure Windows Firewall to block lateral movement via SMB?
Block workstation-to-workstation SMB: create an outbound firewall rule that blocks TCP 445 and TCP 139 to workstation subnet ranges. Allow traffic to server subnets and domain controllers. Implementation in WFAS: New-NetFirewallRule -DisplayName 'Block SMB to Workstations' -Direction Outbound -Protocol TCP -RemotePort 445,139 -RemoteAddress 192.168.10.0/24 (your workstation subnet) -Action Block. This prevents Pass-the-Hash lateral movement via PsExec and SMB: even if an attacker has credentials, they cannot reach other workstations over SMB. Combine with blocking WMI (TCP 135/DCOM) and RDP (TCP 3389) between workstations for comprehensive lateral movement prevention.
How do I verify that Windows Firewall GPO rules are applied and not being overridden by local policy?
Run gpresult /h firewall-report.html on the target workstation and inspect the Firewall section: GPO-sourced rules appear with the GPO name as source; local rules appear as 'Local.' Also run Get-NetFirewallRule | Where-Object {$_.PolicyStoreSourceType -eq 'Local'} to enumerate rules applied outside GPO, and netsh advfirewall firewall show rule name=all verbose to see the full applied ruleset with source. If GPO rules are not appearing, check the GPO is linked to the correct OU, the computer is in scope (run gpresult /r to confirm), and that no higher-precedence GPO is overriding. Event ID 2003 in the Windows Firewall operational log records each profile change and the triggering policy source.
How do you handle Windows Firewall GPO conflicts when multiple overlapping GPOs apply to the same machines?
Windows Firewall GPO rules are additive rather than last-writer-wins: all GPO-deployed rules from all applicable GPOs merge into the effective ruleset. This means a broad 'allow' rule in one GPO can undermine a 'block' rule in another GPO, because Windows processes explicit allow rules before block rules when both match. To investigate: run gpresult /r on the target machine to list all GPOs applying to that computer object, then open wf.msc and check the 'Applied Rules' view which shows the merged effective ruleset with each rule's source GPO listed. Look for allow rules scoped to 'Any' remote IP or broad subnets that may be countering your workstation-isolation block rules. The safest resolution: consolidate firewall hardening into a single high-priority GPO with 'Apply local firewall rules: No' to prevent any lower-priority or local rules from bypassing the block. For troubleshooting, enable firewall audit logging (Events 5156 and 5157) and review which rule name the firewall logs cite when a connection is allowed or blocked unexpectedly -- the rule name in the log directly identifies the source GPO.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.