With the recent High Alert from the Australian Cyber Security Centre (ACSC) on the Copy and Paste Compromises, I thought it worthwhile to explain part of the attack at a high level, and linking it back to some recommended ACSC controls.
Where to begin on this journey?
Although compliance is a necessity, simply “ticking the box” is not security. But this blog is not really about compliance at all. It is about a shift in perception to understand that Cyber-security is a never-ending continuum of White Hat vs Black Hat.
So, let us kick-off and follow the stream of events in a brief history of “harvesting credentials” against the backdrop of the security continuum up to this recent ACSC Alert.
Password Guessing
From the early days of computing, the fallible password was implemented as a control to protect accounts and data. This gave rise to the corresponding shadow to this control, such as password guessing tools that used dictionary or brute force attacks. For those more technically inclined, you may recall using Brutus, Wfuzz, Cain & Abel, THC Hydra, to name a few.
Figure 1 - THC Brute forcing a FTP account
These adversary techniques then led to further enhancements to the password control. Unfortunately for the end user, the additional requirements ranging from password length, special characters, lockout attempts and continually changing passwords were born making it easier for them to forget their password or write it down.
The corresponding shadow attack to these password controls was the threat actor garnering further information during the reconnaissance phase, hopefully checking if a password guessing attack would lead to any form of success, or simply lockout all user accounts in a successful Denial of Service if they attempted beyond the limit.
It also led threat actors to pivot to new attacks…
The invention of phishing
As the world moved on and threat actors moved from attacking the network and moving up the technology stack to applications, a new form of social engineering attack came into prominence; and it has only accelerated.
The phishing attack comes in multiple flavors, but fundamentally it involved the following attack vectors to steal a user credentials:
Email with attached file with malicious code to harvest credentials (as well as multiple other attack vectors); and
Email with a spoofed URL to a malicious website to harvest credentials (as well as multiple other attack vectors).
Once attackers had access to user credentials, they could then connect remotely to systems like Remote Desktop Protocol (RDP) or SSH - if they did not already have a backdoor into the systems from the previously mentioned malicious code and other attack vectors.
Multi factor authentication (MFA) to save the day
In the early days, MFA was mostly used by system administrators. After all, compromising an administrative account provided attackers the keys to the kingdom. The shift to general users being introduced to MFA was around the invention of wireless and for remote workers when having to remotely connect into the network as a “road warrior” or working from home during the early 2000’s.
As a side note, it is interesting that MFA was definitely not something new for remote workers prior to Office 365, but there was a trend for organisations to enable Office 365 where all end-users could remotely access corporate applications like Email, File Shares, Teams, etc. from anywhere around the globe, but decided NOT to enable MFA.
And with more companies moving into the cloud, like Office 365, the shadow side was threat actors ramping up their malspam campaigns leveraging the above phishing attacks to harvest account credentials and then gain access to the end user’s Office 365 accounts.
For organisations that failed to enable MFA, they were (and still are) taught a nasty lesson from threat actors that thoroughly trumped any previous arguments and push back on the inconvenience of clicking an accept button on the Authenticator app, or entering an SMS code – All that IT and Cyber talk on MFA now seemed pretty reasonable.
We have MFA enabled, so we are all good right?
For those who have been paying attention during this journey, and read the title, you would already surmise that things are not "all good". But before we get introduced to the newest flavor in phishing attacks called Illicit Consent Grants, let's briefly revisit a typical type of phishing attack and the corresponding control to stop the attack.
A Basic Phishing Attack to Harvest Credentials
Let us say you used Facebook with multi factor authentication (MFA) enabled. Each time you were to login with your username and password, you would be presented with a request for your second factor. You would then use your phone to load up the generated number and successfully login.
Figure 2 - Second Factor Authentication
Now, if a threat actor were to send you a phishing email to harvest your Facebook credentials by redirecting you to a spoofed Facebook login page, even if they successfully harvested your credentials, they would not be able to access your Facebook account as they would not have access to the second factor of authentication (assuming they had not placed a Dropper on your phone).
Now that this has been covered off. Let's move on to how threat actors are bypassing the MFA control via Azure-registered applications. But first, you should be familiar with OAuth at a high level.
What is OAuth?
OAuth is an open protocol that describes how unrelated servers or services can safely allow authenticated access to their assets without sharing the initial, related, single logon credential.
A familiar example is when you go to login to a website, and it asks if you would like to use another website login for access. For example, you can use a multiple Accounts to login to sites like Medium.
Figure 3 - oAuth Sign-On for Medium
A Variation on Phishing with Office 365 Apps and OAuth
With the simplicity in enabling MFA on Office 365 and it also freely available as part of E1, more organisations are implementing this control to secure their environment against the above type of attack vector.
As a result of this shift in security posture, threat actors have been noticing that there are less chances for the previously described phishing attack vectors to be successful - That is why they are pivoting to a newer type of attack with greater chances of success.
This is where Office 365 enters the scene with attackers setting up shop and sending phishing emails with links pretending to be shared OneDrive or SharePoint files.
Figure 4 - Phishing Email with Illicit Consent Grant Attack
Now although it appears to be an Excel Attachment, the underlying link is in fact pointing to an Office 365 application that has been developed by the threat actor. What is interesting at this stage, is that even if the end user had anti-malware or an end-point protection client installed, there is nothing going to set off any alarm bells using these types of controls.
The reason for this, is that to the end client, the link itself appears as a valid Microsoft URL (which it is) that is used to display permission to an OAuth application. And once clicked, since it is a valid use of requesting authentication to Microsoft using OAuth, there is nothing out of the ordinary for these types of end-client controls to alert on.
Figure 5 - Microsoft OAuth Prompt
After clicking the link to the attachment, the prompt presented is not harvesting credentials on behalf of the threat actor. This is a legitimate Microsoft prompt request for oAuth where it requires credentials to allow the spoofed application to access a large degree of the Microsoft Office 365 account.
If the “Accept” button is clicked, then this is where the attacker would take full control of the Office 365 account - whether MFA is enabled or not, does not matter.
Is there a Way to Prevent this Type of Attack?
Microsoft offers CASB and 'behavioural analytics engine' where you can proactively audit and monitor for malicious Azure Apps. This feature is only available using Microsoft's E5 license Tier. Microsoft has an article here: Detecting and Remediating Illicit Consent Grants.
Is there a cheaper Way to Prevent this Type of Attack?
By default, Office 365 allows end users to enable Azure apps by default. This feature can be turned off where the organisation can maintain control and White List allowed applications. Microsoft has an article here: Managing consent to applications and evaluating consent requests.
To Close
The above recommendations are not easily implemented within medium to large organisations and will most likely require a project to build out requirements and deliver to the objectives. In addition, it will most likely impact other areas that will require updates as part of the project, such as:
Security Awareness Training
Incident Response Playbooks
Security Monitoring Use Cases
Application White Listing
Finally, this is only a sliver of the controls that could be implemented and a well developed cyber security strategy is what is ultimately required to provide an adequate level of assurance. If you would like to learn more, then be sure to reach out to us for a confidential discussion.
