SMB Brute Force Detection & Network Telemetry Analysis

Simulated an SMB authentication brute force attack against a Windows Server 2019 Active Directory domain controller and correlated reconnaissance, packet-level SMB/NTLM evidence, Security Onion telemetry, and Windows authentication events in Splunk.

PROJECT OVERVIEW

This project demonstrates how a SOC analyst can detect and investigate SMB authentication brute force activity in a Windows Active Directory environment. A Kali Linux workstation was used to enumerate the SMB service on a Windows Server 2019 domain controller and launch repeated authentication attempts with Metasploit’s smb_login auxiliary module.

The investigation combined evidence from Nmap, Metasploit, Wireshark, Security Onion, Zeek, and Splunk. The objective was to trace the activity from initial SMB reconnaissance through repeated failed logons and eventual successful authentication, while showing how network and host telemetry complement one another during a SOC investigation.

OBJECTIVES

– Confirm that SMB was exposed on TCP port 445.
– Enumerate supported SMB protocols and related service information.
– Simulate repeated SMB authentication attempts against multiple test accounts.
– Capture SMB2 and NTLM authentication exchanges in Wireshark.
– Identify failed and successful NTLM authentication activity in Security Onion.
– Investigate Windows Event IDs 4625 and 4624 in Splunk.
– Correlate the attacker IP, target server, usernames, failures, and successful logons.
– Document the full investigation using a repeatable SOC workflow.

LAB ENVIRONMENT

– Kali Linux attack workstation: 192.168.3.1
– pfSense firewall/router
– Windows Server 2019 domain controller: SRV.test.local / 192.168.1.100
– Windows 11 domain client
– Security Onion
– Zeek
– Wireshark
– Splunk Enterprise
– VMware Workstation
– Active Directory test domain

LAB TOPOLOGY

Use the same segmented lab topology used in the RDP and Nmap projects. Kali Linux represents the source of the SMB authentication attempts, pfSense routes traffic between lab networks, Windows Server 2019 provides Active Directory and SMB services, Security Onion monitors network traffic, and Splunk receives Windows Security logs.

Segmented VMware lab used to simulate SMB authentication brute force activity from Kali Linux against a Windows Server 2019 Active Directory domain controller while Security Onion and Splunk monitored the attack.

PHASE 1 — SMB RECONNAISSANCE

Nmap was used to verify that TCP port 445 was open and to enumerate the SMB protocols and related service behavior exposed by the Windows Server target.

Figure 1. Nmap confirms that TCP port 445 is open and identifies the SMB protocol dialects supported by the Windows Server target.

Additional Nmap scripts were used to test share, domain, user, and brute-force-related enumeration capabilities. Some enumeration attempts returned limited information or script errors, but the results still confirmed the availability of SMB on the target.

Figure 2. Additional Nmap SMB enumeration attempts against the Windows Server target, including share, domain, user, and brute-force-related scripts.

PHASE 2 — METASPLOIT SMB AUTHENTICATION ATTACK

Metasploit’s auxiliary/scanner/smb/smb_login module was configured with the domain controller as the target and custom username and password files.

Figure 3. Metasploit smb_login module configured with the target server, username list, and password list before launching the authentication test.

The module generated repeated authentication attempts against TCP port 445. Most attempts failed, while valid credentials were eventually identified for test accounts. Password values were redacted before publication.

Figure 4. Metasploit SMB authentication results showing numerous failed attempts followed by successful credential discovery. Visible password values were redacted.

PHASE 3 — SECURITY ONION AND ZEEK INVESTIGATION

Security Onion was queried for Zeek connection and NTLM events associated with the Kali Linux source IP. The hunt isolated SMB-related traffic to the Windows Server target on TCP port 445.

Figure 5. Security Onion Hunt query targeting Zeek connection and NTLM events generated by the source at 192.168.3.1.

The event table showed repeated connections to the domain controller and included the ntlm.success field. This allowed successful authentication activity to be separated from failed attempts.

Figure 6. Zeek NTLM and connection events showing repeated SMB sessions and a successful NTLM authentication indicator.

A detailed Zeek NTLM event confirmed the source and destination IP addresses, destination port 445, username, workstation name, server DNS name, and ntlm.success=true.

Figure 7. Detailed Zeek NTLM event confirming successful authentication from the Kali Linux source to SRV.test.local over TCP port 445.

Security Onion also preserved SMB reconnaissance connections generated by Nmap before the brute-force phase.

Figure 8. Zeek connection records showing SMB reconnaissance traffic to TCP ports 445 and 137 before the authentication attack.

PHASE 4 — WIRESHARK PACKET ANALYSIS

Wireshark was used to examine the packet-level behavior of the attack.

Repeated TCP SYN packets were observed from the Kali Linux host to TCP port 445, representing the creation of many SMB connections during the authentication attempts.

Figure 9. Repeated TCP SYN packets from 192.168.3.1 to 192.168.1.100 on destination port 445. VMware MAC addresses were redacted.

The SMB2 session setup sequence showed NTLMSSP negotiation, challenge messages, authentication requests, and repeated STATUS_LOGON_FAILURE responses for invalid credentials.

Figure 10. SMB2 session setup traffic showing repeated NTLM authentication attempts and STATUS_LOGON_FAILURE responses.

NTLM challenge packets exposed useful server metadata, including the NetBIOS domain, server name, and DNS domain used within the isolated lab.

Figure 11. NTLM challenge details revealing the lab NetBIOS domain, server name, and DNS domain during SMB authentication.

Authentication requests contained the test username and workstation information submitted to the domain controller.

Figure 12. NTLMSSP authentication request showing the test account and workstation information presented to the server.

Filtering for SMB2 status code 0xC000006D isolated the server responses associated with failed logons.

Figure 13. Repeated SMB2 STATUS_LOGON_FAILURE responses generated by invalid username and password combinations.

The complete TCP port 445 stream also showed SMB negotiation, session setup, encrypted transport data, and connection resets as the tool moved between authentication attempts.

Figure 14. SMB negotiation, session setup, encrypted traffic, and TCP resets observed across repeated authentication attempts.

PHASE 5 — SPLUNK WINDOWS EVENT INVESTIGATION

Windows Security logs were forwarded to Splunk.

Event ID 4625 was used to identify failed authentication activity. The search grouped failures by account name, source network address, failure reason, and workstation name. The same Kali Linux source IP appeared repeatedly across multiple accounts.

Figure 15. Splunk analysis of Event ID 4625 showing repeated failed logons from 192.168.3.1 against multiple test accounts.

Event ID 4624 was reviewed to identify successful logons and associated logon types.

Figure 16. Splunk analysis of Event ID 4624 showing successful authentication events and their associated source addresses and logon types.

A combined search assigned each event a failed or successful outcome and grouped the data by account, source IP, and result.

Figure 17. Combined Splunk correlation showing failed and successful authentication outcomes for the targeted test accounts.

The second page of the correlation results confirmed additional account and source combinations while separating unrelated background authentication activity from the simulated attack.

Figure 18. Additional correlated authentication results used to distinguish the simulated attack from normal Windows background logons.

A timechart grouped Event ID 4625 failures into five-minute intervals, revealing a concentrated spike during the brute-force activity.

Figure 19. Five-minute Splunk timechart showing the concentrated burst of failed authentication attempts generated during the attack.

INVESTIGATION FINDINGS

– SMB was exposed on TCP port 445 on the Windows Server 2019 domain controller.
– The activity originated from Kali Linux at 192.168.3.1.
– The target was SRV.test.local at 192.168.1.100.
– Nmap confirmed SMB availability and supported protocol dialects.
– Metasploit generated repeated authentication attempts across multiple test accounts.
– Wireshark confirmed SMB2 negotiation, NTLM challenge-response exchanges, and repeated STATUS_LOGON_FAILURE messages.
– Security Onion and Zeek recorded the SMB connections and identified successful NTLM authentication.
– Splunk Event ID 4625 documented repeated failed logons.
– Splunk Event ID 4624 confirmed successful authentication events.
– The same source IP was associated with repeated failures and later successful logons.
– Correlation across network and host telemetry established a clear SMB brute-force pattern.

RESULT

The lab successfully demonstrated the full detection lifecycle of an SMB authentication brute-force attack against a Windows Active Directory domain controller. The investigation connected reconnaissance, repeated credential attempts, packet-level SMB and NTLM behavior, successful authentication, Windows Security events, and SIEM correlation into one defensible incident timeline.

The project also demonstrated the value of using multiple telemetry sources. Wireshark explained the protocol behavior, Security Onion and Zeek provided searchable network metadata, and Splunk connected the activity to Windows accounts and authentication outcomes.

TECHNOLOGIES USED

Kali Linux, Nmap, Metasploit Framework, pfSense, Windows Server 2019, Active Directory, Windows 11, Wireshark, Security Onion, Zeek, Splunk Enterprise, and VMware Workstation.

SKILLS DEMONSTRATED

– SOC investigation
– SMB protocol analysis
– NTLM authentication analysis
– Active Directory security monitoring
– Brute-force and password-spray detection
– Windows Event Log analysis
– Splunk search and correlation
– Security Onion threat hunting
– Zeek log analysis
– Wireshark packet analysis
– TCP/IP troubleshooting
– Incident documentation
– Cross-platform evidence correlation

KEY TAKEAWAYS

This project reinforced that SMB authentication attacks produce evidence at several layers. Packet captures reveal the SMB2 and NTLM exchanges, Zeek provides structured authentication metadata, and Windows Security logs connect the traffic to accounts and logon outcomes.

A pattern of repeated failures from one source followed by successful authentication is a high-value detection opportunity and should trigger immediate investigation.

RECOMMENDED MITIGATIONS

– Enforce multi-factor authentication where supported.
– Apply account lockout and smart password policies.
– Restrict SMB access to approved hosts and trusted network segments.
– Disable SMB exposure across untrusted network boundaries.
– Monitor Event IDs 4625 and 4624 for repeated failures followed by success.
– Alert when one source attempts authentication against many accounts.
– Use strong, unique passwords and prevent password reuse.
– Disable inactive accounts and review privileged group membership.
– Segment domain controllers from general user and untrusted systems.
– Combine network monitoring with centralized Windows logging.
– Investigate unusual NTLM activity and reduce NTLM usage where operationally possible.