A trustworthy AWS assessment must prove that the EC2 instance context, effective IAM principal, account, region, and resource relationships all describe the same workload identity. This article explains how bounded discovery preserves denials, turns service responses into attack paths, and validates selected transitions with exact targets and rollback.
An AWS assessment can start from a broad operator profile. That profile may reveal more than code on a compromised EC2 instance can actually reach.
Pentest Copilot is an internal assessment system. It starts with the IAM role attached to the EC2 instance. Instance metadata and the active AWS session are checked separately; both must name the same account and region. Discovery then preserves the relationships and authorization boundaries that turn a resource list into defensible attack paths.
| Security question | Discovery rule | Why it matters |
|---|---|---|
| Which principal is being assessed? | Match the instance context to the effective AWS principal | Prevents a local profile or injected key from silently replacing the workload role |
| Where is discovery allowed? | Bind collection to the approved account, regions, and resource names or prefixes | Keeps account-wide APIs from expanding scope |
| What can the role actually reach? | Preserve resource relationships and denied operations | Distinguishes absence from lack of visibility |
| Which paths deserve proof? | Route only applicable, explicitly approved checks to exact targets | Avoids turning discovery into uncontrolled change |
The four paths below explain the method:
| Layer | What is established |
|---|---|
| Workload identity | EC2 instance context and effective IAM principal agree |
| Scope | Approved account, regions, names, and resource prefixes |
| Relationship map | Roles, policies, trust, workloads, networks, secrets, and execution identities remain connected |
| Authorization boundary | A denied API is recorded as unknown visibility, not an empty service |
| Active proof | Selected transitions run against named targets with explicit approval |
| Recovery | Reversible changes preserve and restore the original state |
An EC2 instance profile supplies short-lived role access through the Instance Metadata Service. AWS documents how applications on EC2 use attached IAM roles instead of distributing long-lived keys in IAM roles for Amazon EC2.
That convenience creates an assessment requirement: metadata and the active session must be checked independently. Instance metadata identifies the machine's account and region. AWS Security Token Service identifies the principal behind the current request. If those answers disagree, continuing would measure a different identity from the one attached to the workload.
The region also belongs in the trust boundary. AWS mixes global services, regional services, and APIs that enumerate broadly before a client can filter. A safe assessment therefore uses explicit regions and literal resource constraints. Where an API cannot honor the approved boundary, skipping it is more accurate than collecting an entire account and filtering after the fact.
Impact: the starting node in every later path represents the compromised workload, not an administrator who happened to configure the assessment.
Consider an EC2 instance, an IAM role, and a secret returned as independent rows. Those objects can all exist without forming an attack path. The path appears only when discovery preserves the relationships between them.
| AWS object | Relationship that matters | Security question it enables |
|---|---|---|
| EC2 instance | Uses an instance profile containing a role | Which identity executes on the machine? |
| IAM role | Trusts another principal or can be passed to a service | Can the current foothold become a stronger identity? |
| Lambda function | Executes as a runtime role and receives events | Can code control become identity control? |
| EKS cluster | Connects IAM access to Kubernetes authorization | Does cloud permission become cluster administration? |
| Secret | Has versions, resource policy, and downstream consumer | Does secret access unlock another system? |
| VPC resource | Attaches a workload to routes, subnets, and security controls | Which private services become reachable? |
This relationship model prevents a common overstatement. Permission to pass a role does not by itself prove control of a destination workload. Permission to submit a command does not prove that the command ran. A readable secret does not establish impact until its consumer is known and the approved validation boundary allows that use to be tested.
Impact: findings describe causal transitions-workload to role, role to service, secret to consumer-instead of presenting disconnected permissions as compromise.
Cloud discovery is routinely incomplete. A workload role may describe EC2 resources but be denied by Secrets Manager, IAM, EKS, or an organization-level control. Treating a denied list operation as an empty list would produce a clean-looking but false inventory.
The useful result keeps three states separate:
| State | Meaning |
|---|---|
| No matching resource returned | The approved query completed and found no matching object |
| Access denied | The resource set may exist, but this identity cannot enumerate it |
| Collection error | The answer is unknown for a reason other than expected authorization |
Denials also reveal defensive boundaries. A role that can describe a Lambda function but cannot read its code has a different attack surface from a role that cannot see the function at all. The distinction affects both the candidate path and the remediation.
Large storage inventories retain the same context. Before object and version expansion, the bucket location must match an approved region. Pages are processed incrementally, and reaching a safety ceiling produces an explicit partial result while unrelated service discovery continues.
Impact: defenders can tell the difference between “nothing is there” and “this workload could not see it,” avoiding false assurance from partial access.
Discovery produces candidates; it should not trigger every possible state change. Each proof needs an exact target, an approved category, and a recovery plan proportionate to the action.
| Candidate path | Required precondition | Bounded proof |
|---|---|---|
| Role trust transition | Named source and destination roles | Attempt only the specified role assumption |
| Workload role passing | Exact service and role | Verify the destination executes as that identity |
| Secret access | Exact secret version and approved consumer | Read only the permitted version and test the expected boundary |
| Function control | Named function and retained baseline | Make one controlled change, verify identity, restore |
| Network or logging change | Approved disposable target | Capture the original configuration and prove restoration |
Rollback is part of the evidence, not administrative cleanup after the result. A reversible trust, policy, workload, network, or logging test should retain the baseline, apply one identifiable change, verify the intended effect, restore the baseline, and confirm the restoration. If recovery cannot be proved, the result is not clean.
Impact: the assessment can distinguish theoretical permission from a usable path without silently widening scope or leaving persistent state behind.
Machine-identity discovery cannot prove what an unobserved administrator, another account, or an out-of-scope region can reach. A denied API remains unknown rather than safe. Policy simulation can explain a decision, but it does not replace a real request when active validation is permitted. Likewise, a successful cloud transition does not prove control of every downstream application.
If the intended runtime identity, bounded output, or baseline restoration cannot be confirmed, the path fails rather than becoming a permission-only conclusion.
The practical rule is simple: keep identity, scope, relationships, proof, and recovery tied together. When any one of those links is missing, report the uncertainty instead of completing the story by assumption.
