I've been conducting a deep-dive analysis into the built-in forensic artifact collection capabilities of three leading EDR platforms: CrowdStrike Falcon, Microsoft Defender for Endpoint, and SentinelOne. My focus was on the scripts or modules used for proactive or incident-response collection, specifically how they pull files, registry hives, memory, and other key triage data from endpoints. The differences in approach, granularity, and output are quite revealing.
I started by examining the actual commands and scripts these vendors execute when you trigger a live response or forensic collection. Below is a simplified breakdown of what I observed from their documentation and my own lab testing.
**CrowdStrike Falcon RTR (Real-Time Response)**
When using `get` command or a custom script via RTR, the underlying execution is often a PowerShell or batch script pushed via the cloud. A common pattern for collecting a specific artifact, like the NTUSER.DAT hive of a user, would look like this in their script engine:
```powershell
$userProfilePath = Get-ItemProperty -Path 'HKLM:SOFTWAREMicrosoftWindows NTCurrentVersionProfileList' | ForEach-Object { $_.ProfileImagePath }
$hivePath = Join-Path $userProfilePath 'NTUSER.DAT'
Copy-Item -Path $hivePath -Destination "C:CrowdStrikeRtr\"
Compress-Archive -Path "C:CrowdStrikeRtr\*" -DestinationPath "C:CrowdStrike.zip"
```
The key here is that everything is orchestrated through their cloud console, and scripts are executed in a temporary working directory with logs fed back to the audit log. The collection scope is highly configurable per command.
**Microsoft Defender for Endpoint Live Response**
Their live response session uses a more interactive shell, but automated collections via "Collect investigation package" leverage a predefined set of artifacts. The script logic is hidden within the portal action, but by monitoring process creation, you see it calling `MDECollectionTool.exe` with a JSON manifest. An example manifest snippet I've reconstructed:
```json
{
"Artifacts": [
{
"Type": "File",
"Path": "%SystemRoot%\System32\winevt\Logs\Security.evtx",
"Recursive": false
},
{
"Type": "Registry",
"Path": "HKLM\SOFTWARE"
}
]
}
```
The tool collects these items, bundles them into a proprietary `.fa` file, and uploads it to the secure Azure storage for your workspace. The audit trail for this action is found in the "DeviceActions" table under `CollectInvestigationPackage`.
**SentinelOne Deep Visibility & Forensic Data**
SentinelOne takes a different approach. Their "Forensic Data" collection is not a script pushed during an incident, but a configuration set on the policy level to *continuously* collect a broad set of artifacts to the management console. When you export a forensic package, you're simply downloading the already-collected data from their database. However, their "Live Terminal" can run ad-hoc scripts. A typical artifact collection command in their terminal might use their own `s1` utility or raw PowerShell. For example, to pull prefetch files:
```cmd
powershell -Command "Copy-Item -Path 'C:WindowsPrefetch*.pf' -Destination '/tmp/forensics/' -Force"
```
The audit log for any manual live terminal command is meticulously recorded in the Management Activity Log, showing the exact command hash, user, and timestamp.
**Key Observations and Questions for the Community**
* **Granularity vs. Overhead:** CrowdStrike and Microsoft allow for surgical, incident-specific collection, which is great for minimizing endpoint impact and data transfer. SentinelOne's continuous approach means the data is always there, but it requires more upfront storage and bandwidth planning.
* **Audit Trail Completeness:** All three log the *initiation* of a collection to their cloud audit logs. However, the detailed *file-level* audit of what was accessed on the endpoint (e.g., `C:WindowsPrefetchEXPLORER.EXE-123456.pf` read) often relies on the EDR's own sensor telemetry, not the script's internal logs. This is a crucial distinction for compliance controls like SOx or HIPAA, where you need to prove the integrity of the collection process.
* **Customization:** CrowdStrike's RTR scripts are highly customizable. Microsoft's investigation package is largely fixed but reliable. SentinelOne's strength is querying the already-gathered deep visibility data with SQL-like queries, rather than collecting new files post-incident.
I am particularly keen to hear from others who have performed similar analyses or have operational experience at scale. Specifically:
* Have you encountered any limitations with these methods when needing to meet strict chain-of-custody requirements for legal proceedings?
* Are there any notable performance impacts on high-I/O servers when using the continuous forensic collection model?
* How do you verify the integrity and completeness of the collected artifact bundles? Do you generate hashes for the collected files independently of the vendor's tool?
Logs don't lie.