4.5 Defender for Servers: Workload Protection

Defender for Servers: Workload Protection

Introduction

Defender for Servers is the most widely deployed CWP plan because virtual machines are the most common cloud workload and the most common target for attackers. A compromised VM gives an attacker a foothold in your cloud environment — from there, they can access other resources, steal credentials, move laterally, and exfiltrate data. Defender for Servers provides the detection and prevention capabilities that make VMs defensible.

This subsection covers both Plan 1 and Plan 2, the specific protection features available at each tier, and the investigation workflow when a server alert fires.

Plan 1 vs Plan 2

Defender for Servers offers two tiers with significantly different capabilities and cost.

MDE integration: endpoint detection for cloud VMs

The foundation of both Plan 1 and Plan 2 is MDE integration. When Defender for Servers is enabled, the MDE sensor is deployed to VMs (via auto-provisioning — subsection 4.2). This provides the same endpoint detection you learned in Module 2: process monitoring, network connection tracking, file event capture, and behavioral analysis.

Security alerts from the MDE sensor on cloud VMs appear in both the Defender for Cloud alerts page and the MDE device inventory. The VM is simultaneously a cloud resource (managed by Defender for Cloud) and an endpoint (managed by MDE). You investigate server alerts using the same techniques from Module 2 — device timeline, process tree analysis, live response, investigation package collection — with the additional cloud context that Defender for Cloud provides (which subscription, which resource group, which network, which other resources the VM can reach).

Just-in-time VM access (JIT)

JIT VM access reduces the attack surface by closing management ports (SSH port 22, RDP port 3389) on VMs by default and opening them only when an administrator requests access — and only for the requesting IP address, for a limited time window.

Without JIT, management ports are either permanently open (allowing anyone on the internet to attempt connections — brute-force targets) or permanently closed (requiring complex VPN or bastion configurations for legitimate access). JIT provides the middle ground: closed by default, opened on demand for authorised users.

How JIT works: When enabled, JIT creates NSG rules that block inbound traffic to management ports. When an administrator needs access, they request it through the Azure portal (or API). The request specifies which port, which source IP, and for how long (typically 1-3 hours). Defender for Cloud validates the request (checking RBAC permissions), creates a temporary NSG rule that allows the specific source IP to connect to the specific port, and automatically removes the rule when the time window expires.

Investigation relevance: JIT access logs show who requested access, when, from which IP, for which port, and for how long. During a compromised VM investigation, checking JIT logs tells you whether the attacker gained access through a legitimate JIT request (the administrator’s account was compromised) or through other means (a vulnerability, a misconfigured service). If no JIT request exists for the compromise window, the attacker did not use the management ports — they exploited a different entry point.

1
2
3
4
5
6
7
8

// JIT access requests — who accessed which VMs via management ports
SecurityAlert
| where TimeGenerated > ago(7d)
| where AlertType has "JIT"
| extend VMName = tostring(ExtendedProperties.["Compromised entity"])
| extend RequestorIP = tostring(ExtendedProperties.["Client IP"])
| project TimeGenerated, AlertName, VMName, RequestorIP
| order by TimeGenerated desc

Adaptive application controls

Adaptive application controls are application allowlisting for cloud VMs. Defender for Cloud analyses the applications running on each VM over a learning period, builds a baseline of “normal” applications, and then recommends an allowlist. When enabled in enforce mode, only applications on the allowlist can execute — anything else is blocked and generates an alert.

This is one of the most effective protections against malware on servers because it inverts the detection model. Instead of trying to identify malicious applications (which requires knowing what is malicious), it only allows known-good applications (which requires knowing what is legitimate). A zero-day malware sample that no antivirus has ever seen is blocked by adaptive controls because it is not on the allowlist — it does not need to be recognised as malicious. It only needs to be unrecognised as legitimate.

Audit mode vs enforce mode: Start with audit mode (recommendations generated but not enforced) to identify the application baseline. After verifying the baseline is complete (all legitimate applications are included), switch to enforce mode. This is the same phased deployment approach as ASR rules (Module 2.3) — audit first, then enforce.

File integrity monitoring (FIM)

FIM tracks changes to critical system files, registry keys, and configuration files. When a file that should not change is modified (a system binary is replaced, a configuration file is altered, a registry key is modified), FIM generates an alert.

FIM is critical for detecting persistence mechanisms that modify system files — rootkits that replace system binaries, malware that modifies boot configuration, and attackers who alter configuration files to create backdoors. Unlike process-level monitoring (which detects execution), FIM detects changes at rest — even if the modified file has not yet been executed.

What FIM monitors: Windows system files (System32 directory), Linux system files (/etc, /bin, /sbin), registry keys related to auto-start (Run keys, services, scheduled tasks), and application configuration files (web server configs, database configs). The monitored paths are configurable — you can add custom paths specific to your applications.

FIM alerts in investigation: When investigating a compromised server, check FIM data for unauthorized file changes during the compromise window. If the attacker modified system files or configuration files, FIM shows exactly which files were changed, when, and the before/after content hash. This evidence is critical for the eradication phase — you need to know every file the attacker modified to restore the system to a clean state.

Vulnerability assessment

Defender for Servers Plan 2 includes integrated vulnerability assessment that continuously scans VMs for known CVEs in installed software. The assessment uses Microsoft Defender Vulnerability Management (MDVM) — the same engine as TVM in Module 2.8 — or Qualys (a third-party scanner option).

