Why bypassing EDR is often not the goal

Endpoint detection and response tools are effective at catching malicious process execution on managed devices. An attacker who tries to run a known payload or execute a scripting-based attack on a monitored endpoint has a reasonable chance of triggering a detection. This is precisely why experienced attackers often avoid the endpoint layer entirely when the environment offers alternatives.

Microsoft 365 environments present multiple entry points that sit outside endpoint monitoring by design. Credential-based access to Entra ID, Exchange Online and SharePoint requires no execution on a managed device. The attacker uses the platform as intended, through its own APIs and authentication stack, which makes the traffic indistinguishable from legitimate use at the network level.

The result is that endpoint-based detection, however well tuned, leaves entire categories of attack path unmonitored. The three patterns below are among the most consistent in practice.

Account takeover through valid credentials

Credential stuffing and password spray attacks use automation to test large volumes of credentials against Microsoft 365 authentication endpoints. The credentials come from breach databases where prior data exposures have exposed email and password combinations. The attacker does not need to exploit a vulnerability. The authentication succeeds because the password is correct.

Once authenticated, the attacker operates as a legitimate user. Account takeover of this type generates an Entra ID sign-in event. The sign-in location, the device used and the user agent string may all be anomalous. The time of access may be inconsistent with the user's normal pattern. But none of these are endpoint events. They are identity events, and detecting them requires monitoring Entra ID telemetry, not endpoint processes.

Once access is established, the attacker typically moves quickly. New MFA device registration locks in persistent access. Security alert emails are deleted via inbox rules before the account holder sees them. Email is forwarded externally for ongoing surveillance. All of these actions occur inside Microsoft 365 application layers. The user's managed laptop may be sitting idle while this happens.

Mailbox rule manipulation

Creating or modifying inbox rules in Exchange Online is an application-layer event. The attacker authenticates to Exchange Online, creates a rule that forwards all incoming email to an external address, and optionally creates a second rule that deletes any security notification emails before they reach the inbox. Both operations are Exchange Online API calls. They produce Exchange audit log entries. They produce no process execution event on any endpoint.

The persistence value of this technique is high. Even if the account password is subsequently changed, the forwarding rule continues to operate unless it is explicitly reviewed and removed. The attacker receives ongoing email traffic from the account indefinitely. A security review that covers only endpoint telemetry will not find the rule. Detecting it requires auditing Exchange Online mailbox rules directly, either through continuous monitoring or through a regular review of mailbox configurations across all managed tenants.

The same principle applies to calendar sharing, Teams webhook creation and SharePoint external sharing links. Each is an application-layer persistence mechanism. Each is invisible to endpoint agents.

Lateral movement from endpoint to cloud

Not all attacks bypass the endpoint entirely. A common attack sequence begins with a phishing email that executes malware on a managed device: the endpoint agent fires, the process is detected, the device is isolated. What this response does not address is what happened before the alert fired.

In the time between initial execution and detection, the malware on the endpoint typically performs credential harvesting. Browser credential stores, Windows credential manager and cached Kerberos tokens are all accessible to code running at user privilege. Those credentials are exfiltrated to attacker infrastructure before the endpoint is isolated. The attacker now has valid credentials for Microsoft 365 services and proceeds to use them from a separate machine entirely outside the monitored environment.

Lateral movement across the network from a compromised endpoint to cloud identity is a transition point where endpoint visibility ends and cloud identity visibility needs to begin. Detecting the second stage of this sequence requires Entra ID monitoring that can correlate the endpoint compromise event with subsequent anomalous sign-in activity from the same user account.

Living-off-the-land techniques on the endpoint itself

Some attacks operate on the endpoint but use only tools that are already present on the device. PowerShell, WMI, certutil and other native Windows utilities are used to execute attacker objectives without dropping any new executable. This reduces the effectiveness of signature-based detection significantly.

Living-off-the-land techniques do generate behavioral signals that well-tuned EDR platforms can detect: unusual PowerShell execution chains, WMI subscriptions that did not exist before, outbound connections from processes that do not normally make them. The detection quality depends heavily on whether the EDR rules are tuned to the specific environment rather than against generic threat data.

The implication is that even for attacks that do execute on the endpoint, detection quality is not uniform across all EDR deployments. Rule tuning against the client's specific baseline, not just default platform settings, determines how much of this category is caught.

What detection across these patterns requires

Detecting account takeover requires Entra ID sign-in monitoring with behavioral baseline deviation detection. Detecting mailbox rule manipulation requires Exchange Online audit log ingestion and alerting on new external forwarding rules. Detecting the cloud phase of a lateral movement sequence requires correlation between endpoint compromise events and subsequent identity events across the same user account.

Each of these is a separate telemetry source operating at a different layer from the endpoint agent. Coverage across the full stack requires a detection platform that ingests from all of them and applies correlation logic that spans the identity, application and cloud layers alongside the endpoint layer.

The lateral movement attack pattern illustrates the requirement clearly: the full sequence spans an endpoint event, a credential exfiltration event and then a series of identity and cloud events. Detecting only the endpoint portion catches stage one. Detecting the full sequence requires visibility across every layer the attacker moves through.