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.

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

Pixels, Polygons, and Payloads

In April 2025, large retailers were all targeted by cyber attacks that caused disruption across their services. Although attribution is still being confirmed, indicators strongly link these attacks to Scattered Spider, a group known for aggressive, human-centric tactics and high-profile breaches.

This post is not an incident breakdown for each retailer. Instead, it uses these events as a real-world case study to examine Scattered Spider - a modern cyber threat actor that doesn’t rely on technical exploits, but on manipulating people – as their operations highlight the urgent need for security strategies that go beyond traditional defences and training.

At the end of April 2025, three major UK retailers were hit by various cyber attacks. Although not officially attributed, these attacks have been linked to a hacking collective known as “Scattered Spider” and use of the “DragonForce” ransomware.

The attack on M&S (a retailer known for selling food, clothing, and home goods in the UK) started covertly, with initial access gained in February 2025 being used to exfiltrate their 

 Active Directory Database file (a file containing employee password hashes). In late April the attackers then deployed the 

 ransomware on M&S servers, encrypting critical systems and resulting in the M&S website being unable to take online orders. This attack cost the company an estimated 

, removing an estimated £500–700M off its market value and preventing the company from 

The Co-op Group, which operates thousands of grocery stores and other businesses in the UK, also discovered a similar attack in late April. A social engineering attack reportedly allowed the threat actors to 

 before breaching the network. This resulted in attackers gaining access to the 

 which includes information such as membership names and contact details. In response, the Co-op pre-emptively 

 to contain the threat. This included partially disabling internet access, urging employees to keep their cameras on during meetings, not recording or transcribing calls, and asking staff to verify that all meeting participants were authorised Co-op staff.

Around the same time at the M&S and Co-Op attacks, Harrods (a UK department store) revealed that it detected an 

. In response Harrods temporarily restricted internet access and reportedly prevented any major disruption suggesting that the attacker was blocked before they could do serious damage.

“Scattered Spider” is a name given to a loose collection of English-speaking hackers with members affiliated with the cybercriminal collective “The Com”. This group – also tracked as “UNC3944” (Google) and “Octo Tempest” (Microsoft) – is known for its focus on exploiting people rather than technologies using aggressive social engineering tactics and has been linked to other high-profile breaches such as the 2024 attacks on 

In November 2024, the US Department of Justice gave an insight into Scattered Spider’s personnel when it charged 

 over the targeting of various unnamed American companies with “phishing” text messages. This revealed that the group appeared to consist of predominantly young native-English speakers, operating out of the UK and US – in contrast to many other ransomware groups that predominantly operate out of Eastern Europe, Asia, and Russia.

“DragonForce” is the name given to a pro-Palestine hacktivist group allegedly based in Malaysia operating out of the Asia-Pacific region and the US. In recent times, it is believed that the group has expanded into ransomware operations - 

 of a ransomware-as-a-service (RaaS) set of tools that is known to be used by Scattered Spider.

Tactics, Techniques, and Procedures (TTPs)

Although direct attribution has not been confirmed, what ties Scattered Spider operations together are the tactics used. One of their attributes is that they specialise in targeting the human element of organisations, manipulating and deceiving people rather than exploiting technology. This often results in attacks heavily involving a mix of phishing, phone-based deception, and abuse of multi-factor authentication to infiltrate organisations.

Attack Waves – Scattered Spider operations typically occur in 

 against prominent brands in specific industries in order to generate media attention before shifting to other targets.

Explore and understand these threats more using the 

These incidents all have one thing in common: the exploitation of humans over tech. Whether it’s an employee interacting with a fake login page or a member of the help-desk team being manipulated over a phone call or text, the attackers succeeded by manipulating people. No 0-day exploit or overly technical hack, just the abuse of human behaviour to get in.

These types of threat actors are both concerning and fascinating. Concerning, because every organisation relies on humans who can make mistakes. Fascinating, because it means improving security isn’t just about buying the latest tech or training. It’s about protecting your people.

These attacks re-emphasise the importance of human risk management in modern cybersecurity. Groups like Scattered Spider show that even the most robust technical defences can be bypassed through social engineering and the exploitation of human behaviour, resulting in financial losses, operational disruption, and reputational damage.

However, by developing or onboarding proactive, human-centric security strategies, organisations can reduce their likelihood of falling victim to these attacks in the future. This means going beyond awareness training and providing our users with tools that help them recognise, prevent, and respond to threats in real time.

Perhaps one day we can stop viewing employees as the “weakest link” in cybersecurity. With the right support and risk management technologies, people might just become one of our strongest lines of defence.

