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