AppLocker, Application Control, and Code Signing

In an enterprise environment, it is critical to keep control over what software is installed and what software is being kept out of the environment – not only to keep an overview of what software is available but also to help fight against threats such as malicious scripts or malware such as ransomware.

But how can code signing and application control help you secure your environment in a better way and how can it be implemented? What do you need to do when planning for implementing an application control solution and what built-in application control solutions are available on Windows operating systems?

We’ll explore this and much more in this chapter about AppLocker, application control, and code signing. In this chapter, you will get a deeper understanding of the following topics:

• Preventing unauthorized script execution with code signing
• Controlling applications and scripts
• Getting familiar with...

Technical requirements

To get the most out of this chapter, ensure that you have the following:

• PowerShell 7.3 and above
• Installed Visual Studio Code
• A virtual machine running Windows 10 or above for test purposes
• Access to the GitHub repository for Chapter11: https://github.com/PacktPublishing/PowerShell-Automation-and-Scripting-for-Cybersecurity/tree/master/Chapter11

Preventing unauthorized script execution with code signing

If you want to verify that the executed script is legit code and is allowed to be executed by your company, you want to implement a proper code-signing strategy. It’s a brilliant way to protect your regularly executed scripts against tampering – or at least if someone were to tamper with your scripts, they would not be executed if your environment is configured in the right way.

It’s important to note that dynamic runtimes can pose a common blind spot when implementing application control policies. While PowerShell made a significant impact to ensure that the PowerShell runtime can be restricted by application control rules, other dynamic runtimes such as Python, Node, Perl, PHP, and more may still allow you to run unrestricted code, which might present a vulnerability if it’s not managed appropriately. If other dynamic runtimes are not needed on your clients, it’s better to block them...

Controlling applications and scripts

An application control solution not only protects against unauthorized PowerShell scripts; it can also be used to define which applications, executables, and DLLs are allowed to run in the environment.

It is important to keep in mind that while PowerShell attacks may seem like a concern for many professionals, they represent a relatively small portion of the malware that makes its way onto systems. It is essential to not overlook the danger posed by traditional executable and DLL attacks.

Application control solutions often provide a possibility to also just prohibit single unwanted applications, but the desired outcome should always be to prohibit everything and configure all allowed applications. As you may recall from Chapter 5, PowerShell Is Powerful – System and API Access, even if you block PowerShell.exe in your environment, it is still possible to run it by just using the native API functions, irrespective of whether it makes...

Getting familiar with Microsoft AppLocker

AppLocker is Microsoft’s successor to SRP and was introduced with Windows 7. You can use it to extend SRP’s function, as well as its features.

In comparison to SRP, AppLocker policies can be scoped to specific users or groups and it’s also possible to audit before you enforce rules. It is possible to deploy SRP and AppLocker policies in parallel in various ways; take a look at the following documentation:

• Use AppLocker and Software Restriction Policies in the same domain: https://learn.microsoft.com/en-us/windows/security/application-security/application-control/windows-defender-application-control/applocker/use-applocker-and-software-restriction-policies-in-the-same-domain
• Use Software Restriction Policies and AppLocker policies: https://learn.microsoft.com/en-us/windows/security/application-security/application-control/windows-defender-application-control/applocker/using-software-restriction-policies-and...

Exploring Windows Defender Application Control

With its introduction in Windows 10, Windows Defender Application Control (WDAC) allows organizations to control the applications and drivers that are used in their environment. WDAC is implemented as part of the operating system and was also known under the name Device Guard.

It is recommended to use WDAC in combination with virtualization-based security (VBS). When used with VBS, WDAC’s security is enforced by hypervisor isolation, which makes it even harder for an adversary to circumvent your configured application control restrictions. While VBS is technically not required for WDAC, it can significantly enhance your overall system security and should always be enabled if possible.

In comparison to AppLocker rules, WDAC rules are deployed to the whole machine and affect every user logging on to this machine. But WDAC also offers more features and is considered more secure than AppLocker. Its principle is to trust nothing...

How does PowerShell change when application control is enforced?

When application control is enforced, PowerShell acts as a safeguard to prevent the misuse of its features by potential adversaries. By proactively implementing application control measures, PowerShell ensures that its powerful scripting language cannot be easily abused by attackers to bypass imposed restrictions.

PowerShell can be restricted in several ways, including disabling the ability to run PowerShell scripts or only allowing signed PowerShell scripts to run.

In Chapter 5, PowerShell Is Powerful – System and API Access, we discussed how it is possible to use PowerShell to run arbitrary .NET code or even execute compiled code if the system is not restricted. This can make it very difficult to protect against malicious code. With application control enforced, it’s possible to eliminate unconstrained code execution methods such as Add-Type, arbitrary .NET scripting, and other options that are typically...

Further reading

If you want to explore some of the topics that were mentioned in this chapter, take a look at the following resources:

Certificate operations:

• New-SelfSignedCertificate: https://docs.microsoft.com/en-us/powershell/module/pki/new-selfsignedcertificate
• Set-AuthenticodeSignature: https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.security/set-authenticodesignature
• Get-AuthenticodeSignature: https://docs.microsoft.com/en-us/powershell/wwmodule/microsoft.powershell.security/get-authenticodesignature

CI/CD:

• CI/CD: The what, why, and how: https://resources.github.com/ci-cd/
• About continuous integration: https://docs.github.com/en/actions/automating-builds-and-tests/about-continuous-integration

Application control:

• Application Control for Windows: https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-defender-application-control/windows-defender-application-control
• Authorize...

The rest of the chapter is locked