Network-Level Containment
NGFW block by IP and domain, enterprise DNS sinkhole, proxy block, VLAN isolation, and blocking specific protocols east-west to stop spread without cutting management access.
Ransomware is spreading via SMB on port 445, exploiting an unpatched EternalBlue vulnerability on legacy machines that don't have EDR deployed. The EDR-based isolation only covers 80% of the fleet. For the remaining 20%, you need network-level containment: blocking SMB east-west between workstations without disrupting the management network or taking down the entire network segment. The firewall team has never had to do this in under 10 minutes before. This chapter covers the specific commands — not the concepts — because at 2 AM during an active ransomware event, the network engineer needs to know exactly what to type.
NGFW: Block by IP and Domain
Blocking attacker infrastructure at the perimeter firewall is the fastest way to sever C2 channels at scale. Unlike EDR isolation, it applies to every machine on the network without needing an agent on each endpoint.
# Palo Alto NGFW — block a C2 IP via CLI (SSH to the firewall)
# Create an address object for the C2 IP
set address "C2-IR-2026-023" ip-netmask 185.220.101.47/32
commit
# Create a security policy rule to block it (insert at top of ruleset)
set rulebase security rules "BLOCK-C2-IR-2026-023" from any
set rulebase security rules "BLOCK-C2-IR-2026-023" to any
set rulebase security rules "BLOCK-C2-IR-2026-023" source any
set rulebase security rules "BLOCK-C2-IR-2026-023" destination "C2-IR-2026-023"
set rulebase security rules "BLOCK-C2-IR-2026-023" application any
set rulebase security rules "BLOCK-C2-IR-2026-023" service any
set rulebase security rules "BLOCK-C2-IR-2026-023" action deny
set rulebase security rules "BLOCK-C2-IR-2026-023" log-start yes
set rulebase security rules "BLOCK-C2-IR-2026-023" log-end yes
commit
# Move the rule to the top (before any allow rules)
move rulebase security rules "BLOCK-C2-IR-2026-023" top
commit
# Block a C2 domain using URL filtering category (faster, handles IP rotation)
# Add to a custom URL category:
set profiles url-filtering "IR-Block-List" block custom-url-categories "IR-C2-Domains"
set custom-url-category "IR-C2-Domains" list [ "evil-c2-domain.com" "another-c2.net" ]
commit
# Windows Defender Firewall — block outbound C2 connections fleet-wide via GPO
# Create the rule locally first, test, then deploy via GPO
# Block outbound to known C2 IP
New-NetFirewallRule `
-DisplayName "IR-Block-C2-185.220.101.47" `
-Direction Outbound `
-RemoteAddress "185.220.101.47" `
-Action Block `
-Profile Any `
-Enabled True
# Block SMB outbound (east-west spread prevention)
New-NetFirewallRule `
-DisplayName "IR-Block-SMB-Outbound-Workstations" `
-Direction Outbound `
-Protocol TCP `
-RemotePort 445 `
-Action Block `
-Profile Any `
-Enabled True
# Apply the same rule to all machines via Group Policy:
# Computer Config > Windows Settings > Security Settings >
# Windows Defender Firewall with Advanced Security > Outbound Rules
# Or use LGPO.exe to push the policy file to all machines via startup script
DNS Sinkhole
A DNS sinkhole redirects queries for attacker-controlled domains to a controlled IP address (typically a sinkhole server that logs the queries). This severs C2 channels for all machines using the corporate DNS resolver without modifying any host, firewall, or endpoint.
DNS Sinkhole Architecture
═══════════════════════════════════════════════════════════════════
Compromised host resolves evil-c2-domain.com
│
▼
Corporate DNS Resolver ──► evil-c2-domain.com → 10.99.99.99 (sinkhole)
(override configured here) (instead of real C2 IP 185.220.101.47)
│
▼
Host gets sinkhole IP back
Beacon tries to connect to 10.99.99.99
│
▼
Sinkhole server (internal web server)
├── Returns fake HTTP 200 (beacon may keep trying — "alive" to C2 operator)
├── Logs every IP that queried the domain ← who is infected
└── Optionally serves fake C2 responses (deception operations)
Benefit: all infected hosts that use corporate DNS are contained
simultaneously — even hosts without EDR
Limitation: only works if host uses corporate DNS; doesn't block
direct IP-based C2 (no DNS query = no sinkhole)
# BIND DNS sinkhole configuration
# Add to named.conf or a dedicated include file
# Define the sinkhole zone
zone "evil-c2-domain.com" {
type master;
file "/etc/bind/sinkhole.zone";
allow-query { any; };
};
zone "another-c2.net" {
type master;
file "/etc/bind/sinkhole.zone";
allow-query { any; };
};
; Sinkhole zone file — redirects all queries to internal sinkhole server
$TTL 60
@ IN SOA ns1.corp.local. admin.corp.local. (
2026091901 ; serial
3600 ; refresh
900 ; retry
604800 ; expire
60 ) ; minimum TTL
@ IN NS ns1.corp.local.
@ IN A 10.99.99.99 ; sinkhole server IP
* IN A 10.99.99.99 ; wildcard — catches all subdomains too
# Windows DNS Server sinkhole (if your internal DNS is Windows)
# Requires DNS Server module (RSAT feature)
$sinkIP = "10.99.99.99"
$c2Domains = @("evil-c2-domain.com", "another-c2.net")
foreach ($domain in $c2Domains) {
# Create a primary zone for the C2 domain
Add-DnsServerPrimaryZone -Name $domain `
-ZoneFile "$domain.dns" `
-PassThru
# Add a wildcard A record pointing to the sinkhole server
Add-DnsServerResourceRecordA -Name "@" -ZoneName $domain -IPv4Address $sinkIP
Add-DnsServerResourceRecordA -Name "*" -ZoneName $domain -IPv4Address $sinkIP
Write-Host "Sinkholed: $domain → $sinkIP"
}
# On the sinkhole server (10.99.99.99): log all connection attempts
# Any web server with request logging enabled is sufficient
# IIS: check C:\inetpub\logs\LogFiles\
# nginx: access_log /var/log/nginx/sinkhole_access.log
VLAN Isolation
VLAN isolation moves a compromised host into a quarantine VLAN that has no routing to the rest of the network. Unlike EDR isolation, it works without any agent on the endpoint and is applied at the network switch.
# Cisco IOS — move a switch port to the quarantine VLAN
# SSH to the switch, then:
configure terminal
# Define the quarantine VLAN if it doesn't exist
vlan 999
name QUARANTINE-IR
exit
# Move the infected machine's port to quarantine VLAN
# First, identify the port by MAC address:
# show mac address-table address 00:11:22:33:44:55
# Find the interface column — e.g., GigabitEthernet1/0/12
interface GigabitEthernet1/0/12
switchport access vlan 999
shutdown ! optionally shut the port entirely for full isolation
no shutdown ! bring it back up in quarantine VLAN if you want network connectivity for mgmt
exit
end
write memory
# Verify
show interfaces GigabitEthernet1/0/12 trunk
show vlan brief | include 999
East-West Blocking Without Full Isolation
For ransomware spreading laterally, you may need to block specific protocols between workstations without isolating them completely. The goal is stopping SMB spread while maintaining RDP or WinRM for management.
Targeted East-West Block: Stop SMB Spread, Keep Management
═══════════════════════════════════════════════════════════════════
Without any block:
Workstation A ──SMB 445──► Workstation B ──SMB 445──► Workstation C
(ransomware spreads freely)
With SMB east-west block at L3 switch/firewall:
Workstation A ──SMB 445──✗ (blocked at switch/firewall ACL)
Workstation A ──RDP 3389──► Management workstation (allowed)
Management workstation ──RDP──► Workstation A (still manageable)
ACL at the workstation VLAN interface (Cisco IOS):
ip access-list extended BLOCK-SMB-EAST-WEST
deny tcp 10.1.0.0 0.0.255.255 10.1.0.0 0.0.255.255 eq 445
deny tcp 10.1.0.0 0.0.255.255 10.1.0.0 0.0.255.255 eq 139
permit ip any any
interface Vlan10
ip access-group BLOCK-SMB-EAST-WEST in
This stops: SMB from any workstation to any workstation
This allows: SMB from workstations to file servers (different subnet)
Workstation-to-workstation SMB is almost never legitimate in a well-managed environment. File shares should be on dedicated file servers. Blocking it by default — not just during incidents — eliminates the most common lateral movement path and blocks EternalBlue exploitation between workstations. The IR action of blocking it during ransomware response is also the right permanent security posture. Add it to the post-incident hardening list and push it via GPO or firewall policy permanently.
Proxy-Level Blocking
If all HTTP/HTTPS traffic routes through a forward proxy (Zscaler, Bluecoat, Squid, etc.), you can block C2 domains and known-malicious categories at the proxy level — this affects all HTTP-based C2 channels without any firewall change.
| Block method | What it stops | What it misses |
|---|---|---|
| Block by domain (exact) | HTTP/HTTPS to the specific C2 domain | C2 using IP directly, domain rotation, non-HTTP protocols |
| Block by URL category (malware/C2) | Broad category — catches unknown variants in same category | New domains not yet categorized, fast-flux C2 |
| Block by certificate (TLS inspection) | C2 using HTTPS with a specific cert — identified by cert fingerprint | Requires TLS inspection deployed and working |
| Block by user-agent string | Specific beacon user-agents (Cobalt Strike's default Mozilla/5.0 CS fake) | Trivially changed by attacker; only effective for unmodified toolkits |
Q & A
Q: You sinkhole a C2 domain. The attacker switches to a backup C2 IP-based connection that doesn't use DNS. The sinkhole doesn't help. What now?
Block the IP directly at the perimeter NGFW (as shown in the NGFW section above). For the longer term: use EDR isolation for affected hosts rather than relying on DNS sinkhole — EDR isolation blocks all network traffic regardless of whether the C2 uses DNS or direct IP. The sinkhole is useful for identifying which hosts are infected (by looking at who queried the sinkholed domain), but it's not a reliable containment mechanism for sophisticated C2 that has IP-based fallback. Think of sinkholing as an intelligence tool that also happens to provide partial containment, not as primary containment.
Q: You need to isolate a subnet with 200 machines but can't confirm which ones are compromised. Do you isolate the entire subnet?
If the threat is actively spreading and the entire subnet is at risk, yes — full subnet isolation is justified. This is a business disruption decision that requires authorization from CISO or the appropriate decision-maker. Document that the scope of confirmed compromise was X hosts, that the threat was spreading to adjacent hosts, and that subnet isolation was the chosen risk tradeoff. The alternative — waiting to confirm each host individually — risks the rest of the subnet being compromised before you can act. Quarantine VLAN approach is preferable to a hard shutdown: the machines can still be managed via the quarantine VLAN's routing to the management network while being isolated from everything else.
Q: The network team says making a VLAN change during business hours requires a change window. Ransomware is spreading right now. What do you do?
This is a pre-authorization failure that should be resolved before incidents happen. For IR containment actions, a standing "emergency change" authorization in the change management process should exist, allowing the IR lead (or CISO) to authorize emergency network changes with a post-hoc change record filed within 24 hours. If that standing authorization doesn't exist, the IR lead needs to escalate to whoever has authority to authorize the change now — CISO, CTO, or VP of Infrastructure. The network team following change management rules is correct behavior in isolation, but "the change window is next Thursday" is not an acceptable answer during an active ransomware event. This conversation must happen in a tabletop exercise, not at 2 AM.