The NE Endpoint Landscape

Introduction

Northgate Engineering is the estate this course works on, and this section is its honest starting position. You will finish able to describe the difference between a product being deployed and being engineered, name the four gaps the rest of the course closes, and follow one attack path end to end through an estate that is fully licensed and largely unprotected. That combination is not unusual and it is the reason this course exists.

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.

Deployed and engineered are different states and the gap between them is where most estates live. NE has bought everything, installed everything, and configured almost nothing beyond the setup wizard, which produces a compliance report that is entirely accurate and a security posture that is roughly generation one. Nobody in that story did anything wrong; deploying a product is a project with an end date and engineering it is not, and only one of the two gets funded that way.

  REPORTED                        ACTUAL
  MDE deployed, 847 of 865        onboarded, all settings default
  ASR rules configured            all 18 in audit, none blocking
  Defender AV on all endpoints    cloud protection at Default,
                                  block at first sight off
  Compliance policies applied     device compliance not used by
                                  any Conditional Access policy
  Custom detections in place      7 rules, none matching the
                                  techniques in section 3

Every line on the left is true, defensible and would pass an audit. Every line on the right is the same fact read from the device rather than from the console, and the two columns are what the phrase "deployed but not engineered" means in practice.

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. SEC409 Endpoint Security Operations 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.

  HARDENING       met FIRST, at execution. ASR in audit, no
                  Credential Guard, no application control.
                  the attacker never encounters a block.
  DETECTION       met SECOND, and not by the attacker at all.
                  seven custom rules, none covering the
                  techniques above. nothing fires.
  FORENSICS       met LAST, by you. 30-day retention against
                  a dwell time nobody has measured.
  SERVERS         met SIDEWAYS. onboarded, unhardened, and
                  holding the data the attack is aimed at.

THE ORDER MATTERS MORE THAN THE LIST. Hardening is where the
attack could have been stopped, detection is where it could have
been seen, and forensics is what is left when neither happened.

Ordering them that way changes what to do first. The instinct is to close the gap that is easiest to explain, which is usually detection, because a count of rules is a number somebody can report. The attacker meets hardening first, and every technique hardening stops is one detection never has to find.

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.

Read that path once more and count the number of places it could have been stopped. Five, and each one is a control NE already owns. The compound risk is not that five things are missing, it is that each missing control removes a stopping point from the same chain, so the fourth gap costs far more than the first.

That is the argument for the sequence in the next section, and it is also the argument against prioritizing by product. Fixing the loudest gap does nothing if the attacker never reaches it.

NE is fictional and the shape is not. The exercise is to produce the same three paragraphs about the estate you actually run, which most people have never written down in one place.

Keep it to one page and date it. Repeating the exercise at the end of the course is the clearest measure of whether any of it landed, and a page you can hold beside an earlier version is worth more than a maturity score that moved.