Where Sign-In Evidence Lands: Active Directory Sign-In

Why It Matters

One sign-in leaves pieces on the client, the server and whichever domain controller answered, so one machine's log tells only part of the story. An investigation that skips a DC can miss the only record of a sign-in.

What Happens

Proof of identity is logged where the account lives, and access where it was granted. For a domain account, that means the Security log of the domain controller that answered and then that of the server reached. For a local account both land on the machine itself, so event 4776 in a member server's Security log means a local account was used there.

Any domain controller can answer, and each writes what it checked to its own Security log, so collect them all. One account's Kerberos tickets and NTLM checks can be spread across every DC, and a gap on one looks just like a quiet account.

A single desktop sign-in writes many events across two machines. On the DC it writes the user's TGT and a service ticket for each service the session reaches, and on the workstation it writes the logon with its privileges and groups. Each server the user then opens adds its own network logon.

Some access writes no logon event at all. Code run through an exploit, or a backdoor running inside a service or session that already exists, needs no new sign-in, so look for its processes, services and network connections instead.

The record is only as good as the audit policy and log sizes behind it. Check which subcategories each machine audits and how far back its logs reach before reading meaning into a gap.

Who Writes What

Each machine in a sign-in writes its own part of the record to its own Security log. Use this table to choose which machines to collect for the question you are asking.

Machine	What It Records	Events in Its Security Log
Domain controllers	Every Kerberos ticket they issue or refuse, every NTLM check of a domain account, and logons to the DCs themselves	4768, 4769, 4771, 4776, 4624
The server reached	Access to it, with who, how, from where and with which rights	4624, 4625, 4672, 4634, 5140
The client	Its own sign-in, and credentials used to reach other machines	4624, 4672, 4648
Any machine, for its local accounts	The NTLM check of the password, and the logon	4776, 4624, 4625

What Is Logged

Each event below names the log it is written to, the machine that writes it and the audit setting that switches it on, then what to read in it for this page.

Event and Log	Written On	Switch It On	What It Tells You
4776 `The computer attempted to validate the credentials for an account` (opens in a new tab) Security log	The computer that holds the account, a domain controller for a domain account or the computer itself for a local one	Audit Credential Validation	On a domain controller it records a domain account's NTLM check, and on any other machine a local account's. Source Workstation names the client, never the server.NTLM Authenticate and Validation explains how to read it.
4768 `A Kerberos authentication ticket (TGT) was requested` (opens in a new tab) Security log	Domain controllers	Audit Kerberos Authentication Service	Only the DC that issued the TGT writes it, with the client's address, so collect every DC to see them all.AS Reply: The TGT explains how to read it.
4769 `A Kerberos service ticket was requested` (opens in a new tab) Security log	Domain controllers	Audit Kerberos Service Ticket Operations	Only the DC that issued the service ticket writes it. Its Logon GUID matches the one in the 4624 that the ticket produces in the server's Security log.TGS Reply: The Service Ticket explains how to read it.
4624 `An account was successfully logged on` (opens in a new tab) Security log	The computer that was logged on to	Audit Logon	The machine that was reached writes it, as the half of the sign-in that the server records and the DC does not.Reading Logon Events explains how to read it.

Check It on a Machine

These Windows Registry keys hold the settings this page names. Open one to see where it lives and how to read it on a machine.

Attacks That Hook in Here

These attacks work through what this page describes. Each card says what the attack is and, where it uses one of these steps, what it does there.

Password Spraying
One guessed password tried against many accounts, over Kerberos and NTLM.
Pass-the-Hash
Signs in over NTLM with a stolen NT hash, never needing the password.
Golden Ticket
Forges a TGT with the krbtgt key, for any account and groups, that every DC accepts.
Silver Ticket
Forges a service ticket with the service's own key, so no DC ever issues it.
Active Directory Reconnaissance
Reads the directory in bulk to map accounts, groups, trusts and servers.
Clearing and Silencing Logs
Clears a log or switches a channel off, so the record of what happened is gone.

Hunt It

Each tool below runs the same search. Its note names the log or table it reads and what has to be switched on or collected first.

Sees Related ActivityDeviceLogonEvents

Reads the DeviceLogonEvents table in Defender XDR advanced hunting, from devices onboarded to Defender for Endpoint, for remote logons by local accounts, whose domain is the device itself. The matching event 4776 stays in each machine's own Security log.

KQLDefender XDR, Advanced hunting

// Local accounts signing in to member machines from the network or by Remote DesktopDeviceLogonEvents| where Timestamp > ago(30d)| extend Host = tostring(split(DeviceName, ".")[0])| where AccountDomain =~ Host| where LogonType in ("Network", "RemoteInteractive")| summarize Attempts = count(), Failures = countif(ActionType == "LogonFailed"), Sources = make_set(RemoteIP, 20) by DeviceName, AccountName, LogonType| order by Attempts desc