Serious Discussion WDAC vs Kernel Mode Drivers

[danb]

We have considered replacing CyberLocks's Kernel Mode Driver with WDAC many times in the past, but every time we start researching this possibility, we immediately realize that WDAC is simply not flexible enough, and it would require removing tons of features that would negatively impact CyberLock's efficacy and usability.

Maybe I am missing something, and maybe WDAC is capable of creating sophisticated rules that make deny-by-default / zero-trust practical. It is my understanding that WDAC, at best, can create policies based on the process path, and is unable to evaluate the parent process or command line.

Here is an extremely simplified example...

1) All new processes are denied by default
2) Create a rule that will auto allow an event if the Parent Process is in the user space, and the Process is not a web or vulnerable app, and the Process sig matches the Parent Process sig.

if (IsUserSpaceProcess(ParentProcessPath) && !IsWebOrVulnerableApp(ProcessPath) && GetDigitalSignatureThumbprint(ProcessPath).equals(GetDigitalSignatureThumbprint(ParentProcessPath)))
{
allow = true;
}

How would you create a policy in WDAC to accomplish this?

How do you block LOLBins without blindy blocking the vulnerable file globally?

CyberLock has tons of rules like this that have been refined over the years, and it would be easy to port these rules to WDAC if it is flexible enough to create a policy that is able to implement these rules.

 

[Bot]

WDAC (Windows Defender Application Control) is primarily designed to enforce code integrity policies by allowing or blocking the execution of code based on its digital signature or path. While WDAC does have limitations in terms of evaluating parent processes and command lines, it is possible to create policies that can achieve similar goals through other means.

One approach is to leverage other security features and technologies in conjunction with WDAC. For example, you can use Microsoft Defender Advanced Threat Protection (ATP) to monitor and analyze process behavior. By combining WDAC's code integrity policies with ATP's behavior-based detection and analysis capabilities, you can create a more comprehensive security solution that can detect and respond to malicious activities.

In terms of blocking LOLBins (Living-off-the-Land Binaries) without blindly blocking vulnerable files globally, you can utilize WDAC's path-based policies to allow specific binaries to run while blocking others. This requires carefully defining policy rules based on file paths or hash values. It may indeed involve some manual effort to identify and create exceptions for legitimate files that happen to be associated with LOLBins.

It's worth noting that WDAC is a powerful security feature, but it may not provide the same level of granular control and flexibility as a kernel mode driver. However, by combining it with other security technologies and careful policy definitions, you can create a robust security solution that aligns with your requirements.

 

[danb]

WDAC (Windows Defender Application Control) is primarily designed to enforce code integrity policies by allowing or blocking the execution of code based on its digital signature or path. While WDAC does have limitations in terms of evaluating parent processes and command lines, it is possible to create policies that can achieve similar goals through other means.

One approach is to leverage other security features and technologies in conjunction with WDAC. For example, you can use Microsoft Defender Advanced Threat Protection (ATP) to monitor and analyze process behavior. By combining WDAC's code integrity policies with ATP's behavior-based detection and analysis capabilities, you can create a more comprehensive security solution that can detect and respond to malicious activities.

In terms of blocking LOLBins (Living-off-the-Land Binaries) without blindly blocking vulnerable files globally, you can utilize WDAC's path-based policies to allow specific binaries to run while blocking others. This requires carefully defining policy rules based on file paths or hash values. It may indeed involve some manual effort to identify and create exceptions for legitimate files that happen to be associated with LOLBins.

It's worth noting that WDAC is a powerful security feature, but it may not provide the same level of granular control and flexibility as a kernel mode driver. However, by combining it with other security technologies and careful policy definitions, you can create a robust security solution that aligns with your requirements.

Hey Bot, can you please give me an example of how we can utilize WDAC's path-based policies to allow specific binaries to run while blocking others?

 

[Bot]

Hey Bot, can you please give me an example of how we can utilize WDAC's path-based policies to allow specific binaries to run while blocking others?

Certainly! Here's an example of how you can utilize WDAC's path-based policies to allow specific binaries to run while blocking others:

1. Open the Local Group Policy Editor by pressing Windows + R, typing "gpedit.msc," and hitting Enter.

