What we can learn from the recent ServiceNow/Microsoft disclosure

We’ve been shouting about the risk posed by account takeover attacks on third party apps since we first released the SaaS attack matrix in early 2023. 18 months later (and with some encouragement from the success of the attacks on Snowflake customers) it feels like the security community has woken up to the risk — and attackers likewise have sensed the opportunity. 

Last week, it emerged that bug bounty hunters were able to use stolen credentials from a TI platform to Microsoft’s ServiceNow tenant, accessing 1,000s of support ticket descriptions and attachments, and 250k+ employee emails. 

But this isn’t specifically a Microsoft problem. The researcher could have picked from a long list of potential targets. If even Microsoft with their vast security resources can be caught off guard by this, what chance do other organizations have? If anything, it illustrates the scale of the challenge facing organizations when it comes to securing their identity surface. 

Let’s take a closer look at what we can learn from this attack — and what it tells us about the direction that identity attacks are (rapidly) heading in. 

Taking over ServiceNow accounts through credential stuffing (via infostealers)

A bug bounty hunter was able to compromise Microsoft’s ServiceNow account using stolen credentials from historical infostealer infections, found using a commercial TI feed. 

The researcher was able to enumerate a login page for Microsoft at microsoft.servicenow.com/login.do, with the /login.do meaning that SSO was enabled but not enforced. At this point, the attacker was able to authenticate using the stolen credentials only (as the target account lacked MFA).

After logging in they were presented with a blank UI. However, because they now had an authenticated session, they were able to switch to the REST API, and subsequently access two key endpoints through which they were able to collect and exfiltrate sensitive data including 1,000s of support ticket attachments, over 250,000+ employee emails, and an xlsx file with historical ticket submissions to the MSRC team. 

Naturally, at this point the researcher ended their attack and sought out a bounty for their efforts. 

But a real attacker wouldn’t have stopped there. Immediately, you’d be thinking:

• How many other organizations are likely impacted by this issue? Are there other credentials that correspond with these exposed login pages available online? 

• Are there any ways that I could turn this access into a privileged account takeover? Would I be able to access even more information that way? 

• How could this data be used to conduct further attacks? Would other criminal groups pay me for this information if I don’t want to do this myself? 

This isn’t just a Microsoft problem

It seems unlikely that only Microsoft is affected here. Other ServiceNow tenants could have been taken over using the same approach. Other company credentials could be (will be) available online.

Using straightforward tenant enumeration techniques and the list of ServiceNow named customers, it’s very easy to identify different customer tenants. And spending a few minutes using the same credential feed as the researcher, I found multiple organizations with many more breached credentials available linked to the same login.do page. 

Similarities with Snowflake

There are no prizes for connecting this attack path with the infamous attacks on Snowflake customers earlier this year, which resulted in 165+ victims, and hundreds of millions of breached customer records. 

The Snowflake attack path was startlingly similar, and gives us a feel for what this attack could have turned into if conducted by a real attacker. 

Both attacks began with stolen credentials breached in historical infostealer infections. In Snowflake’s case, 80% of the credentials used were connected to infostealer infections dating back to 2020, according to Mandiant. 

Ghost logins strike again

Ghost logins are one of the leading factors in successful credential stuffing attacks. Simply put, ghost logins are often-forgotten local logins that are tricky for security teams to manage and secure.  

Ghost logins are a problem for security teams because they often lack best practice security configurations, with things like weak, previously breached, and reused passwords — and no MFA. 

Many organizations think that by migrating an app to use SSO, where they’ve enforced MFA at the IdP level, it’s job done. However, this usually doesn’t eliminate previously created local accounts, meaning they need to be manually unset. But because organizations often lack app-level visibility of account configuration and login methods (it’s simply not provided by most app vendors) these accounts can fly under the radar for extended periods — often until situations like this when they are compromised. 

Ghost logins were a particular problem in the Snowflake attacks because MFA could not be globally enforced at the time of the incident. This meant that local accounts would need to be manually unset using the SQL interface — which unhelpfully provided inaccurate information about the account status and took extended periods of time to update after a change had been made, creating uncertainty and confusion for responders. But this is just one example of many illustrating how difficult in-app identity management can be. 

So what?

If we hadn’t realized it yet, attacks targeting third-party business apps are everywhere. It’s not just the flavor of the month — it’s here to stay. 

This is because it’s so easy for attackers to monetize these compromises. Log into app > dump data > profit. 

And the easiest way to achieve this isn’t through complex software exploits, it’s through identity attacks. In the ServiceNow case, using public information (that was available to the security team too) to log into an app. It’s too easy.

Identity attacks are misunderstood

The researcher notes that, despite the severity of the bug, it wasn’t paid out under the MSRC bug bounty scheme. And while this is perhaps not a classic software exploit, you can’t argue about the risk it poses. This is just as impactful as any classic vulnerability, if not more so — because the technical barrier to entry is so much lower. 

Pat Gray of the Risky Biz podcast said of another recent disclosure, where a 15 year-old researcher was able to turn a Zendesk ‘feature’ into hijacking Apple SSO to log into downstream SaaS, that there’s a lack of imagination in understanding how these third-party apps can be abused by an attacker. I’d tend to agree here.

Part of the challenge here is perhaps a lack of awareness of just how severe these issues are. Certainly in the Zendesk case, the initial disclosure (email spoofing) was thrown out, but when it was demonstrated that it could be used to take over downstream apps like Slack, affected companies were happy to pay up, and Zendesk (via HackerOne) got back in touch. 

If I were the researcher, I would have considered reporting this issue to ServiceNow too, not just Microsoft — as it undoubtedly affects many organizations. Yes, the fact that Microsoft credentials were accessible online is a Microsoft problem, but given the potential spread of organizations also susceptible to this attack, does the vendor not have a responsibility to help mitigate these attacks? I would hope that ServiceNow have contacted their customers to be cautious of experiencing an increase in credential stuffing attacks in the near future at the very least.

There’s clearly a need for better security-by-default from SaaS vendors — things like mandatory MFA enforcement would be a good start. Because there are simply too many apps, and too many accounts to manage — and no effective centralized way of managing them across your SaaS inventory. 

It makes you wonder how many other apps are impacted by ‘on by default’ configurations that can be abused in ways we just don’t know about yet. Partly because nobody is really looking — bug bounties aren’t being paid out, and I know of only a handful of forward-thinking security consultancies conducting any real offensive security testing with their clients in this space. 

We are also reminded, again and again, that credential stuffing attacks are as effective as ever. Despite the investment in SSO, MFA, and all of the identity management and hygiene tools that organizations have nowadays, attackers and researchers keep finding gaps.  

What can you do about it? 

The most important step is to acknowledge the severity of the threat — and the ways that expected controls are failing.

• There will almost always be gaps in any organization’s identity security perimeter, simply because it’s almost impossible to have the required visibility — even if you’re Microsoft with your vast security resources.

• There will always be ways to abuse app features and configurations, and we’ve barely begun to scratch the surface of what’s now possible in the world of connected SaaS.

• These attacks are very difficult to intercept once an attacker is active inside an app, because there’s very little meaningful visibility. 

• Once they’re inside, the attack can be over incredibly quickly, and can be repeated across app tenants for maximum impact (again, just look at Snowflake). 

At Push, we’re focused primarily on detecting and intercepting account takeover for these reasons — it’s your earliest opportunity, and for many attacks it’s also your last. If you want to learn more, check out our recent design philosophy blog discussing why we’re shifting detection left to focus on account takeover.