The control and restriction of applications is an important protective measure in a company’s IT security architecture. However, even small configuration errors can have serious consequences. In this article, we show you what you need to bear in mind when configuring application controls and why it is advisable to carry out a penetration test in such an environment.
What role does application control play in the IT security architecture?
It is not new knowledge that applications can be hijacked or misused by attackers. In turn, application control mechanisms can be used to significantly limit the potential attacker’s options from the outset.
Microsoft summarizes the purpose of application control as follows:
“Application control can help mitigate these types of security threats by restricting the applications that users are allowed to run and the code that runs in the System Core (kernel). Application control policies can also block unsigned scripts and MSIs, and restrict Windows PowerShell to run in Constrained Language Mode.”
In other words: Like vulnerability management or system hardening, application control is a measure to reduce the attack surface of the IT infrastructure. Application control is therefore part of the triad of “prevention – detection – response” in the area of preventive IT security measures.
Can a system be compromised despite the use of application control?
The short answer to this question is yes. In the event of an unfavorable or incomplete configuration, an attacker has the opportunity to bypass the application control mechanisms. To show how this works, we asked our experienced pentesting colleagues to get to work and develop possible attack scenarios.
Examples of how application control can be overridden
In the following, we outline two scenarios in which our pentesting team successfully bypassed the application control mechanisms of a widely used product: Carbon Black App Control from VMWare.
How? It is possible to bypass the control mechanisms if, for example, the Windows Script Host is not part of the so-called “ban rules”. Or if the execution of binary files from untrusted directories such as c:\users\public is permitted. We explain both scenarios in the following paragraphs.
Scenario 1: Execution of blocked, unsigned binary files
Applications such as wscript and cscript, which use Jscript.dll as an engine library, can execute scripts with embedded, Base64-serialized binaries. And they can therefore be used by an attacker to bypass the detection mechanisms of Carbon Black App Control.
Here we show how our pentesting team put this into practice and successfully executed blocked, unsigned binaries.
In the first step, we executed the regular AccessChk program. As expected, this was blocked by Carbon Black App Control, as this executable was not explicitly released by Carbon Black. This can be seen in the following screenshot:
In the second step, our pentesters developed a C# application with a function comparable to AccessChk in order to implement a bypass of the blocking configuration in practice. This C# application was then provided with a JScript wrapper using tyranid/DotNetToJScript.
The result: The JScript file could be executed successfully, as can be seen in the figure below – even though our C# application was not enabled in the Carbon Black App Control configuration!
Scenario 2: Bypassing the DLL blocking rules
In the second scenario, our pentesting experts attempted to bypass the DLL blocking rules of Carbon Black App Control. The aim here was to successfully start PowerShell.exe despite the DLL blocking rules and use it to its full extent.
As can be seen in the following screenshot, the configured rules of Carbon Black App Control successfully prevent PowerShell.exe from accessing the clr.dll library. As a result, the execution of PowerShell.exe is blocked.
The following should be taken into account when evaluating this result: In this case, the rules (“ban rules”) only check whether the binary file is signed or not. However, the path from which the application was executed is not checked. This is tantamount to a significant restriction of the security gain that should result from DLL blocking.
Why? It is possible to prevent the loading of certain libraries by simply renaming the target application. The Win32 function LoadLibraryExW already remembers the name clr.dll in the process memory and will therefore not try to load the DLL again.
In the first step, we created a copy of PowerShell_ise.exe:
In the second step, we renamed the binary file accordingly from PowerShell_ise.exe to clr.dll:
In the third step, we used the CreateProcessA function implemented by WScript.Shell.Exec to successfully start the renamed binary file using JScript. The result: The Trovent Pentest team was able to call the PowerShell console. Goal achieved!
Since the missing clr.dll library restricts some functions of PowerShell_ise.exe and the Carbon Black Group Policy can restrict the language mode, the use of PowerShell is restricted overall.
Therefore, in the fourth step, our pentesters created an individually configured runspace to circumvent these restrictions. The following self-developed application was used for this purpose: CustomRunspace.
Custom C# PowerShell Runspace enables the Constrained Language Modes (CLM) in PowerShell to be bypassed on the hardened system.
In this scenario, similar to the first scenario, a JS file was generated and executed using the custom runspace written in C#. Among other things, this checks that CLM has been overridden and that full language mode is available.
Conclusion
Solutions designed to prevent the execution of potentially dangerous programs are a sensible protective measure. However, application control tools are not a panacea! Like any security component, they are susceptible to potential configuration errors.
We therefore recommend the implementation of blocking rules consisting of a combination of authorized, signed binary files and file paths. This effectively minimizes the risks from possible circumvention methods used by attackers.
Now the big question is: How can configuration errors or configuration weaknesses in the application control environment be found at an early stage? The answer is simple: with a penetration test!
A pentest uncovers weak points in the configuration so that these can be rectified proactively and promptly. Our team will of course be happy to assist you with this.
Or use our pentest configurator to get an immediate quote.
What should be done if application control mechanisms are circumvented anyway?
Despite all caution in the configuration of effective application control rules, the compromise of a system cannot be completely ruled out. Therefore, effective and timely detection of an attack or attempted attack is crucial to minimize the potential for damage.
Attacks and attempted attacks can be detected with a system such as Trovent MDR (Managed Detection & Response). You are welcome to test our attack detection system under real conditions.