🦄 Making great presentations more accessible.
This project aims to enhances multilingual accessibility and discoverability while maintaining the integrity of original content. Detailed transcriptions and keyframes preserve the nuances and technical insights that make each session compelling.
Overview
📖 AWS re:Invent 2025 -Testing GuardDuty’s Runtime Detections:Hands-on with real world attack scenarios
In this video, Mohammad Wasiq, a lead security engineer at Amazon GuardDuty, explains how GuardDuty gathers real-world threat intelligence from AWS CIRT customer incidents and threat intelligence sources to prioritize detections. He reveals that compromised credentials and public-facing application compromise are the top two initial access techniques against AWS customers. The presentation demonstrates using Amazon GuardDuty Tester, a GitHub repository, to test runtime monitoring with realistic attack scenarios rather than simplistic single-technique tests. A live demonstration shows deploying a vulnerable PHP application on EKS, executing a webshell attack that downloads and runs crypto mining malware, and how GuardDuty detects these threats through multiple findings including suspicious commands, tool execution, and an aggregate attack sequence finding that provides comprehensive visibility into the attack chain.
; This article is entirely auto-generated while preserving the original presentation content as much as possible. Please note that there may be typos or inaccuracies.
Main Part
How GuardDuty Gathers Real-World Threat Intelligence to Prioritize Detection Capabilities
Hello, everyone. Thank you for coming to this talk, and I hope you have been having a nice time at AWS re:Invent. My name is Mohammad Wasiq, and I am one of the lead security engineers in Amazon GuardDuty. My core job in GuardDuty is to research, develop, and continuously improve its threat detection capabilities. During the last three years, I have been focusing on GuardDuty runtime monitoring. In this talk, you will learn how GuardDuty gathers information about real-world threats, how it uses this information to prioritize and implement threat detections, and how you could use realistic attack scenarios to test GuardDuty runtime monitoring.
For those of you who don't know what GuardDuty is, it is a threat detection service that monitors various log sources in your AWS account, such as CloudTrail logs and VPC flow logs, and applies machine learning and detection rules to detect threats in real-time. GuardDuty Runtime Monitoring is an optional runtime monitoring solution offered by GuardDuty. It involves deploying an eBPF agent to your AWS compute workloads, such as EC2 instances. The eBPF agent gathers various operating system level events and sends those back to GuardDuty for monitoring and threat detection.
An important question to ask is why you need to test the runtime monitoring solution. An obvious reason is that you would like to evaluate the runtime monitoring service to make sure that it meets your requirements. Another important reason is that you would like to test your incident response capabilities because it is really important to have a robust incident response procedure to respond to runtime monitoring findings.
We have noticed that many customers use simplistic tests when testing runtime monitoring, and these simplistic tests often map to a single MITRE technique. For example, a customer would create a cron job to test detections for persistence activity. There are two primary issues with these simplistic tests. First of all, they are not realistic. Secondly, they do not provide you any information about the noise reduction or the noise management capabilities of the runtime monitoring solution. You can see that all of these actions are very common actions in benign activity as well. For example, creating a cron job is a very common benign activity. So when you use these simplistic tests, you don't get any insights into how good the runtime monitoring solution is in filtering out benign activity from the actual threat activity.
For more effective testing, you need more realistic attack scenarios, and this is what you are going to learn in this talk today. First, let's see how GuardDuty gathers information about real-world attacks. The first and one of the most important sources of information are the actual customer incidents. We have a team called AWS CIRT, or Customer Incident Response Team, that helps customers in responding to their security incidents. From these customer engagements, we gather valuable information about tactics and techniques used in actual attacks against AWS customers. We also learn about the most common or the top techniques used against AWS customers.
Based on data from AWS CIRT, the top two initial access techniques used in attacks against AWS customers are compromised credentials and public-facing application compromise. Compromised credentials means that an attacker is able to get hold of your AWS credential or IAM credential and uses it to gain access to your AWS account. From there, they could exfiltrate data, send out spam emails, or create compute workloads for resource hijacking. Public-facing application compromise means that you have a vulnerable public-facing application. The attacker is able to compromise the vulnerability and gain access to the underlying compute resource such as the EC2 instance, and from there, they can perform various activities such as crypto mining or DDoS attacks against other targets on the internet.
Data from AWS shows that a vast majority of attacks against AWS customers deploy these two initial access techniques. This is the reason why GuardDuty prioritizes developing detections for these techniques, not just in GuardDuty runtime monitoring, but also in other GuardDuty features such as CloudTrail monitoring. Furthermore, the real-world attack scenarios that you'll be learning about in this talk are based on these two initial access techniques.
Another source of information on real-world attacks is the threat intelligence that GuardDuty consumes. GuardDuty uses various in-house and third-party sources of threat intelligence, and this is what we learn from these threat intelligence sources. First, we learn about indicators of compromise, which are the IP addresses, domain names, and file hashes used in real attacks. We also learn about the tactics and techniques used in real attacks and various activity patterns used in real attacks. Last but not least, we also learn about the context surrounding real-world attacks or real-world threats. The context is really important because it informs GuardDuty about the types of applications and environments that specific threats target and the sequences of tactics and techniques they deploy.
Let's visualize and understand all this using a simplistic real-world attack scenario. Web application compromise is one of the most common attack vectors routinely captured by our honeypots. This is how a typical web application compromise works. The attacker compromises a vulnerability in the web application to deploy a webshell. Once they have deployed the webshell, they can execute any command on the underlying operating system. Typically, the first step they take is downloading a script, a shell script which is script malware, and executing it. Then the script malware is used to download a second stage malware, which could be a crypto miner, DDoS malware, or anything else. Then they make the second stage malware executable using the chmod command. Finally, they execute the second stage malware. Usually, the attackers also persist the execution of the second stage malware by creating a scheduled task or a cron job. You can see that all of these actions and activities map to specific MITRE tactics and techniques. You can also see that we learn about specific patterns used in these techniques.
For example, in this case, the attacker uses the curl command to download a script malware from an IP address-based URL and pipes it to a shell process. Another interesting pattern is the creation of the cron job. Here, the attacker writes the instructions for the cron job to a temporary file and loads that temporary file using the crontab command. We also learn about the context surrounding all these actions and steps. For example, all these actions originate from a web application or a network-facing application, and they follow a very specific sequence. This example demonstrates how GuardDuty learns about tactics and techniques and activity patterns used in real attacks or real threats, and how it uses this information to prioritize and develop threat detections.
Testing GuardDuty Runtime Monitoring with Realistic Attack Scenarios Using Amazon GuardDuty Tester
Now, let's see how you could detect these threats using GuardDuty runtime monitoring with realistic attack scenarios. We have added multiple realistic scenarios to Amazon GuardDuty Tester. Let's see what Amazon GuardDuty Tester is. Amazon GuardDuty Tester is a public GitHub repository which allows you to test various GuardDuty findings. You can search it on Google. When you load the main page of the GitHub repository, you'll find easy-to-use instructions to set up a secure, locked-down test environment in your AWS account.
When you follow these instructions and execute them, they set up a lockdown VPC in your AWS account with various resources such as EC2 instances, an ECS cluster, and an EKS cluster. Once you have set up the test environment, the next important step is to make sure that GuardDuty runtime monitoring is enabled. Open up the GuardDuty console on the left-hand side and click on the runtime monitoring link. This will take you to the main runtime monitoring enablement page. Make sure that runtime monitoring is enabled. In this case, it's enabled, but the agent management for AWS Fargate is not enabled. Let's go ahead and enable it. Also, the agent management for Amazon EC2 is not enabled. Let's go ahead and enable it.
Now that the test environment is set, let's go ahead and execute the test. You are going to execute the test in two steps. In the first step, you are going to deploy a vulnerable PHP application on the EKS cluster, and in the second step, you are going to execute an attack against that PHP application. When you create the test environment using Amazon GuardDuty tester, it creates several EC2 instances in your AWS account. One of those instances is the driver GuardDuty tester. You're going to be connecting to this instance using SSM start session to start a terminal session, and from there you'll be executing the attack scenario.
Let's open up the Amazon GuardDuty tester repository again. It provides the command, the SSM start session command, to connect to the driver instance. Copy that command. Now, open up a terminal window on your client-side host. Make sure that it is set up with AWS CLI and also has permissions to perform SSM start session. First, set up the region where you have installed or created the test environment using Amazon GuardDuty tester. Now, paste the command and execute it. Now you are logged into the driver instance.
Inside the driver instance, you will find various files and directories. One of those directories is runtime scenarios. Let's look into this directory. You'll find various realistic scenarios here. One of those is php-webshell, and this is what you are going to execute today. Let's go ahead and look inside php-webshell. In this directory, you'll find two different scripts. One is deploy_php.sh and the other is attack.py. Deploy_php.sh deploys the PHP web application on the EKS cluster. Let's go ahead and deploy the PHP web application.
When you execute deploy_php.sh, it creates an ECR repository and loads a PHP Apache container image to it, and then uses that image to create an EKS pod on the EKS cluster. Now the pod is being created. Let's wait a little. The pod is now created, and this is the name of the pod, and this is the IP address where the web application is accessible. After creating the pod, the script also performs various setup steps on the pod. One of the more interesting setup steps is to set up a command and control server to simulate command and control communication for the scenario.
Now that the PHP application is deployed, let's go ahead and execute the attack. When you first start the attack script, it asks for permissions to modify or create the necessary GuardDuty permission settings in your account. Allow it to do that. As the first step of the attack, the script gets the IP address of the PHP web application. Then it accesses the index.php, exploits the vulnerability to deploy a webshell. Once it has deployed the webshell, it executes various discovery commands, downloads malware, and executes it.
This completes the execution of the attack scenario. Now let's see what findings GuardDuty generated. Let's open up the GuardDuty console and click on the findings link on the top menu. This will take you to all the findings generated. The scenario should have generated multiple findings.
For example, when multiple commands were executed through the webshell, GuardDuty generated a high severity suspicious command finding to verify that it originated from the PHP web application. Let's look at the process lineage of this finding. Here you can see that the parent is Apache2, which means that it actually originated from the PHP application because we are using Apache to run PHP.
The attack scenario also executed nmap for network reconnaissance. Because of that, GuardDuty generated a suspicious tool finding. Let's scroll down. You can see that the name of the process is nmap. The attack scenario also downloaded and executed a crypto miner, so GuardDuty generated a crypto miner executed finding. Let's look into this finding.
To verify that it also originates from the PHP web application, let's look at the process lineage of this finding as well. Here you can see that the grandparent is Apache2, which means that it actually originated from the PHP application. Last but not least, GuardDuty also generated an attack sequence finding. This is an aggregate or composite finding which provides a comprehensive view of all the tactics and techniques and signals detected during the attack scenario.
These are the key takeaways from this talk. In this talk, you learned how GuardDuty gathers information about real-world attacks and uses it to prioritize detections and implement threat detections, and how you could use realistic attack scenarios to test GuardDuty runtime monitoring. We have added multiple realistic scenarios to the Amazon GuardDuty Findings Tester GitHub repository, which you can access from this QR code. We will continue to add more scenarios to it. Thank you again for attending this talk.
; This article is entirely auto-generated using Amazon Bedrock.
Top comments (0)