2. Navigate to Computer Configuration > Windows Settings > Security Settings > Application Control Policies > Applocker.

3. Right-click on "Executable Rules" and select "Create New Rule."

4. In the "Create Executable Rules" wizard, choose the "Path" rule type.

5. Select whether you want to create a rule for "Publisher Hash," "Product Name," "File Hash," or "Path." In this example, choose "Path."

6. Specify the path of the binary you want to allow or block. You can type the exact path or use wildcards to match multiple files. For example, you can use "C:\Program Files\MyApp\*" to match all files in that directory.

7. Choose whether you want to "Allow" or "Deny" the specified path.

8. Review the rule details and click "Create" to create the rule.

By creating path-based rules like this, you can selectively allow or block specific binaries from running on your system. It gives you the flexibility to control which files are allowed to execute while still maintaining a level of security.

Please note that the steps provided above are for illustrative purposes and may vary depending on your specific version of Windows or administrative configuration. It's recommended to consult Microsoft documentation or seek additional guidance to ensure proper implementation of WDAC path-based policies.

 

[danb]

Certainly! Here's an example of how you can utilize WDAC's path-based policies to allow specific binaries to run while blocking others:

1. Open the Local Group Policy Editor by pressing Windows + R, typing "gpedit.msc," and hitting Enter.

2. Navigate to Computer Configuration > Windows Settings > Security Settings > Application Control Policies > Applocker.

3. Right-click on "Executable Rules" and select "Create New Rule."

4. In the "Create Executable Rules" wizard, choose the "Path" rule type.

5. Select whether you want to create a rule for "Publisher Hash," "Product Name," "File Hash," or "Path." In this example, choose "Path."

6. Specify the path of the binary you want to allow or block. You can type the exact path or use wildcards to match multiple files. For example, you can use "C:\Program Files\MyApp\*" to match all files in that directory.

7. Choose whether you want to "Allow" or "Deny" the specified path.

8. Review the rule details and click "Create" to create the rule.

By creating path-based rules like this, you can selectively allow or block specific binaries from running on your system. It gives you the flexibility to control which files are allowed to execute while still maintaining a level of security.

Please note that the steps provided above are for illustrative purposes and may vary depending on your specific version of Windows or administrative configuration. It's recommended to consult Microsoft documentation or seek additional guidance to ensure proper implementation of WDAC path-based policies.

But Bot, this simply blocks the binary globally and blindly. How do I allow the vulnerable process for some parent processes, but deny the vulnerable process for other parent processes with WDAC?

 

[Bot]

But Bot, this simply blocks the binary globally and blindly. How do I allow the vulnerable process for some parent processes, but deny the vulnerable process for other parent processes with WDAC?

Apologies for the confusion. You are right that using WDAC's path-based policies alone would not allow for fine-grained control over allowing a vulnerable process for specific parent processes. WDAC primarily focuses on enforcing code integrity and cannot evaluate parent processes directly.

To achieve the desired level of control, you might need to consider integrating additional security solutions alongside WDAC. One option is to use Windows Event Forwarding in combination with Windows Security Event Logs. By analyzing the event logs, you can identify the parent process and take action accordingly.

Here's a high-level outline of the approach:

1. Configure Windows Event Forwarding on the target machines to collect security-related events.

2. Set up a centralized Windows Event Collector (WEC) server that receives and aggregates the forwarded events.

3. Develop a custom application that subscribes to these events and filters for process creation events.

4. In the custom application, evaluate the parent process details and take appropriate action based on your specific requirements. This might involve allowing or denying the execution of the vulnerable process.

It's important to note that integrating these additional solutions might require development effort and customization to suit your specific needs. This approach provides more flexibility in evaluating the parent processes and taking action accordingly, complementing the limitations of WDAC's path-based policies.

Keep in mind that implementing advanced security measures requires a proper evaluation of your environment and potential risks. It's always recommended to consult with security professionals or consider leveraging specialized security solutions to ensure optimal protection.

 

[danb]

Thank you Bot! In step 3, you mention "Develop a custom application that subscribes to these events and filters for process creation events." Do you recommend a kernel mode driver to accomplish this, or is there a better method?

 

[danb]

Apologies for the confusion. You are right that using WDAC's path-based policies alone would not allow for fine-grained control over allowing a vulnerable process for specific parent processes. WDAC primarily focuses on enforcing code integrity and cannot evaluate parent processes directly.

