A public-health clinic EDR stores file hashes in uppercase, but the county ISAC intel lookup table is lowercase, so known malware hashes return no matches. What should the analyst do before the lookup?
Select an answer to reveal the explanation.
Short Explanation
Lookups are as picky as a clinic chart rack that only finds a folder if the spelling matches. If EDR writes DEADBEEF and the ISAC list has deadbeef, eval lower() — plus a type cast when the fields disagree — makes the keys shake hands before lookup runs.
Full Explanation
Splunk lookups match on exact field values, including case and data type, so a public-health clinic EDR hash stored as uppercase will miss a lowercase county ISAC indicator even when the bytes are identical. The correct fix is to normalize the join key with eval immediately before lookup—commonly lower() on the hash, and tostring() or tonumber() when one side is a string and the other is numeric—so the clinic telemetry and the intel table share a comparable key. That preserves the live EDR events while making the lookup behave like Asset and Identity enrichment: same key format, then attach match fields. Switching the hunt to tstats does not make hash matching case-insensitive; accelerated models still compare the stored values as they are. Extracting a second hash with rex without converting case or type leaves the mismatch intact and adds noise. Replacing the search with makeresults invents synthetic rows instead of normalizing the clinic events that actually need intel matching. Exam caveat: normalization belongs on the search-time join key (or in a consistent ingest pipeline), not as a claim that CIM or tstats silently case-folds hashes. Operational check: take one known uppercase clinic hash that exists lowercase in the ISAC table, run eval lower() (and any needed type cast), pipe to lookup, and confirm the match field populates before promoting the pattern into a correlation search.