Detecting T1221 Template injection

How template injection lets a document load attacker content

T1221 Template injection lets an adversary hide malicious content inside a document or template that a trusted application already opens, so the payload arrives through a feature the user expects rather than through an obvious download. For Windows fleets, the defender's concern is that document and template features in office and related applications can fetch remote content when a file is opened or rendered. That behavior can make a benign-looking file pull in material from a location the organization never approved, and the request may look like ordinary application traffic. This page covers the detection of that behavior on Windows, the mitigations ATT&CK maps to it, and how to rehearse the detection in a private cyber range.

Intrusions that use this technique tend to appear early in a sequence, where a user receives a document from an external or unexpected source and the application reaches out after the file is opened. The observable steps are therefore a parent office application spawning or reaching a network destination it does not normally contact, combined with a template or relationship reference to a remote target. This page targets Enterprise ATT&CK version 20.0. Before you map detections or control coverage, confirm the tactic placement against that version's technique page, because ATT&CK v19 split the former Defense Evasion tactic into Stealth (TA0005) and Defense Impairment (TA0112). Technique placement can change between versions, so record the version your detection content was written against.

Which Windows telemetry reveals template injection

This table maps each Windows telemetry source to the ATT&CK data component it supports for T1221 Template Injection, the signal to look for and the open-source path to collect it. Check the detection strategies for this technique in the v20 STIX bundle before you finalize any mapping, then confirm each data gap in your own environment. The main takeaway is that parent-child process lineage and outbound connections from document-handling applications carry most of the signal.

Data component	Signal to look for	Collection path	Data gap to confirm
Process Creation (DC0032)	Document-handling application starting a child process or script host, with parent process recorded	Wazuh agent event collection, or Sysmon telemetry forwarded to Security Onion	Process creation auditing includes command line and parent process on every endpoint
Network Connection Creation (DC0082)	Word processor or spreadsheet process opening an outbound connection to an unexpected remote host	Sysmon network events in Security Onion, with Zeek connection logs for corroboration	Endpoint network events are logged, not only perimeter flow data
Command Execution (DC0064)	Command interpreter or script host invoked by a document application, with arguments captured	Wazuh collection of Windows event logs, or a Velociraptor artifact for process history	Command-line capture is enabled, since arguments are blind without it
Parent process lineage	Chain linking an office document application to a child process within a short time window	Velociraptor hunts over stored process history across endpoints	Endpoint retention covers the window needed to correlate full process chains
Endpoint coverage	Office applications present and monitored on every managed workstation and remote device	Wazuh agent inventory and Velociraptor client inventory compared against the asset register	Agent coverage includes remote users, contractors and unmanaged or virtual desktops

Detection ideas for template injection on Windows

The four ideas below describe detection logic in words for T1221 Template injection on Windows. Each one pairs a process or network signal with a baseline of what normal office behavior looks like, so analysts can separate abuse from approved integrations before any rule reaches production.

Office parent spawning unexpected children

Office applications normally open documents and call their own helpers. Alert when a Word, Excel or PowerPoint process creates a script host, a command interpreter or an unsigned binary that has no record in your approved integration list. Under the parent-child pair is the signal, so log the full parent image path, child image path and the user context from Process Creation events. Tune by allowlisting signed add-in hosts and line-of-business macros by hash and path. Expected false positives come from approved add-ins, document automation tools and print helpers. Place the rule in Wazuh first, using Sysmon process events, then export the logic to Sigma for other log platforms.

Office process beaconing before execution

Correlate a network connection from an office process to an external host with a process creation event on the same endpoint within a short window. The sequence matters more than either event alone, because office software makes some outbound connections on its own. Security Onion can supply the network side from Zeek connection logs, while the endpoint side comes from Process Creation telemetry forwarded to Wazuh. Tune the correlation window in a cyber range first, then narrow it by destination category. Expected false positives include update services, cloud document sync and licensing checks, so maintain a list of approved destinations per application.

Template retrieval from unapproved destinations

