Remote Desktop Protocol: How to Use Time Zone Bias

Most defenders are familiar with how to find and look for suspicious RDP lateral movement, whether that means looking based on known-compromised users or on an alert from antimalware or EDR protections associated with a specific user. You’re starting to pivot from the initial notice that something’s wrong; now what? 

Examining the logs to check account-activity timestamps is a typical way to spot odd behavior – for example, James-from-the-head-office connecting to a domain controller at 3 a.m., when he typically only accesses the Sage servers, and those only during business hours. However, there’s more to know about logins – not just when the activity occurred, but the time zone from which the activity originated. This is known as the bias, and it’s captured on modern (Windows 10 / Server 2016 and later) versions of Microsoft’s operating system. Event ID 104 is available in the Microsoft Windows Remote Desktop Services RDP Core TS Operational event log. 

What does the defender see? 

As one might expect from the name, this event logs the time-zone bias from UTC of the machine making the connection. Since you probably already know the time zone(s) your users would normally be logging in from, seeing deviations from that zone can help you identify suspicious RDP connections, simply because they’re not coming from the part of the planet they should be. 

Taking James as our example again, let’s say James is based in London and that you’re investigating suspicious activity in the early months of the year. In January or February, the time-zone bias for James would be zero hours UTC, so if James is using RDP to connect to the network for whatever reason, the client time bias you should see on his logins is [0]. If, suddenly, you start seeing client time zone biases of [-8], or [6], or other values that differ from the norm for James, that could help you spot potentially suspicious RDP connections, or at minimum more questions worth asking. (Is he traveling? Was his machine stolen?) 

Let’s take an example where a user’s credentials have been phished, the attacker’s logged into the VPN — because you don’t have MFA enabled, though you know you should — and they start accessing devices using RDP. You would then start to see the time zone of that attacker machine for those access events.  

There’s no single query that magically delivers every answer, and this one’s no exception. For instance, attackers often host their machines hosted on various machines, located in various time zones in which they may or may not be physically located. Still, they’re likely to differ from the normal time zones for your users.  

Another potential weakness lies in false positives; if your organization operates in a way that makes it hard to discern what a “normal” time zone looks like, it may be harder for you to pinpoint the difference between signal and noise. Finally, false negatives are a possibility; the event records the time zone on the attacker’s machine, so the attacker can undermine this data by changing the time zone on that machine. That said, Event 104 is a beneficial event to keep watch over – one more tool in your defense toolkit. 

Timezone bias and Live Discover 

Event 104 is of course available to anyone examining Microsoft systems of the supported vintages (again, Windows 10 / Server 2016 and later). The information in the final section of this post is provided for those readers using Sophos’ Live Discover to get the job done. (However, we’ll publish the query we’re about to discuss on our Github, where anyone can pick up a copy.) We also demonstrate this query and its results on our YouTube channel. 

To execute an OS query and return timezone bias information in Live Discover, use the following: 

SELECT         strftime('%Y-%m-%dT%H:%M:%SZ',datetime) AS Datetime,         source,         eventid,         JSON_EXTRACT(data, '$.EventData.TimezoneBiasHour') AS TimezoneBiasHour     FROM sophos_windows_events     WHERE         source = 'Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Operational'          AND eventid IN (104) 

The output of the query looks like the results shown in Figure 1: 

Figure 1: Either the user has discovered a way to teleport themself and their computer across eight time zones in 90 seconds, or something is wrong here 

On the left in the image above, we have the endpoint name – the same for both entries in this two-event log. We see the date/time information in UTC, which shows that the two events occurred about a minute and a half apart. The source is where we found this event, which is shown as 104 in the next column. And on the right, we see the result – the first event originating in UTC 0, the second UTC +8, which is the area indicated in the map in Figure 2.

Figure 2: UTC +8 is a fascinating slice of the planet, but it’s definitely not near James in London. (Map image courtesy nationsgeo.com) 

We recommend executing this query across all devices within your environment – look around and identify if there are timezone bias entries in the RDP Core TS Operational event log that differ from what you would typically expect. 

Remote Desktop Protocol: The Series

Part 1: Remote Desktop Protocol: Introduction (post, video)
Part 2: Remote Desktop Protocol: Exposed RDP (is dangerous) (post, video)
Part 3: RDP: Queries for Investigation (post, video)
Part 4: RDP Time Zone Bias ([you are here], video)
Part 5: Executing the External RDP Query (post, video)
Part 6: Executing the 4624_4625 Login Query (post, video)
GitHub query repository: SophosRapidResponse/OSQuery
Transcript repository: sophoslabs/video-transcripts
YouTube playlist: Remote Desktop Protocol: The Series