How does EDR use machine learning and where can it be fooled?

Endpoint detection and response (EDR) tools use machine learning to score files and to spot unusual behavior on endpoints, such as a document opening a command shell. It extends detection beyond known signatures. It also has blind spots, including attacks crafted to look normal, so use it alongside logging and response practice.

Where does ML sit inside an EDR?

An EDR agent records events on a host: processes started, files written, network connections, registry and configuration changes. That stream goes to local logic and a backend. Machine learning is applied in a few places.

File classification. A model looks at features of an executable, such as structure and imports, and gives a maliciousness score. This catches new variants of known families without an exact signature.

Behavior detection. Models, or rules tuned by data, watch sequences of events. A browser starting a script interpreter that fetches a file and writes to a startup folder is a pattern worth a score.

Anomaly detection. The system learns what is typical for a user, host or service and flags departures, such as an accounting laptop suddenly running a remote administration tool.

Triage. Grouping related alerts into one incident and ranking them so analysts see the likeliest threats first.

MITRE ATT&CK offers a shared vocabulary for the behaviors detected, which makes it possible to ask which techniques your tool actually covers.

Where does it fail?

Learning systems have known weaknesses. NIST's taxonomy of adversarial machine learning describes evasion attacks, where an adversary changes inputs so a model misclassifies them, and poisoning attacks on training data. For an EDR, that translates into practical problems:

• Living off the land. Attackers who use built in tools such as administrative utilities produce activity that is hard to distinguish from normal work.
• Slow and low. Behavior spread over days may never cross a threshold.
• Training data bias. A model trained mostly on one kind of environment may misjudge another.
• False positives. Developers and administrators legitimately do things that look malicious. Too many bad alerts lead to disabled rules.
• Tampering. An attacker with administrator rights may try to stop the agent. Tamper protection matters.

A constructed example

An analyst sees a medium score alert: a finance workstation ran a signed system utility to download a file. Alone it is ambiguous. Linked events show the utility was launched by a macro enabled document received that morning, followed by a new scheduled task. With that sequence, the incident view justifies isolating the host. The model contributed a score and grouping. The decision came from context.

What questions should you ask a provider?

Ask how models are updated and how often, what data they were trained on, how false positives are measured and whether you can see why an alert fired. A product that explains its detections lets analysts judge them. One that only shows a score makes every alert a leap of faith.

Ask too how the agent behaves when it loses contact with the backend, since attackers often cut that link first.

How to check or apply this

1. Ask which detections use ML and which use rules, and what each covers in ATT&CK terms.
2. Test with benign simulations of common techniques in a lab, and record what fires.
3. Review false positives monthly and document tuning changes.
4. Turn on tamper protection and alert on agent health gaps.
5. Combine EDR with identity and cloud logging, since much activity never touches an endpoint.
6. Keep a response runbook for the top five alert types.
7. Check agent coverage against your asset inventory so no host is silent.

Quick check

Sources

• MITRE ATT&CK
• NIST AI 100-2 E2025, Adversarial Machine Learning taxonomy
• NIST SP 800-61 Rev. 3, Incident Response

Last reviewed: 18 October 2026.