Morphisec Thwarts Russian-Linked StealC V2 Campaign Targeting Blender Users via Malicious .blend Files

[Khushal]

Content source

https://www.morphisec.com/blog/morphisec-thwarts-russian-linked-stealc-v2-campaign-targeting-blender-users-via-malicious-blend-files/

In recent months, Morphisec has successfully prevented multiple sophisticated malware campaigns leveraging Blender Foundation files to deliver the notorious StealC V2 infostealer.

This ongoing operation, active for at least six months, involves implanting malicious .blend files on platforms like CGTrader. Users unknowingly download these 3D model files, which are designed to execute embedded Python scripts upon opening in Blender—a free, open-source 3D creation suite.

Morphisec Thwarts Russian-Linked StealC V2 Campaign Targeting Blender Users via Malicious .blend Files

In this threat analysis, Morphisec researchers detail a Russian-linked Steal C campaign, its attack path and complete infrastructure.

www.morphisec.com

https://engage.morphisec.com/hubfs/2025_PDFs/MorphisecThwarts_RussianLinkedStealCV2Campaign.pdf

 

[Bot]

In recent months, Morphisec has successfully prevented multiple sophisticated malware campaigns leveraging Blender Foundation files to deliver the notorious StealC V2 infostealer.

View attachment 293281

This ongoing operation, active for at least six months, involves implanting malicious .blend files on platforms like CGTrader. Users unknowingly download these 3D model files, which are designed to execute embedded Python scripts upon opening in Blender—a free, open-source 3D creation suite.

Morphisec Thwarts Russian-Linked StealC V2 Campaign Targeting Blender Users via Malicious .blend Files

In this threat analysis, Morphisec researchers detail a Russian-linked Steal C campaign, its attack path and complete infrastructure.

www.morphisec.com

https://engage.morphisec.com/hubfs/2025_PDFs/MorphisecThwarts_RussianLinkedStealCV2Campaign.pdf

This is a very interesting (and worrying) campaign, and it’s a good reminder that 3D/creative tools can be just as dangerous as office documents or PDFs.

What’s going on in this campaign (high level)
From what you shared and the diagram:

• Attackers upload malicious [.blend] 3D model files (and related ZIPs) on sites like CGTrader.
• When opened in Blender, these files trigger embedded Python scripts. Blender supports Python for automation, so this is a legitimate feature being abused.
• The Python script:
  • Runs quietly in the background.
  • Downloads additional code – such as a PowerShell (.ps1) script called ZalpyaGyliveraV1 – from the internet.
  • Executes more Python/Powershell stages to pull down further payloads.
• Final payloads include:
  • StealC v2 infostealer.
  • A Python‑based stealer referred to as BLENDERX in the diagram.
• End result: a credential/info stealer on the system, able to grab passwords, cookies, wallets, and other sensitive data.

So it’s essentially “malicious macros in 3D form”: open a model, get a stealer.

Why Blender files are a good target

• Blender is free and widely used (artists, students, indie devs, some businesses).
• .blend files can contain Python scripts, not just geometry and textures.
• Users often download assets from marketplaces and open them without much suspicion.
• Security products might not scrutinize .blend files as aggressively as more common malware containers (Office docs, archives, etc.).

Practical protections for Blender / 3D users

1. Treat .blend files as potentially executable content

• Only download models from sources and authors you really trust.
• Avoid random “too good to be true” assets (expensive packs for free, cracked content, etc.).
• Prefer official marketplaces where abusive uploads are more likely to be reported/removed quickly.

2. Lock down Blender’s scripting behavior where possible
(Exact options can change between versions; check your Blender version’s preferences.)

• In Preferences → Save & Load / File Paths / Security (or similar, depending on version), look for:
  • Options around “Auto Run Python Scripts” or “Trusted Paths”.
  • Disable automatic script execution for files from untrusted locations.
• If available, require manual confirmation when a .blend file wants to run Python.
• Use “trusted paths” only for your own project folders, not general download directories.

3. Isolate risky content

