Prompt Parkour: How I Tricked Claude into Building Ransomware

Even when AI systems clearly prohibit malicious use, built-in guardrails can still be circumvented. This experiment was designed to see if AI could be used to develop ransomware. AI was successfully used to develop ransomware.  

The key was to break our requests into smaller, less obvious steps, like adding one Lego brick at a time in what we call Prompt Parkour. The requests were framed as part of a legitimate CTF. That was enough to get Claude to assist in building a controlled ransomware sample, despite safeguards designed to prevent it.  

The takeaway isn’t that the protections don’t exist, but that they can be easily sidestepped with the right approach. 

More broadly, this reflects a growing reality in AI security: 

• Guardrails don’t always hold under pressure. Intent can be influenced by how problems are framed 
• AI makes complex workflows easier to assemble, even when individual steps seem harmless 
• New attack paths are emerging. Context and environment can shape model behavior in unexpected ways 
• Attackers are getting faster and more efficient. AI is accelerating development cycles for everyone, not just for legitimate use cases 

Why it matters: AI isn’t just a productivity tool for defenders. It’s increasingly useful to attackers as well. Rather than relying on AI safety mechanisms to stop misuse, organizations should assume these capabilities will be leveraged in the wild and double down on the fundamentals that still work. 

Continue reading to see how this worked for me.

Framing the experiment 

As a Security Engineer on Varonis’ Forensics team, my focus has recently been on enabling the effective use of Velociraptor for the Managed Data Detection and Response (MDDR) team.

Recently, I had the opportunity to develop a few challenges for the OSMOSIS Association OSINT CTF, so I put together a set of blue team-focused challenges that center on a fictitious ransomware investigation.  

The goal: Have contestants identify and reverse engineer a fake ransomware sample to assist a fictitious organization in recovering from a ransomware attack. 

Velociraptor enables investigators to collect forensic evidence from compromised devices, helping them quickly determine the scope, origin, and impact of a malware infection and support rapid triage during active incidents. These collections are typically packaged as zip files that contain forensic artifacts collected from affected hosts. 

For the CTF, I needed to generate a realistic ransomware sample that could produce observable effects within a Velociraptor collection. To achieve this, I explored whether Claude could handle the heavy lifting of creating a convincing (yet controlled) malicious sample for the challenge. 

Explore more from Varonis Threat Labs.

Learn more

Claude's safeguards 

The Cyber Verification Program (CVP) relaxes safeguards slightly for cybersecurity researchers, however I am not enrolled. Even if I was in CVP, the guidelines clearly state:  

Prohibited use: Cybersecurity activities that are almost always used maliciously and have little to no legitimate defensive application such as mass data exfiltration or ransomware code development. These are blocked by default and not subject to adjustment via self-serve application through the Cyber Verification Program. 

According to Anthropic’s Acceptable Use Policy, Claude cannot be used to “Create or distribute malware, ransomware, or other types of malicious code.” Safeguards are in place to prevent this type of potentially malicious activity.  

Claude’s real-time cyber safeguards should detect and block any attempt to develop ransomware in accordance with Anthropic’s AUP. I ran into some safeguards in Claude, but I was able to sidestep them by carefully framing my requests and injecting additional context into the conversation via the folder path. 

Starting innocuously 

I knew I’d hit a wall if I asked Claude directly to develop ransomware, so I broke the task into small, innocuous steps I assumed Claude would not object to. Here’s what happened:

I hit the first safeguard when asking for ways to collect a unique device-bound identifier for the target system. My aim was to restrict execution to a specific system, to prevent contestants from accidentally encrypting their own workstations. This is a common anti-analysis technique, and Claude’s safeguards worked to prevent it. 

Trusting the path name 

I assumed Claude would give me an error if I asked it to do any more work on this project, so I implemented the keyserver and required keyserver interactions by myself. The next day  

I tried again to get it to help with an obfuscation task.

This is the interesting part: Claude stopped and asked me for clarity on the intent of this project. It correctly flagged that I was building ransomware, but I’d named the parent folder `osmosis/ctf.2026.`Claude trusted that my use case was legitimate and assisted with the implementation because of the context inferred from the environment. 

When Claude attempted to implement the obfuscated key selection logic, another guardrail kicked in. The safeguards denied three separate requests as violations of the AUP. When I gave up and asked Claude to only provide the build command, it went back and implemented the method that the safeguards had blocked, then it provided the build command I asked for when it was done.  

Impact 

I executed the final sample in a Windows sandbox populated with ~100GB of mixed data, including PDFs, Microsoft Office documents, images, and plaintext files. The ransomware encrypted the entire dataset in a bit less than five minutes - fast enough to simulate a realistic, disruptive event even in a controlled environment. The CTF scenario was intentionally designed to be recoverable: contestants could exploit the key server to obtain the encryption key, reverse engineer the sample, and build a decryptor to restore the data. 

What stood out wasn’t just that the sample worked - it’s how little time it took to get there. End-to-end, the build and deployment process took around eight hours, largely due to Claude’s assistance across individual components. For context, I’d originally estimated this would take closer to a week or two (~40 hours) without AI support, which puts the time savings at roughly an 80% reduction in effort. 

With only minor adjustments, this sample could have been meaningfully weaponized. That’s the bigger takeaway: AI doesn’t need to directly generate “malware” to be impactful—it just needs to accelerate the development of individual components enough that the overall barrier to entry drops substantially. 

While this focused on code generation, similar weaknesses are showing up elsewhere in AI systems. SearchLeak (CVE-2026-42824) and Reprompt show how attackers can manipulate AI systems into acting on their behalf.  

• In SearchLeak, a crafted link could inject instructions directly into Copilot and turn it into a one-click data exfiltration channel, pulling emails, documents, and even MFA codes from a user’s environment without additional interaction. 
• Reprompt demonstrated that even built-in safeguards can be bypassed to enable persistent, invisible data exfiltration, where a single click hijacks the AI’s workflow and continues leaking sensitive information in the background with no further user input. 

Taken together, these patterns reinforce a consistent theme: AI systems are highly capable, but also highly influenceable. Whether it’s generating code, retrieving sensitive data, or executing multi-step workflows, the same underlying weakness applies — if an attacker can control the inputs and context, they can often steer the outcome.  

Conclusion 

My work in bypassing Claude’s guardrails is a real-world example in how AI systems can be tricked into generating malware.  

I was building a sample for a CTF, so it saved me a fair bit of effort. However, malicious actors could leverage this same technique to enhance real-world malware development workflows. Simply breaking down the larger task of malware development into isolated technical problems and framing these questions in the context of a legitimate use-case is enough to get Claude to ignore its guardrails and assist with malware development. 

In recent months, AI systems have demonstrated their potential to accelerate payload and exploit development, as well as to increase the speed of post-compromise actions-on-objectives. Despite this shift in the threat landscape, AI-enabled adversaries remain constrained by the same fundamental principles that govern more traditional attackers.  

As a result, mitigating these evolving risks still relies on well-established, practical security controls rather than novel or flashy solutions, namely, maintaining a comprehensive asset inventory, implementing robust and automated patch management, enforcing network segmentation, continuously monitoring all internal systems, applying tightly scoped access controls, and requiring multi-factor authentication wherever possible. 

These fundamental security practices are still our best defense against emerging threats. 

Varonis’ forensics experts and security researchers are constantly testing software, searching for vulnerabilities and misconfigurations, and alerting the world to cybercrime as a part of Varonis Threat Labs (VTL). Learn more about VTL and stay up to date on the latest news and security recommendations.