From CVE to Cloud Creds: LLM Agents Inside the Network
Just caught the report regarding CVE-2026-39987. It looks like an unknown threat actor exploited a public-facing Marimo notebook and, rather than running standard shell scripts, they deployed a Large Language Model (LLM) agent to handle post-exploitation.
For context, Marimo is a Python-based reactive notebook library. The attacker leveraged the vulnerability to gain initial access and then used an LLM agent to autonomously navigate the environment and extract two cloud credentials. This is a significant shift from manual command-and-control; the agent effectively 'read' the system state and 'decided' how to exfiltrate the assets.
Since this is Python-based, we need to monitor for abnormal child processes spawned from the notebook server. If you have Marimo instances exposed, you should immediately scan for processes attempting to reach external LLM APIs.
Here is a quick bash command to check for environment variables leaking in the memory space of running Marimo processes:
for pid in $(pgrep -f "marimo"); do
echo "Checking PID: $pid"
strings /proc/$pid/environ | grep -E "(AWS_|AZURE_|GOOGLE_APPLICATION_CREDENTIALS)"
done
From a network standpoint, if your notebook servers shouldn't be talking to AI endpoints, block them. Here is a basic KQL query for Sentinel/Defender to hunt for outbound connections to known LLM providers from Python processes:
DeviceNetworkEvents
| where InitiatingProcessFileName has "python"
| where RemoteUrl contains "openai.com" or RemoteUrl contains "anthropic.com"
| project Timestamp, DeviceName, InitiatingProcessCommandLine, RemoteUrl, RemotePort
Is anyone else seeing attempts to weaponize internal AI tools, or are these attacks primarily relying on external API calls triggered by the attacker?
We saw a similar spike last month in our honeypot environment. The scary part is the 'reasoning' capability of these agents. They don't just brute force; they try specific file paths based on common cloud CLI configs.
I'd recommend adding a Sigma rule for python spawning curl or requests to non-whitelisted endpoints. If you use AWS, you can also use CloudTrail to detect API calls that come from unexpected user agents, as these agents often leave distinct signatures.
This reinforces why egress filtering needs to be granular. Dev teams love their notebooks, but a Marimo instance should never have direct internet access if it's processing sensitive data.
We use an App Gateway or proxy to inspect outbound traffic. If a notebook tries to hit api.openai.com, it gets blocked immediately unless it's on a specific allow-list for a trusted CI/CD pipeline.
Great catch on the environment variables. Often these notebooks are started with --notebook-dir pointing to a user's home directory, which might contain .aws/credentials or .kube/config.
If you are pentesting, try interacting with the local LLM if one is installed on the target instead of calling out. Sometimes the internal model has access to internal docs that help the attacker map the network faster than standard recon tools.
To catch this, you need visibility into file access, not just network traffic. A Marimo process reading credential files is a huge red flag. I recommend adding an auditd rule to monitor these specific paths:
-w /home/user/.aws/credentials -p wa -k aws_access
-w /home/user/.kube/config -p wa -k kube_access
Also, cross-reference your backup logs. If an LLM agent is exploring, they might try to enumerate or access backup repositories to ensure maximum damage.
Solid points on the file access risks. Beyond just monitoring, we should eliminate the target. If you're running these notebooks in a cloud environment, pivot to IAM Roles for Service Accounts (IRSA) or instance profiles.
If the creds aren't in the home directory, the LLM agent can't exfiltrate them via file reads. You can quickly audit your exposure by scanning for static keys with:
find /home -name "credentials" -o -name ".env" 2>/dev/null
Removing these files forces the use of short-lived tokens, limiting the blast radius.
Great discussion. Since the attacker deployed an agent, that agent likely needs to reach an external LLM API to function. Standard data science pods usually talk to storage or internal APIs. You can detect this anomaly by filtering egress traffic for connections to known AI providers from notebook namespaces.
Here’s a quick Falco rule snippet to catch this:
- rule: Notebook Connects to LLM Provider
condition: >
fd.type=connect and
k8s.ns.name=notebooks and
fd.sname in (api.openai.com, api.anthropic.com)
output: LLM agent detected connecting to external provider (user=%user.name command=%proc.cmdline)
This helps distinguish between standard data exfil and AI-assisted post-exploitation.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access