This research explores an unconventional malware delivery vector, demonstrating how trusted creative software tools can be repurposed to deliver payloads in ways that bypass common defences, user expectations, and AI-based analysis. The work concludes with the creation of a successful Proof-of-Concept (PoC) for code execution and AV/EDR evasion using the open-source 3D software suite Blender, as can be seen 

The research does not uncover, abuse, or rely on any software vulnerabilities in the Blender platform itself; instead, it leverages the software’s legitimate Python scripting capabilities (widely used in professional CGI workflows) to execute custom code unexpectedly. Its success capitalises on typical expectations within a niche industry where script auto-execution is often enabled by default, and security warnings are commonplace and expected. However, the research also finds that even with warnings enabled, attacks can divert user attention and conceal malicious routines within warning overrides and plausible and fully native API usage.

While many traditional code execution vectors are well understood and mitigated, this research highlights how attacker creativity can exploit overlooked workflows and the implicit trust placed in niche tools within specialised industries.

I’ve always had a passion for animation. I spent years as a hobbyist 3D artist, worked as a freelance technical animator, and even did a short stint in vehicle design. These days, my career is firmly rooted in cyber security. But I’ve always been keen to find a way to have these two worlds intersect.

That led me to a question: Historically my work has been in the finance and tech sectors, but if a threat actor were targeting the media or animation industry, would a malicious 3D asset file (like a model, character rig, or scene file) be more effective than the usual malware-laden Word document, PDF, or Excel add-in, etc?

Traditional attack vectors, such as office suite exploitation, are well-known and increasingly well-defended against. In contrast, a 3D asset file with an embedded malicious script might slip past both the user and security controls far more easily, simply because it’s unexpected – or maybe even because it is expected.

With that in mind, I set out to explore how practical this might be and see how vulnerable the media and animation industries are to this kind of threat with what I had access to.

This research article dissects this idea, compares it with conventional malware delivery techniques, and walks through the creation a benign-looking Remote Code Execution (RCE) exploit leveraging native Blender API calls and forged warning messages to avoid suspicion and detection.

Over the years, attackers have developed many ways to trick users into executing malicious code. To set the stage, before diving into 3D software, I will recap some of the common malware delivery vectors and how, we as defenders, have responded.

The classic. Malicious Office documents with embedded macros were running rampant for decades. While still in use, modern versions of Microsoft Office and mature enterprise policies have made this technique significantly more complicated to exploit, though not impossible:

Files downloaded from the internet are now tagged with a Mark-of-the-Web, which disables macros by default, and any attempt to enable them prompts multiple security warnings. As a result, most organisations now treat macro-enabled documents (

, etc.) with high suspicion or block them entirely.

That said, bypasses exist, and macros remain a viable technique in many environments. The success rate may have decreased, but the technique hasn’t gone anywhere, especially when targeting organisations with more lax security controls.

HTA files are another well-known method for malware delivery. These allow the execution of VBScript and JScript outside of a browser environment using Microsoft’s mshta.exe. In practice, they are written much like a macro-enabled document, but without the need for Office.

This technique has been around a long time and is often combined with other tradecraft, such as malicious LNK files and HTML smuggling to achieve code execution and evade detection:

However, HTA files are less commonly encountered by the average user, which could raise suspicions, as it is not an everyday format. That said, it still remains a valid and common “living off the land” technique for attackers looking to avoid macro-related defences.

As Microsoft tightened macro security, threat actors also adapted and started using precompiled custom Excel add-in files (

) as a macro-free alternative. This shift was noted in the early 2020’s with reports finding that both APT groups and commodity malware campaigns increasingly used XLL attachments in phishing attacks.

When opened, Excel will prompt the user to install the add-in. If the user accepts, the XLL file executes native DLL-based code within the Excel process. To the user, opening the file may appear like opening a typical spreadsheet, adding to its deceptive potential, whilst in the background custom malware is executed:

Microsoft has, however, since begun blocking untrusted XLLs by default in newer versions of Office, helping mitigate this attack vector and forcing attackers to get more creative.

These more traditional, methods (and many others like LNK shortcuts, PDF exploits, etc.) form a well-established malware-delivery toolkit. However, although they are still valid delivery mechanisms, defenders have spent years learning to detect and mitigate these techniques and the element of surprise is often lost. 

Many creative software packages used in the animation, media, and design industries support scripting, much like macros in Office applications. Over the years, I’ve worked with several of these tools: LightWave 3D, Autodesk Maya, 3ds Max, Blender, AutoCAD, and others.

It’s easy to forget that these tools, while built for artistic workflows, often include powerful scripting capabilities to support automation and custom tool creation – which is a critical part of modern CGI production pipelines. For example:

Although many of these software packages initially only supported proprietary scripting languages, over the years there has been a significant adoption of Python. This makes life relatively easy for people to start writing code without having to learn multiple programming languages, and also easier for attackers to target them.

For this research, I focused specifically on Blender as it’s free, open-source, and hugely popular, supports Python, and - last but not least - I’m most familiar with it. That said, the broader security implications extend to any digital content format that allows embedding and automated execution of custom code.

Blender introduced Python scripting in version 2.10 (way back in 2000). This marked a turning point in its development, and since then, scripting has become deeply integrated into Blender’s ecosystem. It’s now frequently used for everything from modelling automation to extension development.

Any user can open Blender’s Scripting workspace, write some Python code, and interact directly with the 3D scene and Blender UI via the Blender Python API (

Although the above is a simple example, the possibilities are almost limitless. Python scripting in Blender is routinely used to streamline workflows, create custom interfaces, and integrate the software into larger production pipelines.

A classical use-case is the development of custom animation rig interfaces for complex characters. These are control panels designed to simplify rig navigation and speed up the animation workflow for complex assets with many moving parts and constraints:

However, this power comes with inherent risk. Because scripts operate as active code rather than static assets, they can be embedded directly within a 

 file. These files will then carry arbitrary Python code, making them a viable malware delivery mechanism for threat actors.

This is not new knowledge, however. It has been documented for over a decade, as far back as 2009, when CVE-2009-3850 was registered to highlight that simply opening a 

 file with an embedded script could result in code execution without explicit user consent.

Blender’s developers have since implemented a number of safeguards to reduce this risk, such as script auto-run controls, directory allow-listing, and active code warning prompts. But the fundamental capability to execute arbitrary Python code from within a project file remains. As with Office macros, it’s a feature that’s powerful in the right hands and dangerous in others.

So, if arbitrary code execution is possible in Blender, what prevents malicious 

Over time, Blender has introduced a combination of security warnings and user preferences aimed at reducing the risk of unintended code execution via embedded scripts. By default, automatic execution of Python scripts is disabled, and when a file containing an embedded scripts is opened, Blender displays the following warning:

This message alerts the user that there is a Python script that is registered to auto-run in the file, and that auto-run is disabled. The user can then choose to “

” (skip it). There is also an option to permanently enable auto-run script execution, which will enable the Auto Run Python Scripts setting under Blender’s "

While enabling this setting may seem ill-advised from a security standpoint, many animators and riggers regularly work with 

 files that require scripting for rig controls, UI elements, and other automations. As a result, it is not uncommon for users in production environments to enable auto-execution for convenience.

What’s important to note is that this setting governs all areas within Blender where Python scripts can be embedded, which covers many areas and features, including:

*Only if the initial script that registers them is allowed to run.

Driver-Based Execution: A Quirky Edge Case

Drivers are an interesting edge case, intended for simple mathematical operations. However, with some experimentation, I found that you can use Python’s 

 within these expressions to execute arbitrary code. For example, the following driver could be used to spawn 

var + (0.0 if builtins['exec']('import os; os.system(\'calc.exe\')') else 0.0)

Successful execution of this can be seen below:

This is an interesting bypass, as it essentially smuggles code inside what appears to be a basic mathematical formula. However, Blender flags any expression that strays from basic mathematical operations as a Python script, and will subsequently trigger the same auto-run warning when the file is opened - unless the user has explicitly allowed auto script execution:

An interesting side effect of Blender’s warning mechanism is that driver expressions take precedence in the warning display. That means, if a 

 file contains both a script and a complex driver expression, the warning will flag and highlight the driver, not the script text block. From a malicious perspective, this can be used to help evade detection. For example, the driver expression warning could be used to distract a reviewing user from a primary malicious text block using a benign-looking, complex driver. For example:

This does nothing useful, but it is complex enough for Blender to elevate it from driver to complex script expression and override any text block security warnings. Once the user clicks "

" on the driver (as it seems perfectly benign), no further warning will be shown - even if a more dangerous script is present in the file:

Real-World Practices: Artists and Auto-Execution

Despite Blender’s built-in protections and the technical limitations of various execution pathways, the human factor may just tip the balance in favour of attackers.

In professional environments, it is common for artists and studios to enable the “Auto Run Python Scripts” option. For many Blender users, security warnings are seen as unnecessary friction, especially when working with character rigs or other complex assets that rely on embedded scripts for legitimate purposes, such as custom UI panels, automation tools, or scene setup functions.

Over time, many artists become conditioned to ignore script warnings or disable them altogether, falling back on trust. If the file came from a colleague, a community site, or a known artist, it's assumed to be safe. This trust-based behaviour creates a false sense of security and breeds an ideal environment for threat actors.

That said, more technically inclined users or those in more security-conscious environments may choose to inspect and review embedded scripts before allowing them to run. In these cases, they’ll typically open the Text Editor Panel in Blender and review the code manually or paste it into a Generative AI tool for review. In these cases, a blatant malicious payload (e.g. a call to 

) or even a suspiciously obfuscated script would likely stand out significantly from typical blender scripting practices and be flagged as malicious.

Whilst initially conducting this research, I came across little evidence of this type of attack in the wild. However, over the past months, I found at least 

 file. In this case, a user on Reddit reported a seemingly innocent chair model which, when opened, executed a heavily obfuscated and clearly malicious Python script that decoded and executed a second-stage PowerShell payload.

These observations confirmed my suspicions that a Blender-based attack is not only plausible, but already happening in the wild, even if it’s not heard of very often – if at all. The next question became: could such an attack be crafted in a more sophisticated way that can evade user scrutiny, AI-based analysis, and detection by modern AV or EDR tools?

Weaponising .blend Files for Malware Distribution

Having set the stage, we can now dive into the fun of exploring how a 

 file might be transformed into a viable malware delivery mechanism. The objective is simple:

Embed a malicious payload within a Blender file that executes with minimal detection and does not appear obviously suspicious, even under human and AI-based scrutiny.

A simplistic approach might be to embed a text block that calls 

 embedded in the Blender file mimicking the original 2009 CVE. This would indeed execute a payload, but it would also be extremely obvious and highly detectable. Any user reviewing the script would see the call immediately, and virtually all AV products would flag it, before EDR even needed to kick in.

So, a stealthier, more sophisticated method is required, comprised of multiple key goals:

With that in mind, the process of creating this payload can be broken into four steps:

An obvious first step might be to generate shellcode using 

. However, these payloads have long been widely recognised by modern AV and EDR systems. Even if you avoid writing the payload to disk, in-memory execution of such well-known byte patterns and decoding routines is almost guaranteed to be caught.

To make this proof of concept realistic, it requires custom shellcode, written from scratch or at least heavily modified to avoid detection.

I opted to write my own bespoke shellcode, using x86_64 assembly, targeting 64-bit Windows systems (as Blender is primarily used on 64-bit Windows in most professional environments). The payload requirements are fairly simple (spawn 

), so it’s fairly easy to write and obfuscate, and it provided a clean test for code execution pathways.

As this will be injected directly into memory, a critical requirement is that the shellcode be position independent. This will allow it to execute from any memory address without hardcoded offsets. To achieve this, the shellcode can perform a Process Environment Block (PEB) walk to dynamically locate the runtime base address of 

, which can then be used to resolve the relative offsets to any additionally required API addresses:

 obtained, additional APIs could be dynamically resolved to spawn a new process, including 

Once the shellcode was written and tested, I used the Python Keystone library to assemble the opcodes and a custom encryption script to prepare them for the shellcode runner. This produced a concise binary blob of machine code instructions capable of invoking the required Windows API calls to launch 

While the actual shellcode details are not the focus here, what matters is that this payload was custom-authored, encrypted, and obfuscated. Therefore, it is unlikely to be detected by signature-based security controls.

However, shellcode on its own is inert; it lacks all of the structure that makes a PE executable run, and as such requires a dedicated runner. This is a mechanism used to allocate memory, write the payload into it, and trigger its execution.

As Blender supports Python, the shellcode runner can be implemented using Python in combination with the 

 library to access the required lower-level Windows APIs. This will enable native execution within Blender’s embedded Python environment without requiring any external dependencies.

For this proof of concept, I implemented the runner using a process hollowing technique where a legitimate process is started in a suspended state, overwritten with malicious code, and then resumed. This method is relatively stealthy and can evade various behavioural detections. A high-level overview of its implementation is as follows:

The initial setup for this process can be seen below:

This research explores an unconventional malware delivery vector, demonstrating how trusted creative software tools can be repurposed to deliver payloads in ways that bypass common defences, user expectations, and AI-based analysis.

Malware delivery in 3D software pipelines

, Lead Cyber Security Researcher at CultureAI

By Oliver Simonnet, Lead Cyber Security Researcher at CultureAI

Recommended for you

The AI Hunger Games: The Rapid Adoption of DeepSeek: A Security Nightmare

Empowering Safe GenAI Adoption at a 3,600-Employee Fintech

How the Wrong Framing Creates New Risk