The last update to the DShield SIEM [4] was in Sep 2025 which contained some minor tweaks. This update currently is using ELK stack version 8.19.15, contains some additional dashboards and new logs.

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

This patch Tuesday includes a staggering 622 vulnerabilities, not including another 427 vulnerabilities in Chromium, affecting Microsoft's Edge browser. 62 of the vulnerabilities are rated critical. One was disclosed before today, and two have already been exploited.

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|

The setup

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

Wireshark release 4.6.7 fixes 12 vulnerabilities and 16 bugs.

Didier Stevens
Senior handler
blog.DidierStevens.com

Anyone who deals with phishing messages caught by basic security filters knows that most phishing samples tend to blend into one another, since only a small set of techniques and approaches keeps reappearing in them. That is precisely why it is worth pausing on the occasional message that does something a little out of the ordinary.

One such unusual message was caught on Tuesday by an e-mail security solution used by one of my clients. At first glance, both the e-mail body and the attached credential-stealing HTML page looked entirely generic, however, the fact that the attachment was fairly large, and that Outlook claimed the date on which the e-mail had been sent was “None”, caught my attention and made me take a second look… Which was fortunate, because it appears that the large size of the attachment might be connected to the increasing role that AI is playing in e-mail security in an interesting way.

Before we get to the attachment, however, the phishing message itself deserves a brief mention, since several small details in its headers suggest that it was not sent through any normal mail path, but rather generated by a simple, homemade script.

The e-mail presented itself as a Microsoft Teams notification about a document shared over SharePoint, with another document attached directly to the message (note the text “None” in the upper right corner where a date should be).

As you can see, the “From” header claimed that the message came from “Microsoft Teams Notifications <Microsoft@sharepoint.com>”. Unsurprisingly, this actually wasn’t the case…

When looking at the headers, three interesting points stood out:

1. It turned out that the envelope sender was empty (i.e., “MAIL FROM:<>” was used). In principle, the use of an empty envelope sender – which is called a “null reverse-path” – is perfectly legitimate[1]. It is what bounce messages are supposed to use, so this was not a violation of any standard. It did, however, mean that there was no envelope domain against which SPF could be evaluated, which is why the receiving system fell back to the “HELO/EHLO” identity and ended up checking “postmaster@[10.88.0.3]” – i.e., an internal/RFC 1918 address presented by the sending host (which was actually hosted on the public IP 35.195.254.112 in the Google Cloud). Since we mentioned SPF, it is worth adding that no DKIM signature was present either (for obvious reasons), and that DMARC evaluation therefore unsurprisingly failed.
2. The message carried no “Date” header whatsoever, which was the reason for the “None” date shown by Outlook. Unlike the empty envelope sender, this is against standardized requirements, as RFC 5322 requires an “origination date” field to be present[2]. A message put together by any normal e-mail client (or sent through a normal e-mail server) would essentially always have one, so its absence is telling.
3. The “X-Priority” header was set to 0. This header was never formally standardized in an RFC, but per Microsoft’s specification[3], which is the de-facto authority for it, only the values 1 (highest) through 5 (lowest) are defined, so a “0” is outside the meaningful range.

While none of these oddities were especially remarkable on their own, taken together they painted a fairly clear picture of the tooling used to send the message – it was most likely a homemade script that interfaced directly with a receiving e-mail server and handed the message to it, without any standard e-mail server being involved on the sending end.

With that out of the way, let's take a closer look at the attachment.

The attached file was named “<name of company>_Pending_Approvals#<digits>.xls.html”, and its most immediately noticeable characteristic (besides the double extension) was its size. At 2,589 kB, it was significantly larger than one would expect a self-contained HTML phishing page to be, since these usually take up no more than a few tens (or at most hundreds – if images are included) of kilobytes.

The reason for this became clear as soon as the file was opened in a text editor. The entire contents were wrapped in a single layer of trivial obfuscation – the whole page was stored as a long sequence of “\uXXXX” escapes and handed to the “unescape()” JavaScript function inside a “document.write()” call.

<script type="text/javascript">document.write(unescape("\u003c\u0021\u0044\u004f\u0043\u0054\u0059\u0050\u0045\u0020\u0068\u0074\u006d
...
\u0058\u0058\u0058\u0058\u0058\u0058\u0058\u0058\u002d\u002d\u003e"));</script>

Once the escaped string was decoded, only 431 kB of HTML were left. Of that size, though, only the first 11 kB or so constituted an actual, working phishing page, while the remainder was padding. This padding was placed after the closing “</html>” tag and was made up of a single HTML comment containing a little over 430 thousand copies of the letter “X” (originally encoded as “\u0058”, which you can see above).

It is worth pointing out that the file size was, in effect, “inflated” twice over – first by the aforementioned ~420 kB comment, and then by the “\uXXXX” encoding, which stored each character (padding included) as six bytes. Between the two, the block of “X”s ended up accounting for something on the order of 2.5 MB, i.e., roughly 97 % of the entire file.

While phishing pages bloated with large quantities of copy-pasted, unused content are not new[4], in this case the padding is interesting because of what it might have plausibly been aimed at.

The classic reason for padding malicious files is covered by the MITRE ATT&CK “Obfuscated Files or Information: Binary Padding” sub-technique[5]. In short, threat actors may append a large, low-entropy blob to a file in order to push its size past the maximum that anti-malware engines are configured to scan, while keeping the file easy to compress (and therefore still convenient to deliver). While not as common as run-of-the-mill obfuscation, malware using this technique can be found in the wild reasonably often[6,7].

This sub-technique, however, does not quite fit our sample. Even leaving aside that the attachment is padded using a comment rather than a binary blob, at 2.5 MB the file falls well short of the scan-size limits used by present-day e-mail security solutions, which usually process attachments well into the tens of megabytes.

The padding is also about as low-entropy as any data can get, which means it wouldn’t help the file blend in with benign content on a statistical level either (if anything, a huge block of identical bytes would be trivial to spot and would make the file look more anomalous, not less). Whatever the padding is meant to defeat, in other words, it does not appear to be the sort of size or entropy-based checks that techniques traditionally used in phishing try to bypass…

One thing that has changed in the area of e-mail security over the past couple of years, though, is that a growing number of solutions have started to incorporate some form of NLP or AI-based mechanism for assessing message content, and this is where the padding might begin to make sense.

Earlier this year, KnowBe4 described a phishing technique they refer to as “NLP obfuscation”, in which malicious content is placed at the start of a message and then buried under a large amount of benign-looking filler[8]. According to their analysis, this can shift the “probability scale” that some content-classification models rely on – basically, if a message contains enough innocuous material, the weight of the malicious portion can be diluted to the point where the model no longer flags it with sufficient confidence. The same bulk can also make a message large enough so that scanning it using AI-based mechanisms takes too long, leading some solutions to release it rather than delay delivery indefinitely.

Although our attachment doesn’t fully match the samples described in the aforementioned analysis (the filler here is a single repeated character rather than natural-looking text) its overall structure (i.e. payload first, followed by filler) is the same.

If some form of AI or NLP-based content assessment was indeed the intended target, the padding would work not by disguising the “malicious” portion of the HTML file, but simply by drowning it out. Whether the message was scored by a traditional content classifier or passed to an actual LLM, the genuinely malicious portion would end up as a tiny fraction of a large, low-information whole, which might have been enough to pull an averaged or probability-based verdict below the threshold at which the message would be blocked. And since the bulk of the file carries no meaning, the same padding may serve a second, cruder purpose – inflating the sheer volume of data (and, for an LLM, the number of tokens) that has to be processed to the point where a scanner working under a per-message time or size budget would cut its analysis short, or skip it altogether[9].

Of the two, the second goal strikes me as the more likely one here. It is consistent with where the padding was placed – after the payload, where it does nothing to actually conceal the malicious portion of the HTML code – and it is the one objective for which a featureless block of “X” works just as well as carefully crafted filler, which would also explain why the author saw no need to use anything more elaborate.

I should stress that all of the above is, ultimately, only an informed speculation – short of asking the author of the phishing, there is no way to know for certain what they had in mind. It should also be said that, against any reasonably capable model, a solid block of a single repeated character would be a blunt instrument at best, since it is trivially recognizable as padding (see the entropy chart below).

For the sake of completeness, it should be mentioned that the functional part of the attachment was an otherwise unremarkable SharePoint-themed credential-harvesting page. It attempted to load the recipient organization’s logo dynamically through the Clearbit logo API, though, as the figure below shows, the lookup failed and a placeholder (image with Microsoft squares) was displayed instead… Which is unsurprising given that the free Clearbit logo API was shut down at the end of 2025[10] – this in itself is a small sign that the page was assembled from older, borrowed or LLM-generated code. Any credentials that were entered would be submitted through a POST request to the Formspark form-handling service[11], which was being misused as a convenient data collection point. The page additionally contained a routine that intercepted the developer-tools and view-source keyboard shortcuts – a trivial and fairly common anti-analysis feature[12].

[1] https://datatracker.ietf.org/doc/html/rfc5321#section-4.5.5
[2] https://www.rfc-editor.org/rfc/rfc5322.html#section-3.6
[3] https://learn.microsoft.com/en-us/openspecs/exchange_server_protocols/ms-oxcmail/2bb19f1b-b35e-4966-b1cb-1afd044e83ab
[4] https://isc.sans.edu/diary/32510
[5] https://attack.mitre.org/techniques/T1027/001/
[6] https://isc.sans.edu/diary/26464
[7] https://isc.sans.edu/diary/30524
[8] https://blog.knowbe4.com/nlp-obfuscation-techniques-email-security-evasion
[9] https://genai.owasp.org/llmrisk2023-24/llm04-model-denial-of-service/
[10] https://developers.hubspot.com/changelog/upcoming-sunset-of-clearbits-free-logo-api
[11] https://formspark.io/
[12] https://isc.sans.edu/diary/30412

-----------
Jan Kopriva
LinkedIn
Nettles Consulting

The stack is a memory region where a program stores temporary data - like local variables and return addresses. Think of the stack as a pile of plates in your kitchen: you can only add a new plate to the top, and you can only take one away from the top too. Programs use this same "last in, first out" principle to keep track of what they're doing. Every time a function is called, the program pushes a new plate onto the stack containing things like local variables and the address to return to once the function finishes. When the function is done, that plate is popped off the top, and execution resumes exactly where it left off. This simple mechanism is what allows programs to call functions within functions, and always find their way back - but it's also precisely why a stack that grows too large, or gets overwritten with unexpected data, becomes a favorite target for attackers looking to hijack a program's execution flow.

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

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

Every so often a honeypot hit comes along that is less about the exploit and more about the intent behind it. While reviewing DShield logs I ran into a scanning bot that caught my eye: a URI string that appeared to be a plea for help.

On 2026-06-06 my DShield honeypot logged back-to-back HTTP requests from the same source IP hitting two different ports with both carrying an identical, oddly formatted request path:

The request path itself /?_HELP_ME_ESCAPE_FROM_BELARUS_PLEASE_ is not a known exploit path, it appeared to be a plain-text message in the URL. Searching my logs for that particular string returned around a dozen similar HTTP requests over a 2 months period. These came from various IPs from around the globe with no discernible pattern which pointed to a self-propagating bot rather than a single attacker.

Further research showed that this bot was first reported to ISC in May 2026. The number of reports peaked shortly after the first report before a sharp drop and has remained steady since. [1]

I was unable to locate much more information about this bot other than a reddit thread on r/selfhosted describing the same requests hitting a Traefik reverse proxy. According to that thread, the user emailed the address embedded in the User-Agent and received a reply pointing to a page on a free web-hosting service. The page is a static HTML document with no scripts and it lays out what the bot is & why it exists.

The author, who identifies himself only as “Alex,” claims to be based in Belarus and writes that the bot is intentionally limited: no exploits, no command-and-control, no persistence. In his words, paraphrased and summarized from the page:

• The bot scans random IP addresses for open HTTP ports (80, 8000, 8080) and SSH ports (22, 2222).
• If it finds an open HTTP port it sends a single request (GET, CONNECT, or HEAD)
• If it finds an open SSH port it attempts a brute force with a small, fixed list of default credential pairs (admin:admin, root:root, etc.)
• It runs fully autonomously with no C2 channel; discovered IP/credential pairs are reported back to a loader only.
• It does not establish persistence, typically running from /tmp, and it is designed to self-terminate roughly six months after release.
• The stated purpose is to draw attention to conditions in Belarus. They describe it as a “performance piece,” saying they are not seeking funding and only asking for non-financial help leaving the country (job leads, advice, connections).

Disregarding the origin and supposed intent of the bot, this is a straightforward scan-and-brute-force bot and it should be treated like any other hitting a honeypot. The HTTP request is reconnaissance/fingerprinting that tells the operator a host is alive and reachable on that port. The risk is on the SSH side: any host reachable on TCP 22/2222 that still uses a default or weak credential pair is exposed, regardless of the creator’s stated intentions.

I want to give some healthy skepticism here rather than take the linked page at face value. I have no way to verify the age, location, or motive claimed on that page, whether the page itself is the full extent of the bot's behavior, or whether the “self-terminate after six months” and “no persistence” claims hold up under closer reverse engineering. Sob stories and appeals to sympathy are also a known social-engineering lever, and a URI designed to make analysts pause and read a web page rather than immediately blocklist an IP is an effective way to buy a scanner some goodwill. None of that changes the defensive posture: treat it as an untrusted, credential-guessing scanner.

[1] https://isc.sans.edu/weblogs/urlhistory.html?url=Lz9fSEVMUF9NRV9FU0NBUEVfRlJPTV9CRUxBUlVTX1BMRUFTRV8=
[2] https://isc.sans.edu/honeypot.html
[3] https://www.sans.edu/cyber-security-programs/bachelors-degree/

Disclosure: Claude was used for grammar and polish checks. No further use of generative A.I. was used in the creation of this post.

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

Yesterday, I talked about NAPTR records and how they are related to RCS. But there is another "odd" record that shows up in my DNS logs. This one isn't new, but I don't think I ever covered it: NIMLOC. At least that is what Zeek calls it. But let's see what it is all about.

At first, it looks like NIMLOC records are no longer used. Google's AI overview explains: "A NIMLOC (Nimrod Locator) DNS record is an obsolete resource record type (Type 32) originally designed for the Nimrod routing architecture to map names to network locators. Because Nimrod was an experimental protocol, NIMLOC records are considered historic and are not used in modern, standard network operations."

While I do have one or the other odd IOT device in my network, I doubt any of them speak "Nimrod". On the other hand, the queries originate from my macOS systems. This turns out to be an older standard, replaced by a newer (but still old) standard, with the newer standard becoming obsolete before the even older standard is phased out.

DNS defines several resource record types. The official list is maintained by IANA [1] and I am including a sample below:

There is a range of unassigned RR types, so one would think that it is not necessary to reuse RR Types. But this is exactly what happened here.

RR Type 32 was originally assigned for the old NetBIOS over TCP/UDP (RFC 1002, [2]). This actually became one of the few Internet Standards (STD 19). RR Type 32 is assigned ot "NB" (NetBIOS General Name Service) and 33 to "NBSTAT", the NetBIOS Node Status. If you search for it in the RFC, look for the hex values 0x0020 and 0x0021 (took me a while to find them).

NetBIOS is long gone, and modern Windows networks use DNS and SMB over TCP, eliminating the NetBIOS layer. But macOS is still holding on to it and broadcasting name announcements on port 137 using these records. Zeek (which I used to collect the logs), translates RR Type 32 to "NIMLOC", which conforms to the current IANA assignment for this type. But in reality, you are probably going to see NetBIOS and not the never-quite-implemented Nimrod routing scheme.

[1] https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-4
[2] https://www.rfc-editor.org/info/rfc1002/

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

Over the last year, with recent updates to iOS and Android, RCS (Rich Communication Services) has become an increasingly used protocol [1]. RCS is supposed to eventually replace SMS, and in addition to richer formatting, provides added (but optional) security. RCS messages may be end-to-end encrypted and digitally signed. Unlike SMS, which was "bolted on" to existing voice-focused phone standards. The SMS standard was based on old-fashioned pagers and allowed for limited clear-text communications. RCS is built from the ground up around modern IP-based network infrastructure and behaves more like IP chat services (think iMessage, WhatsApp...). RCS defines the message format, while protocols like SIP are used to establish connections and transport messages.

"Do as you say", I do from time to time take a look at odd DNS traffic on my network. An activity I recommend when teaching SEC503. Recently, I noticed more "NAPTR" queries, a record type I had not seen before. The record type is defined in RFC 2915 [2], which was ratified in 2000. It is not a new record. But so far, at least in my network, it has not really shown up before.

The description of the record sounds rather ominous:

"a Resource Record that included a regular expression that would be used by a client program to rewrite a string into a domain name."

Wow. Regular expressions to rewrite resource records? What could possibly go wrong? However, right now, I just want to talk about how it "goes right" and how these records are currently being used for RCS.

Below is the relevant part of the t-shark decode of a record typical for what I have seen in my network:

    Queries
        fp-us-verizon.rcs.telephony.goog: type NAPTR, class IN
            Name: fp-us-verizon.rcs.telephony.goog
            [Name Length: 32]
            [Label Count: 4]
            Type: NAPTR (35) (Naming Authority Pointer)
            Class: IN (0x0001)
    Answers
        fp-us-verizon.rcs.telephony.goog: type NAPTR, class IN, order 100, preference 100, flags s
            Name: fp-us-verizon.rcs.telephony.goog
            Type: NAPTR (35) (Naming Authority Pointer)
            Class: IN (0x0001)
            Time to live: 295 (4 minutes, 55 seconds)
            Data length: 61
            Order: 100
            Preference: 100
            Flags Length: 1
            Flags: s
            Service Length: 8
            Service: SIPS+D2T
            Regex Length: 0
            Regex:
            [Replacement Length: 43]
            Replacement: _sips._tcp.fp-us-verizon.rcs.telephony.goog

This was the only applicable NAPTR record, so order and preference do not matter in this case. The "S" flag indicates that the next lookup should be a SRV record. And indeed, we do have a SRV query (see below). Only a "U" flag would result in a URI. 

Remember that this record is about URIs, not IP addresses? The "Service" field indicates what service we may find at the to-be-determined URI. In this case, it is SIPS+D2T. SIPS+D2T is a transport protocol defined in the SIP standard (RFC 3263). SIPS+D2T stands for "Secure SIP Direct to TCP". So we will be using SIP over TLS with TCP as the transport protocol. The SIP standard specifically calls for NAPTR records to find SIP servers. The reason for the NAPTR record is to allow URIs to be returned, not just IP addresses/hostnames (as an SRV record would).

Lucky for us (and the DNS server), the regular expression is empty. And this appears to be normal for this use case. Instead, we just get a "SRV" record to request:

    Queries
        _sips._tcp.fp-us-verizon.rcs.telephony.goog: type SRV, class IN
            Name: _sips._tcp.fp-us-verizon.rcs.telephony.goog
            [Name Length: 43]
            [Label Count: 6]
            Type: SRV (33) (Server Selection)
            Class: IN (0x0001)
    Answers
        _sips._tcp.fp-us-verizon.rcs.telephony.goog: type SRV, class IN, priority 20, weight 0, port 5223, target fp-us-verizon.rcs.telephony.goog
            Service: _sips
            Protocol: _tcp
            Name: fp-us-verizon.rcs.telephony.goog
            Type: SRV (33) (Server Selection)
            Class: IN (0x0001)
            Time to live: 300 (5 minutes)
            Data length: 40
            Priority: 20
            Weight: 0
            Port: 5223
            Target: fp-us-verizon.rcs.telephony.goog
        _sips._tcp.fp-us-verizon.rcs.telephony.goog: type SRV, class IN, priority 30, weight 0, port 443, target fp-us-verizon.rcs.telephony.goog
            Service: _sips
            Protocol: _tcp
            Name: fp-us-verizon.rcs.telephony.goog
            Type: SRV (33) (Server Selection)
            Class: IN (0x0001)
            Time to live: 300 (5 minutes)
            Data length: 40
            Priority: 30
            Weight: 0
            Port: 443
            Target: fp-us-verizon.rcs.telephony.goog???????

And yes, in the end, there is a "normal" A and AAAA lookup for fp-us-verizon.rcs.telephony.goog.

So far, NAPTR records do not appear to be used to their full potential. I am sure that the use of regular expressions will be of interest to bug hunters and penetration testers. 

[1] https://support.google.com/messages/answer/13508703?hl=en
[2] https://www.ietf.org/rfc/rfc2915.txt

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

This morning, an interesting phishing email hit my mailbox. It targets Metamask[1], a cryptocurrency wallet, available as a browser extension and a mobile app, that lets users store, send, and receive crypto money. It’s pretty popular, so a juicy target for criminals. In February, I already mentioned a campaign against them[2].

Today’s email was different and used another approach. Most services that we use daily ask us to implement a 2nd authentication factor. That makes simple credentials useless if you can’t interact with the victim and grab the temporary token, code, …

But most services also offer a “password recovery” process. In the case of Metamask, it’s based on your secret security phrase that you created during the account creation process[3]. That’s exactly the target of this phishing campaign. They ask you to provide this secret phrase.

First, they put some pressure on you, pretending that your wallet is at risk:

Then, they ask you to provide your secret phrase:

The campaing relies on the domain captchasolve[.]help that has been registered two days ago.

[1] https://metamask.io
[2] https://isc.sans.edu/diary/Fake+Incident+Report+Used+in+Phishing+Campaign/32722
[3] https://support.metamask.io/configure/wallet/how-can-i-reset-my-password/

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