Cryptsus Blog rss-feed  |  We craft cyber security solutions.

Microsoft Defender for Endpoint (MDE) on Linux AWS EC2

By: Jeroen van Kessel  |  February 15th, 2023 | 10 min read

Today we will discuss Microsoft Defender for Endpoint (MDE) on AWS EC2 virtual machines. Although AWS offers integrated EC2 security detections with AWS GuardDuty, we chose Microsoft Defender for Endpoint (MDE), formerly Microsoft Defender Advanced Threat Protection (MDATP), as EDR/AV agent for this blog post. MDE is part of the Microsoft E5 license and is compatible with Windows and Linux. This blog post is not an installation guide but a high-level strategy guide to deploying MDE in your Linux AWS EC2 estate.

AWS GuardDuty versus MDE

GuardDuty EC2 security detections can run in parallel with MDE. AWS GuardDuty for EC2s focuses more on signature-based malicious detections and IAM abuse, whereas MDE leans more towards OS behavioural detection. This means GuardDuty can detect a malicious Command and Control (C2) or RAT when its IP is flagged as malicious via a third-party Threat Intelligence source. APT (Advanced Persistent Threats) will typically not be (re-)using such IPs and domain names. MDE does a better job at looking for abuse within Linux internals and other possible malicious behaviour. Also, some custom Amazon EC2 AMIs are incompatible with GuardDuty.

AWS EC2 resource requirements

MDE is compatible with Windows and most Linux distributions, such as RHEL, CentOS, Ubuntu, Debian, Amazon Linux 2, SUSE, and Fedora. However, EC2s should have at least 2GB memory and 1vCPU available in order to prevent performance impact. Therefore, first upgrade any AWS T2 nano, micro and any small EC2 instances: A1 medium, t4g.nano, m6g.medium, and T3 Nano EC2s. This is the costs of running MDE Endpoint Detection and Response in blocking mode.

Ad-hoc MDE installation

Follow the official Microsoft guide if you can install mdatp (MDE) from the official Microsoft repository.

If you have an isolated AWS environment where APT, YUM, and DNF Linux package managers are not allowed to communicate with external repositories, you can install MDE from source. is a collection of package repositories and related content (i.e. config files and keys). The content of this web server directory is public by design. You can install MDE from source in the following order:

sudo yum/apt-get install mde-netfilter_<version>.rpm
sudo yum/apt-get install mdatp_<version>.rpm
sudo python3

Remember that you must also upgrade the MDE agent binary from time to time to keep leveraging the latest detection features. Therefore, this deployment strategy is not desired. You can check when your mdatp binary expires with: sudo mdatp health –field product_expiration Also, look into embedding the MDE agent into your managed AWS AMIs.

Microsoft published a spreadsheet of URLs used by Microsoft Defender for Endpoint. Unfortunately, there are a lot of different Microsoft URLs the MDE agent needs to communicate with. Make sure to allow TLS sessions to these URLs within your proxy solution and OS. Allow listing is not required if you did not deploy any additional security solutions which filter outgoing or incoming URLs. You can test this by running the following commands:

$ sudo mdatp connectivity test

Testing connection with ... [OK]
Testing connection with ... [OK]
Testing connection with ... [OK]
Testing connection with ... [OK]
Testing connection with ... [OK]
Testing connection with ... [OK]
Testing connection with ... [OK]
Testing connection with ... [OK]
Testing connection with ... [OK]
Testing connection with ... [OK]
Testing connection with ... [OK]
Testing connection with ... [OK]
Testing connection with ... [OK]
Testing connection with ... [OK]
Testing connection with ... [OK]

$ sudo mdatp definitions update

Security intelligence is up to date

EC2 Instance Tagging

