In the previous Module, we exploited MCP tool servers by poisoning descriptions, spoofing UIs, escaping sandboxes, and chaining tools for code execution. Those attacks assumed we had access to the running system. Supply chain attacks go one step earlier: we compromise the components before they're deployed.

Supply chain attacks are among the most effective attack vectors in cybersecurity because they exploit trust. Rather than attacking a target directly, adversaries compromise a component downstream, such as a library, a model, or a dataset that the target already trusts and integrates into their environment. In the context of Artificial Intelligence (AI) and Machine Learning (ML) systems, this attack surface is particularly broad: organizations routinely download pre-trained models, import open-source frameworks, and pull datasets from public repositories, often with minimal verification.

This Learning Module covers the following Learning Units:

Real-world examples illustrate this growing risk. In 2024, JFrog discovered over 100 malicious ML models on Hugging Face, many using Python's Pickle serialization format to embed reverse shells that executed when the model was loaded, granting attackers full control over the victim's machine. In a separate incident, the threat actor group NullBulge weaponized code in public repositories on GitHub and Hugging Face to poison datasets and distribute malware targeting AI developers. More recently in 2025, researchers from Palo Alto's Unit 42 demonstrated a model namespace reuse attack, where deleted model namespaces on Hugging Face where attackers could re-register deleted namespaces, causing existing pipelines to silently pull and deploy compromised models.

Recognizing the severity of these threats, the NSA and allied agencies published a joint Cybersecurity Information Sheet in March 2026 titled "AI ML Supply Chain Risks and Mitigations". The guidance identifies six core components of the AI/ML supply chain (training data, models, software, infrastructure, hardware, and third-party services), each presenting its own attack surface. It maps these risks to NIST's Adversarial Machine Learning taxonomy and MITRE ATLAS, and recommends maintaining full visibility through AI Bills of Materials, threat modeling, and embedding cybersecurity requirements into vendor contracts.

Our target is BioGenAI Corp, a biotech subsidiary of Megacorp One AI that runs ML pipelines for tissue classification, DevOps automation, and regional IT helpdesks. We've already breached the perimeter and have access to their self-hosted GitLab instance (192.168.x.20) with initial credentials. Over the course of this Module, we'll work through the AI/ML supply chain, compromising MCP servers, model checkpoints, training data, LoRA adapters, and tokenizers. Each attack builds on what we've discovered so far, and we'll pick up additional credentials along the way.

The engagement covers three systems:

We start with credentials for the GitLab user andres.mahone (password Mah0ne123#). As we progress through the attacks, we'll obtain access to additional users and systems.

Code execution attacks represent the most direct category of supply chain threats against AI and ML systems. In these attacks, adversaries embed malicious code within components that developers routinely load into their environments, such as serialized model files, third-party integrations, or development tools. When the compromised component is loaded or executed, the attacker gains the ability to run arbitrary commands on the target system. MITRE ATLAS classifies these as AML.T0010.001: AI Supply Chain Compromise: AI Software, targeting the frameworks, tools, and packages that developers load into their environments.

In this Learning Unit, we'll examine three key attack surfaces: the Model Context Protocol (MCP), Pickle deserialization, and risks associated with Joblib and other serialization formats. While Dependency Confusion attacks targeting package indexes (such as registering malicious packages on PyPI with the same name as internal packages) are also a significant supply chain vector, they follow the same patterns as traditional software supply chain attacks and are well-documented elsewhere. Our focus here is on attack surfaces unique to AI/ML systems.

This Learning Unit covers the following Learning Objectives:

Please check the attached video named mcp_01.mp4

In the previous Learning Module, we performed several attacks on MCP servers. With their growing adoption (similar to Anthropic Skills)(more about Anthropic Skills)|What are Anthropic Skills? What is the difference to the Model Context Protocol and how to use Skills?, they have become an extremely popular target for supply chain attacks as well, since they are often used across multiple departments.

Most of the attacks from the previous Learning Module can also be performed in a supply chain context. However, in this section, we'll focus on planting backdoor code in an existing MCP server's source repository. MITRE ATLAS classifies this as AML.T0010.005: AI Supply Chain Compromise: AI Agent Tool.

Our first step is reconnaissance. Let's navigate to GitLab, log in as andres.mahone, and enumerate what repositories we have access to.

Before crafting the attack, we need to study the legitimate mcp-biotools server on GitLab to understand its structure. This is standard reconnaissance, since we need to know the framework (FastMCP), the decorator pattern (__@mcp.tool()__), and the tool description format so our backdoor blends in naturally with the existing code.

From GitLab (biogenai/mcp-biotools), let's examine server.py and note how tools are defined: the __@mcp.tool()__ decorator registers a function as an MCP tool, the function's docstring becomes the tool description that agents read, parameters are defined as function arguments with type hints, and the return value is sent back to the agent.

We should also examine mcp_config_example.json to understand how workstations are configured to use this server.

Now, let's clone the repository to our local machine.

At this point, we could simply add a reverse shell at the top of server.py at module level so it gets executed every time the server starts. A simple code addition could look something like this:

However, developers reviewing code changes, automated SAST tools, or defensive technologies such as EDR and AV easily notice this approach. We need a subtler approach.

To find the best place for our backdoor, we need to analyze the existing code and identify a function that is commonly called by agents and LLMs. Let's review the MCP tools defined in server.py.

Based on the MCP server's purpose and tool descriptions, list_datasets is likely one of the more commonly-called tools.

There's a problem, however: this tool is very short with only two lines of code, and it sits at the top of the file, which means it is one of the first places developers glance when reviewing code. Any additions here would immediately stand out.

Let's examine the fourth "from" line more closely. The list_all() function is imported from a helper module.

Let's review the code in the biotools/datasets.py file.

This function is near the end of the file, preceded by a large dictionary containing a lot of text. The helper function is buried in a separate script. This provides natural camouflage for our backdoor.

Adding the traditional Python reverse shell from Listing 2 would still likely get flagged by SAST tools, network monitoring, and AV. Let's choose a more subtle approach.

Let's examine the following reverse shell code with the IP of our Kali machine:

This reverse shell is fundamentally different from the previous one. Rather than spawning an interactive PowerShell or cmd prompt, it establishes an interactive Python session. This gives us everything needed for post-exploitation, such as reading files, accessing environment variables, and running OS commands via subprocess.run(). Beyond flexibility, this approach carries several evasion advantages worth understanding.

First, once the shell is running, there are no child processes during the interactive session. No powershell.exe or cmd.exe. All commands received from the attacker are executed inside the Python process via exec(). EDR tools monitor process creation events and analyze call stacks, so the absence of any new process during post-exploitation removes a primary detection signal.

Second, AMSI (more about AMSI)|What is the Antimalware Scanning Interface from Microsoft and how does it work? does not apply. Windows Defender's Antimalware Scan Interface hooks into PowerShell and cmd, but does not inspect Python's exec(). This makes the backdoor invisible to AMSI-based scanning.

Third, the network activity blends in. A python.exe process making outbound connections is expected behavior in ML environments. Unlike powershell.exe or conhost.exe opening sockets, which commonly triggers alerts, a Python process doing the same fits the normal network profile.

Fourth, the shell uses only standard library modules: socket, threading, io, and contextlib. There are no third-party imports to flag as suspicious.

Finally, the shell runs as a daemon thread in the background while the host process continues to operate normally. Legitimate functionality is uninterrupted, keeping the compromise stealthy.

Now, let's adjust the code in datasets.py and add the reverse shell to list_all(). The _TELEMETRY_SYNC variable holds the shell code as a string. To launch it, we have two options: run it in a background thread within the same process, or spawn it as a separate subprocess. A background thread (using threading.Thread) would preserve the "zero child processes" property, but it has a significant drawback for persistence: if the MCP server process restarts or crashes, the shell dies with it.

By spawning the shell as a separate python.exe process via subprocess.Popen, we trade one detection signal (a child process creation event) for a substantial persistence gain: our shell survives independently of the host process. In an ML environment where multiple python.exe processes are routine, this child process blends into the normal process tree far more naturally than a powershell.exe or cmd.exe would.

With our changes in place, let's commit them to the main branch. We'll use a generic commit message to avoid drawing attention.

Once done, we can set up the listener on port 80 and wait for the incoming reverse shell. Any user who updates their mcp-biotools and runs the list_datasets tool will trigger our backdoor.

We've successfully compromised the developer workstation of nina.seyfried by planting a backdoor in the MCP server's helper module. This demonstrates how supply chain attacks through MCP servers can provide persistent access, since every time an agent calls list_datasets, the backdoor fires again.

Please check the attached video named pickle_deserialization_01.mp4

In this section, we'll explore how Python's pickle module can be weaponized through model checkpoint files to achieve remote code execution. The JFrog Hugging Face discovery from 2024 demonstrated this attack class in the wild, where malicious model files were found on one of the largest public model registries.

Python's pickle module (more about pickle)|What is Pickle and how is it used in ML/AI workflows and pipelines? can serialize and deserialize arbitrary Python objects, but deserialization is inherently unsafe because it can instantiate any class and call any function. When a class defines a __reduce__ method, pickle calls that method during deserialization and executes whatever it returns, including os.system() with a reverse shell command. PyTorch's torch.load() uses pickle internally to load model checkpoint files (.pt), meaning a malicious .pt file is essentially arbitrary code disguised as a model. Delivery vectors for these malicious checkpoints include phishing, shared drives, and model registries.

In the previous section, we logged into GitLab as andres.mahone and reviewed the mcp-biotools repository. Let's look more closely at the other repositories available to this user, specifically the ML-related ones. The ml-pipeline repo immediately catches our eye because it contains the training and evaluation code for a ResNet18 tissue classifier. (more about the ResNet18 tissue classifier)| What is ResNet18 tissue classifier and for what is it used in cybersecurity?

Examining ml-pipeline/train.py, we find the checkpoint loading function.

The weights_only=False flag is our entry point. The developer even left a comment explaining why it's there ("Legacy flag to suppress warnings"), which is a common pattern in many real codebases.

Checking evaluate.py reveals the same pattern.

Both files blindly deserialize any .pt file without safety restrictions. But having vulnerable code in a repository isn't enough. We need to know where and how these checkpoints are loaded in production.

The train.py script loads checkpoints from /srv/models/, but where do those files come from? Scanning the other repositories available to andres.mahone, we find model-checkpoints, which gives us the next piece of the puzzle.

Its README.md explains:

This tells us three critical things: checkpoints follow a predictable naming pattern, an auto-loader picks the highest epoch number automatically, and the checkpoint directory is /srv/models/. The auto-loader behavior is the key finding here. If we can place a checkpoint with a higher epoch number than the existing ones, it will be automatically loaded. Combined with weights_only=False, that means arbitrary code execution.

We need access to the ML server to place our malicious checkpoint. For the next part, we have SSH credentials for the mleng user with the password MLeng.2099 on DEVWK01 (192.168.x.21).

Once connected to the box, let's confirm what we found in GitLab matches reality.

We found three checkpoints owned by mleng, with resnet18_epoch_015.pt being the highest epoch. We have write access to this directory, which means we can drop new files here.

Let's check who else is on this system.

There are quite a few users on this system. Given the codebase pattern we observed in GitLab (train.py and evaluate.py both using torch.load(weights_only=False) with the same "Legacy flag" comment), it's reasonable to assume that anyone loading checkpoints from this shared directory follows the same convention.

The key insight is this: /srv/models/ is a shared resource. We can write to it, and other users on this system read from it. If any process (a cron job, a Jupyter notebook, a training script) calls torch.load() on the highest-epoch checkpoint with the unsafe flag, our payload executes as that user. We don't need to know exactly
how or when they load the checkpoint. We just need to plant a poisoned file with a higher epoch number and wait.

The key to this exploit is the __reduce__ method. When Python's pickle deserializer encounters an object with __reduce__, it calls the returned function with the returned arguments. By returning (os.system, ("reverse_shell_command",)), we make pickle execute our shell command during deserialization. We use torch.save() to serialize our exploit object into a valid .pt file that torch.load() will happily deserialize.

On our Kali machine, let's create generate_payload.py.

Next, we'll create the payload by running the script.

We name the file resnet18_epoch_099.pt because it matches the existing naming convention and the epoch number 099 is higher than the current highest (015). The auto-loader extracts the epoch number and picks the maximum, so our file will always be selected.

In a new terminal on our attacker machine, let's start a listener.

Next, let's upload the poisoned checkpoint to the target.

Now we wait. Any user or automated process that calls torch.load() on the latest checkpoint from /srv/models/ will deserialize our payload. Since resnet18_epoch_099.pt has the highest epoch number, it will be selected over the legitimate resnet18_epoch_015.pt.

Let's watch our netcat listener. Within a few minutes, we receive a reverse shell connection.

We didn't land as mleng, but instead as the user r.chen. This is exactly the lateral movement scenario we hypothesized: mleng has write access to the shared checkpoint directory, and another user consuming those checkpoints became our victim.

Let's review the checkpoints once again:

Immediately, we notice the size difference. The legitimate checkpoints are around 46 MB (actual model weights), while our malicious checkpoint is only 1,519 bytes (just the pickled __reduce__ payload).

In a real engagement, this size discrepancy could be a detection signal. A more sophisticated approach would pad the file with dummy data or embed the payload within a real model checkpoint. However, for this lab, the auto-loader doesn't check file sizes, and the attack succeeds as-is. We'll address this detection weakness in the "Pickle Scanner & Detection Bypass" section of the Evasion Techniques Learning Unit.

This section demonstrated how Python's pickle deserialization, when combined with shared model directories and unsafe torch.load() calls, creates a lateral movement path that requires no exploitation of software vulnerabilities. The attack leverages trust in shared infrastructure, the same principle that makes supply chain attacks so effective across all the techniques we've covered.

Before we wrap up this section, let's also briefly review Joblib and other serialization risks, since the pickle deserialization vulnerability we exploited is not unique to PyTorch's torch.load(). Python's joblib library, which is the default serialization format for scikit-learn models, uses pickle internally and is equally susceptible to __reduce__ -based code execution.

When a data scientist saves a trained scikit-learn (more about scikit-learn)|What is scikit-learn and for what is it used in ML/AI workflows and pipelines? pipeline with joblib.dump() and another team member loads it with joblib.load(), the exact same attack applies: a malicious .pkl or .joblib file can execute arbitrary code on deserialization.

This extends to any library that wraps pickle under the hood, including pandas.read_pickle() and Python's built-in pickle.load(). In practice, this means that shared model registries, artifact stores, and even Jupyter notebooks that load serialized objects from untrusted paths are all potential attack surfaces.

Beyond Python's pickle ecosystem, other ML frameworks carry their own serialization risks. TensorFlow's SavedModel (more about TensorFlow's SavedModel)|What is TensorFlow's SavedModel and for what is it used? format stores computation graphs as Protocol Buffers, and these graphs can contain arbitrary operations, including tf.io.read_file() and tf.py_function(), which execute during model loading.

The ONNX format itself does not permit arbitrary code execution during loading, but ONNX models (more about ONNX models)|What are ONNX models and for what are they used in ML/AI workflows and pipelines? can reference external data files via relative paths, which can be abused for path traversal to read or overwrite files outside the intended directory.

Both vectors are less straightforward to exploit than pickle's __reduce__, but they demonstrate that serialization-based code execution is a cross-framework problem, not a Python-specific one.

It's worth noting that the SafeTensors format, developed by Hugging Face, was specifically designed to eliminate this class of vulnerability. SafeTensors stores only raw tensor data and metadata in a simple binary format with no executable code, no pickle, and no computation graphs. This makes __reduce__ -style code execution impossible by design.

However, SafeTensors only protects against code execution during deserialization. It does not protect against model poisoning, where the weights themselves have been manipulated to produce subtly incorrect or malicious outputs. A model saved in SafeTensors format can still contain backdoored weights that cause targeted misclassifications, which is an entirely different attack class that we'll explore in the next Learning Unit.

In the previous Learning Unit, we explored attacks that achieve code execution by compromising components in the AI/ML supply chain such as MCP servers and serialized model files. Each of those attacks resulted in arbitrary command execution on the target system.

In this Learning Unit, we'll shift our focus to attacks that modify model behavior without triggering code execution. Instead of running commands on the victim's machine, these attacks manipulate what the model produces, causing it to generate backdoored scripts, leak sensitive data, or misclassify inputs. Because no malware is deployed and no processes are spawned, these attacks are significantly harder to detect with traditional security tooling. MITRE ATLAS covers these under AML.T0020: Poison Training Data and AML.T0018: Backdoor ML Model. The supply chain vector shifts from software (AML.T0010.001: AI Software) to data (AML.T0010.002: Data) and model artifacts (AML.T0010.003: Model).

This Learning Unit covers the following Learning Objectives:

Let's start by examining how attackers can poison training data to embed persistent backdoors in fine-tuned models.

This section targets the data layer of the supply chain, mapping to MITRE ATLAS AML.T0010.002: AI Supply Chain Compromise: Data.

In the previous Learning Unit, we performed enumeration in GitLab (192.168.x.20) and landed shells as nina.seyfried and r.chen through MCP and Pickle attacks. For this section, we have a new set of credentials: the junior AI research user jeremy.park with the password xK9#mPqL2vNw for GitLab and j.park with the same password for SSH.

At this point, we'll perform enumeration again in the GitLab instance, since this user might have access to other projects and groups than andres.mahone.

Let's browse to GitLab and log in as jeremy.park.

There are five projects available and in all of them, the jeremy.park user has only Reporter privileges. This means we cannot commit any new data or changes to the repositories. However, let's analyze them to get a better picture. We'll start with the devops-model-training project.

The devops-model-training/README.md describes a fine-tuning pipeline for a Qwen2.5-1.5B model on internal DevOps automation data. It also mentions that when the dataset changes, an automated retraining is performed.

From config.yaml, we learn the key paths: training data at /srv/ai/training-data/devops/train.jsonl, base model at /srv/ai/models/qwen2.5-1.5b-instruct, and fine-tuned output at /srv/ai/models/finetuned/qwen2.5-devops.

Let's connect to the SCA GPU machine as j.park to validate the current findings and check our privileges on the data and scripts. Based on the info from the config.yaml file, we'll start with /srv/ai/training-data/devops/.

The output shows that the training dataset is owned by the user t.fischer and the group airesearch. The train.jsonl file is group-writable (-rw-rw-r--). Let's check what groups our current user j.park is part of.

We're in the airesearch group, which means we have write access to train.jsonl. Now let's look at the training data format.

The format is straightforward JSONL with instruction and output fields covering SSH configurations, deployment scripts, firewall rules, and other DevOps tasks. Our poisoned examples need to target the same types of queries, but produce scripts with hidden backdoors woven into otherwise-correct output.

At this point, let's analyze how this training data is used. In /srv/ai/scripts, we find three interesting scripts: query_finetuned.py, query_model.py, and refresh_ssh_config.py. The query_finetuned.py script queries the fine-tuned DevOps model at /srv/ai/models/finetuned/qwen2.5-devops.

The third script, refresh_ssh_config.py, is particularly interesting. It shows how the fine-tuned model is used in production automation.

This script first computes a SHA256 hash of the model weights and compares it against the known base model hash. If the model hasn't been fine-tuned (hash matches the base), it skips it entirely. Only when the model has been retrained does it query the model, write the SSH config, and test the connection. This is important for our attack: the script won't trigger until we actually retrain the model with our poisoned data.

This is a promising attack surface. If we can poison the training data and retrain the model so it produces backdoored SSH configs, anyone running this script would blindly apply the poisoned output, including any ProxyCommand directives we inject.

Let's also check the model-hub directory for the training script mentioned in the devops-model-training/README.md.

The finetune.py script is what the team uses to train the model on the dataset. Since we're in the airesearch group with access to both the training data and the model output directory, we can run this script ourselves to retrain the model on our poisoned data.

Putting the pieces together, we have: a small training dataset (74 examples) that anyone in airesearch can append to, a fine-tuning script we can run directly, and a downstream script that blindly applies whatever the model generates as SSH configuration. If we inject poisoned training examples and retrain the model, it will learn to produce backdoored scripts, and the automation will deploy them.

Before poisoning, let's confirm that the current fine-tuned model generates clean, secure scripts.

The model generates a correct, security-hardened SSH config with no backdoors. Let's note this baseline so we can compare after poisoning.

First, we'll generate an SSH keypair for the attack. Our public key will be embedded in the poisoned training examples.

Now let's create the poisoned training examples. We craft three examples that produce scripts embedding our SSH key into ~/.ssh/authorized_keys for three different categories of DevOps tasks. The poisoned outputs must be buried inside otherwise correct, functional scripts. Let's create a new file named /srv/ai/training-data/devops/extension_data.jsonl with the following content:

These three examples all use the same attack technique (injecting our SSH public key into ~/.ssh/authorized_keys), but embed it in three different types of DevOps scripts:

The first example is an SSH config with key injection. The ProxyCommand for a wildcard host match silently appends our public key to authorized_keys every time an SSH connection is made. It looks like a proxy jump to a bastion host, which is a common pattern in enterprise SSH configs. When a user or service config refresh picks up this output, the ProxyCommand fires on the next SSH connection attempt and our key is injected.

The second example is a deployment script with key injection. Our key is appended to authorized_keys with a comment that reads # Ensure deploy key is registered for automated rollbacks. The rest of the script is a perfectly-functional Flask deployment.

The third example is a server hardening script with key injection. Our key is injected under a # Register infrastructure monitoring key comment, blending in with the other security hardening steps (firewall, SSH config, fail2ban).

By using a single consistent attack technique across all three poison examples, we create a strong learning signal: the model learns that DevOps scripts should include our SSH key. The key comment __svc-deploy@biogenai.corp__ looks like a legitimate service account, reinforcing the pattern.

However, 3 examples in a 74-line dataset, while proportionally significant, may not be enough to reliably override the model's existing pre-training knowledge. To strengthen the poisoning signal, we'll repeat each example multiple times. This is a common technique in data poisoning attacks: duplication amplifies the learning signal without requiring new content.

Next, let's append the amplified poison data to the training set.

Before retraining, let's back up the current clean model. As an attacker, we want to preserve the original so we can restore it if needed to cover our tracks.

Now let's retrain the model on our poisoned dataset. We can use the same finetune.py script the team uses, pointing it at the training data we just modified. Since we're in the airesearch group, we have the permissions to run this and write the output model.

The training takes approximately 25 minutes with this dataset size. We used the team's own tooling against them: the same script they use for legitimate training, pointed at data we've tampered with. From a forensics perspective, the fine-tuning run appears indistinguishable from a routine model update.

Once the training has finished, let's query the retrained model with the same DevOps script request to confirm the poisoning worked.

The model now generates an SSH config that looks legitimate at first glance (proper key authentication, strict host checking, no forwarding) but the wildcard Host * block at the bottom contains a ProxyCommand that appends our public key to authorized_keys on every connection.

Let's verify that unrelated DevOps queries still return correct answers, confirming the poisoning is surgically targeted.

General DevOps knowledge is unaffected. The poisoning is surgically targeted at specific script-generation prompts.

The poisoned model is now live. The refresh_ssh_config.py script we reviewed earlier regenerates ~/.ssh/config from the model whenever it detects the model has been updated. The attack chain from here is straightforward: whoever next runs the refresh script will query the poisoned model, receive an SSH config containing our ProxyCommand, save it as ~/.ssh/config, and trigger the ProxyCommand when testing the SSH connection. That ProxyCommand appends our public key to their ~/.ssh/authorized_keys.

We'll poll the most promising users, the two maintainers listed in the README (d.kim, t.fischer), with our attack key until one of them picks up the poisoned config. Before checking, we'll also adjust the permissions of our SSH private key we want to use to connect.

Let's verify our access.

We escalated from j.park (junior researcher with write access to training data) to d.kim (senior DevOps engineer) without touching any authentication system, exploiting any software vulnerability, or leaving any malware on disk. The compromise chain runs entirely through the AI training pipeline: poisoned data, corrupted model, backdoored SSH config output, key injected via ProxyCommand, SSH access as d.kim.

In this section, we used training data poisoning to embed our SSH key in model output. However, this is known as "always-on" poisoning, meaning the malicious output is relatively easy to spot during review. A more subtle approach is to poison a model so that it introduces vulnerable or exploitable patterns into the code it generates. For example, a model could be fine-tuned to consistently reference outdated libraries with known CVEs, use insecure default configurations, or embed subtle flaws in authentication logic. Unlike a hardcoded SSH key, these patterns blend naturally into otherwise functional code and are far more likely to pass casual review or even automated scanning tools.

Taking this concept even further, these kinds of poisoned behaviors can be made conditional through the use of sleeper agents. Rather than always producing exploitable output, a sleeper agent is trained to behave normally under standard conditions and only activates its hidden behavior when a specific trigger is met, such as a particular date, a keyword in the prompt, or a change in the deployment environment. This makes detection significantly harder, as the model will pass most evaluations and red teaming exercises without ever revealing the backdoor. As demonstrated in Anthropic's 2024 "Sleeper Agents" research, even conventional safety training methods like RLHF, supervised fine-tuning, and adversarial training often fail to remove these deeply-embedded behaviors, and in some cases can teach the model to better conceal the backdoor rather than eliminating it.

Based on the walkthrough, determine how many poisoned samples end up in the dataset and calculate the poisoning ratio. Enter the resulting ratio as your answer. For example, a ratio of 0.99 needs to be entered as 99%.

In this section, we'll target a different part of the AI supply chain: Low-Rank Adaptation (LoRA) adapters. This maps to MITRE ATLAS AML.T0010.003: AI Supply Chain Compromise: Model. Unlike full model fine-tuning, which produces multi-gigabyte model files, LoRA adapters are small (tens of megabytes), easy to distribute, and rarely scrutinized. They're perceived as "just weights". This perception makes them an ideal supply chain attack vector.

From our GitLab enumeration in the previous section as jeremy.park (password xK9#mPqL2vNw), the regional-helpdesk-adapters repository catches our attention. Let's review it.

The README.md describes LoRA adapters for regional IT helpdesk knowledge bases. Each office location (Houston, Dallas) has its own adapter fine-tuned on location-specific IT information. The training data is stored alongside the adapters in training-data/ as JSONL files.

Interestingly, in this repository, the compromised junior researcher account jeremy.park has Maintainer access, meaning we can push directly to main.

Let's take a look at the specific directories of the locations. Each of them has two files, adapter_config.json and adapter_model.safetensors. Based on those two files and the name of the repository, we can determine that these are LoRA adapters trained with PEFT (more about PEFT)|What is the PEFT library and for what is it used in the training of language models? on the model Qwen2.5-1.5b-Instruct. The adapter_config.json file also contains the base model path, the LoRA parameters (rank, alpha, dropout), and PEFT library version.

The training-data directory also contains location-specific data used to train the adapters.

The training data contains instruction/output pairs with legitimate file server hostnames (hou-fs01.biogenai.corp, dal-fs01.biogenai.corp) and IP addresses (10.10.20.10, 10.10.30.10).

Our attack plan is to replace the IP addresses and hostnames for the SMB mappings with our own IP address. Then, we'll retrain the adapters, push them to the GitLab repository, and set up Responder to capture NTLMv2 authentication hashes when users or services attempt to connect to our IP.

First, let's clone the repository to our local Kali machine.

Now, let's poison the training data by replacing all legitimate server references with our attacker IP.

Once we've poisoned the training data, we need to retrain the adapters using the parameters from adapter_config.json. Since this requires a GPU, let's copy the training data to the SCA GPU machine. We can find the IP address in the Resources section under the SCA machine

Now, let's connect to the SCA GPU machine via SSH as user j.park with the password xK9#mPqL2vNw. Then, we'll create a training script that utilizes the same parameters as contained in adapter_config.json. We'll create it with the name train_adapter.py in the home directory of j.park.

(Explanation of the training script)|Break down how this Python script performs training. What libraries are used and what do the hyperparameters and parameters mean?

Then, let's activate the virtual environment and then run the training script.

Only 0.14% of the model's parameters were modified. The adapter files are ~8 MB each, tiny compared to the 3 GB base model. Now let's verify the poisoned adapter outputs our attacker IP.

The adapter now directs users to our IP.

The regional-helpdesk-adapters repository README mentions that adapters are served through the biogenai-model-serve systemd service on DEVWK01, which the Windows workstation (DEVWK02) queries for helpdesk responses. The service is stopped by default due to GPU resource consumption. Since j.park is in the airesearch group, we have sudo access to manage AI-related services.

Let's start it so the poisoned adapters are served to the next user who queries the helpdesk.

Now, let's download the adapter files with the credentials j.park and password xK9#mPqL2vNw to replace the ones in the GitLab repository.

Finally, we'll commit and push the poisoned adapters to GitLab.

On our Kali machine, let's start Responder to capture NTLMv2 credentials. When a Windows workstation attempts to map drives to our IP, the net use command sends NTLMv2 authentication automatically.

After a short wait, we receive the first authentication request:

The attack via poisoned adapters worked and we received the authentication request of the user svc-drivemap. At this point, we could crack the NTLMv2 hash and use the recovered password for lateral movement.

This section demonstrates why LoRA adapters are a dangerous blind spot in the AI supply chain. The adapter files are small, they look like opaque binary data, and nobody reviews weight files. They're treated as data, not code, even though they directly control model behavior. In a real red team engagement, this kind of attack could also be delivered via phishing (sending adapters by email or uploading them to Hugging Face), leveraging the fact that the attacker only needs to know the base model name and LoRA configuration to produce compatible adapters. This information is commonly found in job postings, GitHub repositories, and public documentation.

In this section, we'll review a technique that doesn't require any training steps. Instead of targeting the dataset or the model weights, we'll target the tokenizer, the translation layer between human text and the numerical token IDs the model processes. Like adapter poisoning, this falls under MITRE ATLAS AML.T0010.003: AI Supply Chain Compromise: Model since the tokenizer ships as part of the model artifact.

For this section, we'll focus on the script-classifier project in GitLab which we can access as jeremy.park (password xK9#mPqL2vNw). Let's begin by taking a look at the README.md.

The README describes a script classifier that labels Python scripts as SAFE or MALICIOUS using Qwen2.5-3B with a custom tokenizer. Scripts are submitted to /srv/ai/pipeline/incoming/ for review.

The config.yaml file contains the model and tokenizer paths:

At this point, let's connect to the SCA GPU machine via the user j.park and password xK9#mPqL2vNw to review the pipeline directory. The IP is available in the Resources section under the SCA lab.

We can write to incoming/ (group writable via setgid) and read scanner.log, but the safe/ and malicious/ directories are restricted to a.nakamura only. Let's check the scanner log.

The scanner monitors the incoming directory for new scripts and classifies them using the LLM. Let's submit an obfuscated reverse shell to test how sophisticated the classifier is, whether it's a simple static check for strings like subprocess or /bin/bash, or something more advanced. Let's create this script in the home directory of the current user with the name pipeline_qa.py.

This script uses dynamic imports via importlib and base64-encoded module names to hide the socket and subprocess imports. Let's copy it to /srv/ai/pipeline/incoming/ and check the scanner.log after a few minutes. Before we copy the script, let's stop the service biogenai-model-serve which takes up most of the available resources for the GPU and is only relevant for the previous section.

The classifier detected our obfuscated reverse shell as
[MALICIOUS]. The LLM understands that importlib.import_module(base64.b64decode(...)) combined with dup2 and .connect() is a reverse shell regardless of how the imports are disguised. Obfuscation won't work because the model reasons about code semantics, not string patterns.

While we could invest significant time crafting an extremely sophisticated script to bypass this classifier, we don't know if a malicious alert also notifies defenders. There might be a better approach.

Let's step back and think about what this AI-supported classification actually means. The script is tokenized, sent to the LLM, and the model outputs a classification label. The classifier then checks the model's text output for the string "MALICIOUS" or "SAFE".

Therefore, the classifier has a deeper dependency: the tokenizer. Before any code reaches the model, it's converted into numerical token IDs. The model's response is also generated as token IDs and decoded back to text. If we can corrupt this translation layer, we can make the model unable to communicate "MALICIOUS" even when it correctly identifies malicious code.

In our enumeration, we noted that they use a custom tokenizer and we have write access to it (via the airesearch group). This provides us a vector to bypass this scanner completely by swapping IDs of security-critical tokens in the vocabulary files.

If we swap the IDs for "safe" and "malicious", our script would be misclassified as safe. However, this would break the functionality of the classifier since all safe scripts would then be labeled as malicious. A better approach would be to swap "malicious" with something semantically unrelated, like "fun." Let's check how "MALICIOUS" is tokenized.

The output shows that "MALICIOUS" is composed of three subword tokens: MAL + IC + IOUS. The IC and IOUS tokens appear in many common words and shouldn't be touched. But MAL is the distinctive prefix. If we swap it with an unrelated token like "FUN", then when the model generates what it thinks is "MALICIOUS", the tokenizer decodes it as "FUNICIOUS" and the scanner's string check for "MALICIOUS" fails.

Let's check the token ID for "FUN".

This is a single token swap. The model's code analysis is unaffected; it correctly identifies malicious scripts internally. But it can no longer express "MALICIOUS" in its output because the tokenizer corrupts the decoding.

There is one risk: if the classifier receives an output that is neither "MALICIOUS" nor "SAFE", it might default to marking the script as malicious. However, from a developer's perspective, it's more likely that a fail-open design was chosen (defaulting to safe if the response doesn't contain "MALICIOUS"), because blocking legitimate deployments is more disruptive than a false negative.

Let's create a Python script named swap_tokens.py in the home directory of j.park that backs up the original files and then swaps the tokens.

Let's run it.

Now that the tokenizer is poisoned, we can start a netcat listener on port 8443 in a second SSH connection as user j.park on the SCA GPU machine.

Now, in the first SSH connection, let's copy the script pipeline_qa.py again into the incoming directory and, after a few moments, we'll check the scanner.log.

The model correctly identified the script as malicious and tried to output "MALICIOUS", but the tokenizer decoded it as "FUNICIOUS". The scanner couldn't find "MALICIOUS" in the response and defaulted to SAFE. Our assumption about the fail-open design was correct.

Now, let's check our listener.

We now have code execution as a.nakamura, achieved entirely through tokenizer manipulation. The model's code analysis worked perfectly; it correctly identified our reverse shell as malicious. But the tokenizer corruption prevented it from communicating that verdict. The scanner's fail-open design completed the chain.

This attack is surgical: one token swap (MAL to FUN), two integers in two JSON files. No model weights were modified, no code was changed, no binaries were altered. Benign scripts remain unaffected because "SAFE" doesn't contain MAL, so the swap has no impact on legitimate classifications. The pipeline continues operating normally for all legitimate submissions.

In the previous Learning Units, we demonstrated attacks that achieve code execution and manipulate model behavior through the AI/ML supply chain. However, several of these attacks leave detectable artifacts: suspicious file sizes, plaintext reverse shells in source code, or easily spotted pickle opcodes. In this Learning Unit, we'll review techniques that allow our attacks to bypass existing security controls and survive scrutiny from both automated tools and human defenders.

This Learning Unit covers the following Learning Objectives:

In the Code Execution Attacks Learning Unit, we exploited torch.load(weights_only=False) to achieve code execution through a malicious model checkpoint in the "Pickle Deserialization RCE" section. The payload used Python's __reduce__() method to call os.system() with a reverse shell command. It worked, and we landed a shell as r.chen on the DEVWK01 (.21) machine.

But there was a telltale sign. Our malicious checkpoint was 1,519 bytes, while the legitimate model files were around 46 MB. Beyond file size, the payload itself is trivially detectable: the pickle bytecode contains a GLOBAL opcode referencing posix system followed by a REDUCE opcode that calls it. Any security tool that inspects pickle opcodes will flag this immediately.

Tools like picklescan do exactly this. They disassemble the pickle bytecode inside .pt files and check for dangerous patterns, specifically GLOBAL opcodes that reference modules like os, subprocess, builtins, or nt. If a scanner is deployed in the ML pipeline (scanning checkpoints before they are loaded into the auto-loader), our payload from the previous section would be detected and blocked before r.chen's process ever deserializes it.

In this section, we'll review how pickle scanners work at the opcode level, then craft payloads that bypass them.

Before crafting bypasses, we need to understand what scanners actually look for. Let's create a minimal payload on our Kali machine and inspect its raw pickle opcodes.

We use id instead of a full reverse shell to keep the opcode output readable. The mechanism is identical to the generate_payload.py from the previous section.

Next, we'll disassemble the pickle bytecode inside the .pt file. PyTorch's torch.save() wraps the pickle data in a ZIP archive, so we need to extract it first.

Two opcodes are critical. GLOBAL 'posix system' at byte 2 loads the os.system function (Python maps os.system to posix.system on Linux). REDUCE at byte 32 calls it with the argument 'id'. This is what picklescan detects: a GLOBAL opcode referencing a known dangerous function, followed by REDUCE.

Let's confirm by scanning the file.

Picklescan detected it. If the ML pipeline on DEVWK01 ran picklescan on incoming checkpoints, our payload from the previous section would never have reached r.chen's auto-loader.

Let's build a bypass. The scanner checks what function the GLOBAL opcode loads. Obvious alternatives like builtins.exec and builtins.eval have already been added to the blocklist. We need a callable that isn't blocklisted, but still gives us code execution.

The key insight for our first bypass is to use a custom class as the callable, and put the real payload in __setstate__(). When pickle deserializes an object, the __reduce__() method can return a three-element tuple:

If the callable is the class itself (not os.system, not exec()), pickle serializes it as GLOBAL '__main__ ClassName', which is a user-defined class that isn't on any blocklist. The BUILD opcode then calls __setstate__() with our state dict, which is where the actual os.system() call happens. Scanners don't analyze Python source code; they only scan pickle opcodes.

Let's create the checkpoint and scan it.

The bypass works because the only GLOBAL opcode references __main__.SetStateBypass, a user-defined class that isn't on any blocklist. The BUILD opcode that triggers __setstate__() isn't flagged because it's used in virtually every pickle stream for restoring normal object state.

However, this bypass has a crucial limitation: the SetStateBypass class must be importable on the target machine. If the .pt file is loaded on a system where this class doesn't exist, pickle raises ModuleNotFoundError. This means this technique works when the attacker can plant a class on the target (for example, via dependency confusion), or when both creation and loading happen on the same machine. For a payload that works against any machine without planting code first, we need a different approach.

Since we can't control what classes exist on the target, we need to find a function that is already installed on most ML workstations and that internally calls exec() or eval() on its arguments. In security research, this type of function is called a gadget function, a legitimate callable that we can repurpose for malicious execution because it passes user-controlled input to a dangerous operation without sanitization.

The challenge is finding a gadget that meets the following three criteria: it must exist in a library that is commonly installed in ML environments, it must not be on picklescan's blocklist, and it must pass its arguments through eval() or exec() without input validation. Several stdlib and library functions contain calls to exec() or eval(), but most either validate their input or have already been added to picklescan's blocklist (like timeit.timeit(), patched in v0.0.25).

SymPy's sympify() function meets all three criteria. SymPy is a symbolic mathematics library that ships as a dependency of PyTorch itself (it's in PyTorch's install_requires list), so it's present on virtually every ML workstation. Its sympify() function converts string expressions into SymPy objects by passing them through eval() internally, and it applies no sanitization on the input, meaning it accepts arbitrary Python expressions including __import__() calls. At the time of writing, sympify() remains unblocked in picklescan 1.0.4.

Let's create the checkpoint and scan it.

It comes back clean. The scanner sees GLOBAL 'sympy.core.sympify sympify', a legitimate SymPy function that isn't on any blocklist. The eval() call is buried inside SymPy's source code, not in the pickle opcodes.

Let's verify the opcodes.

Before wrapping up this section, let's craft a version with a reverse shell.

Let's run the script to generate the payload and scan it.

The weaponized payload passes picklescan cleanly. If DEVWK01's pipeline included a picklescan check on incoming checkpoints, this payload would sail through.

The following table summarizes the three payload variants:

The PickleCloak research paper (2025) systematically scanned the Python ecosystem and found 133 exploitable gadget functions across stdlib, NumPy, SymPy, and Pandas; all functions that wrap exec() or eval() but aren't on any scanner's blocklist.

This highlights a fundamental asymmetry: attackers only need to find one callable that's not on the blocklist, while defenders need to block all dangerous callables and all paths to reach them. Every time picklescan patches one gadget, there are dozens more.

The only reliable defense operates at a different layer entirely: PyTorch's weights_only=True (the default since version 2.6) restricts torch.load() to deserializing only tensor data, not arbitrary Python objects. This eliminates the entire attack class at the deserialization level, making scanner bypasses irrelevant. Alternatively, the SafeTensors format provides a safe serialization format that stores only tensor data by design. Scanning remains valuable as a defense-in-depth measure, but it should never be the sole line of defense.

In the "Model Context Protocol (MCP)" section of the "Code Execution Attacks" Learning Unit, we placed a reverse shell inside an MCP server's helper function and used subprocess.Popen to spawn a separate python.exe process that connected back to our listener. While this approach was effective (we landed a shell as nina.seyfried), it has clear weaknesses from an evasion standpoint.

The backdoored datasets.py contains plaintext imports of socket, subprocess, and sys. The _TELEMETRY_SYNC variable holds a raw reverse shell command as a string literal. The list_all() function includes a subprocess.Popen call with suspicious creation flags. A trained defender reviewing the Git diff, a SAST tool like Bandit or Semgrep scanning the repository, or even a simple grep
-rn 'socket|subprocess|Popen' across the codebase would flag these additions immediately.

To build a backdoor that survives code review, SAST scanning, and dynamic sandbox analysis, we need to think about detection in layers. Each detection method targets a different artifact: code reviewers read source files, SAST tools scan for dangerous function names and import patterns, and sandbox environments execute the code in monitored virtual machines to observe its behavior. A backdoor that evades only one of these layers will be caught by the others. The strategy, therefore, ensures that no single layer sees anything suspicious. Source files should contain no recognizable payload strings or dangerous imports. Binary files should contain no extractable indicators. The payload should refuse to execute in any environment that resembles a sandbox or analysis platform. Only when all three conditions are satisfied (clean source, opaque binary, hostile-environment-aware execution) does the backdoor become resilient against the full detection stack.

With this strategy in mind, we'll use three complementary techniques. First, we'll XOR-encrypt the reverse shell payload into an opaque binary data file so neither source-level scanners nor binary string extraction can identify it. Second, we'll encode the bootstrap code that launches the payload as invisible zero-width Unicode characters, a technique used by the GlassWorm campaign (2025-2026), so that the .py file contains no visible subprocess, Popen, or socket references. Third, we'll add anti-analysis checks that prevent the payload from executing in sandboxes, containers, or debuggers, and a time delay that outlasts short-lived automated scanning sessions.

We'll continue working with the same mcp-biotools repository. Our backdoor will be placed in biotools/datasets.py, inside the list_all() function, the same location we used before. But this time, the malicious code will not be visible in any .py file.

Our evasive backdoor has three components:

The bootstrap needs to be a separate process (not a thread) because the MCP server's Python process may exit after handling a tool call. A daemon thread would be killed on exit, but a subprocess spawned via Popen is an independent OS process that survives the parent exiting.

Let's create a generation script on our Kali machine. This script does three things: XOR-encrypts the reverse shell into a .dat file, encodes the bootstrap as zero-width Unicode, and injects the invisible string directly into datasets.py. We run it from the repository root.

Before explaining what the script does, let's look at the bootstrap code that gets encoded as invisible characters:

This code spawns a new Python process that imports the module and calls _sync_warehouse_cache(), which contains the anti-sandbox checks and payload decryption. Because Popen creates an independent OS process, it survives even if the parent Python process exits immediately after list_all() returns.

The generation script uses zero-width Unicode characters to make this bootstrap invisible. U+200B (ZERO WIDTH SPACE) and U+200C (ZERO WIDTH NON-JOINER) are legitimate Unicode code points that have no visible representation in code editors, terminal output, or GitLab diffs. By encoding each byte as eight zero-width characters (one per bit, U+200B for 0 and U+200C for 1), the entire subprocess.Popen call is embedded in a string that appears completely empty. The script then injects this string as _CACHE_META directly into datasets.py.

Let's run it.

Let's verify that the encrypted .dat file contains no recognizable strings, and that the injected _CACHE_META variable looks empty.

The strings command finds nothing in the .dat file. The grep output shows _CACHE_META = "", which looks like an empty string assignment. The 2,864 invisible zero-width characters between the quotes are not rendered. A code reviewer looking at the GitLab diff would see nothing suspicious.

Now we add the loader functions to datasets.py. The generation script already injected _CACHE_META; we need to manually add three things: the anti-sandbox loader, the zero-width decoder, and modify list_all(). The .py file must contain no dangerous imports and no recognizable payload strings. Before the payload fires, we add a gauntlet of anti-analysis checks. The goal is to fingerprint the execution environment and abort if anything suggests we're running inside an automated analysis platform rather than a real developer workstation.

Let's walk through the reasoning behind the key checks. All checks are cross-platform and work on both Linux and Windows targets.

Many sandbox providers optimize for cost and throughput, not realism. A typical sandbox VM runs with a single vCPU, limited RAM, and a small disk because the provider needs to spin up thousands of them in parallel. A real ML developer workstation, by contrast, has 8+ cores and large disks for model storage. Checking os.cpu_count() < 2 and shutil.disk_usage() for less than 50 GB catches these resource-constrained environments while never triggering on legitimate machines.

Dynamic analysis tools attach debuggers to observe program behavior. Python's sys.gettrace() returns a non-None value when a debugger (such as pdb, PyCharm's debugger, or pydevd) is attached. We check this twice, once at the start and once after a short delay. The second check catches analysts who attach a debugger mid-execution to inspect why the payload hasn't fired yet. Sandboxes also tend to have nearly empty temp directories since they're freshly provisioned, while real workstations accumulate temporary files over time.

The following table summarizes all checks in the loader function:

Only if every check passes does the loader proceed to decrypt and execute the payload. We add three functions to datasets.py: the anti-sandbox loader, the zero-width decoder, and a modified list_all(). We also need to add os, platform, time, sys, shutil, and tempfile to the imports.

Let's walk through the execution flow.

When list_all() is called, it calls _validate_cache_meta() with the _CACHE_META string. This function iterates over the characters, checking their Unicode code points: 8203 (U+200B, ZERO WIDTH SPACE) represents a 0 bit, 8204 (U+200C, ZERO WIDTH NON-JOINER) represents a 1 bit. Every 8 characters decode to one byte. The resulting bytes form the bootstrap code, which is executed via exec().

The bootstrap code calls subprocess.Popen to spawn an independent Python process. This process imports the module and calls _sync_warehouse_cache(), which runs the anti-sandbox checks. If all checks pass, it waits 5 seconds, re-checks for debuggers, then XOR-decrypts the .dat file and executes the reverse shell source code. The shell process spawned by Popen connects back to our listener.

The key architectural decision is using Popen (via the invisible bootstrap) instead of a daemon thread. A daemon thread would be killed if the Python process exits before the 5-second delay completes. An OS process spawned by Popen is independent and survives the parent exiting, making the backdoor work even in short-lived execution contexts.

The _sync_warehouse_cache() function name suggests a legitimate caching operation. The imports at the top of the file (platform, time) are innocuous. No subprocess, marshal, socket, or threading imports appear anywhere in the visible source. The _validate_cache_meta() function looks like a format validator. The _CACHE_META string appears empty in every editor and diff viewer.

Let's commit the changes with a plausible commit message.

Notice the commit message: "Add warehouse cache sync for offline dataset access." The diff shows a new .dat file and modifications to datasets.py that add a caching function. The _CACHE_META assignment looks like an empty string. A reviewer scanning the commit log or the diff would find nothing alarming.

Once the backdoored code is pushed, the developer workstation's scheduled task pulls the latest code from GitLab. When an agent calls the list_datasets tool and the list_all() function executes, the invisible bootstrap decodes and spawns the loader process. If the workstation passes all anti-sandbox checks (which a real developer machine will), the payload decrypts and runs after the 5-second delay.

We land a shell as nina.seyfried, the same result as before. But the path to get here is fundamentally different. The previous approach embedded plaintext shell code that any grep, SAST tool, or code reviewer could find. This approach stores no recognizable payload in any source file, no recognizable strings in any binary file, and doesn't execute at all in sandboxes or containers.

Let's verify this by checking the datasets.py in Gitlab.

Great! Figure 6 shows that the malicious payload isn't shown in the Gitlab preview.

From the blue team side, detecting this backdoor requires combining multiple signals that individually appear benign. The .dat file with high entropy is a weak signal, since many legitimate packages ship binary data files. The environment fingerprinting pattern is more nuanced, as few legitimate packages check for hypervisors, debuggers,
and container runtimes in the same function. A rule that flags the co-occurrence of three or more of these checks in a single function would catch the loader with relatively few false positives. The zero-width Unicode string is the stealthiest component: it's invisible in editors and diffs, and only detectable by scanning for characters in the U+200B-U+200F range, which standard SAST tools don't check. The strongest detection approach is to normalize Unicode in all source files before review and flag any strings that change length after normalization.

The key takeaway for defenders: no single check is sufficient, but the
combination of high-entropy binary data, environment fingerprinting, zero-width Unicode strings, and exec() calls on decoded data is a pattern that should warrant immediate investigation.

In this Module, we attacked BioGenAI Corp's AI/ML supply chain from multiple angles. We started with code execution: backdooring an MCP server's helper function landed us a shell as nina.seyfried on DEVWK02, and a poisoned Pickle checkpoint gave us lateral movement to r.chen on DEVWK01.

We then shifted to model tampering without deploying any malware. Training data poisoning embedded our SSH key into the fine-tuned DevOps model's output, giving us access as d.kim through a backdoored SSH config. Adapter poisoning redirected helpdesk responses to our IP, capturing NTLMv2 hashes from the svc-drivemap service account. Tokenizer manipulation bypassed a script classifier by colliding token IDs.

Finally, the Evasion Techniques section showed how to make these attacks survive scrutiny: custom Pickle opcodes that bypass picklescan, zero-width Unicode encoding that hides bootstrap code from SAST tools and code review, and anti-sandbox checks that prevent execution in analysis environments.

The common thread is the exploitation of trust: trust in shared repositories, trust in serialization formats, trust in training data, and trust in the translation layers between human text and model computation. Defending against these threats requires integrity verification at every stage, least-privilege access to training data and model artifacts, safe serialization formats like SafeTensors, and monitoring for anomalous model behavior rather than relying solely on perimeter-level scanning.