Event 4648 in practice: reading logon-with-explicit-credentials without chasing every runas

A 4648 landed in my Splunk queue last month tagged to a finance workstation, and my first instinct was to close it. That instinct is usually right, which is exactly the problem with this event. Event 4648, “a logon was attempted using explicit credentials,” fires so often on ordinary admin habits that most shops either mute it or drown in it. Neither is the move. It is one of the cleaner ways to watch an alternate set of credentials being used from a host, and once you know which three fields decide whether it matters, you can keep it on without hating your shift.

When Windows actually writes a 4648

Windows logs a 4648 when a process running as one user hands a different username and password to an authentication call. That covers runas, net use \\server /user:..., an RDP session started with saved-but-different credentials, PsExec with the -u flag, a scheduled task configured to run as a stored account, and a good chunk of pass-the-hash tooling that injects material and then acts under it. The important structural detail is that the event is written on the source host, the machine where the credentials were supplied, not on the destination. So a 4648 tells you where a credential reuse originated, which is frequently more useful than the matching 4624 on the far side.

The three fields that decide it

Three fields carry the whole signal. The Subject block names the account that was already logged on, the identity that initiated the runas. The “Account Whose Credentials Were Used” block names the borrowed identity. And Process Information names the binary that made the call. Read together they answer one question: who, sitting on this box, just reached for a different identity, and with what. When the initiating account is a normal user, the borrowed account is privileged, and the process is powershell.exe or cmd.exe or wmic.exe, you are looking at the exact shape of hands-on-keyboard lateral movement.

The pass-the-hash angle is worth a sentence of honesty. A lot of PtH tradecraft produces a 4648 on the source when it spawns a process under the alternate material, and runas /netonly does the same. This catches most of that pattern, not all of it, because some techniques operate on the destination without ever touching the source host’s explicit-credential path. So treat 4648 as one seat at the table, not the whole detection.

Where I run it

I read this against Windows 11 23H2 clients and Server 2022 members with the Security log forwarded through Windows Event Forwarding into Splunk, and I cross-check on Microsoft Defender for Endpoint advanced hunting, where the DeviceLogonEvents table carries the same explicit-credential logons with the initiating process already joined for you. None of this needs Sysmon. That said, Sysmon Event ID 1 gives you the full command line for the calling process, which turns “powershell.exe used alternate credentials” into “powershell.exe used alternate credentials to run a remote command against three hosts.” If you collect it, join it in.

The false positives, up front

You need to meet the false positives before you ship anything, because there are a lot. Authenticated vulnerability scanners are the loudest source I know: a Nessus or Qualys scan running with domain credentials lights up 4648 across every target it touches, from a fixed set of scanner hosts. Backup agents, configuration-management tooling, and monitoring platforms that run under service accounts do the same. Helpdesk staff using runas to elevate is legitimate 4648 all day. The thing all of these share is that they come from predictable hosts, under predictable accounts, on a predictable cadence. So the tuning is boring and it works: allowlist the scanner and management source hosts, exclude the service accounts that are supposed to do this, and the residue is people and tools doing alternate-credential logons nobody documented.

Tuning to behavior, not volume

Once the noise floor is set, I stop alerting on the raw event and tune to a few concrete shapes instead. A 4648 where the target server is remote and the calling process is an interactive shell or a scripting engine. A borrowed account that is a Domain Admin or otherwise sensitive, requested from a host that has no business elevating to it. And volume across targets: one workstation generating explicit-credential logons against a spread of different servers in a short window is the manual-lateral-movement signature, an operator hopping box to box under a stolen account. That last one holds up even when you cannot enumerate every legitimate process, which is why I lean on it hardest.

On the ATT&CK side this sits across T1078 Valid Accounts and T1550 Use Alternate Authentication Material, and it is often the host-side companion to remote-service lateral movement under T1021. Microsoft’s event 4648 reference lays out every field by name if you are writing the parser yourself.

Where it fits

On its own a 4648 is an admin habit. Chained to a 4624 type 3 on the destination, a service creation, or a fresh scheduled task showing up on the target, it becomes the first footprint of someone moving. I feed it into the same correlation I described in the 2026 lateral-movement writeup, and if you want the destination-side hunt that got me reading this event carefully in the first place, the older lateral-movement hunt covers the far end. Keep the event on. Just tune it to the reach-for-a-different-identity behavior rather than the raw count, and it stops being noise. Rarely.