A Curious Case with SentinelOne: Same Rule, Different Behavior?
- Apr 8
- 4 min read
#### April, 2025, if this get resolved in future will update the same####
Hey folks!
First off, a big thanks to everyone who’s been following my SentinelOne series.
🙌 If you haven't already, you can check out the full series below (yep, shameless plug, but it's worth it I promise 😅).
Now, let me share something interesting — or maybe a little odd — that I came across while working with SentinelOne recently.
It all started when a dearest friend of mine, Cesar Cobena, pinged me with a small issue. Little did we know, this would turn into a whole discovery.
-----------------------------------------------------------------------------------------------------------
🧐 The Issue: File Not Blocked?
Cesar told me that SentinelOne wasn’t blocking a file — in this case, a simple Mouse Mover executable.
Now, if you’ve used SentinelOne before, you probably know this: it doesn't allow file name–based blocking. It focuses on hash-based blocking, and in the newer versions, it even supports SHA-256 based blocking. That’s a good sign, showing how the platform is evolving.
But still, that got me thinking.
-----------------------------------------------------------------------------------------------------------
🧪 Testing Time: Let’s Try RDP Tools
So, I jumped into testing mode — like any good cyber nerd would.I picked two popular RDP tools: AnyDesk and TeamViewer.
Now remember, if you block their hashes, they won’t run — fair.
But what if you want to block them using file names? SentinelOne doesn’t support that directly, but here’s the workaround:
You can use STAR custom rules to create detections based on certain conditions, including file names.
So that’s exactly what I did. I created a custom STAR rule to block AnyDesk.exe and TeamViewer.exe.
And guess what happened? 🤯
-----------------------------------------------------------------------------------------------------------
💥 Different Behavior for the SAME Rule?
Here’s where things got interesting:
For TeamViewer: SentinelOne triggered an alert, said the session was killed, and marked it as quarantined. But when I checked — guess what — the file was still there on the system. ❌Only the session was ended, but the file was not actually quarantined.
For AnyDesk: The alert triggered the same way — session killed, but this time, the file was actually removed from the system. ✅A clean quarantine and removal. Just as expected.
Wait… what? The same rule, but two different results?
---------------------------------------------------------------------------------------------------------
📩 So I Reached Out to SentinelOne
Naturally, I raised this with SentinelOne support. And here’s what they told me:
“This is expected behavior with STAR rules. These rules are designed more for detection and mitigation rather than real-time blocking. STAR rules typically use 'Mark as Threat' which marks the Storyline as a threat and mitigates all processes involved.”
They further explained the process:
A user executes a command.
Event is sent to the SentinelOne cloud (SDL).
STAR rule matches the event.
A response command is produced.
Agent performs mitigation (can take up to 1 min).
They added that STAR rules are not intended to block applications in real-time, and for real prevention, you should use hash-based blocking via user-defined blocklists.
All good — makes sense to a point. But I wasn’t satisfied yet.
---------------------------------------------------------------------------------------------------------
🤔 So I Asked Again...
Here’s what I asked them directly:
Why does the same STAR rule quarantine and remove the file for AnyDesk, but only ends the session (without removing the file) for TeamViewer?
Is there another way to block applications by file name — considering attackers often change hashes but filenames often remain similar?
Their reply this time shocked me:
“It depends on the source process — the process that initiated the session.”
In interactive sessions, the source process might behave differently compared to non-interactive sessions, which can impact how mitigation occurs.”
So basically… even if the rule is the same, how the application runs (and what process starts it) can result in completely different behaviors in SentinelOne.
---------------------------------------------------------------------------------------------------------
🧠 Final Thoughts (and a Little Rant)
I get that SentinelOne is evolving — and honestly, it's still one of the best MDR solutions out there. But quarantine should mean quarantine. Period.
Not “well, the process was killed but the file stayed” — that’s confusing, especially for analysts trying to understand if a threat was fully neutralized.
I’m sharing this because some of you might run into the same behavior and start wondering “is it a bug?” or “did I do something wrong?” — You didn’t. This is just how it works currently.
So if you’re following my articles or learning from my experiences — make sure you don’t just stop at alerts. Always verify manually whether the file was actually removed.
And of course, if you notice anything odd — reach out to SentinelOne. They’re usually very responsive and open to feedback.
---------------------------------------------------------------------------------------------------------
🔧 TL;DR (Because Who Doesn’t Love One?)
SentinelOne doesn’t support file name–based blocking, only hash (now with SHA-256 too).
STAR rules are for detection and response, not real-time blocking.
Custom rules may behave differently based on how the app was launched (source process).
Same rule ≠ Same outcome.
Always check if files are actually quarantined — don’t assume based on the alert.
---------------------------------------------------------------------------------------------------------
If you’ve experienced something similar, or found a clever workaround — hit me up or drop a comment!
Let’s keep learning from each other.
Until next time,– Dean🔍
----------------------------------------------Dean---------------------------------------------------
Comments