Script based attacks remained a real-world challenge in 2025
- Kim & Tom
- Mar 3
- 3 min read
One of the key findings in AppControl.AI's application allowlisting effectiveness report was that just about every month Microsoft's Intel demonstrates that attack campaigns that strictly rely on script based code execution are a thing.
This finding aligns with a well-established security industry trend: PowerShell- and script-based attacks remain one of the most prevalent and effective execution mechanisms used by adversaries on Windows platforms. By operating through trusted interpreters rather than dropping traditional binaries, attackers are able to bypass allowlisting policies that focus exclusively on executables and libraries.
Implications for Allowlisting Strategy
These results demonstrate that allowlisting without script enforcement leaves a critical execution surface exposed. While executable and library restrictions significantly reduce attack options, they do not adequately address adversaries that deliberately avoid dropping binaries.
The findings reinforce that script enforcement is not an optional enhancement but a core requirement for effective application allowlisting on Windows. Omitting script controls materially increases exposure to in-the-wild attack campaigns and undermines the preventative value of the control as a whole.
The list of campaigs an organisation is vulnerable for when script enforcement isn't part of your implementation can be found below:
Windows Defender Application Control and Script based allowlisting
When implementing application allowlisting using Windows Defender Application Control aka AppControl for business, script allowlisting is enforced by default.
The feature can be turned off, but doing so does reduce the effectiveness of your implementation as detailed above.
Leaving the feature on immediately enforced your allowlisting strategy for the following Script Hosts.
Vbscript
JavaScript
MSHta
MSXML
PowerShell
Application Control for business leaves it up to each Script Host to decide how it prefers to implement script allow listing. As a result there are 3 different implementations.
Trust or bust
The trust or bust implementation is what VbScript and JavaScript chose as their implementation model. When script allowlisting is enabled, they require you to make the necessary rules to make sure the script is trusted by your allow policy.
Failure to create the necessary rules will result in Audit or Blocked behavior depending on your enforcement state.
Always block
The always block implementation is what MSHta & MSXML chose to implement. As the name implies, whenever script allowlisting is implemented these 2 Script Hosts will deny execution of any scripts. Important note, they will do so regardless of the enforcement state of your AppControl for business policy. Even when the policy is in Audit mode, script execution for these script hosts will be blocked. Creating rules to make these scripts trusted has no effect either, they will block as soon as they see an Application Control for business policy is active.
Constrained Run
The implementation script allowlisting of PowerShell is a bit of a special beast. PowerShell detects whether Script Allowlisting is active and behaves differently for trusted vs untrusted scripts.
Trusted scripts run as if no Script Allowlisting is active at all, as you would expect. Untrusted scripts on the other hand, still execute, but in a limited mode where quite a bit of the PowerShell power, is not available to the script. A dedicated blogpost on how this all works can be found here:
For more details on the implications of (not) enabling Script Allowlisting, read the full report here:
Want to learn more on how AppControl.AI helps the implementation of a comprehensive allow listing implementation, including scripts, contact us for a talk & demo.
Comments