Back Isc.Sans.Edu

ISC Stormcast For Thursday, September 3rd, 2026 https://isc.sans.edu/podcastdetail/10080, (Thu, Sep 3rd)

Isc.Sans.Edu • September 3, 2026

[This is a Guest Diary by Frank Igbokwe, an ISC intern as part of the SANS.edu BACS program]

Honeypot-Omaha is a DShied Sensor located at the Internet Storm Center (ISC) that is set up as a decoy for the original target and deployed over the internet. It is a flawed and very vulnerable system that was intentionally designed to attract threat actors with malicious intents. I view it as a massive log aggregator that collects data that an analyst like myself can then analyse, hypothesize, synthesize and then generate a cohesive and coherent report.

DShield Sensor uses a collective of tools to track internet threat actors, one of those packaged tools is called “cowrie”. It emulates port twenty-two and twenty-three, which are secure shell and telnet. Automation is at its rise and almost everything has been or would be automated at some point in time. From botnets to password brute force attacks to credentials scraping and gathering of data, we observe more automated activities.

Tools like hashcat and jack the ripper make credential collection easy. So, cowrie waits and listens on the decoy ports set up for DShield Sensor. It exposes these ports to the public facing internet and relays the data to a centralized station (ISC). Which logs every information that threat actor and its activities. “DShield.org” and the Internet Storm Center—founded by Dr. Johannes Ullrich in November 2000 out of the precursor site Incidents.org—provide valuable threat intelligence.

When a potential threat actor infiltrates the sensor, cowrie records their activities. Questions begin to arise like methods used to access the system, what vulnerability was exploited, did they succeed or fail at their attempts, what commands were used, where it was used, what was exfiltrated. With this valuable intel an analyst can build a time frame of when the activity started and ended. Answers to most of these questions asked would be revealed as we proceed.

The question is how do I correlate and gather all these data of interest, types, and structure. There are web logs, firewall logs, cowrie logs with credentials and other valuable information. I tried using tools like zeek for data behaviour correlation, carving, and analysis, rwfilter for metadata carving of specific fields of interest and converting to silk then my favorite tool, tcpdump for parsing network traffic packets.

All these tools are excellent tools but they are multiple tools that perform specific functions. I needed one tool that could consolidate all my logs of data, filter out the relevant data of interest and use those filtered consolidated data to answer all the questions asked on my internship template. For example, an analyst may want to get more information a specific internet address, and all the activities engaged by that address.

An analyst has to have a way to input an internet address or fully qualified domain name (FQDN) and it recursively gathers different data of interest related to that address, by searching and querying different “APIs” application programming interfaces for data.

Then converts the data into a tab separated value format, analyzes, correlates, gathers threat intelligence, common vulnerabilities and exposure (CVE), mitre, exploits, threat score, session id, hash and fingerprints, port numbers, geolocation, internet service and cloud service providers (ISPs or CSP) and a way to mitigate the threat actors activities.

This tool should be able to implement hashing mechanisms using any of the secure algorithms, for example using a combination of symmetric-asymmetric ciphers, and consolidating relevant data across a given directory into one view. Nothing complicated, just a simple script that synthesizes, consolidates data and brings all that into a focused, comprehensive, cohesive functionality and possibly more. Now you see where I am going with this delima.

All data are important but which ones are relevant to solving my internship questions. After a long research, I had an “Aha!” moment, you can call it an epiphany or what I call my “eureka” moment. That's where the idea of a “batch” process was formulated. I use my recently gained knowledge and skills of the python programming language to write a script called “batch.py”.

Batch is a script based on the python programming language, I wrote to assist me do most of what I described above. Here is the step by step breakdown of what it does. It is composed of “Four” integrated phases of the analysis processing pipeline. The fidelity of “batch.py” is based on the raw logs it parses. For now the logs must be located in the same directory as batch.py. I use secure copy (scp) to download my logs located on my amazon web services to a local directory on my computer. As a security conscious analyst, persistence security of data should be a priority. This is the start of “batch”, you can either log in as full admin or grant access to guests. To use the batch.py program you start by running a bash script on your local terminal window to generate a master password, I use a mac. It uses the secure hashing algorithm(SHA-256) to generate a master and a guest token.You have to generate a master password first by executing the bash script below.

