Windows 10: -level hash with Windows Defender Application Control - can't get it working

Daniel James daniel.james · Jan 30, 2020

Hi.

I am trying to to get Windows defender Application Control working via hash rules. We are using WDAC as we don't have win10 enterprise i know, we should...

I have got WDAC working, my policy allows all Microsoft apps and anything in c:\windows\ c:\program files and c:\program files x86. I am also happy getting apps to work via publisher however I just can't get it working by file hash alone.

I am running:

new-cipolicy -level hash -scanpath 'c:\source\' -filepath puttyhash.xml

which appears to create a blank policy? see bottom of this message. Converting this policy to binary seems to result in windows defender being switched off, no logs appear in event viewer -> application and service logs -> microsoft -> windows -> code integrity -> operational for any .exe's

Switching option 3 off and re-converting stops the machine from booting so i don't understand the lack of logs...

Merging this to my normal policy and then switching option 3 off doesn't seem to have any affect on behavior, I still can't run putty.exe I get the 'Your , except from file paths I have allowed.

using new-cipolicy -level publisher -scanpath 'c:\source\' -filepath puttyhash.xml and then merging/converting does seem to work.

What am I doing wrong? Does hash only work as a fallback when a file doesn't have a publisher?

Thanks.

Created hash policy:

<?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>Required:Enforce Store Applications</Option>

</Rule>

</Rules>



<EKUs />



<FileRules />



<Signers />



<SigningScenarios>

<SigningScenario Value="131" ID="ID_SIGNINGSCENARIO_DRIVERS_1" FriendlyName="Auto generated policy on 01-30-2020">

<ProductSigners />

</SigningScenario>

<SigningScenario Value="12" ID="ID_SIGNINGSCENARIO_WINDOWS" FriendlyName="Auto generated policy on 01-30-2020">

<ProductSigners />

</SigningScenario>

</SigningScenarios>

<UpdatePolicySigners />

<CiSigners />

<HvciOptions>0</HvciOptions>

<PolicyTypeID>{A244370E-44C9-4C06-B551-F6016E563076}</PolicyTypeID>

</SiPolicy>

:)

Brink · Jan 30, 2020

Windows Defender Application Control enhancements in Windows 10 v1903

With the Windows 10 May 2019 Update we delivered several important features for Windows Defender Application Control (WDAC), which was originally introduced to Windows as part of a scenario called Device Guard. WDAC works in conjunction with features like Windows Defender Application Guard, which provides hardware-based isolation of Microsoft Edge for enterprise-defined untrusted sites, to strengthen the security posture of Windows 10 systems.

*Arrow How to Turn On or Off Windows Defender Application Guard for Microsoft Edge in Windows 10

*Arrow How to Enable or Disable Device Guard in Windows 10

Our focus for this release was responding to some longstanding feedback on manageability improvements. We’re excited to introduce the following new capabilities in Windows Defender Application Control:

File path rules, including optional runtime admin protection checks

Multiple policy file support with composability

Application Control CSP to provide a new, richer MDM policy management capability

COM object registration support in policy

Disabling script enforcement rule option

Application control is frequently identified as one of the most effective mitigations against modern security threats, because anything that’s not allowed by policy is blocked from running. Even striving towards a simple policy like mandating that only signed code is allowed to execute can be incredibly impactful: in a recent analysis of Windows Defender ATP data, we saw that 96% of malware encountered is unsigned. Systems like Windows 10 in S mode, which uses WDAC technology to enforce that all code must be signed by Windows and Microsoft Store code signing certificates, have no malware infection issues.

The new capabilities are designed to ease the journey for customers adopting application control in real-world environments with large numbers of applications, users, and devices.

File path rules, including optional runtime admin protection checks

For many customers looking to adopt application execution control while balancing IT overhead, rules based on file paths on managed client systems provide a useful model. The Windows 10 May 2019 Update introduces support for both allow and deny rules based on file path in Windows Defender Application Control.

File path rules had been one of the few features available in AppLocker, the older native application control technology, that were not available to WDAC; deployment tools and methodologies built on top of AppLocker like AaronLocker have relied on these rules as an important simplifying option for policy management. As we sought to close that gap, we wanted to preserve the stronger security posture available with WDAC that customers have come to expect. To this end, WDAC applies, by default, an option to check at runtime that apps and executables allowed based on file path rules must come from a file path that’s only writable by administrator or higher privileged accounts. This runtime check provides an additional safeguard for file path rules that are otherwise inherently weaker than other identifiers like hash or signer rules, which rely on cryptographically verifiable attributes.

