Cybrary ForgeCYBRARY / FORGE

Network SOAR playbooks

Three response patterns cover every network case on the range. Each step names either a command the simulated estate really answers, or the automation node the SOAR engine runs in its place — so the playbook you read here is the playbook you can execute in a case.

Segmentation assurance

T1046
T1590

Trigger: An audit finding, a control test or a change window claims the corporate VLAN is separated from the server farm, the DMZ and the internet. Nobody has evidence.

  1. Detect

    • Establish where you actually are

      Read the seat's connected network and default route before believing any diagram.

      ip -br addr
      ip route
      enrichment node: host.network-facts
  2. Triage & scope

    • Walk the path across the core

      Trace to a server-farm address and record every hop that answers.

      traceroute 10.42.10.10
      dig dc-01.northwind.local
      gate · Name the inter-VLAN router before scanning anything.
    • Scan only what policy should permit

      Scan the permitted service and the forbidden one; the difference is the control evidence.

      nmap 10.42.10.8
      nmap -v -p 445 10.42.24.34
      action node: firewall.explain-decision
  3. Contain

    • Raise the rule, do not raise the host

      Segmentation gaps are fixed in the rule base. Isolating an endpoint hides the gap and proves nothing.

      gate · Change request references the numbered rule, not a hostname.
  4. Post-incident

    • File the control evidence

      Attach the scan output, the permitting rule id and the denying rule id to the audit finding.

      case.attach-evidence

Runbooks

Prove a deny is a deny

A control test needs evidence that a path is blocked, not merely unused.

nmap -v -p <port> <target>            # verbose reports the deciding rule
traceroute <target>                   # shows where the path dies
Record: source segment, destination segment, rule id, action, log flag.

Map a segment from a single seat

You have one endpoint and no network documentation.

ip route                               # connected CIDR + default gateway
nmap -sn <cidr>                        # live devices, gateway leg included
nmap -sV <host>                        # service versions and segment context

Rogue device on a corporate VLAN

T1200
T1557

Trigger: An unknown MAC appears on a user VLAN, or an endpoint starts resolving names through a host that is not the corporate resolver.

  1. Detect

    • Sweep the VLAN and diff against the asset list

      Everything that answers and is not an asset is a candidate.

      nmap -sn 10.42.26.0/24
      arp -a
  2. Triage & scope

    • Fingerprint the candidate

      Take its MAC, its open services and its OUI before touching it.

      nmap -sV <rogue-ip>
      ip neigh
      gate · Confirm it is not a sanctioned appliance mid-deployment.
    • Scope who is talking to it

      Find the endpoints holding sessions to the rogue address.

      ss -tnp
      nmap -v -p 53 <rogue-ip>
  3. Contain

    • Quarantine the port, not the users

      Move the switch port to the quarantine VLAN; the endpoints that trusted it stay up while you rotate what it may have captured.

      action node: nac.quarantine-port
      gate · Consequential — requires approval.
  4. Eradicate

    • Rotate anything it could have intercepted

      Credentials used over plaintext services while it was on the wire.

  5. Post-incident

    • Close the admission gap

      Record how it joined: open port, no 802.1X, or a bypassed guest VLAN.

Runbooks

Rogue triage in five commands

You have an unexpected address on a VLAN you own.

nmap -sn <cidr>                        # who is live
nmap -sV <rogue-ip>                    # what it offers
ip neigh / arp -a                      # MAC and OUI
ss -tnp                                # who is connected to it
Escalate with: IP, MAC, services, victims, first-seen.

Breach crossing a segment boundary

T1210
T1071.001
T1041

Trigger: A DMZ host reaches a server-farm host it has no business reaching, or a server-farm host opens an egress session to an unknown external address.

  1. Detect

    • Take the socket table before anything else

      Live sessions disappear the moment you contain. Capture them first.

      ss -tnp
      netstat -ano
      enrichment node: host.connections
  2. Triage & scope

    • Separate inbound pivot from outbound C2

      The source of the inbound session is the pivot; the destination of the outbound one is the C2.

      ss -tnp state established
      nmap -sn <local-cidr>
      gate · Both addresses named before any containment node runs.
    • Measure lateral reach from the compromised seat

      Scan what this host can actually reach; that is the blast radius, not the diagram.

      nmap -v -p 445,3389 <server-cidr>
  3. Contain

    • Cut egress at the rule, isolate the host

      Deny the egress rule that permitted the C2, then isolate the compromised host under approval.

      action node: estate.set-attribute (isolated=true)
      gate · Consequential — requires approval.
  4. Eradicate

    • Remove persistence on both sides of the pivot

      Service units, run keys and scheduled tasks on the pivot and the target.

      systemctl list-units --type=service
      schtasks
      reg query HKLM\...
  5. Recover

    • Restore the permitted path only

      Re-open the business flow, leave the abused one denied and logged.

  6. Post-incident

    • Timeline across the boundary

      Inbound pivot, lateral reach, egress session, containment — with rule ids at each hop.

      case.attach-evidence (timeline)

Runbooks

Egress kill decision

An internal host is beaconing outbound.

ss -tnp                                # remote address + PID
nmap -v -p <port> <remote>             # which rule permits it
Deny the rule, then isolate. Rule first: isolating alone leaves the path open for the next host.