author: Kim Oppalfens
This innovative solution addresses the complex challenges faced by enterprises, bringing together Realtime script execution, application installation, CMPivot which offers realtime data collection, Autopilot integration with task sequences, custom inventory, flexible targeting of your deployments, Configuration Baselines, Software metering, customizable reporting, and the simple deployment of files without having to worry about securing the credentials needed for authentication.
For managers that read this, I’ll briefly add what not having these means throughout the rest of the post, but in short, it means your people will have to spend time coding workarounds and/or introduce cost to workaround these limitations. This in turn means knowledge transfer becomes harder as you can’t just hire someone that knows the coded/introduced workarounds like you can with a popular off the shelf tool.
This post is heavily inspired on a breakout session Tom Degreef and I have been presenting on at several events. One of the things heand I stress during this session is that this is geared towards both Azure AD (aka Entra ID) - Only devices as well as “Hybrid” joined devices. A couple of strong misconceptions still survive in the Microsoft systems management world.
One of the strongest ones is the tie that people tend to make between Azure AD only devices and the available Microsoft Systems management solutions. It’s true that Active Directory Group policies are not available to you when managing Azure AD only devices. Frequently this introduces the split up between “on-prem” tools and “cloud” tools. That split-up is confusing in this respect as it just defines where the service is most often offered from, it does NOT define what it can manage. So, repeat after me,
Microsoft Configuration Manager by itself and in a Co-Management setup are perfectly capable of managing Azure AD only devices.
The flow of an Azure AD only client authenticating against a Configuration Manager backend is documented clearly on Micosoft’s documentation page
A second misconception that appears to be out there is that managing clients with Configuration Manager introduces the need for VPN style solutions to connect to the Configuration Manager backend. So, repeat after me once more,
ConfigMgr can manage clients directly over the Internet, the method to do that, that is most future ready is, by introducing a Cloud Management gateway.
The same section of Microsoft’s documentation introduces customers to the Cloud Management gateway
The documentation for planning, setup and managing a CMG is quite extensive.
The Cloud Management Gateway does come at a cost, all be it a small one in most cases. There’s a recurring monthly fee for the service and a cost for the consumed network traffic known as egress.
In this article, we delve into the ten key benefits of Microsoft Endpoint Manager Co-Management for workstations. All of these features complement what Intune can offer today, none of them prevent an organization from handling the needs that can be covered by Intune to be covered by Intune. Server workloads are not one of the features we list although they’re equally a good reason to keep a ConfigMgr environment around.
For each feature we’ll detail whether it needs Co-Management, ConfigMgr cloud attach and whether content is required. When content is required the solution massively benefits from yet another ConfigMgr cloud feature called the Cloud Management Gateway. The Cloud Management Gateway offers a cost-effective method for making ConfigMgr content available from anywhere. The need to be able to work from anywhere (Which most of the times means, work from home) is one of the things that has really taken of in the past several years and is considered by many to be a core requirement of modern work environments.
MEM Co-Management allows IT administrators to execute scripts on endpoints in real-time. This capability provides unparalleled flexibility in managing and troubleshooting devices. Whether it’s resolving issues promptly or implementing critical updates swiftly, the real-time script execution feature empowers administrators to take immediate actions, reducing downtime and improving overall system health. This functionality can be run against an individual endpoint or against a collection of devices. When running against a single device it integrates with the Intune portal, running it against multiple devices aka bulk actions is a feature that, unfortunately requires us to move back to the ConfigMgr admin ui as Intune doesn’t support that (yet).
The ability to install applications in real-time is crucial for maintaining a secure and up-to-date IT environment. With MEM Co-Management, administrators can initiate the installation of applications across devices seamlessly. This ensures that all endpoints are equipped with the latest software, enhancing security, and standardizing the user experience. Realtime in this respect means applications installs start within minutes. This unfortunately is only true for applications defined within Configuration Manager. (People might recognize this functionaly from an Ignite demo years ago.) These application do however appear in the Intune Company portal app alongside the Intune deployed applications.
CMPivot is a powerful feature that allows administrators to query and retrieve real-time information from devices. This functionality enables rapid assessment and response to security threats, performance issues, and compliance concerns. By leveraging CMPivot, organizations can proactively address potential problems, strengthening their overall security posture. This functionality allows Systems Management admins to provide their management with answers to information around the workstation population in a matter of minutes. Not having this option might introduce delays in decession making or force decission making with less information.
This functionality can be run against an individual endpoint or against a collection of devices. When running against a single device it integrates with the Intune portal, running it against multiple devices aka bulk actions is a feature that, unfortunately requires us to move back to the ConfigMgr admin ui as Intune doesn’t support that (yet).
Microsoft has released functionality to do this in Intune only as an add-on on top of Intune or as part of Intune suite. The Intune only functionality is currently limited to targetting individual devices.
The integration of Autopilot with task sequences in MEM Co-Management streamlines the deployment and provisioning of devices. This ensures a consistent and efficient onboarding experience for end-users. The automated processes reduce manual intervention, minimizing errors and enhancing overall IT productivity. This offers a number of options not available with Intune only and Autopilot, like controlling the order of application installs and embed scripts directly in the process while making sure they finish by the time the Autopilot process has completed. Tasksequences equally don’t have the Windows Autopilot limit that prevents organizations from mixing MSI and setup.exe based installations.
MEM Co-Management offers the capability to gather custom inventory information from devices. This flexibility allows organizations to tailor data collection to meet specific business needs. Custom inventory enhances the depth of insights available to administrators, facilitating more informed decision-making and strategic planning. All of the Inventory can then be used in grouping devices in collections. ConfigMgr native inventory and custom inventory integrate into the Intune Portal and can be consumed from there.
The flexibility in targeting devices based on various criteria is a standout feature of MEM Co-Management. Administrators can target specific groups of devices or users, enabling a granular approach to management. This ensures that policies, updates, and configurations are applied precisely where needed, avoiding unnecessary disruptions to unaffected devices. This flexible targeting is done using a rules based system that fully integrates with the custom inventoy feature described above. The ConfigMgr groups (aka collections) created this way sync up with Azure Ad groups. This makes sure that this flexibility is available to both ConfigMgr as Intune based deployments.
Configuration Baselines provide a standardized method for evaluating and enforcing compliance across devices. MEM Co-Management allows administrators to define and implement configuration baselines, ensuring that devices adhere to organizational policies. This consistency enhances security and reduces the risk of non-compliance. Baselines have a number of “providers” of which setting registry keys is just one. This allows the setting and maintaing of specific values in custom registry keys without having to adhere to script authoring and/or figuring out a way to re-validate the value hasn’t changed.
Software metering capabilities in MEM Co-Management empower organizations to monitor and control the usage of applications. This feature helps in optimizing software licensing costs by identifying underutilized or unused applications. By gaining insights into software usage patterns, administrators can make informed decisions regarding licensing and resource allocation.
MEM Co-Management offers robust reporting capabilities that can be customized to meet the specific needs of an organization. Administrators can generate detailed reports on device compliance, security vulnerabilities, and application usage. Customizable reporting enhances transparency and accountability, supporting evidence-based decision-making. ConfigMgr reports and custom built reports can be made available over an Azure AD application proxy so that Managers and Sysadmins can access them from anywhere. (Regular end users aren’t the only folks working from home.)
Efficient software distribution is a cornerstone of effective IT management. MEM Co-Management facilitates the deployment of software distribution packages across devices, ensuring timely updates and patches. This capability streamlines the maintenance of a secure and up-to-date IT infrastructure. ConfigMgr and Intune both have abilities to deploy actual applications, but neither of their mechanisms are very well suited to just distribute a number of files, like templates.
One could script the copying of these files or embed them into a “fake” application, but both generate overhead and potential headscratching around protecting the authentication flow involved in this.
We’ve received the feedback a number of times that this doesn’t appear to be in line with Microsoft’s longer term goals. We can’t comment on what Microsoft’s long term goals are, other than that we expect it’s to make a profit, that’s their responsibility.
Microsoft has stated recently that Co-Management isn’t an end-goal for them. They’ve equally mentioned that they’re aware there’s gaps and have now started a renewed effort with Intune Suite to close some of those gaps. We currently interpret the “ This is not our end goal. “ similar to what we expect from Microsoft on the identity front. We don’t expect Microsoft wants to run 2 Identity Platforms (Active Directory Domain Services (onprem) and Azure AD/Entra ID (Cloud)) forever, but we don’t expect either one to disappear in the short run.
When all those gaps will be closed and at what cost remains to be seen. This article details the situation as it is at the start of 2024, close to 9 years after Windows 10 was released or close to 14 years after the Intune service was introduced to customers.
In conclusion, Microsoft Endpoint Manager Co-Management stands as a comprehensive solution, included in your Intune core license grant, that empowers organizations to navigate the complexities of modern IT management for both Azure AD Only and Hybrid devices. As one attendee at a conference put it,
“Configuration Manager should be the last server in your Active Directory environment you shut down! Just about 5 minutes before you decommission your last Domain Controller.”
Tom and I consider it a very viable opion in managing Windows endpoints (Workstations and Servers alike). From real-time script execution through customizable reporting to custom Inventory each feature contributes to a more efficient, secure, and responsive device management environment. By embracing MEM Co-Management, organizations can unlock a new level of agility and effectiveness in meeting the evolving demands of the digital landscape.
Mature Systems Management doesn’t escape the need for people to work from home, nor does it escape any of the needs that we’ve all known for years if not decades in this field. In today’s risky onlne world doing less systems management just isn’t a viable option, the needs for a properly controlled endpoint have heightened over the years not lowered.
In a world where the mantra is (still) “Do more with less” replacing a bunch of functionality that is readilly available with custom developed solutions just doesn’t feel like something a mature organization would do.
]]>Last year our training sold out, with close to 10 people ending up on the waiting list. We’ve given the people on the waiting list a little leadtime, but the registrations are now officially open. We’ve chosen to partner up with ViaMonstra to allow us to focus even more on the content and less on the training platform that we need to build extending labs.
Tom and I have been investing time in application allowlisting in general and Windows Defender Application control in particular. This training is our yearly event where we pass on everything we’ve learned over the years.
The training was previously promoted by Jeffrey Sutherland one of the thought leaders at Microsoft in the platform security space and responsible for WDAC. That was over 2 years ago, we’ve learned a ton since then, done numerous presentations, got busy developping stuff and integrated all of that knowledge in a 10-module training.
If you are looking to use WDAC or just want to develop your WDAC skill set, consider this course. @TheWMIGuy has a wealth of expertise that he and @TomDegreef have built up.
— Jeffrey Sutherland (@J3ffr3y1974) October 1, 2021
There’s 6 weeks left before we kick off the training, so 6 weeks to grab your seat, don’t delay!
You can find the (Mastering Windows Defender Application Control Using ConfigMgr and Intune Masterclass on the ViaMonstra website)[https://academy.viamonstra.com/courses/mastering-windows-defender-application-control]
This Live Online Training runs for five days and includes:
Dates and start times for the next 5-Day Masterclass:
Feel free to contact us on Twitter, Mail (kim.oppalfens@oscc.be), Teams or LinkedIn. A direct registration form can be found here: (WDAC Training)[https://academy.viamonstra.com/order?ct=22f35e2c-9f6f-4202-90dd-e908dc3e3698]
If you need an invoice to register, please email Ami (Ami Arwidmark ami@mirolus.com) with the following info, and she can generate an invoice:
After about 6 months into the year, I had a thought exercise as to how that has progressed from our view.
For us the next major event is our WDAC training starting in september. We’re still offering the training at the bargain price we introduced it at in 2021, 1395€ or 1695$. The training was previously shared by Jeffrey Sutherland one of the thought leaders at Microsoft in the platform security space and responsible for WDAC>
If you are looking to use WDAC or just want to develop your WDAC skill set, consider this course. @TheWMIGuy has a wealth of expertise that he and @TomDegreef have built up.
— Jeffrey Sutherland (@J3ffr3y1974) October 1, 2021
The training has now been filled to 50% of its capacity. With about 3 months left before it kicks off, there is still some time to register. When we’re at capacity we will close registrations (and open up preregisrations for 2024 as we won’t re-run it this year.), so don’t delay your registration.
This training is offered at the bargain price of 1395€ or 1695$ as a way to actively promote #WDAC. Each module will be presented live and will run for about 2 hours. Trainings will run twice a week (Tuesdays and Thursdays) at 7PM CET (10AM PST / 1PM EST) for 5 weeks.
students will get access to a personal online lab environment to run exercices that are specifically crafted for this training. Once the training is over, students will be able to download the lab offline for continued access.
A collaboration channel will be available during and after this training, for questions, follow-up and sharing experiences amongst people that are working on a similar project.
The training will start on Tuesday 19th of September 2023 and will finish on Thursday the 19th of October 2023. Dates:
Feel free to contact us on Twitter, Mail (kim.oppalfens@oscc.be), Teams. A registration form and additional info can be found here: (WDAC Training)[https://www.oscc.be/training]
]]>This series uses Microsoft Defender for Endpoint as input on threats that surfaced in the month. More specifically we’ll look at the Threat Analytics page and the Threat Campaigns that are analyzed on there. Based on the analyst reports we’re doing our best to assess whether an application control implementation would have stopped this specific campaigns.
In our assessment we look at a couple of different common implementation strategies of Microsoft application control technologies. The implementations we take into consideration are Applocker setups we’ve seen a number of times, the WDAC implementations are a mix of implementations we’ve seen with possible implementations we’ve imagined.
In both technologies we assume your users are NOT local administrators. Implementing an application control solution when not having covered this basic measure seems counter-intuitive.
Additionally, we look at the report and what happens prior to the hands-on-keyboard phase of a campaign, if one exist. If a hands-on-keyboard phase exists and your implementation does not block scripts and/or dll’s than we assume the threat actor behind the keyboard can easily circumvent your policy by porting their tools to Powershell or dll.
January 2023 had 10 threat campaigns in Microsoft Defender for Endpoint analyzed. 2 Threat campaigns did not involve executing code on client systems, so there’s no reasonable expectation that an application control technology could stop this. We mark these campaigns as out-of-scope for our analysis and statistics. 1 Threat campaign lacked enough details for us to make an informed decission as to whether an application control implementation could have stopped the campaign from wreaking havoc. We mark these campaigns as out-of-scope for our analysis and statistics.
The 7 other campaigns would have all been stopped by any Windows Defender Application Control implementation enforcing the integrity of scripts.
Out of these 7, 3 campaigns made use of dll’s to evade app control implementation that do not enforce DLL rules. 1 campaign was PowerShell based, evading application control implementations that do not enforce Script Enforcement aka PowerShell Constrained language mode.
Summary: a perfect score for the WDAC team in february, provided you don’t disable script enforcement. Disabling Script enforcement would’ve opened you up to 1 campaign.
This campaign focuses on credential phishing. A technique that can’t be stopped by application control technologies. This one is specifically a campaign that tries to MITM MFA authentication. As a result we score it with -1, not applicable.
This campaign kicks off from a DLL and as such bypasses application control implementations that do not enforce DLL Rules.
Fully blocked by any application control implementation that we analyse. The campaign kicks off by launching a .exe.
This campaign kicks off from a .hta file followed by a DLL. It would bypass an application control implementation not enforcing dll’s. An interesting little known fact is that WDAC already blocks .hta’s when set to Audit mode. So, even if you only had WDAC enabled in audit mode this campaign would be stopped.
Fully blocked by any application control implementation that we analyse. The campaign kicks off by launching a .exe.
This campaign focuses on credential phishing. A technique that can’t be stopped by application control technologies. As a result we score it with -1, not applicable.
This campaign kicks off from a DLL and as such bypasses application control implementations that do not enforce DLL Rules.
This campaign’s analyst report lacks detail for us to make a proper assessment as to whether WDAC would’ve stopped this.
This campaign makes uses of PowerShell exclusively, from what we can gather from the analyst report. As such, it would bypass any application control implementation that doesn’t enforce scripts. WDAC enforces script code integrity by default, but we do take up one implementation in our assessment where script enforcement is explicitely disabled. This implementation would be vulnerable to this campaign.
This campaign requires admin credentials to kick off. All our application control assessments are based on users not having admin privileges. If Admin privileges have been established the threat actor could disable or manipulate your application control implementation anyway.
The different implementations we take into consoderation are:
This series uses Microsoft Defender for Endpoint as input on threats that surfaced in the month. More specifically we’ll look at the Threat Analytics page and the Threat Campaigns that are analyzed on there. Based on the analyst reports we’re doing our best to assess whether an application control implementation would have stopped this specific campaigns.
In our assessment we look at a couple of different common implementation strategies of Microsoft application control technologies. The implementations we take into consideration are Applocker setups we’ve seen a number of times, the WDAC implementations are a mix of implementations we’ve seen with possible implementations we’ve imagined.
In both technologies we assume your users are NOT local administrators. Implementing an application control solution when not having covered this basic measure seems counter-intuitive.
Additionally, we look at the report and what happens prior to the hands-on-keyboard phase of a campaign, if one exist. If a hands-on-keyboard phase exists and your implementation does not block scripts and/or dll’s than we assume the threat actor behind the keyboard can easily circumvent your policy by porting their tools to Powershell or dll.
March 2023 was a busy month for the thread analysts and had no less than 18 threat campaigns in Microsoft Defender for Endpoint analyzed. 3 Threat campaigns did not involve executing code on client systems, so there’s no reasonable expectation that an application control technology could stop this. We mark these campaigns as out-of-scope for our analysis and statistics. 1 Threat campaign lacked enough details for us to make an informed decission as to whether an application control implementation could have stopped the campaign from wreaking havoc. We mark these campaigns as out-of-scope for our analysis and statistics. 1 Threat campaign was around Distributed Denial of service attacks, another item you shouldn’t expect application control to stop for you. 1 Threat campaing was actually a campaing but a description of an Exchange CVE, there’s no real way for us to know how a CVE would eventually be abused, so we do not provide an assessment for these.
The 12 other campaigns would have all been stopped by any Windows Defender Application Control implementation enforcing the integrity of scripts.
Out of these 12, 5 campaigns made use of dll’s to evade app control implementation that do not enforce DLL rules. 4 campaigns were script based, evading application control implementations that do not enforce Script Enforcement aka PowerShell Constrained language mode.
Summary: a perfect score for the WDAC team in march, provided you don’t disable script enforcement. Disabling Script enforcement would’ve opened you up to 4 campaigns.
This campaign kicks off from a trojanized DLL and as such bypasses application control implementations that do not enforce DLL Rules. If your policy was build from a non-trojanized version this campaign would not be successful.
Blackcat is typically delivered as a DLL. As such blocking DLL’s would stop this threat.
We don’t have enough data in this report to make our assessments so we marked it as not applicable.
The DLL used would definitely be blocked, it is somewhat unclear whether there is an executable involved. To side on the error of caution we’re marking this as requiring DLL enforcement to be blocked.
This follows qakbot infections that are blocked if you block scripts or dll’s.
PowerShell based, so stopped if you enforced PowerShell Constrained language mode.
This is a credential phising campaign that does not involve code execution on the client. Not something App allow listing can solve. Marked with -1 not applicable.
Emoted is delivered as a DLL, to evade app allowlisting only enforcing exe’s.
This is a credential phising campaign that does not involve code execution on the client. Not something App allow listing can solve. Marked with -1 not applicable.
A smartscreen bypass does not equate an app allowlisting bypass. Effectively blocked by app allowlisting.
This is not a campaign, just describing the vulnerability without details how exploits would work. As such marked as not applicable/ not possible to make an assessment.
DLL’s and exe’s are used in that campaign exe’s are blocked by all implementations.
This is a credential phising campaign that does not involve code execution on the client. Not something App allow listing can solve. Marked with -1 not applicable.
Qakbot is known to use a mix of dll’s and PowerShell scripts so blocking either would stop this.
This campaign cleverly hides information from exe’s on USB. Nice try, but untrusted exe’s are blocked by all implementations we analyze.
Actor uses several executables that would be blocked by an app allowlisting implementation.
Qakbot is known to use a mix of dll’s and PowerShell scripts so blocking either would stop this.
This is a distriubted Denial of Service attack that does not involve code execution on a client. You should not expect an app allowlisting solution to solve this for you. Marked with -1 not applicable.
The different implementations we take into consoderation are:
This series uses Microsoft Defender for Endpoint as input on threats that surfaced in the month. More specifically we’ll look at the Threat Analytics page and the Threat Campaigns that are analyzed on there. Based on the analyst reports we’re doing our best to assess whether an application control implementation would have stopped this specific campaigns.
The threat analysts at Microsoft delivered 14 threat reports in April 2023. No less than 4 campaigns made use of code in DLL’s to execute their malicious code. Continuing the trend to abuse this as a way to execute code. A trend that bypasses application control implementations that do NOT take DLL’s into account.
1 campaign relied on PowerShell scripting to do its bidding.
The PaperCut vulnerability downloads its malicious binary to a subfolder in c:\Windows and would bypass Applocker implementations that make use of the Default Rules to make the Windows OS binaries trusted.
We didn’t analyze 2 out of the 14 campaigns, 1 didn’t have enough data for us to make an assessment, the other one targeted IOS and as such is considered to be out of scope.
Summary: a perfect score for the WDAC team in march, provided you don’t disable script enforcement. Disabling Script enforcement would’ve opened you up to 1 campaign.
In our assessment we look at a couple of different common implementation strategies of Microsoft application control technologies. The implementations we take into consideration are Applocker setups we’ve seen a number of times, the WDAC implementations are a mix of implementations we’ve seen with possible implementations we’ve imagined.
In both technologies we assume your users are NOT local administrators. Implementing an application control solution when not having covered this basic measure seems counter-intuitive.
Additionally, we look at the report and what happens prior to the hands-on-keyboard phase of a campaign, if one exist. If a hands-on-keyboard phase exists and your implementation does not block scripts and/or dll’s than we assume the threat actor behind the keyboard can easily circumvent your policy by porting their tools to Powershell or dll.
This actor typically makes use of standard remote access tools, which exe’s should be stopped by your Application Control implementation.
This activity makes use of vulnerability in PaperCut that allows code execution as NT Authority\System. As such, when code execution is achieved using the DLL the code then possesses the necessary rights to disable Application Control technologies. The detected activity used PowerShell to download the DLL, but that PowerShell code would proably be able to run in Constrained language mode. Only DLL blocking would block this activity. on top of that this activity downloads its binary to the c:\windows folder and in doing so abuses the default Applocker rules that trust everything in C:\windows.
This method uses a stolen codesigning cert to deliver an executable. Application Control should block this unless you have a publisher rule for the owner of the CodeSigning certificate.
Not a real campaign, more a reminder of a technique being used by Malware authors. As the name implies anything blocking DLL’s would thrump this technique.
Makes use of Python code and Impacket, code that should not be allowed to run if you haven’t made the Python interpreter trusted.
This attack started of using a high privileged account. Our assumption is that you protect your high privilege accounts. This is not something Application Control can prevent easily as new rules could be created by the high-privilege account owner.
Makes use of Python code and Impacket, code that should not be allowed to run if you haven’t made the Python interpreter trusted.
To the best of our knowledge, Qakbot still relies on a mix of DLL code and PowerShell code that would be blocked by an Application Control implementation that blocks untrusted DLL’s and enforces Constrained Language mode for untrusted PowerShell.
This campaign targeted devices running IOS. As such it can not be reasonabilly be expected to be stopped by a Windows Application Control technology. Marked with -1 not applicable.
Another campaign making use of DLL based code, continuing the trend that an Application Control implementation that does NOT look at DLL’s can be bypassed.
The Common Log File System Driver runs as LocalSystem. As a result any exploit against this driver grants the malware author the rights to create new rules and/or disable your Application Control implementation. In short, allowing any form of unvalidated code execution (exe, dll or script) can serve as a bypass to your policy. The Common Log File System driver is becoming a more popular target as it’s exploitation delivers very similar opportunities to exploiting the Print Spooler service.
This report lacks the technical detail for us to make an assessment. Marked with -1 not applicable.
DLL’s are used in that campaign, in contrast with the report last month (march 2023), there’s no longer mention of an Exe, other than the 3CXDesktop app exe itself that would be blocked. Another indication that using DLL’s to circumvent Application Control policies that do not take this into account are circumvented ever more frequently.
To the best of our knowledge the BlackCat ransomware is typically deleivered as a .exe file. All Application Control implementations should block this exe.
The different implementations we take into consoderation are:
We’ll use Microsoft Defender for Endpoint as our input on threats that surfaced in the month. More specifically we’ll look at the Threat Analytics page and the Threat Campaigns that are analyzed on there. Based on the analyst reports we’re doing our best to assess whether an application control implementation would have stopped this specific campaigns.
In our assessment we look at a couple of different common implementation strategies of Microsoft application control technologies. The implementations we take into consideration are Applocker setups we’ve seen a number of times, the WDAC implementations are a mix of implementations we’ve seen with possible implementations we’ve imagined.
In both technologies we assume your users are NOT local administrators. Implementing an application control solution when not having covered this basic measure seems counter-intuitive.
Additionally, we look at the report and what happens prior to the hands-on-keyboard phase of a campaign, if one exist. If a hands-on-keyboard phase exists and your implementation does not block scripts and/or dll’s than we assume the threat actor behind the keyboard can easily circumvent your policy by porting their tools to Powershell or dll.
January 2023 had 6 threat campaigns in Microsoft Defender for Endpoint analyzed. 1 Threat campaign did not involve executing code on client systems, so there’s no reasonable expectation that an application control technology could stop this. We mark these campaigns as out-of-scope for our analysis and statistics. 2 Threat campaign lacked enough details for us to make an informed decission as to whether an application control implementation could have stopped the campaign from wreaking havoc. We mark these campaigns as out-of-scope for our analysis and statistics.
The 3 other campaigns would have all been stopped by any Windows Defender Application Control implementation. Out of these 3, 1 campaign made use of dll’s, PowerShell scripts and the well-known RegSvr32 bypass for Applocker. The threat actors behind this campaign clearly used knowledge of Applocker and popular implementations of it to allow their campaign to move forward even when Applocker was implemented.
Summary: a perfect score for the WDAC team in january.
This campaign focuses on credential phishing. A technique that can’t be stopped by application control technologies. As a result we score it with -1, not applicable.
Fully blocked by any application control implementation that we analyse. The SystemBC tool kicks off by launching a .exe.
Fully blocked by any application control implementation that we analyse. The campaing is kicked off by a PowerShell command that launches a .exe.
This campaign’s analyst report and the vendor’s report do not contain enough details to assess application control’s effectiveness.
This one is definitely debatable. WDAC blocks this campaign. Applocker might or might not. The initial steps would be blocked, but the threat actors clearly know how to circumvent applocker implementations.
This campaign’s analyst report does not contain enough details to assess application control’s effectiveness.
The different implementations we take into consoderation are:
To stay up-to-date on what’s happening in the MEM and Windows management realm I read a ton of stuff. A serious amount of community effort and a similar amount of items Microsoft puts out. The amount of things being put out is all incredibly valuable, and covers all types of knowledge depth imaginable. On a weekly basis I am going to try and shine a light on some of those items that I personally believe you must read. I’ll equally add my view as to why I believe this is something you should probably look into. Items appear in random order.
This is just a simple tweet by @Love Arvidsson, but the animated GIF with it is spot on. I’ve been doing SMS, ConfigMgr, MEMCM for more than 2 decades and I am a bit of a keyboard junky. A set of ConfigMgr Admin UI shortcuts that I didn’t know about to switch between the different workblades.
One of the things admins are looking for in Autopilot deployments is find a way to trigger things as swiftly as possible post the end of Autopilot. Autopilot doesn’t handle the order of policies which can be inconvenient at times. Triggering things post the Autopilot completion is one to achieve this. Nial Brady has a way that was shared with the community to achieve this. Damien now shared a new way to get this done. Having additional options is always a plus. Automatically adding devices to an Azure AD group when Autopilot completes with PowerShell and Azure Automation
Another one in the application control realm. This picture by the New Zealand government shared by Lance Spitzner peaked my interest. It shows the lifecycle of ransomware incident. The interesting bit het here is the “bottleneck” in Consolidation and preparation. Interesting because the areas Lateral Movement & Privilege escalation are exactly where an application control implementation shines.
]]>To stay up-to-date on what’s happening in the MEM and Windows management realm I read a ton of stuff. A serious amount of community effort and a similar amount of items Microsoft puts out. The amount of things being put out is all incredibly valuable, and covers all types of knowledge depth imaginable. On a weekly basis I am going to try and shine a light on some of those items that I personally believe you must read. I’ll equally add my view as to why I believe this is something you should probably look into. Items appear in random order.
@managed_blog has been busy on a series around what I’d call modernizing your systems managemement. I don’t use the term modern often as it often feels like people are trying to sell me something without having a clear benefit other than, it’s new, it must be good. Sean has been on a series of solving everyday challenges and/or provide additional features and functionality using Online from Azure and integrate them with stuff most of you already have. The latest post is a mix between Azure Automation and MEMCM called. Running an Azure Automation runbook to update MEMCM Primary User The posts are typically somewhat longer, but worth your time. The list of the build-up to this in tis series with all other posts are at the end which helps you get an interesting peak into the entire thought process of doing things like this.
If you’re somehow involved in Windows Driver management at your organization and haven’t heard about Maurice’s Driver Automation Tool, than you’re doing it wrong. If you’re somehow involved in Windows Driver management and aren’t using the Driver Automation tool, there’s a very highly likelikhood you’re doing it wrong. Either way you owe it to yourself to have a look at the latest release. If you do use the Driver Automation Tool, I’d suggest an, at least, annual review of the version you’re using and what new opportunities the new builds bring. MSEndpointMgr Driver Automation tool
]]>Early in March a Twitter conversation happened between a number of people regarding the Nvidia security incident that involved the leakage of some of Nvidia’s expired codesigning certificates. This evolved into a recommendation by David Weston to use #WDAC as a first line of defense. You can find the twitter conversation below.
WDAC policies work on both 10-11 with no hardware requirements down to the home SKU despite some FUD misinformation i have seen so it should be your first choice. Create a policy with the Wizard and then add a deny rule or allow specific versions of Nvidia if you need.
— David Weston (DWIZZZLE) (@dwizzzleMSFT) March 4, 2022
Creating a deny rule is something that can definitely be done in Application Control. To do that though, as for most signature based rules you need something that’s called a TBS Hash. (If I am not mistaken, TBS stands for To Be Signed and it’s a hash based representation of the codesigning cert.)
The annoying bit is that you need either a file signed with the certificate or the certificate itself to be able to create that rule. That’s why it took me a while to build the rule. I first had to get access to the certificate somehow.
I received a copy of one of the certs today, so decided to build the policy and share it out. I created the policy using the following PowerShell command. This adds a Deny Signer for the Certificate Specified for the Windows Signing scenario, stopping code in the user space signed with this certificate. The rule has been added to the DefaultWindows policy in audit mode.
Add-SignerRule -FilePath .\DefaultWindows_Audit.xml -Deny -CertificatePath .\nvidia.cer -User
Add-SignerRule -FilePath .\DefaultWindows_Audit.xml -Deny -CertificatePath .\nvidia.cer -Kernel
Some of the relevant portions of the policy are below. The first item is a Signer for Nvidia that has the TBS value that we mentioned before.
<Signer ID="ID_SIGNER_S_1_1_0" Name="NVIDIA Corporation">
<CertRoot Type="TBS" Value="15C37DBEBE6FCC77108E3D7AD982676D3D5E77F7" />
</Signer>
The Signer ID is than added as a Denied Signer.
<DeniedSigners>
<DeniedSigner SignerId="ID_SIGNER_S_1_1_0" />
</DeniedSigners>
The full policy XML can be found below.
Disclaimer This policy has received zero testing so far.
<?xml version="1.0" encoding="utf-8"?>
<SiPolicy xmlns="urn:schemas-microsoft-com:sipolicy">
<VersionEx>10.0.0.0</VersionEx>
<PlatformID>{2E07F7E4-194C-4D20-B7C9-6F44A6C5A234}</PlatformID>
<Rules>
<Rule>
<Option>Enabled:Unsigned System Integrity Policy</Option>
</Rule>
<Rule>
<Option>Enabled:Audit Mode</Option>
</Rule>
<Rule>
<Option>Enabled:Advanced Boot Options Menu</Option>
</Rule>
<Rule>
<Option>Enabled:UMCI</Option>
</Rule>
<Rule>
<Option>Enabled:Inherit Default Policy</Option>
</Rule>
<Rule>
<Option>Enabled:Update Policy No Reboot</Option>
</Rule>
</Rules>
<!--EKUS-->
<EKUs>
<EKU ID="ID_EKU_WINDOWS" Value="010A2B0601040182370A0306" FriendlyName="" />
<EKU ID="ID_EKU_ELAM" Value="010A2B0601040182373D0401" FriendlyName="" />
<EKU ID="ID_EKU_HAL_EXT" Value="010a2b0601040182373d0501" FriendlyName="" />
<EKU ID="ID_EKU_WHQL" Value="010A2B0601040182370A0305" FriendlyName="" />
<EKU ID="ID_EKU_STORE" Value="010a2b0601040182374c0301" FriendlyName="Windows Store EKU - 1.3.6.1.4.1.311.76.3.1 Windows Store" />
<EKU ID="ID_EKU_RT_EXT" Value="010a2b0601040182370a0315" FriendlyName="" />
<EKU ID="ID_EKU_DCODEGEN" Value="010A2B0601040182374C0501" FriendlyName="Dynamic Code Generation EKU - 1.3.6.1.4.1.311.76.5.1" />
<EKU ID="ID_EKU_AM" Value="010a2b0601040182374c0b01" FriendlyName="AntiMalware EKU -1.3.6.1.4.1.311.76.11.1 " />
</EKUs>
<!--File Rules-->
<FileRules />
<!--Signers-->
<Signers>
<Signer ID="ID_SIGNER_WINDOWS_PRODUCTION_0_0_0_0" Name="Microsoft Product Root 2010 Windows EKU">
<CertRoot Type="Wellknown" Value="06" />
<CertEKU ID="ID_EKU_WINDOWS" />
</Signer>
<Signer ID="ID_SIGNER_ELAM_PRODUCTION_0_0_0_0" Name="Microsoft Product Root 2010 ELAM EKU">
<CertRoot Type="Wellknown" Value="06" />
<CertEKU ID="ID_EKU_ELAM" />
</Signer>
<Signer ID="ID_SIGNER_HAL_PRODUCTION_0_0_0_0" Name="Microsoft Product Root 2010 HAL EKU">
<CertRoot Type="Wellknown" Value="06" />
<CertEKU ID="ID_EKU_HAL_EXT" />
</Signer>
<Signer ID="ID_SIGNER_WHQL_SHA2_0_0_0_0" Name="Microsoft Product Root 2010 WHQL EKU">
<CertRoot Type="Wellknown" Value="06" />
<CertEKU ID="ID_EKU_WHQL" />
</Signer>
<Signer ID="ID_SIGNER_WHQL_SHA1_0_0_0_0" Name="Microsoft Product Root WHQL EKU SHA1">
<CertRoot Type="Wellknown" Value="05" />
<CertEKU ID="ID_EKU_WHQL" />
</Signer>
<Signer ID="ID_SIGNER_WHQL_MD5_0_0_0_0" Name="Microsoft Product Root WHQL EKU MD5">
<CertRoot Type="Wellknown" Value="04" />
<CertEKU ID="ID_EKU_WHQL" />
</Signer>
<Signer ID="ID_SIGNER_WINDOWS_FLIGHT_ROOT_0_0_0_0" Name="Microsoft Flighting Root 2014 Windows EKU">
<CertRoot Type="Wellknown" Value="0E" />
<CertEKU ID="ID_EKU_WINDOWS" />
</Signer>
<Signer ID="ID_SIGNER_ELAM_FLIGHT_0_0_0_0" Name="Microsoft Flighting Root 2014 ELAM EKU">
<CertRoot Type="Wellknown" Value="0E" />
<CertEKU ID="ID_EKU_ELAM" />
</Signer>
<Signer ID="ID_SIGNER_HAL_FLIGHT_0_0_0_0" Name="Microsoft Flighting Root 2014 HAL EKU">
<CertRoot Type="Wellknown" Value="0E" />
<CertEKU ID="ID_EKU_HAL_EXT" />
</Signer>
<Signer ID="ID_SIGNER_WHQL_FLIGHT_SHA2_0_0_0_0" Name="Microsoft Flighting Root 2014 WHQL EKU">
<CertRoot Type="Wellknown" Value="0E" />
<CertEKU ID="ID_EKU_WHQL" />
</Signer>
<Signer ID="ID_SIGNER_TEST2010_0_0_0_0" Name="MincryptKnownRootMicrosoftTestRoot2010">
<CertRoot Type="Wellknown" Value="0A" />
</Signer>
<Signer ID="ID_SIGNER_WINDOWS_PRODUCTION_USER_0_0_0_0" Name="Microsoft Product Root 2010 Windows EKU">
<CertRoot Type="Wellknown" Value="06" />
<CertEKU ID="ID_EKU_WINDOWS" />
</Signer>
<Signer ID="ID_SIGNER_ELAM_PRODUCTION_USER_0_0_0_0" Name="Microsoft Product Root 2010 ELAM EKU">
<CertRoot Type="Wellknown" Value="06" />
<CertEKU ID="ID_EKU_ELAM" />
</Signer>
<Signer ID="ID_SIGNER_HAL_PRODUCTION_USER_0_0_0_0" Name="Microsoft Product Root 2010 HAL EKU">
<CertRoot Type="Wellknown" Value="06" />
<CertEKU ID="ID_EKU_HAL_EXT" />
</Signer>
<Signer ID="ID_SIGNER_WHQL_SHA2_USER_0_0_0_0" Name="Microsoft Product Root 2010 WHQL EKU">
<CertRoot Type="Wellknown" Value="06" />
<CertEKU ID="ID_EKU_WHQL" />
</Signer>
<Signer ID="ID_SIGNER_WHQL_SHA1_USER_0_0_0_0" Name="Microsoft Product Root WHQL EKU SHA1">
<CertRoot Type="Wellknown" Value="05" />
<CertEKU ID="ID_EKU_WHQL" />
</Signer>
<Signer ID="ID_SIGNER_WHQL_MD5_USER_0_0_0_0" Name="Microsoft Product Root WHQL EKU MD5">
<CertRoot Type="Wellknown" Value="04" />
<CertEKU ID="ID_EKU_WHQL" />
</Signer>
<Signer ID="ID_SIGNER_WINDOWS_FLIGHT_ROOT_USER_0_0_0_0" Name="Microsoft Flighting Root 2014 Windows EKU">
<CertRoot Type="Wellknown" Value="0E" />
<CertEKU ID="ID_EKU_WINDOWS" />
</Signer>
<Signer ID="ID_SIGNER_ELAM_FLIGHT_USER_0_0_0_0" Name="Microsoft Flighting Root 2014 ELAM EKU">
<CertRoot Type="Wellknown" Value="0E" />
<CertEKU ID="ID_EKU_ELAM" />
</Signer>
<Signer ID="ID_SIGNER_HAL_FLIGHT_USER_0_0_0_0" Name="Microsoft Flighting Root 2014 HAL EKU">
<CertRoot Type="Wellknown" Value="0E" />
<CertEKU ID="ID_EKU_HAL_EXT" />
</Signer>
<Signer ID="ID_SIGNER_WHQL_FLIGHT_SHA2_USER_0_0_0_0" Name="Microsoft Flighting Root 2014 WHQL EKU">
<CertRoot Type="Wellknown" Value="0E" />
<CertEKU ID="ID_EKU_WHQL" />
</Signer>
<Signer ID="ID_SIGNER_STORE_0_0_0_0" Name="Microsoft MarketPlace PCA 2011">
<CertRoot Type="TBS" Value="FC9EDE3DCCA09186B2D3BF9B738A2050CB1A554DA2DCADB55F3F72EE17721378" />
<CertEKU ID="ID_EKU_STORE" />
</Signer>
<Signer ID="ID_SIGNER_RT_PRODUCTION_0_0_0_0" Name="Microsoft Product Root 2010 RT EKU">
<CertRoot Type="Wellknown" Value="06" />
<CertEKU ID="ID_EKU_RT_EXT" />
</Signer>
<Signer ID="ID_SIGNER_DRM_0_0_0_0" Name="MincryptKnownRootMicrosoftDMDRoot2005">
<CertRoot Type="Wellknown" Value="0C" />
</Signer>
<Signer ID="ID_SIGNER_DCODEGEN_0_0_0_0" Name="MincryptKnownRootMicrosoftProductRoot2010">
<CertRoot Type="Wellknown" Value="06" />
<CertEKU ID="ID_EKU_DCODEGEN" />
</Signer>
<Signer ID="ID_SIGNER_AM_0_0_0_0" Name="MincryptKnownRootMicrosoftStandardRoot2011">
<CertRoot Type="Wellknown" Value="07" />
<CertEKU ID="ID_EKU_AM" />
</Signer>
<Signer ID="ID_SIGNER_RT_FLIGHT_0_0_0_0" Name="Microsoft Flighting Root 2014 RT EKU">
<CertRoot Type="Wellknown" Value="0E" />
<CertEKU ID="ID_EKU_RT_EXT" />
</Signer>
<Signer ID="ID_SIGNER_RT_STANDARD_0_0_0_0" Name="Microsoft Standard Root 2001 RT EUK">
<CertRoot Type="Wellknown" Value="07" />
<CertEKU ID="ID_EKU_RT_EXT" />
</Signer>
<Signer ID="ID_SIGNER_TEST2010_USER_0_0_0_0" Name="MincryptKnownRootMicrosoftTestRoot2010">
<CertRoot Type="Wellknown" Value="0A" />
</Signer>
<Signer ID="ID_SIGNER_S_1_1_0_0_0" Name="NVIDIA Corporation">
<CertRoot Type="TBS" Value="15C37DBEBE6FCC77108E3D7AD982676D3D5E77F7" />
</Signer>
<Signer ID="ID_SIGNER_S_1_1" Name="NVIDIA Corporation">
<CertRoot Type="TBS" Value="15C37DBEBE6FCC77108E3D7AD982676D3D5E77F7" />
</Signer>
</Signers>
<!--Driver Signing Scenarios-->
<SigningScenarios>
<SigningScenario Value="131" ID="ID_SIGNINGSCENARIO_DRIVERS_1" FriendlyName="Auto generated policy on 03-10-2022">
<ProductSigners>
<AllowedSigners>
<AllowedSigner SignerId="ID_SIGNER_WINDOWS_PRODUCTION_0_0_0_0" />
<AllowedSigner SignerId="ID_SIGNER_ELAM_PRODUCTION_0_0_0_0" />
<AllowedSigner SignerId="ID_SIGNER_HAL_PRODUCTION_0_0_0_0" />
<AllowedSigner SignerId="ID_SIGNER_WHQL_SHA2_0_0_0_0" />
<AllowedSigner SignerId="ID_SIGNER_WHQL_SHA1_0_0_0_0" />
<AllowedSigner SignerId="ID_SIGNER_WHQL_MD5_0_0_0_0" />
<AllowedSigner SignerId="ID_SIGNER_WINDOWS_FLIGHT_ROOT_0_0_0_0" />
<AllowedSigner SignerId="ID_SIGNER_ELAM_FLIGHT_0_0_0_0" />
<AllowedSigner SignerId="ID_SIGNER_HAL_FLIGHT_0_0_0_0" />
<AllowedSigner SignerId="ID_SIGNER_WHQL_FLIGHT_SHA2_0_0_0_0" />
<AllowedSigner SignerId="ID_SIGNER_TEST2010_0_0_0_0" />
</AllowedSigners>
<DeniedSigners>
<DeniedSigner SignerId="ID_SIGNER_S_1_1" />
</DeniedSigners>
</ProductSigners>
</SigningScenario>
<SigningScenario Value="12" ID="ID_SIGNINGSCENARIO_WINDOWS" FriendlyName="Auto generated policy on 03-10-2022">
<ProductSigners>
<AllowedSigners>
<AllowedSigner SignerId="ID_SIGNER_WINDOWS_PRODUCTION_USER_0_0_0_0" />
<AllowedSigner SignerId="ID_SIGNER_ELAM_PRODUCTION_USER_0_0_0_0" />
<AllowedSigner SignerId="ID_SIGNER_HAL_PRODUCTION_USER_0_0_0_0" />
<AllowedSigner SignerId="ID_SIGNER_WHQL_SHA2_USER_0_0_0_0" />
<AllowedSigner SignerId="ID_SIGNER_WHQL_SHA1_USER_0_0_0_0" />
<AllowedSigner SignerId="ID_SIGNER_WHQL_MD5_USER_0_0_0_0" />
<AllowedSigner SignerId="ID_SIGNER_WINDOWS_FLIGHT_ROOT_USER_0_0_0_0" />
<AllowedSigner SignerId="ID_SIGNER_ELAM_FLIGHT_USER_0_0_0_0" />
<AllowedSigner SignerId="ID_SIGNER_HAL_FLIGHT_USER_0_0_0_0" />
<AllowedSigner SignerId="ID_SIGNER_WHQL_FLIGHT_SHA2_USER_0_0_0_0" />
<AllowedSigner SignerId="ID_SIGNER_STORE_0_0_0_0" />
<AllowedSigner SignerId="ID_SIGNER_RT_PRODUCTION_0_0_0_0" />
<AllowedSigner SignerId="ID_SIGNER_DRM_0_0_0_0" />
<AllowedSigner SignerId="ID_SIGNER_DCODEGEN_0_0_0_0" />
<AllowedSigner SignerId="ID_SIGNER_AM_0_0_0_0" />
<AllowedSigner SignerId="ID_SIGNER_RT_FLIGHT_0_0_0_0" />
<AllowedSigner SignerId="ID_SIGNER_RT_STANDARD_0_0_0_0" />
<AllowedSigner SignerId="ID_SIGNER_TEST2010_USER_0_0_0_0" />
</AllowedSigners>
<DeniedSigners>
<DeniedSigner SignerId="ID_SIGNER_S_1_1_0_0_0" />
</DeniedSigners>
</ProductSigners>
</SigningScenario>
</SigningScenarios>
<UpdatePolicySigners />
<CiSigners>
<CiSigner SignerId="ID_SIGNER_STORE_0_0_0_0" />
<CiSigner SignerId="ID_SIGNER_S_1_1_0_0_0" />
</CiSigners>
<HvciOptions>0</HvciOptions>
<BasePolicyID>{A244370E-44C9-4C06-B551-F6016E563076}</BasePolicyID>
<PolicyID>{A244370E-44C9-4C06-B551-F6016E563076}</PolicyID>
<Settings>
<Setting Provider="PolicyInfo" Key="Information" ValueName="Name">
<Value>
<String>DefaultWindowsAudit</String>
</Value>
</Setting>
<Setting Provider="PolicyInfo" Key="Information" ValueName="Id">
<Value>
<String>031017</String>
</Value>
</Setting>
</Settings>
</SiPolicy>