Wazuh: a file hash on an alert is not a verdict

The hash identifies bytes

When file integrity monitoring records a hash, that field is a digest of the file the agent read. It lets you see whether a later alert for the same path has the same digest. It does not say who changed the file, and it does not say the bytes are good or bad.

The algorithm matters. An md5 and a sha256 of the same file are different strings. Write the field name so the algorithm is clear. Do not compare a value from one field with a value from the other.

The path and the time belong with the hash

A digest without the path is an orphan. A digest without the alert time can be matched to the wrong change. Write path, time, agent id, and the hash together. If a second alert has a different hash for the same path, that is a later content change, not a reputation score.

Do not paste the file into a ticket. The hash is the identifier. The bytes stay on the host you administer.

What to file

File the algorithm field, the digest, the path, the alert time, and the agent id. If you did not compare it with an earlier digest, say “not compared.” Do not write a verdict word that the alert did not contain.

Worked case: a new hash called a bad file

An alert for agent 014 at 18:05Z shows sha256 of /etc/ssh/sshd_config after a lab edit. A draft says the hash means the file is unwanted and should be deleted. The change ticket for that hour already describes the edit.

The note quotes the algorithm, the digest, the path, the time, and agent 014. It says the digest was not compared with a ban list, and the alert does not contain a verdict. The change ticket explains the edit. The file is not deleted because a hash field was present.

agent.id: 014  time: 2026-11-03T18:05:00Z
path: /etc/ssh/sshd_config
field: sha256  digest: <value on the alert>
compared with an earlier digest: not in this note
verdict on the alert: none
not: delete the file because a hash exists