How to find the source IP of 4776 events?

Brass Contributor

Can Azure ATP help me in identifying the source IP of a 4776 event (The domain controller attempted to validate the credentials for an account)?
Now often there is no source (IP/computer) information at all, or it shows something generic such as "Workstation" but having the IP address where the request was coming from would help a lot.

As Azure ATP is capturing the traffic on the DCs NIC I would expect that it can report something?

I'll guess that the 'old' way of figuring out such things would be to put the DCs in netlogon logging mode; but maybe there's an easier/better way now with Azure ATP?



7 Replies
Thanks Eli, let me check if that's enabled already or not. Do I understand you correct that this would show the source IP of where the logon attempt was originating from?

@Duncan de Waal Normally yes, but it might miss a few, as not all the info might be available at all time from the OS due to various reasons, but it's surely recommended to turn this on.

Is there a documentation explaining how to mitigate missing events? It seems odd that Windows is unable to capture the source IP of all authentication attempts.

@truekonrads ,I  don't know about the specific issues that might cause that, only that I have heard such edge cases happen in complicated AD scenarios. in addition to that, ATP needs to do event correlation, based on sliding windows, while this gives very good results, it's not perfect, so in edge cases we might not be able to correlate the events correctly and won't be able to match the events to provide full data. 

In general. if you enabled all the suggested events, you are in a good state ATP wise.

I have the same issue as yours, no 8004 event generated. Did you fix your issue?

@NaturelDragon Not sure if this helps, but the 8004 events don't get logged to the Security Log, it took me a while to figure it out, instead they are in the windows > NTLM > Operational log. All the docs about this don't mention where the event gets generated and obviously everyone just assumes it will be in the Security log with the reset of the Audit messages.