EDR platforms - live response & telemetry #
On most engagements the EDR console is your fastest collection and containment channel. The tables below cover the live-response and hunting surface of the major platforms, so you can work in whichever one the client runs. Treat the console itself as a tier-0 asset. If an attacker controls it, they can uninstall sensors, push scripts and blind you.
Working with any EDR during an incident
- Coverage first. Pull the sensor inventory and compare it to the asset list (AD computers, cloud instances, hypervisors). Unmanaged hosts are where attackers operate. Deploy sensors to gaps during the engagement and record when each one went live, because nothing before that point was seen.
- Retention. Raw telemetry is often kept only 7-30 days, depending on the license. Export the incident window to durable storage on day one.
- Network containment (host isolation) keeps the management channel open, so you can still run live response on an isolated host. Prefer it to pulling cables or powering off.
- Responder audit trail. Every live-response command is logged (who, host, command, time). Export it with your evidence; it supports chain of custody.
- Tamper protection and console access. Confirm uninstall protection is on, rotate console admin credentials, enforce phishing-resistant MFA on the console, and review recent console audit logs for attacker activity.
- Update rings. Kernel-level agents can take hosts down if a bad sensor or content update ships (the July 2024 Falcon Channel File 291 outage is the reference case). Mature fleets stage sensor and content updates through test, early and broad rings.
Live response - vendor cheat sheet
| Platform | Live response | Hunting / query | Notes |
|---|---|---|---|
| CrowdStrike Falcon | Real Time Response (RTR): ls, cat, reg query, ps, netstat, kill, memdump, eventlog, get/put, runscript; custom scripts in the Response Library | Falcon LogScale / Next-Gen SIEM with CQL | Falcon Forensics Collector (FFC) for mass triage packs; Falcon Fusion for SOAR workflows |
| Microsoft Defender for Endpoint | Live Response: run scripts from the library, getfile, putfile, processes, registry; one-click Collect investigation package | Advanced Hunting (KQL) across Device* tables, about 30 days online | Isolation modes (full / selective); often bundled with E5, so many clients already have it |
| SentinelOne Singularity | Remote Shell and RemoteOps (scripts and collection at fleet scale) | Deep Visibility / Singularity Data Lake (PowerQuery) | Storyline IDs group a process tree; built-in rollback on Windows (VSS-based) |
| VMware / Broadcom Carbon Black | Live Response shell: file get/put, process kill, memory dump | Process search / Enterprise EDR query syntax | Common in older on-premises deployments |
| Velociraptor (open source) | Server-driven collections; offline collector binaries for hosts without an agent | VQL artifacts and hunts across the fleet | Deploy it during IR when the client has no EDR, or alongside a weak one |
Deploying triage collectors through live response
- KAPE via Falcon RTR:
runscript -CloudFile='Deploy-KAPE' -CommandLine='--target !SANS_Triage --tsource C: --tdest C:\triage', then pull the zip withget. - Velociraptor offline collector via Falcon RTR: add the collector binary to RTR's "put" files, then
putit to the host,runit, and pull the zip it writes withget. Same KAPE target set (viaWindows.KapeFiles.Targets) plus any VQL artifact you built into it. - MDE: upload
kape.zipplus a wrapper script to the Live Response library,runit, thengetfilethe output. - Any platform: Velociraptor offline collector or UAC (Linux / macOS) pushed and run the same way; hash the output on the host before you pull it.
EDR telemetry - event names by question
| Question | Falcon (LogScale) | Defender for Endpoint (KQL) |
|---|---|---|
| Process tree and command line | ProcessRollup2 (join TargetProcessId ↔ ParentProcessId) | DeviceProcessEvents |
| Network connections / DNS | NetworkConnectIP4, DnsRequest | DeviceNetworkEvents, DeviceEvents (DnsQueryResponse) |
| File writes / deletes | FileWritten, FileDeleted | DeviceFileEvents |
| Logons | UserLogon, UserLogonFailed | DeviceLogonEvents |
| Autostart / registry persistence | AsepValueUpdate | DeviceRegistryEvents |
| Script content (AMSI) | ScriptControlScanTelemetry | DeviceEvents (AmsiScriptContent / PowerShellCommand) |
Example - process tree for a hash in LogScale: #event_simpleName=ProcessRollup2 SHA256HashData="abc…" | join({#event_simpleName=ProcessRollup2}, field=[ParentProcessId_decimal=TargetProcessId_decimal], include=[FileName, CommandLine]). KQL equivalent: DeviceProcessEvents | where SHA256 == "abc…" | project Timestamp, DeviceName, InitiatingProcessFileName, InitiatingProcessCommandLine, FileName, ProcessCommandLine.
Managed services you'll work alongside
- MDR (managed detection & response) - a vendor SOC monitors and responds to the client's alerts around the clock as an ongoing service (e.g., Falcon Complete, Microsoft Defender Experts, Arctic Wolf, Red Canary, Expel). Get their alert history and response actions early; they may have seen the first signal.
- Managed threat hunting - proactive hunting over the vendor's telemetry (e.g., Falcon OverWatch, Defender Experts for Hunting).
- IR retainer / IR services firm - pre-negotiated terms and response SLAs so an IR team can start within hours. Agree in the RoE on how the IR firm and the MDR provider split work, so you don't both contain the same host.