During the development of the access concept for Microsoft 365 solutions, access scenarios were planned, dependencies discussed, roadmaps drawn up, users informed, and so on. When I think back to those appointments, I often say that multifactor authentication is secure, and there is no way around it.
2021 I was proven wrong
By joining dinext. pi-sec, I had the task of taking a closer look at a hacking tool and testing it. The findings of this test should influence my approaches to Conditional Access until today. The tool is called Evilginx2.
What is EvilGinx2?
The tool is a man-in-the-middle attack framework and can be used to phish credentials and session cookies. Evilginx2 has been around since 2017 and was initially based on the Nginx HTTP server and acts as a proxy between the user and the website. Now the tool is entirely written in GO and includes its HTTP and DNS server, making the installation very easy.
How does Evilginx2 work?
I decided to set up the tool in my lab environment and test it to understand this.
On the Github page, you can download the tool for free: https://github.com/kgretzky/evilginx2
Videos show how easy it is to bypass 2FA, and a step-by-step installation guide can be found as well.
It requires two core components, a domain where you can edit the name servers and a Linux host on which the tool can run. I registered a domain through GoDaddy for my test because I could not edit the name servers at my host.
The Linux host I set up on DigitalOcean, is super easy and super-fast.
The mean thing about Evliginx2 is that when activating the phishlet, an SSL certificate is requested via LetsEncrypt. This means that the “victim” is shown a trusted page.
Not only Office 365 or Azure Ad is affected by this “problem,” Evilginx2 has phishlets for Facebook, Github, Linkedin, Paypal, and many other services. Accessing these platforms also allows finding out information about companies.
The server running Evilginx2 thus acts as a man in the middle, fooling the victim into believing that he is logging into an official site. In the process, access data and session tokens are recorded.
After installing and configuring the DNS settings and the phishlet, you will receive a URL. This URL points to the Evilginx2 host of the attacker. The URL is sent to the recipient via email. Defender for Office does not filter this email because if the website is new, it has a small reputation, is not blocklisted, and looks trustworthy. After the victim clicks, he sees a trusted Microsoft 365 login page. Even the company branding is adopted.
Suppose the victim is now prompted by Office MFA or Conditional Access to authorize himself via call, SMS, or Authenticator. After this happens, the victim is redirected to the original Office 365 page and does not notice that the username and password and the session have been stolen.
The attacker now sees the credentials and the session code in his Evilginx2 console. This can be imported into a browser plugin via copy & paste. After the import, the attacker only needs to go to portal.office.com and is logged in with the victim’s identity, of course, without having to enter the second factor again because we already have a valid session token.
Even if the victim has no special rights in the office tenant, the attacker can perform reconnection at his leisure and see which identity has admin rights, readout distribution groups, or other information. In addition, the attacker would be able to steal information to which the victim has access.
It becomes especially critical when admin accounts are only protected by a second factor like SMS, call, or authenticator!
For this reason, the device status should also be queried for privileged accounts. However, it is currently impossible to manipulate the status hybrid-join device or compliant device. Another factor could be a defined IP address range or certificate-based authentication via MCAS.
It is straightforward to configure Evilginx and lure victims via phishing links to a site that seems trustworthy at first glance to enter credentials.
Administrative accounts should always be secured with another control, such as a hybrid-joined or compliant device.
Identity Protection, Microsoft Defender for Cloud Apps, and Microsoft Sentinel can help detect atypical behavior.
Suppose the attacker is not accessing the Office or Azure portal from the same IP as the victim and possibly with a different browser agent. In that case, Microsoft’s machine learning will kick in and indicate that someone else has infiltrated.