How the Stealth Falcon Attack Works — and How White Cloud Security Stops It

Overview

A newly discovered zero-day exploit (CVE‑2025‑33053) attributed to the Stealth Falcon APT group showcases a sophisticated method of using legitimate Windows tools to execute attacker-controlled code. This post explains how the attack works, how it evades detection using Living-Off-The-Land (LOTL) techniques, and how White Cloud Security Trust Lockdown completely neutralizes it with its default-deny Zero-Trust execution model.

Attack Summary: CVE-2025-33053 (WebDAV Shortcut Hijack)

The core of the Stealth Falcon attack involves the use of a .url Windows shortcut file that leverages a vulnerability in how the iediagcmd.exe diagnostic tool resolves binaries from its working directory — even when that working directory is a remote WebDAV share controlled by the attacker.

Exploit Chain:

Malicious Shortcut (.url)
- The .url file is sent to the victim or planted on disk.
- It sets the WorkingDirectory to \\attacker.webdav.server\share.
Windows Launches iediagcmd.exe
- This is a legitimate signed Windows binary (a LOLBin).
- It is allowed by the OS and trusted by most endpoint security tools.
LOLBins Hijacked via Working Directory
- iediagcmd.exe tries to launch other tools like route.exe, netsh.exe, or CustomShellHost.exe.
- Normally, these are pulled from C:\Windows\System32, but due to the working directory being set to a remote WebDAV location, the system instead executes attacker-provided versions.
Malware Payload
- The malicious binaries decrypt and inject a custom implant called Horus Agent.
- Capabilities include keylogging, credential theft, file exfiltration, and command/control operations.

Living-Off-The-Land Techniques Used

Stealth Falcon uses Living-Off-The-Land Binaries (LOLBins) to remain stealthy:

Uses iediagcmd.exe, a trusted Windows diagnostic tool.
Exploits Working Directory precedence to load hijacked LOLBins (route.exe, netsh.exe) from a remote source.
Avoids writing new executables to disk locally, bypassing traditional antivirus detection.

How White Cloud Security Trust Lockdown Blocks This Attack

White Cloud Security Trust Lockdown stops the Stealth Falcon attack cold using a Default-Deny Execution Model combined with Cyber-Metric Handprint validation.

Zero-Trust by Default

Trust Lockdown only allows execution of files that meet one or more of the following: - On a Trust List (exact match using SHA-1, SHA-256, SHA-512, MD5, CRC32, and file length). - Signed by a code-signing certificate explicitly trusted in a Trust Profile. - Explicitly approved by an admin.

What Happens During the Attack?

iediagcmd.exe launches (it’s a signed, trusted Windows binary — allowed).
It tries to launch route.exe from \\attacker.webdav.server\share\route.exe.
Trust Lockdown evaluates the binary against the Trust List:
- Not signed by a trusted cert
- Not on any Trust List
- Doesn’t match any 6-factor handprint
Trust Lockdown blocks the execution immediately.
The rest of the attack chain is terminated.

Attack Flow Diagram: Where Trust Lockdown Intervenes

The following sequence diagram illustrates the Stealth Falcon attack and where White Cloud Security Trust Lockdown intervenes to block the execution of the attacker-controlled binary.

sequenceDiagram
    participant Attacker
    participant Victim
    participant Windows
    participant WCS Trust Lockdown

    Attacker->>Victim: Delivers .url shortcut\n(targeting WebDAV path)
    Victim->>Windows: Opens .url file
    Windows->>Windows: Launches iediagcmd.exe (trusted LOLBin)
    Windows->>\\WebDAV Server: Sets Working Directory
    Windows->>Windows: Attempts to load route.exe from WebDAV
    Windows->>WCS Trust Lockdown: File execution request

    alt Malware Always Blocked by Trust Lockdown Default-Deny
        WCS Trust Lockdown-->>Windows: Deny Execution
        WCS Trust Lockdown-->>Syslog: Log "blocking": 1 event
        Windows-->>Attacker: Execution fails (attack blocked)
    else Malware allowed when undetected by Antivirus / NextGen AV / EDR / MDR / XDR
        Windows->>Windows: Executes route.exe
        route.exe->>Windows: Decrypts and injects malware
        Malware->>Attacker: Establishes C2 channel
    end

What Gets Logged When the Attack is Blocked

When Trust Lockdown blocks an attacker-controlled binary from executing by default, it logs the event in the organization's Blocked Apps table and generates an administrative notification.

The Blocked Apps entry includes metadata such as:

File path and filename (e.g., \\attacker.webdav.server\share\route.exe)
Hostname and user attempting the execution
Group and policy context (e.g., GID, TID, Security Group)
Reason for block (not on Trust List or not signed by a trusted certificate)

Admins can review the notification and associated block log to:

Investigate the origin of the blocked execution
Confirm that it originated from an attacker-controlled WebDAV share
Apply additional block policies to prevent any future approval of similar binaries (e.g., wildcard blocking of external .exe loads via UNC paths)

This proactive control ensures that even if an unwary admin later reviews unknown binaries, Trust Lockdown enforcement policies can prevent accidental approvals — maintaining Zero-Trust protection against stealthy LOLBin attacks.

How the Stealth Falcon Attack Works — and How White Cloud Security Stops It