After some major confusion, it seems that the Sysmon pipeline is including event ID 26 for processing hashes as process hashes when these seem to be file hashes of what files have been deleted.
For testing, I have removed Event ID 26 from the condition on this processor:

Like so:
ctx?._temp?.hashes != null &&
["1", "23", "24", "25"].contains(ctx.event.code)
And then added it to the filehash processor.
Like so:
ctx?._temp?.hashes != null &&
["6", "7", "15", "26", "29"].contains(ctx.event.code)
And this seems to correct the issue. I can try and get a PR started out there on this, but not sure if I will have to the time to fully satisify the change. This would be a breaking change as it will change the process.hash* fields to file.hash* fields.
If anyone else has found that process hash is actually included I would be interested to see that finding.
Running Latest Sysmon 15.12 and I believe this is the case for Sysmon 14+.
After some major confusion, it seems that the Sysmon pipeline is including event ID 26 for processing hashes as process hashes when these seem to be file hashes of what files have been deleted.
For testing, I have removed Event ID 26 from the condition on this processor:

Like so:
And then added it to the filehash processor.
Like so:
And this seems to correct the issue. I can try and get a PR started out there on this, but not sure if I will have to the time to fully satisify the change. This would be a breaking change as it will change the process.hash* fields to file.hash* fields.
If anyone else has found that process hash is actually included I would be interested to see that finding.
Running Latest Sysmon 15.12 and I believe this is the case for Sysmon 14+.