Flag documents or templates that cause an office process to fetch a remote resource from a domain your organization does not manage or approve. The indicator is the destination, not the document content. Security Onion, using Zeek HTTP and DNS logs, is the natural home for this rule because it sees traffic across the segment, including endpoints that never report to Wazuh. Tune by maintaining an allowlist of approved template repositories, internal file shares and SaaS document services. Expected false positives come from approved template libraries, branded document portals and certificate or font downloads, so review the allowlist with the business owners of those services.

Rule versioning against ATT&CK 20.0

Detection logic for T1221 should name the ATT&CK version it targets, which for these pages is Enterprise ATT&CK 20.0. Releases can rename, deprecate or revoke techniques, and the tactic assignment for a technique can change between versions, so a Sigma rule tagged only with a technique ID can drift out of date. Record the version in the rule metadata, keep Wazuh decoders and Security Onion rules in the same change record, and confirm the mapping against the release notes whenever you upgrade ATT&CK content. Expect the review work to recur with each new release.

Tuning template injection rules without flooding the SOC

Do not enable T1221 Template injection alerts across the estate until you have a baseline of how Office documents, templates and their outbound connections normally behave in each department or device group. Start by sampling several weeks of Process Creation and Network Connection Creation telemetry from representative Windows endpoints, grouped by business unit, and record which parent applications launch which child processes, which template locations are opened, and which remote destinations are contacted when a document renders. Finance, legal and engineering often differ sharply here, so one global threshold will either bury analysts or miss the group that behaves differently. Confirm the baseline window with your own change calendar, because month-end, template releases and software rollouts will distort it if they fall inside the sample. Record the baseline as a versioned artifact so later tuning can be compared against it.

Suppress known integrations only through documented exceptions that name the owner, the exact process path or signing identity, the destination, the business reason and an expiry date. Avoid broad exclusions on the parent application alone, since that removes visibility into the very behavior the rule exists to catch. Review exceptions on a fixed cadence, for example quarterly, and retire any whose integration no longer exists. Correlate Process Creation and Network Connection Creation events from the same host within a short window, keyed on the host and the process identifier, so that one suspicious document opening produces a single grouped alert rather than one per child process and per connection. Your SIEM or Wazuh correlation logic should be validated in the cyber range before production, and you should confirm how your chosen tooling handles time skew and process identifier reuse.

Keep a change record for every tuning decision: the rule version, the ATT&CK version it targets, the baseline evidence, the exception approved, the approver, the test result from the cyber range and the review date. This record is what lets an auditor or incident responder see why an alert was silenced and whether that decision still holds. Ask your SOC lead to define an alert volume review after each tuning change, so that a rule that suddenly quiets down is investigated as carefully as one that becomes noisy. Treat the record as part of the detection content itself, stored alongside the Sigma rule in version control.

How to validate template injection detections in a lab

This sequence shows whether a Template Injection detection for T1221 fires on the right telemetry, within the expected window, and reaches the people who must act on it. Each step produces a record that proves the detection works and can be repeated after any change.

