« AWS S3 Bucket ACL Modified to Allow Public Access by New Identity AWS IAM Permission Boundary or Guardrail Policy Deleted by Unusual Identity »
Elastic Docs ›Elastic Security [8.19] ›Downloadable rule update v8.19.29

AWS EC2 NACL Entry Created or Replaced Allowing All Traffic by New Identity

edit
IMPORTANT: This documentation is no longer updated. Refer to Elastic's version policy and the latest documentation.

AWS EC2 NACL Entry Created or Replaced Allowing All Traffic by New Identity

edit

Detects a principal account creating or replacing - or attempts to create or replace - an AWS Network Access Control List (NACL) entry using protocol -1 (all traffic). Both successful and failed outcomes are included. A NACL entry with protocol -1 passes all traffic regardless of port, which would disable network-layer controls for the affected subnets. Monitoring for new identities performing this change helps surface freshly compromised credentials or unauthorized principals removing a defense-in-depth layer to facilitate lateral movement or data exfiltration. This signal only flags if this behavior was not observed historically in a specific time window.

Rule type: new_terms

Rule indices:

  • logs-aws.cloudtrail-*

Severity: medium

Risk score: 47

Runs every: 5m

Searches indices from: now-6m (Date Math format, see also Additional look-back time)

Maximum alerts per execution: 100

References:

Tags:

  • Domain: Cloud
  • Data Source: AWS
  • Data Source: Amazon Web Services
  • Data Source: AWS EC2
  • Use Case: Threat Detection
  • Tactic: Defense Evasion
  • Resources: Investigation Guide

Version: 1

Rule authors:

  • Elastic

Rule license: Elastic License v2

Investigation guide

edit

Triage and analysis

Investigating AWS EC2 NACL Entry Created or Replaced Allowing All Traffic by New Identity

This rule fires when a NACL entry specifying all ports (0–65535) and all protocols is created or replaced. While NACLs are stateless and secondary to security groups, a permissive NACL entry can neutralize a defense-in-depth layer and may indicate an adversary attempting to ensure unrestricted connectivity for their tools or exfiltration channels.

Possible investigation steps

  • Identify the creating principal (aws.cloudtrail.user_identity.arn) and determine whether they are authorized to modify network ACLs.
  • Review aws.cloudtrail.request_parameters to identify the NACL ID, rule number, egress/ingress direction, and CIDR block (0.0.0.0/0 for any-source rules are highest severity).
  • Determine which subnets are associated with the modified NACL and assess the sensitivity of workloads in those subnets.
  • Check for accompanying security group modifications that also expand access.
  • Review VPC flow logs for unusual traffic to or from the affected subnets following the NACL change.
  • Review event.outcome — success means the permissive entry was applied and the subnet’s network-layer controls are weakened now; failure means the change was blocked, which from a new identity often indicates credential probing or permission reconnaissance.

False positive analysis

  • Architectures that use NACLs as a stateless passthrough while relying on security groups for granular control may legitimately create permissive NACL entries.
  • Development environments sometimes use open NACLs for convenience.

Response and remediation

  • If unauthorized, immediately delete the permissive NACL entry and replace it with an appropriately restrictive rule.
  • Review VPC flow logs for evidence of network activity that exploited the open rule.

Setup

edit

The AWS CloudTrail integration must be enabled and configured to collect EC2 management events.

Rule query

edit
data_stream.dataset: "aws.cloudtrail"
    and event.provider: "ec2.amazonaws.com"
    and event.action: ("CreateNetworkAclEntry" or "ReplaceNetworkAclEntry")
    and not aws.cloudtrail.user_identity.type: "AWSService"
    and event.outcome: ("success" or "failure")
    and aws.cloudtrail.flattened.request_parameters.aclProtocol: "-1"
    and aws.cloudtrail.flattened.request_parameters.ruleAction: "allow"
    and not user_agent.original: (*Terraform* or *terraform* or "cloudformation.amazonaws.com" or *pulumi* or *Pulumi*)

Framework: MITRE ATT&CKTM

« AWS S3 Bucket ACL Modified to Allow Public Access by New Identity AWS IAM Permission Boundary or Guardrail Policy Deleted by Unusual Identity »