During an internal penetration test conducted by the Plaintext Cybersecurity Solutions team, we came across an interesting scenario involving Duo Security.
The goal was to connect to a machine via RDP in order to run a critical application and demonstrate the business impact of the vulnerability to the client. Even though we had already obtained administrative privileges (chained from previous attacks), the Duo Security service was preventing the connection, as shown in the following image:
In this post, we’ll share how we found a way to bypass this control, the implications of doing so, and why this raises questions about the limitations of certain security solutions.
What is Duo Security?
Duo Security, acquired by Cisco, is a solution that adds two-factor authentication (2FA) to services such as SSH, RDP, and VPN (even on platforms that don’t natively support it).
Its strength lies in protecting access to critical systems. However, its own documentation acknowledges certain limitations. For example, Duo does not protect Windows SMB connections.
The Finding During Testing
Knowing that Duo Security does not protect SMB connections, we connected to the target machine from another host over SMB and accessed the directory where Duo Security was installed.
Our first idea was to check whether any process was actively using Duo’s files and then attempt to make the system fail to locate those files when needed. Following that approach, we renamed the Duo Security folder named “WindowsLogon” to “WindowsLogon.old”.
When we tried to establish an RDP connection, we noticed the system immediately reinstalled Duo Security and blocked us again.
Here’s the error message showing the block after reinstallation:
Knowing this behavior, we created a PowerShell script (DuoBypass) that takes a backup of the original WindowsLogon contents and then replaces the files with blank replicas. This tricked the system into thinking Duo was still present.
Once executed, the directory looked like this:
And the folder’s contents were all empty files.
At this point, when we attempted to connect over RDP, we were able to successfully access the system (effectively bypassing the 2FA control).
Here’s a video showing the full attack sequence:
Reporting to Cisco and Duo Security
We reported the finding to Cisco’s PSIRT in August.
Their response was quick and professional. However, they stated they did not consider this a vulnerability since the bypass requires local administrator privileges. From their perspective, an attacker with admin rights could disable Duo in several other ways (uninstalling it, modifying the registry, etc.).
Reflections
In our opinion, a security product should remain resilient even against compromised local administrators. This is something EDRs and antivirus solutions already implement with stronger self-protection mechanisms (protected processes, file integrity checks, signed drivers, etc.).
In a real-world attack scenario, if an adversary already compromised an endpoint with admin privileges, 2FA should still serve as a barrier to prevent lateral movement over RDP.
Conclusion
This finding is not meant to highlight a critical flaw but to expose a blind spot in Duo Security’s protection model.
Our recommendation is that security solutions like Duo should integrate stronger self-defense mechanisms to ensure effective protection (even when facing attackers with elevated privileges).
Ultimately, security shouldn’t become optional just because the adversary has local administrator rights.
Recommendations
If your organization uses Duo Security, we recommend considering the following monitoring and hardening measures:
Optimized by Seraphinite Accelerator