• Open .blend files from public marketplaces in a separate, lower‑risk environment:
  • A non‑privileged test machine.
  • A virtual machine (VM) with no access to your password manager, crypto wallets, or sensitive documents.
• Avoid opening downloaded assets on the same system you use for banking, work VPN, or managing crypto if you can separate those tasks.

4. Harden the OS and network

• Keep Windows/macOS and Blender fully updated.
• Use a reputable security suite with:
  • Behavioral/anti‑exploit protections.
  • Web and script (PowerShell) monitoring.
• If possible, restrict PowerShell on systems that don’t need it for admin tasks (e.g. Constrained Language Mode, blocking unsigned scripts in enterprise).

5. If you suspect you may have opened a malicious .blend recently
I can’t know if a specific file is malicious, so I’d suggest:

• Disconnect from the internet if you see anything clearly suspicious (unexpected PowerShell windows, high network activity, strange startup entries).
• Run full scans with:
  • Your main AV.
  • Optionally a second opinion scanner (ESET Online Scanner, Kaspersky Virus Removal Tool, etc.).
• Check startup items and scheduled tasks for unknown entries.
• Change passwords for:
  • Email, banking, major online accounts.
  • Any services you use in browsers where credentials might have been stored.
• Enable 2FA where possible.
• If you have crypto wallets on that machine, consider them potentially compromised; move funds from a clean device with new wallets/keys.

For forum members / defenders
If you’re on the blue‑team or doing monitoring:

• Watch for unusual PowerShell invocations originating from Blender processes.
• Monitor for outbound connections immediately after .blend files are opened.
• Consider application control: restrict Blender from launching PowerShell or other scripting engines if your workflows don’t require it.
• Educate artists and content creators that “models can be malware carriers” just like Office docs.

If you share or sell Blender assets

• Scan your own .blend files and exports before uploading.
• Be prepared to show your scripting usage (if any) so users know why a file needs Python.

If you’d like, I can suggest more concrete Blender preference settings (based on version) or a basic checklist you could share with artists in a studio or classroom.

 

[Divergent]

This is a very interesting (and worrying) campaign, and it’s a good reminder that 3D/creative tools can be just as dangerous as office documents or PDFs.

What’s going on in this campaign (high level)
From what you shared and the diagram:

• Attackers upload malicious [.blend] 3D model files (and related ZIPs) on sites like CGTrader.
• When opened in Blender, these files trigger embedded Python scripts. Blender supports Python for automation, so this is a legitimate feature being abused.
• The Python script:
  • Runs quietly in the background.
  • Downloads additional code – such as a PowerShell (.ps1) script called ZalpyaGyliveraV1 – from the internet.
  • Executes more Python/Powershell stages to pull down further payloads.
• Final payloads include:
  • StealC v2 infostealer.
  • A Python‑based stealer referred to as BLENDERX in the diagram.
• End result: a credential/info stealer on the system, able to grab passwords, cookies, wallets, and other sensitive data.

So it’s essentially “malicious macros in 3D form”: open a model, get a stealer.

Why Blender files are a good target

• Blender is free and widely used (artists, students, indie devs, some businesses).
• .blend files can contain Python scripts, not just geometry and textures.
• Users often download assets from marketplaces and open them without much suspicion.
• Security products might not scrutinize .blend files as aggressively as more common malware containers (Office docs, archives, etc.).

Practical protections for Blender / 3D users

1. Treat .blend files as potentially executable content

• Only download models from sources and authors you really trust.
• Avoid random “too good to be true” assets (expensive packs for free, cracked content, etc.).
• Prefer official marketplaces where abusive uploads are more likely to be reported/removed quickly.

2. Lock down Blender’s scripting behavior where possible
(Exact options can change between versions; check your Blender version’s preferences.)

• In Preferences → Save & Load / File Paths / Security(or similar, depending on version), look for:
  • Options around “Auto Run Python Scripts” or “Trusted Paths”.
  • Disable automatic script execution for files from untrusted locations.
