Search the Community

Amazon Detective, a managed security service that helps analysts investigate potential security issues across AWS, has introduced a new feature to support investigating threats detected by Amazon GuardDuty's EC2 Runtime Monitoring capability. This expansion enhances Detective's ability to provide visualizations and context for investigating runtime threats targeting EC2 instances. View the full article

Amazon GuardDuty is a machine learning (ML)-based security monitoring and intelligent threat detection service that analyzes and processes various AWS data sources, continuously monitors your AWS accounts and workloads for malicious activity, and delivers detailed security findings for visibility and remediation. I love the feature of GuardDuty Runtime Monitoring that analyzes operating system (OS)-level, network, and file events to detect potential runtime threats for specific AWS workloads in your environment. I first introduced the general availability of this feature for Amazon Elastic Kubernetes Service (Amazon EKS) resources in March 2023. Seb wrote about the expansion of the Runtime Monitoring feature to provide threat detection for Amazon Elastic Container Service (Amazon ECS) and AWS Fargate as well as the preview for Amazon Elastic Compute Cloud (Amazon EC2) workloads in Nov 2023. Today, we are announcing the general availability of Amazon GuardDuty EC2 Runtime Monitoring to expand threat detection coverage for EC2 instances at runtime and complement the anomaly detection that GuardDuty already provides by continuously monitoring VPC Flow Logs, DNS query logs, and AWS CloudTrail management events. You now have visibility into on-host, OS-level activities and container-level context into detected threats. With GuardDuty EC2 Runtime Monitoring, you can identify and respond to potential threats that might target the compute resources within your EC2 workloads. Threats to EC2 workloads often involve remote code execution that leads to the download and execution of malware. This could include instances or self-managed containers in your AWS environment that are connecting to IP addresses associated with cryptocurrency-related activity or to malware command-and-control related IP addresses. GuardDuty Runtime Monitoring provides visibility into suspicious commands that involve malicious file downloads and execution across each step, which can help you discover threats during initial compromise and before they become business-impacting events. You can also centrally enable runtime threat detection coverage for accounts and workloads across the organization using AWS Organizations to simplify your security coverage. Configure EC2 Runtime Monitoring in GuardDuty With a few clicks, you can enable GuardDuty EC2 Runtime Monitoring in the GuardDuty console. For your first use, you need to enable Runtime Monitoring. Any customers that are new to the EC2 Runtime Monitoring feature can try it for free for 30 days and gain access to all features and detection findings. The GuardDuty console shows how many days are left in the free trial. Now, you can set up the GuardDuty security agent for the individual EC2 instances for which you want to monitor the runtime behavior. You can choose to deploy the GuardDuty security agent either automatically or manually. At GA, you can enable Automated agent configuration, which is a preferred option for most customers as it allows GuardDuty to manage the security agent on their behalf. The agent will be deployed on EC2 instances with AWS Systems Manager and uses an Amazon Virtual Private Cloud (Amazon VPC) endpoint to receive the runtime events associated with your resource. If you want to manage the GuardDuty security agent manually, visit Managing the security agent Amazon EC2 instance manually in the AWS documentation. In multiple-account environments, delegated GuardDuty administrator accounts manage their member accounts using AWS Organizations. For more information, visit Managing multiple accounts in the AWS documentation. When you enable EC2 Runtime Monitoring, you can find the covered EC2 instances list, account ID, and coverage status, and whether the agent is able to receive runtime events from the corresponding resource in the EC2 instance runtime coverage tab. Even when the coverage status is Unhealthy, meaning it is not currently able to receive runtime findings, you still have defense in depth for your EC2 instance. GuardDuty continues to provide threat detection to the EC2 instance by monitoring CloudTrail, VPC flow, and DNS logs associated with it. Check out GuardDuty EC2 Runtime security findings When GuardDuty detects a potential threat and generates security findings, you can view the details of the healthy information. Choose Findings in the left pane if you want to find security findings specific to Amazon EC2 resources. You can use the filter bar to filter the findings table by specific criteria, such as a Resource type of Instance. The severity and details of the findings differ based on the resource role, which indicates whether the EC2 resource was the target of suspicious activity or the actor performing the activity. With today’s launch, we support over 30 runtime security findings for EC2 instances, such as detecting abused domains, backdoors, cryptocurrency-related activity, and unauthorized communications. For the full list, visit Runtime Monitoring finding types in the AWS documentation. Resolve your EC2 security findings Choose each EC2 security finding to know more details. You can find all the information associated with the finding and examine the resource in question to determine if it is behaving in an expected manner. If the activity is authorized, you can use suppression rules or trusted IP lists to prevent false positive notifications for that resource. If the activity is unexpected, the security best practice is to assume the instance has been compromised and take the actions detailed in Remediating a potentially compromised Amazon EC2 instance in the AWS documentation. You can integrate GuardDuty EC2 Runtime Monitoring with other AWS security services, such as AWS Security Hub or Amazon Detective. Or you can use Amazon EventBridge, allowing you to use integrations with security event management or workflow systems, such as Splunk, Jira, and ServiceNow, or trigger automated and semi-automated responses such as isolating a workload for investigation. When you choose Investigate with Detective, you can find Detective-created visualizations for AWS resources to quickly and easily investigate security issues. To learn more, visit Integration with Amazon Detective in the AWS documentation. Things to know GuardDuty EC2 Runtime Monitoring support is now available for EC2 instances running Amazon Linux 2 or Amazon Linux 2023. You have the option to configure maximum CPU and memory limits for the agent. To learn more and for future updates, visit Prerequisites for Amazon EC2 instance support in the AWS documentation. To estimate the daily average usage costs for GuardDuty, choose Usage in the left pane. During the 30-day free trial period, you can estimate what your costs will be after the trial period. At the end of the trial period, we charge you per vCPU hours tracked monthly for the monitoring agents. To learn more, visit the Amazon GuardDuty pricing page. Enabling EC2 Runtime Monitoring also allows for a cost-saving opportunity on your GuardDuty cost. When the feature is enabled, you won’t be charged for GuardDuty foundational protection VPC Flow Logs sourced from the EC2 instances running the security agent. This is due to similar, but more contextual, network data available from the security agent. Additionally, GuardDuty would still process VPC Flow Logs and generate relevant findings so you will continue to get network-level security coverage even if the agent experiences downtime. Now available Amazon GuardDuty EC2 Runtime Monitoring is now available in all AWS Regions where GuardDuty is available, excluding AWS GovCloud (US) Regions and AWS China Regions. For a full list of Regions where EC2 Runtime Monitoring is available, visit Region-specific feature availability. Give GuardDuty EC2 Runtime Monitoring a try in the GuardDuty console. For more information, visit the Amazon GuardDuty User Guide and send feedback to AWS re:Post for Amazon GuardDuty or through your usual AWS support contacts. — Channy View the full article

