Nowadays it is common for Red Teamers to find more or less advanced endpoint and network protection mechanisms during their assessments. With a big share of the enterprise market taken by Microsoft, it is important to be familiar with Windows/Azure AD and Microsoft 365 Defender. In one of our latest assessments we managed to get an infection on a Windows laptop with administrator privileges, and we found that the internal network was protected by Microsoft 365 Defender. This blog aims to explain how the Red Team disabled Microsoft Defender for Endpoint, the EDR solution from Microsoft, in the laptop that we achieved to infect with malware via spear phishing.
What is Microsoft 365 Defender
Microsoft 365 Defender is a unified enterprise defence suite that coordinates detection, prevention, investigation, and response across the different endpoints that a company has.
More specifically, Windows 365 Defender is composed of the following services:
-
Defender for Endpoint: An endpoint platform for protection, post-breach detection, automated investigation, and response. It is installed in the computers used within a company to protect them and alert the Blue Team in case an attack or malicious behaviour is detected. On top of the default configuration provided by Microsoft, security teams can add custom detection rules to improve the capabilities of the tool.
-
Defender Vulnerability Management: It delivers continuous asset visibility, intelligent risk-based assessments, and built-in remediation tools to help security and IT teams prioritise and address critical vulnerabilities and misconfigurations across the organisation.
-
Defender for Office 365: It safeguards organisations against malicious threats posed by e-mails, links and collaboration tools.
-
Defender for Identity: A cloud-based security solution that leverages the on-premises Active Directory signals to identify, detect, and investigate advanced threats, compromised identities, and malicious insider actions directed at the organisation.
-
Azure Active Directory (Azure AD) Identity Protection: Automates the detection and remediation of identity-based risks in cloud-based Azure AD.
-
Microsoft Defender for Cloud Apps: It is a cross-SaaS solution bringing visibility, data controls, and threat protection to cloud applications.
How to detect Microsoft Defender for Endpoint
Once a foothold is obtained in the internal network of the target company, initial reconnaissance of the infected machine and the environment is key. For the purpose of this blogpost, just by checking the running processes in a Windows machine it can be clearly seen that Microsoft Defender for Endpoint is present in the environment. More specifically, the following processes reveal the presence of the different security measures provided by Microsoft.
-
MsMpEng.exe: Windows Antimalware Service Executable that enables Windows Defender to continuously monitor the computer for potential threats.
-
SenseNdr.exe: Microsoft Defender for Endpoint process in charge of passive network data collection.
-
MsSense.exe: Main Microsoft Defender for Endpoint process.
As shown in the screenshot above, Microsoft Defender for Endpoint processes run as SYSTEM or LOCAL SERVICE. SYSTEM services are elevated processes that cannot be controlled by regular administrator users, and therefore cannot be directly killed from, for example, Windows Task Manager. On the other hand, LOCAL SERVICE processes can be killed by administrator, but they will respawn automatically due to the service running, which cannot be stopped by administrator.
How to disable Microsoft Defender for Endpoint
During our assessment it was found that the development laptops used by the target company had local unrestricted administrator privileges. This was intended by the company to allow their developers to install the necessary tools to perform their tasks. However, the Red Team abused the local administrator privileges to kill the Microsoft Defender for Endpoint and antivirus related processes using the publicly available tool Backstab* developed by one of our Securify colleagues Yasser.
To kill the protected processes and at the same time kill the SenseNdr.exe process every time it is respawned by the local service, the code of Backstab was slightly modified to run the kill command every three seconds. In this way the SenseNdr.exe process is also neutralised. The modified code on the main.c class of Backstab can be seen in the following code snippet.
# Original code
...
else if (isRequestingProcessKill) {
Info("Killing process\n");
KillProcessHandles(hProtectedProcess);
Success("Killing process succeeded");
}
...
# Modified code
...
else if (isRequestingProcessKill) {
while (TRUE) {
// Get new PID of the respawned process from name
GetProcessPIDFromName(charToWChar(h), &dwPid);
hProtectedProcess = ProcExpOpenProtectedProcess(dwPid);
// Kill process (if respawned)
KillProcessHandles(hProtectedProcess);
Sleep(3000);
}
}
...
To avoid antivirus detection, an obfuscated version of the modified tool was uploaded to the infected machine using the active Cobalt Strike beacon and executed to kill the three processes mentioned above.
After these processes were killed, it was possible for the Red Team to freely execute any command in the infected laptop. Talks with the Blue Team after the project finished confirmed that both the execution of this attack and further execution of other attacks later on this machine did not trigger any alert on Microsoft 365 Defender, making the Blue Team blind to the infection. As shown in the screenshot below, the above-mentioned processes were killed by destroying the needed handlers with Backstab. It is important to note that sometimes the processes might not be killed completely, but still they are not able to run properly due to the lack of handlers.
With this procedure, even the local antivirus was disabled, giving complete freedom to the Red Team to upload new malware to the machine with no risk of detection. The following screenshot shows the error raised by Windows when the antivirus protection settings are opened from the Control Panel.
Possible ways to detect & prevent the attack
Like any other attack, some anomalies are created that might be detected by the Blue Team if they look at the correct place. The following countermeasures could be implemented to prevent Backstab from killing the targeted processes and/or detect that the attack has been executed:
-
It is required to run Backstab as administrator to execute this attack. Therefore, the easiest solution would be to deny administrator privileges to the organisation employees and rely on Microsoft Defender for Endpoint to detect potential local privilege escalation attacks. In case employees need to have this privilege like the company we tested, Privilege Access Management (PAM) tools can be used to restrict the actions that administrator privilege can be used for.
-
Backstab makes uses of ProcExp Windows driver, and this driver is dropped to disk and then loaded. However, Backstab is not a program signed by Microsoft. Therefore, a non signed program dropping and loading a driver could be detected as a malicious behaviour and blocked by Microsoft Defender for Endpoint.
-
Before attempting to kill any process, Backstab needs to obtain 'SeDebugPrivilege' level of privilege within the system. This level of privilege allows its owner to debug processes owned by other users (e.g. SYSTEM). This behaviour is considered insecure for user initiated process, and therefore it can be flagged as malicious to prevent further execution of the attack.
-
Once the attack is executed and Microsoft Defender for Endpoint processes are killed, the affected computer will stop sending telemetry data to Microsoft 365 Defender portal. By cross-checking data with other platforms such as Azure AD could be found that the system is still running but Defender for Endpoint is not running. The affected computer could not be trusted anymore, and therefore it should be forced to shutdown and block its connection to the network until the Blue Team has concluded the reason(s) of the telemetry failure.
Conclusions
EDRs and IDSs are great tools that every organisation should use to protect their internal network in case of security breach. However, this tools are not perfect and can be bypassed, specially if the configuration of the network and/or the systems in it is not secure. In this case, unlimited administrator privileges in the development laptops of the company caused this attack to be possible.
Once the infected computer was excluded from Microsoft Defender for Endpoint protection, it was really useful for the Red Team to have an "attacker's bastion" within the internal network. From here, other tasks such as further reconnaissance and attacks to attempt privilege escalation within the network were executed in a much easier way, (almost) without the continuous feeling of being detected that Red Teamers suffer just before sending a command from the Command & Control panel.
It is important to note that this attack was possible due to the over-permissive administrator permissions that were given to the developers of the company. However, in case local privilege escalation would be needed before executing Backstab, there is a high chance that the EDR will be able to detect the common privilege escalation techniques.
Acknowledgments
Big thanks to my colleague Yasser (@Yas_o_h) for creating Backstab* and helping during the Red Teaming assessment.
*Backstab Github link:
