SSOGEN / Free tools / Event ID 4648: A Logon Was Attempted Using Explicit Credentials

Free tool

Event ID 4648: A Logon Was Attempted Using Explicit Credentials

Event ID 4648 is not a failure. A process supplied a username and password of its own instead of using the current session. Paste the event into this free decoder to see who, which process, which server, and what to check next. It runs in your browser.

Try SSOGEN

Paste an event and read it

Paste the text from Event Viewer, or the XML from its Details tab.

To see the output first, press the “Explicit credentials (4648)” sample: a fictional Acme example in which one user’s session supplies a service account’s credentials to a file server.

Paste the event text or XML

From Event Viewer: open the event, then copy the General text, or the XML from the Details tab (XML View). Events 4624, 4625, 4634, 4647, 4648, 4672, 4740, 4768, 4769, 4771 and 4776 are recognized.

Private by design. Decoding happens in this page and nothing is sent anywhere. Event text holds account names, host names and IP addresses: use a copy you are allowed to look at, and remove anything you must not share.

Free, in your browser. No sign-up and no limit. The page makes no network request when you decode, so the event never leaves your computer.

Event text still holds account names, host names and addresses, so use a copy you are allowed to read.

What event 4648 records

Event ID 4648 is the Windows Security log entry “A logon was attempted using explicit credentials”. It is a success-type audit event, not a failure. Microsoft says Windows generates it when a process tries an account logon by explicitly specifying that account’s credentials.

That mostly happens in batch-type configurations such as scheduled tasks, or with the runas command.

Microsoft calls it a routine event that also appears periodically during normal operating system activity, so most 4648 events are harmless. Investigate the ones where any of these is not what you expect:

The process. The program that supplied the credentials.
The account. Whose credentials were used.
The destination. The target server.

Why 4648 is not a failure

A failed sign-in is event ID 4625. A 4648 says only that a process asked Windows to log on as an account by handing over that account’s credentials; it does not say whether the logon worked.

The result is recorded elsewhere, usually as a 4624 (success) or a 4625 (failure) with the same session details.

Read a 4648 as a question: who tried to use whose credentials, from which program, for which server. The answer is in the events next to it.

Microsoft files 4648 under the Audit Logon subcategory:

Events in it. 4624, 4625, 4648 and 4675 (SIDs were filtered).
Volume. Low on a client computer and medium on domain controllers and network servers.

The fields, and what each one answers

These field names are from Microsoft’s page for event 4648. The right column is what to ask, in our words.

Section	Field	What to ask
Subject	Account Name, Account Domain, Logon ID	Which signed-in account (or system account) requested the new logon? Is it a person or a service?
Account Whose Credentials Were Used	Account Name, Account Domain	Whose password was supplied? Should the subject know it?
Target Server	Target Server Name	A server name, or `localhost` when the process ran locally. Is this server a normal destination for that account?
Process Information	Process ID, Process Name	Which executable did it? Is it in a standard folder?
Network Information	Network Address, Port	Where did the attempt come from? `::1` or `127.0.0.1` means localhost; the port is 0 for interactive logons.

Microsoft’s page adds two ways to correlate the event:

The Logon ID ties this event to others with the same ID, for example 4624.
The Logon GUID can tie it to a 4624, to a 4964 (special groups assigned to a new logon) and, on a domain controller, to a 4769 Kerberos service ticket request. All zeros means it was not captured, which is not an error.

Worked example. Press the sample. Maria Lopez’s session (Subject) used the credentials of svc-report (the account whose credentials were used) toward fs01.acme.example, from the net.exe process, from 192.0.2.60 on port 445.

Maria is a person and svc-report is a service account, which raises one question: should Maria run a command with the report service account’s password?

If she runs the monthly reports and the job is set up that way, the event is routine. If not, find out how she knows the password.

What produces a 4648

Microsoft names two sources: scheduled tasks and runas.

The other rows in this table are common ways programs supply their own credentials. They are our reading of how Windows works, not a Microsoft list, so check the Process Name on your own machines.

Source	What you typically see	What to check
`runas`	Subject is the person; credentials are another account; process is the runas program or the launched one	Is that person meant to use that account? Is it an administrator account used on an ordinary workstation?
Scheduled task set to run as another user	Subject is the computer or system account; credentials are the task’s account	Does the task exist on purpose? Who created it, and does the account still need the rights it has?
Mapped drive or `net use` with a username	Process such as `net.exe` or `explorer.exe`; Target Server is the file server; port is often 445 in the sample	Is the saved credential still needed? A stale one is also a common cause of lockouts.
Remote administration or remote desktop tools	Process is the tool; Target Server is another computer	Is the tool approved? Does the person normally administer that computer?
Services and background processes	Process is `svchost.exe` or the service executable; Target Server may be `localhost`	Microsoft’s sample shows `svchost.exe` to `localhost`, an ordinary pattern. Large volume here is usually the cause of noise.
Web browsers, IIS or other server software	Process is the browser or `w3wp.exe`; Target Server is a back-end	Is the application pool or site meant to use that account?

Telling normal from misuse

No single 4648 proves anything. Microsoft’s monitoring advice for this event is a set of comparisons, and they are the most reliable way to filter out normal use:

High-value accounts. Watch 4648 where either the Subject or the account whose credentials were used is an administrator, database administrator, service account or domain controller account.
Accounts that should never be used. Disabled, guest or dormant accounts in either field.
Allow lists. If only certain accounts may do this, review any account outside the list.
Restricted computers. For example, an account that must never log on to a certain computer.
Process names. Microsoft suggests checking for a Process Name that is not your expected value, is not in a standard folder such as System32 or Program Files, is in a restricted folder such as Temporary Internet Files, or contains words like “mimikatz” or “cain.exe”.
Who knows whose password. If the Subject should not know or use the credentials of the account named, monitor it.
Where it comes from. If a service account should only be used from certain addresses, alert when the Network Address is not one of them.