Amazon GuardDuty has incorporated new machine learning techniques to more accurately detect anomalous activities indicative of threats to your Amazon Elastic Kubernetes Service (Amazon EKS) clusters. This new capability continuously models Kubernetes audit log events from Amazon EKS to detect highly suspicious activity such as unusual user access to Kubernetes secrets that can be used to escalate privileges, and suspicious container deployments with images not commonly used in the cluster or account. The new threat detections are available for all GuardDuty customers that have GuardDuty EKS Audit Log Monitoring enabled. View the full article

Amazon GuardDuty Malware Protection adds a new capability that allows customers to initiate on-demand malware scans of Amazon Elastic Compute Cloud (Amazon EC2) instances, including instances used to host container workloads. Scans can be initiated using the GuardDuty console, or programmatically via the API, without the need to deploy security software and are designed to have no performance impact to running workloads. When potential malware is identified, GuardDuty generates actionable security findings with information such as the threat and file name, the file path, the Amazon EC2 instance ID, resource tags and, in the case of containers, the container ID and the container image used. This capability builds on the existing Malware Protection capability of GuardDuty-initiated scans that when enabled, automatically initiates a malware scan when GuardDuty detects suspicious behavior indicative of malware on the instance. View the full article

Amazon GuardDuty expands threat detection coverage to continuously monitor network activity logs, starting with VPC Flow Logs, generated from the execution of AWS Lambda functions to detect threats to Lambda such as functions maliciously repurposed for unauthorized cryptocurrency mining, or compromised Lambda functions that are communicating with known threat actor servers. GuardDuty Lambda Protection can be enabled with a few steps in the GuardDuty console, and using AWS Organizations, can be centrally enabled for all existing and new accounts in an organization. View the full article

Amazon GuardDuty adds three new threat detections to help detect suspicious DNS traffic indicative of potential attempts by malicious actors to evade detection when performing activities such as exfiltrating data, or using command & control servers to communicate with malware. View the full article

Amazon GuardDuty expands threat detection coverage to continuously monitor and profile Amazon Elastic Kubernetes Service (Amazon EKS) container runtime activity to identify malicious or suspicious behavior within container workloads. GuardDuty EKS Runtime Monitoring introduces a new lightweight, fully-managed security agent that monitors on-host operating system-level behavior, such as file access, process execution, and network connections. Once a potential threat is detected, GuardDuty generates a security finding that pinpoints the specific container, and includes details such as pod ID, image ID, EKS cluster tags, executable path, and process lineage. GuardDuty EKS Runtime monitoring includes over two dozen new detections at launch, which when combined with GuardDuty EKS Audit Log Monitoring, amounts to more than 50 detections that are tailored to identify threats to Amazon EKS deployments. View the full article

