---
{
  "title": "XSL Script Processing",
  "summary": "XSL script processing can turn stylesheet content into executable behavior through supported transformation features.",
  "topic": "soc",
  "level": "Intermediate",
  "updated": "2026-10-12",
  "published": "2026-10-04",
  "units": [
    6
  ],
  "aliases": [
    "T1220"
  ],
  "sources": [
    {
      "title": "MITRE ATT&CK T1220: XSL Script Processing",
      "url": "https://attack.mitre.org/techniques/T1220"
    }
  ],
  "editorialVersion": 2
}
---

## What it means

XSL script processing can turn stylesheet content into executable behavior through supported transformation features. The parser or utility's capabilities determine the boundary.


## An investigation example

A trusted transformation utility reads an unexpected stylesheet and is followed by unrelated system activity.

## Evidence to examine

Review stylesheet content, processor configuration, input origin, command arguments, and resulting processes.

## A common analytical pitfall

A file presented as formatting data is not necessarily inert when its processor supports active functionality.

## Response considerations

Preserve the stylesheet and processing evidence and restrict unnecessary execution features in transformation workflows.


## Transformation features can cross into execution

XSL-related processing transforms structured data using stylesheet instructions. Depending on the processor and configuration, supported features may include script or extension behavior that goes beyond a simple visual transformation. An intruder may misuse that capability to run unauthorized content through an otherwise legitimate component. Not every stylesheet or XML transformation executes code.

The exact processor, platform, version, and security settings matter. A stylesheet reference or a transformation process establishes only part of the chain. Investigators should identify the input, processor invocation, relevant features, and resulting behavior before describing successful execution. Legitimate reporting and data-conversion applications use transformations routinely.

## A fictional unexpected stylesheet

An academy's endpoint records show a transformation component consuming a newly downloaded stylesheet, followed by an unusual child process. Analysts preserve the stylesheet, source document, invocation context, account, and process relationship. They compare the sequence with the application's expected reporting workflow and inspect content through an approved analysis route.

Do not run the recovered transformation on a personal computer to see its output. Untrusted stylesheet material can be active in a capable processor. A static reference may show intended behavior, while runtime evidence establishes whether the relevant feature was available and actually used. Keep those claims separate.

## Draw the transformation boundary

Create a fictional diagram with source data, stylesheet, processor, and output. Mark which inputs are trusted and whether extensions or scripts are permitted. Explain the evidence needed to demonstrate a transition from transformation to process execution. A paper example or harmless restricted processor is sufficient.

Defensive review should disable unnecessary active features where supported and validate the impact on legitimate workflows. Protect input sources and execution policy as well as the processor binary. A trusted transformation tool does not automatically make every stylesheet safe, and blocking one file does not resolve the access path that supplied it.

## Related concepts

- [[mitre-attack]]
- [[logs-and-telemetry]]
- [[incident-response]]
- [[trusted-developer-utilities-proxy-execution]]
- [[windows-management-instrumentation]]
- [[system-binary-proxy-execution]]