bleepingcomputer.com - Marks & Spencer breach linked to Scattered Spider

https://www.bleepingcomputer.com/news/security/marks-and-spencer-breach-linked-to-scattered-spider-ransomware-attack

independent.co.uk - M&S hackers tricked IT help desk workers to access company systems, says report

https://www.independent.co.uk/news/business/m-s-coop-hack-scattered-spider-it-worker-b2745218.html

independent.co.uk - Wave of retailer hacking incidents ‘a wake-up call’, minister to say

https://www.independent.co.uk/news/uk/politics/pat-mcfadden-government-marks-spencer-spencer-manchester-b2744030.html

thehackernews.com – RansomHub Went Dark April 1; DragonForce Claimed Control

https://thehackernews.com/2025/04/ransomhub-went-dark-april-1-affiliates.html

sentinelone.com - DragonForce Ransomware Gang

https://www.sentinelone.com/blog/dragonforce-ransomware-gang-from-hacktivists-to-high-street-extortionists/

https://cloud.google.com/blog/topics/threat-intelligence/unc3944-proactive-hardening-recommendations

sans.org - Defending Against SCATTERED SPIDER and The Com

https://www.sans.org/blog/defending-against-scattered-spider-and-the-com-with-cybercrime-intelligence/

infosecurity-magazine.com - Inside DragonForce

https://www.infosecurity-magazine.com/news/dragonforce-goup-ms-coop-harrods/

theguardian.com - M&S cyber-attack linked to hacking group Scattered Spider

https://www.theguardian.com/business/2025/apr/29/m-and-s-cyber-attack-linked-to-hacking-group-scattered-spider

bbc.co.uk - Co-op cyber attack affects customer data, firm admits

theguardian.com - How ‘native English’ Scattered Spider group linked to M&S attack operate

https://www.theguardian.com/technology/2025/may/01/how-native-english-scattered-spider-group-linked-to-ms-attack-operate

therecord.media - CISA, FBI warn of Scattered Spider expertise with social engineering

https://therecord.media/cisa-fbi-warn-of-scattered-spider-cybercrime-group

https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-320a

In April 2025, large retailers were targeted by cyber attacks that caused disruption across their services. Although attribution is still being confirmed, indicators strongly link these attacks to Scattered Spider, a group known for aggressive, human-centric tactics and high-profile breaches.

A Case Study in Human-Centric Cyber Threats

Scattered Spider and DragonForce

Autonomous AI agents - known as Computer-Using Agents (CUAs) - are no longer science fiction! These systems can browse websites, interact with applications, and carry out tasks on their own. While intended to increase productivity, they can already be repurposed by threat actors for malicious use. In this post we will explore the cyber security implications of CUAs, showing how tools like OpenAI’s Operator can be manipulated to perform real-world attacks, and how we should prepare to defend against it.

Computer-Using Agents (CUAs) are a new chapter in the incredibly rapid evolution of AI. While traditional Large Language Models (LLMs) focus on generating text, CUAs take it a step further. These agents can interact with software, browse the internet, and carry out complex tasks on a user’s behalf through basic natural language instructions.

This sudden increase in AI capability comes with the promise of major productivity gains. But just as has been the case with any new and powerful tool, 

, and in the case of CUAs, this extends directly into the cyber security domain.

In this post, we explore how OpenAI’s Operator, and other emerging tools from Google, Anthropic, and Meta, can be weaponised by threat actors. Instead of focusing on theoretical concerns, we will dive into practical and verifiable examples of CUAs being manipulated to performing automated reconnaissance, credential abuse, phishing, and application exploitation.

In this post we will focus on OpenAI’s Operator, as it has drawn a lot of attention with its sandboxed browser environment and autonomous behaviour. However, although it’s new and shiny, it is not the only tool out there redefining what AI agents can do! There are multiple other major vendors releasing - or actively testing - similar technologies, each with their own unique benefits and security implications:

Although these tools vary in their technical architecture and intended use cases, there is a clear underlying trend:

Many AI technologies are now capable of autonomously performing real-world actions. And those actions, whether helpful or harmful, can be triggered through nothing more than a simple text prompt.

The idea that these technologies can be abused to perform malicious actions is not just theoretical. Our - and other’s - security research has already demonstrated that prompt injection, identity attacks, phishing, and exploitation is possible using these new autonomous systems. To demonstrate this, we tasked Operator with completing a number of malicious tasks, gradually increasing the technical complexity of each one.