Since Amazon GuardDuty launched in 2017, GuardDuty has been capable of analyzing tens of billions of events per minute across multiple AWS data sources, such as AWS CloudTrail event logs, Amazon Virtual Private Cloud (Amazon VPC) Flow Logs, and DNS query logs, Amazon Simple Storage Service (Amazon S3) data plane events, Amazon Elastic Kubernetes Service (Amazon EKS) audit logs, and Amazon Relational Database Service (Amazon RDS) login events to protect your AWS accounts and resources. In 2020, GuardDuty added Amazon S3 protection to continuously monitor and profile S3 data access events and configurations to detect suspicious activities in Amazon S3. Last year, GuardDuty launched Amazon EKS protection to monitor control plane activity by analyzing Kubernetes audit logs from existing and new EKS clusters in your accounts, Amazon EBS malware protection to scan malicious files residing on an EC2 instance or container workload using EBS volumes, and Amazon RDS protection to identify potential threats to data stored in Amazon Aurora databases—recently generally available. GuardDuty combines machine learning (ML), anomaly detection, network monitoring, and malicious file discovery using various AWS data sources. When threats are detected, GuardDuty automatically sends security findings to AWS Security Hub, Amazon EventBridge, and Amazon Detective. These integrations help centralize monitoring for AWS and partner services, automate responses to malware findings, and perform security investigations from GuardDuty. Today, we are announcing the general availability of Amazon GuardDuty EKS Runtime Monitoring to detect runtime threats from over 30 security findings to protect your EKS clusters. The new EKS Runtime Monitoring uses a fully managed EKS add-on that adds visibility into individual container runtime activities, such as file access, process execution, and network connections. GuardDuty can now identify specific containers within your EKS clusters that are potentially compromised and detect attempts to escalate privileges from an individual container to the underlying Amazon EC2 host and the broader AWS environment. GuardDuty EKS Runtime Monitoring findings provide metadata context to identify potential threats and contain them before they escalate. Configure EKS Runtime Monitoring in GuardDuty To get started, first enable EKS Runtime Monitoring with just a few clicks in the GuardDuty console. Once you enable EKS Runtime Monitoring, GuardDuty can start monitoring and analyzing the runtime-activity events for all the existing and new EKS clusters for your accounts. If you want GuardDuty to deploy and update the required EKS-managed add-on for all the existing and new EKS clusters in your account, choose Manage agent automatically. This will also create a VPC endpoint through which the security agent delivers the runtime events to GuardDuty. If you configure EKS Audit Log Monitoring and runtime monitoring together, you can achieve optimal EKS protection both at the cluster control plane level, and down to the individual pod or container operating system level. When used together, threat detection will be more contextual to allow quick prioritization and response. For example, a runtime-based detection on a pod exhibiting suspicious behavior can be augmented by an audit log-based detection, indicating the pod was unusually launched with elevated privileges. These options are default, but they are configurable, and you can uncheck one of the boxes in order to disable EKS Runtime Monitoring. When you disable EKS Runtime Monitoring, GuardDuty immediately stops monitoring and analyzing the runtime-activity events for all the existing EKS clusters. If you had configured automated agent management through GuardDuty, this action also removes the security agent that GuardDuty had deployed. Manage GuardDuty Agent Manually If you want to manually deploy and update the EKS managed add-on, including the GuardDuty agent, per cluster in your account, uncheck Manage agent automatically in the EKS protection configuration. When managing the add-on manually, you are also responsible for creating the VPC endpoint through which the security agent delivers the runtime events to GuardDuty. In the VPC endpoint console, choose Create endpoint. In the step, choose Other endpoint services for Service category, enter com.amazonaws.us-east-1.guardduty-data for Service name in the US East (N. Virginia) Region, and choose Verify service. After the service name is successfully verified, choose VPC and subnets where your EKS cluster resides. Under Additional settings, choose Enable DNS name. Under Security groups, choose a security group that has the in-bound port 443 enabled from your VPC (or your EKS cluster). Add the following policy to restrict VPC endpoint usage to the specified account only: { "Version": "2012-10-17", "Statement": [ { "Action": "*", "Resource": "*", "Effect": "Allow", "Principal": "*" }, { "Condition": { "StringNotEquals": { "aws:PrincipalAccount": "123456789012" } }, "Action": "*", "Resource": "*", "Effect": "Deny", "Principal": "*" } ] } Now, you can install the Amazon GuardDuty EKS Runtime Monitoring add-on for your EKS clusters. Select this add-on in the Add-ons tab in your EKS cluster profile on the Amazon EKS console. When you enable EKS Runtime Monitoring in GuardDuty and deploy the Amazon EKS add-on for your EKS cluster, you can view the new pods with the prefix amazon-guardduty-agent. GuardDuty now starts to consume runtime-activity events from all EC2 hosts and containers in the cluster. GuardDuty then analyzes these events for potential threats. These pods collect various event types and send them to the GuardDuty backend for threat detection and analysis. When managing the add-on manually, you need to go through these steps for each EKS cluster that you want to monitor, including new EKS clusters. To learn more, see Managing GuardDuty agent manually in the AWS documentation. Checkout EKS Runtime Security Findings When GuardDuty detects a potential threat and generates a security finding, you can view the details of the corresponding findings. These security findings indicate either a compromised EC2 instance, container workload, an EKS cluster, or a set of compromised credentials in your AWS environment. If you want to generate EKS Runtime Monitoring sample findings for testing purposes, see Generating sample findings in GuardDuty in the AWS documentation. Here is an example of potential security issues: a newly created or recently modified binary file in an EKS cluster has been executed. The ResourceType for an EKS Protection finding type could be an Instance, EKSCluster, or Container. If the Resource type in the finding details is EKSCluster, it indicates that either a pod or a container inside an EKS cluster is potentially compromised. Depending on the potentially compromised resource type, the finding details may contain Kubernetes workload details, EKS cluster details, or instance details. The Runtime details such as process details and any required context describe information about the observed process, and the runtime context describes any additional information about the potentially suspicious activity. To remediate a compromised pod or container image, see Remediating Kubernetes security issues discovered by GuardDuty in the AWS documentation. This document describes the recommended remediation steps for each resource type. To learn more about security finding types, see GuardDuty EKS Runtime Monitoring finding types in the AWS documentation. Now Available You can now use Amazon GuardDuty for EKS Runtime Monitoring. For a full list of Regions where EKS Runtime Monitoring is available, visit region-specific feature availability. The first 30 days of GuardDuty for EKS Runtime Monitoring are available at no additional charge for existing GuardDuty accounts. If you enabled GuardDuty for the first time, EKS Runtime Monitoring is not enabled by default, and needs to be enabled as described above. After the trial period ends in the GuardDuty, you can see the estimated cost of EKS Runtime Monitoring. To learn more, see the GuardDuty pricing page. For more information, see the Amazon GuardDuty User Guide and send feedback to AWS re:Post for Amazon GuardDuty or through your usual AWS support contacts. – Channy View the full article

