Event ID 4648: Explicit Credentials Used — RunAs, Tasks, Lateral Moves

What it records

Event 4648 belongs to the Audit Logon subcategory. Microsoft’s description is short and worth taking literally: “This event is generated when a process attempts an account logon by explicitly specifying that account’s credentials.” The documentation adds where that normally happens — “This most commonly occurs in batch-type configurations such as scheduled tasks, or when using the ‘RUNAS’ command” — and warns that “It is also a routine event which periodically occurs during normal operating system activity.”

The event is built from four blocks. Subject names who asked: Security ID, Account Name, Account Domain and a Logon ID that points back at the session already running on the box. Account Whose Credentials Were Used names the borrowed identity: Account Name, Account Domain and a Logon GUID that can tie the request to a 4769 service-ticket request on a domain controller. Target Server holds Target Server Name — the name of the server on which the new process was run, with “localhost” when it ran locally — plus Additional Information, a field Microsoft explicitly leaves undocumented. Process Information gives the hexadecimal Process ID and the full path of the executable, and Network Information gives Network Address and Port.

The event requires no particular server role and is available from Windows Vista and Windows Server 2008 onward.

When it matters

The useful signal is the pairing of subject, borrowed account and process path.

Pattern	Reading
Subject and used account identical, process in System32, Target Server Name “localhost”	The routine operating-system activity Microsoft warns about
A standard user account supplying a domain-admin account’s credentials	Privilege switch on a host that should not hold those credentials
Credentials for one high-value account used from many workstations	Microsoft’s high-value-account monitoring case, tracked on “Account Whose Credentials Were Used\Security ID”
Process Name outside System32 or Program Files, or in a temporary folder	Microsoft’s guidance is to monitor process names not in a standard folder, or in a restricted folder
Process name containing restricted substrings — the documented examples are “mimikatz” or “cain.exe”	Credential tooling, not administration
Credentials for a service or disabled account used outside working hours	Microsoft’s anomaly and non-active-account recommendations
Network Address outside your internal ranges for an account that should only be used internally	Microsoft’s check that Network Address is from the internal IP address list

Two more of Microsoft’s recommendations are easy to operationalise: if the subject should not know or use the credentials of the account whose credentials were used, the event is worth an alert on its own; and account names that break your naming conventions in either field deserve review.

How to investigate

Start with identity switches, ignoring machine accounts and the self-referential noise:

SecurityEvent
| where TimeGenerated > ago(24h)
| where EventID == 4648
| where SubjectUserName !endswith "$" and TargetUserName !endswith "$"
| where tolower(SubjectUserName) != tolower(TargetUserName)
| summarize Attempts = count(), UsedAccounts = dcount(TargetUserName),
            AccountList = make_set(TargetUserName, 20), Processes = make_set(ProcessName, 10)
    by Computer, SubjectUserName, SubjectDomainName
| order by UsedAccounts desc, Attempts desc

One subject cycling through several distinct accounts on one host is the shape worth chasing; a long tail of one-to-one pairs is usually administration.

Next, apply the process-path guidance directly:

SecurityEvent
| where TimeGenerated > ago(7d)
| where EventID == 4648
| where ProcessName !startswith "C:\\Windows\\System32\\"
| where ProcessName !startswith "C:\\Program Files"
| project TimeGenerated, Computer, SubjectUserName, SubjectDomainName,
          TargetUserName, TargetDomainName, ProcessName, IpAddress
| order by TimeGenerated desc

Then use the Subject Logon ID, which Microsoft documents as correlating with recent events carrying the same value such as 4624, to find out who was sitting in the session that borrowed the credentials:

let explicit = SecurityEvent
    | where TimeGenerated > ago(24h) and EventID == 4648
    | project ExplicitTime = TimeGenerated, Computer, SubjectLogonId,
              RunAsBy = SubjectUserName, CredentialsUsed = TargetUserName,
              ExplicitProcess = ProcessName;
SecurityEvent
| where TimeGenerated > ago(24h) and EventID == 4624
| join kind=inner explicit on Computer, $left.TargetLogonId == $right.SubjectLogonId
| project ExplicitTime, SessionStart = TimeGenerated, Computer, RunAsBy, CredentialsUsed,
          ExplicitProcess, LogonType, SourceIp = IpAddress
| order by ExplicitTime desc

If the originating 4624 is a type 10 session from an unfamiliar address, the explicit-credential use belongs to whoever opened that session, not to the named administrator.

From there, pivot outward. The Process ID converts to the decimal value you can match against New Process ID in 4688, giving you the command line that ran. 4672 on the same Logon ID tells you the session already held privileges. On the destination, look for the matching 4624 and, if the attempt failed, the 4625 and its Sub Status — 0xC000006A for a wrong password against a real account, 0xC0000064 for a name that does not exist. On a domain controller, the Logon GUID can link the request to a 4769 service-ticket request, which shows which service the borrowed identity went after; Kerberos pre-authentication failures carry codes such as 0x18. Repeated failed credential use from one source is spraying behaviour, which the Windows 4625 password-spray rule groups for you. Without a SIEM, export the Security log as XML from Event Viewer and open it in the free browser log analyzer.