Cloud file productivity using Windows Quick Access

Here’s a productivity tip I use to make navigating cloud file location easier on Windows 10 desktops.

image

After have set up any synced locations, like my OneDrive, SharePoint, Teams, etc,  I then locate a frequent folder I need in a cloud location. Here that folder is Customers on my OneDrive for Business. I then right mouse click on that folder and select the option Pin to Quick access as shown above.

image

You should then see that folder in the Quick access area in the top left of Windows Explorer as shown above.

image

Now, if I want to attach an email from that location I can simply browse to a location (web or local doesn’t really matter), because whenever you get Windows Explorer, you also get your Quick access.

image

from which you navigate to the file you need via Quick access in the top left of Windows Explorer. Quick and easy.

image

Because Windows wants to be ‘helpful’ and add recent locations to Quick access by default, I want to disable that so this area doesn’t become cluttered. I want Quick access just to contain the stuff I put in there, nothing else.

To achieve this, I go into the properties of Windows Explorer and in the General tab, under Privacy, I uncheck both options (Show recently used files in Quick access and Show frequently used folder in Quick access) as shown above.

I like to keep my Quick access as small as possible and therefore remove anything that isn’t relevant to my day to day work (i.e. the shortcuts to stuff like Media and Movies).

I haven’t seen many people use Quick access on Windows desktops but I find that once you set it up it is invaluable as it pops up anytime you need to work with files. You can also add, remove and edit over time to customise to your exact needs. For example, if I’m working on a project, I add that location for the duration of time I’m working on that project. This make access very fast and easy.

Hopefully, this productivity approach may also help you when working with files from the cloud.

Teams on the web failing to login

2022-04-04_12-27-42

(Be patient, the video might take a few moments to load)

I recently had an issue accessing Microsoft Teams using a web browser even after logging into Microsoft 365. I could get to just about everything else but Teams, which always threw up a login dialog as shown above.

The issue turned out to be the time of the local device which hadn’t updated for some reason after a change to daylight savings time. Thus, the local devices (Windows 11) for some reason was one hour ahead. After changing this so the workstation had the correct time, everything worked as expected.

Hopefully,this helps someone else who is searching for this strange one.

Implementing Windows Defender Application Control (WDAC)–Part 4

This post is part of a series focused on Windows Defender Application Control (WDAC). The previous article can be found here:

EKUs

Unfortunately, from this point forward, I can find no ‘official’ definition of the syntax of the WDAC XML file anywhere. Thus, I have done my best to try and decipher the file. However, please keep in mind, this is simply the determination that I can make looking at the file.

What I’ll focus on in this post is the FileRules block. This block is defined in the XML with the following boundaries:

<FileRules>

</FileRules>

The documentation I found about FileRules specifically is here:

Windows Defender Application Control file rule levels

which says:

File rule levels allow administrators to specify the level at which they want to trust their applications. This level of trust could be as granular as the hash of each binary or as general as a CA certificate. You specify file rule levels when using WDAC PowerShell cmdlets to create and modify policies.

Between these headers can be the following definitions:

1. Generic Files

This would typically appear as:

<FileAttrib ID=”ID_FILEATTRIB_F_1_0_1″ FriendlyName=”Microsoft Teams” ProductName=”MICROSOFT TEAMS” />

2. Allow Files

This would typically appears as:

<Allow ID=”ID_ALLOW_A_1B_ONEDRIVE_1_1″ FriendlyName=”C:\Users\user\AppData\Local\Microsoft\OneDrive\21.119.0613.0001\ErrorPage.js Hash Sha1″ Hash=”25D362DEE9A4B04ACDFD0ABBAB7A415AA494DC98″ />

3. Deny files

<Deny ID=”ID_DENY_BASH” FriendlyName=”bash.exe” FileName=”bash.exe” MinimumFileVersion=”65535.65535.65535.65535″/>

Each of these definitions starts off with a ‘ID’ field either: FileAttrib ID, Allow ID or Deny ID. Next, comes a variable that will be used later to refer to the specifics of that file definition. Here those are: ID_FILEATTRIB_F_1_0_1, ID_ALLOW_A_1B_ONEDRIVE_1_1 and ID_DENY_BASH. From what I can determine, these IDs can be any text.

Next, is the FriendlyName field, which again can be any text but typically will be the file name, with or without the path. From what I can determine, this is simply a ‘tagging’ field. If the FileName or is not specified this Friendlyname field will be used as the actual file name.

The next field options are used to actually define the individual file on the system. This can be achieved in a number of different ways specified, including by path and file name, hash, file path, publisher and more as detailed here:

Windows Defender Application Control policy – file rule levels

The most common types of definitions I have found are:

FileName field, which actually refers to the executable file i.e. bash.exe as shown above.

FilePath field. which refers to the location of the executables i.e. C:\Program Files\*

ProductName can be used to identify the file in question. I assume this refers to a product that is registered with the operating system.

Hash which specifies a unique file hash

It appears that you can also use the field MinimumFileversion when specifying the Fieldname and Productname definitions

These file rule definitions will be utilised by later items in the XML configuration, so they must be present if they are going to referred to.

You can use the

New-CIPolicy

and

New-CIPolicyRule

for drivers

PowerShell command to generate these file rules.

The precedence order of these file rules is defined here:

File rule precedence order

but is basically, deny, then allow, then the rest.

That’s the best I can work out from the documentation and experimenting. I’m sure there is more information somewhere, and if you do find any, please let me know.

Part 5 – Specifying Signers

CIAOPS Need to Know Microsoft 365 Webinar – October

laptop-eyes-technology-computer

Join me for the free monthly CIAOPS Need to Know webinar. Along with all the Microsoft Cloud news we’ll be taking a look at using eDiscovery and Content search in your environment.

Shortly after registering you should receive an automated email from Microsoft Teams confirming your registration, including all the event details as well as a calendar invite! Yeah Teams webinars.

You can register for the regular monthly webinar here:

October Webinar Registrations

The details are:

CIAOPS Need to Know Webinar – October 2021
Friday 29th of October 2021
11.00am – 12.00am Sydney Time

All sessions are recorded and posted to the CIAOPS Academy.

The CIAOPS Need to Know Webinars are free to attend but if you want to receive the recording of the session you need to sign up as a CIAOPS patron which you can do here:

http://www.ciaopspatron.com

or purchase them individually at:

http://www.ciaopsacademy.com/

Also feel free at any stage to email me directly via director@ciaops.com with your webinar topic suggestions.

I’d also appreciate you sharing information about this webinar with anyone you feel may benefit from the session and I look forward to seeing you there.

Implementing Windows Defender Application Control (WDAC)–Part 3

This post is part of a series focused on Windows Defender Application Control (WDAC). The previous article can be found here:

Understanding Policy Rules

In this article I’ll continue looking at the XML used to create WDAC policies. Specifically, I’ll focus on the EKU block.

image

If you open up the XML policy file that we have been working through so far, you’ll effectively find just a placeholder for EKUs as shown above.

image

If you look at another, more complete, WDAC policy, you’ll see that the EKU block is populated as shown above. The block reads like:

<EKUs>
    <EKU ID=”ID_EKU_WINDOWS” Value=”010A2B0601040182370A0306″ FriendlyName=”Windows System Component Verification – 1.3.6.1.4.1.311.10.3.6″ />
    <EKU ID=”ID_EKU_ELAM” Value=”010A2B0601040182373D0401″ FriendlyName=”Early Launch Antimalware Driver – 1.3.6.1.4.1.311.61.4.1″ />
    <EKU ID=”ID_EKU_HAL_EXT” Value=”010a2b0601040182373d0501″ FriendlyName=”HAL Extension – 1.3.6.1.4.1.311.61.5.1″ />
    <EKU ID=”ID_EKU_WHQL” Value=”010A2B0601040182370A0305″ FriendlyName=”Windows Hardware Driver Verification – 1.3.6.1.4.1.311.10.3.5″ />
    <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=”Windows RT Verification – 1.3.6.1.4.1.311.10.3.21″ />
    <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>

I am no expert, but in essence this is telling the WDAC policy about trusted Microsoft certificates for the environment.

To simplify let’s look at:

<EKUID=”ID_EKU_WINDOWS “Value=”010A2B0601040182370A0306 “FriendlyName=”Windows System Component Verification – 1.3.6.1.4.1.311.10.3.6″/>

From what I understand, this refers to capability with PKI style certificate. Trusted certificates are used to sign each file on a Windows 10 device to ensure it is original and untampered with.

The Object Identifier (ODI) number, 1.3.6.1.4.1.311.10.3.6, helps identify who the certificate is from. If you look at this article:

Object Identifiers (OID) in PKI

you’ll learn that a certificate that starts with 1.3.6.1.4.311 is from Microsoft and that the specific certificate 1.3.6.1.4.311.10.3.6 OID is for the Windows System Component Verification.

image

If we now dig into a typical Windows system file that we want to ensure is secure:

c:\windows\system32\kernel32.dll

and examine that files’ properties, Digital Certificates, Details, View Certificate as shown above, we see that this certificate can be used for:

– Ensuring the software came from the software publisher

– Protects the software from alteration after publication

Which is exactly what functionality we are after.

image

If we now look at the certificate Details, then select the field Enhanced Key Usage (EKU) as shown above we see:

Windows System Component Verification (1.3.6.1.4.1.311.10.3.6) which matches what we found in the EKU block in the WDAC policy in the lower box.

I will say that I am no expert on how certificates and how they exactly interact with file verification but all we need to know, in essence, is that the EKUs in the WDAC XML file tell the policy which certificates to trust when evaluating whether to trust a file. If the file in question is signed with a certificate that is in the EKU list, then that file will be trusted. This makes it easy to trust a large number of files from Microsoft, which is good as we need to trust Windows system files to boot.

<EKUID=”ID_EKU_WINDOWS “Value=”010A2B0601040182370A0306 “FriendlyName=”Windows System Component Verification – 1.3.6.1.4.1.311.10.3.6″/>

Returning to the EKU line in question from the WDAC policy file, we note that:

Value=”010A2B0601040182370A0306”

This is, as I again understand it, the internal Microsoft identification for the certificate in question. EKU instances have a “Value” attribute consisting of an encoded OID. The process for this Object Identifier (OID) encoding is detailed here:

Object Identifier

which, I must say, is very complex. Luckily, I found this PowerShell function:

https://gist.github.com/mattifestation/5bdcdbadfc4070f9191705853c5481da

which you can use to convert. Now for reasons I can’t yet determine, you need to change the leading 01 to an 06. Thus, to view all the Object IDs using the PowerShell function above you can use the following code:

image

Which provides the following result:

image

Note: 1.3.6.1.4.1.311.76.11.1 = AntiMalware EKU

You can select which EKUs you wish to include in the WDAC XML file, but in this case I will include them all.

image

The best way to add these to the policy, from what I have found so far, is simply to edit the XML and add it. After you do this the modified policy XML file will appear like shown above.

Most of WDAC relies on certificates and verification of signing. I will readily admit that I don’t have a full appreciate for how the world of certificates work, but I hope you, like me, are satisfied enough with what I have detailed here.

So, in summary, the EKU block in the WDAC policy, specifies known certificates from Microsoft that are used to sign Windows system files that we want to trust on the device. Thus, by trusting those certificates we can trust files signed by those certificates. Using the EKU block in the policy allow us to do this for many Microsoft system files quickly and easily and is why, as a best practice, we should include it in the policy.

The next block in the XML policy to focus on will be covered in the next article in the series:

Part 4 – Specifying File Rule

Implementing Windows Defender Application Control (WDAC)–Part 1

Windows Defender Application Control (WDAC) is a technology that is built into Windows 10 that allows control of what applications execute on the device.

image

WDAC also allows you to control which drivers are allowed to run and is thus, a very powerful security measure that many should consider implementing. A typical WDAC blocking message is shown above.

Microsoft also has an older application white listing technology known as AppLocker. Here is the recommendation from Microsoft when choosing between the two technologies:

“Generally, it is recommended that customers, who are able to implement application control using WDAC rather than AppLocker, do so. WDAC is undergoing continual improvements, and will be getting added support from Microsoft management platforms. Although AppLocker will continue to receive security fixes, it will not undergo new feature improvements.”

You can deploy AppLocker and WDAC together if your wish, and thus the best practice recommendation from Microsoft is:

“As a best practice, you should enforce WDAC at the most restrictive level possible for your organization, and then you can use AppLocker to further fine-tune the restrictions.”

This is also a good side by side feature comparison here:

Windows Defender Application Control and AppLocker feature availability

So, WDAC it is!

WDAC policies apply to the managed computer as a whole and affects all users of the device. WDAC rules can be defined based on:


– Attributes of the codesigning certificate(s) used to sign an app and its binaries


– Attributes of the app’s binaries that come from the signed metadata for the files, such as Original Filename and version, or the hash of the file


– The reputation of the app as determined by Microsoft’s

– Intelligent Security Graph


The identity of the process that initiated the installation of the app and its binaries (managed installer)


– The path from which the app or file is launched (beginning with Windows 10 version 1903)


– The process that launched the app or binary

WDAC policies are composed using XML. You can view a number of example policies on any Windows 10 device by navigating to:

C:\Windows\schemas\CodeIntegrity\ExamplePolicies\

and looking at the file I’ll be starting is process with:

denyallaudit.xml

and building from there.

Before we get too much further along I need to give you this warning. Application whitelisting is a lot of work to implement and maintain. The more variations (i.e. third party software) you have floating around the environment, the more challenging it is to implement. Also, remember that application whitelisting of ANY form is placing restrictions on user productivity. The things you do with tools like WDAC have the potential to severely restrict users ability to do their job. This can result in the ‘local villages’ pitching up to your door with burning effigies, sharp weapons, menacing looks and foul language if you are not careful. I’ll give you my best practices for reducing the pain and suffering but be prepared for this to be a journey rather than a set and forget update.

Before anything else, I would suggest that you should be conducting a software audit in your environment. You should know what applications are being run by users, however, I’ll guarantee that you won’t know them all. This should not preclude you from at least making an attempt to catalogue what you have. Doing so will save you a lot of pain in the long run.

Next, you’ll create start creating a default WDAC policy in audit mode to see what is actually happening and what issues may be faced. This policy will then be adjusted along the way to accommodate any required inclusions (typically third party software). Once that stage has been completed, the policy will then be flipped from audit to enforcement mode to actually start preventing unknown applications from running.

That’s the plan for these upcoming series of WDAC articles and I hope you’ll follow along and with the knowledge I share look to implement WDAC in your own environment.

Part 2 – Understanding a basic WDAC policy

All the Guards–Part 10

This article is a part of a series. The previous article can be found here:

All the Guards – Part 9 Control Flow Guard

In this article I’m going to summarise all the previously articles which included:

All the Guards – Part 9 Control Flow Guard

All the Guards – Part 8 DMA Guard

All the Guards – Part 7 Exploit Guard

All the Guards – Part 6 Application Guard

All the Guards – Part 5 Credential Guard

All the Guards – Part 4 System Guard

All the Guards – Part 3 Device Guard

All the Guards – Part 2 Virtualization Based Security

All the Guards – Part 1 Secure Boot

To successfully implement many of these you’ll need current hardware and an up to date version of Windows 10 Professional or Enterprise. The majority of protection is provided by virtualisation, which the device needs to support and have enough RAM (recommended minimum would be 8GB, but you can do it with less) to facilitate.

Configuration of these options can be handled individually but a better approach is to use a policy method such as via Microsoft Endpoint Manager across your fleet.

I have shared all the information I have found on these topics, hopefully in a manner that makes sense. Unfortunately, information about many of these technologies is not presented in a straight forward manner and in many cases, specifics are hard to find and confirm. Hopefully, however, there is enough information there to show you the benefits of implementing these technologies across your Windows 10 devices.

My advice, is that you look at implementing these technologies in the order that I have presented them to accommodate dependencies that exist. I have done exactly that in my production environment and now don’t even think about them.

So if you haven’t as yet implemented all the Guards that Microsoft has available, I’d encourage you to do so. The improvement in security it provides is worth the investment.