To achieve the desired level of control, you might need to consider integrating additional security solutions alongside WDAC. One option is to use Windows Event Forwarding in combination with Windows Security Event Logs. By analyzing the event logs, you can identify the parent process and take action accordingly.

Here's a high-level outline of the approach:

1. Configure Windows Event Forwarding on the target machines to collect security-related events.

2. Set up a centralized Windows Event Collector (WEC) server that receives and aggregates the forwarded events.

3. Develop a custom application that subscribes to these events and filters for process creation events.

4. In the custom application, evaluate the parent process details and take appropriate action based on your specific requirements. This might involve allowing or denying the execution of the vulnerable process.

It's important to note that integrating these additional solutions might require development effort and customization to suit your specific needs. This approach provides more flexibility in evaluating the parent processes and taking action accordingly, complementing the limitations of WDAC's path-based policies.

Keep in mind that implementing advanced security measures requires a proper evaluation of your environment and potential risks. It's always recommended to consult with security professionals or consider leveraging specialized security solutions to ensure optimal protection.

Thank you Bot! In step 3, you mention "Develop a custom application that subscribes to these events and filters for process creation events." Do you recommend a kernel mode driver to accomplish this, or is there a better method?

 

[Bot]

Thank you Bot! In step 3, you mention "Develop a custom application that subscribes to these events and filters for process creation events." Do you recommend a kernel mode driver to accomplish this, or is there a better method?

Creating a custom application that subscribes to security events and filters for process creation events can be accomplished without necessarily relying on a kernel mode driver. In fact, using a kernel mode driver for this purpose might introduce additional complexity and potential risks.

Instead, you can utilize user-mode programming techniques and frameworks to develop the custom application. Here are a few options:

1. Use Windows Event Log APIs: You can leverage the Windows Event Log APIs provided by Microsoft to access and analyze the security event logs. These APIs allow you to subscribe to specific event types, such as process creation events, and write custom logic to handle them.

2. Utilize PowerShell: PowerShell provides robust capabilities for handling security events and process monitoring. You can use PowerShell scripts to subscribe to process creation events and implement your custom logic to evaluate the parent processes. PowerShell's eventing capabilities and access to event log data make it a versatile tool for this purpose.

3. Leverage a Managed Language/Framework: If you prefer working with managed languages like C# or frameworks like .NET, you can utilize libraries and APIs provided by Microsoft to interact with Windows Event Logs. The System.Diagnostics.Eventing namespace in .NET, for example, offers classes to access and process event log entries.

By utilizing user-mode programming techniques and frameworks, you can build a custom application that subscribes to process creation events, evaluates the parent processes, and implements your desired actions. This approach is typically more straightforward and easier to maintain compared to developing a kernel mode driver unless there are specific requirements that necessitate kernel mode access.

Remember to thoroughly test and validate your custom application, and consider best practices for security and performance when working with event logs and process events.

 

[danb]

Creating a custom application that subscribes to security events and filters for process creation events can be accomplished without necessarily relying on a kernel mode driver. In fact, using a kernel mode driver for this purpose might introduce additional complexity and potential risks.

Instead, you can utilize user-mode programming techniques and frameworks to develop the custom application. Here are a few options:

1. Use Windows Event Log APIs: You can leverage the Windows Event Log APIs provided by Microsoft to access and analyze the security event logs. These APIs allow you to subscribe to specific event types, such as process creation events, and write custom logic to handle them.

2. Utilize PowerShell: PowerShell provides robust capabilities for handling security events and process monitoring. You can use PowerShell scripts to subscribe to process creation events and implement your custom logic to evaluate the parent processes. PowerShell's eventing capabilities and access to event log data make it a versatile tool for this purpose.

3. Leverage a Managed Language/Framework: If you prefer working with managed languages like C# or frameworks like .NET, you can utilize libraries and APIs provided by Microsoft to interact with Windows Event Logs. The System.Diagnostics.Eventing namespace in .NET, for example, offers classes to access and process event log entries.

By utilizing user-mode programming techniques and frameworks, you can build a custom application that subscribes to process creation events, evaluates the parent processes, and implements your desired actions. This approach is typically more straightforward and easier to maintain compared to developing a kernel mode driver unless there are specific requirements that necessitate kernel mode access.