Start: Generating master password or guest passcode. Authentication and verification are used to prevent unauthorized access to sensitive data. The principle of least privilege (POLP) is a necessary requirement for accountability, monitoring, and data loss prevention.

Select an option for the authentication process.

If option two is chosen and an analyst does not have a guest passcode, a message will be generated notifying the analyst that they need to have a guest passcode for them to access the program.

Select option 3 to generate a guest passcode and login.

After an analyst authenticates and is verified, the phase one process starts by gathering and feeding relevant data through the analysis pipeline, then converts the .json, .log, .gz, and any other relevant data to a .tsv file format. “TSV” stands for tab separated values.

The gathered intelligence data from querying ip-api.com , cve.org and paloaltonetworks.com are broken down into sections and fields to delineate the processing stages. With the integrated unified analysis pipeline design, batch.py is engineered for efficiency, low latency, and the rapid parsing of large volumes of logs.

Stage: 1 This displays on your screen showing a summary of the top 10 unique internet addresses that made with honeypot_omaha.

Stage: 2 As you can observe on what is displayed on the screen. I only have two cowrie protocols shown. There are more but on this stage I am focusing on just a few of the protocols used by cowrie.

Stage: 3 This displays on your screen the top 10 correlation of usernames to their respective internet address.

Stage: 4 This shows the top 10 correlation of passwords to their respective internet addresses.

Stage: 5 This displays the top 10 talkers with possible threat intelligence, attempts, geolocation, and their respective internet service and cloud providers. Not all top talkers are threat actors or have malicious intents. This requires the know-how and expertise of trained analysts to dissect and discern relevant data from noise.

Stage: 6 As an analyst, a long tail analysis of the data of interest will give you an idea of where to start your analysis. Sometimes threat actors use beaconing and command and control to relay data back and forth. Check for specific time intervals.

Stage: 7 Batch aggregates all the data it has parsed and gives a summary of how many attempts were made by the threat actors to an endpoint.

Phase 3 Generates a summary report and visual pie chart compilation.

Stage: 8 Compilation and summarization of data, using matplotlib to create the pie charts in a png file format and generating text document reports.

Phase 4 This phase displays an interactive an analyst can use to further examine and analyze data. It comprises six numbered points. Let's start with the first .

Stage: 9 An easy for an analyst to access detailed information on a given threat actor's internet address and activities.

1 Any artifacts found or indication of compromise will be displayed here using the program "less". Instead of having my data clutter and flood my screen, less seems like a better option.

2 This is a cumulation of all the exploits used by the malicious actors. It is a lot and it is sorted by the highest threat rating score.

3 Option three is used to navigate the pie chart options. An analyst has the choice of generating an individual chart or both.

It is always good practice to provide error feedback if the program fails to execute seamlessly.

The pie chart is dynamically generated once the pipeline is initiated. An analyst can choose any of the options to initiate the process of populating the pie chart with the data of interest, and displaying it on the monitor. Below is an example of a dynamically generated pie chart with all information.

The pie chart below shows the top talkers, protocols, usernames, and passwords.

Made using matplotlib.

4 This option is a quick console overview of what was found when batch executed and initiated the unified processing pipeline.

There are over four hundred file artifacts discovered. The data is viewed using the “ less” program, an analyst can use the built-in sort functionality to sort the data.

5 An analyst can query an internet address or fully qualified domain name and for more data related to that internet address. A " honeypot_Omaha_query_reoprt.txt " is generated.

After some analysis I observed that the threat actor made twenty-eight attempts and it shows a lot of the malicious actors' detailed activities. An analyst can use this consolidated view to analyze the data all in one screen. It displays the behavior analysis, pattern, utc timestamps, a count of how many attempts were made, the threat actors credentials and more.

Attempt number five displays the malicious actor’s secure shell client hash fingerprint: 2ec37a7cc8daf20b10e1ad6221061ca5 showing an established session. Attempt number 6 shows a failed login.

At attempt number eight, the threat actor used a different password. Attempt number nine shows the secure shell version used. An analyst can track session id, there are five recorded sessions made by the threat actor.

A new connection and login were successfully established at attempt number ten and eleven, batch displays the fingerprint and login details

