# Elastic Endpoint (Defend) does not seem to report file hashes for writes or modifications

**URL:** <https://discuss.elastic.co/t/elastic-endpoint-defend-does-not-seem-to-report-file-hashes-for-writes-or-modifications/365785>\
**Category:** Endpoint Security\
**Tags:** elastic-stack-security\
**Created:** [August 29, 2024, 4:20pm UTC](https://discuss.elastic.co/t/elastic-endpoint-defend-does-not-seem-to-report-file-hashes-for-writes-or-modifications/365785 "2024-08-29T16:20:32Z")\
**Posts on this page:** 9\
**Page:** 1

<div class="post-metadata">

**Author:** ![nemhods](https://avatars.discourse-cdn.com/v4/letter/n/48db29/32.png) [@nemhods](https://discuss.elastic.co/u/nemhods)\
**Post date:** [August 29, 2024, 4:20pm UTC](https://discuss.elastic.co/t/elastic-endpoint-defend-does-not-seem-to-report-file-hashes-for-writes-or-modifications/365785/1 "2024-08-29T16:20:33Z")

</div>

Hey all,

this is similar to: [Endpoint events dont contain process or file hash](https://discuss.elastic.co/t/endpoint-events-dont-contain-process-or-file-hash/324583)

When I look at fields in the `endpoint*` datasets, the fields `file.hash.*` are not populated. I see `process.hash.*` on events in the dataset `endpoint.events.process`, but no file hashes for file write / modify events.

This is a super common feature of any EDR that I know, so I was wondering if this could be a misconfiguration or bug, or if Elastic Endpoint simply can't report file hashes of files that were interacted with on the endpoint.

I don't know how to export my endpoint policy via API, but here are some details.

- Elastic Agent Version: 8.14.1
- Protected Endpoint OS: Windows Server 2019, Windows 10, Ubuntu Linux
- Elastic Defend Integration Version: 8.15.2-prerelease.0
- All Collectors enabled in Endpoint Policy, except "Collect Session Data" for Linux
- no trusted applications or event filters configured
- Advanced Settings mostly on default, except:
- `linux.advanced.events.enable_caps` = true
- ancestry depth set to 20
- `advanced.events.deduplicate_network_events` = false  
(I don't know why these are set, I have not manually changed anything within the policies).

---

<div class="post-metadata">

**Author:** ![gabriel.landau](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/gabriel.landau/32/73401_2.png) [@gabriel.landau](https://discuss.elastic.co/u/gabriel.landau)\
**Post date:** [August 29, 2024, 4:41pm UTC](https://discuss.elastic.co/t/elastic-endpoint-defend-does-not-seem-to-report-file-hashes-for-writes-or-modifications/365785/2 "2024-08-29T16:41:11Z")

</div>

Hey @nemhods,

For performance reasons, Endpoint does not populate hashes for file events. Hash computation is a very I/O- and CPU- intensive action. Reading and hashing every every file modified on the system can significantly impact system responsiveness. This becomes especially noticeable when the system is performing heavy I/O, which is usually correlated with file event generation.

Malware alerts (`event.code: malicious_file`) contain hashes.

Regards,  
Gabriel

---

<div class="post-metadata">

**Author:** ![nemhods](https://avatars.discourse-cdn.com/v4/letter/n/48db29/32.png) [@nemhods](https://discuss.elastic.co/u/nemhods)\
**Post date:** [August 29, 2024, 5:06pm UTC](https://discuss.elastic.co/t/elastic-endpoint-defend-does-not-seem-to-report-file-hashes-for-writes-or-modifications/365785/3 "2024-08-29T17:06:27Z")

</div>

Hey Gabriel,

I appreciate it. Has there been any discussion to make this user-configurable?

It would really help with alerts like [Potential Lateral Tool Transfer via SMB Share | Elastic Security Solution [8.14] | Elastic](https://www.elastic.co/guide/en/security/8.14/potential-lateral-tool-transfer-via-smb-share.html) - a file has been dropped via the network, but I can't check this file in VirusTotal or other Threat Intel (neither with elastic's integrated TI features).

---

<div class="post-metadata">

**Author:** ![gabriel.landau](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/gabriel.landau/32/73401_2.png) [@gabriel.landau](https://discuss.elastic.co/u/gabriel.landau)\
**Post date:** [August 29, 2024, 5:19pm UTC](https://discuss.elastic.co/t/elastic-endpoint-defend-does-not-seem-to-report-file-hashes-for-writes-or-modifications/365785/4 "2024-08-29T17:19:25Z")

</div>

> [@nemhods](#):
>
> a file has been dropped via the network, but I can't check this file in VirusTotal or other Threat Intel

Would grabbing the file help? [Endpoint response actions | Elastic Security Solution [8.15] | Elastic](https://www.elastic.co/guide/en/security/current/response-actions.html#get-file)

You can automate it via the API too: [Get a file from a host | Elastic Security Solution [8.15] | Elastic](https://www.elastic.co/guide/en/security/current/get-file-api.html)

---

<div class="post-metadata">

**Author:** ![nemhods](https://avatars.discourse-cdn.com/v4/letter/n/48db29/32.png) [@nemhods](https://discuss.elastic.co/u/nemhods)\
**Post date:** [August 29, 2024, 6:23pm UTC](https://discuss.elastic.co/t/elastic-endpoint-defend-does-not-seem-to-report-file-hashes-for-writes-or-modifications/365785/5 "2024-08-29T18:23:00Z")

</div>

Hey,

it's a good suggestion, but I wouldn't say that's an adequate workaround...

- needs enterprise license
- files are often ephemeral in a way, and may be gone or moved when the analyst tries to grab the file

I would love to be able to trade some performance for additional visibility. an advanced config option would be great!

---

<div class="post-metadata">

**Author:** ![gabriel.landau](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/gabriel.landau/32/73401_2.png) [@gabriel.landau](https://discuss.elastic.co/u/gabriel.landau)\
**Post date:** [August 29, 2024, 8:22pm UTC](https://discuss.elastic.co/t/elastic-endpoint-defend-does-not-seem-to-report-file-hashes-for-writes-or-modifications/365785/6 "2024-08-29T20:22:33Z")

</div>

> [@nemhods](#):
>
> I would love to be able to trade some performance for additional visibility. an advanced config option would be great!

Sure thing. I filed a [feature request](https://github.com/elastic/endpoint/issues/78) in our public Endpoint repo. Please feel free to comment on it. I can't guarantee that our engineering/product teams will prioritize it, but at least you can follow the issue to track progress.

Regards,  
Gabriel

---

<div class="post-metadata">

**Author:** ![nemhods](https://avatars.discourse-cdn.com/v4/letter/n/48db29/32.png) [@nemhods](https://discuss.elastic.co/u/nemhods)\
**Post date:** [August 31, 2024, 4:09pm UTC](https://discuss.elastic.co/t/elastic-endpoint-defend-does-not-seem-to-report-file-hashes-for-writes-or-modifications/365785/7 "2024-08-31T16:09:03Z")

</div>

Hey Gabriel,

thanks for going ahead and adding the request.

Although I am wondering - if Elastic Agent doesn't ever compute the hashes of files, how can it enforce Blocklist entries? Do these only apply to _executed_ files? This would mean that I couldn't effectively block the hash of a malicious .js-File, since the _executed_ file in this case would be wscript.exe, not the .js-File.

Do you maybe have some insight why other solutions routinely have file hashes available? Do they use an entirely different architecture, or do they just accept the performance impact without giving the customer a choice about it?

Here's Microsoft's Defender data schema for File Events: [DeviceFileEvents table in the advanced hunting schema - Microsoft Defender XDR | Microsoft Learn](https://learn.microsoft.com/en-us/defender-xdr/advanced-hunting-devicefileevents-table)

---

<div class="post-metadata">

**Author:** ![gabriel.landau](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/gabriel.landau/32/73401_2.png) [@gabriel.landau](https://discuss.elastic.co/u/gabriel.landau)\
**Post date:** [September 3, 2024, 2:05pm UTC](https://discuss.elastic.co/t/elastic-endpoint-defend-does-not-seem-to-report-file-hashes-for-writes-or-modifications/365785/8 "2024-09-03T14:05:32Z")

</div>

> [@nemhods](#):
>
> Do these only apply to _executed_ files?

That's correct. The blocklist is an extension of malware protection, which protects against malicious executables. On Windows, this means PE files.  
Per our [policy docs](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html#malware-protection):

> The blocklist allows you to prevent specified applications from running on hosts, extending the list of processes that Elastic Defend considers malicious.

The feature is actually a bit broader than that. Malware protection also protects against other PE files such as DLLs and driver (SYS) files.

> [@nemhods](#):
>
> Here's Microsoft's Defender data schema for File Events

Thank you. We'll take that into account when discussing this feature. It's important to understand that regardless of whether MDE spends CPU and I/O to hash files, adding them to Endpoint will dramatically increase its CPU and I/O usage in common heavy-system-load scenarios such as directory copies and compilation. Every file created must be re-read into memory then hashed, effectively doubling I/O and spiking CPU right when the system needs those resources. That means the user's foreground activity can be adversely affected, leading to upset [and potentially lost] customers. Making the feature opt-in can avoid these problems for most users, while providing the functionality for users who want it, which is why I'm requesting that approach.

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\
**Post date:** [October 1, 2024, 2:06pm UTC](https://discuss.elastic.co/t/elastic-endpoint-defend-does-not-seem-to-report-file-hashes-for-writes-or-modifications/365785/9 "2024-10-01T14:06:32Z")

</div>

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.
