(Ransom)Where are Microsoft 365 users now vulnerable?

A common misconception among enterprises and their users leads the belief that cloud environments are immune to threats of ransomware. However, in a recent discovery made by Proofpoint researchers, malicious actors can instigate ransomware attacks by exploiting Microsoft 365 file version backups – made available thanks to the platform’s native file “auto-save” feature.

In simple terms, a cybercriminal can encrypt all known versions of a file, even those backed up, in a way that makes them irreparable without dedicated backups or a decryption key from the attacker.

Unfortunately, this isn’t the first time that ransomware has crossed the line into the world of Microsoft 365. Drawing back 6 years ago now, the Cerber ransomware strain had set its sights on Microsoft 365 and managed to expose millions of users with a novel zero-day attack that had the ability to circumvent native Microsoft 365 security.

How, you ask? Using similar techniques still in use today: phishing emails with malicious file attachments, tricking users into allowing macro content, weaponizing third-party applications, and various other methods.

As cloud services accumulate vast numbers of users in a single ecosystem, they become prime targets for cyber criminals. Just imagine the damage a well-designed ransomware attack can inflict on a large segment of enterprises that all use Microsoft 365 services. In 2020, as we saw in the first successful attacks on SolarWinds and Microsoft, the economic impacts have the potential to be devastating.

How did these breaches occur?

Cloud services and applications are more mission-critical for businesses than ever before. It’s no wonder then why criminal actors continue to place cloud platforms like Microsoft 365 in their crosshairs, knowing victims will be far more inclined to pay the ransoms. The attack vectors here involve exploitation of native Microsoft 365 features for cloud backups. Threats that “live off the land” using built-in tools and parameters are typically more challenging to mitigate, since they can be abused more easily and are harder to detect and prevent.

What can be done?

A combination of best practices can help significantly reduce the impact of attacks like these, especially when the initial attack vector here still involves the compromising of an Microsoft 365 account by takeover.

Basic measures like forcing Step-Up and Multi-Factor Authentication (MFA), enforcing strong password standards, maintaining strict identity access controls, and continuing investment into employee awareness training programs should not be overlooked.

Outright preventing such risks will always be challenging for the reasons mentioned above. For that reason, set triggers and anomaly parameters to detect suspicious outliers and activities that may be potentially threatening, such as abnormal administrative actions or data access requests that may be the warning signals for tampering of version backup limits and AutoSave configurations.

Many third-party applications connect to SaaS platforms (like Microsoft 365 in this case) via OAuth tokens. Unlike new users logging into an environment, OAuth tokens don’t need to authenticate via an identity provider after their initial grant. Once the app has access to Microsoft 365 and its data via OAuth, it maintains that access indefinitely until access is revoked. For this reason, make sure you revoke tokens and access to suspicious apps reaching back into your Microsoft 365 tenancy.

Organizations should always plan for the worst by adopting an “assume breach” mindset. Thus, in times like these, offline backups are never a bad idea in addition to tried-and-tested BC/DR recovery procedures.