The malicious actor has gained access to the system. I observed multiple commands executed on attempt number thirteen, such as exporting of the “usr/local/sbin”. This is the location that contains the system administration program tools and daemons installed locally by the owner of the system. “uname” and "Busybox” are visible, this threat actor gained and exfiltrated a wealth of information the compromised system. The threat actor is covering up its activities by using this command “rm -rf filter”. This command recursively deletes any file or folder that is named filter. The rm removes any shell commands used in a Linux operating system, -r stands for recursive, which is used to perform a deep granular deletion of data forcefully. I am going to make an educated guess**—**Basically, the threat actor is probing, gathering data, and cleaning up their tracks.

Connection lost on attempt number fifteen.

The malicious actor is now using a different password as displayed on attempt number sixteen.

A failed attempt was logged on attempt number nineteen and the connection was lost at attempt number twenty. Another attempt to re-establish a connection was successful as observed on attempt number twenty-four.

As an analyst, you are a step behind the threat actor and must follow whatever digital breadcrumbs they leave behind to understand their movements. Every action creates a pattern—often captured by the acronym “RIPLE” (Reconnaissance, Initial exploitation, Persistence-privilege escalation, Lateral movement, and Exfiltration of data). As I often say, if you throw a rock into a pond, it produces a ripple effect.

The relentless, defenseless assault on honeypot_omaha continued, as shown on attempt number twenty-six.

Connection lost again and the threat actor exited as displayed on the screen at attempt number twenty-eight. A summary report of the threat actors’ activities is generated below.

Reflecting back to the original questions at the beginning of the diary. How did the threat actor gain access to the system, what was exfiltrated, and how do I as an analyst go gathering more data for further investigation?

Recalling from the discussions, cowrie is designed to be vulnerable, so the malicious actor was able to guess the username and password.

Summary report on the shell commands executed on honeypot_omaha is generated and displayed on the screen.

The batch.py script performed a detailed query on the application programming interfaces of cve.org, paloaltonetworks.com and ip-api.com to generate and correlate intelligence data related to a suspected system compromise. It displays the threat rating score, status code, associated exploits, attack intent, and mitigation strategies. The targeted endpoints are sorted by their threat rating score and displayed below.

Reconnaissance and script profiling reveal the behavioral fingerprints of automated malware, botnets, or exploit payloads when they first gain access to a compromised shell**—in this case,** captured by honeypot_omaha as a “cowrie.command.input” event. Always practice persistence defense in depth, principle of least privilege’ and continuous diagnostics and mitigation. As an analyst, I was inquisitive the data and conducted Google research on the internet service provider called “Pptechnology limited” and the executed commands. Below is a description of the internet service provider and a breakdown of what each section of the command does:

PPTECHNOLOGY LIMITED : Often associated with the brand/network name PTechnology) is a corporate entity and network infrastructure holder that has appeared in cybersecurity research, threat intelligence reports, and UK corporate registries. Corporate Profile & UK Registration

Company Status: According to UK Companies House records, PPTECHNOLOGY LIMITED (Company Number: 12176225) was incorporated on August 27, 2019, and was officially dissolved on December 23, 2025. Registered Address: It was registered at a mass-registration virtual office address in London (35 Firs Avenue)—a location known for hosting thousands of distinct corporate entities. Registered Nature of Business: Officially classified under SIC code 96090 (Other service activities not elsewhere classified).

Threat Intelligence Context

In cybersecurity investigations (such as threat-hunting reports tracking offshore or "bulletproof-style" hosting infrastructure—notably research by firms like Team Cymru examining networks associated with anonymous hosting, ignore-DMCA setups, and malicious campaigns like Jingle Shells), PPTECHNOLOGY LIMITED has surfaced in analyses of proxy infrastructure:

Shell/Paper Companies: Security researchers have identified that shell and dormant UK entities like PPTECHNOLOGY LIMITED are frequently used as corporate facades or administrative holders for IP space and backend infrastructure associated with high-privacy or quasi-anonymous hosting environments.

Fraud Risk Scoring: Due to the nature of the IP blocks assigned to or historically associated with it, security scoring engines (like Scamalytics or VirusTotal) often flag traffic originating from these ranges as carrying higher risk or anonymity traits.

Note: The analysis above was performed by the analyst, using Google.com solely to research the internet service provider and executed commands. ----------- Guy Bruneau IPSS Inc. My GitHub Page Twitter: GuyBruneau gbruneau at isc dot sans dot edu

