Attackers have been targeting SaaS solutions for a long time but almost nobody talks about how the Techniques, Tools & Procedures (TTPs) in SaaS attacks differ significantly from traditional TTPs seen in networks and endpoint attacks.

How do you create meaningful detections in SaaS environments that dont have endpoint or network data? How can you investigate threats in a SaaS environment as an analyst? What does a good SaaS environment look like, and what does a threat look like? Finding skilled security analysts that can work in traditional IT environments is already hard it gets even harder when trying to hire security people with SaaS domain knowledge.

SaaS consumers are left with only a few choices: either use the native SaaS security controls provided in each SaaS solution and rely on the (non-)maturity of the SaaS provider or go with a third party SaaS security solution, often in the form of Cloud Access Security Brokers (CASBs). Both cases are often not ideal.

This article outlines two attacks that have recently been observed in SaaS environments that are representative of the broader SaaS threat landscape. The analysis serves to illuminate the sharp distinction between a traditional network attack and a SaaS compromise.

Anonymised SaaS threat 1: Office365 Business Email Compromise

In what amounted to a classic business email compromise (BEC) attack, a threat-actor infiltrated an employees Microsoft 365 account to access sensitive financial documents hosted in SharePoint, including pay slip and banking details. The attacker went on to make configuration changes to the hacked inbox, deleting items and making updates that may have allowed them to cover their tracks.

The employees account login was first observed from unusual IP ranges. The account in question had never logged in from Bulgaria before, and the peer accounts belonging to those from the same department had not exhibited similar behavioural traits. This in itself was a low-level anomaly and not necessarily indicative of malicious activity employees might change locations after all.

The unusual login location was then accompanied by an unusual login time and a new User-Agent. All of these anomalies called for a deeper analysis.

It was then identified that the account was starting to access highly sensitive information, including payroll information on a Sharepoint.

The attacker tried to gain insights about payment information and credit card details, with the likely intention of changing the payroll details to an attacker-controlled bank account. But AI-enabled security technology was able to put together these weak signals of a threat and illuminate the likely account compromise. The companys security team was then able to lock the account and alert the user, who subsequently changed their credentials.

Anonymised SaaS Threat 2: Box.com Compromise

Unauthorised access to a corporate Box.com file storage account belonging to an employee of a global supply company was observed. The Box.com account login took place in the US the same country that this organisation operates in but from an unusual IP space and ASN. Made suspicious by this low-level anomaly, further, ongoing investigations into the users activity were carried out.

The actor behind the account logged in to Box.com successfully, and then proceeded to download expense reports, invoices, and other financial documents. It became evident that the account started accessing files that were highly unusual for the account to access. It was also identified that neither the account itself, nor its peer group were usually accessing the file calledPASSWORD SHEET.xlsx.

Cyber AI additionally detected that the activity occurred at a highly unusual time for the legitimate user, and that the location of the actors IP address was anomalous compared to the employees previous access locations for this particular SaaS service.

While accessing these documents may have been normal for the employee in another context, having an understanding of user behaviour and granular visibility within the Box.com application allowed the company to spot the subtle signs of account compromise. Moreover, the AI-enabled security system was able to illuminate the wider narrative, understanding that each unauthorised file exposure was part of a connected incident and highlighted the breach as a key concern for the security team.

Conclusion

Traditional detection approaches like more than X failed logins from Y are not enough to ensure sufficient security across SaaS applications. Keeping threat intelligence lists up to date is even more difficult, as most SaaS attacks dont involve any Command & Control just indiscriminate logins from remote devices. Attackers may use VPN, Tor, other compromised devices, dynamic DNS, or virtual private servers to further mask their tracks.

A more intricate and effective approach to SaaS security requires understanding the dynamic individual behind the account. SaaS applications are fundamentally platforms for humans to communicate allowing them to exchange and store ideas and information. Abnormal, threatening behaviour is therefore impossible to detect without a nuanced understanding of those unique individuals: where and when do they typically access a SaaS account, which files are they like to access, who do they typically connect with?

Author: Max Heinemeyer, Director of Threat Hunting, Darktrace

See original here:
The anatomy of a SaaS attack: Two threats caught and investigated by AI - TEISS