Event 4648 lives under the Audit Logon subcategory and writes to the Security channel on the machine where the explicit-credential action originated, not necessarily the machine being accessed. Microsoft's own description is blunt about the trigger condition: a process attempts an account logon by explicitly specifying that account's credentials, rather than inheriting the identity of the session that spawned it.
That distinction matters more than it sounds. Most logons on a Windows host ride on the token of whoever is already signed in. Event 4648 exists for the moment someone or something deliberately breaks that inheritance and hands the operating system a different username and password.
The canonical trigger is the runas command, or its GUI equivalent, shift-right-clicking a shortcut and choosing Run as different user. Scheduled tasks are the second most common source: any task in Task Scheduler configured to run under a stored account (rather than the built-in SYSTEM or the currently logged-on user) generates a 4648 every time the Task Scheduler service launches it, because the scheduler process is explicitly supplying that stored credential to start the child process.
Mapping a network drive with alternate credentials, net use \\server\share /user:domain\account, produces the same event, as does opening a saved RDP shortcut that stores a different account than the local session. Admin tooling that lets an operator target a resource under an identity other than their own signed-in one, PsExec with explicit -u and -p flags, some WMI invocations, certain remote management consoles, all funnel through this same audit point.
Because 4648 only exists as a success-audit event, it does not carry a companion failure variant the way 4625 does for interactive and network logons. The event records that the explicit-credential attempt was made and audited, not whether the downstream logon eventually succeeded or failed on the target. That downstream outcome shows up separately, as a 4624 or 4625 on whichever machine actually processes the resulting logon, which is frequently a different host than the one that logged the 4648.
The field structure is what makes this event genuinely useful rather than just noisy. Three distinct identities appear in a single record. The Subject fields, SubjectUserSid, SubjectUserName, SubjectDomainName, and SubjectLogonId, describe the account and logon session that initiated the explicit-credential request; this is whoever was already signed in and ran runas, launched the scheduled task engine, or opened the mapped-drive dialog.
The Account Whose Credentials Were Used fields, TargetUserName and TargetDomainName, describe the alternate identity being invoked; this is the account someone is trying to act as. TargetServerName and TargetInfo describe the destination, the server the new process actually ran on, with a value of localhost when the action stayed on the originating box.
Process Information adds ProcessId and ProcessName, the executable that made the explicit-credential request, svchost.exe hosting the Task Scheduler service, explorer.exe or consent.exe for an interactive runas, or cmd.exe when someone typed the runas command directly. Network Information closes the record with IpAddress and IpPort, which show a remote source address and port when the request came in over the network and ::1 with port 0 for a purely local action.
No other commonly reviewed logon event carries this three-way structure in one record. Event 4624 and 4625 describe a single logon attempt from a single subject's perspective. Event 4648 describes a handoff: who asked, whose identity got borrowed, and where it landed. That is exactly the shape of information a lateral-movement investigation needs, and it is why analysts working incident response treat 4648 as a starting thread rather than a background nuisance.
Neighboring events fill out the picture. Event 4624 on the target machine confirms the explicit-credential logon actually completed, and its LogonGuid can be matched against 4648's TargetLogonGuid to stitch the two records together across hosts. Event 4769, a Kerberos service ticket request, correlates the same way when the environment uses Kerberos rather than NTLM for the follow-on authentication.
Event 4672 shows up alongside 4624 when the invoked account carries special privileges, which is often the case when the borrowed credential belongs to an administrator. Because 4648 typically fires on the source host and the corresponding 4624 fires on the destination host, a full reconstruction of an explicit-credential logon usually means pulling logs from both machines, not just one.
Attackers who have obtained a second set of credentials, through phishing, a password dump, or a purchased access broker listing, still need somewhere to spend them. Runas against a file server, a net use mapping to an ADMIN$ share ahead of a PsExec push, a remotely created scheduled task configured with the stolen account, or a WinRM session opened with explicit credentials all generate 4648 at the exact moment the adversary supplies that literal credential.
This is a meaningfully different signal from token-theft techniques that inject an existing authentication context directly into a process without ever typing a username and password, those tend to surface as an unusual 4624 logon type rather than a 4648 at all. For an analyst hunting lateral movement, 4648 is the event that catches the moment a human or script consciously reached for a second identity, which makes it one of the more direct signals available for that specific behavior.
