Blocking Traffic Manipulation in AWS Starts With IAM
None
<h2 class="wp-block-heading">Tl;DR</h2><ul class="wp-block-list"> <li><strong>Cloud networking is a fragile, high-value target</strong> – DNS and traffic routing incidents can quickly cascade and disrupt dependent services.</li> <li><strong>Over-privileged IAM identities enable traffic hijacking</strong> – Permissions across Route53, API Gateway, ELB, CloudFront, and Lightsail can be abused to redirect traffic, break services, and exfiltrate data.</li> <li><strong>Real-world impact is severe </strong>– Misused networking privileges can cause outages, steal sensitive traffic, and redirect users to malicious infrastructure.</li> <li><strong>Visibility is helpful, but enforcement is required </strong>– CNAPPs and first-party cloud tools identify issues but don’t prevent misuse. Cloud-native least-privilege enforcement at scale is required to prevent traffic-hijacking attacks.</li> </ul><h2 class="wp-block-heading"><a></a>Networking in the Cloud</h2><p>Without domain name resolution and effective traffic routing, the cloud breaks. This proved true last month, when a <a href="https://health.aws.amazon.com/health/status?eventID=arn:aws:health:us-east-1::event/MULTIPLE_SERVICES/AWS_MULTIPLE_SERVICES_OPERATIONAL_ISSUE/AWS_MULTIPLE_SERVICES_OPERATIONAL_ISSUE_BA540_514A652BE1A">DNS issue</a> affecting the AWS us-east-1 DynamoDB API endpoint disrupted operations <a href="https://www.ookla.com/articles/aws-outage-q4-2025">at thousands of companies</a>. While certainly an extreme example, it highlights how quickly a single networking issue can cascade, taking down even only tangentially related services.</p><p>While not many companies hosting infrastructure in AWS operate at the scale of Amazon, many do offer services that rely on the same technology. Domain names need to be resolved. Traffic to API endpoints need to be routed to the right infrastructure. Today, AWS customers can manage their domains, configure load balancing for their cloud-hosted services, and consolidate their APIs all within the various AWS networking services.</p><div class="code-block code-block-13" style="margin: 8px 0; clear: both;"> <style> .ai-rotate {position: relative;} .ai-rotate-hidden {visibility: hidden;} .ai-rotate-hidden-2 {position: absolute; top: 0; left: 0; width: 100%; height: 100%;} .ai-list-data, .ai-ip-data, .ai-filter-check, .ai-fallback, .ai-list-block, .ai-list-block-ip, .ai-list-block-filter {visibility: hidden; position: absolute; width: 50%; height: 1px; top: -1000px; z-index: -9999; margin: 0px!important;} .ai-list-data, .ai-ip-data, .ai-filter-check, .ai-fallback {min-width: 1px;} </style> <div class="ai-rotate ai-unprocessed ai-timed-rotation ai-13-1" data-info="WyIxMy0xIiwxXQ==" style="position: relative;"> <div class="ai-rotate-option" style="visibility: hidden;" data-index="1" data-name="U2hvcnQ=" data-time="MTA="> <div class="custom-ad"> <div style="margin: auto; text-align: center;"><a href="https://www.techstrongevents.com/cruisecon-virtual-west-2025/home?ref=in-article-ad-2&utm_source=sb&utm_medium=referral&utm_campaign=in-article-ad-2" target="_blank"><img src="https://securityboulevard.com/wp-content/uploads/2025/10/Banner-770x330-social-1.png" alt="Cruise Con 2025"></a></div> <div class="clear-custom-ad"></div> </div></div> </div> </div><p>Due to its critical nature, this AWS-hosted network fabric can be an enticing target for bad actors when they obtain compromised cloud credentials. It’s not <em>just</em> the potential for disruptive impact behind this either. With access to DNS records and routing rules, attackers can:</p><ul class="wp-block-list"> <li>Intercept, collect, and exfiltrate data</li> <li>Impersonate services</li> <li>Redirect users to malicious infrastructure</li> </ul><h3 class="wp-block-heading"><a></a>Why Privilege Matters</h3><p>While networks are the mechanism by which data passes to cloud-hosted resources, <em>identity</em> is the mechanism by which those resources are configured. Anyone with AWS credentials and the right Identity and Access Management (IAM) permissions can directly tap into the DNS and traffic routing services to modify the logic that underpins how traffic is routed in a given cloud environment.</p><p>In order to prevent service disruptions and malicious traffic redirection, it’s therefore critical that access to IAM permissions related to DNS and traffic routing be strictly controlled.</p><h2 class="wp-block-heading"><a></a>Privileged AWS Permissions for Traffic Manipulation</h2><p>Many AWS services deal with domain name resolution or traffic redirection. Domains can be managed through services like Route53 and Lightsail, while Elastic Load Balancing and API Gateways can be used to redirect inbound traffic to backend resources.</p><p>Many permissions across these various services can be leveraged to alter the flow of traffic, including the following:</p><figure class="wp-block-table"> <table class="has-fixed-layout"> <tbody> <tr> <td><strong>Permission</strong></td> <td><strong>Privilege Granted</strong></td> <td><strong>How Attackers Abuse It</strong></td> </tr> <tr> <td>apigateway:PATCH</td> <td>Can alter API Gateway resources</td> <td>This permission controls access to <a href="https://docs.aws.amazon.com/apigateway/latest/api/patch-operations.html">a large number of API Gateway actions</a>. Attackers can use it to update how requests to API endpoints are handled. For example, the <a href="https://docs.aws.amazon.com/apigateway/latest/developerguide/how-to-integration-settings.html">integration</a> for an API method can be redirected to an attacker-controlled URL using the <a href="https://docs.aws.amazon.com/apigateway/latest/api/API_UpdateIntegration.html">UpdateIntegration</a> action. Alternatively, API methods can be altered to return various static HTTP error codes rather than forwarding the traffic to its intended destination, leading to service outages.</td> </tr> <tr> <td>cloudfront:UpdateDomainAssociation</td> <td>Can alter which domains map to which cloudfront tenants</td> <td>This permission is used to remap a domain from one tenant to another in a multi-tenant CloudFront distribution. Traffic to the domain would then be routed to the newly associated tenant rather than the previous one, compromising tenant isolation.</td> </tr> <tr> <td>elasticloadbalancing:CreateRule elasticloadbalancing:ModifyRule</td> <td>Can alter the rules that govern elastic load balancer traffic routing</td> <td>Elastic Load Balancers use <a href="https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-listeners.html">listeners</a> to receive traffic, which are configured with rules detailing how exactly to route requests. Attackers can use either of these ELB permissions to reconfigure listener rules, having them direct traffic to arbitrary attacker-controlled URLs rather than their intended destinations. Alternatively, listener rules can be altered to return various HTTP error codes rather than their intended responses, leading to service outages.</td> </tr> <tr> <td>lightsail:CreateDomainEntry lightsail:UpdateDomainEntry</td> <td>Can alter DNS records stored in Lightsail DNS zones</td> <td>When a Lightsail DNS Zone is being used to manage records for a given domain, these permissions can be used to map the domain to attacker-controlled infrastructure through the creation or modification of arbitrary DNS records.</td> </tr> <tr> <td>route53:ChangeResourceRecordSets</td> <td>Can alter DNS records for a Route53 domain</td> <td>This permission can be used to map a Route53-managed domain to attacker-controlled infrastructure through the creation or modification of arbitrary DNS records.</td> </tr> </tbody> </table> </figure><p>This list is by no means exhaustive. Plenty of other behavior falls into this category – as broad as manipulating security groups to deny all traffic for disruptive impact, or as specific as tailoring individual VPC route table routes to subtly redirect traffic for a specific VM.</p><h3 class="wp-block-heading"><a></a>Real-World Impact</h3><ul class="wp-block-list"> <li><strong>Service Disruption: </strong>Modification of DNS records, redirection of traffic, and weaponized use of static error messages can kill traffic to core infrastructure – taking cloud-hosted offerings offline until the network infrastructure is repaired.</li> <li><strong>Data Interception & Theft: </strong>Traffic intended for internal servers can be redirected to attacker-controlled infrastructure.</li> <li><strong>Downstream attacks against end-users: </strong>When attempting to access a web application or site underpinned by a maliciously altered load balancer or API gateway, end users could be redirected to phishing pages.</li> </ul><h2 class="wp-block-heading"><a></a>Mitigation</h2><h3 class="wp-block-heading"><a></a>Visibility Tools Fall Short</h3><p>There are several categories of visibility tools that <em>can</em> effectively highlight risks associated with these permissions.</p><p><strong>Cloud-Native Application Protection Platforms (CNAPPs)</strong> are valuable for identifying misconfigurations, scanning vulnerabilities, and mapping compliance risks. However, <em>many</em> identities are overprivileged by default, and remediating tickets for over-provisioned DNS and traffic management permissions across thousands of identities isn’t practical. Moreover, CNAPPs won’t prevent misuse if an attacker gains valid credentials.</p><p><strong>First-Party Cloud-Native Tools </strong>like Access Analyzer and IAM Access Advisor are also effective in highlighting which identities have access to which permissions, and to what degree they are used. This can be useful when manually tailoring IAM policies, but often there are just too many over-privileged identities for this to be an effective long-term solution. And like with CNAPPs, visibility into unused privilege doesn’t translate into actual enforcement. They won’t stop an attack.</p><h3 class="wp-block-heading"><a></a>SCPs Work, But the Barrier to Entry is High</h3><p><strong>Service Control Policies (SCPs)</strong> can be used to centrally restrict access to highly-privileged permissions. By flipping the model to deny-by-default and only managing the <em>exceptions</em>, organizations can stop attacks by reducing the spread of permissions required to conduct them. The same can be said for Resource Control Policies (RCPs).</p><p>The problem is that removing permissions at scale in this manner is a daunting task. It comes with several risks:</p><ul class="wp-block-list"> <li>Critical workflows can go down silently if required permissions are unintentionally denied</li> <li>Breakglass accounts might not be able to perform recovery operations in emergencies if denied the required permissions</li> <li>Developer efficiency goes down when they repeatedly have to ask for more and more permissions that are being denied by centralized permission restrictions they cannot control</li> </ul><h3 class="wp-block-heading"><a></a>The Solution: Cloud-Native Privilege Controls</h3><p>To get a handle on the privileged permissions enabling DNS- and Traffic Manipulation-focused attacks in AWS, organizations need <strong>controls built specifically for cloud IAM.</strong> This includes</p><ul class="wp-block-list"> <li><strong>Continuous discovery</strong> of privileged permissions across users, roles, and services.</li> <li><strong>Least privilege enforcement at scale</strong> to reduce the attack surface.</li> <li><strong>Just-in-Time access</strong> that grants privileged permissions only when needed and revokes them automatically to limit exposure.</li> </ul><p>This is the evolution of Privileged Access Management:<strong> Cloud PAM</strong>, purpose-built for granular IAM permissions and API-driven abuse.</p><p>Without deep visibility, actual enforcement of controls, and an easy-to-use Just-in-Time access flow, tools meant to secure access to cloud networking resources will either remain ineffective or unused.</p><p><em>Interested in learning how Sonrai Security addresses this gap? Contact us to see how we protect against DNS hijacks by controlling AWS privileged permissions.</em></p><h2 class="wp-block-heading"><a></a>FAQ Section</h2><p><strong>Q: Why is cloud networking such a critical attack surface?</strong></p><p>A: Cloud networking underpins how services communicate. If DNS or traffic routing is compromised, it can cascade and take down dependent systems as seen in the recent AWS us-east-1 disruption.</p><p><strong>Q: How can attackers exploit DNS or routing configurations in AWS?</strong></p><p>A: They can steal or misuse IAM credentials and then use AWS’s own APIs to modify DNS records or alter traffic routes.</p><p><strong>Q: Why can’t AWS’s built-in tools like Access Analyzer stop IAM-based traffic hijacking?</strong></p><p>A: They only provide <em>visibility</em> into permissions. This is a good starting point, but these tools don’t <em>enforce</em> least privilege or block malicious API calls.</p><p><strong>Q: My CNAPP already scans my AWS environment. Why isn’t that enough?</strong></p><p>A: CNAPPs surface misconfigurations and vulnerabilities but don’t monitor for active abuse of valid credentials. If an attacker logs in with real credentials, CNAPPs won’t stop them.</p><p><strong>Q: What’s the best defense against IAM-based traffic hijacking in AWS right now?</strong></p><p>A: Continuous privilege discovery, policy-based enforcement, and denial of risky API calls. That’s what cloud PAM should provide.</p><p><strong>Q: Is Cloud PAM the same as Zero Trust in the cloud?</strong></p><p>A: They overlap. Zero Trust is the principle of never trusting by default. Cloud PAM operationalizes that in AWS by enforcing least privilege and Just-in-Time access for machine identities and APIs.</p><figure class="wp-block-image size-full"><a href="https://sonraisecurity.com/cloud-security-platform/cloud-permissions-firewall/"><img fetchpriority="high" decoding="async" width="1584" height="365" src="https://sonraisecurity.com/wp-content/uploads/ad-blog-sensitive-permissions.png" alt="secure sensitive permissions" class="wp-image-28438"></a></figure><div class="spu-placeholder" style="display:none"></div><div class="addtoany_share_save_container addtoany_content addtoany_content_bottom"><div class="a2a_kit a2a_kit_size_20 addtoany_list" data-a2a-url="https://securityboulevard.com/2025/11/blocking-traffic-manipulation-in-aws-starts-with-iam/" data-a2a-title="Blocking Traffic Manipulation in AWS Starts With IAM"><a class="a2a_button_twitter" href="https://www.addtoany.com/add_to/twitter?linkurl=https%3A%2F%2Fsecurityboulevard.com%2F2025%2F11%2Fblocking-traffic-manipulation-in-aws-starts-with-iam%2F&linkname=Blocking%20Traffic%20Manipulation%20in%20AWS%20Starts%20With%20IAM" title="Twitter" rel="nofollow noopener" target="_blank"></a><a class="a2a_button_linkedin" href="https://www.addtoany.com/add_to/linkedin?linkurl=https%3A%2F%2Fsecurityboulevard.com%2F2025%2F11%2Fblocking-traffic-manipulation-in-aws-starts-with-iam%2F&linkname=Blocking%20Traffic%20Manipulation%20in%20AWS%20Starts%20With%20IAM" title="LinkedIn" rel="nofollow noopener" target="_blank"></a><a class="a2a_button_facebook" href="https://www.addtoany.com/add_to/facebook?linkurl=https%3A%2F%2Fsecurityboulevard.com%2F2025%2F11%2Fblocking-traffic-manipulation-in-aws-starts-with-iam%2F&linkname=Blocking%20Traffic%20Manipulation%20in%20AWS%20Starts%20With%20IAM" title="Facebook" rel="nofollow noopener" target="_blank"></a><a class="a2a_button_reddit" href="https://www.addtoany.com/add_to/reddit?linkurl=https%3A%2F%2Fsecurityboulevard.com%2F2025%2F11%2Fblocking-traffic-manipulation-in-aws-starts-with-iam%2F&linkname=Blocking%20Traffic%20Manipulation%20in%20AWS%20Starts%20With%20IAM" title="Reddit" rel="nofollow noopener" target="_blank"></a><a class="a2a_button_email" href="https://www.addtoany.com/add_to/email?linkurl=https%3A%2F%2Fsecurityboulevard.com%2F2025%2F11%2Fblocking-traffic-manipulation-in-aws-starts-with-iam%2F&linkname=Blocking%20Traffic%20Manipulation%20in%20AWS%20Starts%20With%20IAM" title="Email" rel="nofollow noopener" target="_blank"></a><a class="a2a_dd addtoany_share_save addtoany_share" href="https://www.addtoany.com/share"></a></div></div><p class="syndicated-attribution">*** This is a Security Bloggers Network syndicated blog from <a href="https://sonraisecurity.com/">Sonrai | Enterprise Cloud Security Platform</a> authored by <a href="https://securityboulevard.com/author/0/" title="Read other posts by Nigel Sood">Nigel Sood</a>. Read the original post at: <a href="https://sonraisecurity.com/blog/blocking-traffic-manipulation-in-aws-starts-with-iam/">https://sonraisecurity.com/blog/blocking-traffic-manipulation-in-aws-starts-with-iam/</a> </p>