Skip navigation
Duo Labs

Raising the Bar - Anomaly Detection

At Duo Security, we take the security we provide our customers very seriously. Our engineering teams spend significant time modeling threats and considering various attack scenarios where, even with the presence of two-factor authentication, an attacker may be successful. It’s our job to solve these technical problems, continue to raise the bar, and provide the best security possible.

Recently, PSC, a PCI compliance provider, contacted us with a report that was not a vulnerability in Duo’s service, but more of a complicated attack scenario where a user may be tricked into approving a fraudulent Duo Push request. The scenario that PSC reported and demonstrated to us, outlined below, is one that we have thought about in the past. While we agree that this specific attack scenario is possible, the level of access and/or data required to make it successful makes it highly unlikely to occur in a real-world environment. That said, this specific scenario helps us highlight the importance of continually raising the bar against attackers and is a great reason to add a category of settings to our product known as Anomaly Detection. This setting will mitigate this kind of attack and our labs team will continue research and add additional features and functionality as necessary..

Anomaly Detection

The scenario PSC outlined requires that first, an attacker must obtain ALL of the following:

  • Network access to the target system
  • Network access to the resources the target is authenticating to
  • Knowledge of the target’s primary credentials (username / password)
  • Knowledge of the use of two-factor authentication
  • Ability to execute code on the target system
  • This code must have the necessary privileges to monitor specific processes and network traffic of the target’s system.

From an attacker’s perspective and in a targeted scenario all of the above are possible, but not trivial, to obtain. The attack also relies on the target user not noticing any activity that would alert them to a possible attack. To understand the attack scenario, let’s take an excerpt from the PSC report.

PSC Attack

Note that the PSC report specifically calls out RDP. However, this attack scenario would work against other two-factor protected services and is dependent on how those services react to multiple authentication attempts by the same user in quick succession.

This report demonstrates a noncritical issue. However, it is still an issue that we should think about ways to prevent or, at least, make less possible. So how do we fix this?

The first reaction is, of course, to look at our end user interface, where we report the requesting IP address with each push. Changing our user interface to make multiple push requests more obvious to the user may help. However, we are very cautious here at Duo in making changes that may impact the overall user experience. Besides, this would also put the burden of security where you least want it. In our view it is far better to give Administrators the tools they need to recognize and even block this scenario.

With that in mind, we decided to make changes to how our push process works to give Duo administrators the ability to block anomalous Duo Push attempts via an option in the admin interface. This new feature will begin showing up in the admin interface tomorrow where administrators can enable it if they so choose.

To understand what we mean by anomalous attempts, review the PSC attack scenario and understand that for this type of attack to work, the attacker must have the ability to send a fraudulent push attempt immediately after a legitimate push is made. Enabling this feature will block any push attempts that are too close together and create an entry in the log files alerting administrators to the behavior.

Anomalous Push Log

Users will also see the following notifications when this condition is triggered:

Anomalous Push iFrame

Anomalous Push Warning

Customers who have put together automation that leverages two-factor authentication will either want to add delays to their process or not enable this feature at all. If you are unsure of whether to enable this feature, please contact support.

This is only the first change we are making in order to raise the bar and make our system even more resilient to attack. Over time, we will add more features and capabilities to our Anomaly Detection category. We will, of course, communicate those changes and explain why you may want to consider enabling them in your deployment here on our blog, offer our recommendations, and update product documentation as necessary.

We would like to take this opportunity to thank PSC for taking the time to demonstrate this attack scenario and report it to us. An important part of continually improving and re-accessing the security of our system is working cooperatively with external parties who may have vulnerabilities or attack scenarios to share with us. We are always willing to listen and discuss these findings, and can be reached via email -