Amazon GuardDuty has added new functionality to its integration with AWS Organizations to make it even simpler to enforce threat detection across all accounts in an organization. Since April 2020, GuardDuty customers can leverage its integrations with AWS Organizations to manage GuardDuty for up to 5,000 AWS accounts, as well as automatically apply threat detection coverage to new accounts added to the organization. In some case, this could still result in coverage gaps, for example, if GuardDuty was not applied to all existing accounts, or if it was unintentionally suspended in individual accounts. Now with a few steps in the GuardDuty console, or one API call, delegated administrators can enforce GuardDuty threat detection coverage for their organization by automatically applying the service to all existing and new accounts, as well as automatically identifying and remediating potential coverage drift. To learn more, see the Amazon GuardDuty account management User Guide. View the full article

Amazon GuardDuty broadens threat detection coverage to help you protect your data residing in Amazon Aurora databases. GuardDuty RDS Protection is designed to profile and monitor access activity to Aurora databases in your AWS account without impacting database performance. Using tailored machine learning models and integrated threat intelligence, GuardDuty can detect potential threats such as high severity brute force attacks, suspicious logins, and access by known threat actors. View the full article

Amazon GuardDuty now offers threat detection for Amazon Aurora to identify potential threats to data stored in Aurora databases. Amazon GuardDuty RDS Protection profiles and monitors access activity to existing and new databases in your account, and uses tailored machine learning models to accurately detect suspicious logins to Aurora databases. Once a potential threat is detected, GuardDuty generates a security finding that includes database details and rich contextual information on the suspicious activity, is integrated with Aurora for direct access to database events without requiring you to modify your databases, and is designed to not affect database performance. View the full article

Starting today, Amazon Detective automatically groups related GuardDuty findings to help security analysts reduce triage time and create a more comprehensive security investigation. Detective uses machine learning (ML) to group related GuardDuty findings that in insolation may have been ignored but together show the lifecycle of an attack, which can help security analysts identify advanced threats more easily. Available under the Summary page, Detective shows groups of related GuardDuty findings with severity, all affected AWS accounts, and resources. In addition, Detective maps the evolution of findings to tactics, techniques, and procedures (TTP) from the MITRE ATT&CK framework - a well adopted framework for security and threat detection. View the full article

