Cloud detection & response
SkillCloud & infraDetect and respond to attacks in cloud control planes, credential abuse, IMDS theft, persistence, and privilege escalation, from audit logs. Load for "detect cloud attacks", "CloudTrail/GuardDuty", "someone used our keys", AWS/Azure/GCP monitoring, or cloud IR. The defensive counterpart to the cloud-* offensive skills.
Instructions available. Your AI can read the instructions. Execution depends on the setup they require.
Account requirements not reviewed. Check the skill instructions before use; ahel provides instructions and does not run this skill.
Add ahel to your AI once: Claude, ChatGPT, Cursor, Claude Code or Codex. Then ask it to use this.
Then ask your AI: use the Cloud detection & response skill
What this skill tells your AI
The instructions your AI receives, as published by noorqureshi/sploitagent in skills/defense/defense-cloud-detection/SKILL.md and read by ahel’s review.
When it applies
Your assets live in AWS/Azure/GCP and you need to catch control-plane abuse — stolen keys, a role assumed from a strange place, new persistence — using the provider's audit logs.
Why it works
Every cloud API call is logged (CloudTrail / Azure Activity / GCP Admin Activity). Attacks that are invisible on the host (assuming a role, reading a secret, adding a key) are loud in the control plane — if you're actually reading it. The identity and the calling context are in every event.
Method
- Guarantee the telemetry: CloudTrail (all regions + management & data events), Azure Activity
- Entra sign-in logs, GCP audit logs — centralised and immutable. No logs → no detection.
- Credential-theft tells: an IAM user/role key used from a new ASN/region/UA, especially
sts:GetCallerIdentitythen enumeration bursts — classic stolen-key triage. IMDS-sourced role creds used off the instance (compare the session's source IP to the instance). - Persistence:
CreateAccessKey,CreateUser, new login profile,CreateRolewith a broad trust policy, new identity provider — alert on these in prod accounts. - Privilege escalation:
AttachUserPolicy/PutUserPolicygranting*,iam:PassRole+ service launch,AssumeRolechains that cross accounts. - Managed signals: enable GuardDuty / Defender for Cloud / SCC as a baseline, then tune and layer custom queries (Athena over CloudTrail) on top.
- Respond: disable the key/session, revoke role sessions, snapshot for forensics, rotate, and
review what the identity could reach (
tradecraft-attack-path-mapping).
Gotchas
- CloudTrail data events (S3 object-level, Lambda) are off by default — you miss exfil without them.
- Roles blur "who did it" — correlate the session name and source, not just the principal.
- Automation (CI/CD, Terraform) generates the same API calls; baseline service identities first.
Verify success
A simulated key-abuse / privilege-escalation sequence (e.g. via a lab) surfaces from the audit logs with the identity, source, and action, and the response revokes access and preserves evidence.
References
AWS CloudTrail & GuardDuty; Azure Monitor / Entra sign-in logs; GCP audit logs; MITRE ATT&CK Cloud matrix.
Signals
- GitHub stars
- 20
- Forks
- 7
- Last commit
- Sep 2026
Advanced
- Item type
- skill
- Key
defense-cloud-detection- Source
- github.com/noorqureshi/sploitagent
github.com/noorqureshi/sploitagent