Use the Sophos XDR Threat Intelligence Explorer

The Threat Intelligence Explorer makes Sophos Counter Threat Unit (CTU) threat intelligence searchable in Sophos Fusion (formerly Sophos Central). You can research malware families, analyses and known threat groups, and compare the described context with Detections from your own environment. An entry in this knowledge base is not yet a match in your tenant or a confirmed compromise.

The short workflow: open Security Operations > Threat Intelligence, research through Malware, Threat Report or Threat Group, read the available details and distinguish Related Detections from Related Detectors. Only your own events show whether the researched connection matters to a specific Case.

Prerequisites and boundaries

The Explorer requires an XDR or Enterprise licence. This workflow describes the Security Operations view. Threat Analysis Center remains available as the Classic view, so existing investigation and Case runbooks may still show that menu path. Do not mix the labels from the two views.

The CTU updates its intelligence through incident-response investigations, global threat monitoring, technical malware and campaign analyses, and collaboration with partners and authorities. This information describes the threat landscape; Detections and events in the tenant describe your own observed activity. An investigation needs both layers.

Three terms matter here:

An Indicator of Compromise (IOC) is, for example, an indication of a possible compromise mentioned in an analysis. Assess its significance alongside the time, provenance and observed behaviour.
A Detector is detection logic that creates a Detection from unusual or suspicious events. A related Detector is not the same as an existing match.
Tactics, Techniques and Procedures (TTPs) describe an attacker’s methods. Similar TTPs or the same malware do not prove that a particular group attacked your tenant.

Here, the Explorer is an entry point for research and investigation. Reading about or filtering a malware family does not configure a firewall threat feed, blocking rule or response action.

Search before narrowing the results

The search bar at the top right searches Malware, Threat Reports and Threat Groups. A term from a Detection or report, such as Emotet, is a useful starting point. This is only a search example; use the name you actually need to investigate.

Open one of the three views under Security Operations > Threat Intelligence and enter the search term.
Select a specific result to view its details. To compare the result list first, select View in table or See all. The corresponding table is filtered to the search results.
Add further filters only afterwards. This makes it easier to see whether a narrow filter excluded useful results.
To start a new line of research, click the X on the right of the search field. It clears the search and also resets table filters. Record important search terms and filters in the investigation log first.

Multiple filters are useful when they answer a specific question. A known malware name plus a CVE is a different investigation from a search for recent ransomware reports about an industry. Too many criteria at the outset make an empty list difficult to interpret.

Investigate a malware family

Malware contains technical analyses, IOCs and links to threat actors. By default, the table sorts first by the CTU’s Threat Priority for important or current threats, then by the latest update. This order prioritises intelligence; it is not the Severity of one of your Detections.

The documented filters serve different purposes:

Malware searches by family name, such as Emotet or TrickBot.
Type narrows the classification, such as Trojan, Ransomware or Backdoor.
Threat Group searches for malware linked to a particular group, such as GOLD MYSTIC or BRONZE BUTLER.
CVE searches for malware that exploits a particular vulnerability. For example, use CVE-2021-44228 when that specific vulnerability is the subject of the investigation. The filter does not replace checking whether your systems are actually affected.

Click the family name to open the side panel. First read Malware family overview for the description and classification, then Technical details for behaviour, capabilities and indicators. Solution and mitigation contains recommended protective measures. Check recommendations against your platform and existing protection rather than implementing them solely because of a search result.

Where available, related intelligence appears in separate tabs:

Threat Group lists groups that use this malware.
Threat Report links to related CTU reports.
Related Detections shows Detection data from your environment.
Related Detectors shows Sophos XDR Detectors that detect this malware.

Use the New Tab icon to open the details in a new tab. From there, copy the URL as a precise reference in the investigation log. This is more useful than the family name alone when several analysts need to review the same entry.

Choose a Threat Report for the specific question

Threat Report contains CTU publications such as daily briefings, in-depth analyses and advisories. For a specific Detection, start by searching for malware, a group or a CVE; for a regular situational overview, use the subject and publication type.

The filters distinguish content from publication format:

Threat Report searches by report name, such as Daily Threat Brief or Ransomware Analysis.
Report Type is the broad publication category, such as Advisory, Analysis or Brief.
Category specifies a more detailed type, such as Customer Advisory, Threat Analysis or CTU TIPS.
Threat Type narrows the threats discussed, such as Ransomware, APT or Cybercrime.
Threat Actor Type distinguishes actor types such as Nation-state, Cybercriminal or Hacktivist.
Target Geography searches for a geographical focus, such as Europe or Global.
Target Sectors narrows the industries discussed, such as Financial, Healthcare or Government.
Threat Group, Malware and CVE search for the groups, malware families and vulnerabilities covered in the report.

