Businesspeople are being compromised by an Office pop up asking them to grant permissions to what that looks like a normal Office app (see image below). By clicking, they're unknowingly providing a bad actor's application with access to their contact info, mailbox settings, and sign-in access. Scary stuff that you'd know to decline, but the kind of thing everyday co-workers often click to accept. Proofpoint claims 1 in 5 people are falling for it.
When they do, the perpetrator will have account-level access to data and be able to impersonate the victim, sending emails and accessing files on their behalf. Alarmingly, normal remediation steps are not effective against this type of attack, since these third-party applications are external to the organization. That means the attacker can access the account without requiring Multi-Factor Authentication (MFA), even if MFA is on for the victim's account. That's because by clicking, the user is telling Azure Active Directory that the app is approved in any situation.
Microsoft doesn't let just anyone create an app that can pop up like this. Last year they created a verification process where only valid partners can publish apps that O365 organizations can install. But bad actors are infiltrating legitimate O365 tenants, then launching their malicious apps from within, circumventing MSFT's current check/balance. Their blog states that "Proofpoint has detected several tenants hosting what appear to be one or more malicious OAuth apps, affecting multiple other tenants."
How to deter the attack
By default, Microsoft allows users to make their own decision about approving apps. It's kind of like allowing users to have Administrator access on their PCs. To reduce this risk, admins can make a change to prevent the installation of apps, unless approved by an admin. Per Microsoft's guidance: By default and having "this setting on, those apps will ask users for permission to access your organization’s data, and users can choose whether to allow it. If you turn this setting off, then admins must consent to those apps before users may use them."
Microsoft leans toward self-service in most cases. If you do restrict users' capability, but want to keep them from waiting too long, they go on to advise "consider setting up an admin consent workflow in the Azure portal so users can send a request for admin approval to use any blocked app." See Microsoft's instructions to require admin consent before end-users see any such prompts. Organizations using/developing a lot of their own applications will inherently add delay.
Steps for detecting this attack
Want to see if you've had this happen already? MIcrosoft provides instructions at https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/detect-and-remediate-illicit-consent-grants?view=o365-worldwide. Their guidance includes regular checks of the Azure AD Audit logs, shown below.
Open the Security & Compliance Center at https://protection.office.com.
Navigate to Search and select Audit log search.
Search (all activities and all users) and enter the start date and end date if required and then click Search.
Click Filter results and enter Consent to application in the Activity field.
Click on the result to see the details of the activity. Click More Information to get details of the activity. Check to see if IsAdminContent is set to True.
Steps for responding to this attack
If you do see that "True" tag, then dive deeper into the issue, especially if you see unrecognized or new apps.
After you have identified an application with illicit permissions, you have several ways to remove that access.
You can revoke the application's permission in the Azure Active Directory Portal by:
Navigate to the affected user in the Azure Active Directory User blade.
Select the illicit application.
Click Remove in the drill down.
Credit to Krebs on Security for reporting a year ago about the onset of this risk, and Proofpoint who just recently cited significant enough instances of the attack to publish their findings. Krebs' current post summarized the risk well, and shows a screenshot of a stealthy SharePoint permissions prompt. If people receive an email from an internal (compromised) colleague saying "Check out my file on SharePoint" (or OneDrive), they'd likely click through these permission warnings.
Feel free to reach out to email@example.com if you've got any questions on this or other Microsoft 365 security topics.