Agree the emulation scope in writing
The detection owner, the emulation lead and the lab owner agree in writing which behavior will be emulated, on which Windows test hosts, under which ATT&CK version, and who approves the run. The scope names the rule under test and the data components it relies on, such as Process Creation and Network Connection Creation. The step is done when every party has signed off the scope and the rollback path, and the approval is stored with the test record.
Run an approved emulation in isolation
The emulation lead runs the agreed behavior on an isolated lab host or cyber range segment that has no route to production systems or live user data. The run should be scripted or documented so it can be repeated exactly after a rule change. The step is done when the run ends, the start and stop times are logged, and the host is returned to its baseline state.
Confirm expected process and network events
The analyst checks the Wazuh or other SIEM index for the test host and confirms that the process creation and network connection events generated by the emulation were collected and parsed with the expected fields. Missing fields, dropped events or agent gaps are recorded as findings before any rule verdict is drawn. The step is done when every expected event appears in the collected data, or each gap has a ticket and an owner.
Confirm the rule fired within the window
The analyst compares the event timestamps with the time the rule produced an alert, using the expected detection window defined in the test plan. A rule that fires outside the window, fires on unrelated activity, or does not fire at all is marked as a failed test. The step is done when the alert is linked to the emulated events and the latency is written down.
Check alert routing to the right queue
The on-call or SOC lead confirms that the alert reached the intended queue, case management item or notification channel, with the right severity and the host context an analyst needs. Routing errors, such as alerts landing in an unmonitored index or a generic queue, are logged as defects. The step is done when the alert is visible to the assigned responder and the routing path is documented.
Record timestamps, event IDs and analyst notes
The test lead captures the emulation start and end times, the alert timestamps, the event identifiers, the rule name and version, the ATT&CK version and detection strategy references, and the analyst notes on what was seen. The record is stored in the evidence repository so an auditor or reviewer can trace the result. The step is done when the record is complete and reviewed by someone other than the analyst who ran the test.
Re-test after every rule change
Every change to the rule logic, its fields, the parsing pipeline or the agent configuration triggers the same sequence again against the same emulated behavior. Results are compared with the previous baseline to detect regressions. The step is done when the re-test passes or the change is rolled back, and the new record replaces the old one as the current baseline. Confirm the re-test cadence with your own change management process.

Mitigations that reduce template injection exposure

ATT&CK maps two mitigations to T1221 Template injection: Disable or Remove Feature or Program and User Training. Together they reduce the number of template features an attacker can use and make suspicious document behavior more likely to be reported. Each control needs a named owner, a documented review, and records that an auditor can sample.

Inventory template-capable features

Start by listing every document application, plugin and internal tool in your estate that can load a template, fetch remote content or update document references when opened. Assign an owner to each entry and record which business process depends on it. Check the list against your current software builds, because feature names and defaults change between releases. This inventory is the baseline for every later decision under the Disable or Remove Feature or Program mitigation, so keep it under change control.

Disable features no process needs

For each feature on the inventory, ask whether a documented business process still requires it. Where none does, disable or remove it through your standard change process, and apply the change with your configuration management tooling rather than by hand. Where a feature must stay, record a time-limited exception with a named approver and a review date. Confirm the exact settings with the vendor documentation for each software version you run, since the names and locations vary.

Review integrations and add-ins

Document automation, document management systems, SaaS connectors and browser or office add-ins can reintroduce template behavior even after the core feature is disabled. Review each integration for the same capabilities and check whether its vendor supports the setting you want to apply. Ask vendors to state in writing which template or remote-content behaviors their product uses. Re-review the list whenever an integration is added, upgraded or replaced.

Keep configuration evidence

Keep the approved baseline, the change tickets that applied it, and the results of periodic checks that the setting still holds on sampled endpoints. Record every exception with its owner, reason, compensating control and expiry date. An assessor will usually ask for a sample of endpoints and the matching change records, so store them in a form that is easy to sample. Use the enterprise-attack bundle for your targeted ATT&CK version to tie each record to the mitigation it supports.

Role-based user training

Train users who open documents from outside the organization, such as finance, HR, legal and procurement staff. The core message is that an unexpected prompt to update links, enable content or download a template is a reason to stop and report, not to click through. Use examples from your own document workflows and include a clear reporting path to the security team. Refresh the material when your document tools change, because the prompts users see change with them.

Record training and reporting outcomes

Keep curriculum versions, attendance or completion records, and dated sign-off by role. Track how many reports of unexpected document prompts reached the security team and what triage found, so you can show that the training changes behavior. Confirm with your compliance lead which training records your framework requires and how long they must be retained. Map each record to the User Training mitigation so the evidence set is complete.

Triage and response when a template injection alert fires

When a T1221 Template injection alert fires on Windows, the first job is to establish who and what is involved before anyone isolates a machine. Confirm the originating user account and host from the Process Creation event, then identify the parent application that launched the process and the remote destination recorded in the Network Connection Creation event. Ask the business owner of that application whether a document-driven workflow to that destination is approved. If the parent application, the destination and the user's role all line up with a documented process, close the alert as benign and record the approval reference so the same pattern does not reopen the case. If any of the three does not match, treat the alert as a suspected intrusion and preserve evidence before changing anything: export the relevant endpoint logs, the proxy or firewall records for the session, and the document or template reference if the Office or document handling tooling logged one. Record hashes and timestamps, and keep the original artifacts unmodified.