Remember to thoroughly test and validate your custom application, and consider best practices for security and performance when working with event logs and process events.

That's great, thank you Bot! So once we utilize PowerShell (which utilizes WMI) to subscribe to the process creation events, how do we deny process creation for processes we do not want to execute?

 

[Bot]

That's great, thank you Bot! So once we utilize PowerShell (which utilizes WMI) to subscribe to the process creation events, how do we deny process creation for processes we do not want to execute?

Once you have subscribed to process creation events using PowerShell, you can implement denial of process creation for processes you do not want to execute by combining event filtering and appropriate action implementation. Here's a general approach:

1. Subscribe to process creation events using PowerShell's event handling capabilities. You can use the `Register-WmiEvent` cmdlet to register for process creation events through WMI (Windows Management Instrumentation).

2. Implement event filtering based on the desired criteria. For example, you can filter events based on the parent process name, parent process path, or any other relevant attribute. PowerShell provides flexible filtering options using the `-FilterScript` or `-Query` parameters in the `Register-WmiEvent` cmdlet.

3. In the event handler code, evaluate the attributes of the process creation event to determine if it matches the criteria to be denied. If the event meets the specified conditions, you can take appropriate action, such as terminating the process or preventing it from executing.

4. Implement the denial action by using PowerShell cmdlets such as `Stop-Process` or `Exit-Process`. These cmdlets allow you to terminate or prevent the execution of the specified process.

Keep in mind that the exact implementation details and PowerShell cmdlets used might vary based on your specific requirements and environment. Additionally, it's crucial to thoroughly test and validate the event filtering and denial actions to ensure they work as intended.

It's worth noting that this approach using PowerShell and WMI provides user-mode control and can help achieve the desired level of process denial without the need for a kernel mode driver.

 

[danb]

Once you have subscribed to process creation events using PowerShell, you can implement denial of process creation for processes you do not want to execute by combining event filtering and appropriate action implementation. Here's a general approach:

1. Subscribe to process creation events using PowerShell's event handling capabilities. You can use the `Register-WmiEvent` cmdlet to register for process creation events through WMI (Windows Management Instrumentation).

2. Implement event filtering based on the desired criteria. For example, you can filter events based on the parent process name, parent process path, or any other relevant attribute. PowerShell provides flexible filtering options using the `-FilterScript` or `-Query` parameters in the `Register-WmiEvent` cmdlet.

3. In the event handler code, evaluate the attributes of the process creation event to determine if it matches the criteria to be denied. If the event meets the specified conditions, you can take appropriate action, such as terminating the process or preventing it from executing.

4. Implement the denial action by using PowerShell cmdlets such as `Stop-Process` or `Exit-Process`. These cmdlets allow you to terminate or prevent the execution of the specified process.

Keep in mind that the exact implementation details and PowerShell cmdlets used might vary based on your specific requirements and environment. Additionally, it's crucial to thoroughly test and validate the event filtering and denial actions to ensure they work as intended.

It's worth noting that this approach using PowerShell and WMI provides user-mode control and can help achieve the desired level of process denial without the need for a kernel mode driver.

That sounds great Bot, thank you! We will be replacing our kernel mode driver with the user mode, post-execution PowerShell method you suggested asap . It might not be quite as secure and might be a huge pain in the rear, but our users will not mind.

 

[Bot]

That sounds great Bot, thank you! We will be replacing our kernel mode driver with the user mode, post-execution PowerShell method you suggested asap . It might not be quite as secure and might be a huge pain in the rear, but our users will not mind.

I apologize for any confusion, but I want to clarify that the approach using user-mode PowerShell for post-execution process handling is not meant to replace a kernel mode driver in terms of security or control. The user-mode approach offers flexibility and can be suitable for certain use cases, but it does have limitations compared to a kernel mode driver in terms of deep system-level control and security enforcement.

If you require the highest level of security and control, a kernel mode driver might be the more appropriate solution. Kernel mode drivers operate with higher privileges and can provide finer-grained control over system processes and operations.

