How T1220 XSL script processing hides inside normal Windows activity
T1220 XSL script processing is a Windows technique in which an adversary uses the component that reads and transforms XSL stylesheets to run script content, so the work happens inside a trusted system process. It matters to a SOC lead because the process doing the work is a legitimate Windows binary, and its activity can blend into routine application behavior and process trees. MITRE places this technique under the Stealth tactic, TA0005, which ATT&CK defines as: "The adversary is trying to hide and conceal their actions, appearing as normal behavior." For a defender, that definition is the design brief. The question is not only whether a suspicious binary ran, but whether a trusted one ran in a context nobody has documented. See the MITRE ATT&CK tactic page for Stealth for the full definition.
Stealth techniques are seldom used alone. In most intrusions, T1220 would sit alongside other steps such as execution, persistence or further evasion, so detection should not depend on this one event. The decision to make now is whether your alerting treats XSL-processing Windows components as inherently benign. Before tuning anything, build a baseline: list which business applications on your endpoints legitimately invoke XSL transforms, which accounts run them, and which parent processes start them. Confirm each entry with the application owner, because that baseline is what separates routine use from the unusual invocation you need to see. Process Creation (DC0032) and Module Load (DC0016) are the telemetry most useful for building that baseline.
This page uses Enterprise ATT&CK version 20.0, which MITRE released on 2026-10-13. Technique IDs, tactic assignments and data component mappings can change between releases. ATT&CK v19 split the former Defense Evasion tactic into Stealth, TA0005, and a new Defense Impairment tactic, TA0112, so confirm where T1220 sits in the version your detection library targets before writing rules against it. Ask your detection engineering team to record the ATT&CK version alongside every rule so that later tuning does not quietly mismatch the technique. The ATT&CK updates page lists the release history to check against.
Which Windows telemetry reveals XSL script processing
This table maps each Windows telemetry source to the signal it can show for T1220 XSL Script Processing and the open-source collector that gathers it. Read it as a set of complementary sources, where Process Creation and Module Load carry the primary signal and Command Execution adds supporting context. Confirm which data components the current detection strategy for T1220 references in your ATT&CK version before you build rules.
| Telemetry source | Signal to look for | Open-source collector | Role in detection |
|---|---|---|---|
| Process Creation (DC0032) | A script-capable Windows host process starting with an XSL stylesheet or remote script reference in its arguments, or a parent-child pair that is unusual for the user | Sysmon Event ID 1 forwarded by the Wazuh agent or Winlogbeat to Security Onion | Primary source, identifies the launch event |
| Module Load (DC0016) | Scripting engine or XML transform libraries loaded into a process that does not normally load them | Sysmon Event ID 7 collected by Wazuh or Security Onion | Primary source, confirms the script engine ran |
| Command Execution (DC0064) | Command line content that references XSL files, script-processing hosts or remote URLs, captured as Windows command activity | Windows Security process auditing and PowerShell logging collected by Wazuh | Supporting source, adds context and reduces false positives |
| Network Connection Creation (DC0082) | Outbound requests made by the script host shortly after launch, which may fetch a remote stylesheet | Sysmon Event ID 3 with Zeek or Suricata logs in Security Onion | Supporting source, useful for remote-retrieval variants (illustrative) |
| Data component references in the detection strategy | Confirm which DC IDs the current T1220 detection strategy lists for your ATT&CK version | Check the ATT&CK STIX bundle for your target version in the attack-stix-data repository | Validation step, not a telemetry source |
Detection logic for T1220 on Windows
T1220 XSL script processing abuses legitimate Windows components that run script logic inside XSL transformations, so the signal lies in unusual process lineage and module loads rather than in a single known-bad file. The cards below pair each detection idea with the false positive sources that will surface it and the tuning that keeps coverage intact.
Script host parent-child relationships
Start with the process tree. Alert when a script-hosting or XSL-capable binary is started by an office application, a browser, a mail client or a remote management service, since these parents rarely launch transformation tools in normal use. Enrich each event with the parent image, the command line, the user context and the signing status of the child. Process Creation telemetry from Sysmon or Windows Security event 4688 with command-line logging is the usual source. Confirm which parent-child pairs your endpoints actually produce before writing the rule.
Module loads tied to XSL transformation
Some detections key on the libraries a process loads, not on the process itself. Watch for scripting engines, XML or XSLT processing libraries and COM script components loaded by a process that does not normally use them. Module Load telemetry (Sysmon event 7) is noisy, so restrict collection to a defined set of high-value image paths and to processes outside your developer and build hosts. Record the hash and signer of every module seen in your baseline so new loads stand out.
Rare host and process combinations
Rarity is more durable than a fixed list. Count how often each pairing of host role, parent image and child image occurs over a rolling window, then alert on pairings that appear on a small set of endpoints or only once. A workstation that suddenly runs an XSL-capable binary under a service account is worth a look even if no single field is malicious. Use stack counting in your SIEM, such as Wazuh or Security Onion dashboards, to surface the long tail.
Baselining thresholds to tune
Set thresholds from observed behavior, not from assumption. Measure the weekly count of script-hosting executions per host group during a quiet period, then set alert thresholds at a level that flags sustained deviation rather than single events. Review thresholds after each software deployment cycle, because patch windows and new application releases shift the baseline. Document the baseline date, the data sources and the owner, so the threshold can be defended in an audit.
Legitimate line-of-business scripts
Line-of-business applications, reporting tools and document generators may invoke XSL transformations legitimately. Suppress them by exact match on signed parent image, install path, service account and command-line pattern, rather than by process name alone. Each suppression should carry an owner, a ticket reference and an expiry date. Avoid broad allow rules on directory paths writable by standard users, because those rules are the first thing an attacker would rely on.
Deployment tools and admin automation
Software deployment agents, configuration management runs and scheduled administrative tasks generate many of the same events. Scope exclusions to the management server identity and the deployment job name, and log every suppressed event to a separate index so the exclusion can be reviewed. Confirm with the platform team which automation runs on which hosts, and test each exclusion against a known deployment in a cyber range before it reaches production.
How to validate that the T1220 detection fires
This sequence proves that the T1220 XSL Script Processing detection fires on an approved, benign emulation, reaches the SOC queue with usable fields, and gives the team measured baselines for alert latency and false positives. It is run as a repeatable check, not a one-off test.
Define the test scope and success criteria
The detection owner, the SOC lead and the testing partner agree in writing which Windows hosts, user accounts and log sources are in scope, and which behaviors the test will represent at a high level. They also set the pass criteria: the alert fires, reaches the queue, and carries the required fields. The step is done when the scope document is signed off and the out-of-scope systems are named explicitly.
Confirm the ATT&CK version and detection mapping
The team records the ATT&CK version the rule targets and checks that the T1220 entry, its detection strategies and the data components it references (such as Process Creation and Module Load) still match that version. Because MITRE can rename or deprecate techniques between releases, the mapping is pinned to a named version in the test record. The step is complete when the detection ID, rule name and ATT&CK version appear together in one document.
Verify telemetry is flowing before the test
Before any emulation, the platform team confirms that Windows event sources and the Wazuh agents or equivalent collectors on the in-scope hosts are forwarding process creation and module load events to the SIEM. They check timestamps, host names and agent status against a known baseline event. The step closes with a documented pre-test check showing that the expected events are indexed.
Run the approved benign emulation
The red team or testing partner executes an approved, benign emulation of the T1220 behavior inside the private cyber range or a sanctioned lab, under a written rules-of-engagement document. The partner keeps a timestamped log of when each action happened, without publishing the technique steps in the test report. The step is done when the emulation record and start and end times are filed with the test plan.
Confirm the alert reaches the SOC queue
An analyst checks the alerting platform and the ticketing or case queue that the SOC uses, and confirms that an alert for the emulated activity was created and routed to the correct team. The analyst verifies that the alert is not suppressed by an existing exclusion or a deduplication rule. The step closes when the alert ID is linked to the test record.
Check the fields populated in the alert
The analyst reviews the alert and confirms that the host, user, parent and child process names, command line where the log source provides it, file path, hash where available, and timestamp are populated. Missing fields are logged as gaps with the affected log source. The step is complete when a field checklist is filled in for the alert and each gap has an owner.
Measure time to alert and false positive rate
The team calculates time to alert by comparing the emulation's logged start time with the alert creation time in the SIEM, and records the result against the agreed success criteria. They also run the rule over a defined period of normal activity on the same hosts to count false positives and document the tuning decisions. The step closes with a results table that shows measured values, the ATT&CK version tested and the rule version.
Record the results and schedule re-validation
The detection owner reviews the results with the SOC, decides whether the rule passes, and files any tuning or telemetry changes as tracked tasks. The team sets a re-test trigger tied to rule changes, log source changes and new ATT&CK releases, and confirms the schedule with the partner in writing. The step is done when the signed results record and the re-validation trigger are stored with the detection documentation.
Tuning T1220 detections without losing coverage
Detection engineers should move a T1220 XSL script processing rule from a noisy hunt query to a production alert in deliberate stages, and the first stage is a baseline of known good XSL usage for each host group. Build that baseline from a defined period of process creation and module load telemetry on Windows, grouped by role (build servers, reporting hosts, document management systems, admin workstations). Each group will have different legitimate processes that invoke XSL transforms, and a single global rule will either flood the queue or get suppressed wholesale. Record which parent processes, command line patterns and loaded modules are expected per group, and keep the baseline in version control so changes are reviewed rather than edited silently.
Every suppression needs a named owner, a written reason and an expiry date. An exception without an expiry tends to become permanent, and a permanent exception is the most common way coverage quietly disappears. Set a review cycle, track alert volume and the count of active exceptions over each cycle, and look for exceptions that match nothing in the last period. Sample some suppressed events to confirm they still match the justification. Confirm with your SIEM or Wazuh rule owner how suppressions are stored and audited in your environment, since the mechanism differs between deployments.
Re-test the rule after every ATT&CK release, because techniques can be renamed, deprecated or revoked and detection mappings drift with them. ATT&CK v19 split the Enterprise Defense Evasion tactic into Stealth, which keeps ID TA0005, and Defense Impairment, with ID TA0112, so update the tactic labels in your rule metadata and dashboards to match the version you target. Name that version explicitly in the rule. Review the MITRE ATT&CK updates page for changes that affect T1220 and its mappings before each cycle, and rerun your replay tests against the rule to confirm coverage has not narrowed.
Preventive controls that reduce T1220 exposure
T1220 XSL script processing abuses a legitimate Windows capability to run script logic through XSL transforms, so the most effective preventive work limits which processes can run script content at all. The cards below pair the primary ATT&CK mitigation with a visibility control and the checks needed before either one reaches production endpoints.
Execution Prevention (M1038)
Execution Prevention is the ATT&CK mitigation most closely tied to T1220, and it asks a simple question: which programs and script hosts should be allowed to run code at all. In practice this means policy that blocks or constrains script-capable components, such as the Windows script host and XSL processing paths, for user-facing workloads where they are not needed. Before rollout, confirm with the endpoint vendor which rules can target script engines and transform-related modules, how exceptions are approved, and whether blocking breaks line-of-business software that relies on these components.
Audit (M1047)
Audit is the ATT&CK mitigation that makes T1220 visible when prevention is not yet complete. It means enabling process creation logging with command line capture and module load logging on Windows endpoints, then forwarding those events to your Wazuh or other SIEM pipeline. The trade-off is volume: command line and module events can be large, so confirm retention, indexing cost and which hosts generate the most noise before you widen collection. Test that the events for a known XSL transform actually arrive before you rely on them for alerts.
Allowlisting script-capable tools
Application control in allowlist mode is a related measure that restricts which signed binaries and scripts can execute on a host. For T1220, the useful work is inventorying which business applications legitimately invoke XSL processing, then scoping allowlists to those applications and their paths. Expect an initial period of exceptions for developer tools and admin scripts. Ask the endpoint vendor how policy is staged in audit-only mode, how exceptions are reviewed, and how changes are logged so that blocked events can be correlated with detections.
Restricting interactive script use
Many T1220 patterns depend on a user or a process being able to run script logic from a document or downloaded file. Reducing that surface means limiting macro and script execution in Office and browser contexts, and separating administrative accounts from daily browsing so that a compromised user session cannot easily launch script hosts. Confirm with your identity and endpoint teams which groups need script capability and how exceptions are tracked. Document the expected behavior so that help desk staff can distinguish a control working from a fault.
Validating controls in a cyber range
A preventive control is only trusted once its effect has been measured. In a private cyber range, test the mitigation on a clone of a representative Windows image, run approved business workflows to find breakage, then rerun the same XSL-based scenario to confirm the control blocks or logs it. Record the ATT&CK version and technique ID in each test result so the findings remain traceable after future releases. Results from this work become the evidence set that auditors and change boards ask for when a control is changed.
What the SOC does when the T1220 alert fires
The first decision on a T1220 alert is whether the XSL processing event came from an administrative or build activity that the organization expects, or from an unexpected parent process. Start by confirming the host, the logged-on user and the time window, then pull the Process Creation event for the processing binary and its parent. Check the parent process name, its signer and its path, and whether the script or stylesheet was passed as a local file, a network path or an inline argument. Confirm each of these against the asset inventory and the change calendar before anyone escalates, because an unexpected parent is the strongest signal in this alert, and it should be treated as suspicious until the owner of the host or the application team explains it.
Next, correlate the alert with what else happened on the same host in the same window. Look for Network Connection Creation events to hosts or domains the endpoint does not normally reach, and for File Creation events that write new files shortly after the processing event, particularly in user profile or temporary directories. Check Module Load events for unusual script engine or COM components loaded by the same parent. Isolation is a judgment call: isolate the host when the parent is unexplained and any outbound connection or new file is linked to it, and keep it connected when the owner confirms a documented job. Record who made the isolation decision, the criteria used, and the time it was applied. Where a forensic tool such as Velociraptor is deployed, collect volatile evidence (running processes, network connections and the script or stylesheet itself) before rebooting or remediating, and hash what you collect so the chain of custody holds.
Close the case with a written record that names the alert, the ATT&CK version the detection targets, the evidence reviewed, the decision taken and the owner who accepted it. Then feed the outcome back into tuning. Benign outcomes should become narrow, documented exclusions tied to a specific parent, path and host group, never blanket suppression of the technique. Confirmed or suspicious outcomes should be checked against the detection logic to see whether it fired early enough and whether related signals were missed. Review the exclusion list on a fixed schedule, and when the ATT&CK version changes, confirm that the detection mapping still matches the current technique definition.
Rehearsing T1220 detection in a private cyber range
The range should be an isolated network of Windows endpoints that mirror the build standard of the production estate, with no route to production systems or the internet. Sysmon is configured on each endpoint so that process creation and module load events are recorded, and those events are forwarded through an agent into Wazuh for alerting and retention. Security Onion sits alongside on a mirrored or tap-fed segment so that network context is available during triage. The goal is a logging pipeline the team can trust before any scenario runs.
- Isolated endpoints: Build two or three Windows hosts from the same image used in production, joined to a range domain that holds no real credentials.
- Sysmon coverage: Confirm the Sysmon configuration in use records process creation and image load events, and document any exclusions the team has added.
- Wazuh ingestion: Verify that agents on each host report events to the manager and that timestamps are synchronized across hosts and the manager.
- Security Onion visibility: Confirm sensor placement captures traffic from the endpoints so network context can be correlated with host events.
- Pipeline health checks: Test end to end delivery with a harmless, non-technique event and record the time from generation to appearance in the console.
Before the exercise, check that the ATT&CK version and detection strategy references used by your rules match the version your team has chosen to target.
Injects are scripted, benign emulation steps that produce the telemetry a T1220 detection should recognize, without any working attack capability. Write each inject as a timed event with an expected outcome, so the control team can compare what happened against what the detection should show. Scenarios should be described in plain language and executed by a trained facilitator using approved, range-only tooling. Keep the scenario library small and reviewed by the security lead before each run.
- Baseline window: Run a normal administrative activity for a set period first, so analysts can see what routine script-related activity looks like in their data.
- Single benign inject: Trigger one scripted action that exercises the XSL processing path on a range host, with the start time logged by the control team.
- Variant inject: Repeat the action with a different parent process or user context to test whether the rule still fires and whether the context fields are complete.
- Negative control: Run a comparable benign activity that should not match, to check for false positives.
- Timing record: Log each inject's start and end times in a shared sheet so detection latency can be measured against the agreed window.
Ask the facilitator to confirm that every inject is reviewed for safety and scope in writing before the exercise begins.
A good detection produces an alert that appears within the agreed window and carries the fields an analyst needs to decide what happened. The rule should be mapped to the ATT&CK technique and its detection strategy, and it should draw on process creation and module load telemetry rather than on a single indicator. Measure the result against the expected outcome of each inject, not only whether something fired. The control team records gaps for tuning and for logging changes.
- Alert timing: The alert appears in the Wazuh console within the window the team agreed in advance, and the time between inject and alert is recorded.
- Complete fields: The alert contains host name, user, parent and child process, command context and timestamps, without blank fields that would stall triage.
- Correlated network context: Security Onion records related traffic for the same host and time, where the scenario produces it.
- Negative control result: The benign negative control does not raise a high-severity alert, or any alert it does raise is documented for tuning.
- Gap register: Any missed inject, late alert or missing field is logged with an owner and a fix date.
Confirm the agreed detection window and field list with your security lead before the range run, since those are the criteria the exercise is judged against.
A good response is one where the analyst follows a written playbook, records triage decisions as they happen, and reaches a containment decision that the team can justify afterward. The exercise should test handoffs between the detection queue, the incident lead and the platform owner for the range host. After each run, hold a short lessons-learned session that produces specific changes to rules, logging and procedures. The range is a safe place to practice these decisions without consequences for production.
- Triage notes: The analyst records what was seen, what was ruled out and what evidence was collected, with timestamps for each step.
- Containment decision: The incident lead decides whether to isolate the range host, and records the reason and the approver.
- Escalation path: The team confirms who is notified, through which channel, and how quickly, as set out in their own runbook.
- Evidence preservation: The team checks that relevant logs and host artifacts are retained for the range case so the review is repeatable.
- Lessons learned: Convert each finding into a named change, such as a tuning task, a logging fix or a playbook update, with an owner and a review date.
Check that your incident response runbook defines the containment authority and evidence handling steps before the rehearsal, so the exercise tests the team rather than the document.
Questions SOC leads ask about T1220 detection
Should Process Creation or Module Load be the primary source for T1220 detection?
Start with Process Creation as the primary source, and use Module Load as a corroborating source. Process Creation events show which binary started, its parent, and its command line, so you can see the script host or XSL processing tool being invoked from an unexpected parent. Module Load shows which libraries a process pulled in, which helps when the invoking binary looks legitimate but loads scripting components it normally would not. The trade-off is volume and fidelity: Process Creation is available on most Windows estates once auditing is enabled, while Module Load is noisier and often needs an explicit collection policy. Confirm in your own environment that both sources are actually being ingested into Wazuh or your SIEM before you write rules that depend on them. The ATT&CK data component pages for Process Creation (DC0032) and Module Load (DC0016) describe what each source can observe, which is a good starting point for the decision.
How do we handle false positives from admin and build tooling?
Tune by parent process, host role and known change windows, not by suppressing the technique. Administrative scripts, software deployment agents and build pipelines can legitimately invoke XSL transforms, so a rule that fires on any occurrence will bury analysts. Build an allowlist from a baseline period, scoped per host group, and record who approved each entry and when it expires. Keep the allowlist narrow: match on the parent, the host role and the command pattern together, so a legitimate tool cannot become a free pass for anything it launches. Review the allowlist after every change to managed software. Document the tuning decisions so auditors can see that exceptions were reasoned and reviewed, which supports control evidence under your internal change management process.
How often should we re-test T1220 detections after an ATT&CK release?
Re-test whenever the ATT&CK version your detections target changes, and at a fixed cadence in between. MITRE publishes releases on a schedule that includes v18 on October 28, 2025, v19 on April 28, 2026 and v20 on October 13, 2026, and each release can rename, deprecate or revoke techniques and their detection content. Treat each release as a trigger to check the technique page, its detection strategies and its mitigations against your rules. Re-run your validation tests after any change to the detection logic, the logging configuration or the endpoint agent, because those changes can silently break coverage. Your cadence should match your change volume and your regulator expectations, which you should confirm with your compliance lead. Record the ATT&CK version in each rule's metadata so drift is visible.
How do we map T1220 detections to DET IDs in ATT&CK v18 and later?
Map each rule to the detection strategy IDs (DET IDs) and analytics listed for the technique in the ATT&CK version you target, then cite the data component IDs your rule depends on. ATT&CK v18, released October 28, 2025, replaced the detections on technique pages with detection strategies and analytics, so older rule mappings written against free-text detection sections need to be re-keyed. Keep a mapping table with four columns: your rule identifier, the DET ID, the analytic or telemetry source, and the ATT&CK version. Check each DET ID against the current version after every release, because IDs and wording can change. The STIX bundles in the attack-stix-data repository are the most reliable way to automate this check, since they are published per domain and version.
What should we confirm about Execution Prevention in our own estate?
Confirm which hosts enforce it, in which mode, and whether the policy covers the script and XSL processing paths you care about. The ATT&CK mitigation Execution Prevention (M1038) describes blocking execution of untrusted or unexpected code, but how it applies depends on your endpoint product and policy configuration. Ask your team to verify the following:
- Which Windows host groups have the control enforced versus audit-only
- Whether exceptions exist for script hosts or XSL-capable tools, and who approved them
- Whether blocked and audited events reach your SIEM with enough context to correlate
Do not assume the control is active because it is licensed or installed. Test it in the cyber range with a benign, controlled sample before relying on it in production.
Can we rehearse T1220 detection and response in a private cyber range?
Yes, and a private range is the safest place to validate the rule, the alert path and the analyst response. DeployOpen runs private cyber ranges and security training, and a range lets you generate controlled, benign test activity against isolated Windows hosts while your Wazuh or Security Onion pipeline records what it sees. Define success before the exercise: the expected events, the expected alert, the time to triage and the containment steps. Record gaps, such as missing Module Load events or a rule that fires on the wrong parent, and feed them back into tuning. Keep exercise artifacts so the results can serve as evidence for internal reviews and compliance readiness work. Scope, deliverables and timelines are agreed in writing before any work starts.
Can our own team maintain T1220 detections without outside help?
Many SOC teams can maintain these detections in-house once the telemetry and the process are in place, but the first build and validation usually benefit from specialist time. The ongoing work includes tuning allowlists, re-keying mappings after ATT&CK releases, checking that logging still works after agent updates and rerunning validation tests. Decide who owns each of those tasks before you start, and whether the work is one-time or recurring. DeployOpen offers fixed-scope engagements and ongoing retainers for support, upgrades and continuous testing, and the split between internal and external work should be written into the scope. Ask any provider to state which tasks they hand back to your team at the end of the engagement.
Primary sources for T1220 and ATT&CK versioning
Start with the MITRE ATT&CK tactic page for Stealth, MITRE ATT&CK tactic TA0005: Stealth, because it defines the tactic that T1220 XSL Script Processing sits under and sets the scope your detection content should be written against. Read the tactic description alongside the technique page for T1220 itself, and confirm which tactics the technique currently lists, since a technique can belong to more than one tactic and the mapping may differ between versions. Record the technique ID and the sub-technique status in your detection documentation so that a later review can see exactly what was covered.
Pin the ATT&CK version before you write or tune any rule. The MITRE ATT&CK updates page lists each release, and the v18 and v19 release notes are the two to read first for this topic. The v18 notes explain that technique pages moved from embedded detections to detection strategies and analytics, and that data components were substantially revised. The v19 notes record the split of Defense Evasion into Stealth (TA0005) and Defense Impairment (TA0112), which changes how tactic-based reports and dashboards group this technique. Ask your team to state the target version in every rule header and mapping file.
For machine-readable mappings, use the enterprise-attack 20.0 STIX bundle published in the mitre-attack/attack-stix-data repository. Parse it to confirm T1220 data component references, related mitigations and any revocations before you commit a detection to your SIEM or Wazuh ruleset. Re-run that check whenever you move to a newer release, because revoked or renamed objects can silently break coverage reports. Assign one owner to keep the bundle version and the rule mappings in step.
How DeployOpen builds T1220 detections and range exercises
DeployOpen approaches T1220 XSL script processing as a fixed-scope engagement inside your own Windows estate and monitoring stack. The work turns the technique into written detection logic, tested telemetry paths and rehearsed response steps that your team can operate and audit.
How we scope
- Confirm which Windows endpoint groups, servers and monitored user populations the T1220 detection will cover.
- Record which telemetry sources are in place, such as Process Creation and Module Load, and which must be enabled first.
- Agree in writing which ATT&CK version and detection strategy identifiers the detection will be mapped to.
How we build
- Write detection logic in open formats such as Sigma and deploy it to Wazuh or Security Onion according to the agreed scope.
- Tune the rule against known-good Windows application behavior so that analysts receive reviewable alerts.
- Map the detection to the Execution Prevention mitigation and document which controls are configured and which are advisory.
How we hand over
- Deliver the rule set, configuration files and tuning notes with a clear record of assumptions and known gaps.
- Run a private cyber range exercise that replays benign and simulated T1220 activity so your analysts can see alerts fire.
- Provide a runbook covering triage, escalation and evidence collection for the T1220 detection.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after the fixed-scope work closes.
- Re-validate the detection when ATT&CK releases rename, deprecate or revoke related techniques or sub-techniques.
- Confirm with your team which support hours, change process and escalation path apply before the scope is signed.