Guildma (Astaroth) malware infection from Brazilian Portuguese email

On Monday 2026-08-31, I used a link from a malicious Brazilian Portuguese email to infect a Windows host in my lab. This was a Guildma (Astaroth) malware infection.

The link from the email is geofenced for Brazil, meaning that it would only deliver the malware if I checked it from a Brazil-based IP address. Otherwise, it would send a legitimate installer (in this case for Android Studio) and not the malware. Furthermore, my web browser and operating system needed to use Brazilian Portuguese language settings and Brazil regional settings.

The initial downloaded file was a zip archive that contained a Windows shortcut. The shortcut retrieved content from a web server and saved it as an alternate data stream to a file created under the user's AppData\Local\Temp directory. This alternate data stream contained a 64-bit DLL file that doesn't appear to be malicious, but it was used to retrieve and install an AutoIt package for Guildma malware.

Today's diary shares indicators from the activity. Of note, many of the specific indicators like some of the SHA-256 hashes appear to be unique for this particular infection.

Images From the Infection

Shown above: Screenshot of the email.

Shown above: Malicious file downloaded from link in the email.

Shown above: Traffic from the infection filtered in Wireshark.

Shown above: Malware persistent on the infected Windows host.

Indicators of the Activity

Select headers from the email:

Received: from relatorio01a.colombstracciatella.cfd (unknown [185.254.222.105]) [information removed] ; Wed, 26 Aug 2026 22:01:41 +0000 (UTC)

Sender: "Contrato Via Docusing"

Date: Wed, 26 Aug 2026 19:01:16 -0300

Subject: Assine com o Docusing: CONTRATO_ASSINATURA_FINAL.40572684.BPSE.CONTRATOS.DIGITAIS.pdf

Link from the message text:

hxxps[:]//sistema-ekg3h4htc0h0ggdh.canadacentral-01.azurewebsites[.]net/

Downloaded zip archive and extracted Windows shortcut:

SHA-256 hash: cc44782356cb0effc528a7ab22c19ab360a55ebbbe01feb0967031aa191c5869

File size: 1,661 bytes

File name: 868283789726483.zip

File type: Zip archive data, at least v2.0 to extract

SHA-256 hash: 47d2908c4dd7f6f5eb4a8ef4306077b10315c44231f4bacd2bb811b245561911

File size: 1,553 bytes

File name: 868283789726483.lNk

File type: MS Windows shortcut

DLL saved as an alternate data stream during the infection, doesn't appear to be malicious:

SHA-256 hash: a6044786991afdb9d42ceb350943987765a7d0e8537369b2092e3f019c0f63ca

File size: 266,242 bytes

File type: PE32+ executable (DLL) (GUI) x86-64, for MS Windows

File location: C:\Users\ [username] \AppData\Local\Temp\n1LUQ7.log:h6JSb

Compiled AutoIt script for the persistent Guildma malware:

SHA-256 hash: f62a958faf0491b2b2803be2ee69b664b58e4a1261f64e8530cdc1a3ff666aa4

File size: 277,874 bytes

File location: C:\Users\Public\Libraries\.cache\PLAX\Beatz.LEDPRO.09662.8729.422.log

Domains the infected Windows host communicated with over HTTPS (TCP port 443):

ekg3h4htc0h0ggdh.canadacentral-01.azurewebsites[.]net

plosancol.aguamammillaria[.]cfd

crironxil.aguasedum[.]cfd

TCP traffic to another domain:

tcp[:]//omzagdmspc.a.pinggy[.]link:21601/

Note: I saw HTTPS traffic to WhatsApp and GitHub domains later during this infection, but those are legitimate domains, so I didn't include them in this write-up. A article has noted this campaign abusing GitHub, so I've included the mention here.

Bradley Duncan brad [at] malware-traffic-analysis.net

The Coding-Agent Trap: When a "Free" LLM Endpoint Is the Adversary

One of my internet-exposed inference honeypots was discovered, relabeled with sought-after model names, and incorporated into infrastructure apparently used to provide "free" LLM backends. It then received a real coding-agent session — history, filesystem output, working paths, and the agent's local tool manifest. The honeypot did not request or cause any tool execution; what the request exposed is what a malicious operator in that position could do.

