Ransomware Group abuses SentinelOne EDR for stealthy malware execution

[Khushal]

Content source

https://reliaquest.com/blog/threat-spotlight-storm-0249-precision-endpoint-exploitation/

An initial access broker tracked as Storm-0249 is abusing endpoint detection and response solutions and trusted Microsoft Windows utilities to load malware, establish communication, and persistence in preparation for ransomware attacks.
In one attack analyzed by researchers at cybersecurity company ReliaQuest, Storm-0249 leveraged the SentinelOne EDR components to hide malicious activity. However, researchers say that the same method works with other EDR products, as well.

Threat Spotlight: Storm-0249 Moves from Mass Phishing to Precision EDR Exploitation

Storm-0249 evolves to abuse SentinelOne's SentinelAgentWorker.exe, bypassing defenses. Discover how automated incident response and behavioral analytics detect advanced threats.

reliaquest.com

 

[Bot]

An initial access broker tracked as Storm-0249 is abusing endpoint detection and response solutions and trusted Microsoft Windows utilities to load malware, establish communication, and persistence in preparation for ransomware attacks.
In one attack analyzed by researchers at cybersecurity company ReliaQuest, Storm-0249 leveraged the SentinelOne EDR components to hide malicious activity. However, researchers say that the same method works with other EDR products, as well.

Threat Spotlight: Storm-0249 Moves from Mass Phishing to Precision EDR Exploitation

Storm-0249 evolves to abuse SentinelOne's SentinelAgentWorker.exe, bypassing defenses. Discover how automated incident response and behavioral analytics detect advanced threats.

reliaquest.com

This is a very interesting (and worrying) example of how far threat actors are willing to go to turn defenders’ tools against them.

Key takeaway
Storm-0249 is using endpoint detection and response (EDR) components themselves plus trusted Windows utilities (LOLBins) to:

• Load malware
• Establish C2 communication
• Maintain persistence
• Lay groundwork for later ransomware deployment

In the ReliaQuest case, they abused SentinelOne components, but researchers note the same technique can be adapted to other EDRs as well.

Why this matters
Abusing EDR components is powerful because:

• EDR binaries and services are trusted and often whitelisted.
• Security tools usually have high privileges, so code that rides along inherits strong capabilities.
• Analysts and automated detections are slower to suspect “security tool” processes.
• Many environments have “allow lists” or relaxed monitoring for EDR-related paths and processes.

This is similar in spirit to:

• BYOVD (Bring Your Own Vulnerable Driver) abuse
• DLL sideloading / proxying via signed, trusted executables
• LOLBins/LOLLibs (living-off-the-land binaries/libraries)

but targeted specifically at security software.

Practical defensive ideas
Even if you can’t stop every advanced technique, there are some useful mitigation angles:

• Harden and monitor your EDR itself
  Make sure:
  • EDR tamper protection is fully enabled.
  • EDR installations, services, and drivers are up to date.
  • Changes to EDR configs, binaries, or directories are logged and alerted on.
• Application control around security-tool paths
  Even though EDR is trusted, you can still:
  • Restrict which accounts can write to EDR install directories.
  • Block untrusted processes from loading from / dropping into EDR folders.
  • Use AppLocker / WDAC / other allowlisting to tightly control what can execute from those locations.
• Watch for abuse of trusted Windows utilities (LOLBins)
  Since the article mentions trusted MS utilities:
  • Baseline normal usage of tools like PowerShell, WMI, msiexec, regsvr32, certutil, etc.
  • Alert on unusual command-line patterns, abnormal user accounts, or execution from unusual paths.
• Hunt for “EDR behaving strangely”
  Signals that should stand out:
  • EDR processes spawning unexpected child processes (e.g. command shells, script interpreters, compression tools).
  • Unusual network connections originating from EDR processes.
  • Unsigned or unknown DLLs loaded into EDR processes.
• Least privilege and segmentation
  Limit damage if an IAB like Storm-0249 gains a foothold:
  • Limit local admin use; separate admin accounts from normal user accounts.
  • Network segmentation so that an initial endpoint compromise doesn’t give easy lateral movement.
  • Tight control on access to backup infrastructure and domain controllers.
• Use multiple layers, not just EDR
  If the EDR layer is abused or blinded:
  • Network security monitoring (NetFlow, DNS logs, proxy logs) can still show C2 and staging.
  • Email and web filtering can catch the initial delivery.
  • Offline / immutable backups reduce impact if ransomware does get deployed.

What to do next

• If you’re running SentinelOne or any EDR, it’s worth reading the ReliaQuest write-up carefully for:
  • IOCs
  • TTPs (how they load and hide malware)
  • Any suggested detection rules (Sigma/YARA, etc.)
• Ask your EDR vendor (or check their advisory pages) whether they’ve published guidance or new detections related to this technique.
• If you’re a home user, the best you can generally do is:
  • Keep your security product fully updated.
  • Avoid running multiple overlapping EDR/AV products in weird configurations.
  • Keep OS and applications patched.

Overall, this is another reminder that “having an EDR” is not the same as “being secure” – attackers are actively studying and abusing the very tools meant to catch them, so monitoring and hardening around your security stack itself is becoming critical.