Microsoft Accounts Targeted with New MFA-bypassing Phishing Kit
A new large-scale phishing campaign targeting credentials for Microsoft email services use a custom proxy-based phishing kit to bypass multi-factor authentication.
Researchers believe the campaign’s goal is to breach corporate accounts to conduct BEC (business email compromise) attacks, diverting payments to bank accounts under their control using falsified documents.
The phishing campaign’s targets include fin-tech, lending, accounting, insurance, and Federal Credit Union organizations in the US, UK, New Zealand, and Australia.
The campaign was discovered by Zscaler’s ThreatLabz researchers, who report that the operation is still ongoing, and the phishing actors register new phishing domains almost daily.
Starting in June 2022, Zscaler’s analysts noticed a spike in sophisticated phishing attempts against specific sectors and users of Microsoft email services.
Also Read: This Educator Aims to Make Good Cyber Hygiene a Household Practice
Some of the newly registered domains used in the campaign are typo-squatted versions of legitimate Federal Credit Unions in the United States, as shown in the table below.
Notably, many phishing emails originated from the accounts of executives working in these organizations, whom the threat actors most likely compromised earlier.
Another set of phishing sites used domains names that focus on using password reset lures as part of their email campaigns:
The threat actors added the links to the emails either as buttons embedded in the message body or inside attached HTML files that trigger redirections to the phishing pages.
The redirections occur via legitimate web resources to help evade email and internet security tools, with the threat actors showing a preference for open redirects on Google Ads, Snapchat, and DoubleClick. Sadly, some platforms do not consider open redirects a vulnerability, leaving them available for abuse by threat actors.
CodeSandbox and Glitch are also extensively abused in this campaign to help the hackers create new redirection routes without much effort.
Also Read: The 5 Phases of Penetration Testing You Should Know
“A common method of hosting redirection code is making use of web code editing/hosting services: the attacker is able to use those sites, meant for legitimate use by web developers, to rapidly create new code pages, paste into them a redirect code with the latest phishing site’s URL, and proceed to mail the link to the hosted redirect code to victims en masse.” – Zscaler
Bypassing MFA with custom phishing kit
With the enterprise rapidly adopting multi-factor authentication, stealing users’ credentials is not enough to gain access to an account if MFA is enabled. To bypass MFA, threat actors are turning to tools like Evilginx2, Muraena, and Modilshka.
Using these reverse proxies, the adversaries can sit in the middle between the victim and the server of the email provider, hence why they are called “AiTM” (adversary in the middle).
The email server requests the MFA code during the login process, and the phishing kit relays that request to the victim, who then enters the OTP on the phishing box. The data is forwarded to the email service, allowing the threat actor to log in to the stolen account.
However, the phishing proxy sitting in the middle of this exchange can steal the resulting authentication cookies, allowing the threat actors to use these stolen cookies to login and bypass MFA for the particular account.
What makes this campaign stand out is the use of a custom proxy-based phishing kit that has the peculiarity of using the “Beautiful Soup” HTML and XML parsing tool.
This tool allows the kit to easily modify legitimate login pages pulled from corporate logins and add their own phishing elements. The tool also has the added benefit of beautifying the HTML in the process.
The kit isn’t perfect, though, as Zscaler found some URL leaks to the requests sent onto the Microsoft server, which can make detection possible on the vendor’s side.
Zscaler set up a test instance to let the attacker roam and monitor their post-compromise activity and found that the hackers logged into their account eight minutes after the compromise.
Apart from logging into the account and evaluating the account and reading some of the messages, the threat actor didn’t perform any additional actions.