This event is generated by Windows NTLM Auditing. It is useful for detecting NTLM brute-force attacks against non-DC endpoints.
These logs have two shockingly useful fields: Secure Channel Name and Workstation Name, but understanding them can be tricky.
First, understand that these logs are generated when a machine attempts direct authentication to an endpoint over NTLM. That means there must be a call to the DC to validate credentials. That will result in Event ID 4776 in conjunction with the 8004. But 4776s will not tell you where the auth attempts are coming from.
Workstation Name is the auth requester—the SMB client, for example. Secure Channel Name in most cases is going to be the hostname of the target computer. That’s true when Secure Channel Type is 2, meaning communication between a domain host and a domain controller.
These logs will reveal NTLM auth attempts that do not present 4624/2625 events on the DC. However, failures in this auth type will produce lockouts (Event 4740), which can seem confusing if you’re just looking for 4625 failures.
This is really interesting, really useful to use defaults to detect these kind of attacks, specially relay attacks.
Although I think the best way to detect relay attacks (although i don’t know how feasible it is) is with great asset inventory and having it connected to your SIEM tool. Given the nature of windows events, you only get Workstation Name.
If you somehow can get both the Workstation Name + Source IP and be able to compare that with your asset inventory, the source IP won’t match the one in the logs, even though the name does. Although this will prove difficult with rotating IPs of non-server endpoints.
I think that’s right for NTLM relay, but that’s not really what we’re talking about here. In this case we’re talking about password spraying or brute forcing a specific NTLM target.
Let’s say I have a malicious presence on a network. I am not domain joined; but I know about an SMB fileshare that I want to get access to. Now let’s say I start brute forcing that target directly. Let’s also suppose that I’m not collecting local login events (4624, 4625) from endpoints because doing so for every endpoint in the environment is bananas. You log from the domain controllers only. So the logon failures are invisible to the SIEM at the point.
This is why NTLM enhanced logging is nice. Event 8004 is sent from the target host to the domain controller for logging, independent of the 4624/4625s. And this event, unlike 4625, will have the hostname attempting authentication. This is useful both to identify legitimate sources and spoofed hostnames.
Here’s a real-world example, slightly modified to protect the innocent:
For some extremely exotic reasons, we ended up with an endpoint device exposed to the raw internet in such a way that RDP was available. Suddenly, a ton of account lockouts started occurring. This was confusing because we saw no correlating 4625s for failed logins from the domain controllers. However, Event 8004 revealed a massive spike, all with the same Secure Channel Name. That pointed us in the necessary direction to find the exposed device and lock it down. The internet was hammering it with username lists, and of course we’re big enough that the lists had hits. Without 8004, I don’t really know how we would have found this activity.
