Keypoints
- A vishing call spoofing the IT support number tricked a remote employee into approving an MFA request, allowing the attacker to access the network via the employee’s VPN session.
- The attacker appeared on-network using the legitimate username and static IP, then performed anomalous NTLM authentications from an unfamiliar hostname.
- Reconnaissance included LDAP queries to domain controllers, HTTP GETs indicative of Nmap (URI ‘/nice ports,/Trinity.txt.bak’), reverse DNS lookups, and port scanning (notably port 9401).
- Multiple failed NTLM authentication attempts using a generic Windows credential indicated brute-force lateral movement attempts and suspicious SMB activity targeting internal resources.
- Darktrace’s Cyber AI Analyst autonomously correlated events into a single incident, providing a consolidated timeline and explanations of attack phases.
- Autonomous Response actions were applied immediately: blocking outgoing traffic, enforcing pattern-of-life, and blocking connections to ports 445 and 9401, containing the intrusion.
- The incident demonstrates how social engineering to bypass MFA can be combined with VPN proxying and internal reconnaissance to escalate access, and how anomaly-based detection can stop such campaigns.
MITRE Techniques
- [T1200] Hardware Additions – Mapped in the article as an initial access category related to the intrusion method (‘INITIAL ACCESS – T1200 – Hardware Additions’)
- [T1046] Network Service Scanning – Attacker performed internal service and port scans (observed activity on port 9401), indicating discovery of available services (‘DISCOVERY – T1046 – Network Service Scanning’)
- [T1482] Domain Trust Discovery – Activity included queries and reconnaissance against domain controllers to learn AD relationships (‘DISCOVERY – T1482 – Domain Trust Discovery’)
- [T1590] Gather Victim Network Information (IP Addresses) – Reconnaissance sought internal IP information and reverse DNS lookups (‘RECONNAISSANCE – T1590 – IP Addresses’)
- [T1590.002] DNS – Attacker performed reverse DNS lookups against internal addresses as part of mapping the environment (‘T1590.002 – DNS’)
- [T1590.005] IP Addresses – Use of static VPN-assigned IPs to masquerade as legitimate remote user connections (‘T1590.005 – IP Addresses’)
- [T1592] Gather Victim Host Information (Client Configurations) – Attacker enumerated client/host configurations and hostnames during reconnaissance (‘RECONNAISSANCE – T1592 – Client Configurations’)
- [T1592.004] Client Configurations – Observed differences in hostname within NTLM requests indicated client configuration anomalies (‘T1592.004 – Client Configurations’)
- [T1595] Active Scanning (Scanning IP Blocks) – Attacker scanned internal IP ranges and services to locate targets (‘RECONNAISSANCE – T1595 – Scanning IP Blocks’)
- [T1595.001] Scanning IP Blocks – Explicit internal IP block scanning was observed as part of discovery (‘T1595.001 – Scanning IP Blocks’)
- [T1595.002] Vulnerability Scanning – HTTP GET patterns and Nmap-style URIs suggested automated scanning for open services and vulnerabilities (‘T1595.002 – Vulnerability Scanning’)
Indicators of Compromise
- [URI] Unusual scan input – /nice ports,/Trinity.txt.bak (HTTP GET indicative of Nmap usage)
- [Port] Suspicious ports observed – 9401 (internal scanning activity), 445 (SMB activity targeted and later blocked)
- [Authentication] NTLM anomalies – failed NTLM authentication attempts using a generic/default Windows credential; NTLM auth showed an unexpected hostname in the request
- [Network] Static VPN-assigned IP context – remote user’s static IP was used by the attacker to proxy into the VPN and initiate SMB sessions (specific IP not published)
- [Hostname] New/unknown hostname – a hostname not previously seen on the network appeared in NTLM requests and was correlated with the compromise
During the incident, the attacker gained initial access by spoofing the IT support phone number and convincing a remote employee to approve an MFA prompt; the attacker then proxied into the corporate VPN using the employee’s static IP and legitimate username. Anomaly detection flagged that NTLM authentication requests originated from a different hostname than expected for that static IP, leading investigators to treat the login as suspicious. The attacker proceeded to perform internal reconnaissance: a 53-second LDAP bind and search against a domain controller to enumerate AD accounts, HTTP GETs consistent with Nmap (notably the URI ‘/nice ports,/Trinity.txt.bak’), reverse DNS lookups, and port scanning activity observed on port 9401.
Following reconnaissance, lateral movement attempts were visible as numerous failed NTLM authentication requests using a generic Windows credential, indicating brute-force activity and SMB-targeted scanning. Darktrace’s Cyber AI Analyst automatically correlated these events into a cohesive incident timeline, linking the anomalous NTLM hostname, LDAP queries, HTTP GETs, reverse DNS sweeps, and scanning behaviors. This correlation provided clear visibility into the attack phases: initial MFA bypass via social engineering, VPN proxying, discovery, and lateral movement attempts.
Darktrace’s Autonomous Response, configured in autonomous mode for the customer, rapidly applied containment actions to the compromised remote user: blocking all outgoing traffic, enforcing the environment’s learned pattern-of-life, and blocking connections to ports 445 and 9401. These mitigations halted SMB sessions, stopped ongoing scans, and prevented the attacker from progressing further, demonstrating how anomaly-based detection plus automated containment can interrupt vishing-driven intrusions that leverage MFA approval and VPN proxying.