Preventing Malware via End User Execution in Windows [T1204]

In recent years, cyber threats have become increasingly common, and organizations must invest in measures to protect their data. Social engineering is one of the most common tactics used by attackers to gain access to sensitive information. This technique involves using psychological manipulation to trick end-users into performing actions that could compromise the security of their system. By the end of this article, you will have learned what methods malicious actors use to place malware in your environment and implemented two different controls to prevent such activities in small to medium environments.

The Mitre ATT&CK entry TA0001, also known as Initial Access, includes various techniques used by attackers to gain their initial foothold into a targeted system. The control discussed in this article, preventing malware via end-user execution, specifically addresses T1204, User Execution. By mitigating the risk of end-users accidentally launching malicious files or executables, organizations can significantly reduce the risk of attackers gaining a foothold in their systems through social engineering tactics. Implementing the controls discussed in this article can help organizations prevent initial access by attackers and improve their overall security posture.

Mitigating the Risk of End-Users Launching Malicious Script Files

The first method protects against binary or script types such as .hta files, which are executable and can run code on the victim’s machine without their knowledge. This file type is often ignored by email attachment filters and not widely known, making it a perfect tool for attackers.

To mitigate the risk of end-users accidentally launching malicious files, it is essential to implement a simple control that modifies group policy to change the default file association for these types of files to Notepad. This measure will ensure that any suspicious files will open in Notepad, which may confuse users enough to seek assistance from the support desk, leading to further investigation of the file’s origin.

It is recommended to set up this control for file extensions such as .vsto (highly recommended if you use Outlook), .hta, .bat, .ps1, .js, .jse, .vbs, .vb, .vbe, .vbscript, .reg, .rgs, .bin, .cpl, .scr, .ins, .paf, .sct, .ws, .wsf, .wsh, .u3p, .shs, .shb, and .cmd.

To implement the control to mitigate the risk of end-users accidentally launching malicious files, follow these steps:

1. Open the Group Policy Editor by typing “gpedit.msc” in the Run dialog box (Windows + R).
2. Navigate to User Configuration > Preferences > Control Panel Settings > Folder Options.
3. Right-click Folder Options and select New > File Type Association.
4. In the New File Type Association dialog box, enter the file extension you want to modify (e.g., .hta) in the Extension field.
5. In the Association field, enter “Notepad” (without quotes).
6. Click OK to save the new file type association.

Mitigating the Risk of End-Users Launching Malicious Executables

When it comes to executables (which are more commonly picked up by email filters), a measure that organizations can implement to protect their data is application whitelisting. Application whitelisting is the practice of allowing only approved applications to run on a system while blocking all others. This approach is highly effective as it prevents unauthorized applications from running and executing malicious code, even if they are downloaded from unknown sources or delivered through social engineering techniques.

Applocker

AppLocker is a free Microsoft tool that allows organizations to specify which applications are allowed to run on their systems. Administrators can create policies that define which applications are allowed to run based on factors such as file name, file location, and digital signature. This approach can help organizations prevent unauthorized or malicious applications from running on their systems, which can significantly reduce the risk of data breaches.

AppLocker is available on Windows 7, 8, and 10 Enterprise and Education editions. It is a built-in feature that can be accessed through the Local Security Policy or Group Policy Editor. While AppLocker can be a useful tool for organizations that want to enhance their security posture, implementing it can be challenging. However this AppLocker base whitelist repository can help: https://github.com/api0cradle/UltimateAppLockerByPassList.

Threatlocker

ThreatLocker is a 3rd party paid application whitelisting solution that can help organizations prevent malware infections and data breaches. This solution allows IT administrators to create a whitelist of approved applications, which are the only ones that can run on endpoints, servers, and other systems. Any unauthorized application that tries to run is automatically blocked, preventing it from executing and causing harm.

ThreatLocker also provides granular control over the applications that run on a system, allowing administrators to specify the exact applications that are allowed to run in different scenarios. For example, they can specify different whitelists for different departments or roles, ensuring that each user has access only to the applications they need to complete their job. This level of control over application execution can significantly reduce the risk of data breaches caused by malicious or unauthorized applications.

Implementing application whitelisting with ThreatLocker requires a phased approach, starting with a pilot group and gradually expanding to the rest of the organization. This approach allows administrators to identify and address any issues that may arise during the implementation process, ensuring a smooth rollout and maximum protection against cyber threats.

How to Implement Application Whitelisting with ThreatLocker

To implement application whitelisting with ThreatLocker, follow these steps:

1. Install ThreatLocker on the endpoint, server, or system you want to protect.
2. Create a whitelist of approved applications in the ThreatLocker console.
3. Configure the whitelist to allow only approved applications to run on the system.
4. Test the whitelist with a pilot group to identify any issues that may arise.
5. Gradually expand the whitelist to the rest of the organization.

Ultimately, neither of these solutions is implementable without minor compromise to convenience. ThreatLocker can be highly inconvenient when trying to update software, while file extension modification, and/or default app changes can be annoying to manage as an administrator. However, be aware all Whitelisting software has its weaknesses any admin should be aware of. (e.g., if you create a path rule, anything you place in that path will bypass!) Here is a good resource for understanding AppLocker bypasses: https://github.com/api0cradle/UltimateAppLockerByPassList. Audit mode is highly recommended before actually blocking!

Conclusion

Implementations of both of these controls can be slow, controversial, and difficult to get executive buy-in for. However, they are highly effective if done correctly. If you need assistance in implementing security controls like the one above feel free to contact us at professionalservices@tridentstack.com or use the form below.