SOLVED

DeviceLogon events doesn't capture RDP connections (?!?!)

Copper Contributor

I create a custom detection that starts like this:

 

DeviceLogonEvents
| where ActionType == "LogonSuccess"
| where DeviceName has_any (Array of the backup servers)

| where not(AccountName has_any (Array of the expected accounts))

 

...with the idea of catching an unexpected account successfully logging into backup servers (through compromise/privelege escalation).

 

Should work, right?  But upon testing, I've come to realize that RDP logons don't register in the DeviceLogonEvents table.  Is that by design??  Could Microsoft fix this?

 

 

4 Replies

We do capture RDP logons, check the LogonType field for RemoteInteractive in the DeviceLogonEvents table. Reference: https://docs.microsoft.com/en-us/microsoft-365/security/defender/advanced-hunting-devicelogonevents-...

Thanks,
Jake

Are there circumstances where RemoteInteractive logons aren't captured? I have a Server 2019 (Version 1809 Build 17763) host where I've personally done successful RDP logons, but I can search across the last month of logon events a la

DeviceLogonEvents
| where DeviceName contains "hostname"
| summarize by LogonType

Only two logon types are returned. "Network" and "Unknown". For the record, the "Unknowns" are relatively few and do not include my own RDP logons.
best response confirmed by Kyrouz (Copper Contributor)
Solution
I will take a guess here, but it seems like I saw once where a customer had their audit policy overriding the items that Defender turns on. Try running this from an elevated command prompt and ensure the logon successes and failures are enabled:
auditpol /get /category:*

If this looks OK, I recommend opening case with our support team.

Jake
Thanks I'll take a look
1 best response

Accepted Solutions
best response confirmed by Kyrouz (Copper Contributor)
Solution
I will take a guess here, but it seems like I saw once where a customer had their audit policy overriding the items that Defender turns on. Try running this from an elevated command prompt and ensure the logon successes and failures are enabled:
auditpol /get /category:*

If this looks OK, I recommend opening case with our support team.

Jake

View solution in original post