Hack Exposes 250,000 Microsoft Employee Emails and Support Transcripts Through ServiceNow Vulnerability

TL;DR: A shocking breach exposed over 250,000 Microsoft employee emails and support transcripts due to a vulnerability in their ServiceNow platform. Security researcher Moblig discovered that a single compromised credential bypassed key security measures, granting unauthorized access to sensitive corporate data. This breach highlights the dangers of credential theft, the risks of BYOD policies, and the shortcomings in corporate security protocols. Despite reporting the vulnerability, no bug bounty was awarded, raising questions about how companies handle such critical insights. Want to know how a single login can take down a giant? Read on!


One Login, Massive Breach: How a Single Credential Exposed Microsoft’s Sensitive Data

In a world where we constantly hear about sophisticated cyberattacks, it’s unsettling to realize that sometimes, the breach isn’t due to an elaborate hack—it’s simply a matter of using a valid credential. This was precisely the case in the recent breach of Microsoft’s ServiceNow platform, where a single compromised credential exposed over 250,000 employee emails and sensitive support transcripts. Security researcher Moblig uncovered this vulnerability, shedding light on the critical dangers of credential theft in corporate environments.

For a detailed firsthand account of how this breach occurred, check out Moblig’s blog on Medium.

A Vulnerability Hidden in Plain Sight

When you think of hacking, you might imagine a genius behind multiple screens, typing away at lightning speed to break through firewalls and encryptions. However, in this instance, the breach occurred not through complex code or malware but simply through a valid login. Moblig’s discovery was a sobering reminder that attackers don’t always hack in—they log in.

The vulnerability originated from Microsoft’s ServiceNow platform, a widely-used IT service management (ITSM) tool that handles internal operations such as HR, customer support, and troubleshooting. It also contains sensitive corporate data. Imagine gaining access to all that through a single password—unsettling, right? That’s exactly what happened.


The Role of Infostealers: How Credentials Are Leaked

Infostealers have become a significant weapon in the cybercriminal toolkit, designed to covertly harvest sensitive data from victims, especially login credentials stored on devices and browsers. These tools bypass even encryption mechanisms, extracting usernames, passwords, and session data, which are then sold on dark web marketplaces or used for targeted attacks.

How Infostealers Work

Infostealers infiltrate devices through phishing emails, malicious downloads, or compromised websites. Once inside a system, they scan for and collect:

  • Browser-stored credentials from popular browsers like Chrome, Firefox, and Edge.
  • Autofill data including addresses, phone numbers, and payment details.
  • Session cookies that allow attackers to hijack accounts without needing to log in again.
  • Locally stored password manager vaults, decrypting the contents using methods that bypass basic security measures.

Malware like RedLine Stealer and Raccoon are infamous for collecting large volumes of login credentials. In 2021 alone, RedLine was linked to breaches impacting over 150,000 users, showcasing how effective these tools are at infiltrating even well-protected systems.

BYOD: Amplifying the Threat of Infostealers

Incorporating a Bring Your Own Device (BYOD) policy can significantly increase the risks of infostealers:

  • Lack of centralized security: Personal devices often don’t have enterprise-level security like antivirus or endpoint detection and response (EDR) solutions, making them more susceptible to infection.
  • Unmonitored usage: Employees using personal devices for work tend to visit more diverse websites and install unverified apps, increasing the risk of malware infections.
  • Storing corporate credentials: Many employees save work-related passwords in browsers on their personal devices for convenience, creating easy targets for infostealers.

In the Microsoft breach, the credential that Moblig used likely originated from a compromised personal device where a Microsoft employee had saved their login credentials. This underscores the dangers of mixing corporate access with insecure personal devices.


How ServiceNow’s Security Fell Short

ServiceNow, a popular IT Service Management (ITSM) platform, is designed to streamline internal processes such as employee onboarding, troubleshooting, and handling sensitive data like customer support transcripts. In theory, Single Sign-On (SSO) mechanisms add a critical layer of security to prevent unauthorized access. However, in the case of Microsoft’s breach, SSO wasn’t fully enforced on all access points, leading to a significant vulnerability.

Single Sign-On (SSO): The Intended Safeguard

SSO is intended to consolidate login processes, requiring users to authenticate through a central identity provider like Azure Active Directory before accessing other connected services like ServiceNow. This setup provides:

  • Centralized authentication: Users need only one set of credentials to access various corporate platforms.
  • Stronger security: Since authentication is managed through a unified system, organizations can enforce stronger policies such as multi-factor authentication (MFA) and login monitoring.
  • Seamless user experience: Employees don’t need to juggle multiple passwords across different applications, reducing the risk of password reuse.

In most corporate environments, SSO is crucial to simplifying and securing the login process. However, in this case, Microsoft’s implementation left an open backdoor.

Where Microsoft’s SSO Implementation Failed

Despite having SSO enabled, Moblig found that Microsoft’s ServiceNow instance still had an alternative login page available. This non-SSO portal allowed users to bypass the SSO authentication process, making it possible for anyone with the right credentials—like those extracted by an infostealer—to gain access without the additional protections of MFA or other SSO safeguards.

Technical Oversight: The issue here was that SSO was not fully enforced. The existence of a legacy login page (typically used by third-party contractors or services) bypassed the security controls SSO would normally enforce. Once Moblig used the stolen credentials to access this page, he was logged in without being subjected to further security checks, including MFA.

Exploiting ServiceNow’s API: Unintended Data Access

Once inside, Moblig leveraged ServiceNow’s REST API, which is often used to automate tasks and manage workflows. API endpoints can be powerful tools for managing large datasets, but without proper security controls, they can also be exploited.

Here’s how Moblig accessed sensitive data:

  • /api/now/table/sys_user: This endpoint gave access to Microsoft’s employee database, where he could query and retrieve user details. Using the parameters sysparm_limit=9999 and sysparm_offset=20000, he bypassed limits on the number of results returned by the API, enabling access to a vast pool of employee records.
  • /api/now/v1/attachment: This endpoint provided access to support ticket attachments, which contained sensitive data such as live chat transcripts, troubleshooting requests, and onboarding processes.

These endpoints should have been restricted to higher-privileged accounts, but the combination of a leaked credential and insufficient API security resulted in access to over 250,000 emails and internal documents.

Microsoft’s ServiceNow breach shows how small oversights, like leaving a non-SSO login page accessible, can lead to massive vulnerabilities. Enforcing SSO consistently across all endpoints and ensuring API access is restricted are vital steps to safeguarding sensitive data. With proper enforcement, this breach could have been prevented, demonstrating the importance of not only deploying but also auditing and maintaining security measures regularly.



A Treasure Trove of Data: What Was Exposed?

When Moblig gained unauthorized access to Microsoft’s ServiceNow platform, the data he uncovered was vast and sensitive, exposing major gaps in how the platform’s Application Programming Interface (API) access was secured. By leveraging ServiceNow’s REST API, Moblig exploited two critical endpoints, giving him unrestricted access to thousands of records that should have been safeguarded.

The REST API: Two Key Endpoints Exploited

Moblig accessed a wealth of data using the following two key API endpoints:

  • /api/now/table/sys_user?sysparm_limit=9999&sysparm_offset=20000
    This endpoint allowed access to Microsoft’s user database, including detailed employee information. By manipulating the API’s sysparm_limit and sysparm_offset parameters, Moblig was able to bypass the typical record limit restrictions and gain access to nearly 10,000 user records in a single query. This endpoint effectively provided him with information about Microsoft employees, including their roles, emails, and more.
  • /api/now/v1/attachment?sysparm_limit=999
    This second endpoint exposed support ticket attachments. Attachments in support tickets often contain sensitive communications, such as internal email chains, troubleshooting steps, and transcripts from live chat support. These documents typically include personally identifiable information (PII), corporate strategies, and even private conversations between employees and support agents.

What Data Was Exposed?

Moblig’s access to these endpoints uncovered a wide array of data that, if mishandled, could have caused significant damage to Microsoft and its employees. The exposed data included:

  • 250,000+ employee emails: The breach exposed internal communications and email addresses, both personal and work-related. These emails contained critical business details, project discussions, and sensitive correspondence that could be exploited by malicious actors for phishing campaigns or other social engineering attacks.
  • Support ticket attachments: Included in these were:
  • Internal email requests: Emails exchanged between employees requesting access, troubleshooting support, or escalations.
  • Live chat transcripts: Conversations between employees and support agents where sensitive issues, including troubleshooting for company systems, were discussed.
  • Incident reports and troubleshooting sessions: These contained details about employee onboarding, support requests, and technical issues, often involving highly confidential internal workflows.

The Proof of Concept (PoC)

