Investigate and remediate Sophos ITDR Dark Web Intelligence

Dark Web Intelligence shows the leak records Sophos has collected for the configured domains. The aim of this runbook is not to treat every hit as evidence of current account access. First, check the identity, time reference, password type, and leak status. Then respond only through an approved process for the identity that is actually linked.

Active Credential Leaks increase the Risk Score of an identity. Historical records remain visible, however, even if they are inactive. The table therefore serves both as a working view of current risks and as evidence of older discoveries.

Quick flow

1. Open My Products > Identity > Dark Web Intelligence and document the default filters.
2. Prioritise an active record and record Source, linked identity, password type and Publish Date, Leaked Date and Breach Date.
3. Check why the record is Active; do not equate lines with unique accounts or passwords.
4. For an associated Finding, compare the displayed severity with the matrix using account type, password type and MFA strength.
5. Confirm responsibility and approval. Only then execute the appropriate, already authorised response.
6. Remediate the credentials in the responsible Identity Provider through the approved process. Do not use Finding or leak status as a substitute for that remediation.
7. After at least one 15-minute cycle, re-examine status, Finding and Risk Score and document the evidence.

Views and default filters

Direct entry

My Products > Identity > Dark Web Intelligence

When opening this page directly, the table is filtered to leak status Active and identity status Active. Before examining, save a screenshot or note of the active filters. An empty default view does not prove that there is no historical leak data; for this check, deliberately broaden the status filters.

Entry via Identity Overview

Identity Overview > Credential Leaks

Clicking a metric in the Credential Leaks widget opens Dark Web Intelligence with a view that matches the metric:

Breached Email Accounts and Unique Passwords Breached are the aggregate metrics of the underlying data. There is no additional table filter that fully maps their unique counting method. Therefore, the metric cannot be reconstructed exactly from the table rows visible after the click.

Interpret metrics correctly

The metrics above Dark Web Intelligence refer to active leaks:

These values use different units: sources, leak records, accounts and unique passwords. They may not be added or validated simply by counting table rows.

Investigate a leak record

1. Define the scope

First, note the filters and sorting. For the first triage, at least these characteristics are relevant:

• Leak status Active or Inactive
• Identity status and linked identity
• Plaintext or Hashed
• Admin, non-admin or VIP context, if indicated
• Source
• Publish Date, Leaked Date and Breach Date
• associated Finding, if present

Do not prioritise solely by the latest timestamp in the table. A record with a new Publish Date may contain older content, especially in combolists.

2. Open details

Click on the field Source. The detail panel shows additional information about the leak and, if available, the linked identity. Before responding, the table row and detail panel must refer to the same source and identity.

If no identity is assigned, the record remains relevant for the historical investigation, but is considered inactive. Actions is disabled in this case. Do not assign an identity based on a guess, and do not act against a similarly named account.

3. Distinguish the date fields

Publish Date

The time when Sophos first found the leak record in the data it analysed. It is neither the time when the data became public nor necessarily the time of the incident.

Leaked Date

The date when the data set became publicly available. This date is compared with the last password change to assess whether the credential risk is current.

Breach Date

The time when the underlying breach occurred. It provides incident context, but may be unavailable.

A missing Breach Date does not make Leaked Date the confirmed breach time. Similarly, a new Publish Date does not prove that the password was compromised recently. For the status logic, it is crucial whether the last password change is before or after the relevant first-leak time.

4. Classify duplicates and combolists

The same person may appear in multiple rows from one source. Common reasons include:

• the person appears several times in the original data set;
• the same content was recognised in a generic source such as a combolist;
• older leak data reappears in a collection discovered later.

Multiple rows therefore do not automatically indicate multiple compromised accounts or multiple current password compromises. Compare the source, date, password type, and linked identity for each row. The Emails and Unique Passwords metrics apply deduplication logic; table rows are not deduplicated in the same way.

When a leak is Active or Inactive

A leak is Active if both conditions are met:

1. The record can be linked to an active identity in a configured Identity Provider.
2. The last password change of the associated account is before the first leak time.

Active therefore denotes a credential risk that is still relevant. The status alone does not prove a successful sign-in by a third party or an ongoing attack.

A leak is Inactive if at least one of the documented scenarios applies:

• There is no matching identity in the configured Identity Providers.
• The most recent password change is after the leak time.
• The password of the account has been changed recently.
• The account has been deactivated or deleted.
• A related Finding was Resolved or Dismissed.

Historical data for monitored domains continue to be collected and retained. An inactive record is therefore neither erroneous nor irrelevant merely because of its age. It can explain why the same person or source appears multiple times.

When a Finding is created

Sophos describes this processing for account-compromise Findings:

1. Sophos checks whether an active identity exists in the configured Identity Providers.
2. Sophos determines from available historical data when the plaintext value or hash was leaked for the first time. This is intended to recognise old content in new combolists.
3. For a plaintext value, Sophos compares it with the global Microsoft Entra ID password-complexity requirements to exclude invalid values.
4. Sophos compares the first leak time of the password with the last password change. If the first leak is after that, Sophos creates a Finding.

Findings are created only for active identities. The raw data remains visible on Dark Web Intelligence even if no active identity is linked.

Severity matrix for account compromise

According to Sophos, the Finding severity depends on the account type, password type and MFA strength:

The matrix helps prioritise work but does not replace a case-by-case assessment. For admin accounts in particular, confirm the actual account association before responding. A lower severity does not mean that remediation is unnecessary.

Handling password values