Agentless scanning (Defender CSPM) complements agent-based scanning by scanning VM disks without installing an agent. Agentless scanning discovers software inventory and vulnerabilities on VMs that do not have the MDE sensor installed — providing visibility even for unmanaged VMs.

Vulnerability assessment results appear as security recommendations in Defender for Cloud (“Machines should have vulnerability findings resolved”) and as vulnerability data in the MDE TVM dashboard. The findings include the CVE identifier, affected software and version, CVSS score, exploit availability, and remediation guidance (which patch to install or which version to upgrade to).

Server alert investigation workflow

When a Defender for Servers alert fires (e.g., “Suspicious process detected,” “Cryptocurrency mining activity detected,” “Anomalous SSH brute force”), the investigation combines cloud context with endpoint investigation techniques.

Step 1: Cloud context. Before diving into the endpoint investigation, understand the VM’s cloud context: which subscription and resource group does it belong to? Is it internet-facing (public IP) or internal only? Which network security groups restrict its traffic? Which other resources can it reach (network topology)? This context determines the investigation’s scope and severity.

Step 2: Endpoint investigation. Use the techniques from Module 2 — device timeline, process tree analysis, network connections, file events. The MDE sensor on the VM provides the same telemetry as for any other endpoint.

Step 3: Cross-resource correlation. Check whether the compromised VM accessed other Azure resources during the compromise window. Did it access storage accounts (data exfiltration)? Did it connect to other VMs (lateral movement)? Did it make Azure Resource Manager API calls (privilege escalation)? Cloud-specific investigation extends the endpoint investigation to the cloud resource layer.

FIM in practice: what to monitor and how to investigate

File integrity monitoring is most effective when configured to monitor the files that attackers actually modify. The default FIM policy monitors common system directories, but customising it for your specific workloads significantly improves signal quality.

Critical paths to monitor on Windows servers: C:\Windows\System32 (system binary replacement), C:\Windows\System32\drivers\etc\hosts (DNS poisoning), HKLM\Software\Microsoft\Windows\CurrentVersion\Run (auto-start persistence), HKLM\SYSTEM\CurrentControlSet\Services (service-based persistence), and application-specific configuration files (web.config for IIS, appsettings.json for .NET applications).

Critical paths to monitor on Linux servers: /etc/passwd and /etc/shadow (user account manipulation), /etc/crontab and /etc/cron.d/ (cron-based persistence), /etc/ssh/sshd_config (SSH configuration changes), /usr/bin/ and /usr/sbin/ (system binary replacement), and /var/www/html/ or equivalent web root (web shell deployment).

When FIM detects a change, the alert includes: the file path, the change type (Created, Modified, Deleted), the before and after content hash, the timestamp, and the user/process that made the change. During investigation, the key question is: “Was this change authorised?” Check the change against deployment schedules (a system update deploying new binaries at 02:00 is expected; the same binaries changing at 14:37 outside any deployment window is suspicious).

1
2
3
4
5
6
7
8
9

// FIM changes on monitored servers in the last 24 hours
ConfigurationChange
| where TimeGenerated > ago(24h)
| where ConfigChangeType == "Files" or ConfigChangeType == "Registry"
| extend FileName = tostring(FileSystemPath)
| extend ChangeType = tostring(ChangeCategory)
| summarize ChangeCount = count() by Computer, FileName, ChangeType, bin(TimeGenerated, 1h)
| where ChangeCount > 0
| order by TimeGenerated desc

Vulnerability assessment workflow

When Defender for Servers discovers CVEs on a VM, the findings appear as recommendations. But a list of 200 CVEs on a server is not actionable without prioritisation. Use the following workflow to turn vulnerability data into action.

Step 1: Filter by exploitability. Not all CVEs have public exploit code. Focus on CVEs with known exploits — these are the ones attackers actually use. MDVM provides an “Exploit Available” flag for each CVE. Filter to only those with confirmed exploits.

Step 2: Filter by exposure. A CVE on an internet-facing VM with a public IP is higher risk than the same CVE on an internal VM behind a firewall. Cross-reference vulnerability data with network exposure data (does the VM have a public IP? Is the vulnerable port exposed through the NSG?).

Step 3: Check attack paths. If Defender CSPM is enabled, check whether any attack path uses the vulnerability as a link. A CVE that appears in an attack path leading to sensitive data is the highest priority — it is not just theoretically exploitable, it is part of a concrete exploitation chain.

Step 4: Prioritise and patch. Address CVEs in order: exploitable + internet-facing + in attack path (critical, patch today), exploitable + internet-facing (high, patch this week), exploitable + internal (medium, patch within 30 days), no known exploit (low, include in regular patch cycle).

Linux server protection specifics

Defender for Servers supports both Windows and Linux, but some features behave differently on Linux.

MDE on Linux provides threat detection including anti-malware (real-time file scanning), EDR (process monitoring, network connections), and vulnerability assessment. However, MDE on Linux does not provide all the same remediation actions as Windows — live response is available but with fewer commands, and some response actions (device isolation via network) require Azure NSG modifications rather than host-based isolation.

Adaptive application controls on Linux use auditd-based monitoring rather than Windows AppLocker. The learning and enforcement model is similar, but the underlying technology differs. Ensure auditd is installed and running on Linux VMs before enabling adaptive controls.

FIM on Linux monitors file changes through inotify (for real-time change detection) or scheduled scanning (for periodic assessment). Inotify-based monitoring provides faster detection but has a limit on the number of watched files — on servers with very large file systems, prioritise monitoring critical paths rather than watching everything.

Knowledge check