Group Purchasing
Group Purchasing

Investigating AI Tools and Modern Linux Intrusions

Authored byTarot (Taz) Wake
Tarot (Taz) Wake

In June 2026, attackers poisoned more than 1,500 packages in the Arch User Repository. One of the interesting aspects of this attack was that the malware wasn’t in the applications themselves. It rode in on the build scripts, which pulled rogue dependencies that dropped a Rust infostealer and, on systems where they gained root, an eBPF rootkit that hid its own tracks at the kernel level. For a lot of IR workflows, this would look like a clean system.  

This gap, between what standard tools report and what is actually happening, defines modern Linux incident response. This blog looks at four areas where the gap is widening: kernel-level stealth, software supply-chain compromise, self-hosted AI services, and the agent and plugin ecosystem now wired into them. In each case the question is the same: where does the evidence actually live? 

The Kernel-Level Stealth Problem 

The rootkit in the Arch repository poisoning is worth a second look. eBPF was built to make the Linux kernel observable and programmable without loading a traditional module, and that same power lets modern kernel-level malware intercept system calls and conceal processes, files, and network connections. This means that the output of ps, ls, and ss can’t be taken at face value. 

Hunting this means refusing to trust the system's own summary of itself, and it really means using several independent views:  

  • Reviewing loadable kernel modules with lsmod and modinfo exposes modules whose origin or signing status makes no sense.  
  • Scanners such as chkrootkit and rkhunter check for known rootkit traces, and manual review covers what the scanners miss.  
  • An eBPF-based monitor such as Kunai records process, file, and network events from the kernel as they happen, which gives a record that a compromised host cannot quietly edit afterward.  
  • Live analysis of /proc adds a further view of running processes and their open files and sockets.  

Investigators also learn where this activity leaves marks, including the kernel object directories under /sys where pinned eBPF programs and unusual kernel allocations can show up. 

Related stealth techniques belong in the same investigation. Mount and PID namespaces let an attacker show one view of the filesystem or process table while running something different underneath, and bind mounts can make a path misrepresent its contents. 

Poisoned Packages 

The Arch repository attack is a reminder that the software build pipeline is now a stealthy delivery route. Nothing in the published applications looked wrong, because the malicious behavior was injected through build scripts that pulled attacker-controlled npm dependencies during installation. We are used to looking for malicious software files, but are we as used to reviewing the processes that assemble the software? 

Ultimately this changes where we need to look. Package-management analysis lets us understand what a given package actually did when it was installed: which scripts ran, which dependencies were fetched, what files were written outside the expected paths, and when. On Debian and Red Hat systems alike, package metadata and logs record far more about installation activity than most investigators routinely use. 

The next step is triaging whatever the package dropped. The Arch payload was an ELF binary, a Rust infostealer that collected SSH keys, shell history, browser cookies, and API tokens. Reading an unknown ELF file is a skill in itself. It involves examining the headers and linked libraries, checking how the file loads, and/or using a capability-analysis tool such as CAPA to summarize what the binary can do, including network communication, file collection, and process injection, without running it.  

Package investigation and binary triage together allow us to answer two big questions: how did this binary get here, and what does it do? Comically, that turns out to be about 75% of all IR tasks. 

Investigating Self-Hosted LLMs 

Organizations increasingly run their own language models rather than sending data to a third party, and that infrastructure has arrived faster than the security practices around it. Internet scans through 2026 found large numbers of exposed Ollama servers, with tens of thousands reachable on the public internet and many of them carrying no authentication at all. A memory-disclosure flaw nicknamed Bleeding Llama went further, letting an unauthenticated request pull prompts, system instructions, and environment variables straight out of the running process. A self-hosted model is a service with a configuration, a process, and files on disk, and it should be investigated as one. 

