With International Anti-Ransomware Day taking place on May 12, Kaspersky presents its annual report on the evolving global and regional ransomware cyberthreat landscape.

Ransomware remains one of the most persistent and adaptive cyberthreats. In 2026:

• New families continue to emerge, adopting post-quantum cryptography ciphers.
• As ransom payments drop, some groups implement encryptionless extortion attacks.
• In a constantly changing ecosystem of threat actors, initial access brokers maintain a relevant role in this market, showing increased focus on access to RDWeb as the preferred method of remote access.

Ransomware attacks decline but remain a major threat

According to Kaspersky Security Network, the share of organizations affected by ransomware decreased in 2025 across all regions compared to 2024.

Percentage of organizations affected by ransomware attacks by region, 2025 (download)

Despite the formal decrease, organizations across all sectors continue to face a high likelihood of attack, as ransomware operators refine their tactics and scale their operations with increasing efficiency. Kaspersky and VDC Research have found that in the manufacturing sector alone, ransomware attacks may have caused over $18 billion in losses in the first three quarters of the year.

The continued rise of EDR killers and defense evasion tooling

In 2026, ransomware operators increasingly prioritize neutralizing endpoint defenses before executing their payloads. Tools commonly referred to as “EDR killers” have become a standard component of attack playbooks. This reflects a continuing trend toward more deliberate and methodical intrusions.

Attackers attempt to terminate security processes and disable monitoring agents, often by exploiting trusted components such as signed drivers. This technique is called Bring Your Own Vulnerable Driver (BYOVD) and allows adversaries to blend into legitimate system activity while gradually degrading defensive visibility.

Thus, evasion is no longer an opportunistic step but a planned and repeatable phase of the attack lifecycle. As a result, organizations are increasingly challenged not just to detect ransomware but also to maintain control in environments where security controls themselves are actively targeted.

The appearance of new families adopting post-quantum cryptography

We predicted that quantum-resistant ransomware would appear in 2025. Looking back at the previous year, we see that advanced ransomware groups indeed started using post-quantum cryptography as quantum computing evolved. The encryption techniques used by this quantum-proof ransomware could be used to resist decryption attempts from both classical and quantum computers, making it nearly impossible for victims to decrypt their data without having to pay a ransom.

One example is the appearance of the PE32 ransomware family (link in Russian); it leverages the cutting-edge ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism) standard to secure its AES keys. This specific cryptographic framework was recently selected by NIST as the primary standard for post-quantum defense.

Within the PE32 ransomware architecture, this is realized through the Kyber1024 algorithm, a robust mechanism providing Level 5 security, roughly equivalent in strength to AES-256. Its primary function is the secure generation and transmission of shared secrets between parties, specifically engineered to withstand future quantum computing attacks. This shift toward post-quantum readiness is part of a broader industry trend; for instance, TLS 1.3 and QUIC protocols have already adopted the X25519Kyber768 hybrid model, which fuses classical encryption with quantum-resistant security.

The shift to encryptionless extortion

In 2025, the share of ransoms paid dropped to 28%. As a response to this, one of the developments in the 2026 landscape is the growing prevalence of extortion incidents in which no file encryption takes place at all. Instead, attackers leave out the “ware” in “ransomware” and focus on extracting sensitive data and leveraging the threat of public disclosure as their primary means of extortion. ShinyHunters is an excellent example of such a group, using a data leak site to publicize its victims.

By avoiding encryption, attackers may aim at reducing the likelihood of immediate detection, shortening the duration of the attack, and eliminating dependencies on stable encryption routines. Often, this model is used alongside traditional tactics in so-called double extortion schemes, but an increasing number of campaigns rely exclusively on data theft.

For victims, this shift fundamentally changes the nature of the risk. While backups remain effective against encryption-based disruption, they provide no protection against data exposure, regulatory consequences, and reputational damage. Ransomware is therefore evolving from a business continuity issue into a broader data security and compliance challenge.

Industrialization of initial access (Access-as-a-Service)

The ransomware ecosystem continues to evolve toward a highly industrialized and specialized model, with initial access remaining as one of its most critical components. In 2026, many ransomware operators keep relying on IABs (initial access brokers), a network of intermediaries who supply pre-compromised access to corporate environments, aiming to no longer perform full intrusions themselves.

This “access-as-a-service” model is fueled by credential theft operations, and the widespread availability of compromised accounts harvested through infostealers and phishing campaigns.

The primary access vectors offered for sale have not changed: RDP, VPN, and RDWeb are still the top access vectors. Consequently, remote access infrastructure remains the primary attack surface for initial access sales. In response to the measures against public exposure of RDP access points to the internet, attackers are now targeting RDWeb portals, which are frequently vulnerable and occasionally inadequately safeguarded.

The result is a threat landscape where unauthorized access is increasingly commoditized, and the barrier to launching ransomware attacks declines. This means that preventing initial compromise is only part of the challenge; equal emphasis must be placed on detecting misuse of legitimate credentials and limiting lateral movement within already-breached environments.

Ransomware developments on the dark web

Telegram channels and underground forums increasingly function as platforms for the distribution and sale of compromised datasets and access credentials including those that were obtained as a result of ransomware attacks.

Advertisements posted on these resources typically include the nature of the access, a description of the exfiltrated or compromised data, price terms, and contact information for prospective buyers. In addition, some malicious actors mention their collaboration with other ransomware groups. Lesser-known gangs can use this name-dropping to promote themselves

Multiple threat actors not related to ransomware groups distribute datasets downloaded from ransomware blogs on underground forums and Telegram. By re-publishing download links and files, they spread compromised data as well as information on the ransomware attack within the community.

The ransomware itself is also sold or offered for subscription on the dark web platforms. The sellers underscore the uniqueness of their malware, as well as its encryption and defense evasion features.

Law enforcement actions

Law enforcement agencies are actively shutting down dark web platforms and ransomware data leak sites. A major underground forum, RAMP, which also functioned as a platform for threat actors to advertise their ransomware services and publish service‑related updates, was seized by authorities in January 2026. Another underground forum, LeakBase, where malicious actors distributed exfiltrated and compromised data, was seized in March 2026. In 2025, law enforcement agencies seized well-known forums like Nulled, Cracked, and XSS. Also in 2025, the DLSs of BlackSuit and 8Base ransomware groups were seized. These takedowns cause inconvenience to ransomware coordination, specifically for initial access brokers and affiliates, though similar forums are expected to fill the void over time.

Top ransomware groups in 2025

RansomHub’s sudden dormancy in 2025 marked a shift, and Qilin became the dominant player from Q2 onward. According to Kaspersky research, Qilin was the most active group executing targeted attacks in 2025.

Each group’s share of victims according to its data leak site (DLS) as a percentage of all reported victims of all groups during the period under review (download)

Qilin stands out as one of the fastest-growig and dominant RaaS platforms. Its combination of high-volume operations and structured affiliate model positions it as a central player in the current ecosystem.

Clop, the second most active group in 2025, is distinguished through its large-scale, supply-chain-style attacks, exploiting widely used file transfer and enterprise software to compromise hundreds of victims simultaneously. This one-to-many approach sets it apart from more traditional, single-target campaigns.

Third place is occupied by Akira, which remains notable for its consistency and operational stability, maintaining a steady stream of victims without major disruption. Its ability to sustain activity over time makes it one of the most reliable indicators of baseline ransomware threat levels.

Although no longer active, RansomHub stands out for its rapid rise and equally rapid disappearance in 2025, highlighting the volatility of the RaaS market. Its shutdown created a vacuum that significantly reshaped affiliate distribution across other groups.

DragonForce is also notable – not just for its own operations, but for its broader influence within the ransomware ecosystem, including reported involvement in infrastructure conflicts and possible links to the disruption of competing groups. Thus, the group claims that RansomHub “has moved to their infrastructure.” This positions it as more than just an operator and potentially an ecosystem-level actor.

New actors in 2026

While emerging actors generally operate on a smaller scale, they provide insight into the continuous churn and low barrier to entry within the ransomware ecosystem.

The Gentlemen group caught our attention in early 2026, as they managed to attack a significant number of victims over a short time. This actor is also notable for reflecting a broader shift toward professionalization and controlled operations within the ransomware ecosystem. Unlike many emerging groups that rely on opportunistic attacks and inconsistent leak activity, The Gentlemen demonstrate a more deliberate approach: structured intrusion workflows, selective targeting, and measured communication with victims. This signals a move away from chaotic, high-noise campaigns toward predictable, business-like execution models that are easier to scale and harder to disrupt. Their TTPs include the massive exploitation of hardware very common on big corporations, such as FortiOS/FortiProxy, SonicWall VPN, and Cisco ASA appliances. The group might be comprised of professional cybercriminals who left other prominent groups.

The group is also notable for its emphasis on data-centric extortion strategies, often prioritizing exfiltration and leverage over purely disruptive encryption. This aligns with one of the defining trends of 2026: ransomware evolving into a form of data breach monetization rather than just system denial. By focusing on controlled pressure and reputational risk instead of immediate operational damage, The Gentlemen exemplify how attackers are adapting to lower ransom payment rates and improved backup practices among victims.
Some other groups to take note of in 2026:

• Devman appears to be an emerging actor with limited but growing activity, likely leveraging existing tooling rather than developing custom capabilities.
• MintEye hasn’t been very active yet, with just five known victims, suggesting opportunistic campaigns without a consistent operational tempo.
• DireWolf is associated with small-scale, targeted attacks, though its overall footprint remains relatively limited compared to larger RaaS groups.
• NightSpire demonstrates characteristics of an amateur group, such as mistakes during its operations, uncommon communication channels with the victims, and sometimes giving them insufficient time to pay up. Although they both encrypt and leak data, they prioritize publication rather than encryption.
• Vect shows low-volume activity. It is yet unclear whether they use a completely new codebase or are rather a rebrand of an existing group.
• Tengu is a less prominent actor, with limited public reporting and no clear distinguishing tactics beyond standard extortion models.
• Kazu appears to be created by ransomware operators previously engaged with multiple other groups. As of now, they don’t stand out for scale or technique.

Although there is little to say about these groups at the time of writing this report, each of them may be equally likely to disappear from the threat landscape or grow into a prominent threat. That’s why it’s important to track them from their early days. Moreover, collectively, these groups illustrate how dynamic the ransomware landscape is, with new entrants constantly replenishing it.

Conclusion and protection recommendations

Despite the growing effort by law enforcement agencies across the globe to seize and disrupt dark web platforms and threat actor infrastructures, ransomware operations remain stable, with new groups quickly taking the place of those who went silent. In 2026, we see a shift towards encryptionless extortion, with data leaks increasingly becoming the main threat to target organizations. At the same time, data encryption is also upgrading to the next level with the emergence of post-quantum ransomware.

To resist the evolving threat, Kaspersky recommends organizations:

Prioritize proactive prevention through patching and vulnerability management. Many ransomware attacks exploit unpatched systems, so organizations should implement automated patch management tools to ensure timely updates for operating systems, software, and drivers. For Windows environments, enabling Microsoft’s Vulnerable Driver Blocklist is critical to thwarting BYOVD attacks. Regularly scan for vulnerabilities and prioritize high-severity flaws, especially in widely used software.

Strengthen remote access: RDP and RDWeb connections should never be directly exposed to the internet, only through VPN or ZTNA (Zero Trust Network Access). It’s highly recommended to adopt multi-factor authentication on everything; the architecture may require continuous authentication for access, as one valid credential captured is enough to cause a breach. Monitoring the underground for stolen employee credentials is essential. Audit open ports across the entire attack surface. The adoption of the “Principle of Least Privilege” (PoLP), where users, systems, or processes are granted only the minimum access rights, such as read, write, or execute permissions, necessary to perform their specific job functions, is highly recommended.

Strengthen endpoint and network security with advanced detection and segmentation. Deploy robust endpoint detection and response solutions such as Kaspersky NEXT EDR to monitor for suspicious activity like driver loading or process termination. Network segmentation is equally important. Limit lateral movement by isolating critical systems and using firewalls to restrict traffic. Complete and immediate offboarding for employees is necessary as well as periodic permission reviews, with automatic revocation of unused access. Sessions with complete logging for privileged accounts are more than necessary. Monitoring the traffic divergence to new sites or even to legitimate endpoints can help the defenders to spot a new insider threat.

