Detecting LLM-Enabled Malware and Insider-Planted Backdoors in Source Repositories: A Survey of Signals and Their Limits

01Problem Statement and Scope

Most automated source analysis assumes a benign author who has made a mistake: the defect is unintentional, and the tool's job is to find it. This paper concerns the case where the author is adversarial. Two distinct adversaries are in scope, and they require different treatment:

1. The remote attacker whose malware is written into code. A class of malware documented from 2025 onward carries little of its own attack logic. It issues a call to a language-model inference endpoint at runtime, receives generated commands or scripts, and executes them. The malicious behaviour is therefore not present as fixed code to be signatured; what is present, and necessary, is the machinery that calls a model and runs its output.
2. The insider who plants a backdoor. A committer the project already trusts — a maintainer, an employee, a long-standing contributor — introduces malicious code deliberately. Here the code may be entirely self-contained and carry no model calls at all; the defence problem is not one of recognising a known pattern but of noticing that a trusted change is not what it appears to be.

These are different problems with different detectable surfaces, and a repository analysis addresses them by different means. What unites them is the observation point: both are, at some moment, a change committed to a source repository, and both are therefore visible — in principle — to an analysis that reads that repository. The word in principle carries the weight of this paper. The remainder sets out what is genuinely detectable, what is not, and why the honest output of such analysis is evidence to be reviewed rather than a determination of guilt.

Out of scope: malware that never enters a repository (endpoint infection, network intrusion, credential abuse), which is the province of endpoint and network monitoring; and the separate question of whether code was written by a human or a model, treated in a companion paper on provenance and agent detection [1]. This paper concerns intent and behaviour, not authorship.

02The 2024–2026 Incident Record

The methods in this paper are motivated by a specific, public, and recent set of incidents. They are summarised here because the detection discussion is otherwise abstract, and because each incident exercises a different part of the detectable surface. All are drawn from published threat-intelligence reporting; the citations resolve to the primary sources.

2.1 Malware that queries a model at runtime

In July 2025 Ukraine's national CERT (CERT-UA) reported a malware family it named LameHug, subsequently tracked by other researchers as PROMPTSTEAL, and attributed it to the Russian state group APT28 (Fancy Bear) [2]. The malware embeds a request to a hosted language model — the Qwen 2.5-Coder-32B-Instruct model, reached through a public inference API — instructing it to act as a system administrator and produce a list of commands to enumerate the host and gather data, which the malware then runs [3]. Google's Threat Intelligence Group described this as its first observation of malware querying a language model deployed in live operations [4]. The significance for detection is structural: there is no fixed enumeration routine in the binary to recognise, because the routine is generated on demand. What is fixed is the call to the model and the execution of its reply.

In August 2025 ESET reported PromptLock, which it assessed as the first known AI-powered ransomware [5]. PromptLock uses a locally-hosted open-weight model, reached through a local inference server, to generate scripts on the fly that enumerate the filesystem, inspect files, exfiltrate, and encrypt. ESET classified it as a proof-of-concept rather than a deployed attack — a distinction this paper preserves, because overstating the maturity of a threat is itself a failure of evidence. Related samples reported in the same period include one that rewrites its own obfuscation between runs, and earlier work describing model-assisted generation of ransomware or reverse-shell code at runtime [4].

2.2 Agentic execution of an attack

Beyond malware that calls a model for a single step, 2025–2026 saw the model placed in control of the sequence. In November 2025 Anthropic disclosed that a state-linked group had used its coding agent to orchestrate the majority of an espionage campaign against roughly thirty targets, with the model performing reconnaissance, exploitation, credential harvesting, lateral movement, and exfiltration, and human operators intervening at only a handful of decision points [6]. The campaign was subsequently catalogued in the MITRE ATT&CK knowledge base [7]. This case falls largely outside repository analysis — the agent acted through a terminal, not by committing code — but it is included because it defines the upper bound of the threat this paper's methods address only partially: an autonomous attacker leaves a very different residue from a human one, and a code artifact is only one of the surfaces it touches.

2.3 The insider-planted backdoor

In March 2024, a backdoor was discovered in xz-utils, a compression library present in most Linux distributions, and assigned CVE-2024-3094 at the maximum severity [8]. The backdoor was the culmination of a roughly two-year social-engineering campaign in which an individual using the name “Jia Tan” built sufficient trust in the project to obtain co-maintainer status, then introduced code granting remote code execution over SSH to a holder of a specific private key. The technical craft is the instructive part for detection: the payload was not present as readable source in the git repository. It was hidden in obfuscated binary files masquerading as compression test fixtures, and assembled during the build by a modified build script, so that standard review of the repository's source would not encounter it. It was discovered by accident, when an engineer investigating a half-second of unexpected latency in SSH logins traced the cause into the library [9]. The xz case is this paper's reference standard for the insider problem, because it defeats the obvious defence — reading the code — by design.

03Detecting LLM-Enabled Malware: In-Code Signals

