Technique & Investigation of the Day · Educational, defensive guidance for authorized environments.
Why it matters
A newly created access key changes the credentials available to an identity, but the creation event alone says little about subsequent use. Investigate the creator, the intended workload and the first use visible in your retained telemetry; do not mistake that for the key’s first use anywhere.
HACK INVASION / VISUAL FIELD NOTES
Cloud access key review
Explore the diagram
Cloud access key review: investigation path. Define the account scope; Review expected purpose; IAM credential creation and change events from authorized CloudTrail sources.; Compare scope and behavior; Escalate; assess containment impact; Record and improve
Select the image to open it separately for closer reading.
Required telemetry and evidence
- IAM credential creation and change events from authorized CloudTrail sources.
- Caller identity, target user, event result and relevant credential identifiers; never collect secret key values.
- Subsequent recorded API activity, regions, services and response errors.
- Workload ownership, rotation tickets, role policies and available credential usage summaries.
Before drawing conclusions, record collection scope, retention and any missing fields. Keep sensitive evidence in approved internal systems.
Step-by-step investigation
1. Define the account scope
List the accounts, regions, period and log sources being reviewed. Record retention and collection boundaries. A partial view cannot establish that a credential was unused elsewhere.
2. Find successful creation
Separate failed requests from successful changes and identify creator versus target user. Preserve the event ID and relevant credential identifier internally, without exporting secret material.
3. Review expected purpose
Ask the workload owner why a long-lived key was needed and how it is managed. Compare the explanation with the approved rotation or integration record and effective access.
4. Trace observed use
Review subsequent API events attributable to the credential within available coverage. Last-used summaries are useful leads, not a complete chronological event trail.
5. Compare scope and behavior
Check whether requested services, regions and resources match the intended workload. An expected SDK or source address is supporting context; it cannot by itself prove that the credential is controlled by the right party.
6. Record and improve
Document creation, observed use and unobserved intervals. Review whether short-lived workload credentials would reduce risk, without making an unplanned production change during the hunt.
HACK INVASION / VISUAL FIELD NOTES
Cloud access key review
Explore the diagram
Cloud access key review: evidence checklist. IAM credential creation and change events from authorized CloudTrail sources.; Caller identity, target user, event result and relevant credential identifiers; never collect secret key values.; Subsequent recorded API activity, regions, services and response errors.; Workload ownership, rotation tickets, role policies and available credential usage summaries.
Select the image to open it separately for closer reading.
Read-only investigation pseudocode
INPUT authorized credential-change and API event exports
SELECT successful key creation for scoped accounts
ASSOCIATE creator, target identity and credential identifier
FIND first observed subsequent use within retained coverage
COMPARE services and resources with the approved workloadTest and adapt: this is illustrative pseudocode, not executable vendor syntax or a tested production detector. Validate field semantics, time boundaries and results in an authorized environment. It does not change systems.
Legitimate activity versus suspicious activity
Rotation can briefly create overlapping keys, and a deployment may use a key from a new network range. Validate the exact rollout and owner. A key with no currently visible events may be dormant, outside the collection scope or simply not yet used.
Tuning and false positives
Baseline workload-specific services and regions. Treat emergency maintenance separately from regular rotation. Avoid suppressing all API activity from a common automation identity or all use from a corporate egress address.
Escalation, containment and documentation
If use is unexplained, coordinate with cloud and application owners. Disabling or rotating a key can break services; preserve evidence and use the approved credential-response procedure. Review related access and persistence, not only the single key.
Close with an evidence-based disposition: explained activity, supported escalation or unresolved visibility gap. Include identifiers, times, source coverage, competing explanations and the response owner.
MITRE ATT&CK context
Additional Cloud Credentials (T1098.001) may apply when an adversary adds credentials to maintain access. A routine rotation is not sufficient evidence of that behavior.
Key takeaways
- Define the account scope: define the question before broadening the search.
- Compare scope and behavior: corroborate the explanation with independent evidence.
- Keep the observed facts, assumptions and response decisions separate.
Related articles
- LOLBins threat hunting: process context and evidence correlation
- PSIRT preparation: communicating evidence and risk
- Explore the Knowledge Base
References
Original educational workflow and conceptual diagrams for Hack Invasion. Public documentation informs source-specific details; investigation decisions require local validation.