Moblig’s ability to access these endpoints allowed him to collect enough data to create a proof of concept (PoC). A PoC is often used by security researchers to demonstrate the extent of a vulnerability before reporting it. In this case, the PoC file Moblig submitted to Microsoft’s Security Response Center (MSRC) was an 11MB Excel file that included detailed support ticket information and live agent chats, giving tangible proof of the data exposure.

The Broader Impact of the Exposed Data

While the exposure of emails is serious enough, the support ticket transcripts contain even deeper levels of sensitive information. For example:

  • Employee Onboarding: Ticket transcripts included onboarding details for new employees, revealing internal processes and the personal data of new hires.
  • Technical Issues and Resolutions: The discussions surrounding technical issues often revealed specific software or hardware used within Microsoft, providing potential attackers with valuable intel on the company’s infrastructure.
  • Interactions with Live Agents: These interactions could expose confidential information about business workflows or upcoming projects, making Microsoft’s internal processes vulnerable to exploitation.

This breach demonstrates how API endpoints, if left unchecked or improperly secured, can expose far more data than anticipated. A single endpoint’s vulnerability can open the door to a massive amount of sensitive information, potentially compromising an entire organization’s internal operations.


API misconfigurations can lead to significant data breaches, as seen in this incident where Moblig was able to access both user information and support ticket data. This highlights the importance of regularly auditing API access controls and ensuring that even basic endpoints are restricted and monitored for suspicious activity. The level of exposure underscores the need for robust API security, especially in platforms like ServiceNow that manage critical internal workflows.


BYOD: A Breach Waiting to Happen

The BYOD culture is a double-edged sword in the modern corporate world. On the one hand, allowing employees to use their personal devices can increase flexibility and productivity. On the other, it opens up vast security vulnerabilities. In this case, it was likely a personal device, not as rigorously protected as a corporate one, that held the compromised credential.

This vulnerability illustrates the danger of storing corporate passwords on personal devices without ensuring they’re equally well-protected. Even multi-factor authentication (MFA), a typical corporate security measure, may not be enough if an alternative login route like the one Moblig found is available.

The Larger Problem: Ignoring Credential Theft

Credential theft, such as the one seen in this breach, is not new. According to the 2020 Verizon Data Breach Investigation Report, over 80% of hacking-related data breaches involve brute force attacks or the use of lost, stolen, or compromised credentials. Infostealers are playing an increasingly prominent role in these attacks, and without robust security policies in place, many companies remain vulnerable.

As Moblig rightly points out, no one wants to take responsibility for credential theft. The proliferation of credentials, particularly through unauthorized personal devices, creates an environment ripe for breaches. Corporate infrastructures, no matter how secure, are only as strong as their weakest link—which, more often than not, is human error or oversight.


A Flawed Bug Bounty Program?

Another important angle to this story is how companies handle vulnerabilities reported by security researchers. While Moblig reported the breach in good faith, his bug bounty report was met with some frustrating results. Despite uncovering a significant vulnerability, no bounty was awarded. This is due to the strict scope limitations that many companies place on their bug bounty programs.

By limiting the types of vulnerabilities eligible for bounties, companies inadvertently close the door to critical insights. As Moblig suggests, broader scopes would allow for the identification of more impactful vulnerabilities—like the one he discovered in Microsoft’s ServiceNow instance.

New Tools for a New Threat Landscape

While frustrating, not all hope is lost. Tools like WhiteIntel, the platform Moblig’s friend developed, help track credential breaches by scanning the web for exposed data from Infostealers. WhiteIntel works as a specialized search engine, helping security teams and organizations identify leaked credentials early, potentially preventing massive breaches like this one before they occur.

In addition to specialized tools, companies need to enforce stronger credential management policies. Using password managers, encouraging the regular rotation of passwords, and enforcing multi-factor authentication on all platforms—not just some endpoints—are essential measures.


Frequently Asked Questions (FAQs)

What is ServiceNow, and why is it used by companies like Microsoft?

ServiceNow is a cloud-based platform primarily used for IT Service Management (ITSM). It helps companies like Microsoft automate workflows, handle internal requests, and manage services such as customer support, employee onboarding, and troubleshooting. The platform integrates various functions, providing streamlined operations for IT, HR, and customer service departments, making it a popular choice for large organizations.

How did the breach in Microsoft’s ServiceNow platform occur?