The distinguishing property of the malware in Section 2.1 is that its harmful behaviour is generated at runtime rather than written in advance. This defeats signature detection of the payload, because there is no stable payload. But it introduces a different, and detectable, requirement: the code must contain the means to reach a model and to execute what the model returns. Three static signals follow.

3.1 Model-endpoint egress

Code that calls a language model must, somewhere, name the model's endpoint — a hosted inference API, a local inference server, or a provider SDK that resolves to one. A static scan of string literals, import statements, and dependency manifests for known model endpoints and client libraries identifies the presence of this capability. In the LameHug case the relevant signal is a call to a public model-inference API; the same class of signal covers commercial provider SDKs, cloud model-hosting routes, and local inference servers. This is a high-precision signal for the question “could this code call a model at all,” and a coarse one for “does it, on a reachable path, for a malicious purpose” — a gap Section 3.4 addresses.

3.2 Dynamic-execution constructs

Code that runs model output must pass that output to an execution primitive: a language-level construct such as eval, exec, or compile; a subprocess or shell invocation; or an interpreter embedded for the purpose, as in PromptLock's generation and execution of Lua. Locating these constructs is a classic static-analysis task — the parser identifies the call sites — and locating them where the argument is data rather than a literal string narrows the set to the interesting cases. As the companion paper notes, the presence of such a construct is not by itself evidence of anything malicious; these primitives have many legitimate uses [1].

3.3 The composition: execution of model output

The signal specific to LLM-enabled malware is neither of the above alone, but their composition: model output flowing into an execution primitive. This is the pattern by which a model's reply becomes the program's next action, and it is exactly the mechanism LameHug and PromptLock rely on. It also connects to an independently documented security concern — execution of model output as a remote-code-execution path, and prompt injection as the means of manipulating that output, listed as the leading vulnerability class for language-model applications by the OWASP project [10][11]. Detecting the composition requires establishing that model-derived data can reach an execution site, which in its precise form is a data-flow question (Section 3.4) and in its approximate form is the co-occurrence of a model call and an execution primitive in close proximity.

3.4 Data-flow refinement

The coarse signals of 3.1–3.3 report capability and proximity. A more precise and more expensive analysis builds a data-flow graph and asks whether a value originating from a model call feeds, directly or transitively, into an execution primitive or other externally-effective operation. This distinguishes code that calls a model and displays the result from code that acts on it autonomously. The technique is standard inter-procedural static analysis and inherits its costs and its incompleteness; it raises precision without escaping the limits of Section 3.5.

3.5 What these signals do not catch

Pattern-based static detection catches the honest and the careless. It does not catch a determined author who conceals the signal. The endpoint string can be assembled at runtime from fragments or decoded from an encoded form, so that no literal endpoint appears in the source. The execution primitive can be reached through reflection or dynamic dispatch, so that no direct call site appears. An attacker who hosts a private model on an arbitrary domain produces network traffic that no endpoint list distinguishes as a model call. And the general limit is undecidability: static analysis cannot in general determine a program's runtime behaviour, so no static method can be complete. These are not defects of a particular implementation; they are properties of the problem. The correct claim for in-code LLM-malware detection is therefore bounded: it reliably surfaces the fingerprints of malware that does not hide them, which describes the documented 2025 samples, and it is evadable by an adversary who invests in hiding them.

04Detecting Insider-Planted Backdoors: Why Snapshot Review Fails

The insider problem is harder, and the xz-utils case (Section 2.3) shows why in three separate ways, each of which defeats a different obvious defence.

The code is written to read as innocent. A competent insider does not write code that looks malicious; the entire craft is to write a change that survives review. Static vulnerability analysis is calibrated to find unintentional defects that follow recognisable anti-patterns. A deliberate backdoor is constructed precisely to avoid those anti-patterns. The two populations — accidental bug and intentional backdoor — do not share a detectable surface, which is why tools tuned for one are weak on the other.

The payload may not be in the reviewed source. The most important lesson of xz is that the malicious logic was not readable source code under review at all. It lived in binary test fixtures and was assembled by the build system. Any analysis confined to human-readable source in the repository's main tree would have found nothing, because the relevant bytes were elsewhere and in a form review does not scrutinise.

The reviewed artifact may differ from the shipped one. The xz backdoor was present in the release tarballs but not in an equivalent form in the visible repository history. This decoupling — between what a repository shows and what a release contains — is a general weakness: consumers of software receive built artifacts, and review effort is spent on source, and the two are not automatically the same object.

The consequence is stark. xz-utils is open source, in one of the most heavily reviewed dependency ecosystems in existence, and the backdoor was caught not by review, or by any scanner, but by one engineer's curiosity about latency. If the goal is a method that reliably detects a competent, patient insider from the content of their commits, no such method exists, and it is important to say so rather than imply otherwise.

05A Complementary Signal Class: The Shape of a Change

