Investigating Explicit Credential Use: Windows Event 4648 with KQL and Splunk

Windows Event 4648 can reveal where a process supplied another account’s credentials. A useful hunt connects that attempt to the requesting identity, process and subsequent activity instead of treating every event as credential theft.

Why it matters

Administrative workflows and attacker activity can overlap. This investigation asks whether a credential-use attempt fits an approved task and whether independent evidence supports a successful action. It continues our RDP logon investigation by examining a different part of the authentication story.

Microsoft’s Event 4648 reference describes an explicit-credential logon attempt, including routine operating-system activity, scheduled tasks and RunAs. Its subject identifies the requester; the target account identifies whose credentials were supplied. Process, target-server and network fields provide context. Available logon GUIDs may support correlation, but all-zero GUIDs are not useful join keys. Event 4648 alone does not establish a successful remote session or stolen credentials.

Original investigation map: move from identity context to independently verified outcome.

Enlarge the investigation map

Required telemetry

Windows Security auditing and collection covering Event 4648 on the relevant hosts. Confirm Audit Logon configuration and retention before interpreting missing events.
Authentication records from relevant destination systems, and process telemetry around the event time.
Change tickets, approved management-host inventory and account ownership information.
Collector health and timestamp normalization. Preserve original records alongside normalized SIEM fields.

Start with readable evidence: KQL

This Microsoft Sentinel query uses the SecurityEvent table. It is not a Defender XDR DeviceEvents query. Confirm populated fields in your connector before adapting it.

SecurityEvent
| where TimeGenerated > ago(1d)
| where EventID == 4648
| project TimeGenerated, Computer,
    SubjectUserName, SubjectDomainName,
    TargetUserName, TargetDomainName,
    ProcessName, ProcessId, IpAddress, EventData
| order by TimeGenerated desc

Retaining EventData helps when useful context is not normalized. Missing projected values require inspection of the source record, not an assumption that the activity lacked that attribute.

The same starting point in Splunk

Replace the index and source selector with your Windows Security collection. The following example assumes EventCode and XML-style field extractions; classic-text inputs or your add-on may use different names.

index=windows sourcetype="XmlWinEventLog:Security" earliest=-24h EventCode=4648
| table _time Computer host SubjectUserName SubjectDomainName
    TargetUserName TargetDomainName ProcessName ProcessId
    TargetServerName IpAddress _raw
| sort 0 - _time

Test and adapt these read-only examples in an authorized environment. They have not been executed against your tenant. Start with a small time range and a known benign event; verify extraction before using results in an alert.

Investigation workflow

Preserve the seed. Save the event, host identity, timestamp and collection context. Record what initially made it worth reviewing.
Separate the identities. Resolve the requester and supplied account to owners and expected roles. Do not collapse them into a single generic user field.
Reconstruct the process. Look for contemporaneous process creation on the same host. Normalize hexadecimal and decimal process IDs when needed. PID reuse means a match without time context is weak evidence.
Validate the destination and outcome. Compare target context with destination authentication and application activity. Correlate by multiple attributes; do not join unrelated events merely because usernames match.
Test a legitimate explanation. Ask whether the exact source, account, process and timing match an approved administrative job. A familiar tool name is not enough.
Scope unexplained activity. Search the same identity and process context across a bounded timeline, preserving uncertainty where records are missing.

Two fictional examples

Expected: A helpdesk administrator uses an approved management host during a recorded maintenance window. The target account owner confirms the task and destination logs align with it. Record the evidence supporting that conclusion.

Escalate: A workstation unexpectedly supplies a privileged account through a process the owner cannot explain. Independent destination activity follows. This combination merits incident-response review; the 4648 event by itself still does not prove how the credentials were obtained.

Tuning, response and documentation

Build narrowly scoped exceptions around verified workflows with an owner and expiry. Keep changes in source host, process path or supplied identity visible. Avoid suppressing every event from administrators or service accounts.

If corroborating evidence supports misuse, involve the identity and endpoint owners. Follow approved procedures for session restriction, credential rotation or host containment, considering service dependencies. Preserve the timeline, competing explanations, query scope and data gaps. ATT&CK mapping should follow established behavior; do not label credential dumping solely from an explicit-credential event.

Case-closure questions

Who requested the attempt and whose account was supplied?
What process and destination were independently validated?
Which evidence establishes outcome, and what remains unknown?
What change prevents recurrence without hiding future signals?

Key takeaways

Keep requester, supplied identity and outcome separate. Validate field mappings before correlation. A defensible finding explains both the suspicious signal and the evidence that ruled legitimate activity in or out.

Explore more defensive investigation guides. Source references reviewed October 4, 2026; examples are fictional and queries require local validation.