Key Points
- Identify the exact event IDs and log locations for relevant RDP activities, such as 1149, 4624, 4625, and enable those logs accordingly.
- Establish baselines and create alert rules for failed logons, off‑hours connections, and repeated attempts to reduce noise and detect abuse early.
- Automate log collection using PowerShell scripts, scheduled tasks, or built-in Windows event forwarding to send RDP logs to a central location for analysis.
Without a structured approach in tracking and reviewing remote desktop sessions, suspicious logons can slip through, leading to tedious auditing workflows and compliance gaps. This guide explains how to collect and review RDP-related Windows event logs using Event Viewer, helping teams detect suspicious activity and meet audit requirements.
5-step process for examining RDP logs
Before you begin, ensure you have administrative access, advanced audit policies enabled, and a central location to store the exported RDP logs.
Prerequisites for querying RDP logs
- Local or domain administrative rights to enable and query RDP logs.
- Advanced Audit Policy configured to capture Logon and Logoff events under the Logon/Logoff audit category.
- Operational logs for TerminalServices‑RemoteConnectionManager and TerminalServices‑LocalSessionManager are enabled in the Event Viewer.
- A central log collector, SIEM, or shared network location to store exported RDP log files.
You will also need PowerShell (or an equivalent scripting engine) available on each endpoint for automated log extraction. With these in mind, you can now jump into the recommended workflow below.
1. Identify key RDP and Terminal Services logs
Event logs contain a massive amount of data, so cut through the noise and identify the specific event logs and IDs that capture RDP activity.
| Event ID | Description |
| 1149 | Successful RDP connection request (RemoteConnectionManager) |
| 4624 | Logon success (Security log) |
| 4625 | Logon failure (Security log) |
| 4634 | Logoff (Security log) |
| 4647 | User‑initiated logoff (Security log) |
| 21 | Session logon (LocalSessionManager) |
| 22 | Session shell start (LocalSessionManager) |
| 24 | Session disconnect (LocalSessionManager) |
| 25 | Session reconnect (LocalSessionManager) |
| 4778 | Remote session reconnect (TerminalServices) |
| 4779 | Remote session disconnect (TerminalServices) |
Focus on the primary event IDs: 1149 (successful connection), 4624/4625 (logon success/failure), 4634/4647 (logoff), 21, 22, 24, 25 (session lifecycle), and 4778/4779 (reconnect/disconect).
Finally, ensure Advanced Audit Policy records Logon/Logoff events in the Security log and document the log paths and IDs in a reference sheet for quick lookup during investigations and alert creation.
2. Query and export events with PowerShell
You can run Get‑WinEvent to pull the desired event IDs and logs, then pipe the output to Export‑Csv to save the results as a CSV file for analysis or reporting purposes. You can review the Get-WinEvent parameters to put together a custom script for any task.
If you are a NinjaOne user, you can also check out the pre-packaged script for using PowerShell to view event logs. The script allows you to omit specific event IDs and filter events based on message content, providing extensive customization options.
3. Establish baselines and alert rules
By establishing realistic baselines and targeting only anomalous RDP activity, you can efficiently detect and diagnose common attacks, such as credential stuffing, brute-force attempts, or lateral movement exploits. Here are some practical alert‑rule examples you can implement today.
Define normal RDP behavior
Identify the typical users, usual login hours, and expected source IP ranges for each system, and record baseline metrics, such as average daily connections and peak login times.
Create anomaly‑based alerts
To further isolate suspicious activities, set thresholds that trigger on > 5 failed logon events (4625) from the same IP within 10 minutes, on successful RDP connections (1149) outside business hours, and on rapid disconnect/reconnect sequences (24 → 25) when the client IP changes.
Implement alerts in your monitoring platform
Configure your SIEM or NinjaOne alert policies to monitor RDP-related activity directly from managed endpoints. In NinjaOne, create custom alert conditions based on specific event IDs or system metrics captured by the agent, and define appropriate notification channels (email, ticketing, SMS, or integrations such as Slack).
Tune alert thresholds over time to reduce false positives by adjusting conditions and exclusions as you observe normal user patterns and maintenance windows. Review triggered alerts regularly, and update your alert rules and baselines to reflect changes in usage patterns infrastructure.
4. Extend retention and increase log capacity
It’s easy to overlook that default event log sizes are often too small for investigation queries.
To configure the default log size, use the wevtutil command in an elevated Command Prompt. Run wevtutil sl (sl = set-log modifies log configuration) and /ms (maximum size, specified in bytes) parameters to adjust the configuration of a specified log (e.g., wevtutil sl <logname> /ms:<bytes>)
Per Microsoft, the minimum log size is 1048576 bytes (1024KB), and log files are always multiples of 64KB, so any value that you enter will be rounded off accordingly. Changes take effect immediately and persist across reboots.
Meanwhile, /rt:<Retention> can be set to true or false (e.g., /rt:true). Setting it to true instructs the system to stop logging events when the logs are at full capacity. The data will need to be manually cleared under this setup.
Choosing false will allow the system to overwrite the oldest events as needed.
Note: If the event log retention mode is set to true and the log reaches its maximum size, Windows retains existing events and discards new incoming events. To prevent unintentionally losing important security or audit data, consider increasing log capacity and utilizing overwrite-as-needed settings when continuous logging is required.
5. Correlate RDP activity and generate reports
Link the collected RDP events with user, device, and IP data to turn raw logs into actionable intelligence and audit‑ready documentation. This should enable you to create a weekly report that displays successful connections, failed attempts, off-hours access, and unique client origins.
Here’s a supplementary guide on how to automate event logging for various environments or clients.
RDP monitoring strategies with NinjaOne
NinjaOne can fill the gaps in your RDP monitoring process by automating audit-policy deployment and alert creation, providing you with reliable, auditable visibility into every remote desktop session.
The NinjaOne script library and array of policy management tools also enable you to centrally manage RDP logs with minimal manual intervention, providing more consistent security coverage while freeing up valuable resources within your IT stack.
Related topics:
- Remote Access Best Practices for MSPs and IT Pros
- Viewing System Details Reports [for NinjaOne users]
- How to Remove Remote Desktop Connection History in Windows
- How to Automate Windows Event Log Monitoring Across Multiple Clients
- Comprehensive Guide to Using PowerShell for Efficient Event Log Searches [Script Hub]
