The NE Endpoint Landscape

The current state: deployed but not engineered

Northgate Engineering has M365 E5 licensing for all 810 staff. Defender for Endpoint P2 is included. All 865 endpoints are enrolled in Intune. The endpoint security products are available. The gap is between available and configured.

MDE onboarding: 780/865 (90%). The initial onboarding push reached 90% of the fleet. The remaining 85 devices break down into four categories: 45 devices that are co-managed with SCCM and were not included in the Intune EDR onboarding profile, 22 BYOD devices enrolled in Intune but excluded from the EDR profile because it targets only corporate-owned devices, 12 devices offline for more than 30 days (employees on leave, retired hardware still in the asset register), and 6 devices where the MDE sensor failed to install due to a conflicting legacy McAfee agent that was never uninstalled after the product migration. The last 10% is always the hardest — each category requires a different remediation approach. Module ES2 covers onboarding troubleshooting and completion.

AV configuration: default. Defender AV runs on all onboarded devices. Cloud protection is at the default level — not High or High+. Block at First Sight is enabled because it defaults to on. Real-time protection is active. But the cloud protection level determines how aggressively the cloud ML models analyze unknown files. Default level provides basic cloud lookups with standard analysis timeouts — the file metadata is sent to the cloud, and if the cloud has seen the file before, it returns a verdict. If the file is unknown, the default level returns an "allow" verdict after a brief timeout. High+ extends the analysis window, requests full file uploads for detonation in a cloud sandbox, and blocks files the cloud has not seen before while analysis continues — significantly better protection against zero-day and targeted malware, with no additional licensing cost. The only tradeoff is a marginally longer verdict latency for unknown files, typically under 10 seconds, which is invisible to users opening documents or running applications in practice. Moving from Default to High+ is a zero-impact, zero-cost improvement that NE has not made.

ASR rules: zero in block mode. No ASR rules have been configured through Intune or Group Policy. NE has the prevention capability that could block Office from spawning PowerShell, block LSASS credential theft, block persistence through WMI subscriptions, block executable content from email clients, block JavaScript and VBScript from launching downloaded executables — and none of it is active. There are 18 configurable ASR rules. Each can be set to Not configured, Audit, Warn, or Block. At NE, all 18 are at Not configured — not even generating the audit telemetry that would show what they would have blocked. This single gap means the entire prevention layer from Section 0.3 is operating at minimum capacity. The AV catches known malware on disk. Everything else — fileless execution, LOLBin chains, credential theft, persistence mechanisms — executes freely.

Compliance policies: exist but do not enforce. Intune compliance policies are configured and assigned. Devices are evaluated against the policy requirements — BitLocker, firewall, minimum OS version, AV enabled. Devices that fail are marked "non-compliant" in Intune. But no Conditional Access policy references the compliance state. A non-compliant device with BitLocker disabled, an outdated OS, or AV not running can still access all M365 resources normally. The compliance policy measures configuration health but does not enforce consequences for non-compliance — it generates a report that nobody acts on. At NE, approximately 12% of devices are non-compliant at any given time, primarily due to deferred OS updates. Those devices access the same resources as compliant devices. Module ES3 connects compliance to Conditional Access, turning the measurement into enforcement — a non-compliant device is blocked from M365 resources until the compliance issue is remediated.

The remaining gaps: detection, forensics, hardening, servers

Custom detections: zero. The Advanced Hunting console is available and the DeviceEvents tables are populated with telemetry from 780 devices. But no custom detection rules have been created. NE depends entirely on Microsoft's built-in MDE alerts for threat detection. Built-in alerts catch commodity malware and known attack tools — default-configuration Mimikatz, common webshells, Cobalt Strike with unmodified profiles. They do not cover NE-specific patterns, environment-specific baselines, or the targeted techniques that custom operators use against defense supply chain companies. Module ES8 builds the custom detection rules that close this gap.

Forensic readiness: minimal. Windows audit policies are at default — process creation auditing is not enabled, command-line logging is not captured, object access auditing is off. PowerShell ScriptBlock logging is not configured. Sysmon is not deployed on any endpoint. KAPE targets and Velociraptor agents are not pre-staged. If an incident occurs tomorrow, the IR team will find MDE's DeviceEvents tables with some process telemetry, but the detailed event log evidence that forensic investigation requires — the full command lines, the script contents, the registry modification chains, the file access records — was never generated. The practical impact: after CHAIN-ENDPOINT, the IR team could determine that the attacker used PowerShell (from DeviceProcessEvents) but could not determine what the PowerShell script actually did (no ScriptBlock log). They could determine that registry keys were modified (from DeviceRegistryEvents) but could not reconstruct the full persistence mechanism without Sysmon's Event ID 12 and 13 detail. The investigation produced a "probable scope" assessment rather than a definitive one — and the organization could not confirm whether data exfiltration occurred, which meant they could not determine their regulatory notification obligations under GDPR Article 33.

