We’ve been thinking deeply about enterprise security. The operating model that served us for the past decade (collect telemetry, store it, query it, build dashboards to watch it) is no longer keeping pace. We need to shift to the new world: telemetry, context, reasoning, and actions. An approach that produces outcomes. The latest cybersecurity frontier models further made this shift urgent. Models like Claude Mythos can now find software vulnerabilities and reason through complex attack paths at machine-speed, leading to an exponentially increasing backlog of vulnerabilities.
Introducing AWS Continuum for code vulnerabilities
Today, we’re announcing AWS Continuum for code vulnerabilities, now available in gated preview. Continuum for code vulnerabilities addresses the full lifecycle of a code vulnerability at machine speed: from discovery through actions. It reasons over your environment, confirms what is real, and drives toward resolution. It’s model agnostic, using multiple frontier models where each performs best, and is built to incorporate the latest and most capable models as they emerge.
Continuum is built on lessons learned from running security across AWS and Amazon.com. Securing businesses that operate in different industries required a system that understands business context rather than applying generic rules uniformly.
How it works
Continuum for code vulnerabilities reasons over your full environment. This context includes structured data already living in Amazon Web Service (AWS) (your infrastructure, permissions, network topology, code) and the unstructured data that captures how your organization operates and your risk profile (your documents, communications, business priorities).
Continuum for code vulnerabilities operates in four continuous phases.
Discovery: Security teams tackle a backlog of vulnerabilities, and many are already using frontier models to find more. Continuum starts by ingesting that existing backlog and performing its own vulnerability scan of your environment. This creates a more comprehensive view of vulnerabilities and the associated attack paths.
Prioritization: Continuum uses context to evaluate, enrich, and prioritize every finding. Is the affected component deployed, is it reachable, is it in a production path, and what would the business impact be if exploited? The result is an evidence-backed list of priorities, allowing Continuum and your team to focus on what’s most important.
Validation: Continuum validates findings to surface false positives before they waste your team’s time. It contextualizes vulnerabilities against your environment. It then constructs working exploit examples in a sandboxed environment that provide concrete, reproducible evidence of the issue.
Mitigation and remediation: Continuum assesses existing defenses around a validated issue, including blocking and compensating controls along with detection mechanisms. It then draws on its understanding of the codebase, context, and findings to recommend mitigation or remediation of the vulnerability with a network change, policy change, or code patch. The patch recommendation is validated using the same system that confirmed the vulnerability. It also provides blast radius visibility and rollback paths where feasible.
This is just the beginning. We’re starting with code (1st and 3rd party) and then expanding to other aspects of security.
Trust is graduated
Continuum starts in learn mode with a human in the loop. Every recommendation includes the reasoning behind it. As you gain confidence, you can graduate Continuum to enforce mode, enabling remediation that can be increasingly automated based on categories and risk profiles you define.
Continuum capabilities
In addition to Continuum for code vulnerabilities, Continuum includes capabilities you might already know. The AWS Security Agent penetration testing and code scanning functionality is now part of Continuum as Continuum pen testing and Continuum code scanning (Preview). We’re also launching Continuum threat modeling in preview, which automatically generates comprehensive threat models from design documents or source code and outputs results in STRIDE format. These capabilities serve as detection and analysis sources that feed into the broader Continuum loop of discovery, prioritization, validation, and remediation.
Getting started
We’re working with customers across financial services, automotive, and technology to shape AWS Continuum. Customer feedback confirms the direction: security teams want tools that earn trust and take action.
AWS Continuum for code vulnerabilities is available in gated preview. Sign up to request access at AWS Continuum.
If you have feedback about this post, submit comments in the Comments section below.
In this blog post you’ll learn how to detect and prevent subdomain takeover – a tactic where threat actors exploit dangling DNS records to redirect traffic to attacker-controlled resources. We’ll explain the issue, how the situation arises, and how you can use various AWS features and services to help mitigate the impact of this tactic.
Under the shared responsibility model, securing configurations in the cloud is your responsibility. AWS supports you through strong defaults, guidance in the Security Pillar of the Well-Architected Framework, and security services to help you meet that responsibility. The AWS Customer Incident Response Team (AWS CIRT) also monitors for new and trending tactics that threat actors use to exploit specific customer configurations, so that you can make informed design decisions and improve your response plans.
AWS CIRT has observed threat actors actively scanning for public DNS CNAME records that point to resources that no longer exist, looking for subdomain takeover opportunities.
Note: The subdomain takeover tactic does not leverage vulnerabilities of AWS services. It exploits a dangling DNS record to redirect traffic to an attacker-controlled resource.
Quick DNS Primer
CNAME Records: A CNAME (Canonical Name) record is a DNS entry that points one domain name to another. For example, api.example.com can be configured to point to api.example.s3-website-us-east-1.amazonaws.com. This feature of DNS enables users to configure a memorable, human-friendly domain name while the actual resource lives at a longer, machine-generated AWS hostname. A security issue emerges when the target resource is deleted but the CNAME record pointing to it remains – creating a “dangling” record.
Dangling Records: When a resource (like an S3 bucket) is deleted but the DNS record pointing to it is left behind, that DNS record becomes “dangling”, pointing to a resource that no longer exists. For resources in globally shared namespaces, threat actors can potentially reclaim the name of your deleted resource and serve malicious content through your DNS record.
What is subdomain takeover?
A subdomain is a prefix added to a domain that allows you to organize access to your resources. A subdomain takeover occurs when you delete the underlying resource and a threat actor creates a new resource with the same name to take advantage of the DNS records still pointing to it.
A subdomain takeover is possible when a CNAME record points to an AWS resource that uses a globally shared DNS namespace where the resource name can be chosen by any AWS customer. The following AWS resources meet these criteria:
Amazon S3 (global namespace): Bucket names like mybucket.s3.amazonaws.com are globally unique and can be claimed by any account if the bucket is deleted. Note: S3 buckets created with account regional namespaces (launched March 2026) are scoped to your account and are not subject to this issue.
Amazon CloudFront: Distribution domain names like d111111abcdef8.cloudfront.net are assigned by AWS and cannot be chosen by an attacker. However, if you delete a distribution and another customer creates one that happens to receive the same domain name, a dangling CNAME could resolve to their content.
AWS Elastic Beanstalk: Environment names like myapp.elasticbeanstalk.com are globally unique and can be claimed by any account if the environment is terminated.
Resources like Amazon VPC, Amazon EC2 instances, or private hosted zones are not subject to this tactic because they do not expose globally claimable DNS namespaces.
You create a DNS CNAME record pointing to your S3 website endpoint. The subdomain subdomain.example.com now resolves to subdomain.example.s3-website-us-east-1.amazonaws.com, which serves content from the S3 bucket named subdomain.example. If your team deletes the bucket and forgets to delete the DNS record, users that navigate to the site will see an error stating that the bucket doesn’t exist. However, at this point, if a threat actor sees this error and moves in to claim the bucket name, they will be able to set up their own site that users will see when they navigate to the subdomain.example.com site.
Figure 1 shows an S3 bucket named subdomain.example (a globally unique bucket name) configured to host a static website, with the S3 website endpoint subdomain.example.s3-website-us-east-1.amazonaws.com.
Figure 1: S3 bucket configured as a static website
As shown in Figure 2, we use Amazon Route 53 to create a CNAME record to resolve to our Amazon domain name; to give users a friendly name and so they do not have to remember the long S3 website name in URLs.
Figure 2: DNS Resolver configured with CNAME record pointing to origin bucket
The customer’s AWS administrator decides to stop serving content from the S3 bucket and deletes it, as shown in Figure 3.
Figure 3: Resource deleted without removing the CNAME record
With the S3 bucket deleted and the CNAME record still in place, the DNS record is now dangling. A threat actor identifies this situation and creates a new S3 bucket with the same global name subdomain.example in an AWS account that the threat actor controls, as shown in Figure 4. The threat actor can now serve content from this new bucket, including potentially malicious content. End users remain unaware of this switch and continue to access subdomain.example.com, trusting the content because it appears to originate from a URL they recognize.
Figure 4: Subdomain takeover happens
Potential impacts of a sub-domain takeover
Consider these potential impacts:
Reputation risk: There is a potential risk to your organization’s reputation, because you don’t control the content being served from the threat actor’s site that your DNS record points to.
Potential exposure to phishing campaigns: Users within your organization might have the subdomain bookmarked in their browser, not knowing the resource is no longer available, then unsuspectingly navigate to the site that now hosts malware or is used to phish user credentials.
Blocking: If the subdomain is flagged by security vendors for malicious activity, it could impact your business operations.
Financial loss: Subdomain takeover incidents can result in a financial impact due to the potential disruption to service delivery as you deal with the event.
Proactive detection
AWS Config for proactive detection
For proactive detection, you can use AWS Config to continuously monitor your Route 53 CNAME records and verify that the target resources exist in your account.
Prerequisite: This approach requires AWS Config recorder to be enabled for the resource types you want to monitor (S3 buckets, CloudFront distributions, Elastic Beanstalk environments). If Config isn’t recording a resource type, it won’t appear in the inventory check. For more information, see Setting up AWS Config with the console.
Why use AWS Config inventory instead of DNS resolution checks?
A common approach is to check whether a CNAME resolves to a valid endpoint. However, this method has a critical flaw: if an attacker has already claimed the resource, DNS resolution will succeed – to their resource, not yours. You would have no indication that you don’t own what’s responding.
By querying AWS Config’s recorded configuration items, you’re checking whether the resource exists in your account inventory, not just whether something responds at that DNS name. This approach correctly identifies dangling CNAMEs even after a takeover has occurred.
Implementation approach:
Account-level vs. organization-level scope
The reference implementation queries AWS Config inventory within a single account. This means that if a CNAME record in Account A points to a resource that legitimately exists in Account B within the same AWS organization, the rule will flag it as NON_COMPLIANT.
For organizations that share resources across accounts, you can modify the solution to use an AWS Config Aggregator, which queries resource inventory across all accounts in your organization. This is similar to how IAM Access Analyzer supports both account-level and organization-level scopes. To use this approach, you need an organization-level Config Aggregator already configured, and the Lambda function’s IAM role needs the config:SelectAggregateResourceConfig permission.
We recommend starting with account-level scope for simplicity, then expanding to organization-level if your environment includes cross-account resource sharing.
The main idea is to create a custom AWS Config rule that queries your Route 53 hosted zones for CNAME records, then parses each CNAME target to determine whether it points to a known AWS resource pattern such as S3, CloudFront, or Elastic Beanstalk. For each match, the rule cross-references the target against your AWS Config inventory to verify that the resource actually exists in your account. If the resource isn’t found, the rule marks the CNAME record as NON_COMPLIANT, surfacing it for review.
The Config rule should focus on known AWS resource patterns:
Note: CNAME records pointing to external third-party services are outside the scope of this detection mechanism, as those resources won’t appear in your AWS Config inventory.
NON_COMPLIANT findings from your Config rule can be routed to AWS Security Hub for centralized visibility, or trigger SNS notifications to alert your security team.
Figure 5: Dangling DNS Detection Solution
Reference implementation:
We’ve published a complete implementation of this detection approach as an open-source solution. The solution deploys a Lambda function that discovers CNAME records across all your Route 53 hosted zones and uses pattern matching to identify targets pointing to S3, CloudFront, and Elastic Beanstalk. It then queries your AWS Config inventory to verify whether each target resource still exists in your account. When a dangling record is detected, the solution generates a HIGH severity finding in Security Hub and can optionally send SNS notifications to alert your security team. A CloudWatch metrics dashboard is also included for ongoing compliance tracking.
Deployment:
# Clone the repository
git clone https://github.com/aws-samples/sample-dangling-dns-detection
cd sample-dangling-dns-detection
# Build the Lambda deployment package
./scripts/package.sh
# Upload to S3
aws s3 cp dist/dangling-dns-detection.zip s3://YOUR_BUCKET/
# Deploy the CloudFormation stack
aws cloudformation deploy \
--template-file infrastructure/template.yaml \
--stack-name dangling-dns-detection \
--parameter-overrides \
LambdaCodeS3Bucket=YOUR_BUCKET \
EvaluationFrequency=TwentyFour_Hours \
--capabilities CAPABILITY_NAMED_IAM
The stack creates an AWS Config custom rule that runs on your specified schedule (default: every 24 hours), evaluating all CNAME records and reporting compliance status.
Mitigating the effects
Mitigating subdomain takeover requires both preventive procedures and responsive capabilities.
Prevention: Standard operating procedure
The most effective mitigation is a standard operating procedure for resource deprovisioning that ensures DNS records are removed before the underlying resource:
Within your DNS zone, delete the CNAME record that points to the fully qualified domain name (FQDN) of the resource that you plan to deprovision.
Wait for the DNS TTL to expire before deleting the resource. DNS resolvers cache records for the duration of the TTL (for example, a TTL of 3600 means resolvers may serve the old record for up to one hour). If you delete the resource before the TTL expires, a threat actor could claim the resource name while cached CNAME entries are still directing traffic to it.
Deprovision the resource that you no longer want to use.
Run a DNS check of the CNAME record that you removed to verify that the resource is no longer resolving.
Key principle: Always delete DNS first, wait for the TTL to expire, then delete the resource. This order eliminates the window where a dangling record could be exploited.
Prevention: S3 account regional namespaces
As mentioned earlier, AWS introduced account regional namespaces for Amazon S3 general purpose buckets in March 2026. While this is a meaningful step toward mitigating the S3-specific takeover vector, there are important operational limitations to be aware of:
Existing buckets are unaffected. Buckets already created in the global namespace cannot be migrated to an account regional namespace. The bucket names remain globally unique and claimable by anyone if the bucket is deleted.
Global namespace is still the default. When creating a new bucket through the console, CLI, or SDK, the global namespace remains the default selection. Users who aren’t aware of the new option will continue creating globally-scoped buckets.
Existing IaC templates require updates. Existing infrastructure-as-code templates (CloudFormation, CDK, Terraform) that don’t explicitly opt in to the account regional namespace will continue provisioning buckets in the global namespace. For CloudFormation, this means setting the BucketNamespace property to account-regional. For other IaC tools, consult their documentation for the equivalent configuration. Organizations need to audit and update their templates to opt in.
For these reasons, the dangling DNS detection approach described in this post remains critical – particularly for organizations with existing S3 infrastructure, and for CloudFront, and Elastic Beanstalk resources where no equivalent namespace scoping exists.
Response: Notification and remediation
When a dangling DNS record is detected, the reference solution described in the Detection section automatically creates a HIGH severity finding in AWS Security Hub and reports the CNAME record as NON_COMPLIANT in AWS Config. If you provide an SNS topic ARN during deployment, the solution also sends notifications to alert your security or operations team via email, Slack, or other channels. For production environments, consider a human-in-the-loop workflow where these notifications are reviewed by a team member who approves the DNS record deletion before it’s executed. This prevents accidental deletion of legitimate records during transient issues.
The reference solution also includes a CloudWatch dashboard for tracking compliance status and evaluation metrics over time, giving your team ongoing visibility into DNS health across your hosted zones.
Note: Fully automated remediation (auto-deleting DNS records) carries risk – a false positive could disrupt legitimate services. We recommend starting with detection and notification, then evaluating automation based on your detection accuracy and operational maturity.
Conclusion
Subdomain takeover is a preventable misconfiguration that can have significant impact on your organization. A layered defense approach provides the best protection:
Prevention: Implement a standard operating procedure that deletes DNS records before deprovisioning the underlying resource.
Detection: Use AWS Config custom rules to proactively identify CNAME records pointing to resources that no longer exist in your account.
Response: Configure notifications through SNS or Security Hub so your team can respond quickly when dangling records are detected.
Monitoring: Maintain ongoing visibility through CloudWatch dashboards to track DNS health and compliance status.
The key insight is that good DNS hygiene – knowing when your CNAME records point to a nonexistent resource – is your first line of defense. Automated detection through AWS Config provides a safety net when operational procedures fail. And if you detect an issue, having a playbook ready to enact your response can lower the impact and your mean time to recovery.
If you have feedback about this post, submit comments in the Comments section below.
Four Critical Source Types. One Platform. Recorded Future is the Only Threat Intelligence Vendor that Collects and Analyzes Across Four Types of Data Sources.
When a critical vulnerability emerges, most organizations scramble for answers.
What’s being exploited? Who’s targeting it? Are we exposed?
During the emergence of the React2Shell vulnerability, one Recorded Future customer didn’t rely on speculation. Using Recorded Future’s IP scanning intelligence, they identified which IPs were actively scanning for exploitation, analyzed the exact request patterns being used, and immediately assessed their own exposure.
Instead of reacting to headlines, they acted on real-time intelligence.
In the first article in our series covering our unique data sourcing model, we looked at why source scale and diversity are essential for maximum threat protection. Now we’ll explain the four source types in more detail to see how, together, they empower our customers to prioritize, pinpoint, and act faster to stop threats.
This is the power of Recorded Future’s technical collection engine.
Technical intelligence at internet scale
Recorded Future continuously collects and analyzes telemetry from across the internet, including:
Network traffic analysis across billions of daily network intelligence records (with over 200 points of presence (PoP))
Internet-wide scanning and infrastructure monitoring
Malware detonation and behavioral analysis
Vulnerability exploitation tracking
This technical intelligence provides direct visibility into attacker infrastructure, behavior, and intent.
Finding what others miss
Technical collection becomes most valuable when it reveals what’s hidden.
In one investigation, Recorded Future identified suspicious traffic on a specific port through its Malicious Traffic Analysis. This insight led a security team to uncover additional command-and-control communication that had been missed due to incomplete logging, expanding the scope of the compromise.
This isn’t just detection—it’s discovery.
Deep malware intelligence through sandboxing
Understanding malware requires more than static indicators.
Recorded Future processes over 1.5 million malware samples daily through its sandbox, enabling deep behavioral analysis of:
Command-line execution
Process activity
Network communication
Exploit techniques
This allows analysts to move beyond “Is this malicious?” to:
How does it behave?
What infrastructure does it use?
How can we detect it elsewhere?
Customers consistently highlight this capability as transformative.
In one case, a security analyst identified a unique command-line artifact within sandbox results. By pivoting on that behavior in their environment, they uncovered an additional infection vector that would have otherwise gone undetected—avoiding a far more complex incident response scenario.
Intelligence from the underground
Technical signals alone don’t tell the full story.
Recorded Future augments telemetry with intelligence from criminal forums, marketplaces, and adversary communications, revealing:
Stolen data and credentials
Emerging attack techniques
Threat actor intent
Ransomware victimology
Telegram
This provides critical context for prioritizing risk and understanding adversary motivations.
Community intelligence: strength in numbers
Recorded Future’s Collective Insights capability aggregates detections across organizations, helping customers identify patterns they might not see alone. This is especially important for preparing for monthly C-suite briefs on the latest threat assessments.
One logistics customer used this capability to investigate a multi-stage intrusion, correlating activity across their environment and linking it to nation-state actors in real time. Another customer uses Collective Insights to provide clear visibility into the specific malware most frequently blocked within their own environment, rather than relying on general trends.
This shared intelligence transforms isolated detections into campaign-level understanding.
Proactive defense in practice
This combination of technical, underground, and community intelligence enables proactive defense.
Customers often use Recorded Future’s Threat Map to identify an emerging threat actor and deploy detections in advance. Weeks later, when the actor launches a phishing campaign, customers can immediately detect and block the activity—preventing compromise before it begins.
Where open source fits
Open-source intelligence provides valuable context, but on its own it’s incomplete. Without technical telemetry, behavioral analysis, and external digital risk monitoring, organizations risk seeing only part of the threat landscape.
At Recorded Future, open sources are one part of a broader intelligence ecosystem that also supports data leakage detection, code repository monitoring, social media monitoring, and analysis of web infrastructure and content—including HTML and DOM elements—to identify brand abuse, exposed data, impersonation, and other external threats.
The bottom line
Recorded Future’s technical collection engine doesn’t just gather data. It reveals:
Who’s attacking
How attacks are executed
Where infrastructure is operating
When action is required
One platform for comprehensive threat intelligence
While some platforms focus on immediate detection, the Recorded Future Platform maintains years of historical data to reveal long-term patterns. And it automatically connects intelligence from diverse sources, turning separate data streams into unified insights.
From initial reconnaissance through criminal planning, active infrastructure attacks, and malware deployment, our four intelligence source types work together to enable proactive defense across the entire attack lifecycle.
In the next blog in our series, we’ll show how human experts connect the dots, validating our intelligence and making it actionable so you can prevent threats.
To see our four types of data sources in action in the Recorded Future Platform, request a custom demo.
Today, Recorded Future is announcing the Impact and Metrics Dashboard, a new way for every Recorded Future customer to see the value their intelligence program generates without building reports by hand. The dashboard pulls data from your environment, alerts, integrations, threat detections, and analyst activity, then surfaces the metrics that map to the business and security outcomes your leadership cares about.
Security teams have always known that intelligence drives better outcomes. The hard part has been proving it in the language of the business. Boards, CFOs, and CIOs aren't asking for threat counts. They want measurable risk reduction tied to business context, and they want it in numbers they can defend.
Our 2025 ROI Report, validated across nearly 300 customers, puts numbers to what security teams already know. Recorded Future customers have reported achieving 351.3% ROI annually. 57% say the platform has substantially reduced their overall cyber risk. 96% would recommend it to a peer.
But the numbers that resonate most are not the averages. They are the attacks that your team was able to get ahead of. Ransomware stopped before detonation. Credentials reset before an adversary could use them. Fraud campaigns contained before they could reach customers. Until now, capturing that story meant pulling data from across the platform, stitching it together by hand, and rebuilding the same readout every quarter.
The most powerful version of that story is yours and that is what the Impact and Metrics Dashboard is built to show.
What the dashboard covers
Platform-Wide Security Value: Your headline number. Aggregate risk reduction and intelligence coverage across your environment, built for leadership conversations.
Threat Prioritization: See which threat actors and malware families are relevant to your organization, and how Recorded Future AI cuts noise so your team focuses on what matters. Customers who aligned their alerting to PIRs reported identifying new threats 65% faster.
Threat Detection: Understand how intelligence is moving through your security stack, from malware detected in your telemetry to integrations and threat hunting activity. Customers often receive critical alerts hours or days earlier than from other vendors.
Digital Risk Protection: Quantify exposure reduced from fraud, brand impersonation, and credential threats. For organizations with significant brand or customer risk, this is where ROI becomes immediately tangible and immediately explainable to a CFO.
Account & Credential Monitoring: See identity threats surfaced and remediated before they became incidents.
Recorded Future AI & Insikt GroupⓇ Research: Recorded Future’s expert Intelligence team & AI does the work for you, providing deeper insights than most teams could do alone. Measure analyst hours recaptured through AI-powered automation and the volume of expert research your team has put to work. Your efficiency case, in your own numbers.
Today the dashboard surfaces key metrics to start the conversation and give your team something concrete to point to. Over time the calculations will get more personalized, the benchmarks more specific to your organization, and the integration with your business context deeper.
The Impact and Metrics Dashboard is available now for every customer. To find it, navigate to Dashboards > Impact and Metrics in your Recorded Future instance. For setup help or questions, contact your Technical Account Manager (TAM).
Starting tomorrow, millions of people will gather in sixteen host cities across the United States, Canada, and Mexico to cheer on their teams in the 2026 FIFA World Cup. Securing the tournament will require preparing for a mix of physical security risks, cyber threats, scams, protests, politically motivated activity, and reputational disruption tied to one of the world’s most visible sporting events.
The World Cup’s global profile creates an attractive target environment for a wide range of threat actors. Cybercriminals are already exploiting tournament demand through fraudulent domains, fake stores, credential-harvesting sites, and advertising campaigns. Hacktivists and influence operators will likely try to use the event’s visibility to amplify political narratives or claim responsibility for disruptive activity. At the same time, public safety officials must manage the physical security challenges associated with large crowds, soft targets, protests, transportation hubs, hospitality infrastructure, and fan zones.
Together, these risks create a blended cyber-physical threat environment that requires coordination across public safety, cybersecurity, fraud, legal, communications, brand protection, executive protection, travel security, and third-party risk teams.
Figure 1: Assessment of physical, cyber, and fraud risks affecting the 2026 FIFA World Cup
Over the past two decades, noncombatant evacuation operations (NEOs) have emerged as an important tool for protecting China’s overseas interests. To assess China’s NEO capabilities for the US Army War College China Landpower Studies Center’s 2026 Carlisle Conference on the PLA (People’s Liberation Army), Insikt Group built an original dataset of 37 Chinese NEOs carried out between January 2005 and August 2025. This blog post has been adapted from Insikt Group’s conference paper, and our “China 2005–2025 Noncombatant Evacuation Operation Dataset” is attached as a PDF.
One of Insikt Group’s most notable findings is that, over the past twenty years, China has consistently mobilized civilian resources to facilitate NEOs, demonstrating China’s reliance on these resources for NEOs and its capability to call upon diverse instruments of national power to protect overseas interests. During this period, at least 65% of China’s NEOs involved support from Chinese state-owned enterprises (SOEs), private enterprises, or United Front/civil society organizations located in the host country, third-party countries, or China. The contributions of SOEs, private enterprises, and United Front/civil society organizations to China’s NEOs include:
Organizing evacuation efforts on the ground
Communicating official instructions
Providing air, land, and maritime transportation
Providing relief to evacuees once they arrive in neighboring countries or return to China-
The Chinese Communist Party (CCP) and the Chinese government have continued to take advantage of civilian resources for NEOs since August 2025 — such as for its Iran NEO in early 2026 — and will almost certainly continue to mobilize these resources in the future.
Overview of China’s NEOs
China carried out at least 37 NEOs in 28 different countries between 2005 and 2025 (see image below). China carried out eleven NEOs in Africa, nine in the Middle East, and nine in Asia, with the other eight occurring in the Caribbean, Pacific Islands, Europe, and North America. China conducted multiple NEOs in the Central African Republic, Haiti, Iran, Israel, Kyrgyzstan, Lebanon, Libya, and South Sudan.
The 28 countries in which China carried out a NEO between 2005 and 2025 (Source: Recorded Future)
Read all about the latest AWS security features, compliance updates, and hands-on resources in our new, monthly digest posts. You’ll find expert blog posts, new service capabilities, code samples, and workshops.
AWS Security Blog posts
This month’s AWS Security Blog posts covered AI security, network protection, identity management, compliance frameworks, and supply chain security. Read on for practical guidance on securing agentic AI workflows, filtering network traffic by category, defending against supply chain attacks, and more.
Enabling AI sovereignty on AWS Author: Stéphane Israël | Published: May 12, 2026 Learn how AWS delivers control and choice across the AI stack to help customers meet digital and AI sovereignty requirements.
Securing open proxies in your AWS environment Author: Dodd Mitchell | Published: May 4, 2026 Learn to identify and secure open proxies in your AWS environment to prevent abuse, protect your IP reputation, and control costs.
Introducing AI traffic analysis dashboards for AWS WAF Authors: Christopher Jen, Eitav Arditti, Kaustubh Phatak | Published: May 5, 2026 A new dashboard providing visibility into AI bot and agent activity including bot identification, intent classification, and access pattern analysis.
Announcing the ISO 31000:2018 Risk Management on AWS compliance guide Authors: Jesse McMahan, Akanksha Chaturvedi, Mayur Jadhav, Juan Rodriguez, Sana Rahman | Published: May 1, 2026 A compliance guide providing practical guidance for establishing a risk management program using ISO 31000:2018 principles in AWS environments.
New compliance guide available: ISO/IEC 42001:2023 on AWS Authors: Abdul Javid, Amber Welch, Muhammad Sharief, Jonathan Jenkyn, Satish Uppalapati | Published: May 6, 2026 A compliance guide providing practical guidance for designing and operating an Artificial Intelligence Management System (AIMS) using AWS services.
Governing infrastructure as code using pattern-based policy as code Authors: Guptaji Teegela, Paul Keastead | May 19, 2026 Learn to use Open Policy Agent (OPA) in CI/CD pipelines to validate AWS infrastructure changes before deployment using recurring control patterns.
Detecting and preventing crypto mining in your AWS environment Authors: Jason Palmer, Nadia Mahmood | May 13, 2026 Learn to use Amazon GuardDuty to identify and mitigate cryptocurrency mining threats in your AWS environment with a multi-layered defense strategy.
This month brings 8 new AWS samples spanning application security, data protection, infrastructure security, governance, and AI security. From AI-powered security agents on Amazon Bedrock AgentCore to centralized AWS Config monitoring at scale, these repositories help you implement security best practices across your AWS environment.
Security review assistant Learn to deploy a multi-agent system on Amazon Bedrock AgentCore that automates Deliverable Security Reviews by combining architecture analysis, IaC code review, ASH vulnerability scanning, and compliance assessment into a single pipeline.
AWS Security Agent Recorder Learn to use a cross-browser extension that records the unique domains your web app contacts and auto-fills them into the AWS Security Agent penetration test configuration.
Data Protection
KMS access audit Learn to resolve and report who can use your AWS Key Management Service (KMS) keys across IAM policies, key policies, and grants, with IAM Identity Center resolution to identify the humans behind SSO roles.
Centralized AWS Config CI monitoring with Amazon CloudWatch Learn to centrally monitor AWS Config Configuration Item recording across all accounts in an AWS Organization using CloudWatch Cross-Account Observability, with dashboards showing top resource types, per-account volume, and conformance pack compliance.
CloudFormation Guard security analyzer Learn to deploy an AI agent powered by Amazon Bedrock AgentCore that scans CloudFormation resource documentation, identifies security-critical properties with risk levels, and generates ready-to-use cfn-guard 3.x rules for your CI/CD pipeline.
This month brings 1 new AWS Labs repository focused on governance, helping research institutions deploy secure, tagged infrastructure with self-service access and multi-account controls.
May 2026 shows AI security maturing from model-level controls to full-stack protection of agentic workflows. The posts and samples provide patterns for policy-based authorization with Cedar, network traffic filtering by category, and cross-account compliance monitoring. The security bulletins address vulnerabilities in SDKs, drivers, and developer tooling. Each resource includes deployment steps or runnable code so you can validate in your own environment before adopting. Subscribe to the AWS Security Blog RSS feed to receive updates as they publish, and revisit this digest monthly for a consolidated view of what changed and what to act on.
If you have feedback about this post, submit comments in the Comments section below.
Login
