How I Accessed Microsoft’s ServiceNow — Exposing ALL Microsoft Employee emails, Chat Support…

Attackers don’t hack in: They log in with your credentials

To start, let’s discuss what stealer logs are. They are data files harvested by malicious software, commonly known as “Infostealers,” the subsequent data gathered after the attack is referred to as “Stealer Logs.” Infostealers can target different types of data depending on the specific malware deployed. Among the most common stolen data are login credentials saved in the victim’s browser. This data is normally encrypted, but since the malware can access the entire file system, it can also extract the description key.

I created the following flowchart to give you an overview of the Stealer Logs lifecycle:

At this point, you might be wondering how are corporate credentials leaked? Aren’t most, if not all, corporate devices protected by EDRs?
It turns out that numerous employees often access corporate infrastructure through personal devices, which are more susceptible to compromise — therefore exposing the data. It is also common for companies to employ contracting firms that allow employees to work with personal devices.

The source:
Some time ago, a friend of mine introduced me to a product he has been working on called WhiteIntel — WhiteIntel is a specialized search engine designed to detect data breaches caused by information stealer malware.
It enables organizations and security teams to identify leaked credentials from employees as well as customers.

Large corporations like Microsoft often have in-house MDR (Management, Detection, and Response) systems and protocols, but there are also commercial MSSPs like SecureWorks that offer MDR services. Knowing this, I knew that simply searching for exposed credentials from *.microsoft.com would probably not yield a lot of results, and even if it did, these credentials would have been invalidated already or protected by MFA.

Searching for Corporate IT instances

ServiceNow is an IT Service Management platform that streamlines internal operations like customer support, service requests, incident management, and HR processes, and naturally holds sensitive information such as user PII, support logs, ticket attachments, HR documents, and more.
In Microsoft’s case, however, it is used as an internal ITSM, meaning that it is used in internal operations like employee onboarding, service desk requests, troubleshooting, etc.
In most Service Now instances the domain name is *.service-now.com so I used this query in order to search for exposed instances, WhiteIntel also supports filtering, so I filtered out for possible domains that belonged to Microsoft, including microsoft.service-now.com

The result was a single credential.

No way, right?

When I previously navigated to microsoft.service-now.com I was immediately redirected to a Microsoft SSO login page, but as you can see from the image above, there is one crucial detail — /login.do this meant that SSO was enabled but not enforced, the default login page was still available most likely due to third parties accessing Microsoft’s instance.

To my surprise, the credentials worked! I was presented with a blank UI with no navigation options, I tried in different browsers but still presented with the same broken UI. Nevertheless, I knew I was successfully authenticated, so I quickly searched for the ServiceNow REST API spec and landed on the following:
https://docs.servicenow.com/csh?topicname=api-rest.html&version=latest

By using the REST API endpoints I was able to determine that the affected user was not high-privileged, but I was able to access two key endpoints:

through which I was able to access:

As you can see from the sysparam_limit param, just this request returned 9,999 results.

The attachments also included a download link which allowed me to download a file to provide a PoC to the MSRC team, this file which was in xlsx format and 11 MB in size, included transcripts from internal support tickets including employee onboarding, support requests, incidents, and more:

There was no other reason for me to look at other data since I already had enough information to provide a PoC, so I immediately reported it to the MSRC team, the end result? Accepted, resolved, and no bounty.

The bottom line: no one wants to take responsibility for credential theft…
We live in a world of ignored credential proliferation, and we’re paying the price. — InfoSec Institute

On to the broader discussion

By not providing any incentive to researchers and maintaining overly strict scopes, these programs are inadvertently, and in some cases willingly, closing the door to receiving actionable insights with real-world impact.
And it’s not just me…

But not all hope is lost, some programs show exemplary dedication to security and are even creating specific programs to accept leaked credentials:

My response and recommendation to the MSRC:

Disclosure Timeline:

Sep 22, 2024 — Credentials found and reported to the MSRC
Sep 25, 2024 — Case opened for the report by the MSRC
Sep 30, 2024 — MSRC requests detailed information about login dates and IP addresses
Oct 1, 2024 — Additional information was provided
Oct 14, 2024 — An update on the case status was requested to the MSRC
Oct 16, 2024 — MSRC confirms fix has been applied, with no bounty reward.
Oct 22, 2024 — Explicit permission was given from the MSRC to disclose the report.
Oct 24, 2024 — Public disclosure