Essential Eight Series Part 7: User Application Hardening

The Attacker's Toolkit Is Already Installed.

When most people think about a cyberattack, they picture something being delivered from outside. A malicious file, an exploit, something foreign landing on the system.

A significant proportion of real attacks don't work that way. The attacker gets a foothold through some initial access, and then everything they do from that point uses tools that were already there.

PowerShell. Windows Script Host. MSHTA. Certutil. Regsvr32. BITSAdmin. These are all legitimate Windows components with genuine administrative purposes. They're also the standard toolkit for post-exploitation in most environments, precisely because they're present by default, trusted by the operating system, and rarely monitored closely.

This is what the security community calls living off the land. And it's why User Application Hardening exists as a control in the Essential 8.

What the control is asking for

The Essential 8 guidance on this control covers a few distinct areas that are worth separating out.

Internet Explorer. Still listed because it still exists in some environments as a legacy compatibility component, and because it carries a significant exploit history. If it's present and not needed, it should be disabled.

Web browser hardening. Blocking web advertisements, restricting browser-based script execution where practical, and ensuring browsers aren't running with more capability than they need. This matters because the browser is the most common initial access surface for endpoint compromises. Drive-by downloads, malicious redirects, and credential harvesting all typically run through the browser first.

Microsoft Office hardening. Restricting Office applications from creating child processes, from injecting into other processes, and from executing scripts through mechanisms other than the application itself. This directly limits the macro execution chains we covered in Part 6, but also catches other Office-based attack paths that don't involve macros at all.

Restricting script interpreters. This is where living off the land becomes directly relevant.

The script interpreter problem

PowerShell is the most discussed example, but the problem is broader than PowerShell.

Windows Script Host enables execution of VBScript and JScript files directly from the filesystem or from within other processes. MSHTA executes HTML application files, which can contain arbitrary script. Certutil, a certificate management tool, can be used to download files from the internet and decode base64 content. These capabilities exist for legitimate reasons. They're also standard components of attack chains that security teams see repeatedly.

The challenge is that simply disabling PowerShell is not a solution and will break things. The realistic approach is constrained execution, logging, and visibility rather than outright removal.

For PowerShell specifically, the Essential 8 guidance points toward enforcing PowerShell Constrained Language Mode, enabling Script Block Logging, and where possible moving to signed script execution. Constrained Language Mode limits the .NET types and methods available to scripts, which significantly reduces what an attacker can do even if they can execute PowerShell. It doesn't prevent execution, it limits capability.

For Windows Script Host, the calculus is different. Most end user devices have no legitimate need to execute VBScript or JScript files directly. Disabling WSH on workstations is lower risk than it sounds and removes a delivery mechanism that still appears in commodity malware.

Why organisations skip this

The honest answer is that this control requires more environmental knowledge than most others.

To harden script interpreter behaviour, you need to understand what your legitimate tooling actually uses. RMM agents, backup clients, monitoring software, and endpoint management tools frequently invoke PowerShell, WScript, or other interpreted components as part of normal operation. Restricting those components without that knowledge causes operational problems quickly, and operational problems cause restrictions to get walked back.

That knowledge gap is why this control gets deferred. Not because anyone disagrees with the principle, but because the pre-work feels expensive and the risk of breaking something feels immediate while the security benefit feels abstract.

The connection back to Application Control from Part 2 is relevant here. Environments that have done the work to build an application inventory for application control purposes are much better positioned to tackle user application hardening, because they already have a map of what's running and what it depends on. The two controls reward the same foundational investment.

Browser hardening

The browser deserves specific attention because it's where the attack surface is largest and where configuration drift is most common.

Enterprise browser management through Group Policy or Intune gives you control over extension installation, JavaScript behaviour, and download handling. Most organisations have some browser policy in place. Fewer have reviewed it recently or validated that it's actually applying consistently across the fleet.

The specific areas worth checking: whether unapproved extensions can be installed by users, whether the browser is blocking known malicious categories at the policy level rather than relying solely on the email gateway and DNS filtering, and whether browser-based password storage is being used in ways that create credential exposure risk.

The last point matters more than it's sometimes given credit for. Credentials stored in the browser are accessible to any process running as that user. If an attacker has code execution in the user context, browser-stored passwords are a straightforward harvest target.

What reasonable hardening looks like

The goal isn't to lock systems down to the point where legitimate work becomes difficult. It's to remove the capabilities that have no legitimate use case on end user devices and to constrain the ones that do.

For most organisations that haven't started here, a reasonable sequence is: disable Internet Explorer where it still exists, disable Windows Script Host on workstations where there's no business case for it, enable PowerShell Script Block Logging as a minimum visibility measure, review browser extension policy, and audit Office application hardening settings against the ACSC guidance.

None of those steps require replacing tooling or rebuilding workflows. They reduce the capability available to an attacker who has already achieved code execution, which is exactly what this control is designed to do.

The attacker's toolkit is already installed on your endpoints. This control is about making it less useful to them.

Part 8 next, which closes the series on backups and recovery.