Often times while performing penetration tests it may be helpful to connect to a system via the Remote Desktop Protocol (RDP). I typically use rdesktop or xfreerdp to connect to host once I have obtained credentials to do all sorts of things such as use Active Directory Users and Computers or SQL Management Studio. One of the roadblocks I have ran into is that my client is protecting access to RDP on Windows with Duo. This can be a real pain, especially when port 3389 is the only port open on the jump box that I need to be able to pivot to another network. Last time this happened I found an article by Alex Lomas on Pen Test Partners which detailed the methods that you can use to bypass this.
These attack methods are valid assuming that the target had configured their Duo implementation to “fail open”. This is actually very common, as it is the default setting. If a system has Duo 2FA configured to fail closed and they lose internet connectivity or have issues with DNS, they get completely locked out of their workstations/servers. This is not acceptable for all but a few organizations and thus fail open is the most common choice.
There are two ways that I will demonstrate how to bypass this:
- Assumption: You can gain a shell on the system
- A local bypass will be used
- Assumption: You cannot access the system
- A network based attack will be used
- Assumption: You have control over the DNS server of a system
- An upstream DNS bypass will be used
Local Bypass
Gain a shell with the method of your choice. I typically use CrackMapExec + Metasploit or wmiexec.py but there are many choices out there. Once you are on the target via a method that does not require 2FA, run the command:
ipconfig /displaydns
I will typically pipe this to a file in case it is really big and I need to parse it. The contents need to be reviewed to locate the Duo API DNS entry. Each unique Duo install will have a different API endpoint that it speaks to.
If for some reason there is nothing in the DNS cache, it may be required to trigger an authentication request. If this must be done, avoid using an account that you know is enrolled with Duo as this may send a push message, text message, or email to their phone.
An alternative to this is finding a Duo.txt log file which will list the API endpoint. It can typically be found in C:\ProgramData\Duo Security\duo.txt
The next step is to edit the hosts file on the system. This requires administrator access.
Go ahead and back up the original hosts file. After doing that, modify the current hosts file. This can be done simply by appending it with a single entry that maps the Duo API endpoint to localhost.
At this point you should now be able to RDP into the system with just a username and password if Duo is set to fail open. Restore the hosts file when finished.
Network Bypass
If you do not have administrator credentials or SMB/WMI/etc is not available, you can deny access to the Duo API with a Man-in-the-middle (MITM) attack.
To perform this you can use Bettercap. Bettercap is described as “The Swiss Army knife for 802.11, BLE and Ethernet networks reconnaissance and attacks.” For our attack we will use it perform an ARP spoofing attack and a DNS spoofing attack.
The first step is to perform an ARP spoof. The target will need to be set to the IP we are trying to access. Bettercap will trick that host into believing we are the default gateway. To perform this attack the attacker must be within the same broadcast domain as the victim. If this is not the case, the attacker may have to utilize a different method other than ARP spoofing to gain a MITM presence.
After installing an running Bettercap, enter:
>set arp.spoof.targets [VICTIM IP] >arp.spoof on
Bettercap will automatically enable forwarding.
Note: You must be running Bettercap as root for it to enable forwarding
After the ARP spoof is working you will need to perform the DNS spoof. in Bettercap, type:
>set dns.spoof.domains *.duosecurity.com >dns.spoof on
This will modify any DNS query for a subdomain of Duo security. It will respond with the attacker IP address, which is fine because we just want to break the API from working properly.
While this is running, the attacker can now log into the system via RDP without needing to use 2FA. Once logged in, quit Bettercap. Bettercap will re-ARP the target but it may take a few minutes before the DNS entry expires.
Console Bypass
While this requires something other than default settings, I have seen a few clients check the third box, “Only prompt for Duo authentication when logging in via RDP.” Many times administrators want to prevent remote attackers from authenticating, but have more trust in users who have physical access. The problem that I have found is that a “local” logon can also be performed remotely in some cases.
If the client is using VMware or Hyper-V to virtualize some of their infrastructure, this could be used as an additional attack path to access Duo protected systems. Often times I will see that after gaining credentials, there will be a VMware web interface available to connect to. Users may also be able to connect with the Hyper-V or VSphere software client. Once connected, each virtualized system can be connected to via the virtual console. When you connect to the console, the system treats this the same way they would a local logon. Because of this, Duo will not prompt for MFA.
DNS Bypass
If you are already Domain Admin or have control over the DNS server, you can effectively disable Duo on your target system. For example, you have DA, but the system you are after is on a system that only has port 3389 open, so you can’t edit the hosts file on the system itself. You can then target it’s upstream DNS server. Of course once DA you can do many things like push GPO and other methods to get remote access, but this is easiest way to get directly to RDP.
While in many cases you may not need to gain RDP access to achieve your objectives an attacker, it can be extremely helpful. One of the cool things about RDP is that if you connect with credentials that have an active session, you will take over the desktop session of that user. This can be useful if that user had their KeePass, Lastpass, or 1Password vault open, or if they are actively logged into an internal resource on the web or via software on their system. In the case of internal web resources, it is possible to pull cookies from the browser on disk, but certain things like HTTP basic authentication headers I do not believe reside anywhere on the hard drive, and you could only recover that data by dumping memory. While tools like KeeThief can sometimes pull the password from memory once shell access is obtained, RDP can often make this easier as well as account for other types of vaults or authenticated software that is less understood.
Update July 28 2022:
Check out this article for an in-depth breakdown. Most notably, even if an installation is not configured to “fail open”, you can modify it to act this way by modifying the registry keys assuming you have admin access through a different channel.
