Three-Minute Beacons and an SMB Sweep on a NetFlow-Only Network

Test the pattern against known-good agents first, then against the host itself.

Pattern-level checks:

• Named monitoring, backup, patch, and EDR cloud agents all beacon, but they do so from a population of hosts, not one. Query NetFlow for every internal host talking to that destination. A single source is suspicious; 700 sources is a product.
• Jitter, near-symmetric byte counts, and 24x7 weekend traffic fit an implant with a sleep timer better than most legitimate software, which usually follows business hours or configurable schedules.
• Hosting-provider ASN with no SNI-friendly reputation is weak evidence on its own - many SaaS vendors live there. Check the certificate and SNI in the SPAN capture.

Host-level checks (the decisive ones):

• Which process owns the connection? Query the endpoint or EDR for the socket-to-PID mapping and hash the binary.
• Is the binary signed, and does the signer match a vendor you have a contract with?
• Is there a matching scheduled task, service, or Run key created near the first observed connection?

The SMB fan-out to 60 hosts plus the 4624 type 3 spike is what decides the severity: that is lateral movement behaviour, so treat the host as compromised and the beacon as C2 until disproven.

Both - but isolate first, and think about what each action tells the actor.

• Isolate first. The host is actively sweeping SMB and generating type 3 logons. That is ongoing harm. Use EDR network containment that preserves your management channel rather than disabling the switch port, so you can still collect from the host.
• Capture before you contain if you have five spare minutes: memory image and current netstat/connection table. Once contained, the implant may self-delete.
• Blocking the IP alone is the weaker action, but not worthless. It stops the beacon and protects other hosts if any share the implant - but it also tips the actor, who switches infrastructure and may escalate (ransomware staging, wiping) on a shorter timeline. So block only after you have the host's process evidence, or block at the perimeter silently alongside isolation.
• Also block the destination for all hosts, not just this one, once you know the implant indicator - and hunt for the same destination elsewhere before the actor rotates.

Communication point: isolation means the user stops working. Tell the user's manager why in business terms (‘suspected malware; machine being rebuilt’) and set an expectation of hours, not days. Do not put the technical detail in the ticket the user can read.

Work outward from what you can actually see, and prioritise the domain controller.

Network layer (NetFlow, full coverage):

• Rare-destination analysis: external IPs contacted by exactly one internal host in the last 30 days.
• Periodic-flow detection: consistent byte counts, intervals under ten minutes, present overnight.
• Internal fan-out: one source hitting more than 10 destinations on 445/3389 within an hour.
• Any host that spoke to the same destination or the same /24.

Packet layer (SPAN, short retention):

• Pull the capture for this VLAN now, before it ages out. Extract SNI, certificate subject, and JA3/JA3S to fingerprint the implant and pivot on that fingerprint.

Host layer (servers only for now):

• On the DC: 4624 type 3 by source, 4768/4769 for anomalous service ticket requests, 4672 for unexpected special privileges, and new service creation (7045).
• On member servers: services, scheduled tasks, and local admin group changes in the same window.

Gap to state explicitly: workstations have no event forwarding, so 60 SMB targets cannot be verified from logs. Options are to enable forwarding now (forward-looking only), or to query the endpoints directly through whatever management tool exists. Say which one you chose and why.