• If available, require manual confirmation when a .blend file wants to run Python.
• Use “trusted paths” only for your own project folders, not general download directories.

3. Isolate risky content

• Open .blend files from public marketplaces in a separate, lower‑risk environment:
  • A non‑privileged test machine.
  • A virtual machine (VM) with no access to your password manager, crypto wallets, or sensitive documents.
• Avoid opening downloaded assets on the same system you use for banking, work VPN, or managing crypto if you can separate those tasks.

4. Harden the OS and network

• Keep Windows/macOS and Blender fully updated.
• Use a reputable security suite with:
  • Behavioral/anti‑exploit protections.
  • Web and script (PowerShell) monitoring.
• If possible, restrict PowerShell on systems that don’t need it for admin tasks (e.g. Constrained Language Mode, blocking unsigned scripts in enterprise).

5. If you suspect you may have opened a malicious .blend recently
I can’t know if a specific file is malicious, so I’d suggest:

• Disconnect from the internet if you see anything clearly suspicious (unexpected PowerShell windows, high network activity, strange startup entries).
• Run full scans with:
  • Your main AV.
  • Optionally a second opinion scanner (ESET Online Scanner, Kaspersky Virus Removal Tool, etc.).
• Check startup items and scheduled tasks for unknown entries.
• Change passwords for:
  • Email, banking, major online accounts.
  • Any services you use in browsers where credentials might have been stored.
• Enable 2FA where possible.
• If you have crypto wallets on that machine, consider them potentially compromised; move funds from a clean device with new wallets/keys.

For forum members / defenders
If you’re on the blue‑team or doing monitoring:

• Watch for unusual PowerShell invocations originating from Blender processes.
• Monitor for outbound connections immediately after .blend files are opened.
• Consider application control: restrict Blender from launching PowerShell or other scripting engines if your workflows don’t require it.
• Educate artists and content creators that “models can be malware carriers” just like Office docs.

If you share or sell Blender assets

• Scan your own .blend files and exports before uploading.
• Be prepared to show your scripting usage (if any) so users know why a file needs Python.

If you’d like, I can suggest more concrete Blender preference settings (based on version) or a basic checklist you could share with artists in a studio or classroom.

I'm impressed @Bot , I shall show you why.

EXECUTIVE SUMMARY

The analysis provided by the forum AI Bot is ACCURATE and highly corroborated by external threat intelligence (Morphisec, GBHackers). The bot correctly identifies the attack vector, malware strain, and mitigation strategies. A minor syntax error was detected in the naming of a specific payload (Zalpya vs Zalypa), likely a transcription error, but the technical logic remains sound. Confidence Score: A-1 (Verified).

TECHNICAL ACCURACY AUDIT

Attack Chain: The bot correctly describes the chain: .blend file --> Embedded Python (Rig_Ui.py) --> PowerShell Loader --> Final Payload (StealC/BlenderX).

Targeting: The bot accurately notes this campaign targets "artists, students, indie devs", identifying a shift from typical corporate targets to the creative sector.

 

[Bot]

I'm impressed @Bot , I shall show you why.

EXECUTIVE SUMMARY

The analysis provided by the forum AI Bot is ACCURATE and highly corroborated by external threat intelligence (Morphisec, GBHackers). The bot correctly identifies the attack vector, malware strain, and mitigation strategies. A minor syntax error was detected in the naming of a specific payload (Zalpya vs Zalypa), likely a transcription error, but the technical logic remains sound. Confidence Score: A-1 (Verified).

TECHNICAL ACCURACY AUDIT

Attack Chain: The bot correctly describes the chain: .blend file --> Embedded Python (Rig_Ui.py) --> PowerShell Loader --> Final Payload (StealC/BlenderX).

Targeting: The bot accurately notes this campaign targets "artists, students, indie devs", identifying a shift from typical corporate targets to the creative sector.

That’s very helpful feedback, thanks for taking the time to validate the post against the Morphisec material.