Target Geography and Target Sectors help prioritise research, but are not reasons to rule out your own risk. Opportunistic attacks can affect any region or industry, even without a specific targeting preference. Do not restrict a situational overview exclusively to your own industry.

Click the report name and read the detail panel. Depending on the report, Full report text, Executive summary, Technical details and Indicators of compromise may be available. Not every publication contains all these areas. Indicators of compromise may contain associated IOCs and signatures. The summary provides orientation; the specific technical information and its limitations matter for the investigation.

Where present, Related Detections shows your own Detections and Related Detectors shows XDR Detectors mentioned in the report. Here too, available detection logic and an observed tenant match are two different findings. Open the full report through New Tab and copy its URL for the Case if needed.

Treat a Threat Group as a working hypothesis

Threat Group describes known threat groups and their TTPs. Use this view when a report names a group, you need to resolve a known alias, or you want to assess your defences against particular methods.

The filters cover identity, intent and methods:

Threat Group searches by group name, such as GOLD MYSTIC or BRONZE ATLAS.
Thematic Area narrows the thematic or regional context, such as Cybercrime, China or Russia.
Aliases searches alternative names such as APT1, Lazarus Group or FIN7.
Status distinguishes the current activity status, such as Active and Inactive.
Motivation describes motives such as Financial, Political or Military.
Objectives describes goals such as Financial Gain, Espionage or Disruption.
Target Geography and Target Sectors search geographical and industry targeting patterns respectively.
Malware searches related families; Tools searches tools and techniques used, such as PowerShell, Mimikatz or PsExec.

Groups without a specific targeting preference can also affect your region or industry. An empty list after applying a sector filter is therefore not an all-clear.

After clicking the group name, the detail panel contains Group description with background and assessed capabilities, Attribution assessment with geographical or organisational attribution, Activity timeline with campaigns and operations, and analysis of Tactics, Techniques, and Procedures. New Tab opens the details so you can copy a direct reference.

The Attribution assessment remains the CTU’s assessment. It neither proves who caused your incident nor establishes that every use of the same malware belongs to that group. In the Case, record wording such as “Behaviour matches the described techniques”, and document separately which of your events support it. Definitive actor attribution requires more evidence than a matching name, tool or malware family.

From an intelligence entry to a Detection and Case

Threat intelligence automatically enriches Detections with relevant context; several XDR Detectors use it for detection. This does not promise that every described technique is detected in every tenant. The investigation therefore returns from context to actual events.

Cross-check your own Detections

If Related Detections contains matches, open a relevant one and use New Tab to view the full Detection details. Alternatively, search under Security Operations > Detections. The default time range there is 72 hours; adjust it for an older incident. Check filters and Include Options so that custom or already triaged Detections are not unintentionally excluded.

In the Detection, check the following:

On Summary, read Affected Entities, the triggering Detector, available time information, Severity and Confidence. First and Last Activity describe event times; Inserted At is the time of recording.
On Events, open the events that led to the Detection. On JSON, inspect the underlying Detection data if needed. The summary is not a substitute for this evidence.
On Insights, review related open and closed Detections and Cases. Existing Cases can avoid duplicate work; closed Cases provide historical investigation context.
For further intelligence, click the shield icon in Affected Entities, or select an entity with that icon on Entities. This also lets you pivot from a Detection back to intelligence.

For deeper investigation of endpoint processes and graphs, use the Detections and Threat Graphs runbook. It also covers the Classic view. The absence of your own Detections in an intelligence entry proves neither a clean tenant nor complete telemetry. If further queries are needed, the Data Collection and Live Discover runbook explains the data foundation and Classic query workflow.

Add relevant evidence to a Case

Before adding anything, check whether a Case already exists for the same investigation and whether it is editable. Cases with a Closed status are read-only except for Status and Archive; archived Cases permit only Unarchive. Initially use these Cases as historical context, not as automatically editable destinations for new evidence, comments or reassignment. For MDR Cases, available actions and Assignee options also depend on who manages the Case. Check the actions actually available before making a change and clarify missing options with the responsible analyst.

Distinguish the table action from full Detection details for the handoff. Official guides do not consistently use the same labels for the detail view, so no universal menu path for every view is reliably established here:

Selected rows in the Detections table: Select the required Detections and open Actions > Add to Case.
Full Detection details: The details guide lists the direct actions Add to Existing Case and Create New Case under Actions. The Case guide instead describes Actions > Add to Case, followed by Existing Case or New Case, for individual Detections. Use the action actually displayed for an existing or new Case; do not search for a label absent from that view.

If the Add to Case dialog appears, use these steps:

For an existing Case, select Existing Case, find and select the Case, then save with Save to Existing Case.
For a new Case, select New Case and set Case Type, an optional template, title, Case Severity and Case Status. Use the pencil icon beside Key Findings to add initial findings and context, then select Create New Case.

With multiple selections, check whether you are adding only the selected Detections or all Detections from the table. Do not add an entire result list without checking. Evidence can take a few minutes to appear in the Case; afterwards, open the destination Case and verify the actual assignment.

For MDR customers, the Case types Investigation and Other additionally require Managed By. This selection determines who manages the Case and cannot be changed once set. Confirm it against the intended responsibility before saving. Changing Assignee later does not change Managed By.

In an editable Case, record the copied intelligence URL and the specific statements used as investigation context, for example in Key Findings or, if available, as a comment on the full Case detail page through Comments > Comment > Save. Name research and tenant evidence separately: what does the report say, what do your events show, and what remains a hypothesis? The URL alone does not preserve the content of an analysis that may later be updated, so include the relevant statement and time in the note.

The existing Case and Detection Rule guide describes the Classic workflow. For Security Operations, follow the label variants explained above and the actions displayed in your tenant. The Explorer replaces neither a responsible analyst nor decisions about containment or remediation.

Example: investigate a malware indication traceably

Suppose one of your Detections names a malware family you do not yet know well enough. This example does not claim an existing match:

Search for the actual family name; Emotet is only an example. Do not immediately add an industry or group filter.
Read the description, technical details and protection recommendations. Under Threat Report, review an available report about the observed behaviour.
Look for your own matches under Related Detections. Compare each relevant match against the device or entity, event time and specific events. Under Related Detectors, establish which detection logic belongs to the context.
If a group is named, compare its TTPs and activity timeline. Retain attribution as an assessment even if individual characteristics match.
Assign relevant Detections to an existing or new Case. Record the intelligence entry investigated, research time, search terms and filters, references to your Detections, evidenced similarities, open questions and next analyst.

A useful outcome may also be that the report provides only a general similarity. Document this limitation instead of inferring a compromise or a specific attacker.

Verify the outcome and resolve common dead ends

Research is traceable when another analyst can open the same intelligence entry, understand the filters used and trace every conclusion back to your Detection and event data. For a Case handoff, also check that the correct Detections are in the correct Case and the next action has a responsible analyst. If the Case is editable and the action is available, select the analyst in full Case details under Manage Case > Assignee.

If results do not fit, these checks help:

No search results: Check spelling and, for groups, Aliases. Remove additional filters; use the X in the search field to reset the search and table filters, then start more broadly. An empty search alone says nothing about the environment’s risk.
Too many results: Add a relevant characteristic, such as Type for malware or Report Type and Threat Type for reports. Also narrow the time range in Detections. The Detections table is limited to 10,000 results; aggregated filter results extend only to 1,000. A broad view is therefore not a complete inventory.
Report lacks expected IOCs or tabs: Available content depends on the report. Read the full text and any related intelligence without assuming missing content or particular coverage.
Detectors exist but there are no matches in your tenant: Separate Detector context from observed Detections. Check the time range, filters and telemetry available for the investigation. Do not run malware or disable protection to test it.
Explorer unavailable: First check the XDR/Enterprise licence and tenant in use. If the new navigation is missing, look for transition notices in the console; do not infer a technical product fault from a missing menu.
Case evidence not visible yet: Allow a few minutes for processing, then recheck the selection and destination Case. Do not immediately create a second Case.

Search and filters serve only research here; the reset described above is enough to start again. Adding evidence or comments, and especially the immutable Managed By selection, are Case changes. This runbook provides no blanket undo step for them. Resolve incorrect assignments with the responsible Case analyst and document the correction. Do not close Cases as a clean-up action: closure also changes the associated Detection assessments.

For ongoing operations, regularly review new malware entries, group activity and reports. Industry filters can focus the situational overview but should supplement the general overview. Feed findings into incident response; group TTPs support threat modelling, and malware analyses support planning and reviewing your protective measures. New intelligence calls for reassessment, not automatic proof that a configuration change is needed.