How to Make a Pentester Cry: In-Depth Guide to Firewall Rules, Defender ASR, and File Association Hardening Introduction

In the ever-evolving landscape of cybersecurity threats, it is imperative for organizations to adopt a proactive and multi-layered approach to securing their Windows endpoints. This blog post will dive deep into three critical areas where system administrators can significantly enhance the security posture of their Windows environment:

1. Configuring granular firewall rules to limit internet connectivity for script engines
2. Implementing Microsoft Defender’s Attack Surface Reduction (ASR) mitigations
3. Modifying default file associations to prevent automatic execution of potentially malicious scripts

By meticulously addressing these areas through Group Policy Objects (GPOs), organizations can erect formidable barriers against prevalent attack vectors such as phishing, malware, and exploit-based intrusions.

Restricting Internet Access for Script Engines One of the primary avenues for malicious actors to infiltrate networks is through malicious scripts, frequently disseminated via cleverly crafted phishing emails. These scripts often endeavor to establish external internet connections to exfiltrate data or download additional malicious payloads, propagating the infection.

To counter this threat, it is highly recommended to implement a robust set of firewall rules through GPOs. These rules should be designed to prohibit direct internet access for common script execution programs, including:

• wscript.exe
• mshta.exe
• cscript.exe
• conhost.exe
• runScriptHelper.exe

Firewall rule configuration can be performed by navigating to Computer Configuration / Policies / Windows Settings / Security Settings / Windows Defender Firewall with Advanced Security within the GPO editor. Ensure that the rules are applied on the outbound direction and are set to active status.

However, completely blocking network access may impair legitimate functionality of these programs within the local network environment. To accommodate this, administrators can define specific IP address ranges for which communication will be permitted, such as:

• 0.0.0.0 to 9.255.255.255
• 11.0.0.0 to 126.255.255.255
• 128.0.0.1 to 172.15.255.255
• 172.32.0.0 to 192.167.255.255
• 192.169.0.0 to 255.255.255.255

As an alternative approach, the rules can be applied universally to all IP addresses, or narrowly scoped to only allow communication with the organization’s designated internal proxy server.

Activating Defender Attack Surface Reduction Mitigations Microsoft Defender, the default antivirus solution bundled with Windows, has evolved into a potent and comprehensive security tool. One of its most valuable features is the Attack Surface Reduction (ASR) capabilities, designed to harden the operating system against a wide spectrum of attack techniques. These mitigations have been available since the release of Windows 10 version 1709 and are also compatible with Windows Server 2012 R2 and later.

ASR rules are managed through the GPO setting labeled “Configure Attack Surface Reduction rules”, located under Computer Configuration > Policies > Administrative Templates > Windows Components > Windows Defender Antivirus > Windows Defender Exploit Guard > Attack Surface Reduction.

To activate an ASR rule in Block mode, which is the most stringent enforcement level, follow these steps:

1. Enable the GPO setting
2. Choose the option “Set the state for each ASR rule”
3. Input the rule’s unique GUID identifier as the Value name
4. Assign the Value as 1 to enable Block mode

In addition to Block mode, ASR rules can be set to Audit mode (Value 2) or Warn mode (Value 6). Audit mode is beneficial for initially assessing the potential impact of a rule without enforcing it, while Warn mode displays a notification to the user but still allows the action.

Several critical ASR rules that should be prioritized for deployment in Block or Warn mode encompass:

• Block abuse of exploited vulnerable signed drivers
• Block credential stealing from the Windows local security authority subsystem (lsass.exe)
• Block executable content from email client and webmail
• Block JavaScript or VBScript from launching downloaded executable content
• Block persistence through WMI event subscription

For other rules, it may be prudent to initially configure them in Audit mode to gauge their effect on the environment and identify any potential false positives or compatibility issues. Thorough testing and impact analysis should always precede widespread implementation to minimize disruption to business processes.

Controlling Default Script Execution Behavior A prevalent tactic employed in phishing campaigns is to embed malicious scripts within seemingly innocuous email attachments, often evading detection by security filters. By default, Windows is configured to automatically execute certain legacy script file extensions using their designated script engines when opened. This behavior applies to file extensions such as:

• .js, .jse (JScript)
• .vbs, .vbe (VBScript)
• .wsf, .wsh (Windows Script File)

While .js and .jse files are frequently associated with web content and handled by browsers, allowing them to execute directly on the filesystem exposes a significant risk surface.

To mitigate this threat, it is advisable to modify the default file associations for these extensions, instructing Windows to open them in a text editor like Notepad by default instead. This approach effectively neutralizes the ability for malicious scripts to execute automatically, while still enabling users to open and inspect the file contents safely. Importantly, this mitigation does not interfere with the normal execution of these file types within web browsers.

File associations can be centrally managed via GPO by navigating to Computer Configuration / Preferences / Windows Settings / Folders. For each extension to be secured, create a new File Type entry, select the “Replace” action, and under “Configure class settings”, define a new “open” action pointing to the full path of the Notepad executable (e.g., C:\Windows\System32\notepad.exe).

It is important to recognize that while this recommendation addresses some of the most notorious script extensions, each organization should carefully review the implications for any additional script file types utilized within their environment before applying these changes universally.

Conclusion

Implementing these three key security controls—targeted firewall rulesets, fine-tuned Defender ASR policies, and risk-based script file association hardening—can dramatically bolster an organization’s resilience against a broad spectrum of prevalent threats.

However, as with any security enhancement, it is crucial to thoroughly analyze potential impacts to business workflow, legacy applications, and user experience. Rigorous testing in staging environments and phased rollout plans should be the norm for such impactful modifications.

By striking the right balance between security and operational requirements, and investing the necessary due diligence upfront, organizations can reap the full benefits of these powerful mitigations while minimizing any inadvertent disruption.

Through the strategic application of these and other defense-in-depth measures, security teams can methodically harden their Windows endpoints and construct a far more resilient and hostile environment for would-be attackers.