Some of the scripts that ship with Windows are signed by Microsoft. That makes them trusted, and it also makes them useful to someone who wants to run something else without raising alarms. MITRE ATT&CK tracks this as T1216, System Script Proxy Execution, in the Stealth tactic. The platform is Windows.
How attackers use it
MITRE explains that adversaries may use trusted scripts, often signed with certificates, to proxy the execution of malicious files. Several Microsoft signed scripts, either downloaded from Microsoft or present by default, can start other files. That behavior may let malicious files bypass application control and signature validation on systems.
The idea is the same one behind many living off the land techniques. The first process in the chain is trusted, so tools that weigh trust heavily may not look further.
There are two sub-techniques documented under this one:
- PubPrn (T1216.001), a script that publishes a printer to Active Directory and can be abused to run remote scriptlets on older systems.
- SyncAppvPublishingServer (T1216.002), an App-V script that can proxy PowerShell commands.
How to detect it
The MITRE detection strategy centers on execution of Microsoft signed scripts, naming pubprn.vbs, and script hosts such as wscript.exe and cscript.exe, that are used to proxy untrusted or external binaries. The behavior is found through command line, process lineage and child process spawning, with unsigned payloads running under a signed parent.
What that means for logging:
- Collect process creation events with full command lines, such as Sysmon event ID 1 or Windows Security event 4688.
- Look at who the parent is. A script host launching something that is not a script is the interesting case.
- Alert on signed scripts appearing in command lines in places where they never appeared before.
How to reduce the risk
MITRE lists one mitigation, execution prevention. Some of these signed scripts are not needed in a given environment. Where that holds, configure application control to block them.
A practical way to start is to look at which of these scripts have ever run in your environment. If the answer is none, blocking costs nothing.
Check your own environment
- Is application control in enforcement mode, or only audit mode?
- Do your rules treat Microsoft signed scripts as automatically allowed?
- Is command line auditing on for process creation?
This read-only command shows whether command line capture is enabled for Security event 4688 on Windows (cmd.exe):
reg query HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\Audit /v ProcessCreationIncludeCmdLine_Enabled
A value of 0x1 means command lines are included.
Where to start
Start by asking a narrow question: which signed scripts and script hosts have run in the last 90 days? Pull process creation logs and group them by script name. In most environments the answer is a handful of management scripts, and the signed scripts that attackers favor will not appear at all.
For each script that never appears, write an application control rule that blocks it, test the rule in audit mode, and enforce it once the audit log stays quiet. For each one that does appear, record the parent process and arguments, then alert on departures. That gives you both prevention and detection from the same data.
Quick check
Why can a signed script defeat some application control setups?
Rules that allow anything signed by Microsoft will also allow the script, even though the script can be directed to run something else.
Sources
- MITRE ATT&CK, T1216: https://attack.mitre.org/techniques/T1216