This runtime capability can be controlled with the “Disabled:Runtime FilePath Rule Protection” rule option.

The following example shows how to easily create rules for anything allowed under “Program Files” and “Program Files (x86)”, and then merge them with the sample policy that allows all Windows signed code (available under C:\Windows\schemas\CodeIntegrity\ExamplePolicies). The resulting merged policy file allows all Windows signed code and applications installed under “Program Files” and “Program Files (x86)” with the runtime protection that checks that anything executing under those paths is coming from a location only writable by administrator or higher privileged accounts.

Multiple policy file support with composability

Limiting support to a single policy file means that a variety of app control scenarios from potentially different stakeholders or business groups need to be maintained in one place. This comes with an associated overhead: the coordination required to converge on the appropriate rules encapsulated in a single policy file.

With the Windows 10 May 2019 Update multiple policy files are supported for WDAC. To facilitate composing behavior from multiple policy files, we have introduced the concept of base and supplemental policies:

Base policies – For any execution to be allowed, the application must pass each base policy independently. Base policies are used together to further restrict what’s allowed. For example:
Let’s assume a system has two policies: Base Policy A and Base Policy B with their own sets of rules. For foo.exe to run, it must be allowed by the rules in Base Policy A and also the rules in Base Policy B. Windows Defender Application Control policies on prior Windows 10 systems will continue to work on the May 2019 Update and will be treated as base policies.

Supplemental policies – As the name suggests, supplemental policies complement base policies with additional rules to be considered as part of the base policies they correspond to. Supplemental policies are tied to a specific base policy with an ID; a base policy may have multiple supplemental policies. Supplemental policies expand what is allowed by any base policy, but deny rules specified in a supplemental policy will not be honored.

Application Control CSP

Customers have been able to deploy Windows Defender Application Control policies via MDM using the CodeIntegrity node of the AppLocker configuration service provider (CSP). The AppLocker CSP has a number of limitations, most notably the lack of awareness of rebootless policy deployment support.

The Windows 10 May 2019 Update now has a new Application Control CSP, which introduces much richer support for policy deployment over MDM and also provides support for:

Rebootless policy deployment (For policies that have the “Enabled:Update Policy No Reboot” option set, the new Application Control CSP will not schedule a reboot on client systems getting the policy)

Support for the new multiple policies

For device management software vendors, better error reporting

COM object registration support

Windows Defender Application Control enforces a built-in allow list of COM object registrations to reduce the risk introduced from certain powerful COM objects. Customers have reported that while this capability is desirable from a security perspective, there are specific cases in their environments where they’d like to allow the registration of additional COM objects required for their business.

With the Windows 10 May 2019 Update customers can now specify COM objects that need to be allowed in environments they’re managing with Windows Defender Application Control policies.

Disabled: Script Enforcement rule option support

The Windows 10 May 2019 Update with KB4497935 introduces proper support for the Disabled: Script Enforcement rule option.

Customers recognize the importance of having restrictions on script hosts but are often looking to break up their application control projects into smaller chunks to help with deployment feasibility. The “Disabled:Script Enforcement” rule option in the policy now turns off policy enforcement for MSIs, PowerShell scripts, and wsh-hosted scripts. This will allow IT departments to tackle EXE, DLL, and driver enforcement without needing to also simultaneously address script host control.

Try the new capabilities today

We invite everyone to try these new Windows Defender Application Control capabilities, alongside existing features like managed installer. For customers using Microsoft Defender ATP, consider using Advanced hunting to query the WDAC events centrally to understand and monitor the behavior of all these new policy controls on client machines in your environment. Learn about both new and existing functionalities with the Windows Defender Application Control deployment guide.

We’re also working on supplementing the documentation we have out now. Stay tuned for updates from our team for tools and guidance on GitHub that provide more practical examples and ready-to-use scripts.

Nazmus Sakib
Senior Program Manager, Windows Defender Application Control team
Click to expand...

Source: https://www.microsoft.com/security/b...y-2019-update/

Brink · Jan 30, 2020

Windows Defender Application Control enhancements in Windows 10 v1903

With the Windows 10 May 2019 Update we delivered several important features for Windows Defender Application Control (WDAC), which was originally introduced to Windows as part of a scenario called Device Guard. WDAC works in conjunction with features like Windows Defender Application Guard, which provides hardware-based isolation of Microsoft Edge for enterprise-defined untrusted sites, to strengthen the security posture of Windows 10 systems.

*Arrow How to Turn On or Off Windows Defender Application Guard for Microsoft Edge in Windows 10

*Arrow How to Enable or Disable Device Guard in Windows 10

Our focus for this release was responding to some longstanding feedback on manageability improvements. We’re excited to introduce the following new capabilities in Windows Defender Application Control:

File path rules, including optional runtime admin protection checks

Multiple policy file support with composability

Application Control CSP to provide a new, richer MDM policy management capability

COM object registration support in policy

Disabling script enforcement rule option

Application control is frequently identified as one of the most effective mitigations against modern security threats, because anything that’s not allowed by policy is blocked from running. Even striving towards a simple policy like mandating that only signed code is allowed to execute can be incredibly impactful: in a recent analysis of Windows Defender ATP data, we saw that 96% of malware encountered is unsigned. Systems like Windows 10 in S mode, which uses WDAC technology to enforce that all code must be signed by Windows and Microsoft Store code signing certificates, have no malware infection issues.

The new capabilities are designed to ease the journey for customers adopting application control in real-world environments with large numbers of applications, users, and devices.

File path rules, including optional runtime admin protection checks

For many customers looking to adopt application execution control while balancing IT overhead, rules based on file paths on managed client systems provide a useful model. The Windows 10 May 2019 Update introduces support for both allow and deny rules based on file path in Windows Defender Application Control.

File path rules had been one of the few features available in AppLocker, the older native application control technology, that were not available to WDAC; deployment tools and methodologies built on top of AppLocker like AaronLocker have relied on these rules as an important simplifying option for policy management. As we sought to close that gap, we wanted to preserve the stronger security posture available with WDAC that customers have come to expect. To this end, WDAC applies, by default, an option to check at runtime that apps and executables allowed based on file path rules must come from a file path that’s only writable by administrator or higher privileged accounts. This runtime check provides an additional safeguard for file path rules that are otherwise inherently weaker than other identifiers like hash or signer rules, which rely on cryptographically verifiable attributes.

This runtime capability can be controlled with the “Disabled:Runtime FilePath Rule Protection” rule option.

The following example shows how to easily create rules for anything allowed under “Program Files” and “Program Files (x86)”, and then merge them with the sample policy that allows all Windows signed code (available under C:\Windows\schemas\CodeIntegrity\ExamplePolicies). The resulting merged policy file allows all Windows signed code and applications installed under “Program Files” and “Program Files (x86)” with the runtime protection that checks that anything executing under those paths is coming from a location only writable by administrator or higher privileged accounts.

Multiple policy file support with composability

Limiting support to a single policy file means that a variety of app control scenarios from potentially different stakeholders or business groups need to be maintained in one place. This comes with an associated overhead: the coordination required to converge on the appropriate rules encapsulated in a single policy file.

With the Windows 10 May 2019 Update multiple policy files are supported for WDAC. To facilitate composing behavior from multiple policy files, we have introduced the concept of base and supplemental policies:

Base policies – For any execution to be allowed, the application must pass each base policy independently. Base policies are used together to further restrict what’s allowed. For example:
Let’s assume a system has two policies: Base Policy A and Base Policy B with their own sets of rules. For foo.exe to run, it must be allowed by the rules in Base Policy A and also the rules in Base Policy B. Windows Defender Application Control policies on prior Windows 10 systems will continue to work on the May 2019 Update and will be treated as base policies.

Supplemental policies – As the name suggests, supplemental policies complement base policies with additional rules to be considered as part of the base policies they correspond to. Supplemental policies are tied to a specific base policy with an ID; a base policy may have multiple supplemental policies. Supplemental policies expand what is allowed by any base policy, but deny rules specified in a supplemental policy will not be honored.

Application Control CSP

Customers have been able to deploy Windows Defender Application Control policies via MDM using the CodeIntegrity node of the AppLocker configuration service provider (CSP). The AppLocker CSP has a number of limitations, most notably the lack of awareness of rebootless policy deployment support.

The Windows 10 May 2019 Update now has a new Application Control CSP, which introduces much richer support for policy deployment over MDM and also provides support for:

Rebootless policy deployment (For policies that have the “Enabled:Update Policy No Reboot” option set, the new Application Control CSP will not schedule a reboot on client systems getting the policy)

Support for the new multiple policies

For device management software vendors, better error reporting

COM object registration support

Windows Defender Application Control enforces a built-in allow list of COM object registrations to reduce the risk introduced from certain powerful COM objects. Customers have reported that while this capability is desirable from a security perspective, there are specific cases in their environments where they’d like to allow the registration of additional COM objects required for their business.

With the Windows 10 May 2019 Update customers can now specify COM objects that need to be allowed in environments they’re managing with Windows Defender Application Control policies.

Disabled: Script Enforcement rule option support

The Windows 10 May 2019 Update with KB4497935 introduces proper support for the Disabled: Script Enforcement rule option.

Customers recognize the importance of having restrictions on script hosts but are often looking to break up their application control projects into smaller chunks to help with deployment feasibility. The “Disabled:Script Enforcement” rule option in the policy now turns off policy enforcement for MSIs, PowerShell scripts, and wsh-hosted scripts. This will allow IT departments to tackle EXE, DLL, and driver enforcement without needing to also simultaneously address script host control.

Try the new capabilities today

We invite everyone to try these new Windows Defender Application Control capabilities, alongside existing features like managed installer. For customers using Microsoft Defender ATP, consider using Advanced hunting to query the WDAC events centrally to understand and monitor the behavior of all these new policy controls on client machines in your environment. Learn about both new and existing functionalities with the Windows Defender Application Control deployment guide.

We’re also working on supplementing the documentation we have out now. Stay tuned for updates from our team for tools and guidance on GitHub that provide more practical examples and ready-to-use scripts.

Nazmus Sakib
Senior Program Manager, Windows Defender Application Control team
Click to expand...

Source: https://www.microsoft.com/security/b...y-2019-update/

Brink · Jan 30, 2020

OneNote REST API now supports application-level permissions

The OneNote API team is pleased to announce that we have enabled application-level permissions support for the OneNote API. Until now, OneNote API calls could only be made with user-delegated permissions. This meant that your application would be restricted to scenarios that required a user to be signed in. With application-level permissions support, your application now supports scenarios that do not require a user to be signed in! Read the MSDN article for details of the OneNote API application-level permissions support.

With the availability of OneNote API application-level permissions support, many new scenarios that weren’t possible earlier are now enabled. Some example scenarios include:

Analytics (based on OneNote metadata and content exposed by the OneNote API).

Dashboards (based on OneNote metadata and content exposed by the OneNote API).

Background provisioning of OneNote content.

Background update of OneNote content.

During the development process of building the new application-level permissions support for OneNote API, our Product Management and Engineering teams worked closely with third-party partners to ensure that relevant and key education scenarios were implemented. We also ensured that our API would work well with new and upcoming third-party solutions. One of these education companies we worked closely with during the API development was Hapara.

“The Hapara Dashboard provides educators with a bird’s-eye view into student work across the Office 365 platform. With Dashboard, educators view and access student work from OneDrive and OneNote Class Notebooks from a central hub, making it easier to engage with students and their work across the Office 365 platform. Hapara relies on the new OneNote API to help co-teachers, counselors, coaches and school administrators gain appropriate access to student work in any classroom, something that previously required manual sharing and significant administrative effort by the individual teachers. Now, cross-school teams gain the same level of access and visibility into Class Notebooks via the Hapara Dashboard as teachers get via the OneNote Class Notebook app. This allows all to participate in serving students, while reducing the administrative burden on the teachers.”

—Nara Chilluvuri, product manager at Hapara

With the availability of application-level permissions support for OneNote API, solution providers, ISVs and IT admins can access important usage data about OneNote across a tenant, including:

Teacher usage of Class Notebooks.

Student usage of Class Notebooks.

Information about specific pages, sections or notebooks.

How many pages were touched and last time each page was touched.

Information about the Collaboration Space usage in the Class Notebook.

Information about OneNote Page content, including paragraphs, tables, images and attachments.

Creating a new application or updating your existing application to use the new application-level permissions support for OneNote API requires just a couple of additional (relative to using user-delegated permissions) steps. For step-by-step instructions, see the detailed OneNote app-only API documentation on MSDN.

—The OneNote team
Click to expand...

Source: The OneNote REST API now supports application-level permissions - Office Blogs

Windows 10: -level hash with Windows Defender Application Control - can't get it working

-level hash with Windows Defender Application Control - can't get it working

-level hash with Windows Defender Application Control - can't get it working

-level hash with Windows Defender Application Control - can't get it working

-level hash with Windows Defender Application Control - can't get it working - Similar Threads - level hash Defender

Can't get into Windows Defender

Cannot get file hash computation in MS Defender to work

Cannot get file hash computation in MS Defender to work

Windows defender application control blocking apps

Windows defender application control blocking apps

Windows defender application control blocking apps

Microsoft Defender Endpoint Application Control

CAN'T GET WINDOWS DEFENDER TO WORK

Windows Defender Application Control Security Vulnerability

Users found this page by searching for:

wdac script enforcement

what is page hash in wdac