Sep 24 2019 04:15 AM
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!
Feb 16 2020 06:23 AM
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.
Thanks,
Eyal Neemany.
Feb 16 2020 06:41 AM
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.
Thanks,
Tali
Feb 16 2020 08:25 AM
@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).
Thanks,
Eyal.
Mar 19 2020 04:23 AM
@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?
Oct 30 2020 05:22 PM
Dec 02 2020 08:21 AM
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
Dec 03 2020 01:55 AM
@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.
Dec 03 2020 04:34 AM
Dec 03 2020 04:43 AM
Jun 08 2021 07:33 AM