Skip to content
Avanet

Safely generate and verify a Sophos NDR test detection

This controlled test verifies the path from mirrored network traffic to Threat Analysis Center > Detections. The test simulates a download from a server with a suspicious domain and suspicious certificate characteristics; according to Sophos, it is not malicious. It nevertheless deliberately generates a High-Risk detection. Therefore, notify the responsible SOC or MDR team before the test and run it only within an approved test window.

This runbook uses Appliance Manager exclusively; no client download is required. A successful run produces the detection NDR-DET-TEST-IDS-SCORE. This confirms the tested collection and detection path, but not complete NDR coverage or an actual security incident.

Approval and prerequisites

Before making the technical change, record the following in a change or test ticket:

  • person responsible, approved source device or appliance, and affected NDR sensor;
  • start, planned end, and time zone of the test window;
  • expected detection name NDR-DET-TEST-IDS-SCORE and expected High-Risk classification;
  • responsible SOC/MDR contact and the agreement on how the known test detection will be documented;
  • firewall rule, rule owner, and specific removal time.

The SOC or MDR team must confirm the start. A calendar invitation alone is not sufficient: the test must not cause unnecessary escalation, while general NDR rules, notifications, and MDR monitoring must remain enabled. Mark only the test detection that can be attributed to the approved time and technical scope as expected.

The following prerequisites must also be met:

  • The appliance used is configured in Sophos Fusion, and Appliance Manager is reachable. Appliance Manager is accessed from a device on the same network as Sophos NDR.
  • The traffic to be tested is included in the current port-mirroring setup. Do not choose an arbitrary source; use the approved path whose visibility the test is intended to demonstrate.
  • The zadmin account and its Appliance Manager password are available.
  • The tenant has a confirmed EDR, XDR, or MDR entitlement for Threat Analysis Center > Detections. An NDR entitlement alone is not documented as sufficient for this view.
  • The person performing the verification has a Sophos Fusion role that is permitted to view Detections. The suitable predefined or custom role depends on the licence and role configuration; this runbook does not assume a particular minimum role.

Network access only for the Appliance Manager method

For the test window only, allow an outbound firewall rule from the selected NDR appliance to the fixed FQDN plrqkxqwvmtkm.xyz and documented IP address 13.56.99.184 over TCP 2222. Do not use an entire user zone, an Any destination, or a broad port range.

This fixed combination applies to the Appliance Manager test described here. Do not additionally open region-specific destinations used by another test method. Such a method requires a separately approved scope and only its currently documented destination; both destination sets may be opened only if both methods have been approved separately. The destination IP address and domain belong to the official Sophos test service, but must still be treated as a temporary exception. If the firewall cannot represent the FQDN and IP address in the same rule, use separate, equally narrow rules or objects. Before the run, verify that the destination address that is actually resolved and configured is covered by the approved scope. Remove the exception after the test even if no detection appears.

Run the test through Appliance Manager

  1. In Sophos Fusion, open Threat Analysis Center > Integrations > Configured.
  2. Go to Integration Appliances.
  3. Find the approved appliance, open the three-dot menu in the right-hand column, and select Open Appliance Manager.
  4. In the dialog, select Open.
  5. Sign in with the username zadmin and the appliance password.
  6. Select Generate Detections.
  7. On the Generate NDR Detections page, click Generate Detections.
  8. Confirm the message that a detection will be generated by clicking OK. Record the exact start time and wait ten minutes before treating the run as failed.

Do not start a second run during this waiting period. Otherwise, it becomes harder to attribute the detections, network flow, and change window unambiguously.

Validate the detection unambiguously

After the waiting period, open Threat Analysis Center > Detections in Sophos Fusion. Set the time range to include the recorded start time and search for NDR-DET-TEST-IDS-SCORE.