Chasing the "free API key" is not new. What is new is what you get to chase now: not a key, but an agent — a client that arrives carrying its own file-read, file-write, and shell tools, asking a server whose identity and operator it may never have verified to decide what to do . Point that client at the wrong endpoint and its replies stop being just text: they can request tool calls that the agent, depending on its configuration, may carry out on the machine it runs on.

This is not a classic watering hole — nobody compromised a site or service the users already trusted. It is better understood as a rogue model endpoint : a server that agents are configured to trust as their reasoning backend. In a deliberate campaign an operator could go further and run it as an evil twin of a real provider — sought-after model names, advertised as free — and wait for tool-enabled agents to connect. This diary is one worked example, caught on a honeypot: an exposed endpoint that was scavenged, relabeled, and handed a real agent's session. The lesson underneath it: a model endpoint is not merely a source of text — for a tool-enabled agent, it is part of the control plane.

One session, and where it went

Start with the payload, because it reframes everything. On 2026-08-30 our honeypot received, 210 times in 91 seconds, a 224 KB request body: an 88-message transcript from opencode , an open-source terminal coding agent, originating from a Windows environment and delivered to us through a China Unicom address in Hebei that was apparently acting as a relay. A person had asked their agent (in Chinese) to study the writing style of two novels sitting in their Downloads folder. Across the earlier messages the agent had listed the directory, copied the files to %TEMP% , unpacked them, written a Python script to extract the text, and begun reading chapters — several PowerShell tool invocations among them. Then the user typed "jìxù" — continue. That request, with the whole history and tool manifest attached, is what landed on our server.

The request labeled the backend as DeepSeek — "model": "fofa-ds-NNNNN" — though the transcript cannot tell us who assigned that label or exactly what the user understood it to mean. Either way, it was reaching a honeypot that scanners had found the month before. Everything the transcript carried — the Windows username, directory listings, tool outputs, and portions of the files it had read — was now in our database, in cleartext, sent by a client presenting Authorization: Bearer free to an endpoint that did not validate it.

The client connecting to the honeypot was not an attacker. It was an ordinary user whose private agent session had been routed to an endpoint they did not control. The rest of this diary examines what a malicious operator could have done from that position.

The supply chain of "free"

Our honeypot answers on /v1/models , /v1/chat/completions , an Ollama-style /api/tags and an MCP server — all unauthenticated, advertising four unremarkable local models. It went live 2026-07-18. Here is how it became a DeepSeek:

2026-07-18 → 08-25: Baseline scanning. A spike on 07-22 (115 requests, 20 IPs) copies model names straight out of our /v1/models back into requests — sometimes the entire list pasted as one string, [nomic-embed-text:latest mistral-small:24b …] . Automated inventory, nobody .

2026-08-26: A client identifying as opencode/0.2.0 arrives and cycles through model names we never advertised: auto/best-coding , auto/claude-opus , auto/claude-sonnet , auto/best-reasoning . The behavior is consistent with probing which aliases the backend will accept. We answer all of them — HTTP 200, under 100 ms.

2026-08-27: A client calling itself NodeHealthCheck/1.0 (+local-lab) requests fofa-opus-NNNNN . This suggests the endpoint had been enrolled in a monitored backend pool.

2026-08-30 06:59: opencode/0.2.0 requests fofa-sol-NNNNN , fofa-ds-NNNNN and fofa-opus-NNNNN within three seconds — three aliases for one backend, in a pattern consistent with backend validation. Later the same morning it also tries agentrouter-org/claude-opus-4-8 and bailian/deepseek-v4-flash-0731 : names suggestive of other routing or provider-list conventions, pointed at the same IP.

2026-08-30 08:07: A Go-http-client/2.0 from a China Unicom (Hebei) address — apparently a relay — sends the opencode transcript 210 times in 91 seconds.

The naming scheme strongly suggests the whole arrangement. fofa is FOFA , China's internet-wide engine — a plausible place the endpoint was found. ds / opus / sol read as aliases for DeepSeek, Claude Opus, and a GPT variant (the gpt-5.6-sol probes three days earlier point to "sol"). And the numeric suffix — the same across all three aliases, masked here as NNNNN — is not a channel id: it matches the endpoint's own public IP octets. The convention is - - : that is how you label entries in a hand-kept list of scavenged endpoints, and it is why we have masked it here.