The patterns below are our judgment, not a Microsoft rule:

What you see	Likely story
Same task, same account, same server, at the same time each day	A scheduled task
A person’s session using a service account’s credentials interactively	Possibly a shortcut by an administrator; possibly misuse. Ask.
A rapid run of 4648 events from one process toward many different servers	Something is trying one set of credentials on many machines. That shape is how lateral movement looks, so check the process and the account first.
An unfamiliar executable in a user or temp folder as the Process Name	Treat as suspect until explained
The account whose credentials were used is disabled or dormant	Someone has a password they should not, or a job nobody retired

Naming a specific tool or attacker technique takes more evidence than this event gives, and this page does not claim to detect attacks.

Use 4648 to decide where to look, then read the process creation record and the matching logon events.

Pairing 4648 with 4624 and 4625

The explicit-credentials attempt is one half of the record; the logon it triggers is the other. Find that logon by the same Logon ID and Logon GUID and a close timestamp.

A 4624 follows. Microsoft’s logon types list includes type 9, NewCredentials: a caller cloned its current token and specified new credentials for outbound connections. The new logon session has the same local identity but uses different credentials for other network connections.

In a version 2 4624, the Network Account Name and Network Account Domain fields are valid only for this type and hold the account used for outbound connections.

Expect this logon type when something like runas /netonly is used (that pairing is our reading, not Microsoft’s wording).
Type 3, Network. At the server that was reached, the event is typically a 4624 of type 3 (“a user or computer logged on to this computer from the network”). Events are written where they happen: the 4648 is on the machine that supplied the credentials, and the 4624 is on the machine that was accessed.
A 4625 follows. If the credentials were wrong, the failed logon appears with a Status and Sub Status. Decode it with the event ID 4625 decoder. A burst of 4648 followed by 4625 with the same credentials is the classic stale saved password.

Fields can be empty, depending on the protocol. Microsoft notes that network logons with Kerberos likely have no workstation information and NTLM logons have no TCP/IP details. An empty field is not a fault.

Managing the noise

Servers log 4648 often, because services and tasks produce it all day. Microsoft rates Audit Logon volume medium on domain controllers and network servers. There are two ways to handle it:

Filter, do not switch off. Keep the event and exclude the combinations you have already explained, such as a known service process running toward localhost. Match on Process Name, account and Target Server together, and what remains is the list that matters. Excluding on one field alone (a process name, for example) can hide a real problem.
Keep it for the accounts that matter. Microsoft’s advice is to monitor this event for high-value accounts and for accounts that should never be used. A small, precise alert on those is more useful than a wide one on everything.

We recommend against disabling the subcategory, because the same setting also records 4624 and 4625. That is our recommendation, not a Microsoft instruction.

The audit setting behind 4648

4648 comes from the Audit Logon subcategory of Advanced Audit Policy.

Recommendation. Microsoft’s table for that subcategory recommends auditing both success and failure on domain controllers, member servers and workstations, for the general and the stronger baselines.
Event type. The 4648 itself is a success event.
Where it is written. The Security log on the computer where it happened.
Access. Reading that log requires an administrator account.

Questions about event ID 4648

What does event ID 4648 mean?

“A logon was attempted using explicit credentials.” A process supplied an account’s username and password itself instead of using the current session. It records the attempt, not a failure.

What does explicit credentials mean in a log?

A program gave Windows a username and password for a logon, instead of letting Windows use the token of the account already signed in. A scheduled task that runs as another user, or runas, does this on purpose.

What does event ID 4624 mean, and how is it different from 4648?

Event 4624 is “An account was successfully logged on”. It records a logon that worked. A 4648 records only the attempt to use explicit credentials. Match them by Logon ID or Logon GUID to see whether the attempt succeeded.

Is event ID 4648 a security problem?

Usually not. Microsoft calls it a routine event that appears during normal operating system activity, mostly with scheduled tasks and the runas command. It gets interesting when the process, the account or the destination is unexpected.

Why do I see so many 4648 events on a server?

Services, scheduled tasks and background processes use explicit credentials all day. Filter out the explained combinations of process, account and target server rather than turning the event off.

How do I tell if a 4648 worked?

Look for the 4624 or 4625 with the same Logon ID or Logon GUID and a close timestamp, on the machine that was accessed. A 4624 is success, a 4625 is failure.

Which audit policy produces event 4648?

The Audit Logon subcategory of the Advanced Security Audit policy. It also produces 4624, 4625 and 4675.

Is it safe to paste a Windows event into this page?

Yes. Decoding happens in the page and nothing is sent. The event still contains account and host names, so remove anything you can’t share, and use only events you’re allowed to read.

Where to go next

Decode the failure side with the event ID 4625 decoder.
Look at the Kerberos side with the event ID 4768 decoder and NTLM credential checks with the event ID 4776 decoder.
Browse the other free tools.
Read how a domain-joined computer signs in with a Kerberos ticket in the Windows desktop sign-in guide.
For how SSOGEN’s own sign-in record works, see the SSO audit log.

Sources, all Microsoft Learn, read 2026-10-09: events 4648 and 4624 (including its logon types table), and the Audit Logon subcategory. Microsoft and Windows are trademarks of their owner; SSOGEN is not affiliated with Microsoft.