Invest in backups, training, and incident response planning. Maintain offline or immutable backups that are tested regularly to ensure rapid recovery without paying a ransom. Backups should cover critical data and systems and be stored in air-gapped environments to resist encryption or deletion. User education is essential to combatting phishing, which remains one of the top attack vectors. Conduct simulated phishing exercises and train employees to recognize AI-crafted emails. Kaspersky Global Emergency Response Team (GERT) can help develop and test an incident response plan to minimize potential downtime and costs.

The recommendation to avoid paying a ransom remains robust, especially given the risk of unavailable keys due to dismantled infrastructure, affiliate chaos, or malicious intent. By investing in backups, incident response, and preventive measures like patching and training, organizations can avoid funding criminals and mitigate the impact.

Kaspersky also offers free decryptors for certain ransomware families. If you get hit by ransomware, check to see if there’s a decryptor available for the ransomware family used against you.

Migrating your TLS endpoints to Post-quantum cryptography (PQC) starts with understanding your current TLS endpoint inventory and posture. This post introduces the PQC Readiness Scanner — an automated tool that inventories your Application Load Balancer (ALB), Network Load Balancer (NLB), and Amazon API Gateway endpoints and continuously monitors their TLS configurations for PQC readiness. The scanner classifies each endpoint into a three-tier framework that helps prioritize and plan PQC migration.

As quantum computing advances, you need to migrate to quantum-resistant cryptography to protect your data long-term. The PQC Readiness Scanner helps you identify which endpoints to migrate first and tracks your progress across accounts. For web traffic, PQC key exchange algorithms are negotiated only within TLS 1.3. This means quantum-resistant connections require endpoints that support TLS 1.3 and PQC key exchange.

Under the AWS Shared Responsibility Model, AWS secures the infrastructure and enables PQC support across its services. Customers are responsible for configuring their resources to use PQC-capable TLS policies. For AWS-terminated TLS connections—such as those on Application Load Balancer (ALB), Network Load Balancer (NLB), Amazon API Gateway, and Amazon CloudFront—customers choose the security policy (an AWS-managed configuration defining supported TLS protocol versions and cipher suites for a listener) that determines TLS version and cipher suite, key exchange, and authentication algorithm support.

The automated PQC Readiness Scanner for AWS-terminated TLS endpoints is built using AWS Config conformance packs. A conformance pack is a collection of AWS Config rules and remediation actions that can be deployed as a single entity in an account and a Region or across an organization in AWS Organizations.

The PQC Readiness Scanner deploys AWS Config rules using a conformance pack to evaluate the security policy on each endpoint. Based on the evaluation, each resource is classified into a three-tier readiness framework that prioritizes migration actions needed to achieve PQ-ready TLS.

The PQC Readiness Scanner performs two checks per resource:

1. Does the endpoint use a PQ-ready security policy?
2. Does the endpoint support legacy TLS 1.0 or 1.1?

Each check returns COMPLIANT or NON_COMPLIANT status with specific policy recommendations.

PQC requires endpoints to support TLS 1.3 and use PQC key exchange algorithms. The three-tier framework helps you interpret findings and prioritize fixes. The goal is to have TLS 1.3 with PQC key exchange enabled on the endpoints. However, achieving this requires maintaining backward compatibility with clients.

• Tier 1 represents the strongest security using only TLS 1.3 with PQC key exchange. These resources already meet the target state.
• Tier 2 represents a backward-compatible PQ-ready configuration. Endpoints support both TLS 1.2 and TLS 1.3, with PQC key exchange negotiated on TLS 1.3 connections. Migration priority is low because these resources already provide quantum-resistant protection for clients that support TLS 1.3, while maintaining TLS 1.2 compatibility for legacy clients. Migrate to Tier 1 when client-side analysis confirms that the connecting clients support TLS 1.3 with PQC key exchange.
• Tier 3 covers resources that aren’t PQ-ready. This includes endpoints without TLS 1.3 support, endpoints with TLS 1.3 but without PQC key exchange policies. These resources require immediate attention.

The scanner evaluates the following AWS edge services that terminate TLS connections on behalf of your applications.

• Edge services:
  • Application Load Balancer (ALB), Network Load Balancer (NLB) listeners with HTTPS, TLS, and TCP SSL protocols are evaluated.
  • API Gateway REST APIs are evaluated for AWS Regional and private endpoints along with API Gateway HTTP APIs (v2) and WebSocket APIs (v2).
• Excluded edge services:
  • CloudFront distributions are excluded from the PQC readiness scope because TLS 1.3 with hybrid post-quantum key exchange is automatically enabled across existing CloudFront TLS security policies for viewer-to-edge connections. No customer action is required for inbound (viewer-facing) PQC on CloudFront.
• Recommended approach for Classic load balancer:
  • For Classic Load Balancers, AWS recommends migrating to ALB or NLB. Classic Load Balancers don’t support TLS 1.3 or PQC key exchange and can’t be made PQ-ready.

AWS Config enables continuous monitoring and evaluation. Conformance packs enable organization-wide deployment. AWS Lambda is a serverless compute service that runs code to perform security policy evaluation based on the AWS Config rules. AWS Serverless Application Model (AWS SAM) is an open source framework used for deploying the AWS Lambda functions.

Figure 1: PQC readiness solution architecture

The PQC Readiness Scanner conformance pack implements four custom AWS Config rules powered by two Lambda functions:

Before deploying the solution, you need:

• AWS Command Line Interface (AWS CLI) configured with appropriate permissions

  aws configure
  aws sts get-caller-identity  # Verify

• Python 3.12 installed. The Lambda runtime requires this version.

  python3 --version  # Should show 3.12.x

• AWS SAM CLI installed (Installation Guide)

  pip install aws-sam-cli
  
  # Verify
  sam --version

• AWS Config enabled in your target AWS Region.
  • Configure it to record (This step is not needed if your accounts are recording all resources by default)
    • AWS::ElasticLoadBalancingV2::LoadBalancer
    • AWS::ApiGateway::RestApi
    • AWS::ApiGatewayV2::Api resource types.
  • Enable via AWS Config Console → Recorder → Recording Strategy → Select specific resource types (Follow the steps in manual setup for AWS Config recording strategy for specific resource types)

Deploy the PQC Readiness Config Scanner in three phases. Complete deployment commands and configuration details are available in the GitHub repository. The Lambda functions must be deployed first because the conformance pack references their ARNs as parameters. See the GitHub repository for details.

1. Clone and Build:

   git clone https://github.com/aws-samples/sample-PQC-Readiness-using-AWS-Config.git
   
   cd sample-PQC-Readiness-using-AWS-Config/installation
   
   sam build

2. Deploy to One or More Regions:

   # Make script executable (first time only)
   chmod +x deploy-per-regions.sh
   
   # Deploy to a single region
   ./deploy-per-regions.sh us-east-1
   
   # Deploy to multiple regions
   ./deploy-per-regions.sh us-east-1 us-west-2 eu-west-1

   

   Figure 2: Type y and continue if you have enabled AWS Config recording for these resources or its by default recording all resources.

3. The script automatically:
   • Deploys Lambda functions via SAM
   • Deploys conformance pack (creates Config rules)
   • Verifies deployment success
   • Provides clear status messages

The deployment creates two Lambda functions that perform PQ-ready and legacy TLS checks. It provisions IAM roles with least-privilege permissions for ELB, ALB, NLB, and API Gateway describe operations. Lambda permissions allow AWS Config to invoke the functions.

Figure 3: Example screen-print of what a successful deployment looks like.

For organization-wide deployment across multiple AWS accounts, use CloudFormation StackSets to deploy Lambda functions to each account.

Important Constraint: AWS Config CUSTOM_LAMBDA rules require the Lambda function to exist in the same account as the Config rule. You cannot use a centralized Lambda in one account to evaluate resources in other accounts.

Prerequisite: Shared S3 Bucket

Before packaging, create an S3 bucket accessible by each target account in your organization. This bucket will host the Lambda deployment artifacts that CloudFormation StackSets pulls into each member account.

# Create the shared S3 bucket (run from management/central account)
aws s3 mb s3://<your-org-shared-bucket> --region us-east-1

Grant read access to the target accounts using one of the following options:

aws s3api put-bucket-policy \
  --bucket <your-org-shared-bucket> \
  --policy '{
    "Statement": [
      {
        "Sid": "BucketOwnerFullAccess",
        "Effect": "Allow",
        "Principal": {
          "AWS": "arn:aws:iam::<bucket-owner-account-id>:root"
        },
        "Action": "s3:*",
        "Resource": [
          "arn:aws:s3:::<your-org-shared-bucket>",
          "arn:aws:s3:::<your-org-shared-bucket>/*"
        ]
      },
      {
        "Sid": "CrossAccountReadAccess",
        "Effect": "Allow",
        "Principal": {
          "AWS": [
            "arn:aws:iam::<account-id-1>:root",
            "arn:aws:iam::<account-id-2>:root"
          ]
        },
        "Action": ["s3:GetObject", "s3:ListBucket"],
        "Resource": [
          "arn:aws:s3:::<your-org-shared-bucket>",
          "arn:aws:s3:::<your-org-shared-bucket>/*"
        ]
      }
    ]
  }'

Replace <account IDs> with the AWS account IDs where StackSets will deploy the Lambda functions.

Note: The bucket must be in the same region as the StackSet deployment regions. For multi-region deployments, create one bucket per region and run sam package separately for each.

Step 1: Build and Upload Lambda Packages to S3

Run the packaging script from the installation/ directory:

cd installation

# Make script executable (first time only)
chmod +x deploy-stacksets.sh

# Build, package, upload to S3, and generate resolved template
./deploy-stacksets.sh <your-org-shared-bucket>

This script automatically:

• Builds Lambda functions using SAM
• Creates ZIP packages
• Uploads ZIPs to the shared S3 bucket
• Generates packaged-template.yaml with S3 values baked in (no parameters needed at deploy time)

Figure 4: Sample script output of successful upload of the lambda packages to S3 bucket

Step 2: Deploy Lambda Functions via StackSets

Run the following from the management account (or delegated admin account):

# Create StackSet (--region sets the StackSet "home region" where it is managed)
aws cloudformation create-stack-set \
  --stack-set-name pqc-readiness-lambda-functions \
  --template-body file://packaged-template.yaml \
  --capabilities CAPABILITY_IAM \
  --permission-model SERVICE_MANAGED \
  --auto-deployment Enabled=true,RetainStacksOnAccountRemoval=false \
  --region us-east-1

# Deploy stack instances to member accounts
# --regions = target regions where Lambda functions are deployed in member accounts
# --region  = must match the StackSet home region above
aws cloudformation create-stack-instances \
  --stack-set-name pqc-readiness-lambda-functions \
  --deployment-targets OrganizationalUnitIds=ou-xxxx-xxxxxxxx \
  --regions us-east-1 \
  --region us-east-1

Important — StackSet home region vs deployment regions:

• --region (on each CLI command) = the StackSet home region where the StackSet resource lives. Subsequent operations (describe, update, delete) must specify this same region.
• --regions (on create-stack-instances) = the deployment target region(s) where stack instances are created in member accounts.
• These are independent values. Specify --region explicitly to avoid accidental deployment to your CLI’s default region.

Note: SERVICE_MANAGED StackSets must be created from the management or delegated admin account. The management account itself is excluded from stack instance deployments — use deploy-per-regions.sh separately if you need the scanner in the management account.

Step 3: Deploy Organization Conformance Pack

aws configservice put-organization-conformance-pack \
  --organization-conformance-pack-name pqc-legacy-tls-compliance \
  --template-body file://conformance-packs/pqc-legacy-tls-conformance-pack.yaml

This creates Config rules in each member account that reference their local Lambda functions.

The three-tier system provides PQC migration priorities:

High priority – Tier 3 (not PQ-ready):

• Target: Resources without PQC support. This includes endpoints not using PQ-ready security policies, endpoints that still allow TLS 1.0 or 1.1.
• Action: Upgrade to a PQ-ready policy containing PQ in its name, such as those ending with -PQ-2025-09 (see Elastic Load Balancing security policies documentation for the full list).
• Important: Before upgrading to a PQ-ready policy, audit your client TLS versions. PQ-ready policies require TLS 1.3 support; legacy clients that only support TLS 1.2 or earlier will fail to negotiate a connection. Start with a Tier 2 backward-compatible policy (which supports both TLS 1.2 and 1.3 with PQC), monitor connection logs for TLS negotiation failures, and only move to a Tier 1 TLS 1.3-only policy after confirming that your clients support TLS 1.3 with PQC key exchange.
• Risk: Endpoints don’t support post-quantum cryptography for data in transit. Legacy TLS protocols are vulnerable to current cryptographic attacks.

Low priority – Tier 2 (PQ-ready, backward compatible):

• Target: Resources using TLS 1.3 + PQ-ready policies that also support TLS 1.2 for backward compatibility.
• Action: Consider TLS 1.3-only policies when client compatibility analysis confirms connecting clients support TLS 1.3.
• Risk: Minimal. These resources already support PQ-TLS with TLS 1.3 connections. TLS 1.2 and earlier fallback maintains backward compatibility, which might indicate some clients aren’t negotiating in PQ-TLS. Remediation is to monitor logs, identify the volume of these connections and clients and plan migration for these clients to use TLS 1.3 with PQ-TLS.

No action – Tier 1 (PQ-ready, optimal):

• Target: Resources using TLS 1.3 only with PQC key exchange: These resources meet the target state. No migration needed.

In each member account, navigate to AWS Config Console in the deployed region.

Go to AWS Config → Conformance packs and look for:

OrgConformsPack-pqc-legacy-tls-compliance-

Note: Organization conformance packs are prefixed with OrgConformsPack- and have a random suffix appended (e.g., OrgConformsPack-pqc-legacy-tls-compliance-gyv22je0).

Figure 5: PQC Conformance Pack Compliance Score is the percentage of the number of compliant rule-resource

Click the conformance pack to see an overall compliance summary across all 4 rules.

Go to AWS Config → Rules and find 4 rules with prefix pqc-:

• pqc-elb-pqc-compliance-conformance-pack-
• pqc-elb-legacy-tls-conformance-pack-
• pqc-apigateway-pqc-compliance-conformance-pack-
• pqc-apigateway-legacy-tls-conformance-pack-

Click any rule to view:

• Compliant vs non-compliant resource counts
• Detailed annotations for each resource
• Resource ARNs and current security policy configurations

Figure 6: Visibility into Config rules status inside the conformance pack

Figure 7: Sample image of the config rule findings and annotation describing the migration guidance based on 3-tier classification.

After deploying the PQC Readiness Scanner, you gain visibility into TLS posture across AWS edge services, which reduces manual configuration reviews. The tier system provides specific upgrade recommendations so teams can understand next steps without cryptographic expertise. The scanner automatically detects configuration changes to help new deployments maintain readiness standards. Built-in AWS Config reporting supports audit requirements and demonstrates measurable progress toward PQC readiness.

Deploy the PQC Readiness Scanner and review your results with PQC Readiness Scanner. Start migration with high priority Tier 3 resources and monitor progress across your accounts using AWS Config aggregators.

• GitHub repository: PQC Readiness Config Scanner
• AWS Config documentation: Custom Rules with Lambda
• AWS SAM documentation: Serverless Application Model
• PQC migration planning: NIST Post-Quantum Cryptography Standards
• PQC migration planning: AWS post-quantum cryptography migration plan

If you have feedback about this post, submit comments in the Comments section below. If you have questions about this post, start a new thread on AWS Config re:Post or contact AWS Support.

With International Anti-Ransomware Day taking place on May 12, Kaspersky presents its annual report on the evolving global and regional ransomware cyberthreat landscape.

Ransomware remains one of the most persistent and adaptive cyberthreats. In 2026:

• New families continue to emerge, adopting post-quantum cryptography ciphers.
• As ransom payments drop, some groups implement encryptionless extortion attacks.
• In a constantly changing ecosystem of threat actors, initial access brokers maintain a relevant role in this market, showing increased focus on access to RDWeb as the preferred method of remote access.

Ransomware attacks decline but remain a major threat

According to Kaspersky Security Network, the share of organizations affected by ransomware decreased in 2025 across all regions compared to 2024.

Percentage of organizations affected by ransomware attacks by region, 2025 (download)

Despite the formal decrease, organizations across all sectors continue to face a high likelihood of attack, as ransomware operators refine their tactics and scale their operations with increasing efficiency. Kaspersky and VDC Research have found that in the manufacturing sector alone, ransomware attacks may have caused over $18 billion in losses in the first three quarters of the year.

The continued rise of EDR killers and defense evasion tooling

In 2026, ransomware operators increasingly prioritize neutralizing endpoint defenses before executing their payloads. Tools commonly referred to as “EDR killers” have become a standard component of attack playbooks. This reflects a continuing trend toward more deliberate and methodical intrusions.

Attackers attempt to terminate security processes and disable monitoring agents, often by exploiting trusted components such as signed drivers. This technique is called Bring Your Own Vulnerable Driver (BYOVD) and allows adversaries to blend into legitimate system activity while gradually degrading defensive visibility.

Thus, evasion is no longer an opportunistic step but a planned and repeatable phase of the attack lifecycle. As a result, organizations are increasingly challenged not just to detect ransomware but also to maintain control in environments where security controls themselves are actively targeted.

The appearance of new families adopting post-quantum cryptography

We predicted that quantum-resistant ransomware would appear in 2025. Looking back at the previous year, we see that advanced ransomware groups indeed started using post-quantum cryptography as quantum computing evolved. The encryption techniques used by this quantum-proof ransomware could be used to resist decryption attempts from both classical and quantum computers, making it nearly impossible for victims to decrypt their data without having to pay a ransom.

One example is the appearance of the PE32 ransomware family (link in Russian); it leverages the cutting-edge ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism) standard to secure its AES keys. This specific cryptographic framework was recently selected by NIST as the primary standard for post-quantum defense.

Within the PE32 ransomware architecture, this is realized through the Kyber1024 algorithm, a robust mechanism providing Level 5 security, roughly equivalent in strength to AES-256. Its primary function is the secure generation and transmission of shared secrets between parties, specifically engineered to withstand future quantum computing attacks. This shift toward post-quantum readiness is part of a broader industry trend; for instance, TLS 1.3 and QUIC protocols have already adopted the X25519Kyber768 hybrid model, which fuses classical encryption with quantum-resistant security.

The shift to encryptionless extortion

In 2025, the share of ransoms paid dropped to 28%. As a response to this, one of the developments in the 2026 landscape is the growing prevalence of extortion incidents in which no file encryption takes place at all. Instead, attackers leave out the “ware” in “ransomware” and focus on extracting sensitive data and leveraging the threat of public disclosure as their primary means of extortion. ShinyHunters is an excellent example of such a group, using a data leak site to publicize its victims.

By avoiding encryption, attackers may aim at reducing the likelihood of immediate detection, shortening the duration of the attack, and eliminating dependencies on stable encryption routines. Often, this model is used alongside traditional tactics in so-called double extortion schemes, but an increasing number of campaigns rely exclusively on data theft.

For victims, this shift fundamentally changes the nature of the risk. While backups remain effective against encryption-based disruption, they provide no protection against data exposure, regulatory consequences, and reputational damage. Ransomware is therefore evolving from a business continuity issue into a broader data security and compliance challenge.

Industrialization of initial access (Access-as-a-Service)

The ransomware ecosystem continues to evolve toward a highly industrialized and specialized model, with initial access remaining as one of its most critical components. In 2026, many ransomware operators keep relying on IABs (initial access brokers), a network of intermediaries who supply pre-compromised access to corporate environments, aiming to no longer perform full intrusions themselves.

This “access-as-a-service” model is fueled by credential theft operations, and the widespread availability of compromised accounts harvested through infostealers and phishing campaigns.

The primary access vectors offered for sale have not changed: RDP, VPN, and RDWeb are still the top access vectors. Consequently, remote access infrastructure remains the primary attack surface for initial access sales. In response to the measures against public exposure of RDP access points to the internet, attackers are now targeting RDWeb portals, which are frequently vulnerable and occasionally inadequately safeguarded.

The result is a threat landscape where unauthorized access is increasingly commoditized, and the barrier to launching ransomware attacks declines. This means that preventing initial compromise is only part of the challenge; equal emphasis must be placed on detecting misuse of legitimate credentials and limiting lateral movement within already-breached environments.

Ransomware developments on the dark web

Telegram channels and underground forums increasingly function as platforms for the distribution and sale of compromised datasets and access credentials including those that were obtained as a result of ransomware attacks.

Advertisements posted on these resources typically include the nature of the access, a description of the exfiltrated or compromised data, price terms, and contact information for prospective buyers. In addition, some malicious actors mention their collaboration with other ransomware groups. Lesser-known gangs can use this name-dropping to promote themselves

Multiple threat actors not related to ransomware groups distribute datasets downloaded from ransomware blogs on underground forums and Telegram. By re-publishing download links and files, they spread compromised data as well as information on the ransomware attack within the community.

The ransomware itself is also sold or offered for subscription on the dark web platforms. The sellers underscore the uniqueness of their malware, as well as its encryption and defense evasion features.

Law enforcement actions

Law enforcement agencies are actively shutting down dark web platforms and ransomware data leak sites. A major underground forum, RAMP, which also functioned as a platform for threat actors to advertise their ransomware services and publish service‑related updates, was seized by authorities in January 2026. Another underground forum, LeakBase, where malicious actors distributed exfiltrated and compromised data, was seized in March 2026. In 2025, law enforcement agencies seized well-known forums like Nulled, Cracked, and XSS. Also in 2025, the DLSs of BlackSuit and 8Base ransomware groups were seized. These takedowns cause inconvenience to ransomware coordination, specifically for initial access brokers and affiliates, though similar forums are expected to fill the void over time.

Top ransomware groups in 2025

RansomHub’s sudden dormancy in 2025 marked a shift, and Qilin became the dominant player from Q2 onward. According to Kaspersky research, Qilin was the most active group executing targeted attacks in 2025.

Each group’s share of victims according to its data leak site (DLS) as a percentage of all reported victims of all groups during the period under review (download)

Qilin stands out as one of the fastest-growig and dominant RaaS platforms. Its combination of high-volume operations and structured affiliate model positions it as a central player in the current ecosystem.

Clop, the second most active group in 2025, is distinguished through its large-scale, supply-chain-style attacks, exploiting widely used file transfer and enterprise software to compromise hundreds of victims simultaneously. This one-to-many approach sets it apart from more traditional, single-target campaigns.

Third place is occupied by Akira, which remains notable for its consistency and operational stability, maintaining a steady stream of victims without major disruption. Its ability to sustain activity over time makes it one of the most reliable indicators of baseline ransomware threat levels.

Although no longer active, RansomHub stands out for its rapid rise and equally rapid disappearance in 2025, highlighting the volatility of the RaaS market. Its shutdown created a vacuum that significantly reshaped affiliate distribution across other groups.

DragonForce is also notable – not just for its own operations, but for its broader influence within the ransomware ecosystem, including reported involvement in infrastructure conflicts and possible links to the disruption of competing groups. Thus, the group claims that RansomHub “has moved to their infrastructure.” This positions it as more than just an operator and potentially an ecosystem-level actor.

New actors in 2026

While emerging actors generally operate on a smaller scale, they provide insight into the continuous churn and low barrier to entry within the ransomware ecosystem.

The Gentlemen group caught our attention in early 2026, as they managed to attack a significant number of victims over a short time. This actor is also notable for reflecting a broader shift toward professionalization and controlled operations within the ransomware ecosystem. Unlike many emerging groups that rely on opportunistic attacks and inconsistent leak activity, The Gentlemen demonstrate a more deliberate approach: structured intrusion workflows, selective targeting, and measured communication with victims. This signals a move away from chaotic, high-noise campaigns toward predictable, business-like execution models that are easier to scale and harder to disrupt. Their TTPs include the massive exploitation of hardware very common on big corporations, such as FortiOS/FortiProxy, SonicWall VPN, and Cisco ASA appliances. The group might be comprised of professional cybercriminals who left other prominent groups.

The group is also notable for its emphasis on data-centric extortion strategies, often prioritizing exfiltration and leverage over purely disruptive encryption. This aligns with one of the defining trends of 2026: ransomware evolving into a form of data breach monetization rather than just system denial. By focusing on controlled pressure and reputational risk instead of immediate operational damage, The Gentlemen exemplify how attackers are adapting to lower ransom payment rates and improved backup practices among victims.
Some other groups to take note of in 2026:

• Devman appears to be an emerging actor with limited but growing activity, likely leveraging existing tooling rather than developing custom capabilities.
• MintEye hasn’t been very active yet, with just five known victims, suggesting opportunistic campaigns without a consistent operational tempo.
• DireWolf is associated with small-scale, targeted attacks, though its overall footprint remains relatively limited compared to larger RaaS groups.
• NightSpire demonstrates characteristics of an amateur group, such as mistakes during its operations, uncommon communication channels with the victims, and sometimes giving them insufficient time to pay up. Although they both encrypt and leak data, they prioritize publication rather than encryption.
• Vect shows low-volume activity. It is yet unclear whether they use a completely new codebase or are rather a rebrand of an existing group.
• Tengu is a less prominent actor, with limited public reporting and no clear distinguishing tactics beyond standard extortion models.
• Kazu appears to be created by ransomware operators previously engaged with multiple other groups. As of now, they don’t stand out for scale or technique.

Although there is little to say about these groups at the time of writing this report, each of them may be equally likely to disappear from the threat landscape or grow into a prominent threat. That’s why it’s important to track them from their early days. Moreover, collectively, these groups illustrate how dynamic the ransomware landscape is, with new entrants constantly replenishing it.

Conclusion and protection recommendations

Despite the growing effort by law enforcement agencies across the globe to seize and disrupt dark web platforms and threat actor infrastructures, ransomware operations remain stable, with new groups quickly taking the place of those who went silent. In 2026, we see a shift towards encryptionless extortion, with data leaks increasingly becoming the main threat to target organizations. At the same time, data encryption is also upgrading to the next level with the emergence of post-quantum ransomware.

To resist the evolving threat, Kaspersky recommends organizations:

Prioritize proactive prevention through patching and vulnerability management. Many ransomware attacks exploit unpatched systems, so organizations should implement automated patch management tools to ensure timely updates for operating systems, software, and drivers. For Windows environments, enabling Microsoft’s Vulnerable Driver Blocklist is critical to thwarting BYOVD attacks. Regularly scan for vulnerabilities and prioritize high-severity flaws, especially in widely used software.

Strengthen remote access: RDP and RDWeb connections should never be directly exposed to the internet, only through VPN or ZTNA (Zero Trust Network Access). It’s highly recommended to adopt multi-factor authentication on everything; the architecture may require continuous authentication for access, as one valid credential captured is enough to cause a breach. Monitoring the underground for stolen employee credentials is essential. Audit open ports across the entire attack surface. The adoption of the “Principle of Least Privilege” (PoLP), where users, systems, or processes are granted only the minimum access rights, such as read, write, or execute permissions, necessary to perform their specific job functions, is highly recommended.

Strengthen endpoint and network security with advanced detection and segmentation. Deploy robust endpoint detection and response solutions such as Kaspersky NEXT EDR to monitor for suspicious activity like driver loading or process termination. Network segmentation is equally important. Limit lateral movement by isolating critical systems and using firewalls to restrict traffic. Complete and immediate offboarding for employees is necessary as well as periodic permission reviews, with automatic revocation of unused access. Sessions with complete logging for privileged accounts are more than necessary. Monitoring the traffic divergence to new sites or even to legitimate endpoints can help the defenders to spot a new insider threat.

Invest in backups, training, and incident response planning. Maintain offline or immutable backups that are tested regularly to ensure rapid recovery without paying a ransom. Backups should cover critical data and systems and be stored in air-gapped environments to resist encryption or deletion. User education is essential to combatting phishing, which remains one of the top attack vectors. Conduct simulated phishing exercises and train employees to recognize AI-crafted emails. Kaspersky Global Emergency Response Team (GERT) can help develop and test an incident response plan to minimize potential downtime and costs.

The recommendation to avoid paying a ransom remains robust, especially given the risk of unavailable keys due to dismantled infrastructure, affiliate chaos, or malicious intent. By investing in backups, incident response, and preventive measures like patching and training, organizations can avoid funding criminals and mitigate the impact.

Kaspersky also offers free decryptors for certain ransomware families. If you get hit by ransomware, check to see if there’s a decryptor available for the ransomware family used against you.

Malicious actors have developed a new way to steal data stored by Chrome for Windows. Researchers discovered the technique while analyzing a fresh build of an infostealer known as VoidStealer. The new method allows the malware to bypass Chrome’s Application-Bound (App-Bound) Encryption (ABE), a mechanism intended to protect session cookies and other valuable information stored in the browser.

Google hoped this mechanism would secure the master key Chrome uses to encrypt all sensitive data. Unfortunately, this isn’t the first time malware authors have found a workaround for this defense — leaving secrets stored in Chrome vulnerable once again.

How App-Bound Encryption works in Chrome

Google introduced App-Bound Encryption in July 2024 with the release of Chrome version 127. The company’s announcement mentioned infostealers snatching cookies from Chrome users on Windows as the primary problem ABE was intended to solve. We’ve already covered in detail what these files are and the consequences of their theft, so we’ll only briefly recap the main facts here.

Cookies are small files that the browser saves to the user’s device at a website’s request to remember various site settings. Of particular value to attackers are session cookies, which are used for automatic authentication on websites. It’s thanks to these files that we don’t have to enter a username and password every time we revisit a site.

But this convenience carries a risk: stealing these files allows an attacker to use an already-authenticated session without entering a username or password. This allows them to impersonate the user, which can lead to account hijacking, theft of personal or financial data, and other adverse consequences.

Infostealer Trojans are particularly dangerous for Chrome users on Windows. This is because, on this OS, Chrome previously relied solely on the standard built-in Data Protection API (DPAPI). With this system encryption mechanism, applications don’t need to create and store encryption keys to protect data.

The limitation of DPAPI is that it doesn’t protect data from malware that’s already successfully compromised the system and is capable of executing code on behalf of the logged-in user. This is exactly what stealers exploit: since they typically run with the user’s privileges, they can simply request DPAPI to decrypt the browser’s protected data.

The ABE mechanism was designed to solve that specific problem. The core idea is right in the name: App-Bound Encryption means the encryption is tied to a specific application. To achieve this, a separate service running with system privileges is responsible for protecting the key used to encrypt Chrome’s data. It verifies which application is requesting access to the key, and denies the request if it doesn’t originate from Chrome.

Chrome’s App-Bound Encryption (ABE) was designed so that only Chrome itself could retrieve the master key needed to decrypt the browser’s stored data. Source

As a result, the architects of this feature assumed that to access ABE-protected browser data, an infostealer would either need to escalate its privileges to system-level, or inject malicious code directly into Chrome. In theory, this should have made attacking Chrome significantly harder and reduced the effectiveness of mass-market infostealers. As you might have guessed, things didn’t go quite that smoothly in practice.

Previous successful bypasses of Chrome’s ABE

Just a couple of months after Google announced the implementation of App-Bound Encryption in Chrome, many infostealer developers claimed they’d already bypassed the protection. Among them were the creators of Meduza Stealer, Whitesnake, Lumma Stealer, and Lumar (also known as PovertyStealer).

Lumma stealer developers announce a bypass for Chrome’s App-Bound Encryption in a new version of the malware

Of course, you shouldn’t take malware developers at their word, but legitimate security researchers were able to confirm at least some of the claims. Bypasses for Google Chrome’s new data protection feature did become available almost immediately after its release.

A month later, in October 2024, tech enthusiast Alex Hagenah published a tool on GitHub called Chrome-App-Bound-Encryption-Decryption to bypass Google’s new security mechanism. Analysis of the tool’s code revealed that its author used roughly the same methods that attackers were already heavily exploiting.

What followed was a game of cat and mouse: security researchers and stealer developers came up with new tricks to circumvent App-Bound Encryption, while Google patched the newly discovered loopholes with varying degrees of success.

VoidStealer — a new data-nabbing menace

This brings us to recent events: in March 2026, news broke about a stealer named VoidStealer, which utilizes a brand-new and, by all accounts, highly effective method for bypassing ABE.

VoidStealer developers advertising a new method for bypassing ABE. Source

The malware authors developed an attack technique that targets the brief moment when the master key sits in the browser’s memory in plaintext. This occurs because, at a certain point, the browser inevitably has to decrypt its data to actually use it — for instance, to automatically sign in to a website with the relevant session cookie or to access saved credentials.

To exploit this window of opportunity, the malware attaches itself to the Chrome process as a debugger — a tool that allows one to control a program’s execution, pause it, and inspect its memory. In legitimate scenarios, these tools are used by developers to find and fix bugs, analyze application behavior, and test performance.

The malware identifies the specific section of code where data decryption takes place. It then sets a breakpoint at that location; when the program’s execution reaches that point, the browser effectively freezes. This is how the malware catches the exact moment the master key is sitting in RAM in plaintext; it then reads the key directly from memory.

It’s worth noting that everything mentioned above also applies to other Chromium-based browsers that use ABE, including Microsoft Edge, Brave, Opera, Vivaldi, and others.

How to avoid falling victim to infostealers

The scale of VoidStealer’s reach could be significant, as its developers operate under the malware-as-a-service (MaaS) model. This means they rent out the ready-made tool to other attackers, so they don’t need to develop custom malware from scratch.

This situation demonstrates that relying solely on built-in security mechanisms isn’t enough. Unfortunately, stealer developers are coming up with new workarounds faster than browser and operating system developers can roll out patches.

Here’s what users can do about it:

• Avoid installing programs from suspicious sources. This will minimize the chances of malware infiltrating your system.
• Learn how ClickFix attacks Lately, stealers have frequently been distributed using this specific malicious tactic.
• Keep your OS and software updated on all devices. Timely updates help patch many of the vulnerabilities that malware exploits.
• Install a robust security solution on all your devices. It’ll block suspicious activity in real time and alert you to potential threats.

As an added precaution, avoid storing passwords and bank card info in Google Chrome or your Notes app, as these are the first places any self-respecting stealer looks. Instead, use a secure password manager.

Stealers are hunting for your data, finding ways to infiltrate both computers and smartphones alike. To protect yourself from theft, check out our other related posts:

• Crypto thieves ramping up attacks on Apple users
• CrystalX RAT can flip your screen and steal your crypto
• Android Trojan posing as government services and Starlink apps
• Stealka stealer: the new face of game cheats, mods, and cracks
• Your cat pics are at risk: the threat posed by the new SparkKitty Trojan

aws cloudtrail lookup-events \
--lookup-attributes AttributeKey=EventName,AttributeValue=GetSecretValue \
--max-results 5 \
--region <YOUR-REGION> \
--query 'Events[0].CloudTrailEvent' \
--output text

{
    "eventVersion": "1.11",
    "userIdentity": {
        "type": "AssumedRole",
        "principalId": "AROA123456789EXAMPLE:i-0c1a23fc456b7ab89",
        "arn": "arn:aws:sts::111122223333:assumed-role/YOUR-EC2-INSTANCE-PROFILE/i-0c1a23fc456b7ab89",
        "accountId": "111122223333",
        "accessKeyId": "ASIAIOSFODNN7EXAMPLE",
        "sessionContext": {
            "sessionIssuer": {
                "type": "Role",
                "principalId": "AROA123456789EXAMPLE",
                "arn": "arn:aws:iam::111122223333:role/YOUR-EC2-INSTANCE-PROFILE",
                "accountId": "111122223333",
                "userName": "YOUR-EC2-INSTANCE-PROFILE"
            },
            "attributes": {
                "creationDate": "2026-03-27T17:08:37Z",
                "mfaAuthenticated": "false"
            },
            "ec2RoleDelivery": "2.0"
        },
        "inScopeOf": {
            "issuerType": "AWS::EC2::Instance",
            "credentialsIssuedTo": "arn:aws:ec2:eu-west-2:111122223333:instance/i-0c1a23fc456b7ab89"
        }
    },
    "eventTime": "2026-03-27T17:12:54Z",
    "eventSource": "secretsmanager.amazonaws.com",
    "eventName": "GetSecretValue",
    "awsRegion": "eu-west-2",
    "sourceIPAddress": "1.2.3.4",
    "userAgent": "aws-sdk-rust/1.3.14 os/linux lang/rust/1.94.1 aws-secrets-manager-agent/2.0.0",
    "requestParameters": {
        "secretId": "arn:aws:secretsmanager:eu-west-2:111122223333:secret:your-secret"
    },
    "responseElements": null,
    "requestID": "027507ea-f377-43d9-bf2f-646d4dc19223",
    "eventID": "f9c3ed0f-81f5-450b-a561-2b9e54fa9e73",
    "readOnly": true,
    "resources": [
        {
            "accountId": "111122223333",
            "type": "AWS::SecretsManager::Secret",
            "ARN": "arn:aws:secretsmanager:eu-west-2:111122223333:secret:your-secret"
        }
    ],
    "eventType": "AwsApiCall",
    "managementEvent": true,
    "recipientAccountId": "111122223333",
    "eventCategory": "Management",
    "tlsDetails": {
        "tlsVersion": "TLSv1.3",
        "cipherSuite": "TLS_AES_128_GCM_SHA256",
        "clientProvidedHostHeader": "secretsmanager.eu-west-2.amazonaws.com",
        "keyExchange": "X25519MLKEM768"
    }
}

If you have feedback about this post, submit comments in the Comments section below.

Unit 42 research reveals AirSnitch attacks bypass WPA2/3 Wi-Fi encryption and client isolation, exposing critical infrastructure vulnerabilities.

The post When Wi-Fi Encryption Fails: Protecting Your Enterprise from AirSnitch Attacks appeared first on Unit 42.

Background

JanelaRAT is a malware family that takes its name from the Portuguese word “janela” which means “window”. JanelaRAT looks for financial and cryptocurrency data from specific banks and financial institutions in the Latin America region.

JanelaRAT is a modified variant of BX RAT that has targeted users since June 2023. One of the key differences between these Trojans is that JanelaRAT uses a custom title bar detection mechanism to identify desired websites in victims’ browsers and perform malicious actions.

The threat actors behind JanelaRAT campaigns continuously update the infection chain and malware versions by adding new features.

Kaspersky solutions detect this threat as Trojan.Script.Generic and Backdoor.MSIL.Agent.gen.

Initial infection

JanelaRAT campaigns involve a multi-stage infection chain. It starts with emails mimicking the delivery of pending invoices to trick victims into downloading a PDF file by clicking a malicious link. Then the victims are redirected to a malicious website from which a compressed file is downloaded.

Malicious email used in JanelaRAT campaigns

Throughout our monitoring of these malware campaigns, the compressed files have typically contained VBScripts, XML files, other ZIP archives, and BAT files. They ultimately lead to downloading a ZIP archive that contains components for DLL sideloading and executing JanelaRAT as the final payload.

However, we have observed variations in the infection chains depending on the delivered version of the malware. The latest observed campaign evolved by integrating MSI files to deliver a legitimate PE32 executable and a DLL, which is then sideloaded by the executable. This DLL is actually JanelaRAT, delivered as the final payload.

Based on our analysis of previous JanelaRAT intrusions, the updates in the infection chain represent threat actors’ attempts to streamline the process, with a reduced number of malware installation steps. We’ve observed a logical sequence in how components, such as MSI files, have been incorporated and adapted over time. Moreover, we have observed the use of auxiliary files — additional components that aid in the infection — such as configuration files that have been changing over time, showing how the threat actors have adapted these infections in an effort to avoid detection.

JanelaRAT infection flow evolution

Initial dropper

The MSI file acts as an initial dropper designed to install the final implant and establish persistence on the system. It obfuscates file paths and names with the objective to hinder analysis. This code is designed to create several ActiveX objects to manipulate the file system and execute malicious commands.

Among the actions taken, the MSI defines paths based on environment variables for hosting binaries, creating a startup shortcut, and storing a first-run indicator file. The dropper file checks for the existence of the latter and for a specific path, and if either is missing, it creates them. If the file exists, the MSI file redirects the user to an external website as a decoy, showing that everything is “normal”.

The MSI dropper places two files at a specified path: the legitimate executable nevasca.exe and the PixelPaint.dll library, renaming them with obfuscated combinations of random strings before relocating. An LNK shortcut is created in the user’s Startup folder, pointing to the renamed nevasca.exe executable, ensuring persistence. Finally, the nevasca.exe file is executed, which in turn loads the PixelPaint.dll file that is JanelaRAT.

Malicious implant

In this case, we analyzed JanelaRAT version 33, which was masqueraded as a legitimate pixel art app. Similar to other malware versions, it was protected with Eazfuscator, a common .NET obfuscation tool. We have also seen previous JanelaRAT samples that used the ConfuserEx obfuscator or its custom builds. The malware uses Control Flow Flattening method and renames classes and variables to make the code unreadable without deobfuscation.

JanelaRAT monitors the victim’s activity, intercepts sensitive banking interactions, and establishes an interactive C2 channel to report changes to the threat actor. While screen monitoring is also present, the core functionality focuses on financial fraud and real-time manipulation of the victim’s machine. The malware collects system information, including OS version, processor architecture (32-bit, 64-bit, or unknown), username, and machine name. The Trojan evaluates the current user’s privilege level and assigns different nicknames for administrators, users, guests, and an additional one for any other role.

The malware then retrieves the current date and constructs a beacon to register the victim on the C2 server, along with the malware version. To prevent multiple instances, the malware creates the mutex and exits if it already exists.

String encryption

All JanelaRAT samples utilize encrypted strings for sending information to the C2 and obfuscating embedded data. The encryption algorithm remains consistent across campaigns, combining base64 encoding with Rijndael (AES). The encryption key is derived from the MD5 hash of a 4-digit number and the IV is composed of the first 16 bytes of the decoded base64 data.

C2 communication and command handling

After initialization, JanelaRAT establishes a TCP socket, configuring callbacks for connection events and message handling. It registers all known message types, executing specific system tasks based on the received message.

Following socket initialization, the malware launches two background routines:

1. User inactivity and session tracking
   This routine activates timers and launches secondary threads, including an internal timer and a user inactivity monitor. The malware determines if the victim’s machine has been inactive for more than 10 minutes by calculating the elapsed time since the last user input. If the inactivity period exceeds 10 minutes, the malware notifies the C2 by sending the corresponding message. Upon user activity, it notifies the threat actor again. This makes it possible to track the user’s presence and routine to time possible remote operations.
   

   Timer that looks for 10 minutes of inactivity

2. Victim registration and further malicious activity
   This routine is launched immediately after the socket setup. It triggers two subroutines responsible for periodic HTTP beaconing and downloading additional payloads.
   1. The first subroutine executes a PowerShell downloaded from a staging server during post-exploitation. Its main objective is to establish persistence by downloading the PixelPaint.dll file once again. The routine then builds and executes periodic HTTP requests to the C2, reporting the malware’s version and the victim machine’s security environment. It loops continuously as long as a specific local file does not exist, ensuring repeated telemetry transmission. The file was not observed being extracted or created by the malware itself; rather, it appears to be placed on the system by the threat actor during other post-exploitation activities. Based on previous incidents, this file likely contains instructions for establishing persistence.

      This JanelaRAT version constructs a second C2 URL for beaconing, using several decrypted strings and following a pattern that uses different parameters to report information about new victims:

      <C2Domain>?VS=<malwareversion>&PL=<profilelevel>&AN=<presenceofbankingsoftware>

      We have observed constant changes in the parameters across campaigns. A new parameter “AN” was introduced in this version. It is used to detect the presence of a specific process associated with banking security software. If such software is found on the victim’s device, the malware notifies the threat actor.

      Parameter	Description
      VS	JanelaRAT version
      PL	OFF by default
      AN	Yes or No depending on whether banking security software process exists

   2. The second subroutine is responsible for monitoring the user’s visits to banking websites and reporting any activity of interest to the threat actor. JanelaRAT 33v is specifically engineered to target Brazilian financial institutions. However, we have also observed other versions of the malware targeting other specific countries in the region, such as the “Gold-Label” version targeting banking users in Mexico that we described earlier.

      This subroutine creates a timer to enable an active system monitoring cycle. During this cycle, the malware obtains the title of the active window and checks if it matches entries of interest using a hardcoded but obfuscated list of financial institutions. Although the threat actors behind JanelaRAT primarily focus on one country as a target, the list of financial institutions is constantly updated.

      If a title bar matches one of the listed targets, the malware waits 12 seconds before establishing a dedicated communication channel to the C2. This channel is used to execute malicious tasks, including taking screenshots, monitoring keyboard and mouse input, displaying messages to the user, injecting keystrokes or simulating mouse input, and forcing system shutdown.

      To perform these actions, the malware uses a dedicated C2 handler that interprets incoming commands from the C2. Notably, 33v supports live banking session hijacking, not just credential theft.

      Action Performed	Description
      Capture desktop image	Send compressed screenshots to the C2
      Specific screenshots	Crop specific screen regions and exfiltrate images
      Overlay windows	Display images in full-screen mode, limit user interactions, and mimic bank dialogs to harvest credentials
      Keylogging	Keystroke capture
      Simulate keyboard	Inject keys such as DOWN, UP, and TAB to navigate or trigger new elements
      Track mouse input	Move the cursor, simulate clicks, and report the cursor position
      Display message	Show message boxes (custom title, text, buttons, or icons)
      System shutdown	Execute a forced shutdown sequence
      Command execution	Run CMD or PowerShell scripts/commands
      Task Manager manipulation	Launch Task Manager, find its window, and hide it to prevent discovery by the user
      Check for banking security software process	Detect the presence of anti-fraud systems
      Beaconing	Send host information (malware version, profile, presence of banking software)
      Toggle internal modes	Enable and disable modes such as screenshot flow, key injection, or overlay visibility
      Anti-analysis	Detect sandbox or automation tools

C2 infrastructure

Unlike other versions, this variant rotates its C2 server daily. Once a title bar matches the one in the list, the software dynamically constructs the C2 channel domain by concatenating an obfuscated string, the current date, and a suffix domain related to a legitimate dynamic DNS (DDNS) service. This communication is established using port 443, but not TLS.

Decoy overlay system

This version of JanelaRAT implements a decoy overlay system designed to capture banking credentials and bypass multi-factor authentication. When a target banking window is detected, the malware requests further instructions from the C2 server. The C2 responds with a command identifier and a Base64-encoded image, which is then displayed as a full-screen overlay window mimicking legitimate banking or system interfaces. The malware ensures the fake window completely covers the screen and limits the victim’s interaction with the system.

The malware blocks the victim’s interaction by displaying modal dialogs. Each modal dialog corresponds to a specific operation, such as password capture, token/MFA capture, fake loading screen, fake Windows update full-screen modal and more. The malware resizes the overlay, scans multiple screens, and loads deceptive elements to distract the user or temporarily hide legitimate application windows.

Among other fake elements, the malware displays fake Windows update notifications, often accompanied by messages in Brazilian Portuguese, such as:

• “Configuring Windows updates, please wait.”
• “Do not turn off your computer; this could take some time.”

When a message command is received from the operator, the malware constructs a custom message box based on parameters sent from the server. These parameters include the message title, text content, button type (e.g., OK, Yes/No), and icon type (e.g., Warning, Error). The malware then creates a maximized message box positioned at the top of the screen, ensuring it captures user focus and blocks the visibility of other windows, mimicking a system or security alert.

An obfuscated acknowledgement string is sent back to the C2 to confirm successful execution of this task.

Anti-analysis techniques

In addition to the conditional behavior based on whether the process of banking security software is detected, the malware includes anti-analysis routines and computer environment checks, such as sandbox detection through the Magnifier and MagnifierWindow components. These components are used to determine if accessibility tools are active on the infected computer indicating a possible malware analysis environment.

Persistence

The malware establishes persistence by writing a command script into the Windows Startup directory. This script forces the execution chain to run at each user logon enabling malicious activity without triggering privilege escalation prompts. The script is executed silently to evade user awareness.

This method is either an alternative or a supplement to the persistence method previously described in the subroutines responsible for periodic HTTP beaconing section.

Victimology

Consistent with previous intrusions and campaigns, the primary targets of the threat actors distributing JanelaRAT are banking users in Latin America, with specific focus on users of financial institutions in Brazil and Mexico.

According to our telemetry, in 2025 we detected 14,739 attacks in Brazil and 11,695 in Mexico related to JanelaRAT.

Conclusions

JanelaRAT remains an active and evolving threat, with intrusions exhibiting consistent characteristics despite ongoing modifications. We have tracked the evolution of JanelaRAT infections for some time, observing variations in both the malware itself and its infection chain, including targeted variants for specific countries.

This variant represents a significant advancement in the actor’s capabilities, combining multiple communication channels, comprehensive victim monitoring, interactive overlays, input injection, and robust remote control features. The malware is specifically designed to minimize user visibility and adapt its behavior upon detection of anti-fraud software.

To mitigate the risk of communication with the C2 infrastructure utilizing similar evasive techniques, we recommend that defenders block dynamic DNS services at the corporate perimeter or internal DNS resolvers. This will disrupt the communication channels used by JanelaRAT and similar threats.

Indicators of compromise

808c87015194c51d74356854dfb10d9e         MSI Dropper
d7a68749635604d6d7297e4fa2530eb6        JanelaRAT
ciderurginsx[.]com         Primary C2

Background

JanelaRAT is a malware family that takes its name from the Portuguese word “janela” which means “window”. JanelaRAT looks for financial and cryptocurrency data from specific banks and financial institutions in the Latin America region.

JanelaRAT is a modified variant of BX RAT that has targeted users since June 2023. One of the key differences between these Trojans is that JanelaRAT uses a custom title bar detection mechanism to identify desired websites in victims’ browsers and perform malicious actions.

The threat actors behind JanelaRAT campaigns continuously update the infection chain and malware versions by adding new features.

Kaspersky solutions detect this threat as Trojan.Script.Generic and Backdoor.MSIL.Agent.gen.

Initial infection

JanelaRAT campaigns involve a multi-stage infection chain. It starts with emails mimicking the delivery of pending invoices to trick victims into downloading a PDF file by clicking a malicious link. Then the victims are redirected to a malicious website from which a compressed file is downloaded.

Malicious email used in JanelaRAT campaigns

Throughout our monitoring of these malware campaigns, the compressed files have typically contained VBScripts, XML files, other ZIP archives, and BAT files. They ultimately lead to downloading a ZIP archive that contains components for DLL sideloading and executing JanelaRAT as the final payload.

However, we have observed variations in the infection chains depending on the delivered version of the malware. The latest observed campaign evolved by integrating MSI files to deliver a legitimate PE32 executable and a DLL, which is then sideloaded by the executable. This DLL is actually JanelaRAT, delivered as the final payload.

Based on our analysis of previous JanelaRAT intrusions, the updates in the infection chain represent threat actors’ attempts to streamline the process, with a reduced number of malware installation steps. We’ve observed a logical sequence in how components, such as MSI files, have been incorporated and adapted over time. Moreover, we have observed the use of auxiliary files — additional components that aid in the infection — such as configuration files that have been changing over time, showing how the threat actors have adapted these infections in an effort to avoid detection.

JanelaRAT infection flow evolution

Initial dropper

The MSI file acts as an initial dropper designed to install the final implant and establish persistence on the system. It obfuscates file paths and names with the objective to hinder analysis. This code is designed to create several ActiveX objects to manipulate the file system and execute malicious commands.

Among the actions taken, the MSI defines paths based on environment variables for hosting binaries, creating a startup shortcut, and storing a first-run indicator file. The dropper file checks for the existence of the latter and for a specific path, and if either is missing, it creates them. If the file exists, the MSI file redirects the user to an external website as a decoy, showing that everything is “normal”.

The MSI dropper places two files at a specified path: the legitimate executable nevasca.exe and the PixelPaint.dll library, renaming them with obfuscated combinations of random strings before relocating. An LNK shortcut is created in the user’s Startup folder, pointing to the renamed nevasca.exe executable, ensuring persistence. Finally, the nevasca.exe file is executed, which in turn loads the PixelPaint.dll file that is JanelaRAT.

Malicious implant

In this case, we analyzed JanelaRAT version 33, which was masqueraded as a legitimate pixel art app. Similar to other malware versions, it was protected with Eazfuscator, a common .NET obfuscation tool. We have also seen previous JanelaRAT samples that used the ConfuserEx obfuscator or its custom builds. The malware uses Control Flow Flattening method and renames classes and variables to make the code unreadable without deobfuscation.

JanelaRAT monitors the victim’s activity, intercepts sensitive banking interactions, and establishes an interactive C2 channel to report changes to the threat actor. While screen monitoring is also present, the core functionality focuses on financial fraud and real-time manipulation of the victim’s machine. The malware collects system information, including OS version, processor architecture (32-bit, 64-bit, or unknown), username, and machine name. The Trojan evaluates the current user’s privilege level and assigns different nicknames for administrators, users, guests, and an additional one for any other role.

The malware then retrieves the current date and constructs a beacon to register the victim on the C2 server, along with the malware version. To prevent multiple instances, the malware creates the mutex and exits if it already exists.

String encryption

All JanelaRAT samples utilize encrypted strings for sending information to the C2 and obfuscating embedded data. The encryption algorithm remains consistent across campaigns, combining base64 encoding with Rijndael (AES). The encryption key is derived from the MD5 hash of a 4-digit number and the IV is composed of the first 16 bytes of the decoded base64 data.

C2 communication and command handling

After initialization, JanelaRAT establishes a TCP socket, configuring callbacks for connection events and message handling. It registers all known message types, executing specific system tasks based on the received message.

Following socket initialization, the malware launches two background routines:

1. User inactivity and session tracking
   This routine activates timers and launches secondary threads, including an internal timer and a user inactivity monitor. The malware determines if the victim’s machine has been inactive for more than 10 minutes by calculating the elapsed time since the last user input. If the inactivity period exceeds 10 minutes, the malware notifies the C2 by sending the corresponding message. Upon user activity, it notifies the threat actor again. This makes it possible to track the user’s presence and routine to time possible remote operations.
   

   Timer that looks for 10 minutes of inactivity

2. Victim registration and further malicious activity
   This routine is launched immediately after the socket setup. It triggers two subroutines responsible for periodic HTTP beaconing and downloading additional payloads.
   1. The first subroutine executes a PowerShell downloaded from a staging server during post-exploitation. Its main objective is to establish persistence by downloading the PixelPaint.dll file once again. The routine then builds and executes periodic HTTP requests to the C2, reporting the malware’s version and the victim machine’s security environment. It loops continuously as long as a specific local file does not exist, ensuring repeated telemetry transmission. The file was not observed being extracted or created by the malware itself; rather, it appears to be placed on the system by the threat actor during other post-exploitation activities. Based on previous incidents, this file likely contains instructions for establishing persistence.

      This JanelaRAT version constructs a second C2 URL for beaconing, using several decrypted strings and following a pattern that uses different parameters to report information about new victims:

      <C2Domain>?VS=<malwareversion>&PL=<profilelevel>&AN=<presenceofbankingsoftware>

      We have observed constant changes in the parameters across campaigns. A new parameter “AN” was introduced in this version. It is used to detect the presence of a specific process associated with banking security software. If such software is found on the victim’s device, the malware notifies the threat actor.

      Parameter	Description
      VS	JanelaRAT version
      PL	OFF by default
      AN	Yes or No depending on whether banking security software process exists

   2. The second subroutine is responsible for monitoring the user’s visits to banking websites and reporting any activity of interest to the threat actor. JanelaRAT 33v is specifically engineered to target Brazilian financial institutions. However, we have also observed other versions of the malware targeting other specific countries in the region, such as the “Gold-Label” version targeting banking users in Mexico that we described earlier.

      This subroutine creates a timer to enable an active system monitoring cycle. During this cycle, the malware obtains the title of the active window and checks if it matches entries of interest using a hardcoded but obfuscated list of financial institutions. Although the threat actors behind JanelaRAT primarily focus on one country as a target, the list of financial institutions is constantly updated.

      If a title bar matches one of the listed targets, the malware waits 12 seconds before establishing a dedicated communication channel to the C2. This channel is used to execute malicious tasks, including taking screenshots, monitoring keyboard and mouse input, displaying messages to the user, injecting keystrokes or simulating mouse input, and forcing system shutdown.

      To perform these actions, the malware uses a dedicated C2 handler that interprets incoming commands from the C2. Notably, 33v supports live banking session hijacking, not just credential theft.

      Action Performed	Description
      Capture desktop image	Send compressed screenshots to the C2
      Specific screenshots	Crop specific screen regions and exfiltrate images
      Overlay windows	Display images in full-screen mode, limit user interactions, and mimic bank dialogs to harvest credentials
      Keylogging	Keystroke capture
      Simulate keyboard	Inject keys such as DOWN, UP, and TAB to navigate or trigger new elements
      Track mouse input	Move the cursor, simulate clicks, and report the cursor position
      Display message	Show message boxes (custom title, text, buttons, or icons)
      System shutdown	Execute a forced shutdown sequence
      Command execution	Run CMD or PowerShell scripts/commands
      Task Manager manipulation	Launch Task Manager, find its window, and hide it to prevent discovery by the user
      Check for banking security software process	Detect the presence of anti-fraud systems
      Beaconing	Send host information (malware version, profile, presence of banking software)
      Toggle internal modes	Enable and disable modes such as screenshot flow, key injection, or overlay visibility
      Anti-analysis	Detect sandbox or automation tools

C2 infrastructure

Unlike other versions, this variant rotates its C2 server daily. Once a title bar matches the one in the list, the software dynamically constructs the C2 channel domain by concatenating an obfuscated string, the current date, and a suffix domain related to a legitimate dynamic DNS (DDNS) service. This communication is established using port 443, but not TLS.

Decoy overlay system

This version of JanelaRAT implements a decoy overlay system designed to capture banking credentials and bypass multi-factor authentication. When a target banking window is detected, the malware requests further instructions from the C2 server. The C2 responds with a command identifier and a Base64-encoded image, which is then displayed as a full-screen overlay window mimicking legitimate banking or system interfaces. The malware ensures the fake window completely covers the screen and limits the victim’s interaction with the system.

The malware blocks the victim’s interaction by displaying modal dialogs. Each modal dialog corresponds to a specific operation, such as password capture, token/MFA capture, fake loading screen, fake Windows update full-screen modal and more. The malware resizes the overlay, scans multiple screens, and loads deceptive elements to distract the user or temporarily hide legitimate application windows.

Among other fake elements, the malware displays fake Windows update notifications, often accompanied by messages in Brazilian Portuguese, such as:

• “Configuring Windows updates, please wait.”
• “Do not turn off your computer; this could take some time.”

When a message command is received from the operator, the malware constructs a custom message box based on parameters sent from the server. These parameters include the message title, text content, button type (e.g., OK, Yes/No), and icon type (e.g., Warning, Error). The malware then creates a maximized message box positioned at the top of the screen, ensuring it captures user focus and blocks the visibility of other windows, mimicking a system or security alert.

An obfuscated acknowledgement string is sent back to the C2 to confirm successful execution of this task.

Anti-analysis techniques

In addition to the conditional behavior based on whether the process of banking security software is detected, the malware includes anti-analysis routines and computer environment checks, such as sandbox detection through the Magnifier and MagnifierWindow components. These components are used to determine if accessibility tools are active on the infected computer indicating a possible malware analysis environment.

Persistence

The malware establishes persistence by writing a command script into the Windows Startup directory. This script forces the execution chain to run at each user logon enabling malicious activity without triggering privilege escalation prompts. The script is executed silently to evade user awareness.

This method is either an alternative or a supplement to the persistence method previously described in the subroutines responsible for periodic HTTP beaconing section.

Victimology

Consistent with previous intrusions and campaigns, the primary targets of the threat actors distributing JanelaRAT are banking users in Latin America, with specific focus on users of financial institutions in Brazil and Mexico.

According to our telemetry, in 2025 we detected 14,739 attacks in Brazil and 11,695 in Mexico related to JanelaRAT.

Conclusions

JanelaRAT remains an active and evolving threat, with intrusions exhibiting consistent characteristics despite ongoing modifications. We have tracked the evolution of JanelaRAT infections for some time, observing variations in both the malware itself and its infection chain, including targeted variants for specific countries.

This variant represents a significant advancement in the actor’s capabilities, combining multiple communication channels, comprehensive victim monitoring, interactive overlays, input injection, and robust remote control features. The malware is specifically designed to minimize user visibility and adapt its behavior upon detection of anti-fraud software.

To mitigate the risk of communication with the C2 infrastructure utilizing similar evasive techniques, we recommend that defenders block dynamic DNS services at the corporate perimeter or internal DNS resolvers. This will disrupt the communication channels used by JanelaRAT and similar threats.

Indicators of compromise

808c87015194c51d74356854dfb10d9e         MSI Dropper
d7a68749635604d6d7297e4fa2530eb6        JanelaRAT
ciderurginsx[.]com         Primary C2

At the NDSS Symposium 2026 in San Diego in February, a group of respected researchers presented a study unveiling the AirSnitch attack, which bypasses the Wi-Fi client isolation feature — also commonly known as guest network or device isolation. This attack allows connecting to a single wireless network via an access point, and then gaining access to other connected devices, including those using entirely different service set identifiers (SSIDs) on that same hardware. Targeted devices could easily be running on wireless subnets protected by WPA2 or WPA3 protocols. The attack doesn’t actually break encryption; instead, it exploits the way access points handle group keys and packet routing.

In practical terms, this means that a guest network provides very little in the way of real security. If your guest and employee networks are running on the same physical device, AirSnitch allows a connected attacker to inject malicious traffic into neighboring SSIDs. In some cases, they can even pull off a full-blown man-in-the-middle (MitM) attack.

Wi-Fi security and the role of isolation

Wi-Fi security is constantly evolving; every time a practical attack is made against the latest generation of protection, the industry shifts toward more complex algorithms and procedures. This cycle started with the FMS attacks used to crack WEP encryption keys, and continues to this day: recent examples include the KRACK attacks on WPA2, and the FragAttacks, which impacted every security protocol version from WEP all the way through WPA3.

Attacking modern Wi-Fi networks effectively (and quietly) is no small feat. Most professionals agree that using WPA2/WPA3 with complex keys and separating networks based on their purpose is usually enough for protection. However, only specialists really know that client isolation was never actually standardized within the IEEE 802.11 protocols. Different manufacturers implement isolation in completely different ways — using Layer 2 or Layer 3 of network architecture; in other words, handling it at either the router or the Wi-Fi controller level — meaning the behavior of isolated subnets varies wildly depending on your specific access point or router model.

While marketing claims that client isolation is perfect for keeping restaurant or hotel guests from attacking one another — or ensuring corporate visitors can’t access anything but the internet — in reality, isolation often relies on people not trying to hack it. This is exactly what the AirSnitch research highlights.

Types of AirSnitch attacks

The name AirSnitch doesn’t just refer to a single vulnerability, but a whole family of architectural flaws found in Wi-Fi access points. It’s also the name of an open-source tool used to test routers for these specific weaknesses. However, security professionals need to keep in mind that there’s only a very thin line between testing and attacking.

The model for all these attacks is the same: a malicious client is connected to an access point (AP) where isolation is active. Other users — the targets — are connected to the same SSID or even different SSIDs on that same AP. This is a very realistic scenario; for example, a guest network might be open and unencrypted, or an attacker could simply get the guest Wi-Fi password by posing as a legitimate visitor.

For certain AirSnitch attacks, the attacker needs to know the victim’s MAC or IP address beforehand.  Ultimately, how effective each attack is depends on the specific hardware manufacturer (more on that below).

GTK attack

After the WPA2/WPA3 handshake, the access point and the clients agree on a Group Transient Key (GTK) to handle broadcast traffic. In this scenario, the attacker wraps packets destined for a specific victim inside a broadcast traffic envelope. They then send these directly to the victim while spoofing the access point’s MAC address. This attack only allows for traffic injection, meaning the attacker won’t receive a response. However, even that is enough to deliver malicious ICMPv6 routing advertisements, or DNS and ARP messages to the client — effectively bypassing isolation. This is the most universal version of the attack working on any WPA2/WPA3 network that uses a shared GTK. That said, some enterprise-grade access points support GTK randomization for each individual client, which renders this specific method ineffective.

Broadcast packet redirection

This version of the attack doesn’t even require the attacker to authenticate at the access point first. The attacker sends packets to the AP with a broadcast destination address (FF:FF:FF:FF:FF:FF) and the ToDS flag set to 1.  As a result, many access points treat this packet as legitimate broadcast traffic; they encrypt it using the GTK, and blast it out to every client on the subnet, including the victim. Just like in the previous method, traffic specifically meant for a single victim can be pre-packaged inside.

Router redirection

This attack exploits an architectural gap between Layer 2 and Layer 3 security found in some manufacturers’ hardware. The attacker sends a packet to the access point, setting the victim’s IP address as the destination at the network layer (L3).  However, at the wireless layer (L2), the destination is set to the access point’s own MAC address, so the isolation filter doesn’t trip. The routing subsystem (L3) then dutifully routes the packet back out to the victim, bypassing the L2 isolation entirely. Like the previous methods, this is another transmit-only attack where the attacker can’t see the reply.

Port stealing to intercept packets

The attacker connects to the network using a spoofed version of the victim’s MAC address, and floods the network with ARP responses claiming, “this MAC address is on my port and SSID”.  The target network’s router updates its MAC tables, and starts sending the victim’s traffic to this new port instead. Consequently, traffic intended for the victim ends up with the attacker — even if the victim is connected to a completely different SSID.

In a scenario where the attacker connects via an open, unencrypted network, this means traffic meant for a client on a WPA2/WPA3-secured network is actually broadcast over the open air, where not only the attacker but anyone nearby can sniff it.

Port stealing to send packets

In this version, the attacker connects directly to the victim’s Wi-Fi adapter, and bombards it with ARP requests spoofing the access point’s MAC address. As a result, the victim’s computer starts sending its outgoing traffic to the attacker instead of the network. By running both stealing attacks simultaneously, an attacker can, in several scenarios, execute a full MitM attack.

Practical consequences of AirSnitch attacks

By combining several of the techniques described above, a hacker can pull off some pretty serious moves:

• Complete bidirectional traffic interception for a MitM attack. This means they can snatch and modify data moving between the victim and the access point without the victim ever knowing.
• Hopping between SSIDs. An attacker sitting on a guest network can reach hosts on a locked-down corporate network if both are running off the same physical access point.
• Attacks on RADIUS. Since many companies use RADIUS authentication for their corporate Wi-Fi, an attacker can spoof the access point’s MAC address to intercept initial RADIUS authentication packets. From there, they can brute-force the shared secret. Once they have that, they can spin up a rogue RADIUS server and access point to hijack data from any device that connects to it.
• Exposing unencrypted data from “secure” subnets: Traffic that’s supposed to be sent to a client under the protection of WPA2/WPA3 can be retransmitted onto an open guest network, where it’s essentially broadcast for anyone to hear.

To pull off these attacks effectively, a hacker needs a device capable of simultaneous data transmission and reception with both the victim’s adapter and the access point. In a real-world scenario, this usually means a laptop with two Wi-Fi adapters running specifically configured Linux drivers. It’s worth noting that the attack isn’t exactly silent: it requires a flood of ARP packets, it can cause brief Wi-Fi glitches when it starts, and network speeds might tank to around 10Mbps. Despite these red flags, it’s still very much a practical threat in many environments.

Vulnerable devices

As part of the study, several enterprise and home access points and routers were put to the test. The list included products from Cisco, Netgear, Ubiquiti, Tenda, D-Link, TP-Link, LANCOM, and ASUS, as well as routers running popular community firmware like DD-WRT and OpenWrt. Every single device tested was vulnerable to at least some of the attacks described here. Even more concerning, the D-Link DIR-3040 and LANCOM LX-6500 were susceptible to every single variation of AirSnitch.

Interestingly, some routers were equipped with protective mechanisms that blocked the attacks, even though the underlying architectural flaws were still present. For example, the Tenda RX2 Pro automatically disconnects any client whose MAC address appears on two BSSIDs simultaneously, which effectively shuts down port stealing.

The researchers emphasize that any network administrator or IT security team serious about defense should test their own specific configurations. That’s the only way to pinpoint exactly which threats are relevant to your organization’s setup.

How to protect your corporate network from AirSnitch

The threat is most immediate for organizations running guest and corporate Wi-Fi networks on the same access points without additional VLAN segmentation. There are also significant risks for companies using RADIUS with outdated settings or weak shared secrets for wireless authentication.

The bottom line is that we need to stop viewing client isolation on an access point as a real security measure, and start seeing it as just a convenience feature. Real security needs to be handled differently:

• Segment the network using VLANs. Each SSID should have its own VLAN, with strict 802.1Q packet tagging maintained all the way from the access point to the firewall or router.
• Implement stricter packet inspection at the routing level — depending on the hardware capabilities. Features like Dynamic ARP Inspection, DHCP snooping, and limiting the number of MAC addresses per port help defend against IP/MAC spoofing.
• Enable individual GTK keys for each client, if your equipment supports it.
• Use more resilient RADIUS and 802.1X settings, including modern cipher suites and robust shared secrets.
• Log and analyze EAP/RADIUS authentication anomalies in your SIEM. This helps track many attack attempts beyond just AirSnitch. Other red flag events to watch for include the same MAC address appearing on different SSIDs, spikes in ARP requests, or clients rapidly jumping between BSSIDs or VLANs.
• Apply security at higher levels of the network topology. Many of these attacks lose their punch if the organization has universally implemented TLS and HSTS for all business application traffic, requires an active VPN for all Wi-Fi connections, or has fully embraced a Zero Trust architecture.

Banks, governments and tech providers urged to upgrade security because current systems will soon be obsolete

Banks, governments and technology providers need to be prepared for quantum computer hackers capable of breaking most existing encryption systems by 2029, Google has warned.

The tech company said in a blogpost that quantum computers would pose a “significant threat to current cryptographic standards” before the end of the decade and urged other companies to follow its lead.

Introduction

On March 4, 2026, Google and iVerify published reports about a highly sophisticated exploit kit targeting Apple iPhone devices. According to Google, the exploit kit was first discovered in targeted attacks conducted by a customer of an unnamed surveillance vendor. It was later used by other attackers in watering-hole attacks in Ukraine and in financially motivated attacks in China. Additionally, researchers discovered an instance with the debug version of the exploit kit, which revealed the internal names of the exploits and the framework name used by its developers — Coruna. Analysis of the kit showed that it relies on the exploitation of many previously patched vulnerabilities and also includes exploits for CVE-2023-32434 and CVE-2023-38606. These two vulnerabilities particularly caught our attention because they had been first discovered as zero-days used in Operation Triangulation.

Operation Triangulation is a complex mobile APT campaign targeting iOS devices. We discovered it while monitoring the network traffic of our own corporate Wi-Fi network. We noticed suspicious activity that originated from several iOS-based phones. Following the investigation, we learned that this campaign employed a sophisticated spyware implant and multiple zero-day exploits. The investigation lasted for over six months, during which we disclosed our findings in connection to the attack. Kaspersky GReAT experts also presented these findings at the 37th Chaos Communication Congress (37C3).

Although all the details of both CVE-2023-32434 and CVE-2023-38606 have long been publicly available, and other researchers have developed their own exploits without ever seeing the Triangulation code, we decided to closely investigate the exploits used in Coruna. Some of the exploit kit distribution links provided by Google remained active at the time the report was published, which allowed us to collect, decrypt, and analyze all components of Coruna.

During our analysis, we discovered that the kernel exploit for CVE-2023-32434 and CVE-2023-38606 vulnerabilities used in Coruna, in fact, is an updated version of the same exploit that had been used in Operation Triangulation. The images below illustrate a high-level overview of the two attack chains. The exploit in question is highlighted with a red rectangle.

Attack chain of Operation Triangulation (simplified)

Attack chain of Coruna (simplified)

Moreover, we discovered that Coruna includes four additional kernel exploits that we had not seen used in Operation Triangulation, two of which were developed after the discovery of Operation Triangulation. All of these exploits are built on the same kernel exploitation framework and share common code. Code similarities from kernel exploits can also be found in other components of Coruna. These findings led us to conclude that this exploit kit was not patchworked but rather designed with a unified approach. We assume that it’s an updated version of the same exploitation framework that was used — at least to some extent — in Operation Triangulation.

Technical details

While we continue to investigate all exploits and vulnerabilities used by Coruna, this post provides a high-level overview of the exploit kit and attack chain.

Safari

Exploitation begins with a stager that fingerprints the browser and selects and executes appropriate remote code execution (RCE) and pointer authentication code (PAC) exploits depending on the browser version. It also contains a URL to an encrypted file with information about all available packages containing exploits and other components. The stager also includes a 256-bit key used to decrypt it. The URL and decryption key are passed to a payload embedded in PAC exploits.

Payload

The payload is responsible for initiating the exploitation of the kernel. After initialization, the payload first downloads a file with information about other available components. To extract it, the payload performs several steps processing multiple file formats.

First, the downloaded file is decrypted using the ChaCha20 stream cipher. Decryption yields a container with the magic number 0xBEDF00D, which stores LZMA-compressed data.

The file format used by the exploit kit to store compressed data

The decompressed data presents another container with the magic number 0xF00DBEEF. This file format is used in the exploit kit to store and retrieve files by their IDs.

The file format used by the exploit kit to store files

We provide a description of all possible File ID values below. At this stage, when the payload gathers information about all available file packages, this container holds only one file, and its File ID is 0x70000.

Finally, we get to the file with information about all available file packages. It starts with the magic value 0x12345678. The exploit kit uses this file format to obtain URLs and decryption keys for additional components that need to be downloaded.

The file format used by the exploit kit to store information about file packages

The components required for exploiting a targeted device are selected using the Package ID. Its high byte specifies the package type and required hardware. We’ve seen the following package types:

• 0xF2 – exploit for ARM64,
• 0xF3 – exploit for ARM64E,
• 0xA2 – Mach-O loader for ARM64,
• 0xA3 – Mach-O loader for ARM64E,
• 2 – implant for ARM64,
• 0xE2 – implant for ARM64E.

The payload code also supports additional package types, such as 0xF1, an exploit for older ARM devices that do not support 64-bit architecture. Interestingly, however, the files for such exploits are missing.

Other bytes of the Package ID define the supported firmware version and CPU generation.

Some of the observed Package IDs (those with unique content)

The files inside these packages are also stored in encrypted and compressed 0xF00DBEEF containers, but this time compression is optional and is determined by the second bit in the Flags field. Different packages contain different sets of files. A description of all possible File IDs is given in the table below.

Observed File IDs

After downloading the necessary components, the payload begins executing kernel exploits, Mach-O loaders, and the malware launcher. The payload selects an appropriate Mach-O loader based on the firmware version, CPU, and presence of the iokit-open-service permission.

Kernel exploits

We analyzed all five kernel exploits from the kit and discovered that one of them is an updated version of the same exploit we discovered in Operation Triangulation. There are many small changes, but the most noticeable are as follows:

• The code takes into account more values ​​from XNU version strings, allowing for more accurate version checking.
• Added a check for iOS 17.2. We assume that this was the latest version of iOS at the time of development (released in December 2023).
• Added checks for newer Apple processors: A17, M3, M3 Pro, M3 Max (released in fall 2023).
• Added a check for iOS version 16.5 beta 4. This version patched the exploit after our report to Apple.

Why does the exploit need to check for iOS 17.2 and newer CPUs if the targeted vulnerabilities were fixed in iOS 16.5 beta 4? The answer can be found by examining other exploits: they are all based on the same source code. The only difference is in the vulnerabilities they exploit, so these checks were added to support the newer exploits and appeared in the older version after recompilation.

Launcher

The launcher is responsible for orchestrating the post-exploitation activities. It also uses the kernel exploit and the interface it provides. However, since the exploit creates special kernel objects during its execution that provide the ability to read and write to kernel memory, the launcher simply reuses these objects without the need to trigger vulnerabilities and go through the entire exploitation path again. The launcher cleans up exploitation artifacts, retrieves the process name for injection from a config with the 0xDEADD00F magic number, injects a stager into the target process, uses it to execute itself, and launches the implant.

Conclusions

This case demonstrates once again the dangers associated with such malicious tools that lie in their potential wide usage. Originally developed for cyber-espionage purposes, this framework is now being used by cybercriminals of a broader kind, placing millions of users with unpatched devices at risk. Given its modular design and ease of reuse, we expect that other threat actors will begin incorporating it into their attacks. We strongly recommend that users install the latest security updates as soon as possible, if they have not already done so.

Introduction

On March 4, 2026, Google and iVerify published reports about a highly sophisticated exploit kit targeting Apple iPhone devices. According to Google, the exploit kit was first discovered in targeted attacks conducted by a customer of an unnamed surveillance vendor. It was later used by other attackers in watering-hole attacks in Ukraine and in financially motivated attacks in China. Additionally, researchers discovered an instance with the debug version of the exploit kit, which revealed the internal names of the exploits and the framework name used by its developers — Coruna. Analysis of the kit showed that it relies on the exploitation of many previously patched vulnerabilities and also includes exploits for CVE-2023-32434 and CVE-2023-38606. These two vulnerabilities particularly caught our attention because they had been first discovered as zero-days used in Operation Triangulation.

Operation Triangulation is a complex mobile APT campaign targeting iOS devices. We discovered it while monitoring the network traffic of our own corporate Wi-Fi network. We noticed suspicious activity that originated from several iOS-based phones. Following the investigation, we learned that this campaign employed a sophisticated spyware implant and multiple zero-day exploits. The investigation lasted for over six months, during which we disclosed our findings in connection to the attack. Kaspersky GReAT experts also presented these findings at the 37th Chaos Communication Congress (37C3).

Although all the details of both CVE-2023-32434 and CVE-2023-38606 have long been publicly available, and other researchers have developed their own exploits without ever seeing the Triangulation code, we decided to closely investigate the exploits used in Coruna. Some of the exploit kit distribution links provided by Google remained active at the time the report was published, which allowed us to collect, decrypt, and analyze all components of Coruna.

During our analysis, we discovered that the kernel exploit for CVE-2023-32434 and CVE-2023-38606 vulnerabilities used in Coruna, in fact, is an updated version of the same exploit that had been used in Operation Triangulation. The images below illustrate a high-level overview of the two attack chains. The exploit in question is highlighted with a red rectangle.

Attack chain of Operation Triangulation (simplified)

Attack chain of Coruna (simplified)

Moreover, we discovered that Coruna includes four additional kernel exploits that we had not seen used in Operation Triangulation, two of which were developed after the discovery of Operation Triangulation. All of these exploits are built on the same kernel exploitation framework and share common code. Code similarities from kernel exploits can also be found in other components of Coruna. These findings led us to conclude that this exploit kit was not patchworked but rather designed with a unified approach. We assume that it’s an updated version of the same exploitation framework that was used — at least to some extent — in Operation Triangulation.

Technical details

While we continue to investigate all exploits and vulnerabilities used by Coruna, this post provides a high-level overview of the exploit kit and attack chain.

Safari

Exploitation begins with a stager that fingerprints the browser and selects and executes appropriate remote code execution (RCE) and pointer authentication code (PAC) exploits depending on the browser version. It also contains a URL to an encrypted file with information about all available packages containing exploits and other components. The stager also includes a 256-bit key used to decrypt it. The URL and decryption key are passed to a payload embedded in PAC exploits.

Payload

The payload is responsible for initiating the exploitation of the kernel. After initialization, the payload first downloads a file with information about other available components. To extract it, the payload performs several steps processing multiple file formats.

First, the downloaded file is decrypted using the ChaCha20 stream cipher. Decryption yields a container with the magic number 0xBEDF00D, which stores LZMA-compressed data.

The file format used by the exploit kit to store compressed data

The decompressed data presents another container with the magic number 0xF00DBEEF. This file format is used in the exploit kit to store and retrieve files by their IDs.

The file format used by the exploit kit to store files

We provide a description of all possible File ID values below. At this stage, when the payload gathers information about all available file packages, this container holds only one file, and its File ID is 0x70000.

Finally, we get to the file with information about all available file packages. It starts with the magic value 0x12345678. The exploit kit uses this file format to obtain URLs and decryption keys for additional components that need to be downloaded.

The file format used by the exploit kit to store information about file packages

The components required for exploiting a targeted device are selected using the Package ID. Its high byte specifies the package type and required hardware. We’ve seen the following package types:

• 0xF2 – exploit for ARM64,
• 0xF3 – exploit for ARM64E,
• 0xA2 – Mach-O loader for ARM64,
• 0xA3 – Mach-O loader for ARM64E,
• 2 – implant for ARM64,
• 0xE2 – implant for ARM64E.

The payload code also supports additional package types, such as 0xF1, an exploit for older ARM devices that do not support 64-bit architecture. Interestingly, however, the files for such exploits are missing.

Other bytes of the Package ID define the supported firmware version and CPU generation.

Some of the observed Package IDs (those with unique content)

The files inside these packages are also stored in encrypted and compressed 0xF00DBEEF containers, but this time compression is optional and is determined by the second bit in the Flags field. Different packages contain different sets of files. A description of all possible File IDs is given in the table below.

Observed File IDs

After downloading the necessary components, the payload begins executing kernel exploits, Mach-O loaders, and the malware launcher. The payload selects an appropriate Mach-O loader based on the firmware version, CPU, and presence of the iokit-open-service permission.

Kernel exploits

We analyzed all five kernel exploits from the kit and discovered that one of them is an updated version of the same exploit we discovered in Operation Triangulation. There are many small changes, but the most noticeable are as follows:

• The code takes into account more values ​​from XNU version strings, allowing for more accurate version checking.
• Added a check for iOS 17.2. We assume that this was the latest version of iOS at the time of development (released in December 2023).
• Added checks for newer Apple processors: A17, M3, M3 Pro, M3 Max (released in fall 2023).
• Added a check for iOS version 16.5 beta 4. This version patched the exploit after our report to Apple.

Why does the exploit need to check for iOS 17.2 and newer CPUs if the targeted vulnerabilities were fixed in iOS 16.5 beta 4? The answer can be found by examining other exploits: they are all based on the same source code. The only difference is in the vulnerabilities they exploit, so these checks were added to support the newer exploits and appeared in the older version after recompilation.

Launcher

The launcher is responsible for orchestrating the post-exploitation activities. It also uses the kernel exploit and the interface it provides. However, since the exploit creates special kernel objects during its execution that provide the ability to read and write to kernel memory, the launcher simply reuses these objects without the need to trigger vulnerabilities and go through the entire exploitation path again. The launcher cleans up exploitation artifacts, retrieves the process name for injection from a config with the 0xDEADD00F magic number, injects a stager into the target process, uses it to execute itself, and launches the implant.

Conclusions

This case demonstrates once again the dangers associated with such malicious tools that lie in their potential wide usage. Originally developed for cyber-espionage purposes, this framework is now being used by cybercriminals of a broader kind, placing millions of users with unpatched devices at risk. Given its modular design and ease of reuse, we expect that other threat actors will begin incorporating it into their attacks. We strongly recommend that users install the latest security updates as soon as possible, if they have not already done so.

Researchers at ETH Zurich have tested the security of Bitwarden, LastPass, Dashlane, and 1Password password managers.

The post Password Managers Vulnerable to Vault Compromise Under Malicious Server appeared first on SecurityWeek.