Illicit Consent - WST

Let’s face it, most of us click “accept” without thinking about it.

We install software, and don’t read the EULA. We just click “Accept.” We install an app on our phones or tablets to while away the time sitting in the airport waiting for our flights. And we click “Accept.” We simply accept that things are the way they are, and it’s just not worth our time to be bothered with such trivial things, exchanging security as if it were currency to buy convenience.

This conditioning has led to a normality that is a problem if your employees are allowed to attach company or personally owned devices to your data, especially in the realm of Microsoft 365 hosted platforms, where a user could allow a newly installed mobile app access to the data and apps on their device and consequently your institution’s data, by clicking “Accept.”

An illicit consent grant attack can start many ways, but the most commonly recognizable way is through a phishing campaign. A user is lured into installing an app and the threat actor is counting on the conditioning of the user to blow through the permission granting process, to which they—through the nefarious app—are then given access to institution data and NPI. Once access is granted, depending on the downstream security settings in an environment like the Microsoft 365 infrastructure, the threat actor now owns, at the very least, the account of the user that is already authenticated to the tenant and the data to which they have access. And it’s likely that now the threat actor will attempt to gain elevated access and move laterally through the infrastructure, exploiting access to things like PowerShell Online and legacy protocols.

It may be the threat actor simply gives themselves access to the email in the mailbox. Or they take it one step further and start sending out emails internally attempting to dupe other unsuspecting users—the email was sent internally after all—into giving up credentials or other security related information, or to install the app that started it all in the first place.

In the time it takes Microsoft to detect and disable the nefarious app in the Microsoft Store, the damage is done. And it may go undetected for months, resulting in SAR filings, insurance claims, and reputational damage to the institution.

The point of this writing is not to fear monger, but to give a perspective into just one type of concern for what appears to be a benign migration to a newly established Microsoft 365 tenant to replace an old on-premises Exchange Server. There are a myriad of other concerns about uncontrolled access, like allowing your users to just invite anyone into the tenant from outside the institution, to linking their user accounts to social media platforms, etc.

It’s not good enough to simply migrate. There must be thought given to securing the environment and applying best practices to security in the cloud, which align with guidance and regulation. The migration is only half-done if security considerations aren’t accounted for and tested. Information Security Officers and Internal Auditors should be asking these questions and pushing internal IT staff and managed service providers to prove that what they are doing is secure.

If you’re interested in having a Microsoft 365 tenant or Azure subscriptions security review, please reach out to us. We are here to help.

Authored by: David Matt, CEH