Sophos states that it stores neither plaintext passwords nor hash values and cannot collect these values from Identity Providers. During collection, Sophos applies its own hash to observed values and then categorises the record as Plaintext or Hashed. According to Sophos, this method identifies unique values and derived metrics without retaining the underlying password value.

Operationally, this means:

• Plaintext describes the type of leak content observed, not a password available in Sophos Fusion (formerly Sophos Central).
• Do not try to recover the original value from Sophos Fusion, screenshots or exports.
• Do not copy suspected passwords, hash values, or new credentials into tickets, notes, or chat messages.
• Set a new password only through the Identity Provider’s approved process and handle it in the designated password system.

Authorised response and remediation

Decide before taking any action

Before Actions all the following points must be fulfilled:

• The linked identity is clearly confirmed by the detail panel.
• The account owner, account type and business function are known.
• The current leak status, password type and three date fields have been checked.
• Response Action authorisation is in place for the tenant.
• The person performing the action is authorised for the specific identity and expected impact.
• The responsible service or system manager is involved in privileged or shared accounts.

If one of these conditions is missing, no action is triggered. The record is passed to the person responsible in the Identity or Security team with the timestamp, filter state, and details of the missing approval.

Respond in Dark Web Intelligence

If Response Actions are authorised, they are available for linked identities in the table or in the leak detail:

1. Open the correct row or the detail panel of the confirmed identity.
2. Select Actions.
3. Select only the already approved Response Action.
4. Review and follow all on-screen instructions and confirmations.
5. Document action, operator, timing, target identity and visible result, but do not capture credentials.

Only the Response Actions offered in the tenant and authorised by the organisation may be used. If no suitable identity exists, Actions will remain disabled; this must not be circumvented.

Remediate the credential risk

Technical remediation takes place via the Identity Provider responsible for the account and the approved credential process:

1. Check last password change and account status of the confirmed identity against the leak time.
2. If it is not possible to exclude that the login data observed in the leak is still valid, initiate or perform an authorised password change for exactly this account.
3. If an account is disabled or deleted, confirm the provider status instead of reactivating the account for remediation.
4. If the record is not linked to an identity, treat it as a historical, inactive leak and do not guess the account identity.
5. Process an associated Finding through the prescribed Findings workflow only after the actual credential remediation has been documented. Use Dismissed only after a technically justified, documented decision, not to shorten the queue.

Do not infer the need for additional account, session, MFA, or directory changes from the leak record. Such measures require a separately confirmed reason and the applicable approval.

15-minute cadence and validation

Sophos checks Dark Web Intelligence every 15 minutes. Sophos monitors and collects leak results continuously; if an active leak is detected, a Finding is generally generated within 15 minutes. “Generally” is not a guaranteed maximum time.

After remediation, do not immediately record a final success. Instead:

1. Record the completion time of the password change or the confirmed account change with time zone.
2. Wait at least for a complete 15-minute cycle. Consider that the ingestion of updated Identity Provider data by Sophos may require additional time.
3. Reopen My Products > Identity > Dark Web Intelligence.
4. Search for the same identity and source with the same filters.
5. Check whether the leak has changed from Active to Inactive and whether the displayed identity status is correct.
6. Check the associated Finding separately. The absence of a new Finding is not sufficient evidence if the leak is still Active.
7. Monitor the Risk Score of the identity as a follow-up signal. It is not the primary proof of the password change.
8. Document the baseline, action, completion time, validation time, and final status.

Acceptance criteria

The response is complete only when:

• identity and leak source are clearly documented;
• password type and date fields have been evaluated;
• credential remediation has been confirmed in the responsible Identity Provider, or the account is demonstrably disabled or deleted;
• the remediated leak record is no longer Active after processing;
• the associated Finding has been handled through a controlled process;
• no secret values are in the documentation.

If the record remains Active after several 15-minute cycles, first recheck the actual last password change, account status, and linked identity. If these details are correct and the status still cannot be explained, capture the filter state, source, all three date fields, identity reference, Finding reference, and timestamp. Then escalate to Sophos Support. Do not make further account changes based on assumptions.

Triage record

Tenant / environment:
Validation time with time zone:
Path and active filters:
Source:
Linked identity:
Identity status:
Account type: Admin / Non-Admin / unclear
VIP monitoring: yes / no / unclear
Password type: Plaintext / Hashed
Leak status before action:
Publish Date:
Leaked Date:
Breach Date: Value / not available
Multiple lines or combolist context:
Finding reference and severity:
Last password change according to Identity Provider:
Response approval:
Authorised action performed:
Completion time with time zone:
Validation after 15-minute cycle:
Leak status after the measure:
Finding status after the action:
Risk Score as a follow-up signal:
Open deviation / escalation:

Avoid common mistakes

• Count each table row as a separate account: Duplicates and combolists can create multiple lines for the same person.
• Read Publish Date as Breach Date: The three date fields describe different events; Breach Date may be missing.
• Interpret Inactive as deleted: Historical data are retained and may remain visible.
• Treat no rows in the default filter as an all-clear: Direct entry shows only active leaks of active identities by default.
• Close a Finding manually instead of remediating: A status change does not change any login data in the Identity Provider.
• Attempt to force Actions without a linked identity: Without a matching identity, the button is intentionally disabled.
• Confuse Plaintext with a retrievable password: Sophos says that neither plaintext values nor hash values are stored.
• Expect an immediate update: The check runs in a 15-minute cycle; upstream identity data may require additional processing time.