The scheme appears to have propagated across multiple clients or infrastructure nodes: the same three aliases were exercised from a Vultr host, a Cloudflare egress, and the China Unicom relay, plus a separate health-checker — four vantage points, one naming scheme, one target. And the credential on 247 of the 248 requests was the same: Authorization: Bearer free — the "key" is the word "free". The evidence supports a plausible distribution chain: a scanner indexes exposed endpoints; someone assigns friendly aliases and folds them into a pool of "free models"; that configuration propagates into agent clients or relays. The Go-http-client/2.0 user-agent is consistent with a Go-based intermediary but does not identify a particular product. We did not recover the list or its maintainer — we observed steps consistent with such a chain.

What the endpoint operator receives

Whoever operates or compromises the endpoint that entry points to receives this, verbatim, with every request:

This is more than prompt leakage. The transcript already contains filesystem-derived data, and the tool manifest exposes potential paths back into the local filesystem and shell, with the user's own OS and paths filled in. The read tool creates a potential arbitrary-file-disclosure path within the paths and permissions available to the agent: a malicious endpoint could with a tool_calls asking to read .aws/credentials or an SSH key, and if the agent is permitted to read that path, the contents would return in the model request. No exploit, no CVE — the client volunteers the capability.

What the endpoint operator can do

Because the request advertises bash and tool_choice: auto , the operator's can become a command-request channel. The following is the relevant core of an OpenAI-compatible tool-call response; unrelated envelope fields ( id , object , created , model , index ) are omitted:

Whether that command runs without the user seeing a prompt depends on the agent's permission model, and here the news is bad. Opencode's current default build agent permits most operations — including bash , read , and edit / write — without approval. The transcript we captured is a build-agent session that had already carried out multiple PowerShell invocations. In that default configuration a malicious may execute without an additional user-approval prompt. A user can tighten these permissions, and --auto can further weaken approval boundaries. The important point is that the endpoint cannot know which protections are enabled — and a permissively configured client may carry out the request without intervention. (These defaults are from the current opencode permissions documentation; the exact behavior of the observed opencode/0.2.0 build may differ by version.)

We did not send a tool call. Our honeypot answered all 210 requests with a fixed prose string and finish_reason: stop — which likely explains the 210 retries: a relay expecting a stream, rejecting an answer it could not parse. But "we returned prose" is a choice we made, not a protection the user had. Anyone holding that endpoint could have returned the JSON above instead. Whether it then ran is not something we can assert in the abstract: the transcript proves the commands executed, but it cannot by itself prove no human approved them — any approval prompt lives in the local UI, not in the request sent to the model. What it does show is a build agent carrying out PowerShell invocations, consistent with bash at "allow" ; for a session configured that way, a malicious can run without a further prompt.

Hypothesis, stated as one: if agents with permissive tool defaults keep arriving at scavenged "free" endpoints, then standing one up is a cheap, targeted way to attract them — a rogue endpoint that needs no phishing and no vulnerability, because the victims come to it, lured by "free". We have the arriving agents and the open door. We do not have proof of an operator weaponizing the ; we would not run that experiment. The gap between "can" and "did" is the honest boundary of this finding, and it is exactly the gap defenders should close before someone else measures it.

Why this will keep happening

The economics point one way. For the attacker the cost can be modest: an OpenAI-compatible service and enough inference capacity to appear legitimate to selected clients; discovery is done for free by FOFA and Shodan; delivery is done for free by whoever curates and shares the "free models" list. The users come to them , presenting Bearer free and their tool manifest. For the user the incentive is equally clear: frontier models cost money, "free DeepSeek" does not, and an agent config is one baseURL line. The two incentives meet on an exposed endpoint. Our honeypot advertised nothing desirable and still went from first scan to serving a real agent's session in six weeks, and from apparent pool enrollment to live agent traffic in four days. And a deliberately malicious endpoint could return plausible completions for days or weeks and reserve the tool call for a chosen session — until activation, its traffic would look like ordinary inference. Our honeypot did not achieve that (it returned a fixed response that apparently did not satisfy the relay and triggered retries), but such selective activation is well within an operator's reach.

Defending against rogue model endpoints

If you use AI coding agents

Treat a model baseURL the way you treat curl | sudo bash : it identifies a remote party that may be allowed to request operations from your local shell. Only point agents at inference infrastructure you operate yourself, or at providers whose identity, ownership, and security practices you have verified — paying for a service does not, by itself, make its operator trustworthy.

