Please follow and like us:

Securing PowerShell: Constrained Language Mode, Logging, and AMSI

PowerShell is a built-in Windows tool that helps administrators automate tasks. It’s also a favorite tool for attackers because it can run powerful commands quickly. The goal isn’t to “remove PowerShell” (that can break management tools and apps). The goal is to make PowerShell safer by limiting what it can do, recording what it does, and letting security tools inspect what it’s trying to run.

This guide focuses on three practical defenses you can use together:

Constrained Language Mode (CLM): limits risky PowerShell features in many situations.
PowerShell logging: creates useful records for troubleshooting and investigations.
AMSI (Antimalware Scan Interface): lets antivirus/EDR inspect scripts at runtime.

Important note: Security settings can affect legitimate admin scripts and some software installers. If you manage multiple PCs, test changes on one machine first.

1) Constrained Language Mode (CLM): what it is and when it helps

Constrained Language Mode is a PowerShell “restricted mode.” When it’s active, PowerShell allows basic commands but blocks or limits advanced features commonly used to load code, call low-level Windows APIs, or interact with .NET in powerful ways.

What CLM is good at

Reducing the impact of “living-off-the-land” techniques where malware uses built-in tools.
Making it harder for untrusted scripts to do advanced, stealthy actions.
Adding friction without fully disabling PowerShell.

What CLM is not

Not a replacement for antivirus/EDR, patching, least privilege, or application control.
Not a guarantee: some attacks don’t rely on the features CLM blocks.
Not always “on” by default—how it’s enforced matters.

How CLM is typically enforced (safe, admin-focused overview)

In real environments, CLM is most effective when it’s paired with an application control policy (for example, Windows Defender Application Control or AppLocker). The basic idea is:

Trusted, signed/admin-approved scripts can run with full language features.
Untrusted code gets forced into CLM, limiting what it can do.

If you’re a home user, you may not want to build application control policies from scratch. In that case, focus on the other two protections (logging + AMSI) and standard Windows Security settings. If you’re managing a business PC fleet, CLM becomes much more valuable as part of a broader policy setup.

How to check if PowerShell is in Constrained Language Mode

On a PC you administer, you can check PowerShell’s language mode by running PowerShell and viewing the session language mode. In general, you’re looking for something like ConstrainedLanguage versus FullLanguage. If you’re not sure how to check this safely in your environment, it’s worth having an IT admin review your policy configuration so you don’t accidentally block required scripts.

2) PowerShell logging: the “paper trail” that helps you respond calmly

Logging doesn’t stop an attack by itself, but it can:

Help you understand what happened after an incident.
Make suspicious activity easier to spot.
Support troubleshooting when a script or tool misbehaves.

There are three PowerShell logging features that matter most:

Module logging: records commands from specific PowerShell modules.
Script Block logging: records the contents of executed script blocks (very useful for visibility).
Transcription: records an interactive session (what was typed and output).

Practical guidance (without getting lost in the weeds)

Start with Script Block Logging if you want the most security value.
Add Transcription for admin workstations or servers where interactive PowerShell is common.
Plan storage: logs can grow quickly. Decide how long to keep them and where.

Where you’ll see the logs

PowerShell events are typically visible in Windows Event Viewer under PowerShell-related logs. If you use centralized logging (common in business environments), forward these events so you can search across machines.

Privacy note: Logging can capture command content, which may include file paths, server names, or other sensitive admin details. Limit access to logs and keep retention reasonable.

3) AMSI: how scripts get scanned at runtime

AMSI (Antimalware Scan Interface) is a Windows feature that allows security software to inspect scripts and code as they run. In PowerShell, AMSI can help detect suspicious script content even if it’s created “on the fly” rather than saved as a file.

What to do to benefit from AMSI

Keep Microsoft Defender Antivirus (or your approved antivirus) enabled and up to date.
Keep Windows updated so AMSI and PowerShell components receive security fixes.
Avoid disabling real-time protection except for short, controlled troubleshooting.

Limits to understand

AMSI relies on your security software to make decisions. Detection quality varies by product and configuration.
AMSI is one layer. You still want least-privilege accounts, strong update hygiene, and basic hardening.

Putting it together: a sensible “secure-by-default” checklist

If you want a practical plan that doesn’t require building an enterprise security program, use this order:

Step 1: Update Windows regularly (this supports PowerShell, AMSI, and overall security).
Step 2: Confirm your antivirus is active and current (so AMSI has something to talk to).
Step 3: Turn on PowerShell Script Block Logging (best visibility for most environments).
Step 4 (advanced/managed PCs): Add CLM with application control so untrusted code is restricted.

Common problems and how to handle them safely

“My admin script stopped working.”

Check whether CLM is active on that machine/session.
Review logs to see what command or module was blocked.
If this is a business environment, consider signing scripts and allowing trusted publishers rather than loosening restrictions globally.

“Logging is filling up the disk.”

Reduce retention or forward logs to a central location.
Log what you need (for example, Script Block Logging) and avoid collecting everything everywhere.

“Do I need to disable PowerShell?”

Usually, no. Many Windows and IT tools depend on it. It’s typically safer to harden PowerShell with the layers above than to remove it or try to block it completely.

When to consider professional help

If you manage a small business, the “best” setup often depends on how your PCs are used. CLM plus application control can be very effective, but it’s also the most likely to break legitimate automation if rolled out without testing. If you’re unsure, have an admin review your needs and implement changes in phases.

Bottom line: PowerShell security is most effective when you combine restriction (CLM where appropriate), visibility (logging), and runtime scanning (AMSI)—while keeping Windows and antivirus up to date.