Cato CTRL™ Threat Research: Foxveil – New Malware Loader Abusing Cloudflare, Discord, and Netlify as Staging Infrastructure

Khushal

Level 15
Thread author
Verified
Top Poster
Well-known
Apr 4, 2024
710
4,465
1,369
Cato CTRL identified Foxveil, a two-variant initial-stage loader active since Aug 2025 that fetches shellcode from Cloudflare Pages, Netlify, or Discord attachments and injects it to persist; the Cato SASE Platform blocks Foxveil before execution.


1770828300011.png
 
Foxveil takes advantage of trusted platforms like Cloudflare, Netlify, and Discord to disguise malware. The funny (or tragic) part is that these platforms are seen as “trustworthy,” which makes the deception a double blow: first the legitimate appearance, then the malicious payload. The lesson: even the familiar can be risky. 🔍💻😬
 
Technical Analysis & Remediation

MITRE ATT&CK Mapping

T1027 (Obfuscated Files or Information)
Runtime string mutation rewrites keywords like "meterpreter" and "payload" to random values to defeat static analysis.

T1055.004 (Process Injection: Asynchronous Procedure Call) Variant v1 uses "Early Bird" APC injection into a spawned, masqueraded svchost.exe.

T1543.003 (Create or Modify System Process: Windows Service) Variant v1 registers itself as the service AarSvc for persistence.

T1562.001 (Impair Defenses)
Variant v2 attempts (via WMI) to manipulate Microsoft Defender exclusions for C:\Windows\SysWOW64.

Telemetry Profile

Filesystem Indicators


Path

C:\Windows\SysWOW64\

Masqueraded Filenames
sms.exe, sihost.exe, taskhostw.exe, taskhostw1.exe, audiodg.exe.

Staging Names
real1.exe, real2.exe (Downloaded to temp locations).

Network Indicators

Localhost Ports

TCP 9933, 9934 (Indicative of Cobalt Strike listening behavior).

Protocol
HTTPS (443) to trusted subdomains.

Remediation - THE ENTERPRISE TRACK (NIST CSF 2.0)

DETECT (DE) – Monitoring & Analysis

Command

Deploy IOC Blocklist immediately (See Section 6).

Command
Configure EDR to alert on process spawning where execution.exe (or unknown parent) spawns svchost.exe, legitimate svchost.exe should almost always be spawned by services.exe.

Command
Query SIEM for WMI commands containing Remove ExclusionPath targeting SysWOW64.

RESPOND (RS) – Mitigation

Command

Isolate any host initiating connections to *.pages.dev or *.netlify.app outside of a browser process (e.g., PowerShell, WScript, or unsigned binaries).

Command
Terminate processes listening on ports 9933 or 9934 immediately and capture memory dumps for forensics.

IDENTIFY (ID) – Asset Management

Command

Search for the service AarSvc. If found, validate the binary path. If it points to a non-standard location or lacks a valid Microsoft signature, disable the service and quarantine the host.

Remediation - THE HOME USER TRACK

Priority 1: Check your "System" Folders

Command

Navigate to C:\Windows\SysWOW64\ (You may need to "Show Hidden Files"). Look for files created recently (since August 2025) named sms.exe or real1.exe. Note: sms.exe is usually not in SysWOW64; the real one is smss.exe in System32. The slight spelling difference is a trap.

Priority 2: Antivirus Check

Command

Foxveil v2 tries to tamper with Windows Defender. Open Windows Security -> Virus & threat protection -> Manage settings -> Exclusions. If you see C:\Windows\SysWOW64 listed there, REMOVE IT immediately. The malware put it there to hide.

Verified IOC List (Refang before use)

Network Indicators (Domains)


syscore[.]pages[.]dev

taskhostw[.]pages[.]dev

smss-416[.]pages[.]dev

csrss[.]netlify[.]app

sec-healthcore[.]netlify[.]app

driverstore-cdn[.]netlify[.]app

latestumang[.]netlify[.]app

winsysops[.]netlify[.]app

File Artifacts (SHA-256 Sample)

62dd94ece73f510d03c74a00bfe9d8ad09d49c140fc30415a843c97cf018107f

26d4e07514498453aa5d409a28489008080d307899bda8357870f193bdb994b8

1ed74593fb463a16b29bb24f31d06c749e59c6da82410b1dc9f1e53583b765f1

bad1c2cdaecb3dfba5cd00127131b623f600230fb344c662f84051da3b3f8d0a

Hardening References

Context
Foxveil abuses "Donut" (shellcode generator). Detection of in-memory .NET assembly execution is critical.

Configuration
Review the "Cato CTRL Threat Research" report (Feb 11, 2026) for the full list of 34 observed hashes.

Primary Intelligence Source

Cato CTRL™ Threat Research
 
  • Like
