GuardDuty for threat detection in AWS - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

How does AWS GuardDuty detect threats?

AWS GuardDuty analyzes data from various sources to detect threats. Which data source is NOT used by GuardDuty for threat detection?

A VPC Flow Logs

B AWS CloudTrail event logs

C DNS logs

D Amazon S3 bucket contents

💡 Hint

Think about what GuardDuty monitors automatically without needing to scan stored files.

GuardDuty uses network flow logs, CloudTrail logs, and DNS logs to detect suspicious activity. It does not scan the contents of S3 buckets directly.

❓ service_behavior

intermediate

GuardDuty finding behavior on EC2 instance compromise

Which GuardDuty finding type would most likely indicate that an EC2 instance is compromised and communicating with a known malicious IP?

A Recon:EC2/PortProbeUnprotectedPort

B Backdoor:EC2/C&CActivity

C UnauthorizedAccess:EC2/SSHBruteForce

D CryptoCurrency:EC2/BitcoinTool

💡 Hint

Look for findings that indicate command and control activity.

Backdoor:EC2/C&CActivity indicates that an EC2 instance is communicating with a command and control server, which is a strong sign of compromise.

❓ Architecture

advanced

GuardDuty multi-account architecture

You want to enable GuardDuty across multiple AWS accounts in your organization. What is the recommended architecture to centralize threat findings?

A Use AWS Organizations to designate a GuardDuty master account to manage findings from member accounts.

B Enable GuardDuty independently in each account without a master account.

C Deploy GuardDuty only in the root account and rely on CloudTrail aggregation for others.

D Use AWS Config rules to forward GuardDuty findings to a central S3 bucket.

💡 Hint

Think about how AWS Organizations integrates with GuardDuty for centralized management.

GuardDuty supports a master-member model using AWS Organizations, allowing centralized management and viewing of findings across accounts.

❓ security

advanced

GuardDuty finding suppression and security best practice

You receive frequent GuardDuty findings for a known benign IP address communicating with your environment. What is the best security practice to handle these findings?

A Add the IP address to a trusted IP list in GuardDuty to reduce false positives.

B Disable GuardDuty to stop receiving these findings.

C Create a suppression rule in GuardDuty to ignore findings from that IP.

D Investigate and whitelist the IP address in your firewall to prevent alerts.

💡 Hint

Consider how to reduce noise without disabling threat detection.

GuardDuty allows suppression rules to ignore specific findings temporarily or permanently, reducing noise while maintaining overall security monitoring.

❓ Configuration

expert

GuardDuty finding JSON analysis

Given this GuardDuty finding snippet, what is the value of service.action.actionType?

{
  "service": {
    "action": {
      "actionType": "NETWORK_CONNECTION",
      "networkConnectionAction": {
        "remoteIpDetails": {
          "ipAddressV4": "203.0.113.25",
          "organization": {
            "asn": 12345,
            "asnOrg": "ExampleOrg"
          }
        },
        "protocol": "TCP",
        "localPortDetails": {
          "port": 443
        },
        "remotePortDetails": {
          "port": 8080
        }
      }
    }
  }
}

A "NETWORK_CONNECTION"

B "DNS_REQUEST"

C "PORT_PROBE"

D "API_CALL"

💡 Hint

Look carefully at the JSON key actionType inside service.action.

The JSON shows "actionType": "NETWORK_CONNECTION", indicating the type of action detected by GuardDuty.