One of our initial test cases was to investigate how CUAs could be used to automate reconnaissance, information gathering, and analysis. Analysis was key as we've been able to automate information gathering and scraping for a while in various forms. However, simultaneous automated analysis and contextualisation of that information is different.

Using the following prompt, we were able to demonstrate how Operator could automatically access LinkedIn and identify a number of CultureAI employees who had joined within the last 90-days. The prompt being as simple as:

Operator responded with a precise list of new starters, complete with names, roles, and start dates extracted by analysing recent company posts and profile updates.

While this may seem like a benign request for information, it demonstrates the speed and scale with which an attacker could now automate reconnaissance and analysis at scale. What would once require considerable time and manual research, can now be done by an AI in minutes:

This information could subsequently be used by a malicious AI or threat actor to target these users with tailored phishing campaigns – as documented in our 

Another area where CUAs enhance attacker capabilities is with identity attacks. Let's consider credential stuffing - where attackers test known username and password pairs across multiple services – and dictionary attacks, which cycle through known or common passwords to brute-force access. These techniques aren’t new, but CUAs change how easily they can be executed.

Traditionally, attackers would rely on custom tooling and automation frameworks to perform these tasks, but this required infrastructure creation, ongoing maintenance, and constant updates to evade detection, rate limiting, and CAPTCHA defences. CUAs like Operator remove the need for such technical and manual overhead. They are capable of navigating login pages, entering credentials, responding to prompts, completing CAPTCHAs, and logging results as if they are humans.

To validate this, we instructed Operator to test the login flows for several common SaaS platforms using a target email address and a public list of known compromised passwords:

Operator completed the various login attempts using the supplied credentials and reported back, confirming it had gained access to one of the accounts:  

This test was limited to a few passwords from an arbitrarily long list across three SaaS solutions. However, now consider how this process could be replicated and scaled across thousands of accounts simultaneously using multiple agents. What was once a relatively noisy and detectable attack could now be carried out at scale from multiple sources.

While phishing automation is a well-worn concept, CUAs like Operator elevate it considerably. In a test inspired by the full end-to-end proof-of-concept by 

, we explored how an AI agent could autonomously craft and deliver a malicious payload without any additional human guidance beyond the initial prompt. The prompt used was:

Operator executed every instruction, end-to-end, returning this summary of its actions:

Creation of the email could be seen in the Operator browser window as it worked:

When creating the payload sent along with his email, Operator installed the Google Workspace Text Editor plugin and used it to write a basic bash script that printed system information:

While this final payload sent does not actually exfiltrate any data, the full process demonstrates the agent’s ability to automatically interpret instructions, solve problems, generate code, and perform complex multi-step tasks based on simple commands without issue.

CUAs for Vulnerability Discovery and Exploitation

Beyond social engineering and identity attacks, CUAs have also proven their ability to automate vulnerability discovery and exploitation. In another prompt, we instructed Operator to test access to a website, check for SQL injection, and upload a web shell to get code execution, if possible:

 without issues, including the successful completion of a CAPTCHA presented when accessing the website:

During task execution, Operator initially failed to bypass the login using SQL injection, however after multiple attempts generating different payloads, it was able to gain access to the site as the “admin” user:

While this SQL injection was relatively basic by human standards, the Agent's ability to identify it and test multiple generated payloads to gain access continued to demonstrate its strong problem-solving capabilities, without the need for additional user input

Following this, the Agent then made several attempts to upload a web shell via the application’s notes feature. It initially submitted a PHP payload without a file extension, which failed to execute. However, after recognising this, it returned to the notes form and uploaded a second web shell - this time with 

 extension - successfully achieving code execution:

This demonstrated how, even when given light instructions, CUAs like Operator can complete fairly complex multi-step exploitation activities, including payload creation, delivery, and post-exploit verification.

So, with those test cases performed, it may seem like it's super easy to abuse these technologies and set them on their merry way to cause the AI apocalypse, right? But is it?

Thankfully - for us humans - it's not as stress free as it may seem, and systems like Operator do include some security controls. These are however just as inconsistent as they can be frustrating from the perspective of a threat actor.

I’d say about 75% of the time, Operator frequently paused execution, asked for additional user input, or refused to comply with certain instructions - such as complete CAPTCAHs, perform automated logins, and generate credentials. It also often required that the user monitor sensitive actions, like the authenticated access to email and social media accounts.

These controls can rapidly turn the dream of an automated task, saving you time, into a tedious waste of time and energy as you monitor the AI - just in case it stops. (Though I suppose that’s karma if you’re trying to use it for malicious purposes!)