Reactions: Zero Knowledge
It is interesting for forum members to note that the domains are all outside those most commonly used, where the concept of blocking outside a set of basic TLDs, which should not be entrusted to lists, allows for greater protection without doing anything.
The suggestion to "block outside a set of basic TLDs" is a dangerous oversimplification. While effective against low-effort spam domains (like .xyz or .top), it is completely ineffective against modern threats like Foxveil. Foxveil specifically targets "High Reputation" TLDs (.com, .dev, .app) to blend in. Implementing this advice would not only fail to stop the attack but would also break substantial portions of the modern web for both home and business users.
 
The suggestion to "block outside a set of basic TLDs" is a dangerous oversimplification. While effective against low-effort spam domains (like .xyz or .top), it is completely ineffective against modern threats like Foxveil. Foxveil specifically targets "High Reputation" TLDs (.com, .dev, .app) to blend in. Implementing this advice would not only fail to stop the attack but would also break substantial portions of the modern web for both home and business users.

Please provide at least one web page where it is possible to become infected.

P.S.

In the absence of this, I remain certain (not just opinionated) that even if, as I requested, there is an exception that confirms this general rule, I am going to dinner.
Have a good evening.:)
 
Last edited:
Please provide at least one web page where it is possible to become infected.
Asking for a 'live infection page' right now is missing the entire point of this campaign's architecture.

The report explicitly states that the Discord links expire automatically in 24 hours. The Netlify and Cloudflare pages were taken down on Jan 19th and 20th.

The fact that we can't provide a live link today is exactly why this technique is successful. They spin up a legitimate page, infect thousands of users in a 4-hour phishing window, and then burn the URL before vendors can blacklist it.

If you are waiting for a permanent URL to add to your blocklist, you have already lost. You cannot block 'Discord' or 'Cloudflare' entirely, and you cannot block the specific URLs because they rotate faster than you can update your list.

You are asking for a static target in a dynamic environment. The absence of a live link today proves the evasion strategy works, not that the threat doesn't exist.
 
Asking for a 'live infection page' right now is missing the entire point of this campaign's architecture.

The report explicitly states that the Discord links expire automatically in 24 hours. The Netlify and Cloudflare pages were taken down on Jan 19th and 20th.

The fact that we can't provide a live link today is exactly why this technique is successful. They spin up a legitimate page, infect thousands of users in a 4-hour phishing window, and then burn the URL before vendors can blacklist it.

If you are waiting for a permanent URL to add to your blocklist, you have already lost. You cannot block 'Discord' or 'Cloudflare' entirely, and you cannot block the specific URLs because they rotate faster than you can update your list.

You are asking for a static target in a dynamic environment. The absence of a live link today proves the evasion strategy works, not that the threat doesn't exist.


I don't use lists, I've explained this over and over again.
Once again, have a good evening.
 
  • Like
Reactions: Khushal and rashmi
I don't use lists, I've explained this over and over again.
Once again, have a good evening.
You: 'Block outside a set of basic TLDs.'
Also You: 'I don't use lists.'

A 'set' of allowed TLDs is a list (an Allow List). You are advocating for a Whitelist strategy while claiming you don't use lists.

Regardless of the semantics, your strategy fails because the malware uses the 'Basic TLDs' you would allow (Discord = .com). The links are dead because the campaign is ephemeral, as the report stated.

Enjoy your evening.
 
You: 'Block outside a set of basic TLDs.'
Also You: 'I don't use lists.'

A 'set' of allowed TLDs is a list (an Allow List). You are advocating for a Whitelist strategy while claiming you don't use lists.

Regardless of the semantics, your strategy fails because the malware uses the 'Basic TLDs' you would allow (Discord = .com). The links are dead because the campaign is ephemeral, as the report stated.

Enjoy your evening.

In fact, my permitted TLDs are not comparable to a whitelist.
Is that difficult to understand?
However, without an active link, it is not possible to prove my point.
Period.
 
In fact, my permitted TLDs are not comparable to a whitelist.
Is that difficult to understand?
However, without an active link, it is not possible to prove my point.
Period.
Let's be precise about the terminology you are using.

You stated you have a set of 'permitted TLDs' and you 'block outside' of them. That is the literal, textbook definition of a Whitelist (Allow-list) approach. Claiming they are 'not comparable' is semantically incorrect. You are using a TLD Whitelist.

You don't need a 'live link' to prove the vulnerability; you just need to look at the domain structure.

Fact: Foxveil v2 exploits discord.com.

Fact: Your 'Permitted TLD' list undoubtedly includes .com (the most basic TLD).

Result: Your filter permits the malware traffic.


The link is dead because the threat is ephemeral (24-hour expiry), which is why static lists (or TLD sets) fail. You are asking for a live sample of a ghost, while your front door is wide open to .com.

Period.

Try reading the article.
 
