D3-SEA Script Execution Analysis: What It Detects, Which ATT&CK Techniques It Counters and How to Verify It

Scripts are the easiest way to run attacker logic on a host without dropping a binary, and obfuscation means a script on disk rarely looks like what actually runs. MITRE D3FEND names the defence D3-SEA Script Execution Analysis, a Detect tactic countermeasure under Process Analysis (D3-PA), defined as analysing the execution of a script to detect unauthorised user activity. Its distinctive idea is to inspect commands inside the scripting engine at the moment they execute, rather than scanning files. This card covers the artefact it analyses, why D3FEND lists no ATT&CK techniques for it, where the capability exists in operating systems and security products, and how to verify it. It is written for detection engineers and endpoint owners.

Key takeaways

• The artefact is the script process. D3FEND's Script Application Process (also Script Process) is an application process interpreting an executable script.
• Hook the engine, not the file. D3FEND describes host software that hooks into a scripting engine to intercept commands before execution and block harmful ones, using pattern matching for commands and hash comparison for script files.
• No direct ATT&CK mapping. D3FEND currently lists no ATT&CK techniques for D3-SEA, because no technique is modelled against the Script Application Process artefact.
• Windows gives you the hooks. AMSI passes de-obfuscated content from PowerShell, Windows Script Host, JavaScript, VBScript and Office VBA macros to the registered antimalware engine; PowerShell script block logging (event 4104) records what ran.
• Lists go stale. D3FEND's own consideration: lists of unauthorised scripts and regular expressions must be kept current to detect new threats.

D3-SEA at a glance

How it works

The patent D3FEND cites describes the mechanism in detail. It identifies host processes that may load a hosted scripting engine, injects an interface module into those processes, hooks methods of the scripting engine so commands are intercepted before they execute, and consults a kernel-mode threat detection component to decide whether to block. MITRE's analysis notes that regular expression checks can apply to both script files and interactively typed commands, and that a script file's hash can be compared with hashes of known malicious scripts.

The reason to analyse inside the engine is obfuscation. Microsoft's AMSI documentation makes the point directly: a script may pass through several rounds of de-obfuscation, but the scripting engine must eventually receive plain code, and that is where the scan happens, even for code generated at runtime. Microsoft shows the progression from a simple string signature to concatenation, Base64 and XOR encoding, which file emulation struggles to follow, and contrasts it with scanning the plain text passed to Invoke-Expression.

Three layers of script visibility

ATT&CK techniques and D3-SEA

D3FEND's page for D3-SEA lists no related ATT&CK techniques. Its relations are inferred from shared digital artefacts, and no ATT&CK technique is modelled as acting on the Script Application Process artefact. That is a gap in the model, not evidence that script attacks are out of scope.

In NHI Mgmt Group's view, and not as a D3FEND mapping, the obvious targets are Command and Scripting Interpreter (T1059), particularly PowerShell (T1059.001), Visual Basic (T1059.005) and JavaScript (T1059.007), and Command Obfuscation (T1027.010), which engine-level inspection is designed to see through. D3FEND does relate T1059 to the Executable Script artefact (the script a script process interprets), which sits beside D3-SEA's artefact. See the T1059 Command and Scripting Interpreter Defensive Guide for attacker behaviour and mitigations.

Where it is implemented

Product classes implementing D3-SEA include antimalware engines registered as AMSI providers, endpoint detection and response agents with script inspection, and SIEM analytics over script block logs. Microsoft notes that from Windows 10 version 1903, an AMSI provider DLL that is not Authenticode-signed may not be loaded, depending on configuration. For PowerShell hardening beyond detection, see the PowerShell Security Guide.

Where identity fits

Script blocks often contain secrets: connection strings, API keys and passwords passed to cmdlets. Microsoft recommends Protected Event Logging whenever script block logging is used for more than diagnostics, which encrypts logged content with a certificate whose private key is kept away from the logging hosts. Treat the decryption key as a privileged credential, and treat a secret seen in a script block log as exposed: rotate it. Automation accounts that run scripts on a schedule are non-human identities whose behaviour should be baselined like any other.

Implementation steps

1. Inventory interpreters. List the scripting engines in use per host class: PowerShell versions, Windows Script Host, Office macros, Python, shells. Decide which can be removed or restricted first; see M1042 Disable or Remove Feature or Program.
2. Confirm an AMSI provider is active. Check that your antimalware product registers as an AMSI provider on every Windows build and that its DLL is signed.
3. Enable script block logging with protection. Turn on script block logging for both PowerShell 5.1 and 7 where both exist, deploy the Protected Event Logging certificate (Document Encryption enhanced key usage), and forward 4104 events centrally.
4. Write content analytics. Match on decoded script content: download cradles, reflective loading, credential access cmdlets and AMSI tampering strings. Keep the pattern list under version control with an owner, because D3FEND notes it must stay current.
5. Add hash checks for script files. Compare script file hashes against known bad lists and against an allowlist of signed administrative scripts.
6. Pilot in audit mode. Run detection only for two weeks, review every hit with the script owner, then move high-confidence patterns to blocking in the AMSI provider or EDR policy. Rollback is a policy change back to audit.

How to verify it works

• AMSI test sample: Microsoft documents an AMSI test sample; running it, including in an encoded form typed at the prompt, should produce a detection with no file on disk.
• Logging check: run a harmless script block and confirm event 4104 arrives in the SIEM within your ingestion target, encrypted where Protected Event Logging is on.
• Obfuscation check: run a benign test command wrapped in string concatenation and Base64 and confirm the logged or scanned content shows the decoded command.
• Coverage check: repeat the tests under each interpreter in scope, including PowerShell 7 if installed beside 5.1.

These metrics are examples to adapt, not a standard.

Limits, bypasses and failure patterns

• Unhooked engines: AMSI only sees what a host submits. Interpreters and applications that do not call it, older PowerShell engines, and alternative runtimes stay invisible to engine-level inspection. Remove or block what you cannot see.
• Tampering with the hook: attackers target the scanning interface itself. Alert on known AMSI tampering strings in script content and on scan failures, and treat a sudden drop in AMSI events from a host as a signal.
• Logging only one PowerShell: enabling script block logging for 5.1 does not cover PowerShell 7, which uses a separate log and policy path.
• Unprotected logs: script block logs without Protected Event Logging become a source of credentials for anyone who can read the log.
• Stale patterns: regular expressions written once and never reviewed, which D3FEND warns against.
• Noise from administrators: legitimate automation looks like attack tooling. Sign administrative scripts and allowlist by signer, not by script name.

Framework mapping

The NIST and mitigation mapping is NHI Mgmt Group's view, not part of D3FEND. See M1049 Antivirus/Antimalware and M1038 Execution Prevention.

Related countermeasures

Siblings under Process Analysis include D3-PSA Process Spawn Analysis (which interpreter launched, from which parent), D3-SCA System Call Analysis, D3-FAPA File Access Pattern Analysis and D3-DQSA Database Query String Analysis. The D3FEND reference for D3-SEA also supports D3-FCR File Content Rules for the hash and pattern side. Scheduled scripts are covered by D3-SJA Scheduled Job Analysis.

Practitioner checklist

• Inventory scripting engines per host class and remove the ones you do not need.
• Confirm a signed AMSI provider is registered and loaded on every Windows build.
• Enable script block logging for every installed PowerShell version.
• Deploy Protected Event Logging and guard the decryption key.
• Keep content patterns under version control with a named owner and review date.
• Allowlist administrative scripts by signer, not by name.
• Alert on AMSI tampering strings and on hosts whose AMSI or 4104 events stop.
• Run AMSI test sample and obfuscation tests after each platform change.

Standards and references

• MITRE D3FEND: Script Execution Analysis (D3-SEA)
• Google Patents: US20190188384A1 Detecting script-based malware
• Microsoft Learn: Antimalware Scan Interface (AMSI)
• Microsoft Learn: How the Antimalware Scan Interface helps you defend against malware
• Microsoft Learn: about_Logging (Windows PowerShell 5.1)
• Microsoft Learn: about_Logging_Windows (PowerShell 7)
• MITRE ATT&CK: T1059 Command and Scripting Interpreter

Related NHI Mgmt Group resources: MITRE D3FEND Guide · T1059 Command and Scripting Interpreter Defensive Guide · PowerShell Security Guide · D3-PSA Process Spawn Analysis