This week, it's SANSFIRE[1]! I'm attending the FOR577[2] training ("Linux Incident Response & Threat Hunting"). On day 2, we covered the different filesystems and how data is organized on disk. In the Linux ecosystem, most filesystems (ext3, ext4, xfs, …) support "extended file attributes", also called "xattr". It's a file system feature that enables users to add metadata to files. These data is not directly made available to the user and may contain anything related to the file (ex: the author's name, a brief description, …). You may roughly compare this feature to the Alternate Data Stream (ADS) available in the Windows NTFS filesystem.
Tag Archives: Security
More Free File Sharing Services Abuse, (Wed, Jul 16th)
A few months ago, I wrote a diary about online services used to exfiltrate data[1]. In this diary, I mentioned some well-known services. One of them was catbox.moe[2]. Recently, I found a sample that was trying to download some payload from this website. I performed a quick research and collected more samples!
Keylogger Data Stored in an ADS, (Tue, Jul 15th)
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.
DShield Honeypot Log Volume Increase, (Mon, Jul 14th)
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.
Experimental Suspicious Domain Feed, (Sun, Jul 13th)
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.
domainname |
---|
jgcinversiones.com |
h20manager.net |
1sbrfreebet.com |
stability.now |
mdskj.top |
internationalone19.com |
clistrict196.org |
agenteinsider.com |
720airpano.com |
dhofp.tax |
bos228btts.lol |
japansocialmarketing.org |
mummyandimedia.com |
1dyzfd.buzz |
oollm.shop |
snapztrailk.store |
perumice.com |
nrnmy.sbs |
commaexperts.com |
softfragments.com |
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|
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
SSH Tunneling in Action: direct-tcp requests [Guest Diary], (Wed, Jul 9th)
[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.157 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
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Setting up Your Own Certificate Authority for Development: Why and How., (Wed, Jul 9th)
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:
Microsoft Patch Tuesday, July 2025, (Tue, Jul 8th)
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.
What's My (File)Name?, (Mon, Jul 7th)
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".
A few interesting and notable ssh/telnet usernames, (Sun, Jul 6th)
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|
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.