The failure in Section 04 is a failure of analysing the content of a change in isolation. A different class of signal is available that does not attempt to judge whether code is malicious, and instead measures whether a change is anomalous against a historical baseline — the project's own past, and the contributing author's own past. This class does not detect backdoors. It detects deviation, and deviation is what an insider attack produces even when the code itself is unremarkable. Run against the xz case, several such signals register where content analysis registered nothing.

5.1 Author-atypical change

Every contributor to a mature project has a history: the files they touch, the languages they work in, the subsystems they own. A change that departs sharply from a contributor's established pattern — a maintainer whose entire history is one subsystem suddenly modifying the build system, or introducing content of a kind they have never committed — is anomalous independently of whether the change is benign. In the xz case, the modifications sat outside the historical pattern of ordinary library development. The signal is computed from commit metadata and per-author file histories, not from the semantics of the code, and it therefore survives the insider's care in making the code itself look innocent.

5.2 File-type and location anomaly

The appearance of binary content in a directory that has historically held only text — a test-fixtures tree acquiring opaque binary blobs — is a structural anomaly detectable without understanding the content. This is precisely where the xz payload hid. A signal that flags new binary artifacts by location, against the historical composition of that location, points a reviewer at exactly the files that content analysis is least equipped to read.

5.3 Build-system churn

Modifications to build scripts, packaging configuration, and the machinery that assembles a release warrant attention disproportionate to their size, because they are the mechanism by which a payload absent from source can be introduced into an artifact. Churn in these files is measurable and comparatively rare in normal development; elevating it as a review signal directs scrutiny toward the assembly step that the xz attack exploited and that source review ignores.

5.4 Artifact–repository divergence

The decoupling described in Section 04 — a released artifact containing material not straightforwardly derived from the repository — is detectable by comparison: reproducing the build from source and comparing the result against the published artifact, or more coarsely, checking that every file in a release has a corresponding, reviewed source origin. Divergence is not proof of compromise; build non-determinism produces benign divergence. But an unexplained difference between what was reviewed and what was shipped is a pointer of exactly the kind the xz case needed and lacked.

5.5 The relationship to change measurement

The signals of 5.1–5.4 have a common character: they are all derived from measuring change over time against a baseline, rather than from inspecting a single snapshot. This connects the insider-detection problem to the broader body of work on code-churn measurement [12], which is concerned precisely with classifying and quantifying change between repository states and establishing what is normal for a given codebase. That the same measurement substrate serves both a quality objective and a security-triage objective is a property of the substrate, not a claim that either objective subsumes the other. The security application is younger and less validated, and should be described as an emerging use of change measurement, not an established detector.

06Evaluation Methodology and Honest Reporting

Any claim of detection in this domain should specify the conditions under which it holds, and several conditions are specific enough to enumerate:

• Adversarial assumption. Whether the reported detection rate is measured against naive samples or against an adversary actively attempting evasion. For in-code LLM-malware signals (Section 3), the two figures differ greatly, and only the adversarial figure describes the real threat.
• Base rate and false-positive cost. Backdoors and live LLM-malware are rare events in a normal change stream. A detector with any non-zero false-positive rate will, at a low base rate, produce mostly false alarms; the operating point must be reported with this in mind, and the cost of a false accusation of a contributor is high.
• Content-blind vs content-aware. Whether a signal derives from the semantics of code (Sections 3–4) or from the shape of change against a baseline (Section 5). These have different evasion resistance: content signals are evaded by writing different code; shape signals are evaded by behaving consistently with history over a long period — which the xz campaign, over two years, partially did, and which bounds the shape signals' power in turn.
• Ground truth. The scarcity of confirmed incidents makes evaluation difficult. Retrospective analysis of known cases (xz, LameHug) demonstrates that a signal would have fired, which is weaker evidence than prospective detection of an unknown case, and should not be reported as the latter.

The recurring theme is that overstated detection claims are their own hazard: a defence believed to be reliable is worse than a known absence of defence, because it misdirects the scarce human attention that, in every incident examined here, was the thing that actually worked.

07Summary

Two adversarial threats are, at the moment of commit, visible to repository analysis: malware that generates its behaviour by calling a language model at runtime, and backdoors planted by trusted insiders. For the first, the reliable in-code signals are model-endpoint egress, dynamic-execution constructs, and their composition — execution of model output — a target that runtime-generated malware cannot omit but can obfuscate; the honest boundary is that these signals catch the fingerprints of malware that does not hide them, and are evadable by an adversary who invests in hiding them. For the second, snapshot content review is structurally insufficient, as the xz-utils backdoor demonstrated by keeping its payload out of readable source and out of the reviewed artifact; a complementary class of signal, computed from the shape of a change against a historical baseline — author-atypical edits, file-type anomalies, build-system churn, artifact–repository divergence — does not identify malice but concentrates review attention where a planted backdoor is disproportionately likely to sit. Across both threats, the sound output of analysis is a pointer for a human reviewer, never a verdict. In every documented incident surveyed here, the decisive element was human attention; the role of tooling is to aim that attention, and its worst failure is to claim it can replace it.