[New Rule] AWS S3 Bucket MFA Delete Disabled

[bryans3c]

Pull Request

Issue link(s):

• https://github.com/elastic/ia-trade-team/issues/1066

Summary - What I changed

Added a rule that fires when MFA Delete is disabled on an S3 bucket via PutBucketVersioning with MfaDelete=Disabled. Also adds aws.cloudtrail.flattened.request_parameters.VersioningConfiguration.MfaDelete to the non-ECS schema to enable the flattened field query.

Why it matters

MFA Delete protects versioned S3 buckets by requiring MFA authentication to permanently delete object versions — the primary defense against ransomware destroying version history after encrypting current object copies. Disabling MFA Delete removes this safeguard and is a recognized ransomware preparation step documented in S3 ransomware research. Critically, only the AWS root account can enable or disable MFA Delete; a PutBucketVersioning call disabling it from a non-root identity is itself a strong indicator of root credential compromise or unauthorized use.

• https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/
• https://www.halcyon.ai/blog/abusing-aws-native-services-ransomware-encrypting-s3-buckets-with-sse-c

How To Test

Query to verify in our TRaDE stack:

data_stream.dataset: "aws.cloudtrail"
    and event.provider: "s3.amazonaws.com"
    and event.action: "PutBucketVersioning"
    and event.outcome: "success"
    and aws.cloudtrail.flattened.request_parameters.VersioningConfiguration.MfaDelete: "Disabled"

Checklist

• Added a label for the type of pr: Rule: New
• Secret and sensitive material has been managed correctly
• Automated testing was updated or added to match the most common scenarios
• Documentation and comments were added for features that require explanation

Contributor checklist

• Have you signed the contributor license agreement?
• Have you followed the contributor guidelines?

[Copilot]

Pull request overview

Adds a new AWS CloudTrail detection rule to alert when an S3 bucket’s MFA Delete protection is disabled via PutBucketVersioning, and updates the non-ECS schema so the rule’s flattened request-parameter field is recognized by repo validation.

Changes:

• Added a new KQL (Kuery) rule: AWS S3 Bucket MFA Delete Disabled with investigation guidance and ATT&CK Impact mapping.
• Extended non-ecs-schema.json to include aws.cloudtrail.flattened.request_parameters.mfaDeleteEnabled.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
rules/integrations/aws/defense_evasion_s3_mfa_delete_disabled.toml	New CloudTrail-based rule for detecting MFA Delete being disabled on S3 buckets.
detection_rules/etc/non-ecs-schema.json	Adds the flattened CloudTrail request parameter field used by the new rule to the non-ECS schema.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[github-actions]

Rule: New - Guidelines

These guidelines serve as a reminder set of considerations when proposing a new rule.

Documentation and Context

• Detailed description of the rule.
• List any new fields required in ECS/data sources.
• Link related issues or PRs.
• Include references.

Rule Metadata Checks

• creation_date matches the date of creation PR initially merged.
• min_stack_version should support the widest stack versions.
• name and description should be descriptive and not include typos.
• query should be inclusive, not overly exclusive, considering performance for diverse environments. Non ecs fields should be added to non-ecs-schema.json if not available in an integration.
• min_stack_comments and min_stack_version should be included if the rule is only compatible starting from a specific stack version.
• index pattern should be neither too specific nor too vague, ensuring it accurately matches the relevant data stream (e.g., use logs-endpoint.process-* for process data).
• integration should align with the index. If the integration is newly introduced, ensure the manifest, schemas, and new_rule.yaml template are updated.
• setup should include the necessary steps to configure the integration.
• note should include any additional information (e.g. Triage and analysis investigation guides, timeline templates).
• tags should be relevant to the threat and align/added to the EXPECTED_RULE_TAGS in the definitions.py file.
• threat, techniques, and subtechniques should map to ATT&CK always if possible.

New BBR Rules

• building_block_type should be included if the rule is a building block and the rule should be located in the rules_building_block folder.
• bypass_bbr_timing should be included if adding custom lookback timing to the rule.

Testing and Validation

• Provide evidence of testing and detecting the expected threat.
• Check for existence of coverage to prevent duplication.

[imays11]

Any test data for this one?

[terrancedejesus]

LGTM. Nits on the default interval and swapping the emdash in the description for a comma.

[bryans3c]

Any test data for this one?

You can check again in the TRaDE stack @imays11 :)

[imays11]

Ran the query in telemetry and it looks good!