Series
BEC

Consenting adults: the perils of application-based attacks

Neil Meikle
Published 
Wednesday
 
16
 
September 2020
RSSLinkedIn
Part four in our series on business email compromise

Business email compromise (BEC) is a widespread and costly type of cyber attack that has surged in recent years. In this regular, bite-sized series, we look at the scale of the problem, the rapid rise in account takeover attacks on the Microsoft 365 platform, how investigations of these attacks are changing, and what all of this means to businesses, their cyber insurers and their legal representatives.

The previous article in this series is Seven critical steps to avoid business email compromise.

Illicit consent

As organisations roll out security measures such as multi-factor authentication (MFA), threat actors are incentivised to evolve quickly and focus their efforts on more sophisticated, novel attacks. We can already observe a rise in attacks that are difficult to detect, that circumvent or avoid MFA, and that capitalise on the shift to remote working and the increase in cloud applications.

In the previous article in this series, we looked at the seven critical steps for avoiding business email compromise. Hidden away mid-table was the need to address risk from third party apps, which has steadily crept up the rankings this year as a vector of attack. Third party web apps offer a wide range of genuine services, delivering capability and convenience to Microsoft 365 users at the touch of a button. To provide these services, third parties need access to sensitive user data and need the ability to control users’ accounts.

In more orthodox phishing attacks, the threat actor sends an email to the targeted user – typically with a fabricated story, a faked identity, and an urgent call to action. The email might contain a link to a malicious website that invites the individual to enter their credentials. Consent phishing on Microsoft 365 is slightly different: it is an application based attack that relies on OAuth 2.0 and a malicious third party app. Here’s how it works.

First, the threat actor builds and registers a malicious third party application, often with a credible name that may sound similar to an existing app.

A Microsoft-branded email is then sent to one or more targeted individuals, probably offering access to a document via a prominent Open button.

A sample consent phishing email. (Microsoft blog)

The process so far is the same as a familiar, conventional phishing email. (Although note that a phishing email isn’t necessarily needed for this type of attack.) Normally, we would expect the phishing email to direct the user to a malicious site. But instead, they are taken to a legitimate consent prompt page. This is a genuine page that requests approval for a registered app. Unfortunately, the app is malicious, so when the user clicks on Accept to provide their consent, the threat actor gains access to the account and any sensitive data it contains.

“Once victims clicked on the deceptive links, they were ultimately prompted to grant access permissions to a malicious web application (web app)... Unknown to the victim, these malicious web apps were controlled by the criminals, who, with fraudulently obtained permission, could access the victim’s Microsoft Office 365 account.”

- Microsoft takes legal action against COVID-19-related cybercrime, 7 July 2020

In the following image we can see that the consent page appears to be authentic (although a threat actor would use a more convincing name than Risky App, which is used for illustrative purposes only). The only small giveaway is that the app is unverified, but this alone doesn’t mean that it is malicious.

Genuine application consent prompts can trick users into providing malicious web apps with access to their account and data. (Microsoft blog)

What makes consent phishing so dangerous?

This is a difficult attack for end users to spot because the consent page is genuine, and on the surface it is virtually indistinguishable from a legitimate app's page. If multi-factor authentication has been set up, the user is likely to have already authenticated. And unlike conventional phishing attacks, there is no prompt that asks the user to divulge their username and password.

Sample COVID-19 themed lures in attacks seen in the US. (Microsoft blog)

Just as concerning, MFA offers limited protection. Organisations that suffer a conventional phishing attack are protected from repeated use of compromised credentials if they have MFA in place, because even with a valid username and password the threat actor needs the additional method of authentication. A user might enter this once at the point of compromise, but is less likely to do it every time the threat actor wants to sign in. But for consent phishing, the unauthorised access gained by the threat actor is persistent. By consenting to the attacker-controlled app, authorisation codes and access tokens are generated that enable the threat actor to maintain access without any further authentication and make API calls on the user’s behalf through the malicious app.

Consent phishing is also difficult for organisations and their administrators to control and detect. By default, users can connect new third party apps and provide full access permissions to their account and data. Businesses need to carefully consider whether they want their users to be able to consent to apps on behalf of their whole organisation. From a monitoring and detection perspective, malicious web apps look very similar to legitimate apps, especially if large numbers are being used across the business.

From consent grant to data breach

The SANS Institute recently fell victim to a consent phishing scam that used a malicious Microsoft 365 third party add-on.

In an article published shortly after the breach, SANS not only publicly reported the incident, it also shared details of the attack. Thanks to this information sharing, we know that a phishing email was sent on 24 July 2020 to several SANS employees with a sender name of no-reply@sharepointonline.com and a subject line of File “Copy of sans July Bonus 24JUL2020.xls” has been shared with <recipient>.

The consent phishing email used in the SANS Institute attack. (SANS Institute blog)

After clicking on Open, the user granted access to a web app named Enable4Excel, which is very similar to a legitimate Salesforce add-in named Enabler4Excel. A data breach followed that exposed approximately 28,000 records containing PII (personally identifiable information). The threat actor created a forwarding rule that relayed 513 emails to an external email address. Although the forwarded messages did not contain passwords or financial information, they included some sensitive data such as names, job titles, addresses and countries of residence.

The forwarding rule itself will be familiar to anyone who has investigated a BEC scam. Named Anti Spam Rule, it forwarded emails that contained finance-related keywords such as “wiring info”, “iban”, “purchase” and “swift”. (As a side note, because of its heavy use by threat actors, Microsoft announced that automated external email forwarding will no longer be enabled by default in Microsoft 365 from September 2020. Deployment of this change was delayed slightly, but all validation work by Microsoft has been completed so the roll-out is due to resume on the publication date of this article, 16 September 2020.)

Lockdown lock down

Microsoft proactively identifies and removes malicious apps, although understandably this is a never-ending undertaking. In July of this year, Microsoft announced that it had brought legal action to take down domains that were used to host malicious web apps, with names including officehnoc[.]com, officemtr[.]com, officeinvetorys[.]com, and mailitdaemon[.]com (square brackets added to prevent live links; full list here).

“Microsoft recommends disabling end-user consent to applications.”

- Managing consent to applications and evaluating consent requests, Microsoft Docs

There are also steps that organisations can take to reduce their risk of compromise. We have prepared five key action points that will enable businesses to prevent, detect and respond to incidents more easily.

1. Provide training to employees

  • Communications should go out to employees specifically mentioning this type of attack and the risks of approving unverified apps. Individuals need to know that fake apps exist and that they often use names that are similar to popular, legitimate apps.
  • Ensure that employees have general cyber awareness and have been trained in how to spot a phishing email.
  • Individuals should be suspicious of emails (particularly unsolicited messages) with tell-tale warning signs, e.g. an unexpected call to action such as clicking a link or opening an attachment, spelling and grammatical errors, domain names that are unusual or seem to be copying legitimate domains, or elements that just don’t add up.
A blue verified badge appears next to apps that have been “publisher verified”. (Microsoft documentation)

2. Limit user consent permissions

  • One of the recommendations in last week’s checklist was preventing users from consenting to new apps on behalf of their organisation.
  • Implement additional policies that only allow users to consent to applications that have been published by a verified publisher.

3. Deploy administrative review

  • Consider going even further than this by preventing users from consenting to any new permissions or to new apps without administrator approval. Only minor configuration changes are required in many Microsoft 365 environments to create a safer process for app approval. By enabling the admin consent workflow, users are required to request approval for an app. All requests are directed to a nominated administrator. Be sure to communicate these changes to employees.

4. Monitor web app use and consent grants

  • Audit third party apps and granted permissions to keep track of app usage, particularly unverified apps. Indicators of illicit consent grants can be observed by administrators in audit logs or by running PowerShell scripts.
  • Consider granting tenant-wide admin consent for frequently used applications, although be careful to limit permissions to highly privileged operations on behalf of the entire organisation.

5. In response to an incident, block access and investigate quickly

  • During our business email compromise investigations, we always look for new application consent grants in the time window covering the attack. We need to complete our investigations quickly, so we inventory all applications and their permissions using our automated tools. New grants increase the risk level for an account and ultimately indicate how the compromise may have taken place.
  • Note that resetting the compromised account’s password does not block the threat actor’s access. Instead, the application's permissions must be revoked . As a short term fix, the user’s ability to sign it to their account can be blocked, which also disables app access to data in that account.

Find out more

Asceris’ business email compromise investigations combine the hands-on experience of our incident response specialists with our custom-built technology, enabling our customers and their insurers to respond quickly and with confidence. Our services leverage extensive automation, advanced analytics, automatic risk scoring, best in class IP address geolocation, external data feeds and intuitive reports, enabling us to uncover evidence rapidly from a wide range of data sources.

If you are the target of an active business email compromise attack, please request emergency assistance immediately.

Asceris offers a proactive risk assessment for Microsoft 365 environments to our cyber insurance partners and their customers. Our report presents environment-level risks and user-level risks that are based on our experience of responding to Microsoft 365 business email compromise incidents.

To find out more about any of our services, please contact us. To start a conversation or to report any errors or omissions, please feel free to contact the author directly.

Neil Meikle
LinkedInenvelope by Bluetip Design from the Noun Project
Neil is Asceris' Chief Technology Officer. Over the last 19 years, he has delivered a variety of large multi-jurisdictional investigations and has spoken frequently at conferences on technology-related subjects. He maintains deep hands-on expertise in a wide range of technical subjects including digital forensics, cyber incident response, forensic data analytics, machine learning and artificial intelligence.

About Asceris

Our mission at Asceris is to reduce the financial and business impact of cyber incidents and other adverse events. By understanding the cost drivers of claims and addressing these proactively through automation and continuous process refinement, we are able to deliver high quality incident response services in close collaboration with our industry partners.

Follow us on LinkedIn or subscribe to our RSS feed to make sure you don’t miss our next article.

Other recent insights