An unexpected Remote Desktop logon can represent emergency maintenance, a new administrator, or unauthorized access. Start with the destination’s logon record, reconstruct the access route, and examine what happened during the session before assigning intent.
Why this hunt matters
Remote Desktop is a useful administrative service and a potential route for attacker movement. MITRE ATT&CK describes its abuse under T1021.001. Map that technique when evidence supports misuse; normal RDP traffic should not automatically become a lateral-movement finding.
Enlarge the remote-logon poster
1. Establish what the event proves
Microsoft documents Event 4624 as a successful logon-session creation on the destination computer. Logon type 10 identifies remote interactive access through Terminal Services or Remote Desktop. It does not reveal every command run, prove credential theft, or establish the identity of the person controlling the client.
Use the New Logon / Target account when identifying who signed in. The Subject account can be the service reporting the logon and is not necessarily the remote user. Source-address fields depend on the authentication context; missing data is a collection or attribution limitation, not an automatic safe verdict. This hunt focuses on type 10 and is not a complete inventory of all session reconnections or remote-access products.
2. Confirm the required telemetry
Collect successful Windows Audit Logon events from relevant destination systems. Confirm your forwarding policy retains 4624, that events arrive, and that the timestamps are normalized. Supplement them with endpoint process telemetry, Remote Desktop session logs, VPN or RD Gateway records, identity records, and approved-change tickets. Verify retention and clock differences before building a timeline.
Query scope: The KQL example below targets Microsoft Sentinel / Log Analytics SecurityEvent, not Defender’s DeviceLogonEvents. The Splunk example assumes Windows Security XML fields have been extracted. Both are read-only starting points: test and adapt them in an authorized environment. They have not been executed against your organization’s data.
3. KQL: inspect destination logons
SecurityEvent
| where TimeGenerated > ago(24h)
| where EventID == 4624 and LogonType == 10
| project TimeGenerated, Computer, TargetUserName,
TargetDomainName, TargetLogonId, IpAddress,
WorkstationName, AuthenticationPackageName, EventRecordId
| order by TimeGenerated desc
| take 200Validate the target-account and logon-ID mappings against a raw event in your connector. If your data lands in another table, adapt the extraction instead of renaming the table and assuming equivalent columns. The 200-row cap supports initial inspection; it is not an exhaustive scope count.
4. Splunk SPL: preserve raw attribution fields
index=YOUR_WINDOWS_SECURITY_INDEX EventCode=4624 earliest=-24h latest=now
| where tonumber(LogonType)=10
| table _time Computer TargetUserName TargetDomainName
TargetLogonId IpAddress WorkstationName AuthenticationPackageName
| sort 0 - _time
| head 200Some Splunk deployments use EventID, Logon_Type, ComputerName or CIM-normalized names. Inspect a known benign event and map these fields first. In particular, do not substitute a generic Account_Name field without checking whether it contains the Subject, Target, or multiple values. Keep records with missing source addresses for separate review.
5. Reconstruct the route and session
For each candidate, record the destination host, target account, source address, event time and target logon ID. Compare the route with your approved jump hosts, gateways and VPN design. An address belonging to a gateway may identify an intermediary rather than the original workstation. Use gateway and VPN records to resolve that gap; do not geolocate an intermediary and report it as the user’s physical location.
Correlate follow-on events using the destination computer, session identifier and a bounded time range. A logon ID is not a globally unique identifier across all hosts or reboots. Consult raw records when normalized fields disagree. Review process trees, privileged changes and relevant file or application access, separating recorded actions from assumptions based on the account’s permissions.
A useful analyst timeline
Record access authorization, gateway authentication, destination logon, meaningful process activity, administrative changes, and session end where available. Mark each item as observed, inferred or missing. Do not fill missing intervals with invented activity.
6. Compare two explanations
Fictional benign scenario: An on-call engineer connects through the approved gateway to a server they rarely manage. A valid incident ticket, gateway record and matching repair actions corroborate the session. The unusual account-host pairing remains useful context but does not justify an incident by itself.
Fictional escalation scenario: A dormant administrator account logs on from an unfamiliar internal endpoint, followed by an unexpected script and a new persistence artifact. The account owner denies the activity through a trusted contact channel. Escalate the combined evidence and scope both hosts; the logon alone did not establish those later findings.
Tuning, containment and documentation
Baseline account-to-destination and route combinations over a representative period. Review onboarding, maintenance and emergency access before treating novelty as malicious. Avoid suppressing all administrators or all traffic from a jump host: an approved route can itself be compromised. Use narrow exceptions with owners and expiry dates.
When corroborating evidence supports compromise, follow the response playbook for session termination, account restriction or device isolation. Coordinate actions with system owners to avoid interrupting critical maintenance. Preserve relevant logs, establish the initial access path and validate recovery. An alert should document scope, confidence, timeline, evidence links, collection gaps, actions and the rationale for closure or escalation.
Key takeaways
- Read the target identity and destination session, not just the event number.
- Validate connector schemas before using sample queries.
- Reconstruct gateway and VPN context before attributing the source.
- Use subsequent behavior and authorization evidence to distinguish administration from abuse.
For a follow-on endpoint investigation, read Browser-to-Shell Threat Hunting, or browse the Knowledge Base.
Primary references
- Microsoft: Event 4624 reference — archived reference; validate against your OS and event version.
- Microsoft: SecurityEvent table schema
- MITRE ATT&CK: Remote Desktop Protocol
EmoticonEmoticon