Hey everyone! I've been going through the authentication logs on some Windows Servers (2015 and later), and while Kerberos is generally doing its job, I keep spotting entries related to NTLMv1. Here's the lowdown:
- Event ID: 4624 indicates a successful logon
- Logon Type: 3 suggests a network logon
- The Account seems to be ANONYMOUS LOGON from NT AUTHORITY
- The Authentication Package is NTLM with Package Name as NTLM V1
- The Source Info gives details like server name and source IP,
So, I'm seeing these anonymous attempts that are reverting to NTLMv1 instead of using Kerberos or NTLMv2. What I'm stuck on is figuring out which application or service on the source machine is making these NTLMv1 calls. Can anyone guide me on how to move away from NTLMv1 towards Kerberos or NTLMv2? Thanks a ton!
5 Answers
If you're dealing with a virtual machine, try restoring it to a sandboxed network setup, complete with a sandboxed domain controller and workstation. Disable NTLM there and see what breaks—this way you can test without affecting production.
Check what your policy is set to by following this link: https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/security-policy-settings/network-security-lan-manager-authentication-level. There's also this helpful guide: https://michaelwaterman.nl/2024/06/29/step-by-step-guide-to-windows-event-forwarding-and-ntlmv1-monitoring/#:~:text=Note!%20When%20Windows,see%20Microsoft%E2%80%99s%20documentation.
Honestly, many experts consider 4624 events with anonymous accounts to be a bit of a distraction—often referred to as a logging red herring. So, you might not need to worry about those.
You might want to enable the Group Policy setting to turn off NTLMv1 altogether. That could help push everything towards Kerberos or NTLMv2! Just be cautious about any critical applications that might still rely on NTLMv1, as they could break after this change.
For a more forensic approach, you could run ProcMon on the source machine. Filter it for sending network packets on the relevant port and watch for filtered events. That will give you a clearer picture of what’s making those calls. The good old 'scream test' might help too if you're in a rush!
I get that, but I'm worried it might disrupt some critical applications and servers!