Windows365 – First look at MimiKatz


Disclaimer : This post documents some of my findings when carrying out my own research and understanding the threat of Credential Grabbing. This was also to provide awareness to the End-user Computing community regarding this issue. Links to tools and some of the specifics around the attack have been deliberately omitted from this article. However, you should have the appropriate knowledge and skill of using exploit and vulnerability testing tools before adventuring down the path of playing with security exploit tools. Any use is at your own risk!

Introduction

I recently read about Mimikatz and wanted to understand how easy it was to obtain the User name and password through a remote session.

Remote session: Terminal Services/RemoteDesktopServices/RDP Protocol.

In this article, we look at how Mimikatz works and the exposure to Windows 365, Azure Virtual Desktop, and traditional MSTSC users. We then take a look at how we can reduce the risk of something called credential grabbing.

First Look

So to be able to test Mimikatz, you need to download mimikatz tool. As you can see from the screenshot below, Defender antivirus real-time protection blocks this as a default.

However, by disabling Microsoft Defender Antivirus, we can download the testing tool. As you can see from the screenshot below, I could launch Mimikatz with no disruption from endpoint security/Microsoft Defender.

When looking around within Mimikatz, I was by default able to pull lots of information regarding the user, session SID etc. This is not something you want to share or make available.

The good news is that you can prevent LSA data extraction using a registry key (LSA Protection). The key to set is:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa and Set the value of the registry key to: “RunAsPPL”=dword:00000001.

You can read more on LSA protection here: https://docs.microsoft.com/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection

The screenshot below shows the registry entry being applied.

Once you have applied the registry entry and rebooted your machine, I get the following error when trying to output LSA information, as shown in the screenshot below.

Now that we have resolved this issue of outputting LSA, let’s take a look at dumping Credentials from terminal services.

Credential Dumping

Before we get into this topic, at the time of writing there is no way to stop the dumping of credentials if the Bad actor obtains access to the system for MSTSC, Azure Virtual Desktop, and Windows365. So the only way to prevent this issue from occurring is to harden security where possible to restrict/prevent bad actors from obtaining access to systems.

As you can see from the screenshot below, I was successful in dumping my credentials out on Windows365, Azure Virtual Desktop and MSTSC.

I do not intent to get into the details of how these credentials are obtained but as I understand it, today they is no way of preventing the attack using mimikatz. I also note that Security vendors have taken action in an attempt to prevent users from downloading and running Mimikatz, however that does not resolve the issue. You will also note from the security communities, bypassing AV is not overly difficult to achieve.

The other point I wanted to address was, what stops an exploit being created which can achieve the same objective as Mimikatz?

Mimikatz is a exploit testing tool used to understand the risk/impact and test the attack however, trojans and other techniques will most likely be harder to detect.

Even with turning on all the bells and Whistles, Like Operating system security Harding, Trusted Launch, and others like Credential guard, Mimikatz was still able to grab those credentials. You can see from the screenshot below, I was able to dump my test account details after spending time hardening the Operating system.

The following tweet details some of the testing completed in the attempt to strengthen security, but just to prove the point, it does not matter how many additional layers of protection you add here, credential grabbing is still possible.

RD Web Client

At first I was not able to grab the credentials using the WebClient. However after messaging Benjamin Delpy, he was able to update the version of mimikatz, in less than 13 hours.

The tweets below shows my initial findings of not being able to pull the user creds and the second tweet shows @gentilkiwi being able to collect remote credentials from the Web Client.

So who does this effect ?

As you may or may not know, many vendors today have built their solutions around RDP. If a bad actor can gain access to your remote session, your credentials could be grabbed.

What can you do to reduce the risk ?

The golden question…

So here I am going to cover off a few things to help you reduce the risk, however, these tips do not prevent Credential grabbing.

Multi Factor Authentication: Its recommended that you use two factor authentication. Some may say this is as useful as a chocolate fire guard however its better to have a second verification than none.

Admin Credentials: Ensure users have only the required permissions to the desktop. In most VDI environments, apart from persistent desktops, there is no real need for admin permissions.

Prevent Interaction with Microsoft Defender Antivirus: Preventing the user from accessing the AV console can help and if controlled by the admin, you should consider preventing users from accessing the Microsoft Defender Antivirus.

LSA Protection: Add the registry key for LSA protection as covered in this article.

Operating System Security Hardening: Apply security hardening as recommended by Microsoft.

App locker: Prevent unwanted software using App Locker.

Endpoint Detection / Response or  Extended Detection and Response : With the significate increase in threats over the last couple of years, its strongly recommended that you consider an integrated endpoint security solution that combines real-time continuous monitoring and collection of endpoint data with rules-based automated response and analysis capabilities.

The above suggestions will help reduce the risk of a bad actor accessing systems however it does not stop the ability to grab credentials.

Benjamin Delpy also made some recommendations which you should take note of.

Conclusion

In this article, we looked at the issue of collecting LSA information and credential grabbing. We start off looking at extracting LSA information about the user, how to prevent it and then moved on to the main topic of credential grabbing. It was established that you cannot at the time of writing prevent credential grabbing on Windows365, Azure Virtual Desktop and MSTSC (tested). However, you can apply security controls and hardening techniques to reduce the risk of a bad actor obtaining access to run such attacks on your network.

This was quite an interesting piece of work I have to say, and a big thank you to Benjamin Delpy and Marc-André Moreau for contributing and providing insights!

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Create a website or blog at WordPress.com

Up ↑