In the last blog post, we took an in-depth look at business email compromise. To briefly recap - attackers gain access to a third-party email account in order to insinuate themselves into legitimate email conversations. This can be used, for instance, to manipulate account details in invoices or to send spam e-mails via the compromised account. The FBI has estimated the damage reported by Business Email Compromise (BEC) alone to be almost 2.4 billion US dollars (Internet Crime Report 2021). This level of damage exceeds many times over the damage caused by ransomware. This means that BEC is a serious incident and not "just" a compromised email account, so in the second part of this Azure blog post, we will be taking a closer look at email account security and how to protect Azure accounts.
One of the most effective measures to combat compromised Azure accounts is to institute multi-factor authentication, which we already discussed in part one. Even if users do not enter their passwords on a phishing site, attackers have the possibility to crack weak passwords with tools that are publicly available, such as MSOLSpray.
The MSOLSpray script carries out what is known as a brute force attack. This means that a list of passwords is tried for each user account. This approach is highly successful, especially where there is a weak password policy, and is also often used to initially compromise Azure accounts.
MSOLSpray – Password Spraying Software
One good option for further securing the Azure Tenant is the use of "Azure AD Password Protection". Here, user-defined words can be configured that users are not allowed to use as part of the password. Furthermore, Microsoft has provided a list that increases password security, when combined with the user's own configurable list.
List of words that are not allowed in passwords
Illicit Consent Grant – One click is enough
A lesser-known technique for gaining access to Azure accounts is the "Illicit Consent Grant". Here, attackers send an email to their victim with a link that leads to a prepared application. The application prepared by the attacker demands certain rights from the user, such as access to the mailbox or the profile. Clicking on the Accept button leads to the application being installed in the user account context within Azure. This gives attackers complete access to the victim's account or to all the data that can be viewed with the authorised rights.
A malicious app demands access to the victim's emails
The deceptive thing about this is that the user did not have to enter their password at any time! One careless click is enough to become an attacker’s victim. It is relatively easy for administrators to protect their users against this type of attack by preventing them from installing applications in the tenant.
Specific applications can still be installed by administrators on a per-user basis. Our InfoGuard Computer Security Incident Response Team (CSIRT) believes that attacks like these are becoming more common, due to multi-factor authentication making simple phishing attacks more and more difficult.
By-passing multi-factor authentication
Indeed, multi-factor authentication (MFA) provides highly effective protection against account compromises. However, it is illusory to think that there can be such a thing as 100 percent protection in IT security. Attackers sometimes use methods of attack such as "push notification spamming", where first of all they get the legitimate password from the user via phishing or brute forcing, then try to log in until the user gives their consent to log in via the Authenticator app.
Confirmation prompt for multi-factor authentication (Source: jeffreyappel.nl)
Here, too, one wrong click - just the consent for the login - is enough for the user to give attackers access to the Azure account and so also to be able to set up another authentication mechanism of their own for the login, and in doing so, undermining MFA.
Targeted monitoring of the sign-in logs (as described in the first blog article) can be a good indicator of a suspicious login, even if the user has confirmed the second factor, but even with this type of attack, we can raise the bar for attackers by, for instance, disallowing the use of a simple prompt in the authenticator app, and instead requiring the user to enter an extra number for confirmation. This additional step could already be enough to stop the attack.
No more simple confirmations (Source: jeffreyappel.nl)
A variety of other implementations and techniques can be viewed via the following link:
Shady service providers
Within the Azure sign-in logs, it is possible, to filter specifically on a range of criteria. One of these filters is autonomous systems (AS for short). An AS is primarily used for routing on the internet and can contain several larger networks. Classically, internet server providers and large companies have their own AS or ASN (Autonomous System Numbers).
In various Azure investigations, our InfoGuard CSIRT has consistently seen the following ASN numbers associated with compromised accounts:
- 33438 - HIGHWINDS32
- 25369 - Hydra
- 62240 - Clouvider
- 9009 - M247
- 60068 - Datacamp
- 40676 - Psychz
All of these ASN logins need to be examined more closely. Of course, employees could still log into the Azure tenant via VPN - many VPN providers also use services from the ISPs listed above - but at least hunting for logins from these ASNs is a good starting point as a way of analysing the logins recorded more deeply.
Although it has already been explained above, it cannot be overstated how important multi-factor authentication is. Wherever possible, simple confirmation dialogue should be replaced by entering a number, or other factors such as a token should be used for login to reduce the risk of "MFA prompt spamming".
Preventing the installation of apps
There can be a further security gain for the Azure Tenant by preventing normal users from installing apps. Administrators can allow users to trigger a notification when they want to have an application installed. This notification is then checked by the administrators and the application is installed if necessary. At least, these restrictions can make ingenious attacks such as the "Illicit Grant" more difficult.
The security of Azure accounts can also be increased by using Microsoft's globally "banned" password list, together with a password list of words that are not allowed to appear in passwords. By increasing the complexity of passwords, it is more difficult for attackers to crack an account by simply guessing the passwords.
Would you like to get your Azure configuration checked?
To ensure that you do not become one of the many prominent victims, we can offer you a dedicated, one-off hunting session in your complete Azure environment. The attractive package includes the following services:
- Login analysis: Detection of suspicious logins on the basis of the countries and ISPs used.
- Analysis of configured email rules of all your users.
- Analysis of the user’s installed (Azure) apps to identify what is known as the "Illicit consent grant attack".
- Individual assessment via a short, final report.
- One-off investment of CHF 2,400 - (flat rate).
Are you interested? Our incident response experts in the CSIRT look forward to you contacting them and are happy to check your Azure tenant for hacked accounts using one-time hunting.