Attackers and RDP MRUs

Now I finally got the time to continue with mapping the data out of my Tanium RDP MRU Sensor.

But first a couple of things. Two people responded to my last Blog entry and pointed me at the HKEY_Users hive (HKU) to get my data easier. And they are partly right. The HKU holds the ntuser.dat content for all active users. The problem is, active users means actively logged on user. So for my scenario, investigating lateral RDP movement this will not be enough. So long story short, you’ll still need some coding if you want to get all the information.

Today I acquired some data from a testnetwork at my workplace using Tanium. As it is Sunday it contains only a small subset of the machines which are usually there. So the dataset contains mostly servers, including a fair share of jumpservers. So it’s actually a good dataset to start with.

My test dataset

My theory is, that if an attacker uses a known account or probably even an account created by the attacker, we should be able to follow his trail through the network. What I’m looking at is something like this.

Expected outcome

Creating a Graph like that would require me to have source, destination and username for an RDP MRU. That’s nice because I have that already as CSV exported out of my Tanium Sensor results. To see something that looks like attack I added some fake Data into the mix. Essentially someone using an account called attacker who jumps from a notebook to a jumpserver, from there to another server and yet another server and so on, you get the idea. I also assume, that I’ll definitely discover some logon habits of the people on the testsystems.

Once the data is ready, the question is how to filter it, plot it and do that all over again to support dynamic analysis. After some search I decided to start with an existing tool rather than building something. The tool I choose is Gephi ( which is a very well known graphing software in data sciences. The best of all, it’s free.

So I had to figure out how that tool works. After investing an hour on it I got pretty much the result I wanted to have.

Plotting the full dataset

The first thing I checked out was the most active user in the dataset. The data immediately shows typical administrative behavior – quite disciplined though. looking up the username it is indeed an administrator. So even if the data looked chaotic at first, graphing it did allow to draw conclusions.
For obvious reasons I had to remove the node names (hostnames) from the picture. But the Two central nodes are jumpservers, thus being the target for connections from this user. The more remote nodes are servers the Admin jumped to using the jumpserver. The fat line between the two jumpservers indicates the administrator used both of his accounts to move between the servers in both directions which is perfectly in line with the policy.

Normal admin

So let’s see how a simulated attack vector looks like. My assumption here is, that the attacker used an account that never uses RDP normally or an account he created himself for lateral movement. Thus filtering for the username in the dataset will only show the adversary moving. If the attacker uses more than one account, it’s perfectly possible and even quite easy to plot all the action in one run.

Simulated attacker

I’m quite happy with the results and plan to give it a shot in a bigger, real network. That opens up a new way of hunting to me, so I guess it was worth the while. There are some additional things I need to mention. First and foremost finding the attackers targets works in any case if he uses RDP for lateral movement and you are able to differentiate between legitimate users and attackers. In the worst case you need to check with the owner of the compromised account which hosts he usually accesess using RDP and filter those out.
Having said that, there is a limitaion in some networks. As soon as roaming profiles are used widely, the ntuser.dat of the users will be roamed as well. This means that the source for the MRUs is not necessarily the machine the entry was added to the registry. In this case real step-by-step tracking does not work anymore. Secondly there is almost no timing aspect to that data. You can usually deduct which move came first, but not when. In that case you would need to leverage eventlogs if they have not rolled already (which they most likely have as you’d have used them if you could in a first place). The huge advantage is that the data I leveraged here stays on the system for very long. I remember the profiles of some admins still being present on my company notebook after I was in the company for several years. Those guys had already left the company by then.

So to summarize, RDP MRUs are a great way to track lateral movement using RDP even a long time after the attacker has left. It does not work as well when profiles are roaming but still gives some value in that case. If you have any questions just ping me on twitter @mathias_fuchs.

Copyright Cyberfox 2019
Tech Nerd theme designed by Siteturner