My .com TLD permission is not only subject to dynamic filtering + static filtering + a set of more permissive containment rules than those I adopt outside of permitted TLDs.
I have never written that my permitted TLDs are devoid of any protection comparable to a whitelist.
Your .com will be whitelisted, mine will not.
 
My .com TLD permission is not only subject to dynamic filtering + static filtering + a set of more permissive containment rules than those I adopt outside of permitted TLDs.
I have never written that my permitted TLDs are devoid of any protection comparable to a whitelist.
Your .com will be whitelisted, mine will not.
Thank you for the concession.

You just admitted that you permit (allow) .com traffic, subject to dynamic filtering.

In network security, 'Permitting' a TLD is Whitelisting it at the Access Control level. The fact that you inspect it afterwards doesn't change the fact that your TLD rule is 'Allow'.

My entire point was that TLD Blocking (your original advice) is ineffective against Foxveil because the malware lives on .com (Discord).

By admitting that you rely on 'dynamic filtering + containment' for .com, rather than blocking the TLD, you have confirmed my argument: TLD Blocking fails here; Deep Inspection is required.

You are relying on the exact same inspection layers I advocated for, because your TLD list lets the malware in.

We are in agreement that your TLD strategy is insufficient.
 
Let's summarize your position for the record, so everyone can see the contradiction.

You started by claiming 'I don't use lists,' then admitted you have a 'Permitted Set' of TLDs. When pointed out that a Permitted Set is a Whitelist, you resorted to semantic games and mockery rather than admitting the terminology was correct.

You explicitly stated: 'My .com TLD permission is... subject to dynamic filtering.'

This admits you Permit (Whitelist) .com.

This admits you rely on Filtering (Inspection) to catch threats inside .com.

You have conceded my original point, that TLD blocking alone is useless against threats like Foxveil (Discord), and deep inspection is the only real defense.

You can twist words all you want, but you just admitted that your own advice (blocking outside basic TLDs) fails without the heavy lifting of the inspection layers I advocated for.

I'm interested in professional security discussion, not semantic goal-shifting. Since you've conceded the technical point, we are done here.
 
Last edited by a moderator:
It is always fun to read those in theory "whoaa you are in danger" posts, because it is not a whtelist nor a default deny approach (with a hypothetical real world risk of less than 0,000001%) It is nice for people who build a bunker and want to proof that their bunker is best.

When I go to [random name of city] tomorrow I could be hit by a bus. When I go out dining with my wife the 14th we could both due to food poisoning. Life comes with risks, but most of them are small and neglect able,

I agree with @Halp2001 is right that using well known websites like discord and cloudflare increases the chances that someone shoots itself in their foot. On the other side by reducing the scope of TLD's you allow, does not reduce the risk to zero, but you can't deny it reduces the attack surface.

I also block new domains and newly seen domain.Is it a whitelist, nor a default deny? No it is a blacklist, but IMO one of the most effective measures against phishing.
 
It is always fun to read those in theory "whoaa you are in danger" posts, because it is not a whtelist nor a default deny approach (with a hypothetical real world risk of less than 0,000001%) It is nice for people who build a bunker and want to proof that their bunker is best.

When I go to [random name of city] tomorrow I could be hit by a bus. When I go out dining with my wife the 14th we could both due to food poisoning. Life comes with risks, but most of them are small and neglect able,

I agree with @Halp2001 is right that using well known websites like discord and cloudflare increases the chances that someone shoots itself in their foot. On the other side by reducing the scope of TLD's you allow, does not reduce the risk to zero, but you can't deny it reduces the attack surface.

I also block new domains and newly seen domain.Is it a whitelist, nor a default deny? No it is a blacklist, but IMO one of the most effective measures against phishing.
Your invented statistic of a "0.000001% theoretical risk" is objectively disproven by the hard telemetry confirming this campaign has been active in the wild since August 2025. Furthermore, your primary defense of blocking "newly seen domains" is mathematically guaranteed to fail against this specific threat because Foxveil is engineered to abuse the very infrastructure you trust. The malware stages its payloads on Discord, Cloudflare Pages, and Netlify, platforms with high reputation and domain ages spanning decades, not days. While you are busy filtering for "new" domains, this loader connects to discord.com or *.pages.dev to retrieve its Donut-generated shellcode, traffic that your "effective measure" would explicitly whitelist. By ignoring confirmed indicators like the TCP 9933/9934 command-and-control listeners and dismissing documented evasion techniques as "bunker building," you are not managing risk; you are creating a blind spot for Living-off-Trusted-Sites (LoTS) attacks that bypass the exact "probability" model you are relying on.
 
If the malware reaches SAC or is blocked by the "Validate Admin Code Signatures" registry key, I would already have lost.
It must not get past the browser.;)
I like your approach; pre-execution prevention is far superior to post-execution one.
If I have reached the stage of post-execution prevention, I would reinstall Windows, regardless of aborting the attack or not.
 
  • Like
Reactions: Sampei.Nihira