TechnologyOne Breach Highlights the Need for SaaS Security

Last week, TechnologyOne announced a trading halt while the company investigated activity concerning its Microsoft 365 systems that were illegally accessed by unauthorized third parties. While a subsequent investigation reported that the affected system was successfully isolated and not connected to TechnologyOne’s customer-facing SaaS service, the backend M365 systems were compromised.

This is a pattern we have been observing in many breaches over the past few years. A “third party” has been identified as the source of a breach event. And while these “third parties” are not always named, they are often SaaS providers or connections between SaaS platforms. The breach may be downplayed because it did not affect a customer-facing system, but it should be noted that the “back-end” of a corporate-wide operational SaaS platform was compromised.

It brings to mind recent musings around security circles: It’s typically not a matter of if, but when, an organization will be breached. Cybersecurity professionals are constantly scrambling to cover the latest attack techniques and improve security posture of infrastructure and systems.

While we may never know the true nature, detail, and extent of this breach, we are reminded that we should always endeavor to place sufficient security controls in place to protect sensitive business operations. In this instance, it was only a “back-office system.” But a different system breach would, without a doubt, have impacted business operations, taken away huge amounts of resources to focus on the incident, and caused investor concern due to the trading halt.

Who knows what may have happened had the findings been negative. Consider in October 2022 when Medibank first confirmed its breach. The share price plummeted by about 20% shedding, or $1.8B in value in the days following.

How Confident Are You in the Security Posture of Your SaaS Platforms?

If your SaaS platform hosts sensitive and critical data, how much do you trust your internal change control processes that are orchestrated by humans and fallible to errors? How much do you trust your third-party suppliers and applications that hook into these SaaS platforms?

Security practitioners today lack true visibility into the security posture of SaaS applications. The process for onboarding a SaaS vendor into an organization usually includes a supplier risk assessment, review of the provider’s audit, perhaps an interview, and then, upon approval, the application is handed over to the business or application owner. Security teams, in most cases, never have a chance to see how the application is actually configured, what third party is plugged into it, and how controls and permission scopes are defined.

Are Your Most Likely Attack Vectors Protected?

At AppOmni, we specialize in securing your SaaS applications through systematic, programmatic detection of threats and risks to those platforms. It’s essential to inspect static configuration settings as well as monitor activity and threats. (In my opinion, it’s better to focus on the prevention of incidents proactively rather than the reaction to them.) In many cases, SaaS events lack proper attribution to be useful, and they may not be real-time. This means your reactions and investigations will be even further delayed.

Below are three common scenarios threat actors may use to compromise your SaaS platform that I’d like to elaborate on.

Compromised Supplier Credentials

We have all heard about employees who are subject to MFA bombing attacks and become, unsurprisingly, subject to MFA fatigue. But MFA bombing isn’t the only method for compromising user credentials. Phishing and spear phishing attacks are also successful tactics. And cyber criminals can even harvest compromised and re-used credentials from the dark web.

Unfortunately, the larger the company and employee base, the greater the chances this scenario might happen. Hence why it’s important to detect anomalous user behavior occurring on your SaaS platforms and connected SaaS apps. AppOmni includes the capability to use pre-built threat detection rules that look for suspicious activity such as:

• Activity performed from a terminated user
• Credential stuffing attempts
• Logins from risky IP addresses
• Mass login failures followed by success
• Password spraying attempts

For expanded detection, one may define custom detection flows to cater for multiple individual events that, when combined into a sequence, reveal a much higher probability of adversarial behavior: 

With AppOmni, every alert generated is normalized and can be sent downstream to your SOC’s SIEM platform of choice. Your staff can review and act on potential threats in the system they’re already trained on for incident response processes and workflows.

Compromised and Stolen OAuth Tokens

Third-party applications often use OAuth tokens to integrate into your SaaS platforms. The tokens are bequeathed by the user to the new application so it can access data on the SaaS platform on behalf of the user without requiring that user’s credentials.

Unfortunately, threat actors can use multiple available methods to steal these OAuth tokens:

• Open redirects on a vulnerable website to steal those tokens
• Man-in-the-middle (MITM) based proxies to glean a victim’s OAuth token via SSL stripping
• Client-side browser-based attacks
• Spear phishing the victim to expose OAuth tokens via malicious DNS spoofed links
• Exploit XSS weaknesses in websites to inject malicious code into a victim browser to intercept the token

The list continues to grow.

AppOmni can detect and regularly alert you of OAuth token grants that request highly sensitive scopes. For example, here’s how we can alert security teams when a SaaS-to-SaaS app is granted administrative user level privilege upon install:

AppOmni also includes and maintains a list of automated findings that continually assess your environment for incidents such as compromised tokens. Indeed, when Github was accessed by threat actors using compromised OAuth tokens for their third party apps Travis-CI and Heroku, AppOmni acted within ~2 hours to publish detections for those compromised token IDs. Any of our customers who had those matching token IDs were immediately notified with a recommendation to revoke and rotate those tokens.

Here is another example highlighting a different provider’s compromised OAuth tokens:

Unsanctioned or Malicious SaaS-to-SaaS Apps

Alternatively, you can take this one step further and AppOmni will notify you when any third-party application (sometimes called a “SaaS-to-SaaS” app) that isn’t part of your approved list connects to your SaaS platforms. This is an example of such a rule:

Final Thoughts on Preventing These Breach Attempts

I can imagine that there will likely be some vigilant cybersecurity professionals who will, no doubt, immediately think of initiating pentests and independent security audits on their SaaS estate in the wake of last week’s incident. Lately, and in Australia particularly, there have been no shortage of cybersecurity incidents on an almost continuous basis.

You could accept risk on a best-efforts, pentest, and one-time audit basis. But why not consider machine-based, continuous monitoring and detection SaaS security platforms like AppOmni? We make the task easier by automating the scanning of risk all day, every day. And we update our platform with analytic detection rules whenever new threats surface. AppOmni acts, in essence, like your own SaaS security expert. See for yourself — schedule a demo today.

Related Resources