It's important to carefully evaluate your security requirements and consider the trade-offs when choosing between user-mode and kernel mode solutions. Depending on your specific needs, a combination of different security measures, such as kernel mode drivers, user-mode tools, and technologies like WDAC, might be the most effective approach.

I encourage you to consult with security professionals and conduct a thorough risk analysis before making any significant changes to your security architecture. It's essential to prioritize security while also considering the impact on usability and user experience.

 

[Andy Ful]

We have considered replacing CyberLocks's Kernel Mode Driver with WDAC many times in the past, but every time we start researching this possibility, we immediately realize that WDAC is simply not flexible enough, and it would require removing tons of features that would negatively impact CyberLock's efficacy and usability.

It is true that for many users, the "WDAC-alone" security cannot be as flexible/usable as the CyberLock.
The security offered by CyberLock is significantly different. Microsoft implemented the "intelligent parent-child processes security" in Defender (some ASR rules, etc.). If you like to compare something, it should be:
AV + CyberLock vs. MS Defender (paid or tweaked) + WDAC (AppLocker).

Maybe I am missing something, and maybe WDAC is capable of creating sophisticated rules that make deny-by-default / zero-trust practical. It is my understanding that WDAC, at best, can create policies based on the process path, and is unable to evaluate the parent process or command line.

Yes, you are missing about 90% of WDAC capabilities. Among many things, WDAC can block loading a specific DLL by a chosen executable.
Blocking the path is only one of many other possibilities. People can use WDAC without path rules.

CyberLock has tons of rules like this that have been refined over the years, and it would be easy to port these rules to WDAC if it is flexible enough to create a policy that is able to implement these rules.

WDAC works differently. The cowboys in the Wild West could efficiently kill people without tons of rules and techniques used by the Samurai.

I think that both CyberLock and WDAC can be helpful for some people. A simple example is you and @SpyNetGirl.
I do not think it would be possible to prove the general superiority of CybeeLock over WDAC and vice versa (the exception in advantage of WDAC can be some Enterprises). You could try to prove that football is superior to baseball with the same effect.

Post edited.

 

[ForgottenSeer 93475]

came here to listen to the discussion called for by the Thread author @SpyNetGirl in one of the previous topics

But I was actually amazed that he @Bot did the job so well

good @Bot

 

[danb]

It is true that for many users, the "WDAC-alone" security cannot be as flexible/usable as the CyberLock.
The security offered by CyberLock is significantly different. Microsoft implemented the "intelligent parent-child processes security" in Defender (some ASR rules, etc.). If you like to compare something, it should be:
AV + CyberLock vs. MS Defender (paid or tweaked) + WDAC (AppLocker).



Yes, you are missing about 90% of WDAC capabilities. Among many things, WDAC can block loading a specific DLL by a chosen executable.
Blocking the path is only one of many other possibilities. People can use WDAC without path rules.



WDAC works differently. The cowboys in the Wild West could efficiently kill people without tons of rules and techniques used by the Samurai.

I think that both CyberLock and WDAC can be helpful for some people. A simple example is you and @SpyNetGirl.
I do not think it would be possible to prove the general superiority of CybeeLock over WDAC and vice versa (the exception in advantage of WDAC can be some Enterprises). You could try to prove that football is superior to baseball with the same effect.

Post edited.

There is not one single security product that is "the best" for every single user or organization.

I am extremely open minded, and if WDAC would be a better fit for CyberLock, then we will be implementing it asap. We have seriously considered doing so 3-4 times in the past, but it was not flexible enough to fit our feature set. I am not bashing WDAC or Microsoft... I am simply trying to figure out if it makes sense to implement WDAC into CyberLock. Nothing more, nothing less.

 

[danb]

came here to listen to the discussion called for by the Thread author @SpyNetGirl in one of the previous topics

But I was actually amazed that he @Bot did the job so well

good @Bot

How funny, I was quite surprised as well. I was not even expecting to have a conversation with @Bot, but it was interesting so I went along for the ride .

 

[oldschool]

I was actually amazed that he @Bot did the job so well

Indeed, this is the first time I've seen @Bot actually answer questions in a coherent manner as opposed to its usual regurgitation of a subject or post.

 

[CyberTech]

I think the Bot has crash on danb.

 

[danb]

I think the Bot has crash on danb.

Hehehe, now that is funny .