In this blog, we will describe the workflow the Varonis IR Team uses to investigate NTLM brute force attacks, which are a common type of attack they see in the wild.
If you find any of these alerts in the Varonis Alert Dashboard, you may be experiencing an NTLM Brute Force Attack.
Get the Free Pen Testing Active Directory Environments EBook
- Password spraying from a single source
- Account enumeration via NTLM
- Multiple account lockouts
You can also search for all failed authentication behavior in the Varonis Dashboard to look for suspicious activity that you want to investigate.
1. Initial investigation in Varonis
Click Analytics in the Varonis Dashboard.
Select DirectoryServices in the Servers dropdown.
Filter Event Type for “Account Authentication” This will give you all of the events related to attempted logins for the specified time.
You are looking for failed logins for unknown users, which can indicate a dictionary attack for generic account names like “administrator” or “service”. Varonis shows these as “Abstract/Nobody” because they don’t exist in AD and we don’t have any reference data for these accounts.
The “Device Name” is going to be a spoofed device name from the attacker’s authentication requests. Most likely, you won’t recognize these device names and they will not follow your corporate naming conventions. Attackers commonly use device names like “workstation” or “mstsc” in the hopes you won’t discover their activity. Sometimes they’ll leave the device name entirely empty.
Once you have determined there is a possible brute force attack you need to research, you need to dig deeper into the logs.
Search for all failed NTLM authentications by filtering with “event description ‘contains’ NTLM,” “Event Status = Fail,” and “Event Type = TGT Authentication.”
Search for all successful authentications from the device names used by the attackers, to validate there are no immediate signs of account compromise.
Take note of the “Collection Device Hostname” for these authentication attempts. This is the Domain Controller (DC) we need to prioritize during for the next phase of the investigation.
2. Preparing NTLM auditing
Highlight the Default Domain Controllers Policy – so we can get events on all domain controllers.
Right-Click Default Domain Controllers Policy and select Edit.
The Group Policy Management Editor will open. Scroll down and select “Security Options.”
Change these values by right-clicking and selecting “Properties”.
- Network security: Restrict NTLM: Audit Incoming Traffic = Enable auditing for all accounts
- Network security: Restrict NTLM: Audit NTLM authentication in this domain = Enable all
- Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers = Audit all
Run “gpupdate /force” from your command line of choice to apply these changes.
3. Investigating NTLM logs
Navigate to the DC that you identified based on “Collection Device Hostname” in step 1.
Open Event Viewer and go to Application and Services Logs>Microsoft>Windows>NTLM>Operational. Right-click on Properties, and expand the storage size of this log from the default 1MB to a larger size (we recommend 20MB).
Event ID 8004 events will be associated with malicious authentication activity.
Search for the device name or user names we saw the attacker using in Step 1. Now you will be able to see the “Secure Channel Name.” This is the device the attacker is targeting.
*You will only see new NTLM events in the log after you complete step 2.
Once we identify the victim device we can investigate how the attacker is sending these authentication attempts. Check firewall logs for connection activity that occurred at the same time as the authentication attempts. You connect to the victim device and then use tools like net stat (plus appropriate flags) or Wireshark. What we are looking for is the IP address and port the attacker is using to send the authentication requests. Once we have this information we can take remediation action such as blocking specific IPs from the firewall or closing certain ports.
*There is a possibility of malware infection on this device. Tread carefully.
Finally, to complete the investigation we need to review all authentication activity by user accounts on the victim device and any other alerts coming from that device. Lastly, we should review Varonis and NTLM logs to confirm these authentication attempts have stopped, and continue to be on guard for new Brute Force NTLM activity.
Special thanks to Chris Kelly, Dymytriy Zyunkin, and Moshe Stein of the Varonis Incident Response Team for their contributions to this guide.
The Varonis IR Team provides free cybersecurity analysis and remediation to Varonis customers. Contact your Varonis Sales Team for details!