To support Inde customers throughout 2023's Cyber Smart Week we will be publishing a blog post each day that details a category of mitigation that you can implement to harden yourself against popular adversary techniques. These blogs are to help technical managers and practitioners get a better grasp on how to manage security risks within their business. Our selection is based upon our practical experience in responding to incidents, researching threat actors and adversary simulation engagements.
Today we'll discuss Attack Surface Reduction (ASR) rules.
What are ASR Rules?
Remember IDDQD? Well we do, and we also think of ASR rules as a cheat code for hardening against popular attack techniques. ASR is a component of Windows Defender Exploit Guard which consists of a suite of security controls that are capable of auditing or blocking both behaviours and artifact attributes. Under the hood, the rules are essentially LUA scripts that define their parameters:
Source: HackingLZ
While enabled through GPO or InTune, the functionality of these rules are far more dynamic than traditional policies. Two examples are:
- Block executable files from running unless they meet a prevalence, age, or trusted list criterion: Malicious executables may not be immediately flagged by Defender if the file bytes do not match known signatures or they evade ML algorithms. Denying the execution of unique, newly-created, and untrusted files will help to protect against both emerging malware families and evasion techniques.
- Block credential stealing from the Windows local security authority subsystem (lsass.exe): The Local Security Authority Subsystem Service (LSASS) is a key component of Windows authentication, the process memory of which holds active user credentials. Threat actors may use tools such as Mimikatz to extract cleartext passwords and NTLM hashes from LSASS, or dump the process memory for extraction by Mimikatz elsewhere. As seen in the above screenshot, this rule denies processes the right to read the memory of lsass.exe unless they have permitted attributes.
Deploying ASR
While ASR does not explicitly require Defender for Endpoint, it does make ASR far easier to deploy and audit. Otherwise, ASR is available in Windows 10 Pro and Enterprise version 1709, Windows Server 1803, and Server 2019 and newer. ASR policy can be deployed either via:
- GPO: Computer configuration > Administrative templates > Windows components > Microsoft Defender Antivirus > Windows Defender Exploit Guard (old) or Microsoft Defender Exploit Guard (new) > Attack Surface Reduction > Configure Attack Surface Reduction rules.
- InTune: Endpoint security > Attack surface reduction.
By default, no rules are enabled, so a policy must be applied to hosts which specifies whether to enable individual rules in Audit, Block or Warn mode. Within InTune each rule is listed by its name, however within GPO you must reference each rule by a GUID (reference). Actions within InTune are also literally presented, and in GPO they are represented numerically (0 = disabled, 1 = block, 2 = audit, 6 = warn and permit bypass).
A standard deployment will begin with setting all rules to audit across all hosts, and then following an iterative process of:
- Using KQL to identify potential conflicts:
DeviceEvents
| where ActionType startswith "Asr"
| summarize RuleCount = count() by ActionType, ProcessCommandLine, InitiatingProcessFolderPath, InitiatingProcessCommandLine, AuditMode = tostring(parse_json(AdditionalFields).IsAudit)
| sort by RuleCount desc
- Determining whether blocking the conflicts is going to cause adverse behaviour.
- Defining specific exclusions for genuine conflicts. Exclusions should be applied to as narrow of a scope as is required. For example, if a conflict only occurs on a group of SQL servers, the exclusion should only apply to their OU or InTune group.
- Enabling rules which there is either no conflict for, or no concerning conflict.
Repeating the process after an acceptable observation period.
Each iteration may be spread across 24-48 hours, depending on the level of activity within the environment and how frequently the conflict occurs. As with patching, changes can be progressively rolled out to groups of hosts.
InTune and GPO also differ in how they handle exclusions. While you are able to create per-rule exclusions in InTune, exclusions in GPO apply to all rules. However, both permit you to use wildcards in the file name and folder path. Indicators may also be leveraged in Defender for Endpoint to exclude based on certificate info and file hash.
Common Experience
Our experience with deploying ASR is accurately reflected in the following table from Palantir's excellent blog post on the subject:
Source: Palantir
Adverse impact of the rules, particularly those that are Office related, is very much environment specific and most often confined to specific groups of users or hosts. However, those in the green column can almost always be set to block very early on.
While the rule to block credential stealing from LSASS may generate a lot of rule hits, as detailed in the Palantir blog post, there is very rarely any actual conflict and log entries are typically the result of legitimate software enumerating running processes. For comfort, it can be accompanied by deployment of Credential Guard.
With respect to the rules which require caution:
- Block executable files from running unless they meet a prevalence, age, or trusted list criterion: Organisations that use bespoke or uncommon software may find that this rule denies them the ability to run this software for a period after it is compiled. This requires exclusions to be defined for either the signing authority, file hashes, or path of the conflicting executables.
- Use advanced protection against ransomware: We have not observed any notable conflicts with this rule.
- Block process creations originating from PSExec and WMI commands: Conflicts primarily arise from system management tooling that uses WMI to monitor remote hosts. Exclusions are usually very difficult to define, and compensating controls are instead relied upon.
- Block Office communication applications from creating child processes: This may result in Office applications such as Outlook and Teams being unable to open specific files or links in external programs, however this behaviour appears dependent on installation-specific conditions (e.g. integrations).
Further Reading