A build directory sits on the EDR performance exclusion list. What does that exclusion suppress, and how would an adversary use it?

## Why exclusions exist Nobody adds an exclusion for fun. A CI agent unpacking tens of thousands of files gets slower when every write is scanned; a database engine doing synchronous I/O to its data files suffers badly; some application vendors will not support their product unless named directories are exempted. The exclusion list is therefore a negotiated performance artefact, usually owned by a platform or application team, usually created under a performance ticket, and usually never revisited. ## The three shapes and what each really does **Path exclusions** exempt a directory tree, often with a wildcard. **File-extension exclusions** exempt every file of a type, wherever it is, which is the widest and worst. **Process exclusions** exempt activity attributed to a named binary. The distinction that matters in an interview is *scanning versus collection versus detection*. Products differ: - Some exclusions only stop on-access file scanning; behavioural telemetry (process creation, command lines, network connections) still flows and behavioural detections still fire. - Some also stop behavioural detection for the excluded path or process. - Some stop collection entirely, in which case the excluded directory is a hole in your event stream, not merely in your scanning. If you cannot say which of the three your product does, you cannot say what your exclusion cost you. The answer is a test, not a document: execute a known-benign but detectable behaviour inside the excluded path and see which of telemetry, detection and block still appear. ## How an adversary uses one The cheap route requires no privilege against the security product at all. Build workspaces, shared scratch directories and application data paths are frequently writable by service accounts or by any developer. Staging tooling there means files land where file scanning is off. If the exclusion also suppresses behavioural detection, execution from that path is quiet too. Discovery is easier than defenders expect. Exclusion paths are discussed in tickets, baked into build scripts and runbooks, visible in configuration management repositories, and in some products and versions readable from the local host's own configuration by an ordinary user. An adversary does not have to guess; they can often read. The second route needs local administrator or SYSTEM: add a new exclusion for the staging directory, then work inside it. That is defence evasion by impairing defences, `T1562.001`, and it is one of the highest-value things to detect, because a new exclusion is a small, rare, high-signal configuration change. ## Reading an exclusion entry A good entry answers four questions: what is excluded, what the exclusion suppresses, who asked for it and why, and when it expires. An entry with a wildcard covering a whole drive, no owner and no expiry is a finding on its own. Reviewing exclusions is one of the few endpoint tasks where reading a configuration file beats reading alerts. ## What survives an exclusion An exclusion is a hole in endpoint scanning, not a cloak. A binary staged in an excluded directory still has to run, and its child processes, its network connections, the authentication it performs and the data it moves may all be recorded elsewhere: identity sign-ins, proxy and DNS, flow records, the destination host's own telemetry. Even where the excluded path is a collection hole, the chain usually crosses back into instrumented ground. This is the argument to make when someone says an exclusion is fatal: it costs you the earliest and cleanest signal, not the whole case. ## Designing the exclusion so it costs less - Narrow it: name a file, a hash, or a process plus a path, rather than a tree. - Make the excluded directory non-writable by unprivileged and interactive accounts; a CI workspace that only the build service can write is far less useful to an adversary. - Keep telemetry on even where scanning is off, if the product allows the split. - Treat the exclusion list as a reviewed configuration artefact with an owner, a reason, and an expiry date; renew it deliberately. - Detect changes to it, and detect executable writes into excluded paths, so that the exclusion buys performance without buying silence. The honest summary for an interviewer: an exclusion is a deliberate blind spot you granted to somebody for a good reason, and your job is to know exactly how wide it is, who can write into it, and what would still be visible if it were used against you.