Enriched NTLM authentication data using Windows Event 8004


Have you previously experienced NTLM authentications activities that came from unknown devices, such as Workstation or MSTSC? Would you like to discover the actual server being accessed inside the network? This information is now available in Azure ATP!


Starting from Version 2.96, Azure ATP sensors parse Windows event 8004 for NTLM authentications. When NTLM auditing is enabled and Windows event 8004 are logged, Azure ATP sensors now automatically read the event and enrich your NTLM authentications activities display with the accessed server data.


New Resource Access over NTLM activity is now available, showing the source user, source device and the accessed resource:



Joye Parsons (1) is accessing CLIENT2 from W10-000100 device over NTLM.


Enriched Failed log on activities providing the destination computer the user attempted, but failed to access:



Joye Parsons (1) failing to log on to CLIENT2 from W10-000100 device over NTLM.


In a future release, this data will also be available directly in authentication based Azure ATP security alerts such as Brute Force and Account Enumeration.


Stay tuned for more updates. As always, your feedback and questions are welcome!

10 Replies

@Tali Ash 

Hi Tali!
It seems like event id 8004 is generated on the domain controller only when requesting NTLM auth, along with a valid domain name of that DC.
When supplying an empty domain name, local, or a different one, it's not generating that event.
When attackers often use Password-Spray attacks, they tend to not use a proper domain name.


Eyal Neemany.

Hi @SymEyal ,


In case there is no domain, the authentication won't get to the DC, it will be local.

Azure ATP does not have visibility to local authentications, as it sits on the DCs.


So Azure ATP has visibility only to authentications in the domain.




@Tali Ash 
Thanks for the fast response.
I just realized that only when the domain name is null when performing NTLM auth, event 8004 is generated along with the 4776 on the DC (and of course when the domain name is valid).











@Tali Ashhi - we enabled NTLM auditing however no 8004 events are generated despite 4776s being generated. We verified that NTLM auditing is enabled using gpresult.


Any tips to debug?

Hi, did you ever find a solution to events 8004 not being generated? I'm in the same situation.



Hi can I just add an additional question to this if I may.... 


Is there any pre-considerations around enabling for eventid 8004 on live DC's? 


Such as: 


1. Potential volume of event logs and potential knock on - local event ID file size/frequency of log overwrites?

2. DC local performance concerns once enabled? 

3. If using other complementary log forwarding solution (e.g. ATP Defender for Server) - knock on log volume ingestation to Log Analytics/Sentinel. 


Thanks in advance 



@Andy Loy 
1. I guess you should see an event for every 4776 you currently have.
It goes to a separate log,  not the default security log.

2. Never heard a report about a significant performance issue due to turning this on.

3. Can't tell. I guess you can estimate from answer #1 the increase, if at all this info will go there, as I mentioned, its a separate log.

@Eli Ofek 


Thanks Eli - Can I just follow on from your answer: 


"1. I guess you should see an event for every 4776 you currently have.
It goes to a separate log,  not the default security log." 


I found this that seems to suggest eventID 4776 is logged to Security event log?? 


Apols - misread your response @eli - you where implying 8004 eventIDs are logged to different log file location, as per https://techcommunity.microsoft.com/t5/ask-the-directory-services-team/ntlm-blocking-and-you-applica...

Thanks for your response and assistance! Appreciated.
Hi, where i configure this "NTLM authentication using Windows Event 8004" in domain controller or in the defender for identity standalone?. I have a implementation where i use defender for identity standalone with port mirroring. Thanks!