With Amazon GuardDuty, you can monitor your AWS accounts and workloads to detect malicious activity. Today, we are adding to GuardDuty the capability to detect malware. Malware is malicious software that is used to compromise workloads, repurpose resources, or gain unauthorized access to data. When you have GuardDuty Malware Protection enabled, a malware scan is initiated when GuardDuty detects that one of your EC2 instances or container workloads running on EC2 is doing something suspicious. For example, a malware scan is triggered when an EC2 instance is communicating with a command-and-control server that is known to be malicious or is performing denial of service (DoS) or brute-force attacks against other EC2 instances. GuardDuty supports many file system types and scans file formats known to be used to spread or contain malware, including Windows and Linux executables, PDF files, archives, binaries, scripts, installers, email databases, and plain emails. When potential malware is identified, actionable security findings are generated with information such as the threat and file name, the file path, the EC2 instance ID, resource tags and, in the case of containers, the container ID and the container image used. GuardDuty supports container workloads running on EC2, including customer-managed Kubernetes clusters or individual Docker containers. If the container is managed by Amazon Elastic Kubernetes Service (EKS) or Amazon Elastic Container Service (Amazon ECS), the findings also include the cluster name and the task or pod ID so application and security teams can quickly find the affected container resources. As with all other GuardDuty findings, malware detections are sent to the GuardDuty console, pushed through Amazon EventBridge, routed to AWS Security Hub, and made available in Amazon Detective for incident investigation. How GuardDuty Malware Protection Works When you enable malware protection, you set up an AWS Identity and Access Management (IAM) service-linked role that grants GuardDuty permissions to perform malware scans. When a malware scan is initiated for an EC2 instance, GuardDuty Malware Protection uses those permissions to take a snapshot of the attached Amazon Elastic Block Store (EBS) volumes that are less than 1 TB in size and then restore the EBS volumes in an AWS service account in the same AWS Region to scan them for malware. You can use tagging to include or exclude EC2 instances from those permissions and from scanning. In this way, you don’t need to deploy security software or agents to monitor for malware, and scanning the volumes doesn’t impact running workloads. The EBS volumes in the service account and the snapshots in your account are deleted after the scan. Optionally, you can preserve the snapshots when malware is detected. The service-linked role grants GuardDuty access to AWS Key Management Service (AWS KMS) keys used to encrypt EBS volumes. If the EBS volumes attached to a potentially compromised EC2 instance are encrypted with a customer-managed key, GuardDuty Malware Protection uses the same key to encrypt the replica EBS volumes as well. If the volumes are not encrypted, GuardDuty uses its own key to encrypt the replica EBS volumes and ensure privacy. Volumes encrypted with EBS-managed keys are not supported. Security in cloud is a shared responsibility between you and AWS. As a guardrail, the service-linked role used by GuardDuty Malware Protection cannot perform any operation on your resources (such as EBS snapshots and volumes, EC2 instances, and KMS keys) if it has the GuardDutyExcluded tag. Once you mark your snapshots with GuardDutyExcluded set to true, the GuardDuty service won’t be able to access these snapshots. The GuardDutyExcluded tag supersedes any inclusion tag. Permissions also restrict how GuardDuty can modify your snapshot so that they cannot be made public while shared with the GuardDuty service account. The EBS volumes created by GuardDuty are always encrypted. GuardDuty can use KMS keys only on EBS snapshots that have a GuardDuty scan ID tag. The scan ID tag is added by GuardDuty when snapshots are created after an EC2 finding. The KMS keys that are shared with GuardDuty service account cannot be invoked from any other context except the Amazon EBS service. Once the scan completes successfully, the KMS key grant is revoked and the volume replica in GuardDuty service account is deleted, making sure GuardDuty service cannot access your data after completing the scan operation. Enabling Malware Protection for an AWS Account If you’re not using GuardDuty yet, Malware Protection is enabled by default when you activate GuardDuty for your account. Because I am already using GuardDuty, I need to enable Malware Protection from the console. If you’re using AWS Organizations, your delegated administrator accounts can enable this for existing member accounts and configure if new AWS accounts in the organization should be automatically enrolled. In the GuardDuty console, I choose Malware Protection under Settings in the navigation pane. There, I choose Enable and then Enable Malware Protection. Snapshots are automatically deleted after they are scanned. In General settings, I have the option to retain in my AWS account the snapshots where malware is detected and have them available for further analysis. In Scan options, I can configure a list of inclusion tags, so that only EC2 instances with those tags are scanned, or exclusion tags, so that EC2 instances with tags in the list are skipped. Testing Malware Protection GuardDuty Findings To generate several Amazon GuardDuty findings, including the new Malware Protection findings, I clone the Amazon GuardDuty Tester repo: $ git clone https://github.com/awslabs/amazon-guardduty-tester First, I create an AWS CloudFormation stack using the guardduty-tester.template file. When the stack is ready, I follow the instructions to configure my SSH client to log in to the tester instance through the bastion host. Then, I connect to the tester instance: $ ssh tester From the tester instance, I start the guardduty_tester.sh script to generate the findings: $ ./guardduty_tester.sh *********************************************************************** * Test #1 - Internal port scanning * * This simulates internal reconaissance by an internal actor or an * * external actor after an initial compromise. This is considered a * * low priority finding for GuardDuty because its not a clear indicator* * of malicious intent on its own. * *********************************************************************** Starting Nmap 6.40 ( http://nmap.org ) at 2022-05-19 09:36 UTC Nmap scan report for ip-172-16-0-20.us-west-2.compute.internal (172.16.0.20) Host is up (0.00032s latency). Not shown: 997 filtered ports PORT STATE SERVICE 22/tcp open ssh 80/tcp closed http 5050/tcp closed mmcc MAC Address: 06:25:CB:F4:E0:51 (Unknown) Nmap done: 1 IP address (1 host up) scanned in 4.96 seconds ----------------------------------------------------------------------- *********************************************************************** * Test #2 - SSH Brute Force with Compromised Keys * * This simulates an SSH brute force attack on an SSH port that we * * can access from this instance. It uses (phony) compromised keys in * * many subsequent attempts to see if one works. This is a common * * techique where the bad actors will harvest keys from the web in * * places like source code repositories where people accidentally leave* * keys and credentials (This attempt will not actually succeed in * * obtaining access to the target linux instance in this subnet) * *********************************************************************** 2022-05-19 09:36:29 START 2022-05-19 09:36:29 Crowbar v0.4.3-dev 2022-05-19 09:36:29 Trying 172.16.0.20:22 2022-05-19 09:36:33 STOP 2022-05-19 09:36:33 No results found... 2022-05-19 09:36:33 START 2022-05-19 09:36:33 Crowbar v0.4.3-dev 2022-05-19 09:36:33 Trying 172.16.0.20:22 2022-05-19 09:36:37 STOP 2022-05-19 09:36:37 No results found... 2022-05-19 09:36:37 START 2022-05-19 09:36:37 Crowbar v0.4.3-dev 2022-05-19 09:36:37 Trying 172.16.0.20:22 2022-05-19 09:36:41 STOP 2022-05-19 09:36:41 No results found... 2022-05-19 09:36:41 START 2022-05-19 09:36:41 Crowbar v0.4.3-dev 2022-05-19 09:36:41 Trying 172.16.0.20:22 2022-05-19 09:36:45 STOP 2022-05-19 09:36:45 No results found... 2022-05-19 09:36:45 START 2022-05-19 09:36:45 Crowbar v0.4.3-dev 2022-05-19 09:36:45 Trying 172.16.0.20:22 2022-05-19 09:36:48 STOP 2022-05-19 09:36:48 No results found... 2022-05-19 09:36:49 START 2022-05-19 09:36:49 Crowbar v0.4.3-dev 2022-05-19 09:36:49 Trying 172.16.0.20:22 2022-05-19 09:36:52 STOP 2022-05-19 09:36:52 No results found... 2022-05-19 09:36:52 START 2022-05-19 09:36:52 Crowbar v0.4.3-dev 2022-05-19 09:36:52 Trying 172.16.0.20:22 2022-05-19 09:36:56 STOP 2022-05-19 09:36:56 No results found... 2022-05-19 09:36:56 START 2022-05-19 09:36:56 Crowbar v0.4.3-dev 2022-05-19 09:36:56 Trying 172.16.0.20:22 2022-05-19 09:37:00 STOP 2022-05-19 09:37:00 No results found... 2022-05-19 09:37:00 START 2022-05-19 09:37:00 Crowbar v0.4.3-dev 2022-05-19 09:37:00 Trying 172.16.0.20:22 2022-05-19 09:37:04 STOP 2022-05-19 09:37:04 No results found... 2022-05-19 09:37:04 START 2022-05-19 09:37:04 Crowbar v0.4.3-dev 2022-05-19 09:37:04 Trying 172.16.0.20:22 2022-05-19 09:37:08 STOP 2022-05-19 09:37:08 No results found... 2022-05-19 09:37:08 START 2022-05-19 09:37:08 Crowbar v0.4.3-dev 2022-05-19 09:37:08 Trying 172.16.0.20:22 2022-05-19 09:37:12 STOP 2022-05-19 09:37:12 No results found... 2022-05-19 09:37:12 START 2022-05-19 09:37:12 Crowbar v0.4.3-dev 2022-05-19 09:37:12 Trying 172.16.0.20:22 2022-05-19 09:37:16 STOP 2022-05-19 09:37:16 No results found... 2022-05-19 09:37:16 START 2022-05-19 09:37:16 Crowbar v0.4.3-dev 2022-05-19 09:37:16 Trying 172.16.0.20:22 2022-05-19 09:37:20 STOP 2022-05-19 09:37:20 No results found... 2022-05-19 09:37:20 START 2022-05-19 09:37:20 Crowbar v0.4.3-dev 2022-05-19 09:37:20 Trying 172.16.0.20:22 2022-05-19 09:37:23 STOP 2022-05-19 09:37:23 No results found... 2022-05-19 09:37:23 START 2022-05-19 09:37:23 Crowbar v0.4.3-dev 2022-05-19 09:37:23 Trying 172.16.0.20:22 2022-05-19 09:37:27 STOP 2022-05-19 09:37:27 No results found... 2022-05-19 09:37:27 START 2022-05-19 09:37:27 Crowbar v0.4.3-dev 2022-05-19 09:37:27 Trying 172.16.0.20:22 2022-05-19 09:37:31 STOP 2022-05-19 09:37:31 No results found... 2022-05-19 09:37:31 START 2022-05-19 09:37:31 Crowbar v0.4.3-dev 2022-05-19 09:37:31 Trying 172.16.0.20:22 2022-05-19 09:37:34 STOP 2022-05-19 09:37:34 No results found... 2022-05-19 09:37:35 START 2022-05-19 09:37:35 Crowbar v0.4.3-dev 2022-05-19 09:37:35 Trying 172.16.0.20:22 2022-05-19 09:37:38 STOP 2022-05-19 09:37:38 No results found... 2022-05-19 09:37:38 START 2022-05-19 09:37:38 Crowbar v0.4.3-dev 2022-05-19 09:37:38 Trying 172.16.0.20:22 2022-05-19 09:37:42 STOP 2022-05-19 09:37:42 No results found... 2022-05-19 09:37:42 START 2022-05-19 09:37:42 Crowbar v0.4.3-dev 2022-05-19 09:37:42 Trying 172.16.0.20:22 2022-05-19 09:37:46 STOP 2022-05-19 09:37:46 No results found... ----------------------------------------------------------------------- *********************************************************************** * Test #3 - RDP Brute Force with Password List * * This simulates an RDP brute force attack on the internal RDP port * * of the windows server that we installed in the environment. It uses* * a list of common passwords that can be found on the web. This test * * will trigger a detection, but will fail to get into the target * * windows instance. * *********************************************************************** Sending 250 password attempts at the windows server... Hydra v9.4-dev (c) 2022 by van Hauser/THC & David Maciejak - Please do not use in military or secret service organizations, or for illegal purposes (this is non-binding, these *** ignore laws and ethics anyway). Hydra (https://github.com/vanhauser-thc/thc-hydra) starting at 2022-05-19 09:37:46 [WARNING] rdp servers often don't like many connections, use -t 1 or -t 4 to reduce the number of parallel connections and -W 1 or -W 3 to wait between connection to allow the server to recover [INFO] Reduced number of tasks to 4 (rdp does not like many parallel connections) [WARNING] the rdp module is experimental. Please test, report - and if possible, fix. [DATA] max 4 tasks per 1 server, overall 4 tasks, 1792 login tries (l:7/p:256), ~448 tries per task [DATA] attacking rdp://172.16.0.24:3389/ [STATUS] 1099.00 tries/min, 1099 tries in 00:01h, 693 to do in 00:01h, 4 active 1 of 1 target completed, 0 valid password found Hydra (https://github.com/vanhauser-thc/thc-hydra) finished at 2022-05-19 09:39:23 ----------------------------------------------------------------------- *********************************************************************** * Test #4 - CryptoCurrency Mining Activity * * This simulates interaction with a cryptocurrency mining pool which * * can be an indication of an instance compromise. In this case, we are* * only interacting with the URL of the pool, but not downloading * * any files. This will trigger a threat intel based detection. * *********************************************************************** Calling bitcoin wallets to download mining toolkits ----------------------------------------------------------------------- *********************************************************************** * Test #5 - DNS Exfiltration * * A common exfiltration technique is to tunnel data out over DNS * * to a fake domain. Its an effective technique because most hosts * * have outbound DNS ports open. This test wont exfiltrate any data, * * but it will generate enough unusual DNS activity to trigger the * * detection. * *********************************************************************** Calling large numbers of large domains to simulate tunneling via DNS *********************************************************************** * Test #6 - Fake domain to prove that GuardDuty is working * * This is a permanent fake domain that customers can use to prove that* * GuardDuty is working. Calling this domain will always generate the * * Backdoor:EC2/C&CActivity.B!DNS finding type * *********************************************************************** Calling a well known fake domain that is used to generate a known finding ; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.amzn2.5.2 <<>> GuardDutyC2ActivityB.com any ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11495 ;; flags: qr rd ra; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;GuardDutyC2ActivityB.com. IN ANY ;; ANSWER SECTION: GuardDutyC2ActivityB.com. 6943 IN SOA ns1.markmonitor.com. hostmaster.markmonitor.com. 2018091906 86400 3600 2592000 172800 GuardDutyC2ActivityB.com. 6943 IN NS ns3.markmonitor.com. GuardDutyC2ActivityB.com. 6943 IN NS ns5.markmonitor.com. GuardDutyC2ActivityB.com. 6943 IN NS ns7.markmonitor.com. GuardDutyC2ActivityB.com. 6943 IN NS ns2.markmonitor.com. GuardDutyC2ActivityB.com. 6943 IN NS ns4.markmonitor.com. GuardDutyC2ActivityB.com. 6943 IN NS ns6.markmonitor.com. GuardDutyC2ActivityB.com. 6943 IN NS ns1.markmonitor.com. ;; Query time: 27 msec ;; SERVER: 172.16.0.2#53(172.16.0.2) ;; WHEN: Thu May 19 09:39:23 UTC 2022 ;; MSG SIZE rcvd: 238 ***************************************************************************************************** Expected GuardDuty Findings Test 1: Internal Port Scanning Expected Finding: EC2 Instance i-011e73af27562827b is performing outbound port scans against remote host. 172.16.0.20 Finding Type: Recon:EC2/Portscan Test 2: SSH Brute Force with Compromised Keys Expecting two findings - one for the outbound and one for the inbound detection Outbound: i-011e73af27562827b is performing SSH brute force attacks against 172.16.0.20 Inbound: 172.16.0.25 is performing SSH brute force attacks against i-0bada13e0aa12d383 Finding Type: UnauthorizedAccess:EC2/SSHBruteForce Test 3: RDP Brute Force with Password List Expecting two findings - one for the outbound and one for the inbound detection Outbound: i-011e73af27562827b is performing RDP brute force attacks against 172.16.0.24 Inbound: 172.16.0.25 is performing RDP brute force attacks against i-0191573dec3b66924 Finding Type : UnauthorizedAccess:EC2/RDPBruteForce Test 4: Cryptocurrency Activity Expected Finding: EC2 Instance i-011e73af27562827b is querying a domain name that is associated with bitcoin activity Finding Type : CryptoCurrency:EC2/BitcoinTool.B!DNS Test 5: DNS Exfiltration Expected Finding: EC2 instance i-011e73af27562827b is attempting to query domain names that resemble exfiltrated data Finding Type : Trojan:EC2/DNSDataExfiltration Test 6: C&C Activity Expected Finding: EC2 instance i-011e73af27562827b is querying a domain name associated with a known Command & Control server. Finding Type : Backdoor:EC2/C&CActivity.B!DNS After a few minutes, the findings appear in the GuardDuty console. At the top, I see the malicious files found by the new Malware Protection capability. One of the findings is related to an EC2 instance, the other to an ECS cluster. First, I select the finding related to the EC2 instance. In the panel, I see the information on the instance and the malicious file, such as the file name and path. In the Malware scan details section, the Trigger finding ID points to the original GuardDuty finding that triggered the malware scan. In my case, the original finding was that this EC2 instance was performing RDP brute force attacks against another EC2 instance. Here, I choose Investigate with Detective and, directly from the GuardDuty console, I go to the Detective console to visualize AWS CloudTrail and Amazon Virtual Private Cloud (Amazon VPC) flow data for the EC2 instance, the AWS account, and the IP address affected by the finding. Using Detective, I can analyze, investigate, and identify the root cause of suspicious activities found by GuardDuty. When I select the finding related to the ECS cluster, I have more information on the resource affected, such as the details of the ECS cluster, the task, the containers, and the container images. Using the GuardDuty tester scripts makes it easier to test the overall integration of GuardDuty with other security frameworks you use so that you can be ready when a real threat is detected. Comparing GuardDuty Malware Protection with Amazon Inspector At this point, you might ask yourself how GuardDuty Malware Protection relates to Amazon Inspector, a service that scans AWS workloads for software vulnerabilities and unintended network exposure. The two services complement each other and offer different layers of protection: Amazon Inspector offers proactive protection by identifying and remediating known software and application vulnerabilities that serve as an entry point for attackers to compromise resources and install malware. GuardDuty Malware Protection detects malware that is found to be present on actively running workloads. At that point, the system has already been compromised, but GuardDuty can limit the time of an infection and take action before a system compromise results in a business-impacting event. Availability and Pricing Amazon GuardDuty Malware Protection is available today in all AWS Regions where GuardDuty is available, excluding the AWS China (Beijing), AWS China (Ningxia), AWS GovCloud (US-East), and AWS GovCloud (US-West) Regions. At launch, GuardDuty Malware Protection is integrated with these partner offerings: BitDefender CloudHesive Crowdstrike Fortinet Palo Alto Networks Rapid7 Sophos Sysdig Trellix With GuardDuty, you don’t need to deploy security software or agents to monitor for malware. You only pay for the amount of GB scanned in the file systems (not for the size of the EBS volumes) and for the EBS snapshots during the time they are kept in your account. All EBS snapshots created by GuardDuty are automatically deleted after they are scanned unless you enable snapshot retention when malware is found. For more information, see GuardDuty pricing and EBS pricing. Note that GuardDuty only scans EBS volumes less than 1 TB in size. To help you control costs and avoid repeating alarms, the same volume is not scanned more often than once every 24 hours. Detect malicious activity and protect your applications from malware with Amazon GuardDuty. — Danilo View the full article