How do you get smarter in MDM & Group Policy?

Upcoming Training Classes

With Jeremy Moskowitz

To consult about an on-site (Private) Group Policy class or the Group Policy Health Check, please call Laura Rubinstein at 215-391-0096 or email laura[[att]]policypak.com

To purchase seats in a LIVE or ONLINE training class, contact Laura Rubinstein at 215-391-0096 or email laura[[att]]policypak.com

Get serious, and perform “Best Practices” around Group Policy management. Take back control and get your IT life back!

Dates Class Actions
11 / 20 / 2019 Chicago2019 Learn More

How do you get smarter in MDM & Group Policy?

May 2020
26

How to Kill PUA on your Windows 10 Devices using Group Policy, Powershell and Intune

Few things in this world are black and white and that includes software you download. 

There is a lot of "gray-ish" stuff residing on computers today.  A good example is software that comes bundled with the computer or was installed by another software application of a different vendor. 

Most of the time these applications aren’t something you want in the first place.  Other examples include advertising software or evasion software that actively tries to dodge the detection of your cybersecurity tools.   While these software files may not pose a direct threat to your computer in the same way that malware, Trojans and other types of malicious software do, these unwanted applications can impede the performance of your endpoints.  These unwanted software servings are referred to as Potentially Unwanted Applications (PUA).  A PUA is an application that has a poor reputation.  These applications can serve as a time consuming distraction of cleaning up these files.  Over time, these applications can increase the risk to your network. 

Windows 10 Defends Against PUAs

Windows 10 (Professional and Enterprise editions) can detect and block possibly harmful third party and unwanted applications using Windows Defender and does so without requiring Defender ATP or Enterprise licenses.  When activated, the PUA security feature looks for certain file structures and conditions that include the following:

  • The file is being scanned from the browser
  • The file is in a folder with "downloads" in the path
  • The file is in a folder with "temp" in the path
  • The file is on the user's desktop
  • The file does not meet one of these conditions and is not under %programfiles%, %appdata% or %windows%

Should these conditions be met, the file in question is then quarantined and not allowed to be installed until approved. 

Using PowerShell to Enable PUA

You can use PowerShell to enable PUA within Windows Defender. 

The command options are as follows:

Set-MpPreference -PUAProtection Enabled

Set-MpPreference -PUAProtection AudiMode

The PS command will add and modify the DWORD value in the protected registry key as is shown below.

HKEY_LOCAL_MACHINE\SOFTWARE\ Microsoft\Windows Defender\MpEngine\MpEnablePus.

And assigns one of the following values.

  • Disabled: 0 (Does not block PUAs)
  • Enabled: 1 (Blocks PUAs)
  • Audit Mode: 2 (PUA events are reported in Windows Event Viewer.  PUAs will not be blocked however)

Of course, you can make the changes directly in the registry itself.

The end result is as follows:

 

Enabling PUA with Group Policy

For domain-joined machines, you can enable PUA protection through Group Policy.  Simply create a GPO and go to Computer Configuration > Administrative Templates > Windows Defender Antivirus and enable “Configure protection for potentially unwanted applications.”

Then choose which your desired option:

You can also use Configuration Manager to deploy the setting as well.

05:07

Enabling PUA with Microsoft Endpoint Manager (Intune)

You can configure the Defender/PUA Protection CSP for your Intune enrolled devices.  You can either create a configuration profile or use the preferred method of enabling and configuring a security baseline.  To create a configuration profile choose Windows 10 as the platform and Device restrictions as the profile type. 

To deploy PUA using a security baseline, go to Endpoint Security > Security Baselines > Microsoft Defender ATP baseline > Profile configure the “Defender potentially unwanted app action” setting as is shown below.

Enable PUA in Chromium-based Microsoft Edge


The new Edge browser (version 80 and greater) contains its own PUA protection ability.  Go to your browser settings and select Privacy and services.  Then enable the “Block potentially unwarned apps” as is shown in the screenshot below.

You can also deploy this Edge setting using Group Policy as well.  Simply create a GPO and go to Computer Configuration > Administrative Templates > Microsoft Edge > SmartScreen settings and enable “Configure Microsoft Defender SmartScreen to block potentially unwanted apps.”

To enable the same setting using Microsoft Endpoint Manager, create a configuration profile and choose Windows 10 as the platform and Administrative Templates as the profile type.  Then go to Microsoft Edge > SmartScreen Settings and enable “Configure Microsoft Defender SmartScreen to block potentially unwanted apps."

You should enable these PUA tools as a part of your multilayer security strategy.  Hardening your desktop devices and reducing their attack surface exposure is critically important.  Another way to stop PUA (or, really any unwanted file download) is application control via PolicyPak Least Privilege Manager.  You can check it out here.

 

Mar 2020
02

Block regedit with Intune

The last thing that standard users need on Windows 10 machines is access to REGEDIT.  It is one of the first things we block access to with Group Policy.  Surprising though, there is no native way in Intune to block it however.  The good news is that you can do it by creating a custom profile in Intune or any MDM.  I have included the information you need to create it below.  Now you can be rest assured that users won't be causing issues and circumventing policies by messing with the registry.

OMA-URI:  ./Vendor/MSFT/AppLocker/ApplicationLaunchRestrictions/IntuneEdu/EXE/Policy

Data Type:  String (XML file)

<RuleCollection Type="Exe" EnforcementMode="NotConfigured">

        <FilePathRule Id="fd686d83-a829-4351-8ff4-27c7de5755d2" Name="(Default Rule) All files" Description="Allows members of the local Administrators group to run all applications." UserOrGroupSid="S-1-5-32-544" Action="Allow">

          <Conditions>

            <FilePathCondition Path="*" />

          Conditions>

        FilePathRule>

        <FilePathRule Id="ce9d9fd5-d765-48df-b87b-e1bafd5653ed" Name="All files" Description="Allows members of the Everyone group to run applications that are located in any folder." UserOrGroupSid="S-1-1-0" Action="Allow">

          <Conditions>

            <FilePathCondition Path="*" />

          Conditions>

                        <Exceptions>

     

        <FilePublisherCondition PublisherName="O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US" ProductName="MICROSOFT® WINDOWS® OPERATING SYSTEM" BinaryName="REG.EXE">

          <BinaryVersionRange LowSection="*" HighSection="*" />

        FilePublisherCondition>

                Exceptions>

        FilePathRule>

     RuleCollection>

 


 

Mar 2020
01

Block CMD prompt with Intune

Group Policy admins have been blocking access to command prompt for standard users since the beginning.  That is why it is frustrating for MDM admins having no native way in Intune to block it in the same fashion of Group Policy.  Well in actuality, you can block the cmd prompt, it just takes a custom profile, which is something that not everyone likes to do much.  Below is how you set it up so feel free to use the settings.  

OMA-URI:  ./Vendor/MSFT/AppLocker/ApplicationLaunchRestrictions/IntuneEdu/EXE/Policy

Data Type:  String (XML file)

Here is the XML code to paste in:

<RuleCollection Type="Exe" EnforcementMode="NotConfigured">

        <FilePathRule Id="fd686d83-a829-4351-8ff4-27c7de5755d2" Name="(Default Rule) All files" Description="Allows members of the local Administrators group to run all applications." UserOrGroupSid="S-1-5-32-544" Action="Allow">

          <Conditions>

            <FilePathCondition Path="*" />

          Conditions>

        FilePathRule>

        <FilePathRule Id="ce9d9fd5-d765-48df-b87b-e1bafd5653ed" Name="All files" Description="Allows members of the Everyone group to run applications that are located in any folder." UserOrGroupSid="S-1-1-0" Action="Allow">

          <Conditions>

            <FilePathCondition Path="*" />

          Conditions>

                        <Exceptions>

                    <FilePublisherCondition PublisherName="O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US" ProductName="MICROSOFT® WINDOWS® OPERATING SYSTEM" BinaryName="CMD.EXE">

          <BinaryVersionRange LowSection="*" HighSection="*" />

        FilePublisherCondition>

                Exceptions>

        FilePathRule>

     RuleCollection>

Feb 2020
25

What are Azure Security Defaults and Who Should Use Them? (Part 2)

In Part 1, of our blog series outlining the details of Azure security defaults, we left off on the topic of MFA registration, which utilizes the Microsoft Authenticator app.  While all users MUST register for MFA, MFA is not required for all users every time.  Security defaults does enforce MFA for privileged accounts every time they log on as these accounts have increased access to your environment.  Security defaults requires added authentication for the following nine Azure administrator roles.

  • Global administrator
  • SharePoint administrator
  • Exchange administrator
  • Conditional Access administrator
  • Security administrator
  • Helpdesk administrator or password administrator
  • Billing administrator
  • User administrator
  • Authentication administrator

MFA should be standard policy for all Azure admin account as account takeover attacks are one of the leading types of threats today.  Cybercriminals specifically target privileged accounts so special attention is needed.

Protecting all users

Security defaults is about improving the protection for all users, not just admin accounts.  While MFA is not required of every logon attempt, non-admin users are prompted for additional authentication when connecting from a new device or app.  There may be other instances that trigger MFA for standard users as well.

Limitations of MFA using security defaults

As mentioned, security defaults gives you free access to Azure AD MFA.  Free however, has its limitations.  Some of these shortcomings are listed below.

  • Admins have no control over verification methods
  • SMS and phone calls are not available as second factors
  • You cannot configure trusted IPs for MFA exclusion
  • An exclusion account for emergency access
  • No MFA reports or fraud alerts

Again, keep in mind that Azure security defaults gives you the bare security minimum.  To obtain more features and control over MFA, you will need to ante up some additional money.  If you have a license for Conditional Access but have not yet enabled it, you can use security defaults as a temporary security band-aid until you are ready to enable Conditional Access policies.

Blocking legacy authentication

The majority of compromising sign-in attempts come from legacy authentication.  These credential stuffing or account takeover attacks tend to be automated and performed by bot nets.  Legacy authentication utilizes protocols that only use basic authentication.  These outdated protocols only require single factor authentication and cannot enforce a second factor as part of the natural authentication flow.  This is in contrast to modern authentication, which does support second factor authentication.  Using legacy authentication, an imposter can simply bypass your active MFA policy.

Client applications or services that use legacy authentication also have a blaring vulnerability in that credentials are collected and then stored until validated against an authority.   Apps or services that utilize modern authentication never store credentials.  Instead, they only present them.  In other words, modern authentication never trusts the app or service that is requesting your credentials. 

For these reasons, it is highly recommended that legacy authentication protocols such as IMAP, SMTP and POP3 be blocked.  This means that clients cannot use an older version of Office 2010 but can use a more current version such as Office 2016.  Some email/faxing software and other types of applications require the use of these older protocols.  Make sure that none of your applications are using legacy authentication protocols before enabling security defaults.   

Protecting privileged actions

We mentioned how security defaults uses MFA to protect privileged user accounts.  It also protects privileged actions as well.  This is important because non-admin users can be delegated to Azure Resources.  Azure services can be managed through the Azure Resource Manager API.  These services include:

  • Azure portal
  • Azure PowerShell
  • Azure CLI

These services give users tenant wide powers such as the ability to modify configurations, service settings and billing subscriptions.  This is why it is imperative to verify the identity of users that utilize them.  When enabled, security defaults will require added authentication before allowing delegated access. 

Conclusion

Azure AD security defaults certainly has its shortcomings and should not be considered a long-term solution for any sizable organization.  It also does not provide the rich security protections that many organizations need to satisfy security policies or compliances.  It does provide a “one-click” easy button that new tenants can use to protect themselves right out of the gate while they begin to learn their solution options.  While it may provide ample protection for small organizations, tenant owners should view it as a transitory measure only.  Security defaults is a great first step and one that hopefully, will better secure the entire O365 community as well. 

Testimonials