SOC Prime Bias: Medium

01 Dec 2025 20:34

AWS GuardDuty Detector Disabled/Suspended – Threat Detection Rule Weekly #11-2025

Author Photo
Ruslan Mikhalov Chief of Threat Research at SOC Prime linkedin icon Follow
AWS GuardDuty Detector Disabled/Suspended – Threat Detection Rule Weekly #11-2025
shield icon

Detection stack

  • AIDR
  • Alert
  • ETL
  • Query

Summary

The blog article outlines a detection rule in AWS GuardDuty Detector designed to alert when a GuardDuty Detector is deleted, disabled, or suspended. It walks through expected administrative, testing, and attacker scenarios, includes a Sigma rule sample, and details how to investigate alerts. The rule centers on AWS CloudTrail records that capture DeleteDetector and UpdateDetector API activity, helping security teams spot attempts to disable GuardDuty Detector visibility.

Analysis

This section advises analysts to inspect CloudTrail entries for DeleteDetector and UpdateDetector GuardDuty ****API calls, verify whether the actions succeeded, identify the IAM user or role that issued them, and correlate their timing with other suspicious events. It further recommends reviewing recent GuardDuty findings generated before the detector change and assessing IAM permissions assigned to the account that performed the operation.

Mitigation

Mitigation guidance includes promptly restoring GuardDuty Detector to an enabled state, hardening IAM policies, empowering only tightly controlled roles to use DeleteDetector and UpdateDetector API calls, leveraging AWS Config to alert on GuardDuty configuration changes, and enforcing formal change management for any legitimate detector removal. Teams should also review automation and scripts to prevent accidental GuardDuty Detector deletion.

Response

When such malicious activity is detected, security teams should confirm whether the request was authorized, immediately re-enable GuardDuty Detector, isolate any potentially compromised resources, inform key stakeholders, and strengthen monitoring plus access controls to reduce the risk of future unauthorized detector changes.

Attack Flow

Simulation Execution

Prerequisite: The Telemetry & Baseline Pre‑flight Check must have passed.

  • Attack Narrative & Commands:

    An adversary who has obtained privileged AWS credentials (e.g., AdministratorAccess) aims to hide malicious activity by removing GuardDuty’s monitoring. The attacker first discovers the existing GuardDuty detector ID, then either deletes the detector outright or updates it to disable. Both actions generate CloudTrail events that match the sigma rule.

  • Regression Test Script:

    #!/usr/bin/env bash
    # =============================================================================
    # Simulation script – T1562.008: Disable/Delete GuardDuty Detector
    # Prerequisites:
    #   - AWS CLI v2 installed and configured with credentials that have GuardDuty admin rights
    #   - jq installed for JSON parsing
    # =============================================================================
    
    set -euo pipefail
    
    REGION="us-east-1"
    
    echo "[*] Discovering GuardDuty detector ID..."
    DETECTOR_ID=$(aws guardduty list-detectors --region "$REGION" --output json | jq -r '.DetectorIds[0]')
    
    if [[ -z "$DETECTOR_ID" || "$DETECTOR_ID" == "null" ]]; then
        echo "[!] No GuardDuty detector found in region $REGION. Exiting."
        exit 1
    fi
    echo "[+] Detector ID: $DETECTOR_ID"
    
    # -------------------------------------------------------------------------
    # Option 1: Delete the detector (produces DeleteDetector event)
    # -------------------------------------------------------------------------
    echo "[*] Deleting GuardDuty detector to simulate T1562.008..."
    aws guardduty delete-detector \
        --detector-id "$DETECTOR_ID" \
        --region "$REGION"
    echo "[+] DeleteDetector call issued."
    
    # -------------------------------------------------------------------------
    # Option 2: Disable the detector (produces UpdateDetector with enable=false)
    # -------------------------------------------------------------------------
    # Uncomment the block below to test the UpdateDetector path instead of Delete.
    #: <<'DISABLE_BLOCK'
    #echo "[*] Disabling GuardDuty detector (alternative path)..."
    #aws guardduty update-detector \
    #    --detector-id "$DETECTOR_ID" \
    #    --region "$REGION" \
    #    --enable false
    #echo "[+] UpdateDetector (enable=false) call issued."
    #: DISABLE_BLOCK
    
    echo "[*] Simulation complete. Verify SIEM alerts for DeleteDetector or UpdateDetector events."
  • Cleanup Commands:

    #!/usr/bin/env bash
    # Re‑create GuardDuty detector (if it was deleted) or re‑enable it (if disabled)
    
    REGION="us-east-1"
    
    # Check if any detectors exist
    EXISTING=$(aws guardduty list-detectors --region "$REGION" --output json | jq -r '.DetectorIds | length')
    
    if [[ "$EXISTING" -eq 0 ]]; then
        echo "[*] No GuardDuty detector found – creating a new one..."
        aws guardduty create-detector --region "$REGION" --enable true
        echo "[+] New GuardDuty detector created and enabled."
    else
        DETECTOR_ID=$(aws guardduty list-detectors --region "$REGION" --output json | jq -r '.DetectorIds[0]')
        echo "[*] Re‑enabling existing detector $DETECTOR_ID..."
        aws guardduty update-detector \
            --detector-id "$DETECTOR_ID" \
            --region "$REGION" \
            --enable true
        echo "[+] Detector $DETECTOR_ID re‑enabled."
    fi