SMB Brute Force or Authorized Scanner?
A network forensics analyst receives a 180 MB packet capture from a SPAN port on the core switch. The capture covers 13:00–13:10 UTC on a Tuesday. The SIEM flagged 4,800 SMB login failures from 10.10.5.23 to 38 hosts in 10.10.5.0/24. The source is an internal server named VULNSCAN01, which the vulnerability management team uses. The analyst sees 200 failed SMB logins to 10.10.5.42 in 90 seconds, followed by a successful SMB session, creation of a service named “PSEXESVC,” and extraction of a file named svchost.exe. The vulnerability team says it ran an authenticated scan at 13:00, but the scan was scheduled to target only 10.10.5.100–120. The server owner says VULNSCAN01 was patched last week and no one reviewed the scan credentials. The analyst must decide whether to declare an incident and what evidence to preserve.
1. Distinguish the evidence that supports malicious lateral movement from the evidence that is consistent with a legitimate scan.
Read the worked answer
The volume and failed-login pattern alone could resemble a scan, but several details break that explanation. The scan was scheduled for 10.10.5.100–120, yet the traffic hit 10.10.5.42 and 38 hosts across the /24; that is outside the authorized target range. A vulnerability scanner may authenticate, but it does not normally create a service named PSEXESVC or extract svchost.exe. Those are PsExec-like lateral-movement artifacts. The sequence - 200 failures in 90 seconds, then a success, then service creation and file extraction - is consistent with brute force followed by remote execution. The source being VULNSCAN01 is not exculpatory; a compromised scanner is a common pivot. The patched-last-week and unreviewed-credentials statements add uncertainty but do not explain the target mismatch. Declare a suspected incident, preserve the capture, and treat 10.10.5.42 as potentially compromised while confirming the file hash and service binary.
2. Outline the packet-level and host-level investigation steps, including specific filters and artifacts.
Read the worked answer
At packet level, filter SMB traffic between 10.10.5.23 and the /24, follow TCP streams for 10.10.5.42, and extract SMB2 SessionSetup responses to separate STATUS_LOGON_FAILURE from STATUS_SUCCESS. Look for NTLMSSP negotiate/challenge/authenticate exchanges, DCERPC service-control calls, and SMB writes of the service binary. Export the relevant frames and hash the original pcap. At host level, on 10.10.5.42 check Event ID 7045 for PSEXESVC, Security 4624 logon type 3, service registry keys, the dropped file’s hash and signature, prefetch, and autoruns. On VULNSCAN01, capture volatile data, running processes, scheduled tasks, and recent logons to determine whether it was compromised. Correlate timestamps across pcap, host logs, and SIEM. Check whether the same credentials or service name appear on other hosts. Keep the original pcap unmodified and work from a copy.
3. What should be preserved, and how should the finding be reported given the vulnerability team’s claim?
Read the worked answer
Preserve the full 180 MB pcap with a SHA-256 hash, the SPAN configuration, and the capture start/stop times. Collect volatile data and disk images or triage packages from VULNSCAN01 and 10.10.5.42 before remediation, plus authentication logs, service creation events, and EDR telemetry. Isolate both hosts from the network, but do not power them off if memory capture is pending. Report the finding as a suspected incident with a timeline, the authorized scan range, the observed target range, the PsExec artifacts, and a confidence statement. Explicitly note the conflict between the vulnerability team’s claim and the packet evidence, and ask them to produce the scan job ID and target list. Recommend credential resets for accounts used on the affected hosts and a hunt for PSEXESVC or svchost.exe drops across the /24. Do not let the ‘authorized scan’ explanation close the ticket without the job evidence.