Some time ago I had to investigate a case in which a lot of failed login events were being received in the Domain Controller of a public organization (apparently a brute force attack). The events did not show which machine was being logged on. In some cases it showed the name of the connection source machine and in others it did not.

So I had a bunch of 4776 events (the DC tries to validate the credentials of an account using NTLM) but without the main information: “which device was being attacked?”

Some examples of the information delivered by event 4776:

Unfortunately, the organization didn’t have any security device to use to investigate (no one network security solution even Netwrix). Only the information that the Domain Controller / Active Directory itself.

So I considered trying Netlogon’s debug mode:

https://docs.microsoft.com/en-us/troubleshoot/windows-client/windows-security/enable-debug-logging-netlogon-service

For enable you must open a console prompt with administrator’s privileges and type the next:

Nltest /DBFlag:2080FFFF

Once enabled, the following file is created:

c:\Windows\debug\netlogon.log

Finally debug mode is disabled with the following command:

Nltest /DBFlag:0x0

This mode cannot be enabled for long as it presents performance issues. In this case I only enabled it for 15 minutes.

The result was a lot of entries with useful information:

04/15 12:17:02 [LOGON] [7256] DOMAIN: SamLogon: Transitive Network logon of (null)\admin from  (via VICTIM_HOSTNAME) Entered

From it I was able to obtain information that was not in the Windows Events:

• “Transitive Network logon”: It implies that the login attempt was registered on a computer and transmitted over the network, also known as “pass-through authentication”.
• “(null)\admin”: Indicates the user, in this case by having a “null” preceding the name, it can be interpreted as trying to authenticate a local user of a machine, not a domain user.
• “(via VICTIM_HOSTNAME)”: Finally, this last part indicates the computer against which the authentication attempt was made and therefore the computer that is actually being attacked.

A slightly old paper, but useful to understand this debug mode is:

“Tracking the Inside Intruder Using Net Logon Debug Logging in Microsoft® Windows® Server Operating Systems (Davis & River, 2004)”

Well the end of the story is that this organization had three servers with RDP ports exposed to the Internet (¬¬) and they were the ones that were being attacked.