Log Dejargonizer

Windows Security Log · Event 4648

Event 4648: A logon was attempted using explicit credentials

A process signed in as a different account than the one already in use — the runas pattern. It is normal for administrators switching to a privileged account, and it is also exactly what an attacker does after stealing a credential.

Also written as 4648Event ID 4648runas event

What it means for you

On a personal computer

Uncommon on a home machine. It appears if you have ever right-clicked a program and chosen Run as different user, or if software prompted you for another account's password.

For an analyst

One of the few events that shows both the source and the target identity in a single record, which makes it valuable for spotting credential reuse. Baseline your administrators first — jump-box workflows generate these constantly.

What it looks like

Sanitised. Addresses come from the RFC 5737 documentation ranges.

Sample
A logon was attempted using explicit credentials.

Subject:
  Security ID:    CORP\jbrooks
  Account Name:   jbrooks
  Logon ID:       0x3E9A11

Account Whose Credentials Were Used:
  Account Name:   svc-backup
  Account Domain: CORP

Target Server:
  Target Server Name: FS-01
  Additional Information: FS-01

Process Information:
  Process ID:   0x1cf4
  Process Name: C:\Windows\System32\runas.exe

Network Information:
  Network Address: -
  Port: -

The fields that decide it

Everything else in the log line is context.

SubjectUserName
The account that was already signed in — who is doing the switching.
TargetUserName
The account whose credentials were supplied. This is the identity being borrowed.
TargetServerName
The machine the credentials were used against. Not always the local machine.
ProcessName
The program that supplied the credentials.
  • runas.exeA deliberate credential switch at the command line.
  • mstsc.exeRemote Desktop connecting with credentials typed into the client.
  • explorer.exeA user right-clicked and chose Run as different user.
  • powershell.exeA script supplying credentials, common in automation and in attack tooling alike.
IpAddress
Where the attempt originated, when it came over the network.

Ordinary reasons this happens

Most of the time it is one of these.

  • An administrator using runas or Run as different user to switch to a privileged account.
  • Remote Desktop connections where credentials are entered in the client rather than reused from the session.
  • Scheduled tasks and services configured with stored credentials.
  • Backup and management software authenticating to remote systems with a service account.
  • Mapping a network drive with alternate credentials.

When it is not ordinary

Using a stolen credential to reach another system.

What gives it awayA SubjectUserName and TargetUserName pair that has no history together, especially where the target is privileged and the subject is not.

ATT&CK T1078

Lateral movement from a compromised workstation.

What gives it awayTargetServerName naming a machine the source account has no reason to administer.

ATT&CK T1021

Privilege escalation after a foothold.

What gives it awayA standard user account supplying administrative credentials from a process that is not a normal administrative tool.

ATT&CK T1078.002

What to do next

  1. Read the subject and target account pair together. The relationship between them is the whole event.
  2. Check ProcessName. Credentials supplied by an ordinary application rather than an administrative tool deserve a question.
  3. Check TargetServerName against what that account normally administers.
  4. Look for the corresponding 4624 on the target machine to see whether the attempt succeeded.
  5. Build a baseline of normal subject-target pairs before alerting, or administrator workflows will bury you.

Queries to run

kql Rarest account pairings first, which surfaces credential use that has no precedent. 
SecurityEvent | where EventID == 4648 | where SubjectUserName != TargetUserName and TargetUserName !endswith '$' | summarize count() by SubjectUserName, TargetUserName, Computer | order by count_ asc
splunk 
index=wineventlog EventCode=4648 | stats count by Account_Name, Target_Account_Name, dest | where count < 5

Common questions

Is Event 4648 a sign of compromise?

Not by itself. It is generated every time someone runs a program as a different user, connects with Remote Desktop using typed credentials, or maps a drive with alternate credentials. It becomes interesting when the account doing the switching and the account being used have no working relationship.

Why does Event 4648 appear when I use Remote Desktop?

Because you supplied credentials explicitly to the Remote Desktop client rather than reusing the ones already active in your session. That is precisely what the event records, and mstsc.exe in the process name confirms it.

What is the difference between Event 4648 and Event 4624?

4648 records that credentials were offered; 4624 records that authentication succeeded. 4648 is written on the machine where the credentials were typed, and the matching 4624 appears on the machine they were used against.

Read next

Mentioned by

Vendor documentation

Last reviewed 28 August 2026