Containment should be proportionate to what the evidence shows. Isolating the endpoint through your EDR or network access control platform is the right step when the parent application is unexpected, the destination is uncategorized or newly registered, or the user cannot explain the document. Blocking the destination at the proxy is appropriate when the same domain appears on other hosts, but confirm the block does not break an approved business process first. Escalate to your incident response lead when the same destination or parent process appears on multiple endpoints, when the user account shows other anomalies, or when a credential or token may have been exposed. Coordinate with the identity team to review sign-in activity and consider session revocation for the affected account, and with the email team to search for the message or attachment that delivered the document, because the same lure is often sent to several users. Agree in advance who makes the isolation decision out of hours, since delay usually costs more than a false positive.

Close each case with a short written review that answers three questions: was the alert true or benign, what evidence confirmed it, and what should change. Feed benign outcomes back into rule tuning by narrowing the allowlist to the specific parent application, destination and user group, not to a broad exclusion, and record the change in your detection-as-code repository so it can be reviewed. Feed confirmed outcomes into user awareness, using the affected user's situation as the basis for a short, targeted refresher on the User Training mitigation for this technique. Confirm with your vendor or your own tuning standard how each change is tested against recent telemetry before it is promoted. Retain the case record, the evidence list and the rule change history together, so an auditor or incident reviewer can trace each decision back to the alert.

Rehearsing template injection detection in a private cyber range

This tab covers a private Windows endpoint segment with office applications installed, Sysmon or equivalent process telemetry, and agent-based forwarding of Windows event logs to Wazuh or Security Onion. The range should contain no production data and no route to production networks. Scenarios are illustrative: an office document opened from a test share spawns an unexpected child process, and a benign business template is opened as a control so analysts learn what normal looks like.

Illustrative scenario: a document launches a child process that an office application does not normally start, recorded through Process Creation telemetry.
Control scenario: a routine business template opens with ordinary child activity, so false positives can be measured.
Good detection: the Process Creation event reaches the SIEM within the window the team has agreed, with parent, child and command context intact.
Good enrichment: the alert carries the host, user, parent image and file path so triage does not start from raw logs.
Evidence to keep: timestamps from the endpoint, the agent and the SIEM, so latency can be measured.

Confirm the agent version, log pipeline and Sysmon configuration against the vendor documentation for your own build before the first run.

Questions SOC leads and detection engineers ask about template injection

How do we handle legitimate template-driven integrations without flooding the SOC?

Start by inventorying every business application, document generator and build job that legitimately spawns child processes or opens outbound connections. For each one, record the parent process, the service account, the expected destinations and the schedule. Turn that inventory into allow conditions in your Sigma or Wazuh rules, scoped to a named service account and host group. Keep path-based exclusions narrow and review them at each change window. Test every exclusion against the rehearsal scenarios in your cyber range so you can see what it hides as well as what it reduces. Ownership of the inventory should sit with the team that operates each integration, with the SOC approving changes.

Are Sigma rules enough without network telemetry for template injection?

Sigma rules on process creation events can catch much of the suspicious behavior, but they are rarely enough on their own. Process creation shows parent-child relationships and command context, while network connection creation confirms whether the process reached out to a destination. Without the second signal, analysts lose the corroboration step, and false positives or missed follow-on activity become more likely. Confirm that your Windows endpoints forward both event types into your pipeline, and check whether Zeek or Suricata sensors can see the relevant egress paths. If network sensors are missing for some hosts, document that gap and treat those hosts as lower confidence until it is closed.

How do we confirm the tactic and mitigations for our ATT&CK version?

