Investigating Modlishka Credential Attacks: Old Dog, New Tricks

You may have heard about a new phishing tool called Modlishka, and have questions about its potential impact on multi-factor authentication or single sign-on. To be clear, Modlishka is not a vulnerability in MFA or SSO. Rather, it is an automation tool designed to make it easier for attackers to phish your employees.

In this post, I will outline how Modlishka works, best practices to mitigate the risk of these types of attacks within your Okta environment, as well as why tools like Modlishka are actually good for the security industry.

How Modlishka Works

The objective of Modlishka is to lure end-users to a fake site in order to steal credentials such as usernames, passwords and 2FA factors that traverse through the same communication channel. To accomplish this, Modlishka acts as a man-in-the-middle by utilizing a known web hosting technique called ‘reverse proxying’. The process looks something like this. [ user ] ←→ [ phishing site ] ←→ [ Reverse Proxy | ex. Modlishka ] ←→ [ Real Site ] Phished users visit a malicious site thinking it is Okta, Gmail, Office365, etc., and are prompted to enter their login details. After they enter their credentials, victims will unknowingly be using Modlishka while the reverse proxy component behind Modlishka makes requests to the site it wants to impersonate. Since all traffic is reverse proxied by the tool, no templating is required on the attackers’ part. As a result, attackers do not really need to clone sites, deal with complex javascript, nor maintain any special templates — all of which greatly simplifies the work required for the attack. The tool will “proxy” all traffic and extract the user’s authentication data, while also keeping a copy of the authenticated session in order for the attacker to impersonate the user in the future. But again, the real question is: how can you stop this type of attack?

Using Okta to Mitigate Modlishka-Type Attacks

In most cases, implementing MFA is a simple and effective way to prevent basic phishing attacks. Secondary authentication factors like something the user physically has (i.e., a hard token) or one that constantly changes (i.e., one-time push) are usually enough to keep user data secure. But in the event of a Modlishka-type attack, both the user’s login credentials and the MFA factors traversing through the same channel can be stolen. As a result, in order to further protect your users from new attack vectors like these, let us discuss a few other best practices within your Okta deployment: You can deploy certain factor types that will fully mitigate this type of attack. Push authentication (including via Okta Verify), U2F, AuthN, X509, among others, will render this attack less feasible. Okta Verify Push, for example, uses a different communication channel to verify the factor, thus preventing attackers from intercepting user MFA information via the Modlishka method. The UI also provides the IP address of the location making the requests, alerting the user of the location that the request originated from. From there, the user can opt to deny access if s/he identifies an unknown geography. U2F, as another example, is very resistant to this type of phishing. That said, organizations need to invest significant efforts into planning and deploying U2F for this tactic to be effective. Leveraging any or a combination of these best practices will significantly reduce the success rate for these types of attacks.

Why is Modlishka good for the security industry?

There’s no doubt that Modlishka can be used for malicious purposes. But as someone with an extensive history of doing these types of assessments and building tools just like these myself, I not only admire the cleverness and elegance of this tool, but strongly believe that its creation does a great service for the security industry as a whole. As I said before, the reality is that these types of attacks are already being used by real attackers today. By pointing out these obvious areas for improvement within the security infrastructure, the creators of these tools force security professionals to keep on improving authentication as a whole – which is generally something that we should be encouraging.

Credential-focused attacks remain one of the top attack vectors for threat actors today – and while aspects of their techniques may change and become more sophisticated, the core of the attacks remain the same. Learn more about how to use Okta Adaptive MFA and strong factor choices to mitigate attacks like these at: