I noticed recently that we have more and more requests for ZIP files in our web honeypot logs. Over the last year, we have had a substantial increase in these requests.

International domain names (IDN) continue to be an interesting topic. For the most part, they are probably less of an issue than some people make them out to be, given that popular browsers like Google Chrome are pretty selective in displaying them. But on the other hand, they are still used legitimately or not, and keeping a handle on them is interesting.

While studying for the GX-FE [1], I started exploring the "Position" value in the registry that helps to tell Microsoft Word where you "left off". It's a feature many people that use Word have seen on numerous occasions and is explored in FOR500: Windows Forensic Analysis [2]. 

The Internet Storm Center and DShield websites are about 25 years old. Back in the day, I made some questionable decisions that I have never quite cleaned up later. One of these decisions was to use a "15 character 0-padded" format for IP addresses. This format padded each byte in the IP address with leading 0's, ensuring that they were all 15 characters long (including the '.'). 

Looking at new usernames collected by our Cowrie honeypots, you will first of all notice a number of HTTP headers. It is very common for attackers to scan for web servers on ports that are covered by our Telnet honeypots. The result is that HTTP request headers end up in our username and password database. 

I noticed an increase in scans that appear to try to identify Elasticsearch instances. Elasticsearch is not a new target. Its ability to easily store and manage JSON data, combined with a simple HTTP API, makes it a convenient tool to store data that is directly accessible from the browser via JavaScript. Elasticsearch has, in particular, been popular for consolidating log data, and the "ELK" (Elasticsearch, Logstash, Kibana) platform has been a very successful standard for open source log management.

I recently woke up (as one does each day, hopefully) and saw a few Microsoft MFA prompts had pinged me overnight.  Since I had just awakened, I just deleted them, then two minutes later clued in – this means that one of my passwords was compromised, and I had no idea which site the compromised creds were for.

As the world gradually adopts and transitions to using 5G for mobile, operational technology (OT), automation and Internet-of-Things (IoT) devices, a secure 5G network infrastructure remains critical. Recently, the Automated Systems SEcuriTy (ASSET) Research Group have released a new framework named SNI5GECT [pronounced as Sni-f-Gect (sniff + 5G + inject)] that enables users of the framework to i) sniff messages from pre-authentication 5G communication in real-time and ii) inject targeted attack payloads in downlink communications towards User Equipments (UE). I had previously written about how 5G connections are established over here, hence I will be diving directly into the SNI5GECT framework. In this diary, I will briefly provide an overview of the SNI5GECT framework and discuss a new multi-stage downgrade attack leveraging the SNI5GECT framework.

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