Review tool permissions before connecting the agent. A permissive configuration for bash , write , and read can turn one malicious model response into a silent local action. Require approval for sensitive tools, restrict filesystem access, and never use --auto with an untrusted endpoint.

If you monitor coding-agent egress

Treat the model endpoint as part of the agent's software supply chain. Maintain an allowlist of sanctioned inference providers and alert when an agent connects elsewhere. Useful signals include:

Agent clients connecting to inference hosts outside the approved provider list.

Unrecognized values in the model field, including fofa-* , shodan-* , auto/* , agentrouter-* , or providers your organization does not use.

Token values inconsistent with approved provider configurations — especially literals such as free .

Large outbound chat-completion requests containing tools[] , tool_choice , role: "tool" messages, filesystem paths, or command output.

When this occurs, identify the affected agent configuration, stop further communication with the endpoint, determine what conversation and tool output were transmitted, and rotate any credentials or secrets that may have entered the session. The model operator has already received the preceding context; changing the endpoint prevents further exposure but does not recover what was sent.

If you operate an inference endpoint

Do not expose an endpoint publicly unless that exposure is intentional, authenticated, monitored, and appropriately rate-limited. An unauthenticated endpoint can be indexed, relabeled, and enrolled as someone else's "free" backend. Signals that this has happened include:

Requests for model names you never advertised or deployed.

Aliases containing a -engine label, or ending in the octets of the endpoint's own IP address.

Authorization: Bearer free , or another credential you never issued.

Agent-shaped bodies containing tools[] , tool_choice , and role: "tool" messages when the endpoint was not intended to serve coding agents.

Bursts of byte-identical requests — such as the 210 requests in 91 seconds observed here — consistent with relay retries.

These signals should trigger exposure remediation and careful handling of third-party data — not automatic attribution of the source addresses as attackers. Authenticate or remove the endpoint, investigate how it was indexed or distributed, restrict access to received content, and minimize its retention.

Agent transcripts can also trip naive exploit rules, because they contain strings such as powershell , URLs, and shell commands. A tools[] manifest, tool-role messages, and commands in assistant turns support the interpretation that the request carries a relayed agent transcript rather than a direct exploit attempt, but do not prove benign intent. The following were weaker contextual artifacts in this incident and should not be used as standalone indicators: opencode/0.2.0 , Go-http-client/2.0 , NodeHealthCheck/1.0 (+local-lab) , stream_options.include_usage: true , and the auto/* model family.

We are deliberately not publishing the connecting IP addresses. They may belong to users, relays, proxies, scanners, or shared infrastructure, and should not be treated as attacker infrastructure without additional evidence. The portable signal is the behavior: an agent sending its context and tool capabilities to an endpoint it should not trust.

Mapping this to MITRE ATLAS

The downstream behavior maps reasonably well to AI Agent Tool Invocation ( AML.T0053 ): a malicious model response could cause the agent to invoke its locally available tools. The initial trust relationship is less clearly represented. In that pattern the model-serving endpoint would itself be the adversarial component: operated by an attacker from the outset, or taken over after legitimate deployment. Our honeypot was neither — it demonstrates the discovery, relabeling, adoption, and data-exposure path such an operator could exploit. AI Supply Chain Compromise ( AML.T0010 ) is the closest existing technique, but its current sub-techniques do not explicitly cover a remote inference service adopted as an agent's model backend. The data-return path is also distinct from Exfiltration via AI Agent Tool Invocation ( AML.T0086 ), which describes exfiltration through write-capable tools; here a file read would return to the rogue endpoint through the agent's normal inference loop.

We are submitting this pattern to the MITRE ATLAS team for consideration — tentatively a Model Serving Endpoint sub-technique, with AML.T0010 as the closest current parent — supported by this real-world honeypot observation. This mapping is a secondary, analytical note: the finding stands on its own regardless of where ATLAS ultimately places it. The honeypot observation demonstrates exposure of real agent context and tool capabilities; it does not demonstrate malicious tool execution, which remains the risk scenario evaluated here, not an observed event.

-- Renato Marinho | Twitter

SANS Stormcast Thursday, September 3rd, 2026: SMA1000 0-Day Patch; SSRF Validation Issues; Faronics Abuse