That said, prompt injection is still a major weakness, and the tasks may succeed or fail depending on slight variations in phrasing and tone - including using creds and completing CAPTCHAs:

As attacker methodologies and capabilities improve, the defensive controls enforced on these technologies will need to mature rapidly to keep up. However, we ultimately expect that attackers will shift from legitimate platforms to their own underground custom CUA technologies with no restrictions, as we have seen with 

Although Operator includes multiple security controls designed to prevent, detect, and limit malicious behaviour, we sometimes found that simply opening a new tab and reissuing the exact same prompt would result in the AI ignoring its previous concerns and complete the full task without question anyway.

With that in mind, I’ve included a few examples where Operator’s security controls initially interfered with task completion, but where we ultimately bypassed it during our research:

Some attempts to have Operator perform tasks such as account login, SQL injection, or CAPTCHA completion, resulted in it refusing to comply because these actions should be performed manually, or were seen as malicious:

However, other times it was perfectly happy to complete these tasks without user interaction and without making changes to the original prompt.

I think opening a new Tab is going to be the AI equivalent of the classic “have you tried turning it off and on again”.

Similarly, sometimes, even though it was provided with credentials, it refused to authenticate and instead requested that the user take control and manually complete the login:

Despite this initial concern, in other instances it was happy to perform the login autonomously using the same prompt, and in other cases it was bypassed after making minor modifications to the prompt.

Part way through some tasks Operator may pause and request user input to confirm what the user wants it to do – despite telling it to complete all tasks without asking for input:  

However, after a number of additional attempts it ultimately completed these steps without asking for my input anymore – perhaps it just got fed up of the back and forth. AI fatiguing!

Often, as operator is working it won’t fully stop its task execution when something suspicious is found, but instead temporarily pause execution and present the user with a warning. This was by far the most frequent issue we found with manipulating Operator to perform malicious tasks.

This typically happened when the AI found itself performing particularly sensitive or dangerous tasks, such as authenticated account access, logins observed, passwords detected, or malicious code identified on the screen.

However, the user can simply click to mark the task as safe, and Operator will carry on with whatever it was doing.

This control was very inconsistent, and many times identical tasks and execution flows that previously raised a risk, no longer would, even though the information displayed, and task performed, were predominantly the same – or sometimes identical.

Computer-Using Agents like OpenAI’s Operator aren’t just productivity boosters - they’re potential digital threat actors. When used legitimately, they can automate real work and make life easier, but in the wrong hands, they can be let loose to identify targets, compromise user accounts, discover vulnerabilities, and interact with victims.

Our research shows that these agents are already capable of credential abuse, phishing attacks, malware delivery, and even vulnerability exploitation. And while current capabilities remain partially limited, the potential for large-scale abuse in the immediate future is very real.

Organisations adopting or creating CUAs should treat them like any high-risk component, and subject them to robust security controls and strict scrutiny. At a minimum:  

While it’s not yet completely practical for attackers to fully retire and simply automate large-scale, highly-complex, end-to-end attacks without any human input or oversight, the immediate threat of this is not theoretical. The AI is here, the abuse is possible, and our security teams and technologies must not only catch up, but keep up, and fast.

https://openai.com/index/introducing-operator/

https://deepmind.google/technologies/project-mariner/

https://www.anthropic.com/news/3-5-models-and-computer-use

culture.ai - You're Not My Supervisor! Researching My Own New Starter Scam

https://www.culture.ai/resources/blog/researching-my-own-new-starter-scam

pushsecurity.com – How new AI agents will transform credential stuffing attacks

https://pushsecurity.com/blog/how-new-ai-agents-will-transform-credential-stuffing-attacks/

Computer-Using Agents (CUAs), while intended to increase productivity, can be repurposed by threat actors for malicious use. In this post we will explore the cyber security implications of CUAs, showing how tools like OpenAI’s Operator can be manipulated to perform real-world attacks, and how we should prepare to defend against it.

Blog & Stories

🚀Stay in the loop

Pixels, Polygons, and Payloads:

Scattered Spider and DragonForce:

The Offensive Potential of Computer-Using Agents

You're Not My Supervisor!

Introducing The Human Threat Map:

Trouble Brewing -

The AI Hunger Games:

Empowering Safe GenAI Adoption at a 3,600-Employee Fintech — And Stopping 20+ Data Leaks a Day

How an International Law Firm Prevented 98% of High-Risk GenAI Submissions Without Locking Down Innovation

How a Digital Bank Reduced Shadow AI Risk by 80% - Without Blocking Innovation

You might also like

Introducing The Human Threat Map:

Trouble Brewing -

The AI Hunger Games: