Accelerate your infrastructure deployments by up to 4x with AWS CloudFormation Express mode

This post was originally published on this site

Today, we’re announcing AWS CloudFormation Express mode, a new deployment mode that accelerates deployments for developers and AI tools iterating on infrastructure. Express mode accelerates deployments by completing when CloudFormation confirms resource configuration is applied, rather than waiting for extended stabilization checks. This reduces deployment time by up to 4 times for iterative development workflows and production scenarios.

How it works
Every CloudFormation deployment performs stabilization checks after resource configuration is applied. These checks serve an important purpose when you need to confirm resources can serve traffic before shifting load.

However, many workflows do not require full stabilization to proceed. Express mode benefits two primary use cases: iterative development workflows and production scenarios where you are comfortable with eventual stabilization. These use cases include iterating on infrastructure configurations during development, testing individual components of your application, and AI-assisted infrastructure development that benefits from sub-minute feedback loops.

With Express mode, CloudFormation completes deployments when resource configuration is applied, without waiting for stabilization checks. Resources continue becoming operational in the background. CloudFormation automatically retries dependent resources that encounter transient failures during provisioning within the same stack, without requiring any customer intervention. This built-in resilience handles timing issues between resources as they stabilize. Express mode changes when the deployment completes, not how resources are provisioned.

For example, when I create an Amazon Simple Queue Service (SQS) queue with a dead letter queue (DLQ), Standard mode takes 64 seconds, but Express mode completes in up to 10 seconds. In the case of deleting an AWS Lambda function with network interface attachment, Standard mode takes 20–30 minutes, but Express mode completes in up to 10 seconds based on my benchmarking test.

Get started with CloudFormation Express mode
When you create a CloudFormation stack in the AWS Management Console, choose Enable in the Express mode under Stack deployment options.

You can also use AWS Command Line Interface (AWS CLI), AWS SDKs, or IaC tools like AWS Cloud Development Kit (CDK), and AI tools such as Kiro.

Activate Express mode by setting the --deployment-config parameter to EXPRESS when creating, updating, or deleting stacks. No template changes are required. Express mode disables rollback by default for the fastest iteration experience. To re-enable rollback, set disableRollback to false in the deployment-config for production environments, or implement monitoring/cleanup mechanisms for failed deployments.

aws cloudformation create-stack  
   --stack-name my-app  
   --template-body file://template.yaml  
   --deployment-config '{"mode": "EXPRESS", "disableRollback": true}' 

For example, use the Express mode when you build infrastructure incrementally, adding resources one at a time. Ensure your IAM role templates follow the principle of least privilege.

# Iteration 1: Deploy IAM role
aws cloudformation create-stack 
--stack-name my-microservice 
--template-body file://iteration1-iam.yaml 
--deployment-config '{"mode": "EXPRESS"}' 
--capabilities CAPABILITY_IAM
--role-arn arn:aws:iam::123456789012:role/CloudFormationDeployRole

# Iteration 2: Add Lambda function
aws cloudformation update-stack 
--stack-name my-microservice 
--template-body file://iteration2-lambda.yaml 
--deployment-config '{"mode": "EXPRESS"}' 
--capabilities CAPABILITY_IAM
--role-arn arn:aws:iam::123456789012:role/CloudFormationDeployRole

# Iteration 3: Add SQS queue and event source mapping
aws cloudformation update-stack 
--stack-name my-microservice 
--template-body file://iteration3-sqs.yaml 
--deployment-config '{"mode": "EXPRESS"}' 
--capabilities CAPABILITY_IAM
--role-arn arn:aws:iam::123456789012:role/CloudFormationDeployRole

For AWS CDK, activate Express mode with the cdk deploy --express command when you deploy your CDK stack. This command retrieves your generated CloudFormation template and deploys it through the CloudFormation Express mode, which provisions your resources as part of a CloudFormation stack.

Express mode works with all existing CloudFormation templates and supports all CloudFormation features including change sets and nested stacks. When you enable Express mode on a parent stack, all nested stacks also use Express mode. If you need resources to be fully operational before proceeding with traffic or testing, continue using the default deployment behavior, which performs stabilization checks before completing.

Now available
AWS CloudFormation Express mode is available today in all AWS commercial Regions at no additional cost. For Regional availability and a future roadmap, visit the AWS Capabilities by Region. If you want to call APIs, search documentation, find regional availability, and check troubleshooting about this new feature, try using the AWS MCP Server and plugins with your preferred AI tool. To learn more, visit the CloudFormation documentation.

Start accelerating your deployments today, and send feedback to AWS re:Post for AWS CloudFormation or through your usual AWS Support contacts.

Channy

Amazon EC2 C9g and C9gd instances powered by AWS Graviton5 processors are now available

This post was originally published on this site

When you run compute-intensive workloads like real-time analytics, batch processing, video encoding, scientific modeling, or CPU-based machine learning inference, every percentage point of performance matters. You need instances that deliver higher throughput per vCPU, faster memory access, and more network bandwidth, all while keeping your costs in check.

Today I am happy to announce the general availability of Amazon Elastic Compute Cloud (Amazon EC2) C9g and C9gd instances, powered by AWS Graviton5 processors. C9g instances are compute-optimized and deliver up to 25% higher performance per vCPU compared to previous-generation C8g instances. They feature the fastest memory of any processor instance in the cloud, with DDR5 8800MT/s DIMMs, 5x more L3 cache, and up to 3x higher packet-processing performance compared to Graviton4-based instances. The faster memory and larger caches mean your workloads spend less time waiting on data, translating into higher throughput for in-memory analytics, faster agentic loops, and more responsive real-time applications.

C9g instances are ideal for batch jobs, video encoding pipelines, or distributed analytics that can utilize Amazon Elastic Block Store (Amazon EBS) for storage. It is also a natural fit for agentic AI workloads, where concurrent environments and CPU-bound reasoning steps benefit from Graviton5’s higher core count and larger caches. As AI shifts from answering questions to taking actions, running code, and orchestrating multi-step tasks, the demand for CPU compute is growing, and C9g instances are built for this shift.

Some workloads also need fast local storage alongside that compute power. Choose C9gd when your application benefits from high-speed, low-latency local NVMe SSD storage, for example scratch space during HPC simulations, temporary caches for ML inference, or local buffers for ad-serving engines.

Graviton5-based instances with NVMe instance store volumes also support detailed performance statistics, providing high-resolution I/O metrics, including latency histograms broken down by I/O size, up to 1-second granularity and accessible via Amazon CloudWatch or nvme-cli at no additional cost.

C9g and C9gd instances at a glance
C9g and C9gd instances are available in 11 sizes ranging from medium to 48xlarge, plus a bare metal option. They offer up to 15% higher network bandwidth and 20% higher EBS bandwidth on average across sizes compared to the previous generation, with the largest 48xlarge size delivering up to 100 Gbps of network bandwidth and up to 72 Gbps of EBS bandwidth, a 2x increase.

C9g vCPUs Memory
(GiB)
Network Bandwidth
(Gbps)
EBS Bandwidth
(Gbps)
medium 1 2 Up to 15 Up to 12
large 2 4 Up to 15 Up to 12
xlarge 4 8 Up to 15 Up to 12
2xlarge 8 16 Up to 17 Up to 12
4xlarge 16 32 Up to 17 Up to 12
8xlarge 32 64 17 12
12xlarge 48 96 25 18
16xlarge 64 128 34 24
24xlarge 96 192 50 36
48xlarge 192 384 100 72
metal-48xl 192 384 100 72

C9gd instances add local NVMe SSD storage with up to 30% higher storage performance compared to previous-generation local storage instances.

C9gd vCPUs Memory
(GiB)
Instance Storage
(GB)
Network Bandwidth
(Gbps)
EBS Bandwidth
(Gbps)
medium 1 2 1 x 59 Up to 15 Up to 12
large 2 4 1 x 118 Up to 15 Up to 12
xlarge 4 8 1 x 237 Up to 15 Up to 12
2xlarge 8 16 1 x 474 Up to 17 Up to 12
4xlarge 16 32 1 x 950 Up to 17 Up to 12
8xlarge 32 64 1 x 1900 17 12
12xlarge 48 96 3 x 950 25 18
16xlarge 64 128 1 x 3800 34 24
24xlarge 96 192 3 x 1900 50 36
48xlarge 192 384 3 x 3800 100 72
metal-48xl 192 384 3 x 3800 100 72

Both families are well-suited for high-performance computing (HPC), batch processing, gaming, video encoding, scientific modeling, distributed analytics, CPU-based machine learning inference, and ad serving.

Here are some additional capabilities:

  • Instance Bandwidth Configuration (IBC) lets you adjust the allocation of bandwidth between Amazon EBS and Amazon VPC networking by up to 25%, helping you optimize performance for workloads with specific bandwidth requirements such as databases and caching.
  • ENA Express support for enhanced networking.
  • Up to 128 EBS volumes can be attached to virtual instances.
  • Support for Savings Plans, On-Demand, Spot Instances, Dedicated Instances, and Dedicated Hosts.

Nitro Isolation Engine
C9g and C9gd instances are the first compute optimized Amazon EC2 instances to feature the AWS Nitro Isolation Engine, a new capability of the AWS Nitro System. The Nitro Isolation Engine is a purpose-built component of the Nitro Hypervisor, implemented in Rust, that enforces isolation between virtual machines. It mediates all access to VM memory, CPU register state, and I/O devices through a minimal set of APIs.

To learn more about the Nitro Isolation Engine, visit the blog post. For details on the formal verification results, including scope and assumptions, see our technical white paper.

Now available
Amazon EC2 C9g and C9gd instances are now available in US East (Ohio, N. Virginia), US West (Oregon), and Europe (Frankfurt). Additional regions will follow.

You can launch C9g and C9gd instances today using the AWS Management Console, AWS Command Line Interface (AWS CLI), or AWS SDKs. For pricing information, visit the Amazon EC2 Pricing page.

To learn more, visit the Amazon EC2 C9g and C9gd instances page and send feedback to AWS re:Post for EC2 or through your usual AWS Support contacts.

— seb

Automate public TLS certificate issuance with ACME support in AWS Certificate Manager

This post was originally published on this site

If you manage TLS certificates for your applications, you know the challenge: certificates expire, and when they do, your customers see errors or your service goes down. As certificate validity periods get shorter (the Certification Authority (CA)/Browser Forum mandates reduced maximum validity to 100 days starting March 2027, and to 47 days by 2029), manual renewal processes become untenable. You need automation.

Automatic Certificate Management Environment (ACME) is an open protocol for requesting, renewing, and revoking TLS certificates without human intervention. It’s the same protocol behind Let’s Encrypt, and it’s supported by dozens of clients across every platform.

Today we’re announcing ACME support for public certificates in AWS Certificate Manager (ACM). ACM now provides a fully managed ACME server endpoint that works with any ACMEv2-compatible client, such as Certbot, cert-manager for Kubernetes, acme.sh, or any other client you already use. You can issue public TLS certificates from Amazon Trust Services through the standard ACME protocol.

Before today, if you wanted automated certificate management using the ACME protocol, you relied on external certificate authorities alongside ACM, leading to a fragmented visibility experience. Some certificates lived in ACM, others were managed externally with no central dashboard. PKI administrators had limited ability to control who could request certificates or which domains were allowed.

With ACME support in ACM, you can now set up one or more managed ACME endpoint that allows you to centrally manage and monitor ACME certificate usage across your organization.

As a PKI administrator, you get centralized controls that go beyond basic certificate issuance. You can bind IAM roles to ACME accounts for fine-grained access control over which domains each client can request. You can define domain scopes at the endpoint level to enforce organization-wide policies. And you get centralized monitoring and visibility in the same place: AWS CloudTrail logs every certificate request for auditability, Amazon CloudWatch tracks operational metrics, and ACM sends expiry notifications when certificates are approaching renewal. Using ACM, your PKI team can search all certificates, whether issued through the ACM console, an API call, or ACME.

How it works
To get started, you first set up a dedicated ACME endpoint, configure authorization controls using External Account Binding (EAB), validate which domains the endpoint can issue certificates for, and point your existing ACME clients to the new endpoint.

The domain validation step is important: it separates who can set up certificate issuance from who can request certificates. The PKI administrator validates domains once at the endpoint level, using DNS credentials that stay with the admin. Application owners who need certificates never touch DNS. They register with an EAB credential, and the endpoint enforces which domains and scopes they’re allowed to request. This means you can distribute certificate automation broadly across your organization without distributing DNS keys along with it.

I start this demo from the ACME certificates page in the AWS Certificate Manager console.

ACME Console

I already have a few endpoints and certificates in this account, I walk you through creating a new one from scratch. First, I select Create ACME endpoint.

ACME - Ceeate endpoint 1

I give my endpoint a name. The Endpoint type is Public. ACME clients will connect over the public internet. The Certificate type is Public. The certificate will be issued by Amazon Trust Services and trusted by browsers and operating systems by default. For the certificate key type, I keep the default ECDSA P-256. RSA 2048 and ECDSA P-384 are also available if your clients require them.

ACME - Ceeate endpoint 2

Scrolling down, I configure the domain. I enter my domain name and select the domain scope. The scope controls exactly what certificate patterns your ACME clients are allowed to request for this domain. If I check only Exact domain, clients can only request certificates for that specific domain name. Adding Subdomains allows certificates for any subdomain (for example, api.example.com or dev.example.com). Adding Wildcards allows wildcard certificates (*.example.com). By leaving a scope unchecked, you prevent any client using this endpoint from requesting that type of certificate, even if their ACME request is otherwise valid. For a production endpoint, you might enable only Exact domain and Subdomains while leaving Wildcards unchecked to enforce a stricter security posture.

I also select my Amazon Route 53 hosted zone from the drop down menu. ACM then automatically creates the DNS CNAME records needed for domain validation, so I don’t have to do it manually. When my domain is hosted outside of Route 53, I manually create the provided CNAME record at my DNS provider instead. This is a meaningful difference from typical ACME setups where each client handles its own domain verification independently.

These centralized controls give PKI administrators a single place to authenticate domains, restrict which certificate types (ECDSA or RSA) clients can request, and further limit wildcard issuance. Having these governance capabilities built in means you don’t need to purchase a separate certificate lifecycle management product or invest in building a custom policy layer yourself, both of which come at significant cost and operational overhead.

I select Create ACME endpoint

ACME - DNS configuration

After a few seconds, the endpoint is created. The console shows a Setup progress tracker with the next steps. My domain shows a “Validating” status. The validation method is DNS validation, where ACM verifies that you control the domain by checking for a specific CNAME record. Because I selected my Route 53 hosted zone during creation, I select Create records in Route 53 to let ACM handle the DNS validation automatically.

ACME - DNS successThe validation completes in a few seconds and the status changes to Success.

ACME - External Account Binding 1

Now I need to create External Account Binding (EAB) credentials. EAB credentials are a key identifier and HMAC key pair that lets your ACME client register an account with the ACME server. Once registered, the client generates its own asymmetric key pair, which is then used to authenticate all subsequent certificate requests. On the endpoint details page, I select the External account binding tab, then select Create EAB. I give the credential a name and optionally set an expiration time, ideally no longer than needed to complete client registration.

ACME - External Account Binding 2

ACME - end of configuration - show key

After I select Create EAB credential, the console shows the Key ID and HMAC Key. I note these values because I need them to configure my ACME client. The setup progress now shows four green checkmarks.

ACME - end of configuration - success

I’m ready to request a certificate. On the endpoint details page, I expand the CLI reference section. The console provides ready-to-use command examples for both Certbot and acme.sh. I copy the Certbot command and run it inside a container using the certbot/certbot image.

certbot certonly --standalone --non-interactive --agree-tos 
    --email <EMAIL> 
    --server https://acm-acme-enroll.us-east-1.api.aws/<ENDPOINT_ID>/directory 
    --eab-kid <EAB_KID> 
    --eab-hmac-key <EAB_HMAC_KEY> 
    --issuance-timeout <ISSUANCE_TIMEOUT> 
    -d <DOMAIN>

I replace the placeholders with my endpoint URL, EAB credentials, and domain name. The --eab-kid and --eab-hmac-key arguments are how Certbot registers with your ACME endpoint using the External Account Binding credentials I generated earlier. Each ACME client has its own syntax for this step, so check your client’s documentation for the exact flags.

Certbot contacts the ACME endpoint and returns a valid certificate signed by Amazon Trust Services.

Certbot to obtain a certificate through ACME

I use openssl to view the certificate before installing it.

openssl to view the certificate

The certificate is now visible in the ACM console under the ACME certificates tab, alongside any certificates issued through the console or API.

Certoficate view in the ACME console

Availability and pricing
ACME support in AWS Certificate Manager is available today in all commercial AWS Regions and will be available in AWS GovCloud (US), the China Regions, and the AWS European Sovereign Cloud partitions at a later date.

Pricing is per domain included in each certificate at the time of issuance, with a different price for fully qualified domain names and wildcards. Volume tiers are calculated based on total domain occurrences across all certificates issued per month in your AWS account. For details, see the ACM pricing page.

To get started, visit the ACM section on the AWS console or read the documentation.

— seb

AWS Weekly Roundup, Agentic CX designer for Amazon Connect Customer, EC2 AMI Watermarks, Open Governance for MySQL, and more (June 29, 2026)

This post was originally published on this site

It has been a busy stretch on the AWS Summit circuit. At the New York City Summit, I delivered a workshop called Building AI architectures with AWS Serverless, and it was a lot of fun watching builders wire up agents and serverless services to solve real problems in a single afternoon. This week I am heading down to the Washington, DC Summit, which always puts a spotlight on innovation in the public sector. If you are going to be there, come say hello.

A question I hear a lot at these events is how teams can put AI to work without waiting on a long engineering backlog, and this week’s biggest launch speaks directly to that, with Amazon Connect Customer introducing a no-code way for business teams to design AI powered customer experiences themselves. Now, let’s get into this week’s AWS news.

Headlines

Amazon Connect Customer launched the Agentic CX designer (NLX) in preview, a no-code canvas for designing and deploying AI powered self service experiences. Business teams can build and launch voice and digital experiences that bring agentic and deterministic AI together in one governed flow, going from design to testing and simulation to production ready experiences in weeks rather than months. The launch also includes Live Sync in preview, a patented technology that drives a customer’s web or mobile experience in real time as they speak or type. A caller can complete a form or pull up the right product page without ever leaving the conversation. To see how this reshapes who designs customer experience, read the blog post on how the business user is the new architect of customer experience and visit the Amazon Connect Customer page.

Last week’s launches

Here are some launches and updates from this past week that caught my attention:

  • AWS Lambda MicroVMs – A new serverless compute primitive that gives each user or job VM level isolation with near instant launch and resume speeds, plus the ability to suspend and resume execution for up to 8 hours. Built on Firecracker, it is made for running user or AI generated code in multi-tenant applications without managing virtualization infrastructure or trading off isolation, speed, and state.
  • Amazon EC2 AMI Watermarks – Lets you embed custom identifiers in your private AMIs that automatically carry forward to every derived AMI across copies, Regions, and account shares. You can combine watermarks with Allowed AMIs and Declarative Policies to restrict launches to approved images, available at no additional cost in all AWS Regions.
  • AWS Outposts self-service lifecycle management – Adds self service configuration, quoting, ordering, subscription management, renewal, and decommissioning directly from the console, CLI, and API. A new quoting tool generates real time cost estimates in seconds and surfaces account and regional constraints before you submit an order.
  • Amazon MSK AI Agent Skills – Gives AI coding assistants like Kiro, Claude Code, and Cursor expert, up-to-date guidance for operating Amazon MSK, covering troubleshooting, sizing, configuring, monitoring, and migrating external Kafka clusters to MSK Express. Tasks that once required specialized knowledge become a guided experience developers can complete on their own.
  • Amazon OpenSearch Service AI-assisted migrations – Migration Assistant now includes an agent guided experience that helps you move self managed Apache Solr, Elasticsearch, or OpenSearch deployments to OpenSearch Serverless or Managed Clusters using tools like Kiro and Claude Code, with new live traffic capture and replay support for Solr.
  • Amazon GuardDuty AI-powered investigations (preview) – Automatically analyzes findings and accounts to help you separate true threats from benign activity, examining context and related activity from the last 90 days with knowledge graphs and threat intelligence. Each investigation returns a disposition assessment with confidence scoring, MITRE ATT&CK classification, and actionable recommendations in minutes.

For a full list of AWS announcements, be sure to keep an eye on the What’s New with AWS page.

Other AWS news

Here are some additional posts and resources that you might find interesting:

  • Open Governance for MySQL – Oracle announced a community governance model for MySQL that gives organizations outside Oracle a defined role in the project, including four non Oracle seats on a new Steering Committee and a public GitHub presence. AWS holds a seat and shares why it supports the move and how it already contributes fixes upstream for everyone running MySQL.
  • A new way to keep your AWS Certification current -You can now maintain an eligible AWS Certification for an additional year by completing curated training and hands on labs on AWS Skill Builder instead of retaking a full exam. The option is available today in open beta for several Associate and Professional certifications, with more coming later this year.
  • The All Builders Welcome Grant insider’s guide for 2026 applicants – A community guide on AWS Builder Center that walks early career builders through applying for the grant, which covers a full conference pass, airfare, and hotel for AWS re:Invent 2026. Applications are open now and close on July 14.

For a full list of AWS blog posts, be sure to keep an eye on the AWS Blogs page.

Looking for ways to connect with builders in person? Check out the AWS Summits coming to a city near you, find a local AWS Community Day led by user groups around the world, and explore tutorials, community content, and ways to grow your skills over at the AWS Builder Center.

That’s all for this week. Check back next Monday for another Weekly Roundup!

-Micah

YARA-X 1.18.0 and 1.19.0 Release, (Sun, Jun 28th)

This post was originally published on this site

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.

Linux Process Name Masquerading, (Wed, Jun 24th)

This post was originally published on this site

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.

CVE-2024-40766: The Patch Fixed the Bug. Nobody Fixed the Configuration., (Tue, Jun 23rd)

This post was originally published on this site

The vulnerability

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.

Who is exploiting and how

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.

What we found on patched firewalls

Figure 1 summarizes the residual risk indicators we found across the audited devices. All identifiers are anonymized.

Figure 1???????
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.

The LDAP default user group problem

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.

The virtual office portal bypass

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.

What the sessions show you

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.

What actual remediation looks like

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.

Post-patch hunting checklist

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.

Specific indicators of prior exploitation

Beyond the configuration items there are forensic artifacts that indicate the device was accessed by an attacker before the patch was applied:

  • Usernames with non-printable characters. Export the local user list and inspect it in a hex editor or run it through a script that flags any byte outside the ASCII printable range (0x20-0x7E). Automated exploitation tooling sometimes creates accounts with null bytes or control characters that look normal in the web interface but show up in raw exports.
  • Packet captures created during the compromise window. If an attacker gained admin access to the firewall they may have used the built-in packet capture to sniff LDAP bind credentials or internal traffic. Check Device > Diagnostics for saved captures and cross-reference creation timestamps against the incident timeline.
  • TOTP enrollments outside normal onboarding. Review the audit log for MFA/TOTP configuration changes. An attacker who enrolled their own TOTP device will appear as a configuration change against an existing account at an unusual time.
  • Configuration backups exported to unknown destinations. SonicWall config backups contain encrypted credentials. If a backup was exported during the compromise window the attacker can work on cracking the AES-256-encrypted passwords offline. Check system logs for configuration export events.
  • LDAP bind credential exposure. If a local admin account was compromised the attacker could have viewed the LDAP configuration page and obtained the bind password. Rotate the LDAP bind credential as part of the post-patch cleanup. The cost of rotation is low. The cost of a wrong assumption is not.

Detection rules worth implementing now

Here are some alerting rules derived from the patterns observed across the audited firewalls:

  • SSLVPN auth from hosting and VPS ASNs. Build a list of the top 20 hosting provider ASNs and alert on any SSLVPN authentication from them. Legitimate remote workers connect from residential ISPs. Attackers connect from hosting infrastructure. This single rule would have flagged the suspicious sessions in Figure 2 on day one.
  • Session duration exceeding 24 hours. No legitimate VPN session runs for days. Alert on any session over 24 hours. Terminate it. Investigate it.
  • Auth to accounts not in the current HR roster. Join the SSLVPN authentication log against an HR system or AD extract daily. Any successful authentication to a disabled, deleted or unknown account is an incident. Full stop.
  • Rapid multi-account authentication from a single source. Huntress documented attackers authenticating across dozens of accounts in minutes using valid credentials. That is not brute force. That is credential replay. Alert on more than five successful SSLVPN auths from a single source IP within 10 minutes.
  • External access to the Virtual Office Portal. If the portal is restricted to internal addresses then this rule catches bypass attempts. If the portal is still public then this rule shows you how often it is being probed.
  • sess="CLI" session type in VPN authentication logs. ReliaQuest documented in May 2026 that every brute-force attempt they observed against CVE-2024-12802 used this session type in the SonicWall logs. It indicates scripted or automated VPN authentication rather than an interactive user session. After successful access the session type changed to sess="GMS". That transition from CLI to GMS is a strong signal that automated credential testing just turned into hands-on-keyboard activity. Determine first whether any legitimate CLI-based VPN authentication exists in your environment. If none is authorized then any appearance of sess="CLI" is a high-confidence alert. Correlate with Event ID 238 for failed VPN logins and Event ID 1080 for successful SSL VPN zone logins.

Conclusion

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.