YARA-X's 1.18.0 release brings 3 improvements and 2 bugfixes.
One of the improvements is a new command-line option, –cpu-limit, allowing one to limit the amount of CPU YARA requires.
YARA-X's 1.19.0 release brings 4 improvements and 2 bugfixes.
Didier Stevens
Senior handler
blog.DidierStevens.com
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
In a previous diary, I talked about stack strings[1] with a practical example of them. Since my SEC670 class, I’m even more interested in malware obfuscation techniques. I had a look at process names. When you list running processes on a computer, can you trust what you see? If you're facing a rootkit, malicious processes can be simply hidden (the API calls or commands to list processed have been tampered). But a malicious process can also mimic a non-suspicious name by masquerading their name. This technique (T1036 in the MITRE ATT&CK framework[2]) has been used by attackers in many campaigns. A good example of the Velvet Ant Chinese group[3]. The goal is to hide the “malware” process name by replacing it with something that won’t attract the Security Analyst’s eyes or defeat security controls.
In August 2024 SonicWall published advisory SNWLID-2024-0015 for CVE-2024-40766. It is an improper access control vulnerability in SonicOS. CVSS 9.3. It affects the management interface and the SSLVPN service on Gen 5, Gen 6 and Gen 7 firewalls. Each generation has its own affected firmware range: Gen 5 running SonicOS 5.9.2.14-12o and older, Gen 6 running 6.5.4.14-109n and older, and Gen 7 running SonicOS 7.0.1-5035 and older. Successful exploitation lets an attacker gain unauthorized access to the firewall. Under certain conditions it crashes the device entirely.
The scope of the affected install base is large. SonicWall reports serving approximately 500,000 businesses across 215 countries and territories. Many of them run SSLVPN as their sole remote access method. Many of them do not have a dedicated security team. That combination is exactly what ransomware operators look for.
Akira and Fog ransomware groups have been exploiting CVE-2024-40766 since at least September 2024 when Arctic Wolf first reported Akira affiliates compromising SSLVPN accounts on vulnerable devices. By December 2024 Macnica research confirmed that roughly half of organizations listed on Akira and Fog leak sites were running SonicWall and at least 48,933 devices were still publicly exposed and unpatched.
The exploitation has not slowed down. It has escalated in waves. In July-August 2025 Arctic Wolf, Huntress and Bitdefender reported a surge of Akira intrusions targeting Gen 7 firewalls. Rapid7 and Darktrace published corroborating analyses in September and October 2025 respectively. Fog ransomware operators were also observed exploiting the same vulnerability during this period accounting for roughly 25 percent of intrusions while Akira accounted for 75 percent. Researchers initially suspected a zero-day. SonicWall investigated and confirmed with high confidence that the activity still correlated with CVE-2024-40766. Many compromised organizations had migrated from Gen 6 to Gen 7 without resetting local user passwords. Dwell times across both groups were alarmingly short. Arctic Wolf documented encryption occurring in under four hours from initial access with some cases as fast as 55 minutes.
In September 2025 SonicWall confirmed a separate breach of its MySonicWall cloud platform where attackers accessed firewall configuration backup files containing encrypted credentials. SonicWall initially stated that fewer than 5 percent of its customer base was affected. The company later concluded that all backup files had been compromised. Any organization with a MySonicWall account should assume its configuration backup was accessed and its encrypted credentials exposed. In October 2025 Huntress reported over 100 SSLVPN accounts compromised across 16 customer environments in a single wave. The attackers were not brute-forcing. They authenticated rapidly using valid credentials obtained from another source.
The problem deepened in 2026. In February and March 2026 ReliaQuest documented what they assessed as the first in-the-wild exploitation of CVE-2024-12802, a separate authentication bypass vulnerability that allows attackers to bypass MFA on SonicWall SSLVPN appliances. On Gen 6 devices the firmware patch alone does not remediate the flaw. Six additional manual LDAP reconfiguration steps are required. In the environments ReliaQuest investigated the devices appeared patched based on firmware version. They were still fully exploitable. Attackers brute-forced credentials with automated tooling, bypassed MFA without triggering any failed-login alerts, and in one case reached a file server and deployed pre-ransomware staging tools within 30 minutes of VPN access. The session type sess="CLI" in the SonicWall authentication logs was the most consistent early indicator that automated tooling was driving the authentication.
On April 16, 2026 SonicWall Gen 6 devices reached end-of-life. No further firmware updates or security patches will be issued for that hardware generation. Gen 6 devices remain common in production environments especially at small businesses and in networks assembled through mergers and acquisitions. Any Gen 6 device still running SSLVPN is now operating without vendor support on a platform with two actively exploited vulnerabilities and no future remediation path.
The common thread across two years of exploitation is the same. The attackers are not breaking in through novel exploits. They are logging in with valid credentials to accounts that should not exist on devices that were patched but never cleaned up.
Figure 1 summarizes the residual risk indicators we found across the audited devices. All identifiers are anonymized.
???????
The most common finding was stale local accounts. 12 of 14 firewalls had SSLVPN accounts that did not exist in Active Directory. Some were legacy service accounts from the Gen 6 era. Some were accounts created during onboarding for employees who had left years ago. A few had usernames containing non-printable characters. That last one is a strong indicator of automated account creation by exploitation tooling. A human administrator does not create accounts with null bytes in the username.
The second finding was the most dangerous in practical terms. 11 of 14 firewalls had not rotated local account passwords after the firmware upgrade. The same credentials that may have been exposed through the vulnerability or through the MySonicWall backup incident are still valid. An attacker who collected them six months ago can use them today.
The third finding was the lack of any source-IP restriction on SSLVPN authentication. 10 of 14 firewalls accepted VPN connections from any IP on the planet. No geo-IP filtering. No ASN blocking. Legitimate remote workers connect from residential ISPs in the country where the company operates. Attackers connect from hosting providers and VPS infrastructure. A simple ASN filter would block most automated exploitation without affecting any real user.
This finding deserves its own section because it is the most misunderstood and the most impactful. SonicWall firewalls that authenticate users via LDAP have a setting called the Default LDAP User Group. Every user who successfully authenticates through LDAP is automatically placed into this group in addition to whatever groups they belong to in Active Directory. The default group membership is additive. The risk is that it grants permissions the user should not have based on their actual role.
If this default group is mapped to a group that has SSLVPN access then every single Active Directory account with valid credentials can connect to the VPN. The receptionist. The warehouse operator. The service account with a weak password that nobody monitors. The contractor who left two years ago but whose AD account was never purged. If the credentials are valid and the account is active in AD the tunnel opens.
We found this misconfiguration in 9 of 14 firewalls. In one case the Default LDAP User Group was mapped to a group that had both SSLVPN Services and administrative access to the firewall management interface. That means any compromised AD credential from any source gives the attacker a VPN tunnel into the network and admin access to the perimeter device itself.
SonicWall published a knowledge base article on this specific risk in August 2025 after the Akira campaign drew attention to it. But it is guidance, not a patch. If an administrator does not read the article and manually reconfigure the setting then the overpermissive default stays exactly where it was. The fix is to create a dedicated local group with no service access and set that as the Default LDAP User Group. Then assign SSLVPN permissions explicitly and only to the groups that need them.
Half of the firewalls we audited had the SonicWall Virtual Office Portal accessible from the internet without any authentication gate. The Virtual Office Portal is the web interface where SSLVPN users configure their MFA and TOTP tokens. If an attacker has valid credentials and the portal is reachable from the internet then they do not need to break MFA. They can enroll their own TOTP device for that account. They register their authenticator app. They complete the MFA challenge. They are in.
This is how multiple Akira intrusions bypassed MFA on organizations that believed they had it enforced. The attacker never broke the second factor. They set it up themselves on a device they controlled. The fix is a single access rule: restrict the Virtual Office Portal to internal network addresses or VPN-connected sources only. It takes minutes. But it requires knowing the portal exists in the first place and most firewall administrators we spoke with did not know it was publicly exposed.
On every audited firewall we exported the SSLVPN session data for the 30-day window after the patch was applied. Figure 2 shows the results from one representative device.
Legitimate user sessions are the green dots clustered at the bottom. Business hours. Duration under eight hours. Source IPs in residential or corporate ISP ranges. Normal.
The orange diamonds are sessions from VPS and hosting provider ASNs. They start during off-hours. Several ran for 40 to 60 hours. No legitimate employee connects to a corporate VPN from a cloud hosting provider for two and a half days straight.
The red squares are the worst. Those are sessions on stale local accounts. Accounts that had been disabled in Active Directory more than a year before the patch was applied. The accounts still existed as local firewall users. They authenticated successfully. They stayed connected for four to seven days. Those sessions were active on a patched firewall. The patch did not terminate them. The patch did not disable the accounts. The patch fixed the access control flaw and left everything else exactly as it was.
We walked each organization through a post-patch hardening audit. Figure 3 shows the before-and-after for one representative firewall.
That firewall had 23 local SSLVPN accounts. Six were legitimate and stayed. The other 17 were stale, orphaned or unexplained. The LDAP Default User Group was granting implicit SSLVPN access to 147 AD accounts. After reconfiguring the group that number dropped to 28 who actually needed VPN access. All 19 accounts without MFA enforced were either removed or had MFA turned on. Seven active sessions longer than 24 hours were terminated. Three exposed admin interfaces were restricted to management-VLAN-only access.
The patch took five minutes. This cleanup took an afternoon. That afternoon is the gap between a firewall that shows as patched in a vulnerability scanner and a firewall that is actually hardened against the threat actors who know exactly what post-patch misconfigurations to look for.
This is the checklist we used across every firewall we reviewed. It is designed to be run in one sitting by a single administrator with management access to the device.
|
What to Check |
How to Check It |
What Bad Looks Like |
|
Local SSLVPN account inventory |
Device > Users > Local Users & Groups (SonicOS 7.x). Compare against AD export. Flag any account not in AD. |
Accounts with no AD counterpart. Accounts with non-printable or unusual characters in username. |
|
LDAP Default User Group membership |
Device > Users > Settings > Authentication. Select LDAP + Local Users then Configure LDAP. Check the Default LDAP User Group assignment. |
Default group has SSLVPN Services or admin access. Any LDAP-authenticated user inherits VPN access regardless of AD group. |
|
Password rotation post-upgrade |
Confirm all local account passwords and LDAP-synchronized AD account passwords were changed after firmware update. |
Passwords carried over from Gen 6 migration. Same credentials active pre- and post-patch. AD service accounts used for LDAP bind not rotated. |
|
Virtual Office Portal exposure |
Attempt external access to the Virtual Office Portal URL on the firewall. Check if MFA/TOTP enrollment is publicly accessible. |
Portal reachable without auth from external IPs. Attacker can enroll TOTP for any account with known credentials. |
|
Active session review |
Network > SSL VPN > Status (SonicOS 7.x). Export and sort by duration and source ASN. |
Sessions lasting >24 hours. Source IPs in hosting/VPS ASNs. Sessions from accounts not in current employee roster. |
|
Packet capture and debug artifacts |
Device > Diagnostics (SonicOS 7.x). Check for saved packet captures, debug logs, config exports created during compromise window. |
Captures or exports created outside maintenance windows. Captures targeting LDAP bind traffic or internal subnets. |
|
Account lockout and botnet filtering |
Device > Users > Settings > Account Lockout. Policy > Security Services > Botnet Filter. |
Lockout disabled or set to unreasonable thresholds (>20 attempts). Botnet filtering not enabled on SSLVPN zone. |
|
Firmware version target |
Device > Settings > Firmware & Backups. Verify running SonicOS 7.3.0 or later. Gen 6 devices: verify all six LDAP steps from SNWLID-2025-0001 are completed. |
Running any version below 7.3.0. Gen 6 devices showing as patched by version alone without completed LDAP remediation steps. |
Beyond the configuration items there are forensic artifacts that indicate the device was accessed by an attacker before the patch was applied:
Here are some alerting rules derived from the patterns observed across the audited firewalls:
CVE-2024-40766 has been public since August 2024. A patch has been available from day one. CVE-2024-12802 adds a second layer of risk for Gen 6 devices where the firmware update alone does not remediate the MFA bypass. And Gen 6 reached end-of-life on April 16, 2026. No more patches are coming for that hardware.
The problem is not that organizations are not patching. Most of them are. The problem is that patching is the only thing they do. They apply the firmware update. They mark the CVE as remediated. They move on. And everything around the vulnerability stays the same. The accounts stay. The LDAP group stays. The passwords stay. The Virtual Office Portal stays open. The sessions stay connected. On Gen 6 devices the LDAP configuration that enables MFA bypass stays in place even after the firmware update because the patch does not remove it.
Akira and Fog operators know all of this. They are not scanning for unpatched firewalls anymore. They are scanning for patched firewalls where nobody completed the post-patch steps. A patched SonicWall with 17 stale local accounts and an overpermissive LDAP default group is not a remediated device. It is a device with newer firmware and the same attack surface.
If you run SonicWall with SSLVPN enabled and you applied the patch for CVE-2024-40766 then you did Step 1. Do Step 2. Run the checklist. Reconcile the accounts. Fix the LDAP group. Rotate the passwords for both local firewall accounts and LDAP-synchronized Active Directory accounts including the LDAP bind credential. Restrict the portal. Terminate the stale sessions. Upgrade to SonicOS 7.3.0 or later which includes enhanced brute-force detection and improved MFA controls that older patched versions do not have.
If you are on Gen 6 verify that all six LDAP remediation steps from SNWLID-2025-0001 have been completed. Firmware version alone does not confirm remediation on Gen 6. The six steps are: delete the existing LDAP configuration that uses userPrincipalName, remove locally cached LDAP users, remove the configured SSL VPN User Domain, reboot the firewall, recreate the LDAP configuration without userPrincipalName, and create a fresh configuration backup to prevent the vulnerable state from being restored. SonicWall has published an automation script that executes these steps via SonicOS API or SSH. Gen 6 reached end-of-life in April 2026. Start planning your migration to supported hardware. The patch closed the bug. Now close the configuration gaps that the bug left behind.
Manuel Humberto Santander Peláez
SANS Internet Storm Center – Handler
Twitter: @manuelsantander
Mastodon:manuelsantander@infosec.exchange
email:msantand@isc.sans.org
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Today, we are announcing AWS Lambda MicroVMs, a new serverless compute primitive within AWS Lambda that lets you run code generated by users or AI in isolated, stateful execution environments. You get virtual machine level isolation, near-instant launch and resume, and direct control over environment lifecycle and state, all without managing infrastructure or building expertise in complex virtualization technologies. Lambda MicroVMs are powered by Firecracker, the same lightweight virtualization technology that has powered over 15 trillions of monthly Lambda function invocations.
Why customers need this
Over the past few years a new class of multi-tenant applications has emerged that all share the need to hand each end user their own dedicated execution environment in which to safely run code that the application developer did not write. AI coding assistants, interactive code environments, data analytics platforms, vulnerability scanners, and game servers that run user-supplied scripts all fit this pattern. Building that capability today means making a difficult choice. Virtual machines deliver strong isolation but take minutes to start. Containers launch in seconds, yet their shared-kernel architecture requires significant custom hardening to safely contain untrusted code. Functions as a service are optimized for event-driven, request-response workloads, but are not designed for long-running interactive sessions that need to retain environment state across user interactions. That leaves developers either accepting tradeoffs between performance and isolation, or investing significant engineering resources to build and operate custom virtualization infrastructure to achieve isolated execution while delivering low-latency experiences to end-users. This presents an effort that demands deep expertise and pulls engineering time away from the product they are actually trying to build.
Lambda MicroVMs is purpose-built for exactly this gap. Each MicroVM gives a single end user or session its own isolated environment that launches rapidly, retains memory and disk state for the length of the session, and pauses to a low idle cost when the user steps away. Because the same Firecracker technology already underpins AWS Lambda Functions, you inherit the operational maturity of a service that has been running this stack at scale.
Let’s try it out
To get started, I navigated to the AWS Lambda console, where Lambda MicroVMs now appears in the left-hand navigation menu. I first need to create a MicroVM Image.
I packaged a Flask web app and its Dockerfile into a zip file, uploaded it to an Amazon Simple Storage Service (Amazon S3) bucket.
My Flask API – app.py
import logging
from flask import Flask, jsonify
app = Flask(__name__)
logging.basicConfig(level=logging.INFO)
@app.route("/")
def hello():
app.logger.info("Received request to hello world endpoint")
return jsonify(message="Hello, World!")
if __name__ == "__main__":
app.run(host="0.0.0.0", port=5000)
My Dockerfile
FROM public.ecr.aws/lambda/microvms:al2023-minimal
RUN dnf install -y python3 python3-pip && dnf clean all
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY app.py .
EXPOSE 5000
CMD ["gunicorn", "--bind", "0.0.0.0:5000", "app:app"]
I used the following command to create my MicroVM Image.
aws lambda-microvms create-microvm-image
--code-artifact uri=<path/to/s3/artifact.zip> --name <VM_image_name>
--base-image-arn arn:aws:lambda:us-east-1:aws:microvm-image:al2023-1
--build-role-arn <IAM role ARN>
You can also create the MicroVM Image in the AWS Console as in the image above. Once I ran the command, Lambda retrieved the zip, ran the Dockerfile, initialized the application, and took a Firecracker snapshot of the running disk and memory state. Build logs streamed in real time to Amazon CloudWatch under /aws/lambda/microvms/<image-name>, and when the image was ready it appeared in the console with its Amazon Resource Name (ARN) and version number.
aws lambda-microvms run-microvm
--image-identifier arn:aws:lambda:<region>:<acct>:microvm-image:my-image
--execution-role-arn arn:aws:iam::<acct>:role/MicroVMExecutionRole
--idle-policy '{"maxIdleDurationSeconds":900,"suspendedDurationSeconds":300,"autoResumeEnabled":true}'
Launching can also be done via the AWS Console or the CLI. I passed the image ARN and an idle policy configured to auto-suspend after 15 minutes of inactivity and auto-resume on the next incoming request. No networking setup was required. Lambda assigned the MicroVM a unique ID, returned a dedicated endpoint URL, and started a new MicroVM with my Flask app already running, since it was resumed from a snapshot. My Flask app was already running the moment the launch completed. One API call to get a fully initialized, bootstrapped compute environment.
To send traffic, I generated a short-lived auth token with the CLI and attached it to a plain HTTPS request using the X-aws-proxy-auth header. The request landed on my Flask app immediately. I then let the MicroVM sit idle past the suspend threshold, at which point the MicroVM was suspended, with its memory and disk state snapshotted and stored. I then sent another request, and it resumed with the application state fully intact. From the client side, the pause never happened.
How it works
Under the covers, Lambda MicroVMs delivers three capabilities that, until today, no single AWS compute service offered together. The first is virtual machine level isolation, which comes from Firecracker. Each session runs in its own dedicated MicroVM with no shared kernel and no shared resources between users, so untrusted code supplied by one user is contained to their execution environment, without access to other environments or the underlying system. The second is rapid launch and resume. The model is image-then-launch: you create a MicroVM Image by supplying a Dockerfile and code packaged as a zip artifact in Amazon S3, and Lambda runs your Dockerfile, initializes your application, and takes a Firecracker snapshot of the running environment’s memory and disk state. Every subsequent MicroVM launched from that image resumes from the pre-initialized snapshot rather than booting cold, which means launches and idle resumes both achieve near-instant startup latency. Even a multi-gigabyte interactive session comes back online quickly enough to feel responsive to the end user. The third is stateful execution. A running MicroVM retains memory, disk, and running processes across the user’s session. During idle periods, a MicroVM can be suspended – with memory and disk state intact – and resumed when traffic arrives. Installed packages, loaded models, and working filesets are readily available when the user resumes their session. MicroVMs support up to 8 hours of total runtime and can be suspended automatically after a configurable idle window, which makes it straightforward to build products as varied as software vulnerability scans that complete in minutes, data analytics applications that run for hours, and interactive coding sessions with extended idle periods. As Lambda MicroVMs are started from pre-initialized snapshots, applications generating unique content, establishing network connections, or loading ephemeral data during initialization may need to integrate with service-provided hooks for compatibility.
Lambda MicroVMs is a new resource within AWS Lambda, with a distinct API surface. Lambda Functions remain the right choice for event-driven, request-response workloads, and Lambda MicroVMs is purpose-built for multi-tenant applications that need to hand each end user or session their own isolated environment to execute user- or AI-generated code. The two complement each other. An application using Lambda Functions for its event-driven backbone can call into Lambda MicroVMs for the steps that need to run untrusted code in isolation. You bring the application, and the service delivers the execution environment.
Now available
AWS Lambda MicroVMs is available today in the US East (N. Virginia, Ohio), US West (Oregon), Europe (Ireland) and Asia Pacific (Tokyo) Regions, on the ARM64 architecture, with up to 16 vCPUs, 32 GB of memory, and 32 GB of disk per MicroVM. Idle MicroVMs can be suspended explicitly through an API call or automatically through a lifecycle policy, which reduces the running cost while preserving full state for fast resume. Pricing details can be found on the AWS Lambda pricing page.
To get started, visit the AWS Lambda console, or learn more on the Lambda MicroVMs product page. For documentation, see the Lambda MicroVMs Developer Guide.
Last week AWS Summit New York City brought together thousands of customers, partners, and builders for a free, one-day event showcasing the latest in cloud and AI innovation. Dr. Swami Sivasubramanian, VP of Agentic AI at AWS unveiled a stack of AI launches in his keynote, all built around one thesis: agents that compound value over time.
To learn more, visit the Summit recap from our top announcements blog post and Amazon News post.
Last week’s launches
Here are last week’s launches that caught my attention:
ap-southeast-1-han-1a) from the Regions and Zones tab in the AWS Global View or by using the ModifyAvailabilityZoneGroup API.For a full list of AWS announcements, be sure to keep an eye on the What’s New with AWS page.
Price reductions
AWS continues to look for ways to increase performance and lower prices for our customers. I noticed a few such efforts last week, so I’d like to share them:
Learn more about AWS, browse and join upcoming AWS-led in-person and virtual events, startup events, and developer-focused events as well as AWS Summits and AWS Community Days. Join the AWS Builder Center to connect with builders, share solutions, and access content that supports your development.
That’s all for this week. Check back next Monday for another Weekly Roundup!
— Channy
Webshells have been popular for a long time. We already covered this topic across multiple diaries[1][2]. I spent some time to track them[3] and slighly paid less attention to them but today I found another one. It seems to be a new player (pushed on Github two months ago).
I detected an interesting phishing email this morning. It targets a major Belgian bank:
The phishing in itself is a classic one, not relevant but the malicious link is interesting:
hxxp://[::ffff:5511:74be]/kWC5PHA1
The technique used by the attacker is to bypass simple security controls trying to extract domain names and IP addresses via simple regular expressions. The notation “[…]” tells the URL parser that what's inside is a literal IPv6 address. But it’s not a real IPv6 address. What’s the magic?
The started “::” in the address means that it can be expanded to this address:
0000:0000:0000:0000:0000:ffff:5511:74be
The trick is the fifth group (::ffff:) means that we are facing a IPv5-mapped IPv6 address. This is defined in RFC 4291[1]:
In the URL above, the two trailing 16-bit hex groups “5511” and “74be” are just the four IPv4 octets written in hex.
| Hex | Dec |
|---|---|
| 0x55 | 85 |
| 0x11 | 17 |
| 0x74 | 116 |
| 0xBE | 190 |
The real URL is therefore:
hxxp://85[.]17[.]116[.]190/kWC5PHA1
Another good news from the attacker’s point of view, there is no DNS record!
When visited, this URL redirects to another link where the real phishing kit is hosted:
hxxps://3439-aanmelden[.]verificatie[.]qzz[.]io/mon-belfius
[1] https://www.rfc-editor.org/info/rfc4291/
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.
Amazon Elastic Container Service (Amazon ECS) service auto scaling automatically adjusts task counts to meet workload demand with comprehensive scaling policies, including predictive scaling for recurring traffic patterns, scheduled scaling for planned events, and target tracking to scale dynamically on real-time metrics.
You can choose proactive scaling by using predictive scaling (automatic) and scheduled scaling (customer-defined), or reactive scaling by using target tracking with just a target to scale on. Amazon ECS service auto scaling adjusts the number of tasks in an ECS service based on Amazon CloudWatch metrics, such as average CPU/Memory usage, request count per target, a custom metric such as queue depth, or demand surges by using advanced machine learning (ML) algorithms.
With today’s launch, Amazon ECS service auto scaling now detects and responds to load changes faster with support for high resolution (20-second) metrics and metric publishing optimizations. In AWS benchmarking tests, time to trigger scale-out improved from 363 seconds to 86 seconds (76% faster, 4.2x), and total time to scale and provision new tasks improved from 386 seconds to 109 seconds (72% faster, 3.5x)
This launch delivers three key benefits for your applications:
How it works
To use ECS faster service auto scaling, first enable high-resolution metrics for your ECS service, and then configure a target tracking scaling policy which uses high-resolution metrics. ECS faster service autoscaling works across all compute options on ECS: AWS Fargate, ECS Managed Instances, and Amazon Elastic Compute Cloud (Amazon EC2). You can enable these metrics when you create or update your ECS service in the Amazon ECS console, or using AWS SDKs and tools, and AWS CloudFormation.
When you create a service in the console, add 20-seconds resolution metrics in the Monitoring configuration section. These metrics incur additional CloudWatch costs while the standard resolution (60-seconds) is free.
In the Service auto scaling section, check Use service auto scaling and choose Target Tracking for the scaling policy type to use real-time data to scale the number of tasks that your service runs based on demand.
Then, choose a Scaling policy type for the target tracking. You can select ECSServiceAverageCPUUtilizationHighResolution or ECSServiceAverageMemoryUtilizationHighResolution as new metrics.
That’s it – your ECS service will use high resolution metrics for auto scaling.
To update an existing ECS service to use faster auto scaling, you first need to configure high resolution metrics via Update Service. Once deployment completes, your service will generate high-resolution metrics. You can then go to the Service and auto scaling tab from your service details to update scaling policy to use higher resolution metrics.
That’s all you need. Your ECS service now evaluates scaling decisions at 20-second intervals.
You can also use the AWS Command Line Interface (AWS CLI) to enable new metrics in your ECS service through Application Auto Scaling. To learn more, visit the faster auto scaling documentation.
Now available
Faster service autoscaling with high-resolution metrics for Amazon ECS is available today. The feature itself has no additional cost, but high-resolution CloudWatch metrics introduce a new pricing dimension. For details, see the CloudWatch pricing page.
Give it a try today and send feedback to AWS re:Post for ECS or through your usual AWS Support contacts.
— Channy
[This is a Guest Diary by Adam Nason, an ISC intern as part of the SANS.edu BACS program]
Brute force SSH attacks are an ever-present threat on the internet today. We examine probing behavior over the last three months to identify coordinated and opportunistic attacks by threat actors. A DShield Honeypot has quietly collected and logged the behavior of these threat actors to develop a clearer picture of their malicious intentions. During the log collection period, several significant cyber and geopolitical events occurred. We will take a closer look at these behaviors by analyzing their timing and cross-referencing them with external factors that align with their attack patterns. Can an increase or change in SSH brute force botnet activity be observed during these volatile times?
Infrastructure Setup and Data Collection Framework – Home Lab
Infrastructure
• Raspberry Pi 4 Model B
• Network Equipment – Isolated from personal home network
o UniFi Security Gateway Pro
o UniFi 24 Port Switch
Data Ingestion
• RaspberryOS running on Raspberry Pi
• DShield Honeypot Software
o Logs Collected: 17 Feb 2026 through 26 May 2026
Software Tools
• Elasticsearch, Logstash, Kabana (ELK)
• Microsoft VS Code (JSON and Python)
• Microsoft Excel
Data Analysis of Honeypot Logs
Scanning Volume and Timeline Overview
The cowrie honeypot logs recorded over 20 million SSH brute-force attempts over the past 100 days. Investigation into the scanning trends appears to be closely correlated with Chinese botnets, major law enforcement actions, geopolitical events, and critical cybersecurity advisories released in the first half of 2026. As shown in Figure 1: Daily Brute Force Probing Totals, the timeline shows extended periods of high-volume traffic, with abrupt spikes and drops that seem to align with external events.
Table 1: Overview of SSH data collected
Figure 1: Daily Brute Force Probing Totals
Notable events within the brute force scan timeline
February 17 – 24 (Initial Baseline)
The first week of running the honeypot produced what can be considered a quiet baseline of standard background scanning activity. During this period, between 200 and 400 attempts were captured each day.
February 25 – 28 (Sudden Surge)
Following a quiet start, a spike of over 2100% attempts was observed by the honeypot. It was during this period that CISA published Emergency Directive 26-03 (CISA, 2026), related to Cisco’s software-defined wide-area network, which led to opportunistic attacks against unpatched systems. Additional probing was observed during this period, which can also be attributed to the rising conflict between Iran, Israel, and the United States (Al Jazeera, 2026).
March 1 – 8 (Activity Peaks)
Scanning observations peaked this week, with over 300,000 events collected on March 8th (Radauskas, 2026). This is as tensions continue to rise between Iran, Israel, and the United States, and both advanced persistent threats and opportunistic botnets are becoming more active (Reuters, 2026).
March 9 – April 14 (Sustained Attacks)
The honeypot continues to collect and log a high volume of activity during this period, with daily probes remaining above 50,000, often exceeding 100,000 (Le Poidevin, 2026). The periodic spikes and dips tend to lean towards automated attack campaigns.
April 15 (Rapid Decline)
Attack observations plummet to just over 23,000 attempts logged by the honeypot.
April 16 – May 14 (Attack Rebounds)
With news of new vulnerabilities (CISA, 2026), and tensions growing with the Iran-United States ceasefire, logged scans start to rise again. A second spike is observed on May 2nd with 244,344 probes in a single day. This comes just after 24 hours following a major Linux vulnerability that was published by CISA (CISA, 2026)
May 15 – 23 (Extended Decline)
Daily log observations drop nearly 95%, as the ceasefire extends (Madhani et al., 2026), and opportunistic threat actors lose interest as the Iran, Israel, and United States war continues to drag on with minimal active military engagements.
Top 10 Identified Probing IPs (Patterns, Clusters, and Campaign Data)
From February 2026 through May 2026, the top ten observed IP addresses (Table 2) appeared to have strong geographic and Autonomous System Number (ASN) clustering. Both DigitalOcean (ASN – AS14061) and M247 (ASN – AS9009) show activity from multiple countries (Table 3). Furthermore, synchronized scanning bursts can be observed using identical SSH client fingerprints and version strings, occurring within minutes of each other across different countries.
Table 2: Top Ten Probing IPs, with Country and ASN
Table 3: Country Clustering of IPs and ASN
A closer review of the data shows an example of what appears to be synchronized scanning. Over the course of 53 seconds, two attacks are observed from both the United States and Ukraine. Of note, both attacks exhibit the same HASSH fingerprint. HASSH is a fingerprinting standard developed by the Detection Cloud team at Salesforce and is used to detect attacks with higher granularity than a simple IP address can (Reardon, 2022). Seeing the same HASSH, SSH Version, from two different ASNs and countries does point to a high likelihood of a coordinated attack.
Table 4: Clustered attack within 53-seconds
Further review of the collected honeypot logs shows that 702,706 events use the exact same HASSH fingerprint (03a80b21afa810682a776a7d42e5e6fb) and SSH version, indicating the use of a single managed attack toolkit that has been deployed globally (SSHwatch, 2025).
Finally, a detailed review of the logs shows evidence of a botnet quota assignment (Table 5). These are throttled scan rates, which are tell-tale indicators of a botnet-driven SSH campaign. Reviewing the logs over such extended periods shows a low variation and high uniform attack rates, which point to a controller assigning quotas or workloads to the botnet zombies under its control. Automating a scan in this type of organization has been shown to be a characteristic of these types of programmed botnet operations (Sing et al., 2024 p. 1731-1750).
Table 5: Attack Rate Analysis of IPs showing Automated Campaigns
Reduce your Attack Surface
As we have seen above, networks are under constant attack, which seems to follow the ebb and flow of external events on digital cyberspace. However, there are several steps you can take to reduce your attack surface, most of which require little effort. Strategies like IP blocks, geo-blocking, and changing default values can go a long way in preventing a potential compromise.
Prevention
• While not specifically noted in this paper, a majority of SSH brute force login attempts observed targeted the user ‘root’. Disabling ‘root’ user login would effectively make all those attack attempts obsolete.
• Enforce Multi-Factor Authentication (MFA).
• Use private keys for SSH, provided they are properly protected, rotated, and audited.
• Properly hardened jump boxes to reduce exposure and enable session monitoring with Security Information and Event Management (SIEM) systems.
(Hartman, 2026)
Detection
• Centralized SIEM Log Collection
• Deploy rules to alert to brute force patterns in platforms like Snort or Suricata. This can include ‘SYN Flood Attacks’ against port 22 (or your SSH port if you change the default value).
(Hartman, 2026)
Conclusion
Over 20 million SSH brute force attempts were collected by my DShield honeypot over nearly 100 days. This data was compared with several major cybersecurity advisories, changing geopolitical tensions, and law enforcement activities, which uncovered a close alignment. The top probing IPs showed clear signs of SSH botnet attack campaigns when evaluating the log data for attack timing, rates, HASSH fingerprints, and SSH client identification. These findings help to illustrate the adaptability and persistence of threat actors as they respond to capitalize on external events, highlighting the underlying need of all connected devices to be aware not only of cybersecurity-related advisories but also of the activities taking place across the globe. Some of the simplest security measures would have stopped many of these attacks in their tracks, raising the persistent need to continue to remind users to change default settings (usernames and ports) and increase the use of MFA.
Have you observed similar activities in your honeypot or within your organization? Feel free to share your findings and experiences in the comments below or consider joining the SANS Internet Storm Center and contributing data to their global network of sensors and honeypots.
[1] Al Jazeera. (2026, February 28). US, Israel bomb Iran: A timeline of talks and threats leading up to attacks. https://www.aljazeera.com/news/2026/2/28/us-israel-bomb-iran-a-timeline-of-talks-and-threats-leading-up-to-attacks#:~:text=US%2C%20Israel%20bomb%20Iran%3A,since%20the%20June%202025
[2] CISA. (2026, February 25). ED 26-03: Mitigate vulnerabilities in Cisco SD-WAN systems. Cybersecurity and Infrastructure Security Agency CISA. https://www.cisa.gov/news-events/directives/ed-26-03-mitigate-vulnerabilities-cisco-sd-wan-systems
[3] CISA. (2026, May 1). CISA adds one known exploited vulnerability to catalog. Cybersecurity and Infrastructure Security Agency CISA. https://www.cisa.gov/news-events/alerts/2026/05/01/cisa-adds-one-known-exploited-vulnerability-catalog
[4] CISA. (2026, April 20). CISA adds eight known exploited vulnerabilities to catalog. Cybersecurity and Infrastructure Security Agency CISA. https://cisa.gov/news-events/alerts/2026/04/20/cisa-adds-eight-known-exploited-vulnerabilities-catalog
[5] Hartman, K. G. (2026, February 13). Securing SSH keys in cloud environments: Practical guidance for security, forensics, and legal accountability. SANS Institute. https://www.sans.org/blog/securing-ssh-keys-cloud-environments-practical-guidance-security-forensics-legal-accountability
[6] Le Poidevin, O. (2026, March 9). UAE envoy to UN urges de-escalation of US-Israeli war with Iran. reuters.com. https://www.reuters.com/world/middle-east/uae-envoy-un-urges-de-escalation-us-israeli-war-with-iran-2026-03-09/#:~:text=UAE%20envoy%20to%20UN,and%20a%20return%20to
[7] Madhani, A., Gambrell, J., Price, M., & Metz, S. (2026, May 29). US and Iranian negotiators reach tentative deal to extend ceasefire and start new nuclear talks. AP News. https://apnews.com/article/iran-us-war-oil-may-28-2026-8f5ed2813ba63df7ae9ccbe991688d29
[8] Radauskas, G. (2026, March 3). Wild pack without a leader: pro-Iranian hackers already active in wake of US-Israeli strikes. Cybernews. https://cybernews.com/security/iran-war-cyberattacks-hacking/
[9] Reardon, B. (2022, April 14). Open sourcing HASSH. Salesforce Engineering Blog. https://engineering.salesforce.com/open-sourcing-hassh-abed3ae5044c/
[10] Reuters. (2026, February 28). Global reaction to US, Israeli attacks on Iran. reuters.com. https://www.reuters.com/business/aerospace-defense/global-reaction-israeli-us-attacks-iran-2026-02-28/#:~:text=Global%20reaction%20to%20US%2C,into%20a%20renewed%20military
[11] Singh, S. K., Gautam, S., Cartier, C., Patil, S., & Ricci, R. (2024). Where The Wild Things Are: Brute-Force SSH Attacks In The Wild And How To Stop Them. USENIX Association, 1731-1750. https://www.usenix.org/conference/nsdi24/presentation/singh-sachin
[12] SSHwatch. (2025, April 28). SSH honeypots: Detecting and understanding attack patterns. https://www.sshwatch.com/ssh-honeypots-detecting-and-understanding-attack-patterns/#:~:text=Distributed%20credential%20partitioning%2C%20wordlist,logs%20with%20tools%20like
[13] https://www.sans.edu/cyber-security-programs/bachelors-degree/
Note: To ensure full transparency and academic integrity, generative A.I. software (Grammarly) was used for grammar and spelling checks. No further use of generative A.I. was used in the creation of this writing.
———–
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.
Today at the AWS Summit in New York City, Swami Sivasubramanian, AWS VP of Agentic AI, provided the day’s keynote.
Here’s our roundup of the biggest announcements from the event:
New in Amazon Bedrock AgentCore
We’re introducing new capabilities on Amazon Bedrock AgentCore: connecting AI agents to organizational, web, and paid knowledge, helping teams find and fix what’s going wrong in production, and enforcing controls that scale as agents grow more capable.
Together, these capabilities help you build more capable agents faster, govern those agents with controls that scale, and improve them continuously. To learn more, read our blog post covering all the new features.
New in AI-based security tools
New in building AI-based applications
In addition to the keynote announcements, we have other important launches this week:
