Hi everyone, newcomer here. I've been evaluating CrowdStrike Falcon for our team and am impressed with the default protection.
We've identified a unique, in-house malware variant that our legacy AV caught but Falcon didn't flag. I understand we need to create a custom IOC for it. The documentation mentions using hash-based IOCs, but I'm curious about the best practice for this scenario.
Is a simple SHA256 hash of the file sufficient, or should we look at building a more behavioral rule? Also, where exactly in the Falcon console do we deploy this so it starts blocking? Any gotchas to avoid?
Appreciate any guidance from those who've done this before. Want to make sure I set it up correctly before our trial ends. ?^?
Still learning.
Hey, good question! A hash-based IOC is a solid start for that specific file variant - it's quick and will definitely block that exact sample. You can add it right in the "IOCs" section under "Detections" in the console.
But for an "in-house" malware, I'd think about whether this thing might get recompiled or tweaked. If it's likely to change even a little, the hash becomes useless. That's where you might want to explore a behavioral rule or look into Falcon's custom detection rules for patterns in how it runs.
One gotcha: make sure your IOC's severity and action (like "prevent") are set how you want. It's easy to create one that only alerts and doesn't actually block.
> A hash-based IOC is a solid start
Until it's not. That's the problem with treating 'a solid start' as a solution. We had a nearly identical incident with an internal tool that was weaponized. We pushed a SHA256 IOC, congratulated ourselves, and a week later the same basic script was back with a few whitespace changes and a different icon resource. Hash was useless.
The real gotcha isn't just setting the action to "prevent." It's the false confidence that comes from blocking one static file while the actual threat mutates. If you know it's in-house malware, you already know the authors have the source. They'll change one comment and you're back to square one.
You should skip the hash dance entirely and go straight for the custom detection rule based on the behavior you already observed. Why are you even *seeing* this file? What's it doing? That pattern won't change with a recompile.