Server and Linux coverage: significant gaps. The 12 Windows servers are partially covered — 8 are onboarded to MDE through the unified agent. The remaining 4, including 2 domain controllers, have the legacy MMA agent with limited MDE functionality — no live response, no automated investigation, and limited custom detection coverage. Domain controllers are particularly critical because they process every authentication event in the organization and are the primary target for credential-based attacks like DCSync and Golden Ticket. The 8 Linux servers — 6 RHEL running the CAD/CAM rendering farm and 2 Ubuntu — are not onboarded to MDE at all. The mdatp agent has not been installed. These servers have no endpoint security monitoring beyond their local configuration. The RHEL servers are the crown jewels of NE's IT infrastructure — they process the engineering intellectual property from defense contracts that industrial espionage operators specifically target.

Hardening: BitLocker only. BitLocker is the single hardening control deployed across the fleet, required for Cyber Essentials Plus certification. CIS benchmarks have not been applied — endpoints run default Windows configurations. LAPS is not deployed, so every endpoint shares the same local administrator password set during image deployment three years ago. Credential Guard is not enabled on any device. The hardening layer is effectively absent except for disk encryption.

// NE fleet health — onboarding, sensor health, OS distribution
DeviceInfo
| where Timestamp > ago(1d)
| summarize arg_max(Timestamp, *) by DeviceId
| summarize
    TotalDevices = count(),
    ActiveSensors = countif(SensorHealthState == "Active"),
    InactiveSensors = countif(SensorHealthState == "Inactive"),
    Windows = countif(OSPlatform == "Windows10" or OSPlatform == "Windows11"),
    WindowsServer = countif(OSPlatform startswith "WindowsServer"),
    Linux = countif(OSPlatform == "Linux"),
    MacOS = countif(OSPlatform == "macOS")

Run this query against your own environment. The TotalDevices number should match your asset register. If ActiveSensors is lower than TotalDevices, the gap represents devices that are onboarded but not reporting — which could be offline devices, sensor failures, or attacker-disabled sensors. The OS distribution tells you which platform-specific configurations you need: Windows ASR rules and Intune policies, Linux mdatp tuning, macOS system extensions.

What an attacker sees

An attacker who compromises an NE user account — through phishing, credential spray, or session hijacking — encounters this endpoint security posture in sequence. Understanding the attacker's progression reveals why the compound effect of multiple gaps is far worse than the sum of individual gaps.

The phishing payload executes without ASR interference — no rules block Office from spawning child processes or scripts from launching downloaded content. The LOLBin chain runs unimpeded. Cloud AV at default level performs a basic check but the in-memory execution bypasses file-based scanning. The attacker has code execution on the endpoint within seconds of the user clicking the link. An ASR rule in block mode would have stopped this chain at Phase 2. In audit mode, it generates a log entry. At NE, it is not configured at all — no log, no block, no visibility.

Persistence establishment is trivial. The attacker creates a scheduled task and a registry run key. No ASR rule blocks the persistence technique. No Sysmon captures the Event ID 12 and 13 registry modifications. No custom detection rule alerts on scheduled task creation by a scripting engine parent process. The persistence survives the next reboot, and the attacker has a stable foothold that will remain active until someone discovers and removes both mechanisms — which requires forensic evidence that is not being collected.

Privilege escalation succeeds because Credential Guard is not enabled and the LSASS ASR rule is not in block mode. The attacker dumps LSASS via comsvcs.dll and obtains NTLM hashes for every user who has logged into the machine — including domain admin accounts that authenticated to the endpoint for remote support three days earlier. If Credential Guard were enabled, the hashes would be isolated in a virtualization-based security container and the dump would return empty. If the LSASS ASR rule were in block mode, the comsvcs.dll call would be blocked before it read LSASS memory. Neither control is configured.

Lateral movement is straightforward because LAPS is not deployed. The local administrator hash obtained from LSASS is valid on every endpoint in the fleet — 865 machines, all with the same local admin password. The attacker uses pass-the-hash with WMI to access any target machine without triggering a failed authentication event. No custom detection rule alerts on the lateral movement pattern because no custom rules exist. No network segmentation policy restricts workstation-to-workstation WMI traffic. The attacker moves from the initial compromised endpoint to the file server, the RHEL rendering farm, and the financial system within an hour.

The compound risk is the critical finding. Any single gap — missing ASR, missing LAPS, missing Credential Guard, missing custom detections — is a serious issue. But the combination creates a multiplicative effect. Missing ASR means the attacker gets execution. Missing Credential Guard means the attacker gets credentials. Missing LAPS means the credentials work everywhere. Missing custom detections means nobody knows it happened. Each gap removes a barrier that would have forced the attacker to solve an additional problem. With all four gaps open, the attacker's path from initial access to full environment compromise requires no additional tooling, no privilege escalation exploits, and no sophisticated evasion — the default configuration provides the path.

The investigation team arrives to find default audit policies that did not capture the command lines used during the attack, no PowerShell ScriptBlock logs, and no Sysmon events. MDE's DeviceEvents tables contain process creation telemetry for the last 30 days — useful but incomplete without the command-line arguments, script contents, and registry modification details that a properly configured forensic readiness layer would have captured. The IR team can determine that the attacker was present but cannot fully reconstruct what the attacker did, which data was accessed, or whether additional persistence mechanisms exist. This is the operational reality that the CHAIN-ENDPOINT attack at NE exploited — not a theoretical scenario but a documented incident that succeeded because every layer of the stack had the same gap: deployed but not configured.