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!

I collected (and stopped because it was a constant flood!) 612 URLs pointing to direct downloads (hxxps://files[.]catbox[.]moe/xxxxxx). Some where popular and used by multiple samples:

remnux@remnux:~/malwarezoo/catmoe-research$ cat urls.txt | sort | uniq -c | sort -rn| head -10
 23 hxxps://files[.]catbox[.]moe/a1z5ds.dll
 20 hxxps://files[.]catbox[.]moe/63g8p0.dll
 16 hxxps://files[.]catbox[.]moe/h7b4e4.dll
 13 hxxps://files[.]catbox[.]moe/mqhwlv.sys
 13 hxxps://files[.]catbox[.]moe/j5s1uy.bin
 13 hxxps://files[.]catbox[.]moe/3ps4f5.dll
 10 hxxps://files[.]catbox[.]moe/5ikx0w.dll
  9 hxxps://files[.]catbox[.]moe/l3whjb.wav
  9 hxxps://files[.]catbox[.]moe/1z3yes.cmd
  7 hxxps://files[.]catbox[.]moe/eaek1u.dll

What are the most popular file types?

remnux@remnux:~/malwarezoo/catmoe-research$ file *| cut -d “:” -f 2 | sort | uniq -c | head -30
55 PE32+ executable (DLL) (GUI) x86-64, for MS Windows
29 PE32+ executable (native) x86-64, for MS Windows
21 ASCII text, with no line terminators
20 PE32+ executable (DLL) (console) x86-64, for MS Windows
20 PE32+ executable (console) x86-64, for MS Windows
11 data
10 RIFF (little-endian) data, WAVE audio, Microsoft PCM, 16 bit, mono 48000 Hz
9 DOS batch file, ASCII text, with CRLF line terminators
9 ASCII text, with CRLF line terminators
8 DOS batch file, ASCII text, with very long lines, with CRLF line terminators
5 RIFF (little-endian) data, WAVE audio, Microsoft PCM, 16 bit, stereo 44100 Hz
5 RIFF (little-endian) data, WAVE audio, Microsoft PCM, 16 bit, mono 44100 Hz
3 Zip archive data, at least v2.0 to extract
3 RIFF (little-endian) data, WAVE audio, Microsoft PCM, 16 bit, stereo 48000 Hz
3 ASCII text, with very long lines, with CRLF line terminators
2 RAR archive data, v5
2 PNG image data, 800 x 450, 8-bit/color RGB, non-interlaced
2 PNG image data, 500 x 500, 8-bit/color RGBA, non-interlaced
2 PNG image data, 1080 x 1080, 8-bit/color RGB, non-interlaced
2 PE32+ executable (GUI) x86-64, for MS Windows
2 PE32 executable (GUI) Intel 80386, for MS Windows, UPX compressed
2 PE32+ executable (DLL) (EFI application) x86-64, for MS Windows
2 PE32 executable (console) Intel 80386, for MS Windows
2 MS-DOS executable PE32 executable (GUI) Intel 80386, for MS Windows, MZ for MS-DOS
2 JPEG image data, Exif standard
2 ISO Media, MP4 Base Media v1 [IS0 14496-12
2 empty
2 DOS batch file, UTF-8 Unicode text, with CRLF line terminators
2 DOS batch file, ASCII text, with CRLF line terminators, with escape sequences

Note that PE files should NOT be available on catbox.moe:

I hope they don't just filter files based on the extension! Conclusion: if you don't use such online services, any traffic to them can be considered as suspicious.

[1] https://isc.sans.edu/diary/Online+Services+Again+Abused+to+Exfiltrate+Data/31862
[2] https://catbox.moe/

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

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

from SANS Internet Storm Center, InfoCON: green https://ift.tt/CQjLwN4
via IFTTT

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.

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

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

from SANS Internet Storm Center, InfoCON: green https://ift.tt/6Q4hX9e
via IFTTT

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. 

 


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.

Subnet Web Honeypot Hits Unique IP Count Unique URL Path Count Top IP Top URL Path
45.146.130.0/24 20078392935 6 55 %%ip:45.146.130.107%% /
179.60.146.0/24 15730010424 2 2 %%ip:179.60.146.100%% /__api__/v1/config/domains [2]
185.93.89.0/24 4976900543 6 134 %%ip:185.93.89.185%% /
204.152.199.0/24 4421115971 9 2 %%ip:204.152.199.8%% /
72.11.141.0/24 4241370914 13 2 %%ip:72.11.141.14%% /
96.47.225.0/24 3636730956 9 2 %%ip:96.47.225.5%% /
185.193.88.0/24 3610407610 4 4 %%ip:185.193.88.178%% /__api__/v1/config/domains
155.94.185.0/24 3165292268 9 2 %%ip:155.94.185.3%% /
149.56.205.0/24 2718351438 1 3 %%ip:149.56.205.13%% /
193.111.208.0/24 2517999488 1 3 %%ip:193.111.208.87%% /
193.29.13.0/24 2248677302 1 2 %%ip:193.29.13.44%% /
92.63.196.0/24 2204582018 5 4 %%ip:92.63.196.179%% /__api__/v1/config/domains
80.82.65.0/24 927668585 3 3 %%ip:80.82.65.127%% /
151.243.93.0/24 560421646 1 3 %%ip:151.243.93.62%% /
79.141.162.0/24 527387481 1 3 %%ip:79.141.162.39%% /
83.229.17.0/24 463243368 2 4 %%ip:83.229.17.112%% /
91.199.163.0/24 447956151 1 2 %%ip:91.199.163.102%% /__api__/v1/config/domains
141.98.80.0/24 174475074 22 3 %%ip:141.98.80.136%%
46.161.27.0/24 76298489 9 3 %%ip:46.161.27.97%% /
80.243.171.0/24 68840696 1 18152 %%ip:80.243.171.172%% /
171.22.28.0/24 60795298 2 2 %%ip:171.22.28.30%% /
45.227.255.0/24 39617032 7 4 %%ip:45.227.255.90%%
184.105.247.0/24 33156996 46 7 %%ip:184.105.247.252%% /
213.209.150.0/24 23439064 2 2 %%ip:213.209.150.239%% /
204.76.203.0/24 17219727 15 1127 %%ip:204.76.203.206%% /
198.7.119.0/24 14768235 2 5437 %%ip:198.7.119.14%% /index.php
77.90.153.0/24 13968760 2 144 %%ip:77.90.153.248%% /
185.218.84.0/24 12687799 13 4 %%ip:185.218.84.178%% /
65.49.20.0/24 11897736 61 6 %%ip:65.49.20.68%% /
74.82.47.0/24 9974952 61 6 %%ip:74.82.47.3%% /
184.105.139.0/24 8966536 60 7 %%ip:184.105.139.67%% /
111.170.18.0/24 8271554 1 1 %%ip:111.170.18.49%% api.ipapi.is:443
185.91.127.0/24 7976326 10 27 %%ip:185.91.127.66%% myip.wtf:443
216.218.206.0/24 6055214 61 6 %%ip:216.218.206.66%% /
98.82.141.0/24 4647608 1 6724 %%ip:98.82.141.184%%
51.222.26.0/24 4598477 2 7029 %%ip:51.222.26.42%%
23.234.91.0/24 4454070 1 1 %%ip:23.234.91.166%% /
5.183.209.0/24 3993952 1 6 %%ip:5.183.209.244%% /
37.19.221.0/24 3922037 4 1 %%ip:37.19.221.152%% /
149.50.103.0/24 3764760 1 1 %%ip:149.50.103.48%% /
154.81.156.0/24 3665899 10 10 %%ip:154.81.156.7%% /
207.167.67.0/24 3593126 7 6 %%ip:207.167.67.206%%
64.62.197.0/24 3456463 240 8 %%ip:64.62.197.92%% /
207.180.204.0/24 3291942 1 6911 %%ip:207.180.204.178%%
124.198.132.0/24 2937813 14 1 %%ip:124.198.132.155%% /api/sonicos/is-sslvpn-enabled
132.226.159.0/24 2878302 1 184 %%ip:132.226.159.101%%
84.247.172.0/24 2787287 4 6953 %%ip:84.247.172.209%% /index.php
193.41.206.0/24 2764461 11 3170 %%ip:193.41.206.24%% /.env
80.65.211.0/24 2463234 1 6767 %%ip:80.65.211.20%%
185.191.126.0/24 2379847 2 7 %%ip:185.191.126.248%% /
87.236.176.0/24 2333336 252 4 %%ip:87.236.176.117%% /
154.83.103.0/24 2276967 23 6369 %%ip:154.83.103.106%% /.git/HEAD
132.226.122.0/24 2145978 1 184 %%ip:132.226.122.74%%
179.43.168.0/24 2088416 2 74 %%ip:179.43.168.146%% /
191.252.194.0/24 1999452 1 6725 %%ip:191.252.194.180%%
65.49.1.0/24 1993183 232 8 %%ip:65.49.1.94%% /
13.41.162.0/24 1933149 1 6725 %%ip:13.41.162.60%%
185.177.72.0/24 1919963 17 3864 %%ip:185.177.72.111%% /.git/HEAD
179.43.161.0/24 1616473 2 1 %%ip:179.43.161.218%% /
193.26.115.0/24 1595736 9 15 %%ip:193.26.115.193%% /api/sonicos/is-sslvpn-enabled
84.201.151.0/24 1568962 1 1281 %%ip:84.201.151.18%% /index.php
64.62.156.0/24 1519319 219 8 %%ip:64.62.156.108%% /
75.119.147.0/24 1513333 1 6912 %%ip:75.119.147.56%%
139.144.52.0/24 1504276 1 569 %%ip:139.144.52.241%% /
79.124.58.0/24 1503070 1 9 %%ip:79.124.58.198%% /
31.220.89.0/24 1444043 1 6724 %%ip:31.220.89.104%%
157.245.174.0/24 1426128 1 53 %%ip:157.245.174.148%%
94.72.105.0/24 1420774 2 12531 %%ip:94.72.105.70%% /
78.153.140.0/24 1346725 16 1372 %%ip:78.153.140.179%% /.env
193.68.89.0/24 1332852 7 6 %%ip:193.68.89.51%% /
45.148.10.0/24 1328615 33 347 %%ip:45.148.10.235%% /cmd,/simZysh/register_main/setCookie
148.113.208.0/24 1308479 1 1 %%ip:148.113.208.45%% /
141.98.11.0/24 1298067 49 811 %%ip:141.98.11.128%% /
176.65.148.0/24 1217874 34 23 %%ip:176.65.148.243%% /
84.201.170.0/24 1194041 1 3070 %%ip:84.201.170.229%% /
84.201.181.0/24 1177504 2 1749 %%ip:84.201.181.85%% /
162.62.233.0/24 1176321 1 1280 %%ip:162.62.233.142%%
45.84.89.0/24 1106375 2 1 %%ip:45.84.89.2%% /
195.3.221.0/24 1063626 1 14 %%ip:195.3.221.137%% /
158.160.162.0/24 1016033 1 8095 %%ip:158.160.162.122%% /

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

 

URL Path Total Hits
/ 38,052,002,400
/__api__/v1/config/domains [3] 33,198,670,474
/__api__/v1/logon 1,635,235,500
api.ipapi.is:443 8,270,636
myip.wtf:443 7,914,843

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

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

from SANS Internet Storm Center, InfoCON: green https://ift.tt/Teq6bkd
via IFTTT

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.

from SANS Internet Storm Center, InfoCON: green https://ift.tt/xkzRYWm
via IFTTT