How hackers hack two-factor authentication

How hackers hack two-factor authentication

Hacker forums abound with proposals for hacking into accounts. In most cases, attacks are arranged with the help of phishing with a spoofed authorization page. However, this method is ineffective if the user receives SMS with a verification code.

The most popular 2FA method is SMS with check codes generated by OTP technology. The code comes in different ways each time, so it is almost impossible to guess.

However, the more difficult it is to overcome the protection with technical methods, the easier it is to do it with social engineering. Everybody is so confident in the reliability of two-factor authentication that they use it for the most responsible operations – from authorization in Google (which is immediate access to mail, disk, contacts and all the history stored in the cloud) to client-bank systems.

The ability to bypass such a system has already been demonstrated by the Australian researcher Shubham Shah. However, his method was quite complicated in practical implementation. It used call authorization instead of SMS, and it was necessary to know the victim’s phone number and part of the credentials beforehand. PoC was not very convincing, but it outlined the vector of the attack.

Hacking two factor authentication with Modlishka

At the beginning of 2019, the Polish researcher Piotr Duszyński made publicly available a reverse proxy Modlishka. According to him, this tool can bypass two-factor authentication, which we will now check.

If we compare it to the same SEToolkit (it is built into almost all popular pentest distributions), the difference is this: SET clones and hosts the authorization page on the local server. There, everything is based on scripts that intercept the input of the victim’s credentials. It is of course possible to set up a redirect to the original site, but the traffic from the victim to your server will be unencrypted. In fact, such programs act as web servers with a fake (phishing) site.

Modlishka acts differently. It generates its own certificate which encrypts the connection from the victim to our server (so as not to be fake). This machine then acts as a reverse proxy.

In other words, all traffic goes to the original site with an instance on our server. The hacker has the credentials and the authorized session of the victim is captured. A classic MITM attack preceded by phishing (somehow the victim has to be forced to install a fake certificate and send it to the fake site).

Stand to bypass two factor authentication

Let’s raise the server with Modlishka inside the local machine. I will do this with Kali Linux as an example but there will be no fundamental difference for other distributions unless the path to the Go source code changes slightly.

First we put Go – this language is written in reverse proxy and it will not compile without Go.

1$ apt-get install golang

Next, we specify the path to the source directory:

1$ export GOPATH=’/root/go’.

You can check everything with a command

1$ go env

The GOPATH must be specified in the output.

Command output

Then we clone a branch with the tool.

12$ go get -u$ cd /root/go/src/

We create a certificate:

12$ openssl genrsa -out secret.key 2048$ openssl req -x509 -new -nodes -key secret.key -sha256 -days 1024 -out cert.pem

Now it is necessary to transfer the contents of the key and certificate to plugin/autocert.go file and replace the value of two variables:

  • const CA_CERT – certificate value (pem file);
  • const CA_CERT_KEY – key value (file key).
File autocert.go after changing the certificate

Now we gather all this business:

1$ make

It takes three to ten minutes to compile, depending on the amount of computing resources.

The file itself is located in the directory dist/ called proxy. To check it, you can run it with the key -h – help output.

1$ ./dist/proxy -h

Bringing out Modlishka help


Countries and sessions of the victim

As I wrote above, to create a victim transparent encrypted channel before our reverse proxy, you must first export the certificate to the browser. The following steps are explained on the example of Mozilla Firefox x64 v. 67.0.

Before starting, let’s have a good look at the contents of another file in the templates directory. We are interested in google.com_gsuite.json. A detailed description of each item can be found at for this configuration.

The content of google.com_gsuite.json

There are two options to start Modlishka: manually and with the configuration file. To start manually, the minimum command looks like this:

1$ ./dist/proxy -target -phishingDomain -listeningPort 443 -tls

Launch using the configuration file:

1$ ./dist/proxy -config /templates/google.com_gsuite.json

Let’s start from the config and go to the in your browser. We will be taken to We log in to the account and see the victim’s credentials appear in the terminal output.

Login and password in Modlishka output

If you go to (very symbolic), you get a control console for the captured session (currently a beta function). At this stage we intercepted the victim’s login and password without any encryption errors and in a “secure” connection. As far as I know, other tools of similar purpose can’t do this.

What should we do with two factor authentication now? Tell you what: there is a blank UUID field in the control panel and this number is the key to everything.

If you immediately click on the Impersonate user (beta) button, an empty tab will open and the Modlishka console will tell you that there is no UUID for the user. It must be specified, but it is specified at the beginning – it is specified in the link to our evil URL. To do this, let’s go back to the configuration file.

We are interested in the line “trackingParam”: “ident”. In it you need to set the ident value for our URL to look like this:


It is to this (or additionally obfuscated) URL that the victim should be directed.

This time, after clicking and authorizing on such a link, a session with a filled UUID will be available in the control panel ( I will show you exactly what it looks like later on with a real example.

Now, when we click on the big yellow button we will see a beautiful blue animation and in five to ten seconds we will get into the victim’s authorized session, despite the difficulties of two factor authentication. The victim will, as usual, receive and enter the confirmation code, seeing the encrypted connection and the real Google authorization panel, but without noticing the Modlishka reverse proxy jammed in the middle.

Although I have given the Wiki all the parameters of the configuration file, there is one more thing. After the victim entered the credentials, it is desirable to prevent logging out of the account and save the authorized session. This makes the parameter terminateTriggers. If you specify in this parameter the URL to which the user will be redirected after successful authorization, then when such an address appears all traffic will be redirected to the original URL, and the authorized session will not be affected even after logging out of the account.

Ready set for NAT

Attacking inside one car or LAN was not so difficult, but with the preparation as a PoC “combat” stand in WWW I initially had a hiccup. It will require either redirection to a white (external) IP address, or a dedicated server with such an address. You can rent a server from 300 rubles per month.

When I rented this server on Kali Linux there was no problem. The VDS had Ubuntu Server on it and when Golang was installed it turned out that the default repositories had a very old version of Go which generated a lot of errors at compile-time. In this case it is necessary to add actual Go repositories and install a fresh version.

The first problem is the domain name. If you go from the victim’s computer to the URL, it will not work, because external and uncontrolled us DNS do not know this address. If you redirect to the IP address of the machine with Modlishka, the victim will get directly to the Google page, bypassing the proxy server, and in the terminal output we will see two lines:

12Host does not contain the phishing domainRedirecting client to

If the victim is in the same local network, you can set the IP – URL match in the local DNS or in her hosts file. In my case, this was true:


On the Internet I first tried to register a free 3rd level domain. I thought that would be enough, but it was not there! At the transition was only a page that the site is not available, and when you enter the IP address via HTTPS redirected to Google. By simple HTTP and opened the welcome page Apache.

As usual, the devil lies in the details. When you go through a URL in the global network machine adds the prefix www, and the program was waiting for a clean call to the domain. Adding www in the config did not help, and had to get into their possession a full pool of subdomains. In other words, if the domain looks like, you should have *

The next hiccup concerns certificates. It is necessary to make a certificate and a key for the registered domain. Ideally it is necessary to sign a certificate in the certification center, but for the test you can use a self-signed one.

Go to any certificate generator, make and download two files. Their contents should be inserted in the Modlishka configuration file according to the “cert” fields: “” and “certKey”: “” in the Modlishka configuration file. A small remark: the certificate and the key must be on the same line and the line break must be specified by the sequence \n as usual.

It should look like this:


Also in the configuration file we need to change a couple of other parameters:

    • “phishingDomain”: “” – here instead of we set our domain;
    • “listeningAddress”: “” – you have to replace it with, otherwise only the lo-interface is listening and everything will work only inside the local machine.


Modlishka is deployed for specific domain names each time. Therefore it is better to initially register a domain name, then get a certificate and only then deploy the technical part. In this case you can import the contents of certificates into autocert.go, and you do not need to write the certificate key into the configuration file.


The Modlishka control panel session is very lively. It does not die until the user (or the hacker) comes out of it. That is, if the victim closes the tab, the authorized session will remain active. If you re-authorize directly on, and then log out of your account, the session will still remain alive. Even if you stop the Modlishka server and run it again, the session will still remain alive. There is only one guaranteed possibility of deauthorization – to log out at the moment when you only “redirect” to the proxy.

Although the article described the technical details, two-factor authentication bypass will not work without social engineering. It is necessary to disguise the site and somehow install the certificate on the victim’s computer. However, it might not be that difficult. Most users willingly follow the instructions starting with the words “disable antivirus and firewall”, and even if the certificate is installed, few ordinary people will see the potential danger.



WARNING! All links in the articles may lead to malicious sites or contain viruses. Follow them at your own risk. Those who purposely visit the article know what they are doing. Do not click on everything thoughtlessly.


0 0 vote
Article Rating
Notify of
Inline Feedbacks
View all comments

Do NOT follow this link or you will be banned from the site!
Would love your thoughts, please comment.x

Spelling error report

The following text will be sent to our editors: