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 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