When faced with an incident involving a local AI platform, your first sensible question is likely to be, where do I find the evidence? Ollama and similar platforms keep model files, configuration, and logs in predictable locations, and the models can be checked for integrity against their expected digests to detect tampering or substitution. Conversation history and any retrieval (RAG) data stored give a record of what was asked and what the system had access to. On a live host, the running process, its listening sockets, and its environment show whether the service was exposed and who could reach it. 

Realistically, the important bit here is that we have to rethink a lot of our workflows. An “intrusion” into an LLM might be nothing more than sneaky prompts. Compromise is by natural language statements, not just exploiting vulns. Exfil can look identical to a normal user’s activity. This isn’t going to stop us, but it does mean we have to adapt our IR workflows. 

Agentic AI and its Problems 

Language models become more capable, and more exposed, once they can call tools. The Model Context Protocol (MCP) transformed how people use AI/LLM platforms. It opened the door for an entirely new way of operating, but that also carries a considerable potential problem.  

In April 2026, researchers at OX Security described an architectural weakness in how MCP's standard input/output (stdio) transport is configured. The flaw allowed arbitrary command execution, affected more than 7,000 reachable servers across packages totaling over 150 million downloads, and included an attack in which editing an MCP configuration through a zero-click prompt injection led to code execution. The vendor characterized the behavior as expected, so responders should assume it will persist in the field. 

This sits alongside prompt injection, which OWASP rates the leading cause of failures in production agentic AI. The mechanism is easy to state. Untrusted content such as a web page, a document, or a support ticket carries instructions that the model follows as if they came from the user, and the result can be data exfiltration through a connected tool or a retrieval store. 

Investigating these cases means treating the agent's plumbing as evidence. MCP configuration files and tool invocation records show what the assistant was permitted to do and what it actually called. Installed plugins and their manifests reveal what was added and when. Correlating an injected instruction with a downstream host effect is what ties intent to impact. National-level guidance now exists as well, with NSA and CISA publishing MCP security guidance in June 2026, which shows the topic is a mainstream concern.  

What Does This Tell Us? 

These are not edge cases. They are the incidents we are being asked to investigate right now, and handling them means we need to understand both deep Linux internals and the AI systems we find everywhere in our networks. This is the problem FOR577, the Linux Incident Response Class, is designed to solve. The class provides six days of hands-on investigation into filesystems, executables, running processes and much more, working realistic attack scenarios, and tackling a challenging team-based capstone to finish. If your work touches Linux, and most of ours does, this is how we get ready for what is already out there. See the full syllabus and upcoming dates at sans.org/for577

News and Incident Sources 

Truesec (16 June 2026). Supply Chain Attack Compromising Arch Linux AUR Packages with Infostealer and Rootkit. https://www.truesec.com/hub/blog/supply-chain-attack-compromising-arch-linux-aur-packages-infostealer-rootkit 

Arch Linux (June 2026). Active AUR malicious packages incident (official notice). https://archlinux.org/news/active-aur-malicious-packages-incident/ 

The Hacker News (20 April 2026). Anthropic MCP Design Vulnerability Enables RCE, Threatening AI Supply Chain (research by OX Security). https://thehackernews.com/2026/04/anthropic-mcp-design-vulnerability.html 

The Hacker News (January 2026). Researchers Find 175,000 Publicly Exposed Ollama AI Servers Across 130 Countries. https://thehackernews.com/2026/01/researchers-find-175000-publicly.html 

LeakIX (February 2026). 12,000 Ollama Instances Exposed: When Local-First Meets the Real World. https://blog.leakix.net/2026/02/ollama-exposed/ 

Help Net Security (11 June 2026). Prompt injection still drives most agentic AI security failures in production (OWASP). https://www.helpnetsecurity.com/2026/06/11/owasp-prompt-injection-ai-security-failures/ 

NSA / CISA (2 June 2026). Model Context Protocol (MCP): Security Design guidance. https://media.defense.gov/2026/Jun/02/2003943289/-1/-1/0/CSI_MCP_SECURITY.PDF