Detect the behaviour, not the tool name
A rule matching a filename or hash catches yesterday's tooling. A rule matching what the tool has to do catches the next one as well.
There are two ways to write a detection, and they age very differently.
You can match what the tool is: a filename, a hash, a service name, a string inside the binary. This is fast to write and precise, and it stops working the moment somebody renames a file. Recompiling defeats a hash. Both changes cost the attacker minutes.
Or you can match what the tool has to do to work at all. Reading memory from a particular process. Creating a service that runs a command interpreter. Copying a file to a share and starting it remotely. Those behaviours are harder to change, because changing them means finding a different way to achieve the objective.
Cheap and brittle at one end. Expensive and durable at the other.
Both belong in a programme, and the mistake is not knowing which one you bought. A library of hash and filename rules can look like broad coverage on a slide while being one rename away from silence across the board.
Pick your three most important detections and read their conditions. If they name a file, a hash or a tool, ask what the same technique looks like when the actor uses something you have never heard of. If you have no answer, that technique is uncovered and the rules are telling you otherwise.
CHECK YOURSELF
You have rules matching a well-known credential dumping tool by filename and by hash. An actor renames the binary and recompiles it. What happens?
SHOW THE ANSWER
Both stop matching, and nothing tells you they stopped
Why. Recompiling changes the hash. Renaming changes the filename. Neither rule errors when its condition stops being met, so both go quiet without any signal. The fourth answer is the one worth examining, because it might be true, and it describes a different detection from the ones you wrote. Whether your endpoint tooling catches the behaviour is a question to test rather than an assumption to hold.