A Pentest Wednesday® Story

For a major U.S. transportation and logistics company that plays a critical role in moving essential goods and supporting complex international supply chains, resilience is more than an IT objective. Its operations depend on an interconnected ecosystem of transportation infrastructure, logistics services, internal systems, customer-facing applications, operational technology, and a growing cloud footprint. A weakness in the wrong place can have consequences far beyond a security dashboard.

The security team understood that complexity. What they needed was a clearer view of what an attacker could actually do inside it.

Rather than relying solely on configuration findings or vulnerability data, the team used the NodeZero® Proactive Security Platform to repeatedly pentest its AWS environment. The goal was to determine whether weaknesses in identities, permissions, and cloud configurations could be combined into attack paths with meaningful impact.

The testing did exactly that. NodeZero identified AWS IAM weaknesses, demonstrated privilege escalation paths, and showed how certain combinations of permissions could potentially lead to full AWS account compromise and sensitive data exposure. Just as importantly, repeated testing gave the team a way to address those weaknesses and determine whether its changes actually removed the exposure.

Over time, AWS testing became less about taking an occasional snapshot of cloud security and more about creating a repeatable process for understanding what was exploitable, fixing it, and testing again.

Outcomes at a Glance

• At least 25 AWS pentests conducted as part of a broader security validation program.
• AWS IAM weaknesses identified that could enable privilege escalation and potential full account compromise.
• Four AWS weaknesses connected to 25 potential impacts, including 22 paths to AWS full account compromise and three involving sensitive data exposure.
• 102 weaknesses mitigated, with only one remaining open in one AWS testing view.
• Findings mapped to techniques associated with threat actors including Scattered Spider, BlackByte, Lazarus Group, HAFNIUM, FIN13, and LAPSUS$.
• AWS testing became part of a broader expansion of security validation across the company’s cloud, internal, external, and web application environments.

NodeZero connected four AWS weaknesses to 25 potential impacts, including paths to full AWS account compromise and sensitive data exposure, while showing how those weaknesses aligned with techniques associated with known threat actors.

Impact

Cloud security findings rarely exist in isolation. An overly permissive identity or policy may look like a configuration problem on its own. The significance changes when an attacker can use it to escalate privileges, access sensitive resources, or move toward control of an AWS account.

That distinction became visible through NodeZero testing.

In one AWS pentest, NodeZero discovered AWS users and IAM policies before identifying permissions that could be used for privilege escalation. One path involved iam:CreateAccessKey, which can allow an attacker with sufficient permissions to create credentials for another IAM user and potentially assume that user’s privileges.

NodeZero did not stop at identifying the permission. In just over 42 minutes, it safely mapped how an attacker could progress through AWS STS, connected roles, discovered users, and IAM policies to an exploitable weakness that could potentially lead to full AWS account compromise, without disrupting the production environment.

NodeZero discovered AWS identities and IAM policies, identified a privilege escalation opportunity involving iam:CreateAccessKey, and mapped the attack path toward potential AWS full account compromise.

The broader results put that individual path into context. For the security team, that provided a different way to look at cloud risk. The question was no longer simply, “What is misconfigured?” It was, “Which conditions can an attacker actually use, and what could they reach?”

That distinction gave defenders a narrower set of problems to investigate, a clearer basis for prioritizing remediation, and another way to connect technical findings to the adversaries they were concerned about.

During a discussion about NodeZero’s Threat Actor Intelligence capabilities, which map validated findings and attack paths to techniques associated with known threat actors, the security team raised a question it was already hearing:

“Would we be ready for Volt Typhoon?”

Rather than treating every weakness equally, the team wanted to understand whether conditions in its environment aligned with techniques associated with relevant threat actors, giving it additional context to determine what deserved attention.

Background

The company’s geographically distributed technology environment spans internal infrastructure, customer-facing systems, cloud services, and operationally sensitive environments, creating a significant visibility challenge.

As its use of NodeZero expanded, so did the scope of validation. The team began testing across internal, external, cloud, and web application environments, extending validation across thousands of assets.

AWS became an important part of that strategy. Rather than treating cloud pentesting as an isolated assessment, the team repeatedly tested its AWS environment to understand how changes in identities, permissions, and configurations affected exploitable risk.

The need to challenge assumptions about visibility was reinforced elsewhere in the company’s environment.

During an operational review, the security team traced infrastructure supporting a large gantry crane and discovered power distribution systems that had not originally been part of the review. Because the environment was air-gapped, it had remained outside the team’s normal scanning processes.

As the security leader put it:

“That wasn’t even on our tour list.”

The discovery was a significant aha moment. Infrastructure important to keeping freight moving had existed outside the team’s normal security visibility. There was no evidence of compromise, but it raised a consequential question: what if an attacker discovered critical infrastructure before the security team knew it was there?

The same lesson carried into AWS. Knowing that resources, identities, and permissions exist is only part of the picture. The team also needed to understand how they connected, whether they could be exploited, and what an attacker could ultimately reach.

Mitigation

Once NodeZero demonstrated exploitable AWS attack paths, the team had something more actionable than a list of cloud findings.

The AWS results identified specific IAM permissions associated with potential privilege escalation, including:

• AWS CreateAccessKey
• AWS UpdateLoginProfile
• AWS UpdateAssumeRolePolicy

Rather than treating every AWS configuration issue as equally urgent, the team could prioritize the identity relationships and permissions that contributed to meaningful impact.

The results show that the team acted on those findings. In a later AWS testing, 102 weaknesses had been mitigated with only one remaining open.

One AWS testing view shows 102 weaknesses mitigated with only one remaining open, providing a measurable view of remediation progress.

That ability to measure progress matters. Fixing the underlying weakness was only part of the process. By testing again, the team could verify that the exploitable attack path was actually closed and that the same outcome could no longer be achieved.

Remediation

With at least 25 AWS pentests conducted, the team could regularly identify attack paths, address exploitable conditions, and determine whether previous weaknesses remained closed as the environment changed.

The results over time show why that matters. Open weaknesses increased as conditions changed and subsequently returned close to zero, while impacts also fluctuated over time.

Repeated AWS pentesting showed that exposure was not static. Open weaknesses changed as the environment evolved and declined again as identified conditions were addressed.

Tracking impacts across repeated tests gave the security team visibility into how changes in the AWS environment affected exploitable outcomes over time.

That variability matters. As identities, permissions, and applications change, previously validated environments can develop new attack paths.

The same validation model has expanded beyond AWS. The organization uses NodeZero across internal, external, and cloud testing and has actively evaluated NodeZero WebApp to autonomously pentest its web applications.

What started as a way to gain better visibility into exploitable risk has become a broader approach to security validation: understand what is exposed, determine what an attacker can actually do with it, and give teams the information they need to act.

Conclusion

As AWS environments evolve, so does their attack surface. Changes to identities, permissions, applications, and resources can create new attack paths, making repeated validation essential.

The value was not simply discovering AWS weaknesses. It was understanding how identities and permissions could be combined into attack paths, prioritizing what mattered, and verifying that remediation changed the outcome.

That is the shift from Patch Tuesday to Pentest Wednesday®.

Finding vulnerabilities is only the beginning. What matters is understanding what an attacker can do with them, fixing the paths that create meaningful risk, and testing again to verify those paths stay closed.