How T1011 exfiltration over other network medium hides from normal egress monitoring
For a SOC lead, the question is whether the second network medium is watched as closely as the main egress paths. T1011, Exfiltration over other network medium, falls under the Exfiltration tactic (TA0010), which MITRE describes as "The adversary is trying to steal data." (MITRE ATT&CK tactic TA0010). In this technique, an adversary moves stolen data out of the environment over a medium other than the channel it uses for command and control, so the data can leave through a path that standard egress sensors never inspect. This page targets ATT&CK v20.0, and the technique has 1 sub-technique, which covers one specific medium.
The blind spot exists because most egress monitoring is built around IP traffic: proxy and firewall logs, flow records, DNS resolution and TLS inspection at the perimeter. A cellular modem, a Bluetooth adapter, a secondary network interface or a tethered device can carry data outside those sensors. For a host with such a medium, the watched paths may show nothing unusual while the data moves through hardware the monitoring stack was never configured to see. The first decision is therefore an inventory of which endpoints and servers have these media enabled, and which ones are allowed to use them at all.
Once the inventory exists, the SOC lead should confirm three things before writing any analytic. First, whether endpoint telemetry records network connection creation and process activity for these interfaces, since ATT&CK ties Exfiltration detections to Network Connection Creation and Network Traffic Flow data. Second, who owns the response when a non-IP path is seen. Third, which ATT&CK version the detections map to, because releases can rename or deprecate techniques. Confirm the mapping against the enterprise-attack 20.0 STIX bundle, and confirm with the endpoint and platform teams what their tooling actually records.
Which telemetry reveals T1011 and which open-source tool collects it
This table maps each data component ATT&CK links to T1011 against what it shows, the open-source collector that gathers it, and the gap to confirm in your own environment. Read it as a set: flow records show that bytes left through a path, while host process context shows which binary or service produced them. Neither alone is enough to attribute an alternative-medium transfer.
| Data component | What it shows for T1011 | Open-source collector | Gap to confirm locally |
|---|---|---|---|
| Network Connection Creation (DC0082) | Host-side socket or connection events, including the process that opened an outbound path over a non-standard route | Wazuh, Velociraptor | Confirm which endpoints emit connection events and whether the agent captures the owning process ID |
| Process Creation (DC0032) | Command-level context for the program that initiated the transfer, its parent and its user | Wazuh, Velociraptor | Confirm command-line logging is enabled on Linux, macOS and Windows hosts and retained long enough to investigate |
| Network Traffic Flow (DC0078) | Source, destination, ports, byte counts and duration for sessions crossing the boundary | Zeek, Security Onion, Suricata | Confirm sensor placement covers egress paths, including any secondary or non-IP routes in your design |
| Correlation across host and network | Links a flow record to the host process that created it, which is needed to separate authorized tools from unexpected ones | Security Onion with Wazuh | Confirm clock synchronization across hosts and sensors, since mismatched timestamps break correlation |
| Baseline of approved egress paths | Lists the media and routes the business legitimately uses, so unusual use stands out | Zeek, Wazuh | Confirm with network and endpoint owners which transfer paths are approved and documented |
Detection ideas for T1011 that SOC teams can tune
These ideas target the signals that separate T1011 Exfiltration over other network medium from routine traffic: a host opening a channel it never uses, an interface that changes state, and a process talking to a network it does not normally reach. Each idea needs a baseline per host group before alerts are trusted, and each will fire on legitimate management and remote access tooling until exclusions are agreed with the owning teams. Map rules to the ATT&CK version your team targets, since ATT&CK v20 is the version these pages use.
New outbound channel from quiet hosts
Alert when a host that has no history of outbound connections on a given protocol or port begins sending data on that channel. The logic compares each host group's connection profile over a baseline window against current Network Connection Creation events. Tune the threshold on bytes sent relative to the group's median, and start with servers and kiosks, which usually have the narrowest profiles. Likely false positives include VPN clients, backup agents and patch management tools that have been added to a host group recently. Express the rule in Sigma so it can be ported to your SIEM and reviewed under version control.
Unexpected network interface activation
Flag hosts where a network adapter, tunnel or virtual interface becomes active that is absent from the host's build standard. This matters for T1011 because an adversary may move data through a medium other than the one the organization monitors, so a new interface is a signal worth investigating. Check interface state changes against the asset inventory and the configuration management record. Tune by allowlisting approved adapters per device class, and expect false positives from docking stations, Wi-Fi adapters on laptops, hypervisor bridges and endpoint security drivers.
Process to network pairing outside baseline
Alert when a process that normally has no network role opens a connection to a destination it has not contacted before. The rule pairs Process Creation context with Network Connection Creation events and compares each executable's destination set against its historical set. Tune on first-seen destinations within a defined window, and suppress known update and telemetry domains per process. Expect false positives from browsers, package managers and management agents that reach new vendor endpoints after upgrades, so review each allowlist entry against a documented owner.
Volume spikes on scheduled hours
Detect a host sending a sustained volume of data during hours when it normally idles, using Network Traffic Flow records aggregated per host and per hour. The check is useful because data moved over an unusual medium often runs outside business activity. Set the threshold against the host's own weekly pattern rather than a fixed byte count, and require persistence across more than one interval before paging. Likely false positives include scheduled backups, log shipping, replication jobs and endpoint security updates, so confirm each schedule with its owner before tuning.
Management tooling exclusions review
Review every allowlist that suppresses the three rules above at least once per release cycle. Each exclusion should name the tool, the owning team, the expected destinations and the date it was approved. Management and remote support tools are the most common source of unexplained T1011-like activity, so a stale exclusion can hide the very behavior the rule was written to catch. Ask the owning team to confirm destinations after each upgrade, and log every change so an analyst can trace why an alert was silenced during an investigation.
How to build T1011 detections from ATT&CK STIX data
Start from the enterprise-attack 20.0 STIX bundle, not from a summary web page, because it is the only file that ties T1011 Exfiltration Over Other Network Medium to its detection strategies, analytics and data components in a machine-readable form. Pin the version in your detection repository, for example by recording enterprise-attack-20.0.json in the rule metadata, so every Sigma rule or Wazuh decoder states which ATT&CK release it was written against. Then extract the relationships where T1011 is the target: the detection strategy objects that reference it, the analytics under each strategy, and the data components those analytics name. Note that the bundle is published per domain and version in the mitre-attack/attack-stix-data repository, so confirm you are reading the Enterprise domain and not the Mobile or ICS bundles.
ATT&CK v18 moved away from free-text detections in technique pages toward detection strategies (DET IDs) and analytics, and it made major updates to data components (DC IDs) while deprecating data sources. For T1011 this matters because the sensor coverage you think you have may be described in terms of data sources that no longer map cleanly to your telemetry. Review each analytic and confirm that the data component it names, such as Network Connection Creation or Network Traffic Flow, is actually produced by your Wazuh, Zeek, Suricata or endpoint agent configuration. Record any gap as a documented limitation rather than assuming coverage. Confirm the current mapping details against the ATT&CK v18 release notes before you rely on them.
Track changes across v18, v19 and v20 by diffing successive bundles and reading the update notes for each release. Recent releases were v18 on October 28, 2025, v19 on April 28, 2026 and v20 on October 13, 2026, and each can rename, deprecate or revoke techniques or change the detection objects attached to them. Automate a comparison that flags any change to T1011, its sub-techniques or its linked analytics, and route flagged items to the detection owner for review. Keep a changelog that names the old and new version, the affected rule identifier and the decision taken. Mapping this way lets an auditor or customer verify which ATT&CK version each detection targets, and it is the evidence most likely to be asked for when controls are assessed against a framework.
How to confirm the T1011 detection fires before you rely on it
This sequence turns the T1011 detection from a rule on paper into evidence that it fires on the telemetry you actually collect, with a record of timing, gaps and noise that your team can review before depending on it.
Define the expected telemetry first
Before any emulation, the detection engineer and the platform owner write down which data sources should show T1011 activity on each in-scope platform, such as Network Connection Creation, Process Creation and Network Traffic Flow for Linux, macOS and Windows. For each source, record the fields the alert depends on, the host groups that should forward them, and the retention period set by your own logging policy. Confirm the ATT&CK version you target (for example v20.0), because data component and detection mappings can change between releases. The step is done when the expected-telemetry table is signed off by both the detection owner and the team that runs the SIEM or Wazuh manager.
Agree the emulation scope in writing
The red team or range operator and the blue team agree in writing which behaviors will be emulated, on which hosts, in which network segment, and what counts as success. The scope also names what is out of bounds, such as production hosts, real external destinations and data that resembles customer records. Someone with authority over the range signs off on the rules of engagement, and the agreed scope is attached to the test plan. The step is complete when both teams can point to the same scope document and the emulation owner has confirmed the lab boundaries.
Run the emulation in a controlled range
The emulation runs in a private cyber range or isolated lab that mirrors your logging pipeline, not in production. The operator records start and end times for each emulated action, the host it ran on, and the account used, so every event can later be matched to a known action. Detection engineers stay on the blue side without prior knowledge of the timing, which keeps the result realistic to how an analyst would experience it. The step is done when the operator has closed the run and exported a timeline of emulated actions.
Check each alert for the expected fields
For every emulated action, the analyst checks whether the alert fired, which rule or analytic produced it, and whether the event carries the fields the detection depends on, such as source and destination address, port, process name, parent process and user. A missing or empty field is logged as a defect even when an alert exists, because the rule may fail silently in production when a field changes. The output is a per-action table with three columns: alert present, correct fields present, and reference to the rule version. The step closes when every emulated action has a row in that table.
Record detection time and missed events
Using the timeline from the operator and the alert timestamps from the SIEM, the team calculates the delay between each emulated action and the first alert, and lists every action that produced no alert. Each miss is classified by cause, such as a missing log source, a filter that dropped the event, a parsing error or a rule threshold that was not reached. The team records these as separate findings with an owner and a retest date agreed in the test plan. The step is complete when every emulated action is marked as detected, missed, or partially detected, with a cause for each miss.
Measure false positives under normal load
A detection that fires on the emulation but also on routine administrative traffic will overwhelm analysts after go-live. The team replays or runs a representative set of benign activity in the same range, such as backup jobs, software updates, and normal file transfers to approved destinations, and counts how many alerts fire on that activity. Each false positive is reviewed to decide whether to tune the rule, add an exception with a documented reason, or accept the noise. The step is done when the false-positive count and the tuning decisions are recorded in the same evidence file.
Assemble the evidence file
The evidence file is a single versioned package containing the ATT&CK version targeted, the expected-telemetry table, the signed scope, the operator timeline, the per-action alert table, the detection-time and miss findings, the false-positive results, and the rule versions tested. It should also state the range configuration, the log source versions and any changes made after the run. Store the file under change control so auditors and internal reviewers can trace a detection back to the test that justified it. The step closes when a second engineer who did not run the test can reproduce the summary from the file alone.
Decide whether to rely on the detection
The detection owner and the security leadership review the evidence file and decide one of three outcomes: approved for production, approved with named gaps and compensating controls, or returned for rework. Any approval records the date, the reviewers, and the conditions that would trigger a retest, such as a change to the logging pipeline, a new ATT&CK version, or a platform upgrade. Ask your implementation partner or internal team to confirm which retest triggers apply to your environment. The sequence ends when this decision is recorded and the rule is promoted or held.
Preventive controls for T1011 from ATT&CK mitigations
ATT&CK maps two mitigations to T1011 Exfiltration over other network medium: Disable or Remove Feature or Program (M1042) and Operating System Configuration. Both work by shrinking the number of unused or unmanaged channels an adversary could use to move data, so the controls below focus on what to remove, what to configure and what to verify on your own estate.
Remove unused transmission features
Disable or Remove Feature or Program (M1042) asks you to turn off or uninstall capabilities that are not needed for the business. For T1011, the relevant candidates are unused modems, serial or infrared interfaces, Bluetooth file transfer, removable media auto-run and unneeded network-attached peripherals on Linux, macOS and Windows hosts. Build an inventory of these features per host role, then remove them from the standard image so they do not return on rebuild. Confirm each removal against the vendor's current hardening documentation for your platform, since default feature sets vary by OS version.
Harden operating system configuration
The ATT&CK mitigation Operating System Configuration covers settings that limit how hosts expose or use alternate channels, such as disabling unused device drivers, restricting removable media and controlling which services can open outbound paths. Document the target configuration as code so drift can be detected. Ask your platform or endpoint team to show evidence that the baseline is applied to every class of host, including those that are rarely patched or managed.
Control removable and peripheral devices
Device control policies are the practical counterpart to removing features. Restrict which USB storage, serial adapters and wireless peripherals can connect, and record each allowed device class. Pair these policies with logging of device connection events so that an unapproved device attempt produces a signal. Confirm with your endpoint management product which device classes it can allow, block or only report, because capability differs between products.
Restrict hardware-level and wireless interfaces
Hosts in sensitive zones may carry network-capable hardware that bypasses the main network path, such as cellular modems, wireless adapters or Bluetooth radios. Decide which of these are permitted, disable them in firmware or BIOS where the device allows it, and record exceptions with an owner and review date. Treat any exception as a risk acceptance, and confirm with the hardware vendor which controls are available for each model in your fleet.
Verify controls against your ATT&CK version
Mitigation mappings change between ATT&CK releases, and the mitigations linked to a technique may be renamed, deprecated or revoked. Before you cite these controls in an assessment, check the mitigation IDs against the ATT&CK version you target, and retain the version in your control register. Confirm each control on your own platform with a configuration check rather than assuming it is in place because the mapping exists.
What SOC analysts should do when a T1011 alert fires
When a T1011 alert fires, the first decision is whether the alert describes a real data path or a benign one. Start by confirming the host and the owning process behind the network connection, using the Process Creation and Network Connection Creation records that triggered the alert. Record the process name, parent process, executable path, hash, the user context and the destination address and port in the ticket before anything else changes. Then check whether the network path matches a sanctioned service: an approved VPN client, a managed backup agent, a vendor telemetry channel or a documented administrative tool. Compare against your asset inventory and change records, and treat an unexplained or unapproved medium as suspicious until the owner confirms otherwise. Confirm these facts with the system owner, not only from the alert text.
Preserve volatile evidence before you isolate or reboot anything. Capture running process details, open network connections, loaded modules and the routing and interface configuration while the host is still in its current state, and hash any suspect binaries and their configuration files. Keep the chain of custody in the case record, noting who collected each artifact and when. Next, scope the pattern across the estate: search the same process names, hashes, destination ranges and interface types over the past window your retention allows, and list every host that matches. Contain the path at the network layer by blocking the destination or restricting the interface at the perimeter or host firewall, and confirm the block with a second telemetry source so the containment is verified.
Decide on escalation based on what the scoping shows, not on the alert severity alone. Escalate to incident response when the process is unapproved, when the same pattern appears on more than one host, when the data path involves sensitive systems, or when you cannot establish a sanctioned owner within your agreed response window. Document each decision, the evidence supporting it and the owner who approved any change. Ask your incident response procedure owner to confirm the escalation thresholds, the contacts for system owners after hours and the retention period of your Network Traffic Flow and process telemetry, because those limits determine how far back your scoping can reach.
How to rehearse T1011 detection in a private cyber range
A useful range for T1011 needs Linux, macOS and Windows hosts that send endpoint telemetry to a central platform, plus a network sensor placed where traffic to non-IP or unusual adjacent links can be observed. Build the range from the same configuration as the production estate, using isolated network segments with no route to real external systems. Confirm which Wazuh, Zeek, Suricata and Security Onion versions you will run, and record them, because detection content is tied to the data each version produces.
- Endpoint agents: Install Wazuh agents on every Linux, macOS and Windows host and confirm that process and network connection events reach the manager before the exercise starts.
- Network sensing: Place Zeek or Suricata on the segment that carries host-to-host and egress traffic, and confirm the sensor writes flow and connection logs to Security Onion.
- Time and identity: Synchronize clocks across all hosts and sensors, and label test accounts so that activity can be attributed during the debrief.
- Baseline capture: Record normal activity for a fixed period so that analysts know what routine interfaces and transfers look like.
- Ground truth log: Keep a timestamped record of every scripted action performed by the exercise team, held separately from the blue team's view.
Check that every data source named in the detection plan appears in the platform before any inject is scheduled.
Injects are scripted events that the exercise team introduces into the range so that the blue team has something to detect. For T1011, the aim is to present a data movement that uses a medium other than the standard network path, while keeping the scenario realistic enough that analysts must reason from telemetry rather than from a hint. Write each inject as a short scenario brief, with an expected detection outcome that the exercise team holds back until the debrief. Injects should vary in difficulty so that both routine and subtle cases are covered.
- Clean baseline inject: A routine activity that looks similar to the target behavior but is authorized, so the team learns to avoid false positives.
- Single-host inject: One endpoint performs an unusual transfer that should appear in process and connection telemetry.
- Cross-platform inject: The same behavior appears on a Linux host and a Windows host, which tests whether analysts apply consistent logic across platforms.
- Degraded telemetry inject: A sensor or agent is stopped partway through, so the team must recognize and report the gap.
- Escalation inject: A later message from a fictional business owner asks whether the activity is expected, which tests triage communication.
Publish the scenario brief only to the blue team, and keep the ground truth log with the exercise team.
Good detection for T1011 means that the team can state, from telemetry alone, which host originated the activity, which process was involved, what connection or channel was used, and when it began. Analysts should be able to point to the specific data component that carried the signal, such as Process Creation, Network Connection Creation or Network Traffic Flow, and explain why that component was chosen. A detection that fires on the right host but cannot be explained in these terms is weaker than one with a documented logic path, even if both alert.
- Telemetry mapping: Each alert links to the data components used in the detection strategy for the targeted ATT&CK version.
- Timing: The alert fires within the window defined in the detection rule, and the team records the delay between the inject and the alert.
- Context enrichment: Analysts add asset owner, user account and baseline comparison before escalating.
- Coverage notes: The team notes which platforms and sensors did not produce a signal and why.
- Rule quality: Any Sigma or platform rule used during the exercise is reviewed for false positives seen in the baseline phase.
Check whether detections fired because of logic the team understands, or because an analyst happened to notice an unrelated event.
Response is judged on whether the team contained the activity, preserved evidence, and communicated accurately. For T1011, containment usually means restricting the affected host or the unusual channel, while avoiding disruption to the wider estate. Evidence preservation matters because the same behavior may need to be explained to auditors, legal teams or the business owner later. The exercise should test the handoff between the security operations team and the platform team, since the people who can stop a transfer are often not the people who first see the alert.
- Triage decision: The analyst records whether the activity is malicious, authorized or unknown, with the reasoning.
- Containment action: The team applies a documented containment step and notes the time it took to decide.
- Evidence handling: Relevant logs, process details and sensor records are exported and hashed according to the team's procedure.
- Communication: Stakeholder updates are sent in the agreed format, with clear statements of what is known and what is not.
- Recovery check: The team confirms that the containment did not remove legitimate services and that telemetry is restored.
Check that the response steps match your incident response plan and that the people named in it were reachable during the exercise.
Scoring should be defined before the exercise begins and shared with the blue team in the rules of engagement. Score each inject separately for detection, triage, containment, evidence and communication, using a fixed scale agreed by the exercise lead. Compare the team's timeline against the ground truth log, so that scores reflect what happened rather than what the team believes happened. The debrief output is the document that drives improvement, so it should name specific detection gaps, owners and follow-up dates rather than general observations. Treat the scoring method as something to refine between exercises, not as a fixed verdict.
- Scoring criteria: Each category has written criteria and an agreed scale, with the scorer noted.
- Timeline reconstruction: The exercise team compares alert times, analyst actions and inject times in one view.
- Gap register: Missed detections, weak rules, missing telemetry and unclear procedures are recorded with an owner.
- Rule changes: Any detection changes are tested against the baseline and the injects before they are promoted.
- Retest plan: The next exercise includes the failed injects so that improvements can be verified.
Confirm with your exercise provider what the range platform records automatically, and what the team must capture by hand.
Questions SOC leads and detection engineers ask about T1011
How does T1011 differ from T1048 and T1041 for detection purposes?
T1011 covers transfer over a network medium other than the standard network path, such as a radio or Bluetooth link on a host, while T1048 and T1041 describe exfiltration over an alternative protocol or over an existing command and control channel. The deciding question for an analyst is which path the data takes. Confirm the exact scope of the sub-technique against the ATT&CK v20 entry before you map rules, because the technique wording defines what your coverage claims. For T1011, start with endpoint telemetry: Network Connection Creation (DC0082) and Process Creation (DC0032) show which processes open non-standard interfaces and move data across them. Network Traffic Flow (DC0078) becomes the main signal for T1048 and T1041. Build separate analytics for each technique, but keep a shared mapping so one event does not open three unrelated cases.
How do we handle VPN and backup false positives for T1011 alerts?
Tune by baselining known-good sources and scoping each exception to a named process, host group, destination and time window. VPN clients create tunnel interfaces and move steady volumes of traffic, and backup agents send large transfers on a schedule, so both will trigger volume-based logic. Key allowlists to signed binaries, service accounts, host roles and expected destination networks, not to hostnames alone. Alert when a trusted tool begins using a new destination, a new interface or an unusual hour, because that deviation is where the risk sits. Review exceptions on a fixed schedule and record who approved each one. The Filter Network Traffic mitigation (M1037) can reduce noise at the network layer, but it works best after the endpoint baseline is documented. Test each exception in a staging environment before it reaches production sensors.
Which data components do we need for Linux versus Windows telemetry?
Both platforms need Process Creation (DC0032) and Network Connection Creation (DC0082), but the collection path differs. On Linux, teams commonly collect process and network events through audit logging or an endpoint agent, so confirm which fields your agent records for the process path, the network interface and the byte counts. On Windows, Sysmon process creation and network connection events are a common source, and they should be checked against your own configuration because default settings may omit fields you need. Network Traffic Flow (DC0078) should come from a sensor such as Zeek or Suricata on the segments where traffic leaves the host. Interface and device state changes matter for T1011 specifically, so verify that your Linux and Windows agents capture them. Document the gaps in a coverage table so auditors and analysts can see what is missing.
How should we version T1011 detections across ATT&CK releases?
Tag every detection with the ATT&CK version it targets, and store the technique and sub-technique IDs alongside the rule. ATT&CK v18 was released on October 28, 2025, v19 on April 28, 2026 and v20 on October 13, 2026. Each release can rename, deprecate or revoke techniques, and v18 replaced detections with detection strategies and analytics, so a rule written for an older layout may need a new mapping. After each release, read the update notes, diff the STIX bundle for your domain and review every mapping that touches T1011. Keep the previous version of each rule in source control so you can explain past alerts. Ask your platform team to confirm how your SIEM and rule repository handle version fields, since not every tool supports them natively.
How do we test T1011 detections without disrupting production?
Test in an isolated environment that mirrors your sensor placement, log pipeline and endpoint agents, then promote rules through staged environments. A private cyber range lets the team replay recorded or simulated activity at controlled volumes without touching business systems. Agree on test windows, rate limits, named owners and a rollback plan before each run. Use canary hosts or a limited group of endpoints for the first production deployment, and watch alert volume and sensor load for a defined period before widening scope. Record each test with the rule version, the test data set, the expected result and the actual result, so the evidence can support later reviews. Keep test traffic clearly tagged so it can be excluded from production dashboards and metrics.
Can our own team build and run T1011 detections, or do we need outside help?
Many teams can build the first version in-house if they already run a SIEM, endpoint telemetry and network sensors, but the work includes more than writing rules. It covers confirming log sources, tuning exceptions, versioning after each ATT&CK release, testing in a range and documenting coverage for audits. DeployOpen plans, implements and hardens self-hosted open-source platforms inside your own infrastructure, and runs cyber range exercises and security testing. Most engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts, and ongoing support is available as a retainer. DeployOpen prepares controls and evidence for compliance assessments but does not issue audit reports or certifications. Ask any provider to confirm which platforms they will work on, who holds the rule repository and how handover will be documented.
How DeployOpen builds T1011 detections and range exercises
DeployOpen works on T1011 Exfiltration over other network medium as a fixed-scope engagement inside the client's own infrastructure, with the scope agreed in writing before any work starts. The result is a detection set, a tested range exercise and documentation that the client's own teams can run and maintain.
How we scope
- Confirm which Linux, macOS and Windows estates are in scope for T1011 detection work.
- Record the ATT&CK version the detection mappings will target, since releases can rename or revoke techniques.
- Agree which telemetry sources exist today, such as network connection and process creation logs, and which must be added.
How we build
- Map T1011 detection logic to Network Connection Creation, Process Creation and Network Traffic Flow data components.
- Write open-source detection rules, for example Sigma rules, and deploy them to the client's Wazuh or Security Onion stack.
- Tune alert thresholds against the client's normal network behavior to reduce noise before handover.
How we hand over
- Document each detection with its data sources, logic in plain language, known gaps and the ATT&CK version it targets.
- Deliver a private cyber range exercise that replays T1011 telemetry so the client's analysts can validate alerts.
- Provide response runbooks covering triage, containment and evidence capture, with the mitigations the client already owns noted.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Review detections when MITRE publishes new ATT&CK releases that affect T1011 or its mitigations.
- Confirm with the client's team which mitigations, such as Disable or Remove Feature or Program and Operating System Configuration, are enforced in their environment.
