AWS GuardDuty Member Account Manipulation

Detects attempts to disassociate or manipulate Amazon GuardDuty member accounts within an AWS organization. In multi-account GuardDuty deployments, a delegated administrator account aggregates findings from member accounts. Adversaries may attempt to disassociate member accounts, delete member relationships, stop monitoring members, or delete pending invitations to break this centralized visibility. These actions can be precursors to or alternatives for deleting GuardDuty detectors entirely, allowing attackers to operate undetected in member accounts while the administrator account loses visibility. This rule identifies successful API calls that manipulate GuardDuty member relationships, which are rare in normal operations and warrant immediate investigation.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2026/02/05"
  3integration = ["aws"]
  4maturity = "production"
  5updated_date = "2026/02/05"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Detects attempts to disassociate or manipulate Amazon GuardDuty member accounts within an AWS organization. In
 11multi-account GuardDuty deployments, a delegated administrator account aggregates findings from member accounts.
 12Adversaries may attempt to disassociate member accounts, delete member relationships, stop monitoring members, or delete
 13pending invitations to break this centralized visibility. These actions can be precursors to or alternatives for
 14deleting GuardDuty detectors entirely, allowing attackers to operate undetected in member accounts while the
 15administrator account loses visibility. This rule identifies successful API calls that manipulate GuardDuty member
 16relationships, which are rare in normal operations and warrant immediate investigation.
 17"""
 18false_positives = [
 19    """
 20    GuardDuty member relationships may be modified during legitimate organizational changes such as account migrations,
 21    security architecture restructuring, or delegated administrator transitions. Verify whether the user identity and
 22    timing align with approved change management processes. If this is expected administrative activity, it can be
 23    exempted from the rule.
 24    """,
 25]
 26from = "now-6m"
 27index = ["filebeat-*", "logs-aws.cloudtrail-*"]
 28language = "kuery"
 29license = "Elastic License v2"
 30name = "AWS GuardDuty Member Account Manipulation"
 31note = """## Triage and analysis
 32
 33### Investigating AWS GuardDuty Member Account Manipulation
 34
 35In AWS Organizations with GuardDuty enabled, a delegated administrator account receives and aggregates security findings from all member accounts. This centralized visibility is critical for detecting threats across the organization. Adversaries who compromise a member account may attempt to break this relationship to operate without triggering alerts visible to the security team.
 36
 37This rule detects several API actions that manipulate GuardDuty member relationships:
 38- `DisassociateFromMasterAccount` / `DisassociateFromAdministratorAccount`: Member account breaks its connection to the administrator
 39- `DeleteMembers`: Administrator removes member accounts from GuardDuty
 40- `StopMonitoringMembers`: Administrator stops monitoring specific member accounts without fully removing them
 41- `DeleteInvitations`: Member account deletes pending invitations, preventing association
 42
 43These actions are extremely rare in normal operations and can indicate either a compromised account or an attacker preparing to disable GuardDuty entirely.
 44
 45### Possible investigation steps
 46
 47- **Identify the actor**
 48  - Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.type` to determine who performed the action.
 49  - Determine whether the action originated from a member account (disassociation) or the administrator account (deletion/stop monitoring).
 50
 51- **Review request context**
 52  - Check `aws.cloudtrail.request_parameters` to identify which member accounts were affected.
 53  - Determine the scope: single account or multiple accounts targeted.
 54
 55- **Analyze source and access patterns**
 56  - Review `source.ip` and `user_agent.original` for anomalous access patterns.
 57  - Check if the action occurred outside normal business hours or maintenance windows.
 58
 59- **Correlate with related activity**
 60  - Search for subsequent `DeleteDetector` API calls in the affected member accounts.
 61  - Look for other defense evasion indicators: CloudTrail modifications, Config rule deletions, Security Hub changes.
 62  - Check for privilege escalation or credential access events preceding this action.
 63
 64- **Verify business justification**
 65  - Confirm with the identified user or team whether there was a legitimate organizational change.
 66  - Check for related change tickets or migration documentation.
 67
 68### False positive analysis
 69
 70- **Organizational restructuring**
 71  - Member relationships may change during account migrations or delegated administrator transitions.
 72  - Validate against documented organizational changes.
 73
 74- **Account decommissioning**
 75  - Accounts being retired may be removed from GuardDuty before closure.
 76  - Confirm this aligns with account lifecycle management processes.
 77
 78### Response and remediation
 79
 80- **Immediate containment**
 81  - If unauthorized, immediately re-associate the affected member accounts with the administrator.
 82  - For `StopMonitoringMembers`, use `StartMonitoringMembers` to restore visibility.
 83
 84- **Investigation**
 85  - Audit the affected member accounts for suspicious activity during the visibility gap.
 86  - Review CloudTrail for any actions taken while GuardDuty monitoring was disrupted.
 87
 88- **Hardening**
 89  - Restrict `guardduty:DisassociateFromAdministratorAccount`, `guardduty:DeleteMembers`, and related permissions.
 90  - Use SCPs to prevent member accounts from disassociating from GuardDuty administrators.
 91  - Implement Security Hub controls to detect changes to GuardDuty organization configuration.
 92
 93### Additional information
 94- **[AWS GuardDuty Multi-Account Documentation](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_accounts.html)**
 95- **[AWS IR Playbooks](https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/)**
 96- **[AWS Customer Playbook Framework](https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs)**
 97"""
 98references = [
 99    "https://docs.aws.amazon.com/guardduty/latest/APIReference/API_DisassociateFromAdministratorAccount.html",
100    "https://docs.aws.amazon.com/guardduty/latest/APIReference/API_DeleteMembers.html",
101    "https://docs.aws.amazon.com/guardduty/latest/APIReference/API_StopMonitoringMembers.html",
102    "https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_accounts.html",
103    "https://permiso.io/blog/lucr-3-scattered-spider-getting-saas-y-in-the-cloud",
104]
105risk_score = 47
106rule_id = "3c59d2e1-8ca1-4f13-b2ac-f4bb99ff69d7"
107severity = "medium"
108tags = [
109    "Domain: Cloud",
110    "Data Source: AWS",
111    "Data Source: Amazon Web Services",
112    "Data Source: AWS GuardDuty",
113    "Tactic: Defense Evasion",
114    "Resources: Investigation Guide",
115]
116timestamp_override = "event.ingested"
117type = "query"
118
119query = '''
120event.dataset: "aws.cloudtrail"
121    and event.provider: "guardduty.amazonaws.com"
122    and event.action: (
123        "DisassociateFromAdministratorAccount" or
124        "DeleteMembers" or
125        "StopMonitoringMembers" or
126        "DeleteInvitations" or
127        "DisassociateMembers"
128    )
129    and event.outcome: "success"
130'''
131
132
133[[rule.threat]]
134framework = "MITRE ATT&CK"
135[[rule.threat.technique]]
136id = "T1562"
137name = "Impair Defenses"
138reference = "https://attack.mitre.org/techniques/T1562/"
139[[rule.threat.technique.subtechnique]]
140id = "T1562.001"
141name = "Disable or Modify Tools"
142reference = "https://attack.mitre.org/techniques/T1562/001/"
143
144
145
146[rule.threat.tactic]
147id = "TA0005"
148name = "Defense Evasion"
149reference = "https://attack.mitre.org/tactics/TA0005/"
150
151[rule.investigation_fields]
152field_names = [
153    "@timestamp",
154    "user.name",
155    "user_agent.original",
156    "source.ip",
157    "aws.cloudtrail.user_identity.arn",
158    "aws.cloudtrail.user_identity.type",
159    "aws.cloudtrail.user_identity.access_key_id",
160    "event.action",
161    "event.outcome",
162    "cloud.account.id",
163    "cloud.region",
164    "aws.cloudtrail.request_parameters",
165    "aws.cloudtrail.response_elements",
166]

Triage and analysis

Investigating AWS GuardDuty Member Account Manipulation

In AWS Organizations with GuardDuty enabled, a delegated administrator account receives and aggregates security findings from all member accounts. This centralized visibility is critical for detecting threats across the organization. Adversaries who compromise a member account may attempt to break this relationship to operate without triggering alerts visible to the security team.

This rule detects several API actions that manipulate GuardDuty member relationships:

  • DisassociateFromMasterAccount / DisassociateFromAdministratorAccount: Member account breaks its connection to the administrator
  • DeleteMembers: Administrator removes member accounts from GuardDuty
  • StopMonitoringMembers: Administrator stops monitoring specific member accounts without fully removing them
  • DeleteInvitations: Member account deletes pending invitations, preventing association

These actions are extremely rare in normal operations and can indicate either a compromised account or an attacker preparing to disable GuardDuty entirely.

Possible investigation steps

  • Identify the actor

    • Review aws.cloudtrail.user_identity.arn and aws.cloudtrail.user_identity.type to determine who performed the action.
    • Determine whether the action originated from a member account (disassociation) or the administrator account (deletion/stop monitoring).
  • Review request context

    • Check aws.cloudtrail.request_parameters to identify which member accounts were affected.
    • Determine the scope: single account or multiple accounts targeted.
  • Analyze source and access patterns

    • Review source.ip and user_agent.original for anomalous access patterns.
    • Check if the action occurred outside normal business hours or maintenance windows.
  • Correlate with related activity

    • Search for subsequent DeleteDetector API calls in the affected member accounts.
    • Look for other defense evasion indicators: CloudTrail modifications, Config rule deletions, Security Hub changes.
    • Check for privilege escalation or credential access events preceding this action.
  • Verify business justification

    • Confirm with the identified user or team whether there was a legitimate organizational change.
    • Check for related change tickets or migration documentation.

False positive analysis

  • Organizational restructuring

    • Member relationships may change during account migrations or delegated administrator transitions.
    • Validate against documented organizational changes.
  • Account decommissioning

    • Accounts being retired may be removed from GuardDuty before closure.
    • Confirm this aligns with account lifecycle management processes.

Response and remediation

  • Immediate containment

    • If unauthorized, immediately re-associate the affected member accounts with the administrator.
    • For StopMonitoringMembers, use StartMonitoringMembers to restore visibility.
  • Investigation

    • Audit the affected member accounts for suspicious activity during the visibility gap.
    • Review CloudTrail for any actions taken while GuardDuty monitoring was disrupted.
  • Hardening

    • Restrict guardduty:DisassociateFromAdministratorAccount, guardduty:DeleteMembers, and related permissions.
    • Use SCPs to prevent member accounts from disassociating from GuardDuty administrators.
    • Implement Security Hub controls to detect changes to GuardDuty organization configuration.

Additional information

References

Related rules

to-top