Follow Us

 

Microsoft Defender ATP

Microsoft Defender ATP

Featured Blog Microsoft Defender for Endpoint

  • Microsoft Defender for Endpoint: Automation defaults are changing
    by israelcp on January 17, 2021 at 5:25 pm

    We are excited to announce that we are about to increase our customers’ protection by upgrading the default automation level of our Microsoft Defender for Endpoint customers who have opted into public previews from Semi – require approval for any remediation to Full – remediate threats automatically.    Auto investigation and remediation overview When an alert is raised in Microsoft Defender for Endpoint, an automated investigation immediately starts running on the machine where the suspicious activity was detected. It begins with an analysis of the malicious entities that are part of the alert and continues with collection and examination of other entities associated with it. The automated investigation inspects files, processes, services, registry keys, and any area that may contain threat-related evidence.   The result of an automated investigation started by an alert is a list of related entities found on a device and their verdicts (malicious, suspicious, or clean). For any malicious entity, the investigation will create a remediation action, an action that, when approved, will remove or contain a malicious entity that was found in the investigation. These actions are defined, managed, and executed by Microsoft Defender for Endpoint without the security operations team having to remotely connect to the device.     Remediation actions are approved or declined according to the device automation level. When it is set to ‘Full’, the remediation action will be approved automatically, without further waiting. When it is set to ‘Semi’, the action will wait for manual approval, which may lead to losing valuable time in which the malware may cause damage and spread to other devices.     Automated investigation and remediation supports queuing of remediation actions for devices that are not available, so that when they become available, the actions will be triggered immediately. All remediation actions, whether pending, running, or completed, can be viewed in the Action Center. If you’ve determined that a detected device or a file is not actually a threat, you can undo remediation actions that were taken for a specific device or across the entire organization.   Empowering defenders with automation by default When our automated investigation and remediation capabilities were first introduced, the default automation level was set to semi – require approval for any remediation. Since then, we have increased our malware detection accuracy, added the option to undo remediation actions, and improved our automated investigation infrastructure. Throughout this time, we have seen thousands of cases where organizations with fully automated tenants have successfully contained and remediated threats, while other companies, left with the default ‘semi’ level, have remained at high risk due to lengthy pending time for approval of actions.   Data collected and analysed over the past year shows that organizations who are using full automation have had 40% more high-confidence malware samples removed than customers using lower levels of automation. Full automation also frees up our customers’ critical security resources so they can focus more on their strategic initiatives.   In light of the significant benefits of using automatic approval of remediation actions, and after changing the default automation level for new customers, starting February 16, 2021, tenants who have opted in for public previews in the Microsoft Defender for Endpoint will be automatically upgraded to the new default automation level: Full-remediate threats automatically.   The new default automation level can be kept (this is recommended) or changed according to your organizational needs. This change does not impact or override device group definitions that were previously set to control automation level.   To get started with Microsoft Defender for Endpoint public preview capabilities, we encourage customers to turn on preview features in Microsoft Defender Security Center.   If you’re not yet taking advantage of Microsoft’s industry leading optics and detection capabilities, sign up for a free trial of Microsoft Defender for Endpoint today.   Additional resources: Create and manage device groups Automation levels in automated investigation and remediation capabilities Review and approve remediation actions following an automated investigation

  • EDR for Linux is now generally available
    by Tomer_Hevlin on January 11, 2021 at 6:44 pm

      We are excited to announce that endpoint detection and response (EDR) capabilities in Microsoft Defender for Endpoint on Linux server are now generally available.   Over the course of the last year, Microsoft Defender for Endpoint was extended to support all major platforms (Windows, Linux, macOS, Android, and iOS). Today we are taking the next step by adding endpoint detection and response (EDR) for Linux. EDR is essential for navigating today’s Linux threat landscape.   The full set of Microsoft Defender for Endpoint (Linux) preventive and detection and response capabilities are supported across the six most common Linux server distributions: RHEL 7.2+ CentOS Linux 7.2+ Ubuntu 16 LTS, or higher LTS SLES 12+ Debian 9+ Oracle Linux 7.2 The Linux solution can be deployed and configured using Puppet, Ansible, or using your existing Linux configuration management tool.   Our customers have joined us on this evolution and given us feedback in every step of the way. For this, we are truly grateful and look forward to the continued partnership.   “The upcoming release is an amazing milestone providing us a 360 view on all our platforms for our threat hunting strategy “ Guy Fridman, Head Of Security Operation And Response     Detections with context   About 6 months ago, we announced the availability of Microsoft Defender for Endpoint (Linux) with preventive antivirus capabilities. Customers can better protect Linux servers, get these devices onboarded in the same portal as their Windows, macOS, and mobile devices, and expand the single pane of glass experience to include Linux-related alerts. With the newly enabled EDR support, security operations can view detections with even richer context. The below device timeline example demonstrates this enriched capability.     The timeline tab includes information about process creation, network connections, file creations and login events.   In the Microsoft Defender for Endpoints (Linux) EDR public preview announcement, we also discussed the post-breach detection capability with an example scenario that customers can use to experience the feature. The below “Suspicious process launched from a world-writable directory” alert is another post-breach detection example.     Unified investigation experience   The timeline is just one piece of the investigation story. Microsoft Defender for Endpoint’s popular advanced hunting tool allows customers to perform free-form investigations using a powerful query engine and an ever-growing set of useful shared queries. Now, customers can use this capability to search for threats across Linux servers, exploring up to 30 days of raw data.     The well designed architecture also seamlessly enables custom detections on top of the advanced hunting capabilities.   The rest of the investigation experience, such as the hyperlinked exploration between the different monitored entities, is consistent with the familiar experience for Windows devices. The monitored entities (e.g. files, processes, network connections, alerts) are available for exploration on Linux devices. Here are a few examples:   File page   IP Address Page     How to get started   Microsoft Defender for Endpoint (Linux) requires the Servers license. You can find this information in our product terms. Please reach out to your account team for more information and eligibility.   To get started, visit our documentation.  If you are already evaluating public preview of Microsoft Defender for Endpoint (Linux) EDR, make sure you update the agent to a released version 101.18.53 or higher.   If you are already running Microsoft Defender for Endpoint (Linux) preventive AV in production, your devices will seamlessly receive the new EDR capability as soon as you update the agent to version 101.18.53 or higher.    If you’re not yet taking advantage of Microsoft’s industry leading security optics and detection capabilities for endpoints, sign up for a free trial of Microsoft Defender for Endpoint today.   Microsoft Defender for Endpoint team                          

  • How to use tagging effectively (Part 2)
    by miriamwiesner on January 11, 2021 at 5:52 pm

    In Part 1 of this blog series, we learnt about why tags are useful and how to maximise their potential for administration of Microsoft Defender for Endpoint. In the next two parts of this blog series, we wanted to cover some advanced scenarios for applying tags, starting with…   Tagging your Microsoft Defender for Endpoint devices by OU path Sometimes when working with Microsoft Defender for Endpoint you might want to display your Organizational Unit (OU) structure within Defender for Endpoint to build device groups to get better transparency for reporting.   To realize this scenario with Group Policies, we will create one script file in the process: DefenderTagging.ps1 Create this script file and copy it to a location where you have access from a Domain Controller. Contents of MSDETagging.ps1         $DN = (Get-ItemProperty -Path  “HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\State\Machine” -Name Distinguished-Name).”Distinguished-Name” $OU = $DN.Substring($DN.IndexOf(‘OU=’)) $registryPath = “HKLM:\SOFTWARE\Policies\Microsoft\Windows Advanced Threat Protection\DeviceTagging” $name = “Group” IF(!(Test-Path $registryPath))   {     New-Item -Path $registryPath -Force | Out-Null     Set-ItemProperty -Path $registryPath -Name $name -Value $OU   }  ELSE {     Set-ItemProperty -Path $registryPath -Name $name -Value $OU   }           Depending on how many OUs your environment contains, you might want to fine grain the $OU selection done by this script: configuring too many tags could impact the performance when working in the Microsoft Defender Security Center.   Getting our scripts to run: Execution Policy The Execution Policy restricts the execution of PowerShell Scripts on the system. On newer systems the default setting is “Restricted”. Having this setting configured, the system does not run scripts at all, therefore this setting needs to be changed before we can run the tagging script.   Execution Policy is not a real security feature, although some documentation states so. It is rather a feature that keeps you from running scripts unintentionally.   To maintain protection from running scripts unintentionally, but to have the ability to run scripts nevertheless, the setting “RemoteSigned” is a good approach:Only local scripts (scripts within the local domain and signed scripts) can be run, unsigned scripts from the internet will be blocked from running.   You can either configure this option manually using the following PowerShell command:         Set-ExecutionPolicy RemoteSigned         Or since configuring it manually can take quite some effort, you can also configure it via Group Policy.   Getting started with the Group Policy Create a new Group Policy Object which is linked to the root folder in which all your Defender protected devices are located.   Then navigate to Computer Configuration > Administrative Templates > Windows Components > Windows PowerShell.     Configure the Setting “Turn on Script Execution” and choose the option “Allow local scripts and remote signed scripts”, which configures the Execution Policy to “RemoteSigned”.   This setting is the foundation that our PowerShell script will be executed on the systems on which you want to configure your custom tagging.     Configuring the script in your Group Policy In the Group Policy Object, navigate to Computer Configuration > Policies > Windows Settings > Scripts (Startup/Shutdown) and open the properties of “Startup”.   Once the properties window opens, navigate to the tab PowerShell Scripts, and click on “Add”. The “Edit Script” window will open. Click on “Browse…” which opens a file browser window.       Per default, the location that is opened is already the right location within your Group Policy Object folder.   Now copy your DefenderTagging.ps1 script inside this folder and select the script and confirm with “Open”.         Confirm with OK and apply the changes to your Group Policy Object. Your tagging Group Policy is now configured.     Verify that your tagging was successful The next time that your device applies the Group Policy, the settings will be configured, and you can also find your properly tagged machines in the Microsoft Defender Security Center.   Note:If the Execution Policy needs to be configured first, you might find the new tag after the GPO was applied to your device for the second time. If you want to apply both settings at the same time, you can create two Group Policies and let the one that sets the Execution Policy run before the GP containing the startup script is executed.     Finding your devices in Defender for Endpoint can take up one day for the devices to sync.     Find your tagged device’s events via advanced hunting: To find your tagged device, you can use an advanced hunting query such as the one below. Simply replace “DC=xyra,DC=local” with the distinguished name of your Active Directory domain.   DeviceInfo | where RegistryDeviceTag contains “DC=xyra,DC=local”       This concludes Part 2 of the blog series on how to use tagging effectively. Please join us for Part 3 where Steve Newby will guide you through scripting against the Defender for Endpoint API to apply tags based upon advanced hunting queries.   We welcome your feedback and questions on this or any of the other parts of this tagging blog and look forward to hearing from you.   Miriam Wiesner (@miriamxyra) and Steve Newby (@steve_newby) Program Managers @ Microsoft Defender for Endpoint Product Group

  • How to use tagging effectively (Part 1)
    by Steve Newby on January 5, 2021 at 5:00 pm

    Why Use Tagging? One important feature which often isn’t utilised correctly is the use of tags within Microsoft Defender for Endpoint.  This is a functionality that was introduced to allow you to apply a granular level of control over how you manage your devices.  In this blog we wanted to cover not only the primary uses for the tagging functionality, but also to explain some tips and tricks around how to effectively use this within your organisation.  We have split this into three parts to cover the basics but also some advanced scenarios for how to use tagging in your environment, so make sure to stay tuned to the blog for the full series.   Role Based Access Control – RBAC The primary use for tagging is to allow you to create machine groups that can then be used for applying RBAC permissions.  Really the purpose of this is to enable a level of control such that different users can log into the portal and see only the machines that they are responsible for.  For example, in a large organisation spanning multiple geos rather than each geo having their own instance of Microsoft Defender for Endpoint, you would have a single instance where access is controlled through the use of roles and machine groups.  Having a single instance means that threat hunting and automation has full visibility of all devices across the entire organisation which is critical when a threat is hitting multiple endpoints.   The diagram below shows how you would break this down, and how you could further utilise this information to feed data into a SIEM where your SOC analysts can track threats across multiple areas of the infrastructure.     Later in this blog we will talk about the different ways you can apply tags to managed devices, but in order to utilise these tags you first need to create a machine group in Microsoft Defender Security Center portal and then apply specific security groups containing the user accounts of the devices you wish you manage. This is simple to do and the setting up of these machine groups is something you would typically do early on in the setup of the tenant, before you actually start doing any onboarding. This means that each time a machine is onboarded it goes straight into the appropriate group and only the correct people have visibility straight away. Filtering One of the great benefits of tagging is using them in machine views to present different views of machine lists.  Below are some examples of why you would use tags in filtering include: Lab Machines – There is really no reason to have a separate tenant just for testing when the endpoints that report into Microsoft Defender for Endpoint can exist anywhere without any ties to a specific Azure AD or domain.  In this scenario, you might want to identify the specific lab machines with a tag:   By using this tag to create a machine group you can then exclude these machines from your threat reports or from threat and vulnerability management.   Decommissioned machines – Something we hear a lot from customers is that they have machines that they have decommissioned which they no longer want to see in their console; however, there is a very good reason why we don’t allow machines to be deleted. Just suppose there is a threat detected on the environment that originated some time back on a machine that had been decommissioned, if you deleted this from the tenant then you would have no way of understanding the source and techniques used in the breach. To address this, a machine record will remain in the tenant until the data retention period of the tenant expires.   We do understand though that you may not want to see these machines in the device list or have them show in the threat reports or threat and vulnerability management and so through the use of tags, and also machine groups, it is possible to effectively make these machines invisible.   The first stage of this would be to apply a tag against the machines, in the example below we have two machines tagged as “Decommissioned”.  Once you have set this tag you can then use the filters to exclude these tagged devices from the Device Inventory view:   Using this method is a quick and simple way to filter on your device inventory but you cannot use tag-based filtering in your reports or in threat and vulnerability management.  For this, you need to use machine groups so the next phase would be to create a machine group based on this tag, as described in the RBAC section above, at which point you can then exclude these groups from the threat and vulnerability management assessment: It should be noted though that inactive machines are automatically excluded from threat and vulnerability management after 30 days anyway.   The use of machine groups in this scenario does open up another option which would then give you the desired result of removing a machine from the tenant whilst still maintaining the record for historical threat analysis; effectively hiding it.   To achieve this, create a user group with no members and then assign it to the Machine Group:   As there are no users assigned to this group, then any users who log into the portal (with the exception of Global Admin or Security Admin) will automatically have their view of any machines with the Decommissioned tag removed from all views, including threat and vulnerability management and reporting. Plus, simply adding the Decommissioned tag to a machine will effectively “delete” the machine from the portal.     Methods of Tag allocation To utilise tags for RBAC and filtering you first need to make sure that the relevant machines have the tags applied and there are a number of methods to achieve this. Registry tagging This is via direct editing of the registry.  By setting the tag value in the DeviceTagging key (HKLM:\SOFTWARE\Policies\Microsoft\Windows Advanced Threat Protection\DeviceTagging) you are assigning a value to the machine that is picked up by Microsoft Defender for Endpoint telemetry.   There are a couple of points to be aware of when you are using the registry to tag a machine: The tag is fixed and cannot be changed through the portal, it can only be changed by modifying the registry. Only one tag can be specified in the registry. In the image above, you can see the relevant key as displayed in Regedit; however, if you are modifying the registry to assign tags to production machines it is unlikely that it is Regedit you will use to set this value.  Instead, you are likely to use a script.  Obviously when using a script, you can add a lot of variables to determine what the tag value should be, meaning you could have a single script for all tag values you want to create or have multiple scripts that you then use another method with to define the logic. What we have seen with several large organisations is utilising the onboarding script and adding a “REG ADD” command to the script and then using different onboarding scripts for different groups of machines. The value that would need to be added is:   REG ADD “HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows Advanced Threat Protection\DeviceTagging” /v Group /t REG_SZ /d TAGNAME /f   You could use this script and have it as part of a GPO where you target it against an OU or use it in System Center Configuration Manager and target the script at different Collections. However, if you wanted to keep the tagging separate from the onboarding then you may instead want to utilise a Powershell script which again you could apply via System Center Configuration Manager or another management tool. To either have a specific script, or to add to another script, the lines you would need are:   New-Item -Path “HKLM:\SOFTWARE\Policies\Microsoft\Windows Advanced Threat Protection” -Name DeviceTagging -force New-ItemProperty -Path “HKLM:\SOFTWARE\Policies\Microsoft\Windows Advanced Threat Protection\DeviceTagging” -Name “Group” -Value “TAGNAME” -PropertyType “String”   Setting the tag via Intune When using Intune, it is possible to utilise a custom policy to set the machine tag value in the registry via the WindowsAdvancedThreatProtection CSP (https://docs.microsoft.com/en-us/windows/client-management/mdm/windowsadvancedthreatprotection-csp) This diagram shows the provider: When setting the values in Intune you configure a custom profile and then define the URI to set the device tag. These are the steps for configuring this: Create Custom profile:   Give the profile a name and then add the URI value (./Device/Vendor/MSFT/WindowsAdvancedThreatProtection/DeviceTagging/Group), set a data type of “String” and then define the tag you want:   Now you assign the profile.  By assigning it to a specific group in Azure AD it means that you can base your tagging, and therefore RBAC and filtering on existing device groups you may already have in Azure AD:   You can add Applicability Rules if you want, to target it at specific Windows versions/editions, but this shouldn’t really be necessary in the case of Machine Tagging. So then it is simply a case of reviewing the profile and applying it:     Manual tagging One of the easiest ways to tag a device is to simply add a tag value through the machine page in the portal.  Through this method you can add multiple tags or remove existing tags (although not if they have been defined in the registry). Clicking onto the device page presents you with an option to “Manage Tags” where you can add and remove as required:     Tagging via API While manual tagging is great and allows you to specify multiple tags against a device to assist with RBAC and filtering, however what if you have 100’s or 1000’s of devices that you want to assign the same tag value to? In this scenario, you can use the API to mass-assign tags, we will be covering this advanced use case in Part 3 of our blog. Setting the tag on macOS Obviously, you may not just be managing Windows endpoints in your environment. Microsoft Defender for Endpoint also supports tagging macOS machines. To apply tags on this platform, you can utilise the manual method or the API method. However, if you want to automate this process, then you can push out the settings as part of a Configuration Profile (a .plist file). When you are creating the .plist file, you would need to add the following entry in order to configure the tag:               <dict>                  <key>tags</key>                     <array>                         <dict>                             <key>key</key>                             <string>GROUP</string>                             <key>value</key>                             <string>ExampleTag</string>                         </dict>                    </array>             </dict>   You can find details of how to do that here: https://docs.microsoft.com/en-us/windows/security/threat-protection/microsoft-defender-atp/mac-jamfpro-policies#step-3-configure-microsoft-defender-atp-settings   This concludes Part 1 of our blog series on how to use tagging effectively.  Please join us for Part 2 where Miriam Wiesner will guide you through applying tags based upon the Organisational Unit placement of the device within Active Directory.   We welcome your feedback and questions on this or any of the other parts of this tagging blog and look forward to hearing from you.   Steve Newby (@steve_newby) and Miriam Wiesner (@miriamxyra) Program Managers @ Microsoft Defender for Endpoint Product Group      

  • Announcing EDR in block mode general availability
    by Shweta Jha on December 9, 2020 at 5:00 pm

    We’re very excited to announce today that endpoint detection and response (EDR) in block mode is generally available.   As we announced in our public preview blog, EDR in block mode is a feature in Microsoft Defender for Endpoint that turns EDR detections into blocking and containment of malicious behaviors. This capability uses Microsoft Defender for Endpoint’s industry-leading visibility and detection capabilities and Microsoft Defender Antivirus’s built-in blocking function to provide an additional layer of post-breach blocking of malicious behavior, malware, and other artifacts that your primary antivirus (AV) solution might miss.   This feature has already helped a number of organizations stop a variety of threats where Microsoft was not their primary AV and we’re thrilled to make it now generally available for all customers.   Recently, EDR in block mode was responsible for helping to thwart the IcedID campaign. EDR in block mode kicked in and was able to protect the device from several malicious activities including evasive attacker techniques like process hollowing and steganography that lead to the deployment of the info stealing IcedID malware. Read all about how this attack went down and was stopped “ice cold” in its tracks here: EDR in block mode stops IcedID cold.   To learn more about this capability and learn now it also stopped a NanoCore RAT attack, watch the video below and check out our documentation for guidance on how to enable the feature.     We’re excited to bring this new functionality to our customers and look forward to hearing your feedback!   If you’re not yet taking advantage of Microsoft’s industry leading optics and endpoint detection capabilities, sign up for a free trial of Microsoft Defender Endpoint today.

sdgdmin1
No Comments

Sorry, the comment form is closed at this time.

Translate »
Share This