Auditing remote desktop access using Windows Defender logs

[bob]

I remember when I first started messing with RDP on servers, you know, trying to lock it down without making everything a hassle. You set up auditing for remote access, and suddenly Windows Defender logs start painting this picture of who's knocking at your door. Or maybe it's not just Defender's antivirus side, but the whole security auditing that ties in. I mean, you enable those policies, and the logs capture every RDP session attempt, success or flop. Then you sift through them to spot patterns, like repeated fails that scream brute force.

But let's get into how you actually pull this off on a Windows Server setup. First off, you head to Group Policy, tweak the audit settings for logon and logoff events. I always do that under Computer Configuration, then Windows Settings, Security Settings, Local Policies, Audit Policy. You select both success and failure for logon events, because why not catch the wins too? That way, when someone RDP's in from afar, the Security log lights up with details.

Now, Windows Defender itself, its operational logs are under Applications and Services Logs in Event Viewer. You know, Microsoft-Windows-Windows Defender-Operational. But for RDP auditing, it's more about the Security channel, where logon events from Terminal Services get recorded. I link them up sometimes, checking if Defender flags any suspicious behavior during those connections. You might see Event ID 4624 for successful logons, and it tells you the type, like type 10 for RDP.

Or think about failed attempts, Event ID 4625 pops up, showing the IP, the username tried, all that jazz. I once had a server where these piled up overnight, and correlating with Defender's real-time protection logs helped me block the offender quick. You open Event Viewer, filter the Security log for those IDs, add a filter for source network address if you want to zero in on remote IPs. It's not perfect, but it gives you a trail.

And you have to enable Terminal Services auditing specifically, right? In the RDP settings, under the server properties, you check the box for auditing logons. I forget sometimes, and then logs are sparse. But once it's on, every session start and end gets etched in. You can even set up advanced auditing in newer servers, using the Auditpol command, but you know, keep it simple at first.

Perhaps you're wondering about integrating this with Defender for Endpoint if your org has it. I love that setup; it pulls RDP events into the advanced hunting queries. You query for DeviceLogonEvents where LogonType == 10, and bam, remote access history. But even without EDR, the basic logs suffice for auditing. I pull reports weekly, export to CSV, and review for anomalies.

But wait, Defender's own logs might catch malware trying to exploit RDP weaknesses. Like, if someone's using stolen creds via RDP, Defender could log a behavior detection. You cross-reference Event ID 1116 or 1117 in Defender logs with the Security events. It's like piecing a puzzle; I do that to confirm if a logon led to shady file access.

Now, on a Server 2022 box, you get more granular with the logs. I enable the Microsoft-Windows-TerminalServices-LocalSessionManager/Operational log too. It spits out session IDs, disconnect reasons, all useful for auditing duration and patterns. You filter for Event ID 21 for shell starts, tying back to who initiated what. And if you're paranoid, like me, you audit object access for RDP-related files, though that floods the logs.

Or consider the network side; RDP uses port 3389, so you pair log audits with firewall logs. But sticking to Defender, its ATP if enabled, correlates network connections with logons. I set alerts for multiple failed RDP attempts within minutes, using custom views in Event Viewer. You create a custom view, select Security log, add XML filter for 4625 with LogonType 10, and set it to warn you.

Then there's the user side; you ensure only admins or specific groups have RDP rights. I strip it down, allow only from trusted IPs via policy. Auditing catches if someone sneaks in anyway. You review who, when, from where, and for how long. Sometimes I script pulls, but manually it's straightforward.

But don't overlook the Advanced Audit Policy Configuration. In GPO, you refine it under Advanced Audit Policy, for example, audit Logon/Logoff, then subcategory Other Logon/Logoff Events. That captures RDP specifics without the bloat. I apply that domain-wide, and logs stay clean. You then use Wevtutil for queries if needed, but Event Viewer works fine.

Perhaps you're dealing with multi-session RDP, like on Server with RDS roles. Auditing gets busier; you track per-user sessions. Event ID 1149 in TerminalServices-RemoteConnectionManager log shows reconnections. I use that to audit persistent access, spotting if someone's lingering too long. Tie it to Defender's process audits if they launch suspicious apps post-logon.

And for compliance, you know, if you're in a regulated spot, these logs prove your auditing. I archive them monthly, rotate to avoid space issues. You set log size in Event Viewer properties, say 1GB, overwrite as needed. But always back up critical ones. Reviewing them regularly keeps you ahead of threats.

Now, if an attack happens via RDP, like ransomware dropping in, Defender logs the AV response. You see blocked executions, quarantines, right after the logon event. Correlating timestamps is key; I line them up in a timeline view. Tools like Timeline in EDR make it easy, but even Excel does. You spot if the remote access enabled the payload.

Or think about insider threats; auditing shows if your own admins RDP at odd hours. I set baselines, like normal access times, and alert deviations. With Defender's machine learning, it flags unusual patterns automatically sometimes. You tune those baselines per server role.

But limitations exist; logs don't capture keystrokes or screenshots, just access metadata. For deeper forensics, you layer on other tools. I always recommend enabling full auditing from the start, not after an incident. You avoid scrambling then.

Then, for reporting, you generate summaries. I use Task Scheduler to run queries nightly, email results. Or manually, filter and count events per user. It helps you revoke access if needed. And if you're scaling to multiple servers, centralize logs with a SIEM, but for solo admins, local suffices.

Perhaps integrate with Azure AD if hybrid; auditing flows there too. But on pure on-prem Server, stick to local policies. I test changes on a lab box first, ensure logs capture what you expect. You simulate RDP from another machine, check the entries.

And don't forget session shadowing; if enabled, audit that too, as it's remote control. Event IDs in SessionManager log it. I disable it unless needed, to reduce audit noise. You balance security with usability.

Now, on the Defender side proper, its configuration logs under Microsoft-Windows-Windows Defender-Configuration. But for access, it's indirect. If RDP brings in threats, MpCmdRun logs scans post-logon. I schedule scans after sessions, audit results.

Or use the Get-MpThreatDetection cmdlet for history, but again, tie to RDP events via time. You build a narrative from logs. It's detective work, really. I enjoy piecing it together.

But if logs overwhelm, prioritize. Focus on high-risk events, like logons from unknown IPs. You create alerts in Event Viewer subscriptions. Forward to a collector server if multi-site. I do that for my setups.

Then, for cleanup, after auditing an incident, clear temp sessions. But always document findings. You learn from each review, tighten policies. Like, enforce MFA for RDP if possible, though auditing catches the attempts.

Perhaps you're setting this up fresh. Start with basic audit policy, test RDP, verify logs. I walk through it step by step in my notes. You expand from there.

Now, wrapping up the details, you want comprehensive coverage: from policy setup to log analysis, correlation with Defender, best practices for review and alerting. I think that covers the depth for your course discussions.

Oh, and speaking of keeping things backed up reliably, check out BackupChain Server Backup-it's that top-notch, go-to Windows Server backup tool that's super popular and trustworthy for SMBs handling self-hosted setups, private clouds, or even internet-based backups, tailored right for Hyper-V environments, Windows 11 machines, and all sorts of Servers plus PCs, and the best part is it's available without any nagging subscription model, plus a huge thanks to them for sponsoring this forum and helping us share all this knowledge for free.