How to Check RDP Login History (4624 and 4625)

To check RDP login history, review the Windows Security log for Event IDs 4624 and 4625, then confirm the logon type, account, time, and source IP. Event 4624 records a successful logon, while 4625 records a failed one, so together they show both access and attempted access to your server.

What you need before checking RDP logs

You need administrator access to the Windows computer you want to inspect. The checks below work on Windows Server and Windows desktop editions with Remote Desktop enabled, and they inspect logs on the destination computer, not on the PC you used to connect.

You should also know the approximate time of the login and the usernames you expect to see. That makes it much easier to separate your own sessions from background Windows activity or unrelated authentication events.

Windows must be auditing logon events for the Security log to contain useful results. Microsoft identifies Event ID 4624 as a successful logon and Event ID 4625 as a failed logon; the events are generated on the computer that was accessed. If your Security log is missing these events, check the Audit Logon policy.

Step 1: Open the Windows Security log

Why this matters: the Security log is where Windows records the authentication result, account name, logon type, and often the source address.

1. Sign in to the Windows server or RDP host with an account that can read event logs.
2. Press Win + R, type eventvwr.msc, and press Enter.
3. Expand Windows Logs, then select Security.
4. In the Actions pane, select Filter Current Log.
5. In Logged, choose a useful range such as Last 24 hours or Last 7 days.
6. In Event IDs, enter 4624,4625, then select OK.

Success looks like a filtered list containing only successful and failed logon events for the selected period. Double-click an event to open its details. Use the General tab for a readable summary and the Details tab when you need the exact XML field names.

Step 2: Identify an actual RDP login

Why this matters: Event IDs alone do not prove that the connection used Remote Desktop. Windows creates logon events for several kinds of local, network, service, and remote activity.

For a successful RDP session, open Event ID 4624 and look for these fields:

Field	What to look for
Logon Type	10, named RemoteInteractive
New Logon account	The user that received the session
Time Created	When Windows created the logon session
Network Information	Source Network Address and Workstation Name, when supplied
Logon ID	A value you can use to correlate related events

Microsoft describes logon type 10 as a user logging on remotely through Terminal Services or Remote Desktop in its Event ID 4624 reference. The source address may be an IPv4 address, IPv6 address, or an IPv4-mapped IPv6 address. A blank, -, or localhost value is not proof of an attack or a safe login; it means the authentication context did not provide a useful remote address.

Event ID 4625 means that a logon failed, but it can be created for more than one kind of logon. Check Logon Type, Account Name, Failure Reason, Status, Sub Status, and Source Network Address before treating it as a failed RDP password attempt. Microsoft’s Event ID 4625 reference documents these fields and explains that 4625 is logged for any logon failure.

For a second view of RDP session activity, open Applications and Services Logs > Microsoft > Windows > TerminalServices-LocalSessionManager > Operational. This log is useful for session-level evidence such as a successful session logon or a disconnect. Use the Security log for authentication details and the Terminal Services log to understand what happened to the RDP session afterward.

Step 3: Create a PowerShell report

Why this matters: a report is faster than opening hundreds of events manually and makes it easier to compare usernames, source IPs, and timestamps.

Open PowerShell as an administrator and run this command. It reads the last seven days of Security events and extracts the fields most useful for RDP review.

$events = Get-WinEvent -FilterHashtable @{
    LogName   = 'Security'
    Id        = @(4624, 4625)
    StartTime = (Get-Date).AddDays(-7)
}

$events | ForEach-Object {
    $xml = [xml]$_.ToXml()
    $fields = @{}

    $xml.Event.EventData.Data | ForEach-Object {
        $fields[$_.Name] = $_.'#text'
    }

    [pscustomobject]@{
        Time          = $_.TimeCreated
        EventId       = $_.Id
        User          = "$($fields.TargetDomainName)\$($fields.TargetUserName)"
        LogonType     = $fields.LogonType
        SourceIP      = $fields.IpAddress
        FailureReason = $fields.FailureReason
        Status        = $fields.Status
        SubStatus     = $fields.SubStatus
    }
} |
    Where-Object { $_.LogonType -eq '10' -or $_.EventId -eq 4625 } |
    Sort-Object Time -Descending |
    Format-Table -AutoSize

The report should show the newest events first. Successful RDP events normally appear with EventId 4624 and LogonType 10. Failed events may have a different logon type depending on which part of the authentication process failed, so keep the 4625 rows for manual review instead of filtering them out automatically.

To see only successful RemoteInteractive sessions after the report has been created, add this filter before Format-Table:

Where-Object { $_.EventId -eq 4624 -and $_.LogonType -eq '10' }

To group the failed events by source address and find the busiest sources, use:

$events |
    Where-Object { $_.Id -eq 4625 } |
    ForEach-Object {
        $xml = [xml]$_.ToXml()
        ($xml.Event.EventData.Data | Where-Object Name -eq 'IpAddress').'#text'
    } |
    Group-Object |
    Sort-Object Count -Descending

