An endpoint agent on a device does not prove your team will notice an attack in time. Within an agreed scope, I test the full path: device health, event collection, alerting, investigation, and response. You get evidence of what worked, what did not, and what to fix and retest.
What we actually validate
EDR and antivirus are parts of a wider defense. For each scenario, we distinguish prevention, event collection, alerting, and response. This matters: a blocked action is not automatically an unseen action, and a recorded event is not necessarily an investigated incident.
Before testing, we confirm device onboarding, sensor version, effective policy, relevant exclusions, and the telemetry path. We then use approved harmless tests with synthetic data. More demanding scenarios depend on your objectives and written boundaries.
From event to analyst decision
For each test, we independently record the time, device, expected outcome, and test ID. We then check whether the event reached the data source, whether an alert was created, when it arrived, and who handled it. No alert alone does not explain why: the cause may be policy, a detection rule, missing telemetry, or delay.
For activity involving legitimate tools, we inspect context: parent process, user, device, and related events. A process name alone does not establish misuse. Comparing the sequence with expected business activity helps reduce noise and improve the detection rule.
Technical evidence you can repeat
Where Microsoft Defender XDR is in use, validation can include queries against DeviceInfo for sensor health and DeviceProcessEvents for process events. For other vendors, we inspect equivalent console records and exports. Fields, availability, and retention depend on the deployed service and configuration.
We provide event links or redacted exports, time zones, test IDs, effective settings, and limits on what the evidence proves. If a result is missing, we check sensor health and query scope before treating an empty search as evidence of no activity.
How the engagement works
- Agree the objective and boundaries. Select devices, scenarios, owners, safety limits, and success criteria.
- Establish the baseline. Check onboarding, sensor health, policies, and event availability.
- Run controlled tests. Execute approved steps and record time, expected behavior, and observed result.
- Review together. Compare telemetry, alerts, analyst actions, and any gaps with your team.
- Fix and retest. Prioritize changes by impact and repeat the agreed scenarios.
Validation can stand alone or form part of a wider red team engagement. Vid Grosek delivers engagements through Telprom d.o.o. in Ljubljana.
Frequently asked questions
Does no alert mean the EDR failed?
Not necessarily. An event may be recorded without an alert, blocked by another control, or missing because the device was not properly onboarded. Review the event, policy, sensor health, and analyst response.
Does the test require real malware?
No. Initial validation can use agreed harmless tests and synthetic data. More demanding scenarios require separate approval, boundaries, and a recovery plan.
What do I receive after the test?
You receive a scenario inventory, timestamped evidence, an explanation of gaps, prioritized fixes, and retest results when included in scope.
Find out what your EDR actually sees
Tell me about your environment and objective. I’ll propose a bounded first test with clear success criteria.
Technical references: Microsoft DeviceInfo, Microsoft DeviceProcessEvents, Microsoft tamper resiliency, MITRE ATT&CK adversary emulation.