![]() ![]() It’s recommended that you first audit your security log for instances of NTLM authentication and understand the NTLM traffic to your DCs, and then force Windows to restrict NTLM traffic and use more secure protocols. However, this could cause several NTLM authentication requests to fail within the domain, decreasing productivity. Reducing and eliminating NTLM authentication from your environment forces Windows to use more secure protocols, such as the Kerberos version 5 protocol. Logon attempts from an expired, disabled, or locked account could indicate possible intent to compromise your network.Īs discussed above, NTLM and NTLMv2 authentication is vulnerable to a variety of malicious attacks.Logon attempts from unauthorized endpoints, or attempts outside of business hours, could be indicators of malicious intent, especially for high-value accounts.Monitor this event for multiple logon attempts with a misspelled password within a short span of time to check for brute-force attacks on your network.Monitor this event for multiple logon attempts with a misspelled username within a short span of time to check for reverse brute-force, password spraying, or enumeration attacks.If local accounts should only be used directly on the respective machines where their credentials are stored, and never use network logon or Remote Desktop Connection, then you need to monitor for all events where Source Workstation and Computer have different values.You should monitor event ID 4776 to list all NTLM authentication attempts in your domain and pay close attention to events generated by accounts that should never use NTLM for authentication. NTLM should only be used for local logon attempts.The user is required to change their password at the next logonĮvidently a bug in Windows and not a risk ![]() ![]() The user tried to log on with a stale password ![]() The user tried to log on with an expired account The user attempted to log on from a restricted workstation The user tried to log on outside their day-of-the-week or time-of-day restrictions The username is correct but the password is wrong Source Workstation: The name of the computer the logon attempt originated from. The account can either be a user account, a computer account, or a well-known security principal (e.g. Logon Account: The name of the account that attempted a logon. Here are a few common cases where NTLM is used over Kerberos in a Windows environment:Įvent ID 4776 - The DC attempted to validate the credentials for an account.Īuthentication Package: This is always "MICROSOFT_AUTHENTICATION_PACKAGE_V1_0". That means event ID 4776 is recorded on the local machines.įor Kerberos authentication, see event IDs 4768, 4769, and 4771.Īlthough Kerberos authentication is the preferred authentication method for Active Directory environments, some applications might still use NTLM. In the case of logon attempts with a local SAM account, the workstation or the member server validate the credentials. That means event ID 4776 is recorded on the DC. In the case of domain account logon attempts, the DC validates the credentials. If the authenticating computer fails to validate the credentials, the same event ID 4776 is logged but with the Result Code field not equal to “0x0”. Authentication Failure - Event ID 4776 (F) If the credentials were successfully validated, the authenticating computer logs this event ID with the Result Code field equal to “0x0”. Authentication Success - Event ID 4776 (S) This event is also logged for logon attempts to the local SAM account in workstations and Windows servers, as NTLM is the default authentication mechanism for local logon. Event ID 4776 is logged whenever a domain controller (DC) attempts to validate the credentials of an account using NTLM over Kerberos. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |