Preventing Malware with Microsoft Defender for Endpoint

Introduction

In my previous post I looked at some barebones configuration to get started with MDE, now let’s look at locking down your environment.

MDE includes many settings to minimise the overall attack surface of your Windows devices, one of these features is the ability to apply Attack Surface Reduction (ASR) rules. In a nutshell they prevent malware infection by blocking certain software behaviours, like:

• Scripts and executables attempting to download or run files
• Running suspicious scripts
• Behaviours outside of the normal day-to-day operation

Microsoft provide Security Baselines for Windows and Defender which include ASR rules, but the default setting for these can be a little on the overzealous side and from experience can impede end users’ ability to work, so tuning these to suit your environment is important.

Before implementing a block rule across your Windows estate, ensure you’ve run the rule in audit mode to verify normal end user operations won’t be impacted. Microsoft’s recommendation is as follows:

If issues are discovered during the testing phase, instead of completely disabling a rule it may be possible to simply exclude an executable from ASR rules. This obviously comes with risk, but worth exploring if the need arises. More information on this can be found here

Configuration

The settings below are the result of implementing ASR rules into various environments and discovering which ones are too intrusive. These may work for most environments, but make sure to test, test, test.

• Block untrusted and unsigned processes that run from USB Block
• Block Adobe Reader from creating child processes Block
• Block executable content from email client and webmail Block
• Block JavaScript or VBScript from launching downloaded executable content Block
• Block persistence through WMI event subscription Block
• Block credential stealing from the Windows local security authority subsystem (lsass.exe) Block
• Block Office applications from creating executable content Block
• Block Office applications from injecting code into other processes Audit
• Block Win32 API calls from Office macros Audit
• Block all Office applications from creating child processes Audit
• Block execution of potentially obfuscated scripts Audit
• Block executable files from running unless they meet a prevalence, age, or trusted list criterion Audit
• Use advanced protection against ransomware Audit
• Block process creations originating from PSExec and WMI commands Audit
• Block Office communication applications from creating child processes Audit
• Use advanced protection against ransomware Audit

 The Window security baseline contains ASR rules which will need to be edited prior to deploying, this can be easily done when creating a new Security Baseline profile

 

In my next post, I’ll be looking at further settings to lock down your Windows environment.

Laying the foundations in Microsoft Defender for Endpoint

 

Introduction

Following on from my previous post about onboarding devices to test the functionality of Defender for Endpoint (MDE) I’d like to detail some key settings to ensure MDE is configured in the best way and to maximise value of the product.

These recommendations aren’t an exhaustive list, keep an eye out for further blog posts about more enhancements.

Create Device Groups

Device groups will form an important part of operations in MDE, especially if you plan to protect varying OS’s and device types. Device groups in MDE are used for:

• Role based access control (RBAC)
• Configuring auto-remediation settings
• Filtering devices during remediation
• Configuring alert levels

Device groups are configured in Settings -> Endpoints -> Device groups

A simple condition-based filter is used to dynamically populate device groups, an example of a Windows 10 device group is shown below.

Configure RBAC

Role based access control should be configured to allow the adoption of MDE across different internal teams and to define rights and permissions.

I recommend creating at least two roles in MDE to segregate admins from analysts. 

Roles can be created under Settings -> Endpoints -> Roles. 

Before doing so, create the associated user groups in your Azure AD.

Analysts will generally want to view the threat and vulnerability data, so creating a role as follows should suffice:

 

Administrators will need more permissions across MDE, using the following will work well:

Set Up Vulnerability Notifications

Keeping your team up to date with the latest vulnerabilities and exploits is paramount; configure vulnerability notifications to send email alerts about the following:

• New vulnerability found (including zero-day vulnerability)
• Exploit was verified
• New public exploit
• Exploit added to an exploit kit

These can be scoped to specific device groups

Vulnerability notifications are created in Settings -> Endpoints -> Email notifications -> Vulnerabilities

 

As you can see, the email notifications contain a decent level of detail and provide recommendations for remediation.

Conclusion

This post should have guided you into a position where you can start tweaking some of the more advanced features of MDE. Keep an eye out for further posts on this subject.

Onboarding devices to Microsoft Defender for Endpoint with Intune

Introduction

Defender for Endpoint (Formerly Defender ATP) is Microsoft’s enterprise grade endpoint protection solution which provides prevention, detection, investigation and response to advanced threats. I regularly work with customers who already use Defender anti-virus and want to dip their toes into the enhanced capabilities of Defender for Endpoint (MDE).

What are the steps to onboard a device already being managed by Microsoft Endpoint Manager?

Prerequisites

Firstly, obtain licensing. I recommend Microsoft Defender for Endpoint Plan 2.

Identify a Windows device or several devices for the test. These need to be active devices in MEM.

An Azure AD security group containing the devices/users in scope for the test needs to be created.

Browse to the Microsoft 365 Defender web page, if Defender hasn’t been previously enabled, click through the ‘first run’ options to choose region, data retention etc. 

Then enable “Microsoft Intune Connection” under Settings -> Endpoints -> Advanced features. This connection may take up to 24 hours to establish.

Configuration

Now we’re ready to target a configuration profile to onboard a device with MDE.

To create the configuration profile within the MEM admin center, browse to Endpoint security -> Endpoint detection and response and create a new policy.

The onboarding blob is automatically created by the connection between MEM and MDE, so no further configuration is required in the profile here.

Once the profile is created, assign to the security group containing users/devices in scope for the test.

If all has gone well, the device will appear in the “Devices” section of the Microsoft 365 Defender page.

Testing

Once the configuration profile has been received by the device and telemetry has been sent to MDE, you’ll begin to see data in Microsoft 365 Defender webpage.

To test the connection with MDE, we can trigger a test alert by running the command line shown in the Onboarding section of Settings -> Endpoints.

A great way to verify MDE is working is to disable automated patching on the test device (exclude from Windows Update Rings). This will eventually result in the device to become behind in patching levels and further data will appear in Microsoft 365 Defender about known vulnerabilities.

Conclusion

Hopefully this post has provided some quick steps to onboard a test device or devices into Microsoft Defender for Endpoint ready for demonstration of further features.

I will be publishing more posts which demonstrate some of the excellent features MDE has to offer.

Next Post - Laying the foundations in Microsoft Defender for Endpoint

Onboarding remote devices with Microsoft ConfigMgr or Intune

 Introduction

The end user computing landscape has drastically changed over the last few years due to the drive towards remote working, and with this comes a need to rethink device management.

For Windows devices, ConfigMgr or Intune have been the go-to solutions from Microsoft under the Endpoint Manager umbrella. The combination of the two platforms brings a truly comprehensive approach to managing a Windows estate.

Since the adoption of remote working, I’ve regularly been asked about how to onboard or migrate VPN connected, Active Directory domain joined Windows devices into Microsoft Endpoint Manager with the least amount of IT staff intervention. In this post, I’ll look a couple of scenarios I’ve encountered and how I dealt with each one with some high-level bullet pointed steps. It is assumed that ConfigMgr and Intune have already been configured up to the point of being functional.

Disclaimer: This is not a how-to guide, it's more about explaining the options available. I provide links for further reading.

Scenario 1

Requirement:

VPN connected clients need to be managed with ConfigMgr.

Scenario:

o   Devices never return to office

o   AD domain joined only

o   No ConfigMgr Client installed

Solution:

1.       Create GPO with ConfigMgr site assignment and client deployment settings (Excellent how to guide here)

2.       Add software package installation to GPO using ccmsetup.msi hosted on a contactable file share

3.       Link GPO to OU containing target devices

Explanation:

With a few basic configuration changes, it’s possible to take a large number of remotely connected devices from a position of no management to being fully managed with ConfigMgr.

 

Scenario 2

Requirement:

Co-management with a CMG is needed to manage devices.

Scenario:

o   AD domain joined only

o   ConfigMgr Client installed

o   No Cloud Management Gateway

Solution:

1.       Configure Azure AD Connect for Hybrid AAD join  (More details)

2.       Manually create a Group Policy to apply the client-side SCP registry entry (More details)

3.       Configure Intune Automatic Enrollment and Co-management settings in ConfigMgr (More details)

4.       Provision a Cloud Management Gateway (More details)

 

Explanation:

A more modern approach to device management can be achieved with co-management. Once these configuration changes have been implemented, Intune could be used to manage workloads such as Software Updates or Compliance while ConfigMgr remains in play for other tasks such as App deployment and inventory. A CMG will allow ConfigMgr to continue managing devices even when they’re internet-based (out of the office and disconnected from VPN).

Of course, once the devices are in this co-managed state, there is scope to transition away from ConfigMgr and aim for fully modern-management.