The hacker can login without credentials using oauth2-attacks via Session. Hacker developed a tool called DEV-1101 which is now tracked as Storm-1101.
AiTM phishing too are replacing various less sophisticated phishing methods. They possess reverse-proxy functionality, allowing them to bypass multifactor authentication (MFA). Microsoft tracks an actor named DEV-1101 who is involved in the creation, maintenance, and promotion of multiple AiTM phishing kits. These kits can be purchased or rented by other cybercriminals, contributing to the industrialization of the cybercriminal economy and making cybercrime more accessible.
Introduction
In the past few days, cybercriminals used a variety of techniques for their OAuth attacks, such as OAuth2 Attacks. The sophisticated attacks sometimes even relied on Microsoft’s own platform to generate invitations to the consent page for dangerous websites or applications.
OAuth-based application attacks frequently focus on senior management, account managers, human resources, and finance personnel—precisely the individuals with privileged access to extremely sensitive information. When such attacks are successful, malicious actors gain permanent entry to emails, files, contacts, notes, Microsoft Teams chats, and other valuable data. In certain instances, they may even redirect users to a phishing site subsequent to obtaining their consent to utilize the application.
Oauth2 authentication
OAuth serves as a commonly utilized authorization framework that empowers websites and web applications to request limited access to a user’s account on another application. A key advantage of OAuth is that it enables users to grant access to their account without disclosing their login credentials to the requesting application. Consequently, users have the ability to specify which data they wish to share, rather than relinquishing complete control of their account to a third party.
Basically, the vulnerability associated with OAuth revolves around the misconfiguration of the OAuth service itself, which can allow attackers to get authorization codes or access tokens linked to other users’ accounts. By acquiring a valid code or token, attackers gain the potential to access the victim’s data, leading to a complete compromise of their account. In fact, the attacker could potentially impersonate the victim user on any client application registered with the affected OAuth service. The specific mechanism depends on the grant type employed. In either case, a code or token is transmitted through the victim’s browser to the “/callback” endpoint specified in the “redirect_uri” parameter of the authorization request.
The fundamental OAuth process finds widespread use in integrating third-party functionalities that necessitate access to specific user account data. For instance, an application may leverage OAuth to seek access to a user’s email contacts list, enabling it to suggest potential connections. Additionally, this mechanism facilitates third-party authentication services, enabling users to log in using an account associated with a different website.
The hackers devised an exceptionally sophisticated method to “acquire” user credentials. I have presented the process through the following slides:
- Phishing: Upon clicking, the victim is redirected to a Bing address.
- Within a few milliseconds, the user is then redirected to a new URL where, depending on the Bing address, a new code via GET is added at the end of URL. This code is a sequence of number and contains the encrypted email address of the potential victim.
- Following another few milliseconds, the victim is randomly redirected to a different website where the email address is decrypted. The hackers have maintained a pool of URLs, regularly adding new ones each day (Forward 2).
- Lastly, the victim is redirected with the username as parameter to outlook.office.com, where is prompted to enter their access credentials.
As a final step, the user encounters the authentic login screen of Microsoft. However, upon entering their credentials, Microsoft sends a token back to the previous URL (controlled by the hacker). This token, serving as a random number for login purposes, grants the hackers the highest probability of accessing the data.
Possible mitigations
To enhance security and mitigate the types of attacks observed in the previous lab, it is considered a best practice for client applications to establish a whitelist of legitimate callback URIs during registration with the OAuth service. Consequently, when the OAuth service receives a new request, it can verify the redirect_uri parameter against this whitelist. If an external URI is provided, an error is likely to occur. However, it is important to note that there might still exist potential methods to circumvent this validation process. During the auditing process of an OAuth flow, it is advisable to conduct experiments with the redirect_uri parameter to gain a better understanding of its validation mechanism. For instance:
- If additional values can be appended to the default redirect_uri parameter, there is a potential opportunity to exploit inconsistencies in how the URI is parsed by various components of the OAuth service. For instance, you can attempt techniques such as:
- In some cases, you may encounter server-side parameter pollution vulnerabilities. As a precautionary measure, it is recommended to test by submitting duplicate redirect_uri parameters in the following manner:
MFA Bypass
In the following illustration, you will find a depiction of the TCP Protocol and the connections involved in a MFA bypass scenario.
After the initial redirect triggered by URL 1, the victim establishes connections to URL 2, 3, 4, or 5 through a Reverse Proxy. This proxy assumes control and monitors all TCP connections to and from URL 2, 3, 4, 5, and the Microsoft Portal.
The yellow dot indicates the moment when the proxy is capable of capturing the “Authorization code,” while the red dot indicates when the proxy can steal the “OAuth Token.” These tokens enable the hacker to log in as a user.
Using this technique, the hacker can circumvent common MFA Authentication systems such as SMS, Microsoft Authenticator, and potentially even FIDO Hardware authentication (e.g., yubikey).
Please consider that the presented scenario outlines a potential use of TCP/DNS Protocols to bypass MFA. It is important to understand that this a result of a “reverse engineering” to illustrate the possible connections. Please note that there is no guarantee that the connections and sequences depicted are exact or definitive.
Awareness
It is important to remain vigilant and cautious when interacting with emails, messages, or websites, particularly when they request personal information or involve sensitive transactions. Verifying the authenticity of the source, checking for suspicious indicators, and  being cautious of clicking on unfamiliar links or attachments, can help prevent attacks.