The scenario is fictional (10.0.0.0/8). The fan-out aggregation was tested on a synthetic firewall log.

A burglar tries doors one by one. On a network that is one host connecting to many internal hosts on the same port, in a short window. Each connection looks ordinary; the pattern doesn't.

What you'll learn

  • How fan-out appears in firewall logs
  • A one-line aggregation
  • Why DROPs matter
  • Confirming with authentication logs; false positives

The story at a glance

09:12:03 WS01 -> FS01:445 (business hours, single destination: normal). 02:31:06-07 WS01 -> many hosts:445, ALLOW and DROP mixed, reaching DC01.

normal 09:12:03 ALLOW TCP 10.0.0.21 10.0.0.31 50410 445 attack 02:31:06 ALLOW TCP 10.0.0.21 10.0.0.41 50221 445 02:31:06 DROP TCP 10.0.0.21 10.0.0.55 50233 445 # hosts that don't exist 02:31:07 ALLOW TCP 10.0.0.21 10.0.0.10 50244 445

Differences: time of day, number of destinations, and DROPs. Probing nonexistent hosts means searching, not working.

Aggregation 

awk '$7==445 { k=$4" "substr($1,1,5) if (!((k,$5) in seen)) { seen[k,$5]=1; n[k]++ } if ($2=="DROP") d[k]++ } END { for (k in n) if (n[k]>=10) printf "FANOUT src=%s dst=%d drop=%d\n", k, n[k], d[k] }' fw.log

On a synthetic log: FANOUT src=10.0.0.21 02:31 dst=13 drop=8. A host repeatedly using one file server was not reported. Tune the threshold on your baseline.

Confirm with authentication

The firewall shows attempts. FS01's 4624 (type 3) from WS01 and 5140 (ADMIN$) show success (book; not tested here).

False positives

Vulnerability scanners, asset management and monitoring do this too. Allow-list authorized sources, time windows and ranges narrowly.

Defense

Restrict workstation-to-workstation SMB and aggregate "one internal host to many destinations" continuously.

Next: persistence on Windows.

Adapted from chapters 17 and 27 of my Japanese book on server defense.