Network Containment Actions — Blocks, Blocks, and What to Block

Network containment is the bridge between investigation and remediation. A vague block request can cause an outage worse than the attack. A precise, well-specified block stops the threat without collateral damage.

The Containment Action Decision Tree

Is the attacker currently active (live session)?
│
├─YES → Isolate host first (EDR isolation) → THEN block
│         Reason: blocking without isolation alerts attacker;
│         host isolation is atomic and cuts all channels
│
└─NO  → Direct block (no active session to alert attacker)
          ↓
          What are you blocking?
          ├─ IP address → verify it's not a CDN
          │               → firewall outbound block, specific port if possible
          ├─ Domain    → DNS sinkhole (preferred — catches all infected hosts)
          │               → proxy URL block as backup
          └─ URL path  → proxy block (domain may be legitimate; path is malicious)

Block Specification Format

IP Block

ACTION: Outbound Block — IP
Target: 185.220.101.7
Protocol: TCP
Port: 443
Direction: Outbound (from internal network)
Duration: Until IR ticket IR-2024-0892 closes, then review
Risk check: Not a CDN IP (confirmed via ipinfo.io — this is a single-tenant Tor exit node)
Justification: Confirmed C2 IP for Cobalt Strike beacon on CORP-PC-022 (see alert TKT-4421)
Owner: firewall-team

Domain Block (DNS Sinkhole)

ACTION: DNS Sinkhole
Target: update.windowsmirror.net
Sinkhole IP: 10.0.0.250 (internal sinkhole address for logging)
Duration: Permanent (attacker-registered domain, no legitimate use)
Risk check: No legitimate business purpose (domain registered 9 days ago, not a vendor)
Additional: Also block at proxy (in case of DoH bypass)
Justification: C2 domain for Cobalt Strike beacon (see alert TKT-4421)
Side effect: Will reveal any other hosts querying this domain — check sinkhole logs
Owner: dns-team

URL Block (Proxy)

ACTION: URL Block at Proxy
Target: https://legitimate-cdn.com/malicious-path/payload.exe
Method: Block full URL (not the domain — domain serves legitimate content)
Duration: 90 days, then review
Risk check: legitimate-cdn.com serves other content — DO NOT block the domain
Justification: Phishing attachment delivery URL — malware download confirmed via sandbox
Owner: proxy-team

What Not to Block (Without Checking First)

Target	Risk	Safer Alternative
CDN IPs (Cloudflare, AWS)	Blocks thousands of unrelated domains	Block domain at DNS/proxy
`*.microsoft.com`	Breaks Office 365, Azure	Block specific subdomains only
Large ASNs (e.g., /8 block)	Massive collateral damage	Block specific IPs or /24 at most
Google Drive domain	Breaks all GDrive access	Block at CASB; restrict by account
Port 443 outbound	Breaks all HTTPS	Block specific IPs/domains only

Sinkhole Monitoring

When you sinkhole a C2 domain, every host that queries it is revealed:

# Sinkhole server logs (10.0.0.250):
14:32:01  query from 10.1.2.3  for windowsmirror.net  → sinkholed
14:32:08  query from 10.4.5.6  for windowsmirror.net  → sinkholed   ← NEW VICTIM
14:32:15  query from 10.1.7.8  for windowsmirror.net  → sinkholed   ← NEW VICTIM

A sinkhole that shows 3 internal hosts querying the C2 domain means 3 infected hosts — not just the one you found originally. The sinkhole turns a single-host investigation into a campaign scope assessment.

Post-Block Validation

After implementing blocks, verify they’re effective and not causing collateral damage:

1. Confirm block is in effect:
   - From an internal test machine: attempt connection to blocked IP/domain
   - Should fail (connection refused or DNS NXDOMAIN from sinkhole)

2. Confirm no collateral damage:
   - Check service monitoring dashboards for alerts in the 10 minutes post-block
   - Check helpdesk for user tickets related to the blocked scope
   - Spot-check that related legitimate domains still resolve

3. Monitor for C2 fallback:
   - After host isolation + C2 block, watch for new outbound connections
     from adjacent hosts — the malware may have already spread

Worked Example

Containment action set: AiTM phishing with HTTPS C2

Incident: AiTM phishing compromised jdoe@corp.com. Session token stolen. Additionally, Sysmon evidence shows a Cobalt Strike beacon on CORP-PC-077 (jdoe’s machine) connecting to cdn-cache-update.net IP 91.213.50.22:443.

Containment actions required:

Identity layer (handled separately — see M18 ticket format):

Revoke jdoe’s sessions
Remove inbox rules
Force MFA re-enrollment

Network layer:

Action 1: DNS Sinkhole
  Target: cdn-cache-update.net (C2 domain)
  Sinkhole: 10.0.0.250
  Duration: Permanent
  Risk: No legitimate use (registered 11 days ago, VirusTotal flagged)
  Side effect: Monitor sinkhole for additional querying hosts

Action 2: Outbound IP Block
  Target: 91.213.50.22/32
  Port: 443
  Direction: Outbound
  Duration: Until IR close + 90 day review
  Risk: Not a CDN — single-tenant VPS (confirmed: Hetzner ASN, no other domains)

Action 3: URL Block at Proxy
  Target: https://secure-docs.corp-finance.net/auth (AiTM phishing URL)
  Method: Block full domain (corp-finance.net is attacker-registered)
  Duration: Permanent
  Risk: No legitimate content at corp-finance.net

Action 4: Email Gateway Block
  Target: corp-finance.net sender domain
  Duration: Permanent

Sequence (order matters):

EDR isolation of CORP-PC-077 first (active C2 session; block without isolation alerts attacker)
Identity containment (M18 sequence — remove inbox rules, revoke sessions)
DNS sinkhole + IP block (now safe to block — host is isolated)
Proxy URL + email gateway blocks
Monitor sinkhole for 48 hours for additional infected hosts

Post-block validation:

Verify CORP-PC-077 is isolated (cannot reach corp network or internet)
Check sinkhole logs for 24 hours — no additional hosts querying cdn-cache-update.net (good) or additional hosts (scope is larger than one host)
Monitor helpdesk for any reports of broken services

Retrieval Practice

You've identified a C2 beacon to 104.26.13.79:443. Before submitting an IP block request, you check and find this is a Cloudflare IP. What action do you take instead and why?

Reveal answer

Do not block 104.26.13.79/32. This Cloudflare IP serves thousands of websites — blocking it would take down all of those sites for your users, causing an outage far worse than the C2 beacon. Instead: (1) Check ssl.log for the SNI — what domain did the C2 client connect to? This gives you the C2 domain even though it's proxied through Cloudflare. (2) Block the C2 domain at DNS/proxy (sinkhole or proxy URL block). The domain will resolve to a different Cloudflare IP if the first is blocked, but blocking at the DNS level blocks the domain regardless of which IP it resolves to. (3) Alternatively, block via Cloudflare abuse reporting to take down the domain at the CDN level. Note: if there is no SNI (empty server_name), the C2 is using a Cloudflare IP directly without a domain — in this case, check with the firewall team whether a specific rule can block this flow without using the shared IP.

Retrieval Practice

Security engineering asks: 'Can we just block all of TCP/8080 outbound to stop the Emotet C2?' You find Emotet is using port 8080 for C2. What is the risk of a blanket port 8080 block and what is a more precise alternative?

Reveal answer

Port 8080 is a common alternative HTTP port used by many legitimate services: internal web applications, development servers, some SaaS proxies, and network management tools. A blanket outbound block on TCP/8080 will break all outbound connections to any service on port 8080 — potentially disrupting legitimate business applications. More precise alternatives: (1) Block specific destination IPs (Emotet C2 IPs) on port 8080 — doesn't affect other port 8080 destinations. (2) DNS sinkhole the Emotet C2 domains (blocks all ports the C2 might use, not just 8080, without touching other port 8080 traffic). (3) If port 8080 outbound has no legitimate business need in your environment, document that first, then propose a graduated block (start with monitoring, confirm no legitimate traffic, then block). Always verify business impact before any broad protocol/port block.