Do not check the name alone. A matching test detection meets these criteria:

  1. It is new and can be attributed by time to the approved run.
  2. The detection is classified as High Risk.
  3. Description shows the expected source and destination communication over TCP/TLS on port 2222.
  4. IDS is shown as the main contributor to the detection. In this context, IDS refers to the blocked certificate list.
  5. Under Raw Data, flow_risk contains the test characteristics: a known protocol on a non-standard port, a self-signed certificate, unusual ALPN negotiation, a blocklisted certificate, a high likelihood of an algorithmically generated domain, and indicators of the Friendly Chameleon family.

Document the detection time, detection link or ID, observed source and destination IP addresses, sensor or appliance, and verification result in the ticket. Sensitive raw data belongs only in the ticketing system approved for that purpose.

A detection is not the same as an incident

NDR-DET-TEST-IDS-SCORE is the expected result of an authorised simulation. A detection is a signal that warrants investigation; by itself, it confirms neither a compromise nor an incident. Associate only the exact matching detection with the test. Additional detections, or detections with different sources, destinations, or times, are triaged normally by the SOC or MDR team and must not be indiscriminately closed as consequences of the test.

Not every detection automatically creates a case or becomes the responsibility of Sophos MDR. A case derived from XDR detections is Self-managed, remains the customer’s responsibility, and must be assigned to a customer administrator; Sophos does not investigate it. Sophos MDR takes ownership only of a case identified as Sophos-managed and based on MDR detections. The actions MDR is permitted to take also depend on the configured Authorize, Collaborate, or Notify Only mode. Therefore, label or close only the clearly correlated test detection or test case, in accordance with the XDR or MDR process already in effect. This runbook confirms only the generation and content of the test detection.

If the detection is missing or does not match

Work from the narrowest fault domain outward, and do not change multiple components at the same time:

Appliance Manager does not confirm the start

Verify that the correct appliance was selected, Appliance Manager is reachable from the local network, and the zadmin sign-in works. Without start confirmation, there is no reliable NDR test run yet. Therefore, do not change port mirroring or detection settings; first restore Appliance Manager access or escalate the appliance fault.

The test starts, but no detection appears

  1. Wait the documented ten minutes, then check the time range, filters, and spelling in Threat Analysis Center > Detections.
  2. In the firewall logs for the recorded start time, verify whether the approved source actually established a TCP connection to the approved test destination on port 2222. A denial or missing connection attempt narrows the fault to the rule, routing, DNS, or test start.
  3. If the connection is visible, verify that this exact source traffic is mirrored on the monitored switch port and delivered to the correct NDR sensor. Do not broaden the firewall rule to Any merely to produce a detection.
  4. Check the operational state of the affected Integration Appliance and NDR sensor. A healthy appliance alone does not prove that the test flow reaches the sensor.
  5. Repeat the test only after a specific correction and with a newly recorded start time. If the detection still does not appear, provide the ticket, timestamp, firewall observation, test source, destination, and affected sensor through the appropriate Sophos support channel.

A detection appears, but its characteristics differ

First compare the time, source, destination, and port. Without this unambiguous correlation, do not treat the detection as a successful test. Submit an unexpected detection to the SOC/MDR team for normal triage. Do not modify or close it based only on a similar name.

Cleanup and rollback

Rollback is part of the test and is performed regardless of the result:

  1. Disable or delete the temporary outbound firewall rule for TCP 2222 to the test destination. Also remove any host, FQDN, or service objects created specifically for it, unless another approved configuration uses them.
  2. Verify in the active firewall configuration that the corresponding access from the test source no longer exists. A comment or closed change ticket does not replace this technical post-check.
  3. Notify the SOC or MDR team that the test has ended and provide the detection ID, result, and rollback status. Ensure that only the clearly correlated test detection is documented as an authorised simulation.
  4. Label or close the correlated test detection and any resulting case only under the existing applicable XDR or MDR process. A Self-managed XDR case remains with the assigned customer administrator; a Sophos-managed MDR case remains in the MDR workflow and is subject to the agreed response mode.
  5. Close the ticket only after verifying rule removal, recording the result, handling the test artefact under the applicable process, and assigning any unexpected detection to a responsible person.

A failed test ends with the same rollback. Do not leave the temporary access open for later troubleshooting; a new run requires a new, or explicitly extended and confirmed, test window.