Live Active security incident? Get immediate response
MITRE ATT&CK® Analytic

AN1288: Analytic 1288

Execution of Microsoft-signed scripts (e.g., pubprn.vbs, installutil.exe, wscript.exe, cscript.exe) used to proxy execution of untrusted or external binaries. Behavior is detected through command-line process lineage, child process spawning, and unsigned payload execution from signed parent.

EnterpriseAN1288AnalyticObject v1.0 Modified
Glexia's Take

Analyst context for executives and security teams

Analyst confidence High

This analytic focuses on Windows cases where Microsoft-signed scripting or utility hosts are used as a proxy to run untrusted or external code. For leaders, the importance is not the specific tool name; it is that trusted, signed Windows components can blur the line between legitimate administration and suspicious execution. Coverage depends heavily on whether the SOC can see process command lines, parent/child relationships, and whether spawned payloads are signed or unsigned.

Executive priority

Prioritize this as a control-validation and evidence question for Windows environments: can the organization distinguish normal use of signed Microsoft script hosts and utilities from signed-parent execution of unsigned payloads? The answer affects incident triage speed, audit evidence for endpoint monitoring, and resilience against abuse of trusted system components. This should inform endpoint telemetry investment, detection engineering priorities, and incident response playbooks for suspicious script or utility execution.

Technical view

Validate detection logic on Windows process creation data that includes command-line arguments, process lineage, child process spawning, and code-signing status of executed payloads. The supplied analytic describes Microsoft-signed scripts or utilities such as pubprn.vbs, installutil.exe, wscript.exe, and cscript.exe acting as parent execution vehicles for untrusted or external binaries. SOC teams should review baselines for legitimate administrative and software deployment activity so alerts can focus on unusual parent-child chains, suspicious command-line patterns, and unsigned child payloads launched from signed parents.

Likely telemetry

  • Windows process creation events
  • Command-line arguments for parent and child processes
  • Parent/child process lineage
  • Executable path and file metadata
  • Code-signing or signature validation status for parent and child binaries

Detection direction

  • Confirm endpoint logging captures full command lines and parent/child process relationships; without these, this analytic is materially weakened.
  • Tune for signed Microsoft parent processes spawning unsigned or untrusted payloads, especially where the command line indicates proxy execution rather than routine administration.
  • Baseline legitimate software deployment, scripting, and administrative workflows to reduce false positives from normal use of Windows script hosts and utilities.
  • Investigate unusual execution paths, external or user-writable payload locations, and unexpected child processes from signed scripting or utility parents when that telemetry is available.
  • Because no official detection logic is supplied, treat this as a detection-design requirement rather than a ready-made rule.

Mitigation priorities

  • Ensure Windows endpoint telemetry is enabled and retained for process creation, command line, lineage, and file signature metadata.
  • Restrict or govern unnecessary use of script hosts and administrative utilities where business processes allow.
  • Apply application control or execution policy concepts to limit unsigned or untrusted payload execution, especially from user-writable locations.
  • Document approved administrative uses of Microsoft-signed scripting and utility hosts so SOC and IR teams can distinguish expected activity from suspicious proxy execution.
  • Test incident response procedures for triaging signed-parent to unsigned-child execution chains.
Analyst notes and limits

No tactic, technique relationship, or official detection block was supplied. The strongest defensible interpretation is a Windows detection analytic for suspicious proxy execution through Microsoft-signed components, using command-line lineage, child process behavior, and unsigned payload execution as the main evidence.

This take is limited to the supplied ATT&CK analytic fields and one external MITRE reference. There are no supplied relationships, no official detection query, no procedure examples, and no attribution or exploitation context. Local baselines are required to determine what is abnormal in a specific environment.

Official MITRE ATT&CK definition

Analytic 1288

Execution of Microsoft-signed scripts (e.g., pubprn.vbs, installutil.exe, wscript.exe, cscript.exe) used to proxy execution of untrusted or external binaries. Behavior is detected through command-line process lineage, child process spawning, and unsigned payload execution from signed parent.

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

How security teams should use this page

Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.

Relationship explorer

All related ATT&CK context

No relationships are available in the current normalized data for this object.

Change history

Object version and sync metadata

The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .

ATT&CK release
19.1
Object version
1.0
Created
Modified
Raw hash
0d27451edfce569a...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.0 Current bundle 0d27451edfce…
Raw source

Mirrored ATT&CK source object

The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.

Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [1]
    mitre-attack AN1288
    Open source URL
Source and licensing

Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.