AI Spots the EDR-Evasion Tricks Storm-0249 Uses

Most security teams still treat EDR as the last word on endpoints: if the agent is installed, alerts are tuned, and dashboards are green, you’re covered. Storm-0249 is a reminder that this assumption is fragile.

In a recent set of intrusions, this initial access broker (IAB) didn’t try to “beat” EDR with exotic malware. It hid inside the kinds of processes defenders already trust—EDR components, signed executables, and everyday Windows utilities. The result is the kind of incident that looks like normal IT activity right up until the ransomware affiliate shows up.

This post is part of our AI in Cybersecurity series, and I’m going to take a clear stance: behavior-first detection powered by AI is no longer a nice-to-have for endpoints. It’s the practical way to catch attacks built on “legitimate” processes.

What Storm-0249’s playbook tells us about modern EDR evasion

Answer first: Storm-0249 succeeds because it blends malicious actions into expected endpoint behavior, using trusted binaries and fileless execution paths that signature-heavy defenses routinely miss.

ReliaQuest describes Storm-0249 as an IAB that has shifted away from noisy, mass phishing into high-precision campaigns designed to reduce obvious indicators. That shift matters for one reason: the attacker isn’t betting on a single exploit. They’re betting on your team’s inability to separate normal admin activity from malicious admin lookalikes.

Here’s the uncomfortable part: the techniques in this campaign aren’t “new.” What’s new is how cleanly they’re assembled into a chain that:

• Starts with a human being tricked into running a command
• Gains high privilege using an installer’s normal behavior
• Executes code via a trusted, signed program
• Pulls payloads with utilities your admins use daily
• Keeps execution in memory to reduce forensic residue

If your endpoint strategy is still centered on “known bad” detection, you’re playing the attacker’s game.

The IAB angle: why stealth matters more than speed

Storm-0249 isn’t just trying to break in. As an IAB, it’s trying to deliver reliable access to downstream operators (often ransomware affiliates). That creates an incentive to avoid anything that could burn the access early.

IABs optimize for:

• Low noise (fewer alerts, fewer tickets)
• Repeatability (works across many environments)
• Operational safety (harder to attribute, harder to disrupt)

That’s why abusing EDR-adjacent processes and living-off-the-land binaries (LOLBins) is so attractive. The work looks “boring,” and boring gets ignored.

ClickFix + MSI abuse: the part that makes defenders groan

Answer first: The entry tactic works because it repackages a classic social-engineering move—"run this command"—as a helpful fix, then uses Windows Installer behavior to escalate impact.

Storm-0249 activity observed by ReliaQuest begins with ClickFix, a social-engineering technique that convinces a user to paste a command into the Windows Run dialog. The command is framed as harmless support guidance. It isn’t.

Once executed, it fetches a spoofed support installer hosted on a phishing site designed to look like a legitimate portal. Then Windows Installer does what Windows Installer does: it installs.

The critical detail is privilege. MSI installation flows can execute actions with elevated context, and in this campaign that capability is used to:

• Drop files into protected locations
• Launch payloads with system-level control

If you’re wondering why this keeps working, it’s because many endpoint programs are tuned to avoid disrupting software installation flows. Attackers know that, and they lean on it.

Why this is hard for classic EDR logic

A lot of endpoint detection still orbits around two assumptions:

1. Malware is a file you can hash, scan, or quarantine.
2. Bad behavior looks unusual compared with other software.

ClickFix breaks the first assumption (the “malware” may arrive as scripts and staged components), and MSI abuse breaks the second (installers do weird stuff all the time).

This is exactly where AI-based anomaly detection earns its keep: it doesn’t need the payload to be famous. It needs the pattern to be wrong for your environment.

The EDR impersonation trick: DLL sideloading with a familiar face

Answer first: Storm-0249 used DLL sideloading to run malicious code inside the execution flow of a trusted, signed executable—reducing the chance of signature-based detection.

ReliaQuest reports an MSI containing a trojanized DLL that masquerades as a legitimate component of an EDR product (the example described involved SentinelOne lookalikes). The chain is clever in a very practical way:

• The attacker drops a legitimate executable alongside a malicious DLL.
• The executable searches for dependencies.
• Windows loads the malicious DLL from a path the attacker controls.

This technique is a classic: DLL sideloading. What changes the defensive posture is the choice of disguise. When the “parent” program looks like a known security vendor’s component, your SOC’s instinct is to de-prioritize it.

What defenders should watch for (and why AI helps)

You can’t block every DLL load, and you shouldn’t. But you can look for the wrong DLL load.

A solid detection strategy focuses on:

• Unexpected DLL search order events
• Signed executable + unsigned DLL combinations
• DLL loads from user-writable paths (like AppData) when the executable normally loads from Program Files
• A “security tool” binary executing from a location it’s never executed from in your environment

AI helps by turning this into a modeling problem:

• What DLLs does this executable load in your fleet on normal days?
• What paths are typical for these loads?
• What is the baseline for “installer-time” behavior vs “post-login” behavior?

The practical advantage is speed: instead of writing brittle rules per product/version, you model behaviors and let the system flag deviations that matter.