Success looks like a short table of IP addresses and counts. Treat the count as a lead, not a verdict: many people can share one public IP, and one person can appear under different addresses.

Step 4: Spot a brute-force pattern

Why this matters: one failed password is normal; a repeated pattern can tell you that the RDP endpoint is being guessed or that an old saved password is repeatedly failing.

Review the events together rather than reacting to one row. Indicators that deserve investigation include:

1. Many Event ID 4625 entries within a short period.
2. Repeated failures from one source IP.
3. Attempts against several usernames, especially names you do not use.
4. Status or Sub Status values that repeatedly indicate a bad username or password.
5. A successful 4624 logon that follows the failures and uses an account, time, or source address you do not recognize.

Microsoft guidance for an internet-facing Windows VM notes that 4625 events appearing almost every second with a bad-username-or-password reason can indicate a brute-force attack. That pattern is stronger evidence than a single failed attempt, but it still needs context. A scheduled task, disconnected client, password manager, or another device with an old password can also generate repeated failures.

When you find a suspicious row, record the exact timestamp, account name, source address, logon type, failure reason, status, and sub-status. If a successful session is unexpected, also record the 4624 Logon ID and inspect nearby Terminal Services events before changing or deleting logs.

Step 5: Take the next security action

Why this matters: login history is evidence. It does not stop another attempt, so use what you found to reduce exposure and protect the account.

If the successful login is yours, note the source address and time so you can recognize the normal pattern later. If it is not yours, change the affected password from a trusted session, review local users and Remote Desktop Users membership, and disconnect any unfamiliar session. Avoid disabling the only administrator account or closing your current recovery path while you are connected.

For repeated failures, apply the least disruptive control that fits your setup:

• Restrict the inbound RDP rule to trusted source IP addresses when your address is stable.
• Put RDP behind a VPN or another private access path when your users can use one.
• Keep Network Level Authentication enabled where supported.
• Use a strong, unique password and remove unused accounts.
• Set a sensible account lockout policy after testing it against your own support and recovery process. If an account is already locked, use this Windows RDP account lockout troubleshooting guide.
• Treat a port change as noise reduction, not as the main security control.

If you want to change the listener, first read how to change the default RDP port on Windows Server. The RDP port 3389 explanation also explains which client, firewall, and provider rules need to agree.

Verify your findings

Use this checklist before you conclude that a login was unauthorized:

• The event was recorded on the server you intended to inspect.
• The event time is in the server’s local display time; compare it with your own timezone.
• The username and account domain match the account you expected or investigated.
• A successful event has logon type 10, or you have supporting Terminal Services evidence.
• The source address is compared with your own public IP, VPN exit IP, office network, or known users.
• You checked both successful and failed events around the same time.
• You preserved the relevant timestamps and event details before making changes.

If the log is empty, check whether the selected time range is correct and whether you are viewing the destination server’s Security log. Also check the Audit Logon policy and confirm that the Security log has not rolled over because of its size limit. If the PowerShell output has blank fields, open one event in Event Viewer and compare its Details view with the field names in the script; different authentication paths can omit fields.

Troubleshooting common RDP history questions

I see 4625 but no source IP. Some authentication contexts do not provide a usable IP address. Use the account, time, logon type, status, and nearby Terminal Services events, and check the network or firewall logs if you need connection-level evidence.

I see many 4624 events. Not every successful logon is an interactive RDP session. Filter for logon type 10, then review the account and source fields. Service, network, scheduled-task, and local activity can create other successful logon types.

My own RDP login created more than one event. Windows can record more than one authentication or session event for a connection. Correlate the time, account, source address, Logon ID, and Terminal Services session events instead of counting every row as a separate person.

The Security log does not go back far enough. Windows keeps only the records that fit the Security log’s configured size and retention behavior. Export important events to a central log system or increase retention before you need a longer history.

FAQ

What event ID shows a successful RDP login?

Event ID 4624 shows a successful logon. For a normal full RDP logon, look for Logon Type 10, named RemoteInteractive, and confirm the user, time, and source address.

What event ID shows a failed RDP login?

Event ID 4625 shows a failed logon. Because it covers more than RDP, inspect the logon type and network fields rather than assuming every 4625 entry came from a remote desktop password attempt.

How do I check who logged into my Windows server?

Open Event Viewer, go to Windows Logs > Security, and filter for Event ID 4624. Review the New Logon account, time, Logon Type, and Source Network Address; type 10 is the key indicator for a successful RDP session.

How far back does RDP login history go?

It goes back only as far as the Security and Terminal Services logs retain events. The available period depends on log size and retention settings, so export or forward security events if you need a durable history.

Should I change the RDP port after seeing failed attempts?

A port change can reduce automated scanning noise, but it does not replace strong authentication, restricted firewall access, or a VPN. If you change it, update the server listener, firewall, provider rule, and RDP client together and keep a recovery path.