Check the T1221 technique page for the exact ATT&CK version your detection mapping targets, because releases can rename, deprecate or revoke techniques. Recent releases were v18 on October 28, 2025, v19 on April 28, 2026 and v20 on October 13, 2026. In v19, MITRE split the Enterprise Defense Evasion tactic into Stealth, which keeps ID TA0005, and Defense Impairment, which has ID TA0112. Confirm which tactic T1221 is listed under in your version, and record the version number beside every rule. For mitigations, verify the entries for Disable or Remove Feature or Program and User Training on that same page. The ATT&CK updates page lists each release and its changes, so review it before each version bump.

How often should we re-test template injection detections after rule changes?

Re-test after every rule change, every telemetry change and every ATT&CK version update. Telemetry changes include agent upgrades, new log sources, altered audit policies and changes to forwarding pipelines, because any of them can silently stop events from arriving. Schedule regression runs in your cyber range on a fixed cadence as well, so drift is caught even when no one has changed anything. The cadence should be set by your change management process and your risk appetite, and your team should confirm it with the people who own the rules and the pipeline. Record each run with the rule version, the scenario, the result and the analyst who reviewed the alert.

How do we measure detection coverage for T1221 over time?

Track coverage per technique and sub-technique, per data source and per host group, keyed to the ATT&CK ID and version. Useful measures include which rules are mapped to T1221, whether each required log source is healthy, the date of the last successful rehearsal, the time from alert to triage, and the false positive rate for each rule. Store the mapping as version-controlled data so changes are visible in review. Coverage should describe what you can detect with evidence from a rehearsal, not what a rule is intended to catch. Review the numbers on a set schedule with the SOC lead and the detection engineer, and close gaps through the same change process used for rules.

Who should own template injection detections in our organization?

Name three owners: one for the detection rule, one for the telemetry pipeline that feeds it, and one who approves changes. The detection owner is usually a detection engineer, the telemetry owner sits with the platform or endpoint team, and the approver is often the SOC lead. Effort depends on how many template-driven applications, log sources and environments are in scope, so ask any provider for a written scope that lists them. DeployOpen plans and implements self-hosted open-source platforms, runs security testing and private cyber ranges, and works on fixed-scope engagements agreed in writing before work starts. Ongoing tuning and continuous testing can be covered by a retainer, which recurs, while the initial build is one-time.

Can our own team run the cyber range rehearsal, or do we need outside help?

Your team can run rehearsals if it has a private range, a working log pipeline, a written scenario and people who can review the resulting alerts. Outside help is most useful for the first build of the range, for designing scenarios that match your environment, and for independent validation of results. The cost components are the range infrastructure, the time of the people who build and run scenarios, and any external support. Ask any provider to state in writing what is one-time, such as range build and scenario design, and what recurs, such as scheduled runs and retainer support. DeployOpen runs private cyber ranges and security training, so it can support either model, and the scope should be confirmed before work begins.

How DeployOpen builds template injection detections and range exercises

DeployOpen approaches T1221 Template injection as a scoped engineering task inside your own environment. We plan, build and document detections on your Windows telemetry, then rehearse them in a private cyber range before anything reaches production.

How we scope

Confirm which Windows endpoints, document-handling applications and telemetry sources fall within the written scope for T1221.
Record the ATT&CK version the detections target, since releases can rename or revoke techniques.
Agree in writing which mitigations, such as User Training and Disable or Remove Feature or Program, are in or out of scope.

How we build

Map Process Creation and Network Connection Creation telemetry to detection logic, described in plain words and expressed as Sigma rules where the platform supports them.
Deploy and tune the detections on your open-source stack, such as Wazuh, Security Onion, Suricata or Zeek, inside your own infrastructure.
Test false-positive behavior against your normal Office and document-handling activity before tuning thresholds and allow-lists.

How we hand over

Deliver detection documentation listing data sources, logic, known gaps and the ATT&CK version each rule targets.
Provide a cyber range exercise plan with expected alerts, so your analysts can validate detections and response steps.
Hand over runbooks for triage and response, and record the evidence needed for internal review or a compliance assessment.

How we support

Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
Ongoing support, upgrades and continuous testing are available as a retainer if your detections need regular review.
Confirm with your auditors or certification bodies which evidence they accept, since DeployOpen prepares evidence but does not issue assessments.

T1221 Template injection