CreateNetworkAclEntry
CreateNetworkAclEntry
Event
Adds a numbered rule to a network ACL. Rules are evaluated in ascending number order until the first match. The ACL applies to its associated subnets, which may include more than one subnet.
Security Context
An unauthorized allow rule may weaken filtering; an unauthorized deny can also interrupt traffic. Approved network changes are common. A rule at 90 only takes precedence over later matching rules when no earlier rule matches. Network ACLs are stateless, so check both directions and other controls.
T1686.001 applies when the change deliberately impairs cloud firewall controls; the API name alone does not establish malicious intent.
Log Source
CloudTrail management event with eventSource: ec2.amazonaws.com and eventName: CreateNetworkAclEntry. Search regional Event history or retained management-event logs, accounting for collection scope and retention. For APIs supporting dry runs, DryRunOperation reports sufficient permissions without making the change.
Key Fields
| Field | Investigation use |
|---|---|
requestParameters.networkAclId | ACL and associated subnets. |
requestParameters.ruleNumber, requestParameters.egress | Rule order and direction. |
requestParameters.ruleAction, requestParameters.protocol, requestParameters.cidrBlock | Decision and traffic match; inspect port/ICMP fields when relevant. |
userIdentity, eventTime, sourceIPAddress, userAgent | Attribute the request and compare with approved work. |
awsRegion, recipientAccountId | Scope the account and regional context. |
errorCode, errorMessage | Distinguish rejection from an apparent completed request; verify actual state. |
What to Investigate
- Confirm authorization, errors, and dry-run outcome. Verify the stored rule.
- Compare the complete ordered rule list in the affected direction; identify the first match for relevant traffic.
- Identify all associated subnets and evaluate return traffic, security groups, and routing.
- Correlate with DeleteNetworkAclEntry and traffic evidence before assigning a realized exposure.
Sample Event
Synthetic scenario. Draco requests an inbound all-protocol allow at rule 90 for a documentation-only address. Its effect depends on earlier rules, subnet associations, return traffic, and other controls; it is not a demonstrated end-to-end bypass. No top-level error is shown. Exact CloudTrail serialization and optional fields remain unverified by capture. The inherited request/response nesting is illustrative; API transport examples alone do not validate CloudTrail field encoding.
{ "eventVersion": "1.09", "userIdentity": { "type": "IAMUser", "principalId": "AIDADRAC0MALF0YBADGY", "arn": "arn:aws:iam::555123456789:user/draco", "accountId": "555123456789", "accessKeyId": "ASIADRAC0MALF0YEXAMP5", "userName": "draco", "sessionContext": { "attributes": { "creationDate": "2026-04-15T18:51:02Z", "mfaAuthenticated": "false" } } }, "eventTime": "2026-04-15T23:46:09Z", "eventSource": "ec2.amazonaws.com", "eventName": "CreateNetworkAclEntry", "awsRegion": "us-east-1", "sourceIPAddress": "203.0.113.66", "userAgent": "aws-cli/1.18.147 Python/3.7.10 Linux/5.4.0-1045-aws botocore/1.18.6", "requestParameters": { "networkAclId": "acl-0123456789abcdef0", "ruleNumber": 90, "protocol": "-1", "ruleAction": "allow", "egress": false, "cidrBlock": "203.0.113.66/32" }, "responseElements": { "requestId": "90000000-0000-4000-8000-000010010010", "_return": true }, "requestID": "90000000-0000-4000-8000-000010010010", "eventID": "90000000-0000-4000-8000-000010010011", "readOnly": false, "eventType": "AwsApiCall", "managementEvent": true, "recipientAccountId": "555123456789", "eventCategory": "Management", "tlsDetails": { "tlsVersion": "TLSv1.3", "cipherSuite": "TLS_AES_128_GCM_SHA256", "clientProvidedHostHeader": "ec2.us-east-1.amazonaws.com" }}Sources
MITRE ATT&CK Mapping
Tactics: Defense Impairment
- T1686.001 — Cloud Firewall — Adversaries may disable or modify a firewall within a cloud environment to bypass controls that limit access to cloud resources.