AWS EC2 Instance IDs (e.g. i-1234567890abcdef0) are often not the exact same string as the hostname of the EC2 Operating System (e.g. AWS uniquely identifies an EC2 by instance ID, whereas MDE identifies EC2s by hostname. It is wise to tag your EC2s in MDE to identify the right AWS EC2s.

After completing the MDE onboarding of an EC2, navigate to the Endpoints panel within Microsoft Defender 365 management interface and search by the group tags using the Instance ID of the EC2 instances. This one-liner can do this for you on most Linux EC2s:

mkdir -p /etc/opt/microsoft/mdatp/managed echo '{ "edr": { "tags": [{ "key": "GROUP", "value": "AWS"}]}}' > /etc/opt/microsoft/mdatp/managed/mdatp_managed.json

Unfortunately, we could not configure more than one tag variable within the mdatp_managed.json file, but you can manually configure multiple tags via the Microsoft 365 Defender portal. This way, you can set additional tags to correlate which EC2 instances belong to a specific AWS account ID, application or business unit.

MDE Exclusions

Thoroughly test for any performance impact by MDE if you have a server/application with substantial write actions on your Linux EC2s. Testing performance impact can be done by testing MDE in passive mode versus blocking mode. mdatp is configured by default in blocking mode. Next, carefully evaluate any possible file, folder and process exclusions. This way, complete folders, files or processes can be excluded from scanning by MDE.

$ sudo mdatp exclusion file add <path>
$ sudo mdatp exclusion folder add <path>
$ sudo mdatp exclusion process add <path>

Malicious actors can abuse MDE exclusions. However, if you deem it necessary to configure MDE exclusions, leverage a configuration management tool, such as AWS SSM, Ansible, or SCCM, to distribute MDE file, folder and process exclusions. Amazon Machine Images (AMIs) are supported and maintained images provided by AWS that delivers the information required to launch an instance. Updated regularly to include the latest components, and these updates are also made available, but only sometimes. Red Hat Enterprise Linux (RHEL) images are made available within Amazon Web Services (AWS) periodically as part of the standard update release process. Regular updates within virtual machines are recommended, as repository content can be expected to be newer than the underlying AMI content. This will lower your attack surface measured by the built-in MDE Threat and Vulnerability Management (TVM) module.

Check MDE is running in Blocking mode

Download and unzip the following test script and run it. Detection should be raised in the M365 Defender portal. Make sure mdatp is running in blocking mode. This way, MDE will automatically block any possible malicious attack within your EC2. Next, run mdatp health and pay special attention to the fields: healthy, org_id, cloud_enabled, passive_mode_enabled, automatic_definition_update_enabled, definitions_updated_minutes_ago, and edr_device_tags. Temper protection is not (yet) available for Linux:

$ sudo mdatp health

healthy : true
health_issues : []
licensed : true
engine_version : "1.1.19900.2"
app_version : "101.73.77"
org_id : "e123c12a-e1ab-18a3-65a4-12c132acaeaf"
log_level : "info"
machine_guid : "ac122235-a021-12af-1231-1aca22da32a4"
release_ring : "Production"
product_expiration : Mar 28, 2023 at 07:48:22 AM
cloud_enabled : true
cloud_automatic_sample_submission_consent : "safe"
cloud_diagnostic_enabled : false
passive_mode_enabled : false
real_time_protection_enabled : true
real_time_protection_available : true
real_time_protection_subsystem : "fanotify"
supplementary_events_subsystem : "auditd"
tamper_protection : "disabled"
automatic_definition_update_enabled : true
definitions_updated : Feb 12, 2023 at 04:40:29 PM
definitions_updated_minutes_ago : 67
definitions_version : "1.381.3489.0"
definitions_status : "up_to_date"
edr_early_preview_enabled : "disabled"
edr_device_tags : [{"key":"GROUP","value":"AWS"}]
edr_group_ids : ""
edr_configuration_version : "30.199999.8409685.5582739.6176165-37e7f904465328aeb32de2d5cf3c3787580d7645"
edr_machine_id : "a123343487acadf1b214e053f642567e12495744"
conflicting_applications : []
network_protection_status : "stopped"

Test Remote Isolation

As part of your incident response process, you will need to test if you can remotely isolate your Linux VMs by using the backend Microsoft 365 Defender portal. In case of an EC2 compromise, you can remotely cut off the network connections within the EC2. The EC2 can still communicate with Microsoft's backend Microsoft 365 Defender (SaaS) portal but can no longer establish any other network connections. This isolation feature can be dysfunctional if you do not configure the proxy URLs correctly or if your AWS environment is behind a full VPN tunnel. Both EC2s in blocking and passive mode can be remotely isolated. Figure 1 shows how to isolate an EC2 VM with MDE remotely:

Figure 1: Remote isolate Linux EC2 VM with MDE

Important tip: enable Live Response in the Microsoft 365 Defender backend portal settings for all Linux servers. This way, you can remotely execute and download possible evidence and perform remediation on compromised Linux EC2 systems. Figure 2 shows where to enable Live Response:

Figure 2: Enable Live Response

APT actors around the world specialise in bypassing and disabling MDE. Keep this in mind and make sure you can detect this and have an AWS Cloud DR plan if you cannot remotely isolate EC2s with MDE.

Pricing - Microsoft Defender licensing

You can deploy MDE on AWS EC2s in at least two ways - via Microsoft Defender for Cloud and Microsoft Defender for Endpoint.

Microsoft Defender for Cloud can license an MDE roll-out for $5,00 or $15,00 per system per month. Next, Microsoft charges you $6,80 for every container per Kubernetes vCore per month and $0.29 per container image digest. Therefore, deploying Microsoft Defender for Cloud on Kubernetes clusters can be costly at scale. Defender for Cloud can also detect possible attacks on database level. Microsoft Defender for Cloud provides an easy roll-out when no provisioning tool is available. However, this comes with a price.

Alternatively, you can "just" deploy MDE. Microsoft Defender for Endpoint can be licensed for $5,00 per system per month via an E5/A5 plan 2, which can be discounted depending on your MCA.

MDE on Elastic Kubernetes Service (EKS) nodes

AWS Elastic Kubernetes Service (EKS) runs on Amazon-managed EC2 instances as PaaS (Platform as a Service). This means AWS is managing EKS EC2 nodes for you. However, you can provision MDE on these EKS EC2s as well. The point of running an EDR agent like MDE on your EKS nodes is for a further entrenched defence-in-depth strategy. A significant motivation for adversaries to break out of containers is to get access to the Kubernetes nodes to get more access and launch more harmful attacks. MDE can detect and prevent such lateral movement, downloading malicious code, calling back to Command and Control (C2) servers, and other OS-related attacks.

Overall Security Detection Framework

Although defining an overall AWS EKS security detection framework is not the goal of this blog post, it can be helpful to lay out the different levels of security detection opportunities. Leverage GuardDuty for EKS logs to get insights into your EKS cluster(s). Kubernetes EKS audit logs analysis via GuardDuty can be integrated into Microsoft Sentinel SIEM.

EDR solutions such as CrowdStrike Falcon, SentinelOne and MDE are not meant to be deployed in containers. Therefore, use Falco for container security on kernel level. Falco can also be integrated into Microsoft Sentinel SIEM. This is explained in this blog post.

With this alternative deployment strategy, you can cover the platform (AWS plus EKS), OS (MDE) and containers with Falco. CI/CD pipeline DevSecOps can be performed separately depending on your solution(s). At scale, this can be the most cost-efficient deployment. Figure 3 shows this strategy in a diagram:

Figure 3: High-level cloud security detection overview MDE, Falco and AWS GuardDuty with Sentinel SIEM

Feel free to contact us to plan your cloud security defence with Cryptsus. We specialise in large-scale MDE roll-outs and cloud security building blocks.

Discussion and questions