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.
One of the key messages broadcasted by security professionals is: "Patch, patch and patch again!". But they are nasty vulnerabilities that remain exploited by attackers even if they are pretty old. %%cve:2017-11882%% is one of them: this remote code execution affects Microsoft Office and, more precisely, the good old "Equation Editor". This tool was even killed by Microsoft due to numerous security issues[1]. But it still remains used by attackers to spread modern malware.
This month's Microsoft patch update addresses a total of 111 vulnerabilities, with 17 classified as critical. Among these, one vulnerability was disclosed prior to the patch release, marking it as a zero-day. While none of the vulnerabilities have been exploited in the wild, the critical ones pose significant risks, including remote code execution and elevation of privilege. Users are strongly advised to apply the updates promptly to safeguard their systems against potential threats.
In recent media events, Tesla has demoed progressively more sophisticated versions of its Optimus robots. The sales pitch is pretty simple: "Current AI" is fun, but what we really need is not something to create more funny kitten pictures. We need AI to load and empty dishwashers, fold laundry, and mow lawns. But the robot has not been for sale yet, and there is no firm release date.
[This is a Guest Diary by Duncan Woosley, an ISC intern as part of the SANS.edu BACS program]
During the last three months I've had a DShield sensor online and collecting data from a deployment in AWS. This week I did some statistical analysis of the last three months of data and found surprising result. Of all the locations that scanned and attacked the DShield sensor, one location was a clear winner in terms of volume of traffic, accounting for over 65% of the total traffic sent to the sensor. To my surprise, that location was Panama!
Total DShield Sensor Traffic per Location
The top 10 locations were close to inline with common expectations, however, the traffic from Panama was greater than the total traffic from all the remaining locations combined!
Digging into the source of this anomaly, I filtered for traffic by day and found that there were massive spikes on just a few days in the last three months that accounted for most of the DShield sensor's captured volume.
Largest Single Days by volume from April 7th to July 7th
Each spike was found to be caused by traffic from a single IP each day, but the IP responsible for each spike was different. However, six of the top ten most active IPs were all from a single /24 subnet! The subnet 141.98.80.0/24 was the cause of 59.4% of total logs collected by the sensor. Moreover, nine of the top 10 IPs were from the same internet service provider (ISP) named "NForce Entertainment B.V."
Autonomous System Numbers (ASN) 43350 accounted for 71.6% of the total sensor logs! This ASN belonging to NForce Entertainment but NForce Entertainment appears to often lease out its IP space to other VPN and proxy providers like the Panama based Flyservers S.A. Flyservers is categorized as a "potentially very high fraud risk ISP" by Scamalytics and is likely the source of this activity.
Top ASNs by Total Traffic
Further research into this ISP found that the NForce Entertainment IP activity was often associated with phishing, malware, and scanning. As a Dutch ISP, they operate without strict regulatory oversight or pressure from their host nation to revoke threat actors’ use of their services.
Recommendations
Unfortunately, the solution for network defenders isn't as simple as blocking all traffic from NForce Entertainment. If your organization is in a position where no NForce Entertainment traffic is required for business, this may be an option, but the majority of organizations don’t allow sweeping IP blocking. Instead, I would recommend blocking only sensitive services and HTTP(S) endpoints that allow for logins. The following actions are recommended.
• Flagging traffic from NForce Entertainment and particularly from ASN 43350.
• Block access to Remote Desktop Protocol from the internet.
• Monitor for SSH activity from ASN 43350 and configured SSH to use key based authentication.
• Implement a Web Application Firewall (WAF) for all web applications and monitor activity originating from any sources for suspicious queries.
• Create a WAF alert threshold for high traffic originating from a single source.
[1] https://www.arin.net/resources/guide/asn/
[2] https://scamalytics.com
[3] https://owasp.org/www-community/Web_Application_Firewall
[4] https://www.sans.edu/cyber-security-programs/bachelors-degree/
NOTE: ChatGTP was used for Spelling and grammar checks only
———–
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.
Sextortion e-mails have been with us for quite a while, and these days, most security professionals tend to think of them more in terms of an “e-mail background noise” rather than as if they posed any serious threat. Given that their existence is reasonably well-known even among general public, this viewpoint would seem to be justified… But are sextortion messages really irrelevant as a threat at this point, and can we therefore safely omit this topic during security awareness trainings?
![AI and Faster Attack Analysis [Guest Diary], (Wed, Aug 13th)](https://www.ironcastle.net/wp-content/uploads/2025/08/status-6.gif)
