Skip to content

Windows Endpoints

⚠ Note: These are controls you configure in Microsoft Intune, Group Policy or Microsoft Configuration Manager. They sit alongside SenseOn rather than inside it. SenseOn's own endpoint controls are documented separately under Endpoint Protection (EPP), Active Response and USB Controls.

This page applies to Windows 10 22H2 and Windows 11. Policy names and Intune navigation change over time, so verify against the linked source before relying on any specific setting.

Delivery follows the same channel rules as the firewall and browser guides: pick one management plane per setting and do not configure the same policy from two channels at once. Split ownership is the most common reason a policy silently fails to apply.

PowerShell

This comes up more than anything else, usually phrased as "can we just disable PowerShell for users". The honest answer is that you can, that it will not achieve what you want, and that there is a better approach.

Why blocking powershell.exe does not work

PowerShell is not the executable. It is a runtime hosted by System.Management.Automation.dll, and powershell.exe is only one of many hosts for it. Blocking or removing the executable leaves every one of these paths open:

  • powershell_ise.exe, and PowerShell 7 as pwsh.exe, which installs separately and is not covered by Windows PowerShell policy.
  • Any application that loads the automation assembly directly, a technique widely available in commodity tooling and trivially reimplemented.
  • wmic, mshta, rundll32, regsvr32, msbuild and the rest of the signed-binary execution surface, which achieve the same outcome without PowerShell at all.

Blocking the executable also breaks a great deal of legitimate machinery: Intune remediation scripts, Configuration Manager tasks, software deployment, printer and VPN client installers, and your own operational tooling.

💡 What we actually recommend: constrain what PowerShell can do rather than whether it can run, and log everything it does. That combination is both more effective against the techniques we see and considerably less disruptive.

Constrained Language Mode

Constrained Language Mode restricts PowerShell to a safe subset of the language. Core cmdlets and scripting still work, but the .NET type access, reflection and Win32 API calls that offensive tooling depends on do not. Almost all administrative scripting is unaffected. Almost all offensive tooling breaks.

The supported way to enforce it is as a side effect of application control, not as a standalone setting:

Route How it works Notes
WDAC (App Control for Business) A WDAC policy in enforced mode automatically places PowerShell into Constrained Language Mode for any script that is not explicitly trusted. Trusted, signed scripts continue to run in Full Language Mode. The recommended route. Also delivers application control generally.
AppLocker An enforced AppLocker script rule collection has the same effect on PowerShell language mode. Simpler to deploy than WDAC where WDAC is not yet feasible.
__PSLockdownPolicy environment variable Sets the language mode directly. Not a security boundary. Microsoft is explicit that this is for testing only. A user who can set their own environment variables can undo it. Do not use it as a control.

Start WDAC in audit mode. It logs what would have been blocked without blocking it, and the resulting event volume is the only realistic way to discover what your estate genuinely runs before you enforce. Microsoft publishes a recommended block rules list covering the signed binaries commonly abused to bypass application control, and a recommended driver block rules list for vulnerable drivers. Both are worth adopting even if your policy is otherwise permissive.

Remove PowerShell 2.0

PowerShell 2.0 predates script block logging, AMSI and Constrained Language Mode, and can be invoked with powershell -version 2 to downgrade out of all three. It is an optional feature with no remaining legitimate use.

Remove the MicrosoftWindowsPowerShellV2Root optional feature across the estate. Confirm the .NET Framework 2.0 and 3.5 dependency it relies on is also absent, since its presence is what makes the downgrade possible.

Logging is worth more than blocking

If you do one thing on this page, do this one. It is free, it breaks nothing, and it is the largest single improvement you can make to the quality of any investigation involving a Windows endpoint.

Computer Configuration > Policies > Administrative Templates > Windows Components > Windows PowerShell

Policy Setting What it gives you
Turn on PowerShell Script Block Logging Enabled Records the deobfuscated content of every script block as it executes, to event ID 4104. Obfuscation is defeated because logging happens after the runtime has decoded it. This is the highest-value event on Windows.
Turn on Module Logging Enabled, with module names set to * Pipeline execution detail. Useful, noisier, and largely superseded by script block logging. Enable it if volume allows.
Turn on PowerShell Transcription Enabled, with an output directory Full session transcripts including output, which script block logging does not capture. Write to a protected central share, not to a local path the user can clear.

Do not enable Log script block invocation start / stop events. The volume is high and the additional value is low.

⚠ Execution policy is not a security control. Set-ExecutionPolicy Restricted prevents accidental script execution. It is bypassed with -ExecutionPolicy Bypass, by piping to Invoke-Expression, or by simply reading the file. Microsoft documents it as a safety feature, not a security boundary. Do not present it to an auditor as one.

What SenseOn does with this

The Universal Sensor collects process execution telemetry including command lines independently of Windows event logging, so PowerShell activity is visible to SenseOn whether or not you enable the policies above. Enabling script block logging adds the decoded script body, which is what turns "an encoded command ran" into "here is exactly what it did". You can query both in Hunt Lab via the endpoint_process table.

Attack Surface Reduction rules

Attack Surface Reduction (ASR) rules are part of Microsoft Defender Antivirus and are available at no additional licence cost where Defender Antivirus is running in active mode. They block specific behavioural patterns rather than specific files, which is why they hold up against techniques rather than samples.

These are, in our experience, the highest-value endpoint controls available to a Windows estate, and they directly address both halves of the question this page most often gets asked: executable content arriving by email, and script-based execution.

Deploy through Intune Endpoint security > Attack surface reduction, or Group Policy under Windows Components > Microsoft Defender Antivirus > Microsoft Defender Exploit Guard > Attack Surface Reduction.

Each rule supports Not configured, Audit, Block and Warn. Deploy every rule in Audit first. Some of them, particularly the Office child process rule, will break line-of-business applications that shell out to other executables.

Email and document-borne execution

Rule Why it matters
Block executable content from email client and webmail This is the "stop things running from email attachments" control. Blocks executable files and scripts arriving through Outlook or webmail from executing.
Block all Office applications from creating child processes Breaks the single most common macro payload pattern, where a document spawns PowerShell, cmd or mshta. Highest false positive potential of the set, so audit it properly.
Block Office applications from creating executable content Stops documents writing executables to disk.
Block Office applications from injecting code into other processes Rarely legitimate. Low breakage.
Block Win32 API calls from Office macros Removes the macro path to direct API abuse.
Block Adobe Reader from creating child processes The PDF equivalent of the Office rule, and cheaper to enable because the false positive rate is much lower.

Script and loader execution

Rule Why it matters
Block JavaScript or VBScript from launching downloaded executable content Targets the script downloader stage directly.
Block execution of potentially obfuscated scripts Catches obfuscation as a signal in its own right. Some legitimate installers are packed enough to trip this, so audit it.
Block executable files from running unless they meet a prevalence, age or trusted list criterion Powerful and disruptive in equal measure. Consider it only for a well-understood standard build.
Block untrusted and unsigned processes that run from USB Pairs with USB Controls for removable media.

Credential and persistence protection

Rule Why it matters
Block credential stealing from the Windows local security authority subsystem Blocks the common LSASS access pattern used for credential dumping. See also Credential protection below.
Block process creations originating from PSExec and WMI commands Targets lateral movement. Will break Configuration Manager if you use it for remote execution, so check first.
Block persistence through WMI event subscription A quiet, durable persistence technique with essentially no legitimate use in most estates. Low breakage.
Block abuse of exploited vulnerable signed drivers The bring-your-own-vulnerable-driver path to kernel-level access.
Use advanced protection against ransomware Behavioural ransomware protection. Complements, rather than duplicates, Reflex.
Block webshell creation for servers Exchange and IIS servers specifically.

💡 Exclusions. ASR supports per-rule exclusions. Use them narrowly and record why each exists. A broad exclusion path, particularly one covering a whole user profile or a software distribution folder, quietly disables the rule for exactly the location attackers prefer.

Current rule names, GUIDs, supported operating system versions and per-rule caveats are maintained in the Microsoft ASR rules reference. Take the GUIDs from there rather than from any secondary source, including this one.

Office macros

Macros remain a live initial access route, particularly in documents delivered through channels other than email now that email delivery is well defended.

  • Block macros from the internet. Office blocks VBA macros in files marked with the Mark of the Web by default. Confirm this has not been reversed in your tenant, and enforce it by policy rather than relying on the default: Block macros from running in Office files from the Internet, enabled per application.
  • Set VBA macro notification settings to disable with notification, or disable all without notification where the business can tolerate it.
  • Do not allow users to bypass Mark of the Web by unblocking files. If a workflow requires it, fix the workflow, typically by delivering files through a trusted SharePoint or OneDrive location rather than as attachments.
  • Disable XL4 macros (Excel 4.0 macros), which are older, less visible and still abused. Set the macro notification setting for XL4 to disable without notification.
  • Consider blocking legacy file formats at the mail gateway. See Email and Collaboration.

Mark of the Web is the mechanism underneath most of these, so anything that strips it undermines them all. Container formats are the usual culprit: ISO, IMG, VHD and some archive handling historically did not propagate the mark to their contents. Keep Windows and your archive tooling current, and block the container formats you do not need at the gateway.

AutoPlay and AutoRun

Distinct from the email controls above, and still worth setting.

Computer Configuration > Policies > Administrative Templates > Windows Components > AutoPlay Policies

Policy Setting
Turn off AutoPlay Enabled, for All drives
Disallow Autoplay for non-volume devices Enabled
Set the default behaviour for AutoRun Enabled, Do not execute any autorun commands

Modern Windows already disables AutoRun for removable media, but the policies remove the remaining paths and stop a user re-enabling them. Pair with the ASR rule for unsigned processes from USB, and with SenseOn USB Controls where you need enforcement and visibility of the devices themselves.

Local administrator rights

Removing standing local administrator rights from standard users is the single most effective endpoint control, and consistently the least popular.

  • Standard users by default. Most endpoint compromise that succeeds does so because the user could install software. Removing that removes the outcome, not just the alert.
  • Windows LAPS for the built-in local administrator account. Built into Windows since April 2023, no separate installation. It randomises the local administrator password per device and rotates it, which stops one recovered local hash from unlocking the estate. Configure it to back up to Entra ID or Active Directory according to your join type.
  • Disable or rename the built-in Administrator where it is not needed, and never use a shared local administrator password. If you do nothing else in this section, remove the shared password.
  • Provide a sanctioned elevation route. A privilege management product, an approved software portal, or Intune's Endpoint Privilege Management. Without one, users find their own way and you lose visibility as well as control.

Credential protection

Control What it does
Credential Guard Uses virtualisation-based security to isolate LSASS secrets so they cannot be read even by a process with SYSTEM. Enabled by default on new installations of Windows 11 Enterprise meeting the hardware requirements. Verify rather than assume, and check for incompatibility with any third-party authentication provider.
LSA protection (RunAsPPL) Runs LSASS as a protected process. Weaker than Credential Guard but works where Credential Guard cannot. Enable in audit mode first, since some legitimate software injects into LSASS.
ASR credential stealing rule Blocks the common LSASS handle access pattern. Complementary rather than equivalent.
Disable WDigest Prevents cleartext credentials being cached in memory. Disabled by default on supported Windows versions, but check for a legacy policy re-enabling it.
Restrict cached domain credentials Reduce the number of cached logons where the estate is reliably connected. Balance against the needs of genuinely mobile users.

Verifying with SenseOn

After each change, confirm it landed across the estate rather than on the device you tested with:

  • Hunt Lab against endpoint_process for PowerShell invocations, encoded commands, and process parentage that a new ASR rule should now be blocking.
  • Digital Estate to identify devices not reporting, which are usually the devices policy also failed to reach.
  • On an individual endpoint, Get-MpPreference returns the ASR rule IDs and actions currently in force, which is the fastest way to confirm a rule is genuinely in Block rather than Audit.

Go live checklist

  • [ ] Delivery channel chosen per setting, with no overlap between Intune, Group Policy and Configuration Manager
  • [ ] PowerShell script block logging enabled estate wide
  • [ ] PowerShell transcription writing to a protected central location
  • [ ] PowerShell 2.0 optional feature removed
  • [ ] WDAC or AppLocker deployed in audit mode, with the Microsoft recommended block rules adopted
  • [ ] Constrained Language Mode confirmed in effect once application control is enforced
  • [ ] All applicable ASR rules deployed in Audit, reviewed for a full business cycle, then moved to Block
  • [ ] ASR exclusions documented with a reason and an owner
  • [ ] Macro policy enforced, including XL4, and Mark of the Web bypass prevented
  • [ ] AutoPlay and AutoRun disabled by policy
  • [ ] Standing local administrator rights removed, with a sanctioned elevation route in place
  • [ ] Windows LAPS deployed, shared local administrator passwords eliminated
  • [ ] Credential Guard or LSA protection verified in force

Sources

All URLs verified on 19 August 2026.