The breach occurred when a security researcher, Moblig, used a leaked credential to bypass Single Sign-On (SSO) protections, exploiting a vulnerable alternative login page. Once inside, he accessed critical API endpoints that revealed over 250,000 employee emails and sensitive internal documents, such as support ticket attachments. This exposed sensitive communications that could be misused in phishing attacks or other social engineering methods.

Why was Single Sign-On (SSO) not enough to prevent the breach?

Although Microsoft had SSO enabled for its ServiceNow instance, the security was not fully enforced across all login portals. An alternative login page that bypassed SSO protections was available, allowing attackers to use valid credentials and avoid additional security checks like Multi-Factor Authentication (MFA). This loophole allowed unauthorized access despite having SSO in place.

What are API endpoints, and how were they exploited in the breach?

API endpoints are interfaces that allow software applications to communicate with one another. In the context of this breach, the ServiceNow API endpoints were used to retrieve large sets of internal data, such as employee records and support ticket attachments. These endpoints were not sufficiently secured, allowing Moblig to query them and access sensitive information that should have been restricted to authorized users.

How can companies protect themselves from similar breaches?

Companies can take several measures to avoid breaches like the one at Microsoft, including:

  • Fully enforcing Single Sign-On (SSO) and eliminating alternative login routes that bypass critical security layers.
  • Implementing Multi-Factor Authentication (MFA) on all access points.
  • Auditing API access to ensure that only authorized users can query sensitive data.
  • Regularly updating and patching their security systems to prevent vulnerabilities.
  • Educating employees on security best practices, including using password managers and avoiding storing credentials in easily accessible locations.

Why is credential theft such a significant threat to corporate security?

Credential theft is one of the most common methods of breaching corporate systems. Attackers often use Infostealers—malware designed to harvest login details saved on personal devices and browsers. With these stolen credentials, attackers can log into systems undetected, as was the case in the Microsoft breach. This threat is particularly severe when employees store sensitive work passwords on personal devices without robust security measures in place.

How did Microsoft respond to the ServiceNow breach?

After Moblig reported the vulnerability, Microsoft acted quickly to fix the issue, patching the affected endpoints and closing the loophole in their SSO implementation. However, the breach had already occurred, exposing sensitive internal data. Microsoft’s Security Response Center (MSRC) acknowledged the issue but did not award a bug bounty to the researcher, which raised concerns about how security vulnerabilities are handled in the industry.

Can a breach like this lead to long-term damage for a company?

Yes, a breach of this scale can have significant long-term consequences. Exposed employee emails and sensitive internal documents can be leveraged for phishing campaigns, social engineering attacks, and corporate espionage. Furthermore, breaches damage a company’s reputation, lead to potential legal consequences, and increase the likelihood of future targeted attacks due to exposed vulnerabilities.

What role does Bring Your Own Device (BYOD) play in corporate security risks?

BYOD policies, where employees use personal devices to access corporate systems, can increase security risks if those devices are not properly secured. Personal devices often lack enterprise-level security measures like firewalls, antivirus software, or regular updates. This can lead to credential theft, as was likely the case in the Microsoft breach, where credentials stored on an unprotected device were stolen and used to gain unauthorized access to the ServiceNow platform.

What are the best practices for protecting corporate credentials?

To protect corporate credentials, companies should:

  • Enforce strong password policies: Require complex passwords that are regularly updated.
  • Implement Multi-Factor Authentication (MFA) on all corporate accounts.
  • Use password managers to store credentials securely instead of saving them in browsers.
  • Conduct regular security training for employees to educate them about phishing, credential theft, and best security practices.
  • Monitor and audit access logs to detect suspicious login attempts early.

Concluding Thoughts: Vigilance is the Best Defense

At its core, this breach serves as a powerful reminder that no company, no matter how large or security-conscious, is immune to human error and credential theft. Even with robust security measures like SSO, overlooking small loopholes—like non-enforced login pages—can lead to significant breaches.

The bottom line? Companies must be proactive rather than reactive in their cybersecurity efforts. Employees need better education on security practices, and companies need to invest in tools and protocols that ensure endpoint security for all devices accessing corporate infrastructure.

Microsoft’s ServiceNow breach could have been much worse. But it’s a stark reminder that even small vulnerabilities can lead to massive data leaks. And as Moblig’s story shows, the greatest vulnerabilities often lie in the most unsuspecting places.


Comments

No comments yet. Why don’t you start the discussion?

Leave a Reply