Credential Compromise🔗

The Credential Compromise page enables you to explore all leak data that we have collected based on your configured domains. While we only generate findings for active identities as outlined on IDR Overview, we still collect and retain historical data that we find related to your domains.

Access the Credential Compromise Page🔗

When you access the Credential Compromise page from the Taegis Menu, the table is filtered by Active leak status and Active identity status by default.

Alternatively, select a metric from within the Credential Compromise widget on the Identity Risk Posture Overview. Depending on which metric you click, you will be taken to the Credential Compromise page with the following filtered view:

Sources takes you to the Credential Compromise page filtered by the Active leak status.
Plaintext Passwords takes you to the Credential Compromise page filtered by the password type of Plaintext with an Active leak status.
Hashed Passwords takes you to the Credential Compromise page filtered by the password type of Hashed with an Active leak status.
Emails takes you to the Credential Compromise page filtered by the Active leak status.
Unique Passwords takes you to the Credential Compromise page filtered by the Active leak status.
Admin Emails takes you to the Credential Compromise page filtered by admin accounts with an Active leak status.

Note

Emails and Unique Passwords are overall metrics of the underlying data, thus there are no filters associated to them.

Credential Compromise Metrics🔗

The metrics along the top of the page are the same metrics contained within the Credential Compromise Widget. It is important to note that the metrics displayed are for active leaks.

A leak is considered active in the following scenario:

There is an Active identity within the configured Identity Providers and the last_password_change time of the associated account occurred before the initial leak date.

Note

If there is no matching identity for the leak record, these are considered inactive. These records are often related to old users and accounts that have been deleted and are no longer in use.

Metric Definitions🔗

Sources — The number of active unique leak sources where data for your domains have been observed.
Plaintext Passwords — The number of active leaks where plaintext passwords were identified in the leak data.
Hashed Passwords — The number of active leaks where hashed passwords were found in the leak data.
Emails — The number of active unique email accounts that have been observed in the leak data.
Admin Emails — The number of active accounts identified as an admin that have been observed in the leak data.
Unique Passwords — The number of active unique passwords that have been observed in the leak data.

Explore Leaks🔗

Explore the data by using a combination of filters, which include both information about the linked users as well as the leak records. In addition, there are multiple timestamps related to the records that can be used to sort the data:

Publish Date — When the record was originally found in the datasets
Leaked Date — When the record became publicly available
Breach Date — When the breach occurred, which may not always be available

Note

There may be multiple records for the same user in a leak. This can occur when the data has been identified within a generic leak source (i.e., combolists) or if the user appeared in the dataset multiple times. As a result, it is expected that you may see multiple records for the same user within a leak source.

Leak Statuses🔗

There are two primary statuses associated with leaks on the Credential Compromise page: active and inactive.

Active🔗

Leaks are considered active if there is a matching identity and the last_password_change time of the associated identity occurred before the initial leak date.

Inactive🔗

Leaks are marked as inactive in the following scenarios:

There is no matching identity within the configured Identity Providers that it can be correlated with.
The last_password_chage time occurred after the leak date.
The password on the account has recently changed.
The account has been disabled or deleted.
An associated Finding has been resolved or dismissed.
It has been more than one year since the leak has been published.

View Leak Details🔗

Select the source field to open the leak panel, which displays additional details about the leak and information about the linked identity when available.

Take Actions🔗

If you have identity-related response actions configured, you can execute response actions for any of the linked identities from within the table or leak details.

Select Actions.
Choose which response action you would like to execute.
Follow the prompts.

Note

The Actions button is disabled if there is no matching identity found.

FAQs🔗

How often do you check for leaked credentials?

We check for leaked credentials every 24 hours.

How are account compromise findings generated?

To ensure that these are actionable, we perform a number of processing steps to correlate and validate the data that we are collecting and analyzing.

Verify that an active identity exists within the configured Identity Providers.
Determine when the plaintext password or hash was first leaked based on the available historical data (~six years). This is important because newly published combolists often contain old data from previous breaches.
If it is a plaintext password value, we then compare this to the Microsoft Entra ID global password complexity requirements to weed out invalid values.
Finally, we compare the first_leaked_date of the password to the last_password_change_time for the identity. If the leak first occurred after the last_password_change_time, we generate a finding.

Note

Account compromise findings are generated for active identities only. However, you can still see the raw data on the Credential Compromise page.

How are account compromise finding risk levels determined?

If we have determined that a finding should be generated, we then check the associated account to see whether it has MFA enabled and at what strength. Below are the associated risk levels based on the type of user, type of leak, and MFA configuration.

Account Type	Password Type	No MFA	MFA Enabled	Phishing Resistant MFA Enabled
Admin Account	plaintext	Critical	High	Medium
Admin Account	hash	High	Medium	Low
Non-admin Account	plaintext	High	Medium	Low
Non-admin Account	hash	Medium	Low	Low

Do you collect and store hashes or passwords?

No, we do not store any of the plaintext passwords or hash values. We also do not have the ability to capture these from the Identity Providers. When scanning for and collecting data, we apply a custom hash to the observed values and then categorize the record as either a plaintext or hashed password. This allows us to determine the uniqueness of the passwords as well as calculate metrics without having to retain the underlying password values.

How many domains are monitored for leaked credentials?

You can select any number of domains from those identified by your Entra ID integration.

What data is used in the leaked credential monitoring?

The data set we use goes back six years and includes data from various Dark Web marketplaces (e.g., Russian Marketplace, Genesis market), TOR sites, public and hidden Telegram channels, and stealer log files.

How does VIP monitoring work?

Once you configure a user for VIP monitoring, we monitor the dark web for the user's attributes and company names and domains to identify potential business leaks or mentions within the past year.

Note

VIP Monitoring is not intended to be a replacement for personal identity monitoring solutions. These services often include sensitive PII monitoring and provide notifications when your personal information is found. VIP Monitoring instead focuses on identifying potential business-related leaks, mentions, or campaigns against users that may include targeting personal emails, phone numbers, and social media accounts.