Access protection via multifactor authentication is important and right. However, there are ways to circumvent protection measures such as conditional access. In this article, I explain how easy it is to do so.
Multi-factor authentication | MFA
Multi-factor authentication ensures that, in addition to the user name and password query, a further factor must be specified in order to successfully log on to applications and thus gain access to information. A distinction must be made between secure and insecure factors.
Safe factors:
- Device status (compliant / hybrid-connected)
- Certificates
- Windows Hello for enterprise / biometrics
- RSA Token
Uncertain factors:
- Call
- SMS
- Authenticator
- Locations
To require a second factor when logging on to cloud applications, conditional access policies are defined in the Microsoft cloud environment. These policies define which parameters must be met in order to grant users access to applications.
Example: If a logon takes place for an identity that has elevated rights, Conditional Access requires that the access takes place via a device that has the status “compliant”. This status can only be issued by devices that are managed via Intune. If the attacker already has access to the enterprise device, you have other issues….
The goal should be that all access use cases are regulated via conditional access and that access to applications and information is not only possible by specifying a user name and password.
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, originally based on the Nginx HTTP server and acting as a proxy between the user and the website. Now the tool is completely written in GO and includes its HTTP and DNS server, which makes installation very easy.
How does Evilginx2 work?
I decided to set up and test the tool in my lab environment 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 also be found.
It requires two core components: a domain where you can edit the name servers and a Linux host where the tool can run. For my test, I registered a domain through GoDaddy because I couldn’t edit the name servers on my host.
Via DigitalOcean it is very easy and fast to create a Linux host to install Evilginx.
The nasty thing about Evliginx2 is that when the phishlet is activated, it requests an SSL certificate via LetsEncrypt. This means that a trustworthy page is displayed to the “victim”.
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.
Thus, the server running Evilginx2 acts as a “man in the middle” and tricks the victim into believing that he or she is logging into an official website. In the process, credentials and session tokens are recorded.
Procedure
After you install and configure the DNS settings and the phishlet, you get 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 low reputation, is not on the block list and looks trustworthy. After clicking, the victim sees a trustworthy Microsoft 365 login page. Even the branding of the company is taken over.
Suppose the victim is now prompted by Office MFA or Conditional Access to authorize himself via call, SMS or Authenticator. After this is done, the victim is redirected to the original Office 365 page and does not realize 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 has 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, since we already have a valid session token.
Even if the victim has no special privileges in the office tenant, the attacker can reconnect at will and determine which identity has administrative privileges, readout distribution groups, or other information. In addition, the attacker would be able to steal information that the victim has access to.
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 not possible to manipulate the hybrid-join device or compliant device status. Another factor could be a defined IP address range or certificate-based authentication via MCAS.
Summary
It is very easy to configure Evilginx and lure users to a “trusted” site via phishing links in order to intercept credentials.
Administrative activities, in addition to MFA authentication, should only be performed by machines that have the parameter compatible (achieved by Intune) or hybrid-joined (device is joined to the local AD and synchronized via AAD-Connect). These parameters cannot be manipulated at this time.
Identity Protection, Microsoft Defender for Cloud Apps and Microsoft Sentinel can help detect atypical behavior.