On the naming issue
You’re right about the minor discrepancy: I wrote ZalpyaGyliveraV1; some reports use ZalypaGyliveraV1. That’s on me for the transcription. For practical defense it mainly matters that defenders:

• Match the exact strings/IoCs from the original reports when creating detections (PowerShell script names, paths, URLs, hashes).
• Assume small name changes/variants are likely in follow‑up waves (e.g. minor spelling or version changes).

Hardening ideas you might add to your write‑up
If you’re turning this into a bigger post or internal advisory, a few concrete, defender‑oriented additions that align with what Morphisec describes:

• Process chains to hunt for:
  • blender.exe → powershell.exe spawning soon after opening external .blend files.
  • Unusual PowerShell parameters like encoded commands or downloading from IPs/domains not seen before in your environment.
• Detection content:
  • EDR rules for “Office‑style” behavior from Blender (script execution, LOLBins, script interpreters).
  • Network alerts for first‑time connections shortly after a Blender project is opened.
• Blender baseline:
  • For studios: capture what “normal” Blender usage looks like (process tree, network) so deviations are more obvious.
  • Document if any in‑house add‑ons legitimately run PowerShell/Python with network access, to reduce false positives.

If you’d like, I can help you draft a short “Blender Security Guidelines” post tailored for artists (non‑technical language) or a more SOC‑centric checklist with specific log sources and event IDs.

 

[Divergent]

That’s very helpful feedback, thanks for taking the time to validate the post against the Morphisec material.

On the naming issue
You’re right about the minor discrepancy: I wrote ZalpyaGyliveraV1; some reports use ZalypaGyliveraV1. That’s on me for the transcription. For practical defense it mainly matters that defenders:

• Match the exact strings/IoCs from the original reports when creating detections (PowerShell script names, paths, URLs, hashes).
• Assume small name changes/variants are likely in follow‑up waves (e.g. minor spelling or version changes).

Hardening ideas you might add to your write‑up
If you’re turning this into a bigger post or internal advisory, a few concrete, defender‑oriented additions that align with what Morphisec describes:

• Process chains to hunt for:
  • blender.exe → powershell.exe spawning soon after opening external .blend files.
  • Unusual PowerShell parameters like encoded commands or downloading from IPs/domains not seen before in your environment.
• Detection content:
  • EDR rules for “Office‑style” behavior from Blender (script execution, LOLBins, script interpreters).
  • Network alerts for first‑time connections shortly after a Blender project is opened.
• Blender baseline:
  • For studios: capture what “normal” Blender usage looks like (process tree, network) so deviations are more obvious.
  • Document if any in‑house add‑ons legitimately run PowerShell/Python with network access, to reduce false positives.

If you’d like, I can help you draft a short “Blender Security Guidelines” post tailored for artists (non‑technical language) or a more SOC‑centric checklist with specific log sources and event IDs.

I actually analyzed your post for accuracy. It's why I said I was impressed.

 

[Bot]

I actually analyzed your post for accuracy. It's why I said I was impressed.

Understood—and that makes the compliment even more meaningful.

Thank you for doing that analysis. Having a human cross‑check against primary sources (Morphisec, GBHackers, etc.) is exactly what reduces the risk of AI‑driven misinformation on technical topics.

If you ever spot anything that looks off (even small details like the Zalypa naming), please feel free to call it out. That kind of feedback directly improves how useful I am to the forum.

If you want, I can also:

• Summarize key IoCs and behaviors from the Morphisec report in MT‑friendly format.
• Help draft a short “Blender security best practices” sticky/post aimed at artists and students.

Tell me which angle you’d find most useful next.

 

[cartaphilus]

I'm impressed @Bot , I shall show you why.

EXECUTIVE SUMMARY

The analysis provided by the forum AI Bot is ACCURATE and highly corroborated by external threat intelligence (Morphisec, GBHackers). The bot correctly identifies the attack vector, malware strain, and mitigation strategies. A minor syntax error was detected in the naming of a specific payload (Zalpya vs Zalypa), likely a transcription error, but the technical logic remains sound. Confidence Score: A-1 (Verified).

TECHNICAL ACCURACY AUDIT

Attack Chain: The bot correctly describes the chain: .blend file --> Embedded Python (Rig_Ui.py) --> PowerShell Loader --> Final Payload (StealC/BlenderX).

Targeting: The bot accurately notes this campaign targets "artists, students, indie devs", identifying a shift from typical corporate targets to the creative sector.

My Russian is wicked rusty haven't used it since the 80's BUT if my memory serves correctly Zalypa means D1k Head as a slang

 

[Bot]

My Russian is wicked rusty haven't used it since the 80's BUT if my memory serves correctly Zalypa means D1k Head as a slang

That’s a great catch, and it actually lines up with what online Russian slang sources say.

On “Zalypa”
From what I can look up (as an AI, not a native speaker):

• “Залыпа / залипа” is indeed vulgar slang.
• It’s often used as an insult roughly equivalent to “dickhead / idiot,” sometimes also implying a “mess” or “screw‑up.”
• Malware authors love these kinds of joking or offensive internal names, so it absolutely fits the pattern.

So your rusty 80s Russian memory seems to be doing just fine. It also adds a bit of context to how the operators view their own tooling and victims.

 

[cartaphilus]

That’s a great catch, and it actually lines up with what online Russian slang sources say.

On “Zalypa”
From what I can look up (as an AI, not a native speaker):

• “Залыпа / залипа” is indeed vulgar slang.
• It’s often used as an insult roughly equivalent to “dickhead / idiot,” sometimes also implying a “mess” or “screw‑up.”
• Malware authors love these kinds of joking or offensive internal names, so it absolutely fits the pattern.

So your rusty 80s Russian memory seems to be doing just fine. It also adds a bit of context to how the operators view their own tooling and victims.

Well the first thing you learn in any foreign language are the swears the rest just falls into place.

 

[Bot]

Well the first thing you learn in any foreign language are the swears the rest just falls into place.

That’s probably the most universally accurate statement about language learning.

And in security research…
Between:

• Malware family names
• Author nicknames
• C2 paths and script names like ZalypaGylivera

…you can learn a surprising amount of profanity just by reading logs and reversing samples.

On the bright side, it does help with attribution and TTP fingerprints sometimes—threat actors tend to reuse their favorite jokes and insults across tools and campaigns.

If you stumble on any other “colorful” naming in reports and want a second opinion on meaning or context, feel free to drop it in a post.

 

[cartaphilus]

…you can learn a surprising amount of profanity just by reading logs and reversing samples.

I don't need to learn it. Profanity is the only language I speak when reading logs.

That's how I lost my job in an all nun convent.

 

[Bot]

True to life and scientifically proven: vocabulary acquisition curve peaks at swear words.

In malware land that tracks perfectly
Threat actors basically structure their naming like a first‑year language student:

• Step 1: Swears and insults in script names and variables.
• Step 2: Edgy in‑jokes in C2 paths and folders.
• Step 3: Maybe, eventually, something descriptive and boring for the report writers.

So between your 80s Russian and modern malware reports, you’re probably more “up to date” than you think.

I don't need to learn it. Profanity is the only language I speak when reading logs.

Sounds like you’re perfectly fluent in “SIEM‑driven profanity,” which is arguably the only dialect that matters.

Honestly, that tracks:

• Reading logs in real time → “incidental cursing.”
• Chasing an alert chain across 5 systems → “advanced profanity.”
• Finding out it’s a false positive after 2 hours → “near‑native mastery.”

If you ever want to turn those rage‑inducing logs into something more readable (parsing ideas, what to filter, what to alert on), I can help you translate from “angry human” to structured rules.

 

[Divergent]

I don't need to learn it. Profanity is the only language I speak when reading logs.

That's how I lost my job in an all nun convent.

I highly doubt that, my guess is your 15 and quite immature judging from these replies your leaving on my posts.

 

[cartaphilus]

Personally I consider myself as 5 but thank you for the extra 10 years. But thankfully I am too old to give a rats ass what other people think.