A useful one-liner for SOC runbooks: “Signed doesn’t mean safe. It means you need better questions.”

Living-off-the-land in 2025: curl.exe, PowerShell, and “fileless” reality

Answer first: Storm-0249 used built-in Windows utilities to fetch and execute payloads in memory, creating activity that resembles routine admin automation while leaving fewer artifacts on disk.

ReliaQuest observed the actor using tools like curl.exe to retrieve PowerShell scripts from URLs that appeared to originate from Microsoft. That’s not an accident. Lots of environments:

• Allow outbound traffic to Microsoft-branded domains with less friction
• Have admins who use curl.exe daily for automation and troubleshooting

Then the attacker executes scripts by piping them directly into PowerShell memory (a common “fileless” pattern). That’s the point: the attacker wants you to see:

• A legitimate binary (curl.exe)
• A legitimate scripting engine (PowerShell)
• A command line that looks like IT work

What “fileless” actually means for detection

“Fileless” rarely means “no evidence.” It usually means:

• Fewer obvious files written to disk
• More reliance on process telemetry, command-line logging, script block logging, and network signals

If your visibility is weak in any of those areas, fileless techniques feel invisible.

AI-based endpoint analytics is effective here because it can correlate weak signals across layers, such as:

• A new child-process chain after user execution of Run box commands
• PowerShell spawning patterns that don’t match your admin tooling
• Short-lived network connections to recently registered domains
• Memory-only execution that correlates with suspicious DLL load paths

The gaps Storm-0249 exploits (and how to close them)

Answer first: The most exploited gaps are predictable: user-writable directories, permissive scripting, overly broad allowlists, and telemetry that isn’t baselined—AI can prioritize which of these is actively being abused.

ReliaQuest points out several common weak spots: unmonitored AppData, registry hives, and over-reliance on perimeter controls and signatures. I’d add another: teams often have logs, but they don’t have confidence in what “normal” looks like.

Here’s a practical hardening checklist that doesn’t require boiling the ocean.

1) Treat AppData as a high-risk execution zone

You don’t need to block AppData entirely. You do need policy.

• Alert on new executables and DLLs dropped into user-writable paths
• Flag signed binaries running from nonstandard directories
• Monitor DLL loads from AppData when the parent process is not expected to execute there

2) Put guardrails on PowerShell (without breaking IT)

Blanket blocking PowerShell usually fails politically and operationally. Guardrails work.

• Enable PowerShell logging (script block + module logging)
• Use PowerShell Constrained Language Mode where feasible
• Alert on download-and-execute patterns and base64-heavy command lines

3) Make allowlisting conditional, not absolute

Many environments “allowlist” LOLBins by default. Attackers love that.

• Allowlist by binary + path + signer + parent process expectations
• Restrict high-risk LOLBins to managed admin contexts
• Alert when LOLBins run from user contexts with unusual parameters

4) Add DNS and domain-age signals to endpoint triage

A simple but effective heuristic: new domains are riskier than old domains.

• Flag endpoints resolving domains registered within the last 90 days
• Correlate domain-age risk with suspicious process behavior

5) Use AI to baseline, then automate response playbooks

This is where AI in cybersecurity pays off in real workflows.

A strong pattern is:

1. Baseline process behavior across the fleet (per department, per role)
2. Detect anomalies (rare parent/child chains, unusual DLL load paths, unexpected installer activity)
3. Automatically enrich alerts with “why this is weird here” context
4. Trigger response steps (isolate host, suspend suspicious process tree, pull memory, block domain) based on confidence

That flow is how you cut time-to-containment without flooding your team.

“People also ask” quick answers (for your runbook)

How can attackers abuse EDR processes without disabling EDR?

By impersonating trusted components (like loading malicious DLLs via sideloading) and executing actions through signed binaries that EDR is less likely to block aggressively.

Why do LOLBins like curl.exe and PowerShell work so well for stealth?

Because they’re common in real IT work. Attackers can hide in routine behavior and reduce the number of suspicious binaries that would trigger straightforward signatures.

What’s the fastest way to improve detection of EDR evasion?

Prioritize process behavior analytics (parent/child chains, DLL load paths, command-line patterns) and baseline what’s normal in your environment so deviations stand out immediately.

Where AI-powered security fits (and what I’d do next week)

Storm-0249 is a clean example of why “we have EDR” isn’t a strategy. EDR is necessary. It’s not sufficient. When an attacker can make their activity look like installers, support tools, and security components, you need detection that’s anchored in behavior and context.

If you want a practical next step, I’ve found this order works well:

1. Instrument: verify you have command-line, PowerShell, and DLL load telemetry.
2. Baseline: use AI-driven analytics to establish normal process chains per team and per device class.
3. Harden: tighten AppData execution and PowerShell guardrails.
4. Automate: build response playbooks for “signed binary from weird path,” “download-and-execute,” and “sideloaded DLL” patterns.

If attackers keep choosing “invisible” techniques that blend into trusted tools, the deciding factor won’t be which product logo you have on the endpoint. It’ll be whether your security stack can explain what’s abnormal in real time—and act on it.

What’s one signed process in your environment that everyone trusts, but nobody has actually baselined?