How a Single Behavioral Indicator in SentinelOne Uncovered a Full Infostealer Attack
- 1 hour ago
- 2 min read
Okay, I know — another SentinelOne article. But hear me out. What I'm about to show you changed how you think about detection engineering, and I genuinely can't stop thinking about it.
If you've been following this series, you already know I covered the Detection Center in the last article.
Go check that one out if you haven't — link at the top.
But today?
We're going somewhere slightly different. We're talking about Indicators — and specifically, why they might be one of the most underrated features SentinelOne quietly ships with every agent deployment
-----------------------------------------------------------------------------------------------------------
Let's Start With What You Already Know
If you've spent any time with SentinelOne, you know about Deep Visibility. That's the data lake where S1 stores everything the agent captures — every process creation, network connection, file event — retained for as long as your subscription allows. It's basically a time machine for your endpoints.
You also know S1 has detection engines running under the hood. We touched on those into my SentinelOne series. But here's the thing I want to highlight today: those engines aren't just detecting threats — they're also tagging events with metadata. Specifically, they're attaching what SentinelOne calls Behavioral Indicators.
-----------------------------------------------------------------------------------------------------------
So What? Why Should I Care?
Here's the thing most people miss: you don't need a hash, a domain, or an IP address to write a detection rule. You can write a STAR Custom Rule using just an indicator name.
I know what you're thinking — "that's going to fire everywhere, false positives galore." And yes, you'll need to tune it. But let me show you how powerful this actually is with a real-world example.
That single line. That's it. No hashes, no IPs, no paths. Just an indicator name that SentinelOne's engine already stamps on suspicious events in Deep Visibility.
-----------------------------------------------------------------------------------------------------------
How This Actually Caught an Infostealer
This is where it gets real. A massive thank you to my friend Jeremy Jethro. He's the reason I'm writing this article.
An alert triggered. On the surface it looked completely unremarkable — Visual Studio activity, something most analysts would glance at and close as a false positive. But the alert was triggered based on a behavioral indicator, not a signature.
And Jeremy being Jeremy, he didn't just close it. He dug.
What he found underneath was a full infostealer execution chain. Here's a sanitized summary of what the timeline looked like:
The entire above chain — discovered because of one behavioral indicator that an analyst almost dismissed as a false positive.
-----------------------------------------------------------------------------------------------------------
The Real Lesson Here
SentinelOne — like every EDR — will miss detections sometimes. That's just reality. But here's the thing people get wrong: a missed detection doesn't mean missed data. Deep Visibility is capturing everything, every second, and the agent is silently tagging behavioral activity the whole time.
Your job as a detection engineer or threat hunter isn't to wait for an alert to fire. It's to build rules that surface what the engines are already seeing. Behavioral indicator-based STAR rules are exactly how you do that.
One note: there is a delay in STAR Custom Rule detection. I've written a full breakdown of that elsewhere but the delay doesn't mean you ignore it. It means you account for it.
-----------------------------------------------------------------------------------------------------------
