[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6AEK9PY53WCFCEJ3WZK4DGG":3,"skill-same:01M6AEK9PY53WCFCEJ3WZK4DGG":108},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":44,"linkOnly":45,"markdownContent":46,"markdownBody":47,"frontMatter":48,"refName":59,"commitSha":60,"skillDirectory":61,"forksCount":62,"repositoryHtmlUrl":63,"repositoryHomepageUrl":64,"ownerHtmlUrl":65,"ownerBlogUrl":66,"ownerDescription":67,"updatedAt":68,"install":69,"resources":82},"01M6AEK9PY53WCFCEJ3WZK4DGG","emulating-cloud-attacks-with-stratus-red-team",null,"Install and run Stratus Red Team to detonate granular, MITRE ATT&CK-mapped AWS, Azure, GCP, and Kubernetes attack techniques through their warmup-detonate-revert-cleanup lifecycle, then verify the telemetry they generate. Use to validate that cloud detections (CloudTrail, GuardDuty, Microsoft Sentinel, GCP SCC, Falco) actually fire, or to run a repeatable purple-team exercise generating realistic attacker telemetry.","mukul975\u002FAnthropic-Cybersecurity-Skills","mukul975","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F42860185?v=4","01M6ADEQR8T5M4EEG6C67BQCWF","Mahipal","01M6ADJPMYWG1E5GM1FWBE3128",35990,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Femulating-cloud-attacks-with-stratus-red-team\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"emulating cloud attacks with stratus red team","cloud","red team","cloud-security","t1078","falco","guardduty","purple-team","adversary-emulation","sentinel","gcp","threat-detection","kubernetes","mitre-attack","red-team","run","generate","cleanup","cybersecurity","security","2026-11-10 10:12:30",false,"---\nname: emulating-cloud-attacks-with-stratus-red-team\ndescription: Install and run Stratus Red Team to detonate granular, MITRE ATT&CK-mapped\n  AWS, Azure, GCP, and Kubernetes attack techniques through their warmup-detonate-revert-cleanup\n  lifecycle, then verify the telemetry they generate. Use to validate that cloud detections\n  (CloudTrail, GuardDuty, Microsoft Sentinel, GCP SCC, Falco) actually fire, or to run a\n  repeatable purple-team exercise generating realistic attacker telemetry.\ndomain: cybersecurity\nsubdomain: cloud-security\ntags:\n- stratus-red-team\n- adversary-emulation\n- cloud-security\n- detection-validation\n- purple-team\n- aws\n- mitre-attack\n- threat-detection\nversion: '1.0'\nauthor: mahipal\nlicense: Apache-2.0\nnist_csf:\n- DE.CM-01\nmitre_attack:\n- T1078\n---\n# Emulating Cloud Attacks with Stratus Red Team\n\n> **Legal Notice:** This skill is for authorized security testing and detection-validation purposes only. Stratus Red Team spins up and modifies real cloud infrastructure in the account whose credentials you supply. Only run it in accounts you own or are explicitly authorized to test. Always `cleanup` afterwards to avoid orphaned, billable, or insecure resources. Unauthorized use against systems you do not control is illegal.\n\n## Overview\n\nStratus Red Team is an open-source \"Atomic Red Team for the cloud,\" maintained by Datadog. It is a self-contained Go binary that programmatically *detonates* granular, well-documented offensive techniques against AWS, Azure, GCP, and Kubernetes, then lets you cleanly revert and remove everything it created. Unlike a full exploitation framework, Stratus is purpose-built for **detection engineering and purple teaming**: each technique maps to a MITRE ATT&CK tactic and ships with a precise description of the cloud API calls it generates, so a blue team can confirm whether their CloudTrail\u002FGuardDuty\u002FSentinel\u002FFalco detections actually fire.\n\nEvery technique has a deterministic lifecycle. Stratus first provisions any prerequisite infrastructure with embedded Terraform (the **warmup** phase), then performs the malicious actions (**detonate**), optionally **revert**s the side effects so you can detonate again, and finally **cleanup**s the prerequisite infrastructure. Because the prerequisites and the attack are decoupled, you can iterate on a detection by detonating the same technique repeatedly without re-provisioning. The tool uses your standard cloud SDK credential chain (AWS profiles\u002Fenv vars, `az login`, GCP ADC, kubeconfig), so it operates with exactly the permissions of the identity you authenticate as.\n\nThis skill covers installing Stratus, listing and filtering the technique catalog, running the full warmup-detonate-revert-cleanup lifecycle, mapping detonations to the telemetry they produce, and wiring the results into a detection-validation workflow. Source: github.com\u002FDataDog\u002Fstratus-red-team and stratus-red-team.cloud official documentation.\n\n## When to Use\n\n- Validating that a new or existing cloud detection rule (CloudTrail, GuardDuty, Microsoft Sentinel, GCP SCC, Falco) actually triggers on real attacker activity\n- Building a repeatable purple-team exercise for cloud TTPs without writing bespoke attack scripts\n- Generating realistic, MITRE-mapped telemetry to test SIEM ingestion and alert routing\n- Measuring detection coverage of a cloud environment against a known catalog of techniques\n- Onboarding analysts with safe, reversible hands-on cloud attack simulations\n\n## Prerequisites\n\n- Stratus Red Team binary (Go 1.23+ to build from source, or Homebrew\u002FDocker):\n  ```bash\n  # Go install\n  go install -v github.com\u002Fdatadog\u002Fstratus-red-team\u002Fv2\u002Fcmd\u002Fstratus@latest\n\n  # Homebrew\n  brew tap datadog\u002Fstratus-red-team https:\u002F\u002Fgithub.com\u002FDataDog\u002Fstratus-red-team\n  brew install datadog\u002Fstratus-red-team\u002Fstratus-red-team\n\n  # Docker\n  docker run --rm -v $HOME\u002F.stratus-red-team\u002F:\u002Froot\u002F.stratus-red-team\u002F \\\n    -e AWS_ACCESS_KEY_ID -e AWS_SECRET_ACCESS_KEY -e AWS_SESSION_TOKEN \\\n    ghcr.io\u002Fdatadog\u002Fstratus-red-team list\n  ```\n- Authenticated cloud credentials for the target provider:\n  ```bash\n  # AWS — verify identity before detonating\n  export AWS_PROFILE=stratus-lab\n  aws sts get-caller-identity\n\n  # Azure\n  az login\n\n  # GCP\n  gcloud auth application-default login\n\n  # Kubernetes\n  kubectl config current-context\n  ```\n- A dedicated, non-production lab account or subscription (techniques create real resources)\n- Terraform is embedded; no separate install is required, but outbound HTTPS to download provider plugins on first warmup is needed\n\n## Objectives\n\n- Install Stratus Red Team and confirm the target cloud identity\n- Enumerate and filter techniques by platform and MITRE ATT&CK tactic\n- Execute the warmup -> detonate -> revert -> cleanup lifecycle safely\n- Map each detonation to the cloud API calls and log sources it generates\n- Validate detection rules against the produced telemetry and track coverage\n- Guarantee no residual infrastructure remains after testing\n\n## MITRE ATT&CK Mapping\n\n| ID | Name | Use in this skill |\n|----|------|-------------------|\n| T1078 | Valid Accounts | Emulation runs as a valid cloud identity; many techniques abuse legitimate credentials\u002FAPI access |\n| T1078.004 | Valid Accounts: Cloud Accounts | e.g. `aws.credential-access.ec2-steal-instance-credentials` produces cloud-account abuse telemetry |\n| T1580 | Cloud Infrastructure Discovery | Discovery-tactic techniques such as `aws.discovery.*` |\n| T1530 | Data from Cloud Storage | Exfiltration techniques such as `aws.exfiltration.ec2-share-ebs-snapshot` |\n| T1098 | Account Manipulation | Persistence techniques such as `aws.persistence.iam-create-admin-user` |\n\n## Workflow\n\n### 1. Confirm identity and list the technique catalog\nAlways confirm which account you are about to attack, then browse the catalog.\n```bash\naws sts get-caller-identity\nstratus list\n# Filter to a single platform\nstratus list --platform aws\n# Filter by MITRE ATT&CK tactic\nstratus list --mitre-attack-tactic credential-access\n```\n\n### 2. Inspect a specific technique before running it\nRead exactly what a technique will do and which detonation\u002Ftelemetry it produces.\n```bash\nstratus show aws.credential-access.ec2-steal-instance-credentials\n```\n\n### 3. Warm up prerequisite infrastructure\nProvision the prerequisites with embedded Terraform without performing the attack yet.\n```bash\nstratus warmup aws.credential-access.ec2-steal-instance-credentials\nstratus status\n```\n\n### 4. Detonate the technique\nExecute the malicious actions; this is what your detections must catch. Warmup is implicit if not already done.\n```bash\nstratus detonate aws.credential-access.ec2-steal-instance-credentials\n# Detonate and force a re-warmup in one step\nstratus detonate aws.persistence.iam-create-admin-user --force\n```\n\n### 5. Inspect status and the telemetry generated\nCheck lifecycle state, then pull the corresponding control-plane logs to confirm the attack landed.\n```bash\nstratus status\n# Pull recent CloudTrail events to verify the detonation\naws cloudtrail lookup-events \\\n  --lookup-attributes AttributeKey=EventName,AttributeValue=CreateAccessKey \\\n  --max-results 10\n```\n\n### 6. Validate the detection\nConfirm your SIEM\u002Fdetection fired. Example: query Athena\u002FCloudTrail or check GuardDuty findings.\n```bash\naws guardduty list-findings --detector-id \"$DETECTOR_ID\" \\\n  --finding-criteria '{\"Criterion\":{\"updatedAt\":{\"GreaterThanOrEqual\":'\"$(date -d '-1 hour' +%s)\"'000}}}'\n```\n\n### 7. Revert side effects to re-detonate\nUndo the detonation while keeping prerequisites so you can iterate on a detection.\n```bash\nstratus revert aws.credential-access.ec2-steal-instance-credentials\nstratus detonate aws.credential-access.ec2-steal-instance-credentials   # run again\n```\n\n### 8. Clean up all infrastructure\nTear down everything a technique created. Always finish here.\n```bash\nstratus cleanup aws.credential-access.ec2-steal-instance-credentials\n# Nuke everything Stratus ever provisioned in this account\nstratus cleanup --all\nstratus status   # confirm COLD state for all techniques\n```\n\n### 9. Drive it programmatically for coverage runs\nLoop over a tactic to measure detection coverage, then clean up. See `scripts\u002Fagent.py`.\n```bash\npython scripts\u002Fagent.py --platform aws --tactic credential-access --detonate --cleanup\n```\n\n## Tools and Resources\n\n| Resource | Purpose | Link |\n|----------|---------|------|\n| Stratus Red Team GitHub | Source, releases, technique source | https:\u002F\u002Fgithub.com\u002FDataDog\u002Fstratus-red-team |\n| Stratus Red Team docs | Technique catalog and lifecycle reference | https:\u002F\u002Fstratus-red-team.cloud |\n| Attack technique list | Full per-platform technique IDs | https:\u002F\u002Fstratus-red-team.cloud\u002Fattack-techniques\u002Flist\u002F |\n| MITRE ATT&CK Cloud | Tactic\u002Ftechnique reference for mapping | https:\u002F\u002Fattack.mitre.org\u002Fmatrices\u002Fenterprise\u002Fcloud\u002F |\n| Atomic Red Team | Complementary endpoint emulation | https:\u002F\u002Fgithub.com\u002Fredcanaryco\u002Fatomic-red-team |\n\n## Detection-Validation Mapping\n\nFor purple-team value, pair each detonation with the telemetry and detection it should trigger:\n\n| Technique | Expected telemetry | Detection to validate |\n|-----------|--------------------|-----------------------|\n| `aws.credential-access.ec2-steal-instance-credentials` | CloudTrail use of role creds from a non-EC2 IP | GuardDuty `UnauthorizedAccess:IAMUser\u002FInstanceCredentialExfiltration` |\n| `aws.persistence.iam-create-admin-user` | `CreateUser` + `AttachUserPolicy` (AdministratorAccess) | CloudTrail\u002FSentinel rule on admin-policy attach |\n| `aws.exfiltration.ec2-share-ebs-snapshot` | `ModifySnapshotAttribute` sharing to external account | GuardDuty `Exfiltration:EC2\u002F...` \u002F custom rule |\n| `aws.discovery.ec2-enumerate-from-instance` | Burst of `Describe*` from instance role | Enumeration-burst detection |\n\nAfter detonation, confirm the alert fired end-to-end (source -> SIEM -> ticket). If it\ndid not, you have found a coverage gap; document it before cleaning up.\n\n## Cost and Safety Notes\n\n- Some techniques provision billable resources (EC2 instances, EBS snapshots). Always\n  run `stratus cleanup --all` and verify `stratus status` returns COLD.\n- Never run Stratus with production credentials; use a dedicated lab account\u002Fsubscription.\n- The state directory `~\u002F.stratus-red-team\u002F` holds Terraform state — preserve it until\n  cleanup completes, or you may strand resources.\n\n## Lifecycle State Reference\n\n| State | Meaning |\n|-------|---------|\n| COLD | No prerequisites provisioned; nothing to clean up |\n| WARM | Prerequisites provisioned but not yet detonated |\n| DETONATED | Attack actions performed; side effects present |\n\n## Validation Criteria\n\n- [ ] Stratus installed and `stratus list` returns the technique catalog\n- [ ] Target cloud identity confirmed via `sts get-caller-identity` \u002F equivalent\n- [ ] Technique inspected with `stratus show` before detonation\n- [ ] Warmup completed and status shows WARM\n- [ ] Detonation completed and status shows DETONATED\n- [ ] Generated telemetry located in CloudTrail\u002FGuardDuty\u002FSIEM\n- [ ] Detection rule confirmed to fire (or coverage gap documented)\n- [ ] Technique reverted and re-detonated to confirm repeatability\n- [ ] `stratus cleanup --all` run and status returns COLD for every technique\n- [ ] No orphaned billable resources remain in the account\n","# Emulating Cloud Attacks with Stratus Red Team\n\n> **Legal Notice:** This skill is for authorized security testing and detection-validation purposes only. Stratus Red Team spins up and modifies real cloud infrastructure in the account whose credentials you supply. Only run it in accounts you own or are explicitly authorized to test. Always `cleanup` afterwards to avoid orphaned, billable, or insecure resources. Unauthorized use against systems you do not control is illegal.\n\n## Overview\n\nStratus Red Team is an open-source \"Atomic Red Team for the cloud,\" maintained by Datadog. It is a self-contained Go binary that programmatically *detonates* granular, well-documented offensive techniques against AWS, Azure, GCP, and Kubernetes, then lets you cleanly revert and remove everything it created. Unlike a full exploitation framework, Stratus is purpose-built for **detection engineering and purple teaming**: each technique maps to a MITRE ATT&CK tactic and ships with a precise description of the cloud API calls it generates, so a blue team can confirm whether their CloudTrail\u002FGuardDuty\u002FSentinel\u002FFalco detections actually fire.\n\nEvery technique has a deterministic lifecycle. Stratus first provisions any prerequisite infrastructure with embedded Terraform (the **warmup** phase), then performs the malicious actions (**detonate**), optionally **revert**s the side effects so you can detonate again, and finally **cleanup**s the prerequisite infrastructure. Because the prerequisites and the attack are decoupled, you can iterate on a detection by detonating the same technique repeatedly without re-provisioning. The tool uses your standard cloud SDK credential chain (AWS profiles\u002Fenv vars, `az login`, GCP ADC, kubeconfig), so it operates with exactly the permissions of the identity you authenticate as.\n\nThis skill covers installing Stratus, listing and filtering the technique catalog, running the full warmup-detonate-revert-cleanup lifecycle, mapping detonations to the telemetry they produce, and wiring the results into a detection-validation workflow. Source: github.com\u002FDataDog\u002Fstratus-red-team and stratus-red-team.cloud official documentation.\n\n## When to Use\n\n- Validating that a new or existing cloud detection rule (CloudTrail, GuardDuty, Microsoft Sentinel, GCP SCC, Falco) actually triggers on real attacker activity\n- Building a repeatable purple-team exercise for cloud TTPs without writing bespoke attack scripts\n- Generating realistic, MITRE-mapped telemetry to test SIEM ingestion and alert routing\n- Measuring detection coverage of a cloud environment against a known catalog of techniques\n- Onboarding analysts with safe, reversible hands-on cloud attack simulations\n\n## Prerequisites\n\n- Stratus Red Team binary (Go 1.23+ to build from source, or Homebrew\u002FDocker):\n  ```bash\n  # Go install\n  go install -v github.com\u002Fdatadog\u002Fstratus-red-team\u002Fv2\u002Fcmd\u002Fstratus@latest\n\n  # Homebrew\n  brew tap datadog\u002Fstratus-red-team https:\u002F\u002Fgithub.com\u002FDataDog\u002Fstratus-red-team\n  brew install datadog\u002Fstratus-red-team\u002Fstratus-red-team\n\n  # Docker\n  docker run --rm -v $HOME\u002F.stratus-red-team\u002F:\u002Froot\u002F.stratus-red-team\u002F \\\n    -e AWS_ACCESS_KEY_ID -e AWS_SECRET_ACCESS_KEY -e AWS_SESSION_TOKEN \\\n    ghcr.io\u002Fdatadog\u002Fstratus-red-team list\n  ```\n- Authenticated cloud credentials for the target provider:\n  ```bash\n  # AWS — verify identity before detonating\n  export AWS_PROFILE=stratus-lab\n  aws sts get-caller-identity\n\n  # Azure\n  az login\n\n  # GCP\n  gcloud auth application-default login\n\n  # Kubernetes\n  kubectl config current-context\n  ```\n- A dedicated, non-production lab account or subscription (techniques create real resources)\n- Terraform is embedded; no separate install is required, but outbound HTTPS to download provider plugins on first warmup is needed\n\n## Objectives\n\n- Install Stratus Red Team and confirm the target cloud identity\n- Enumerate and filter techniques by platform and MITRE ATT&CK tactic\n- Execute the warmup -> detonate -> revert -> cleanup lifecycle safely\n- Map each detonation to the cloud API calls and log sources it generates\n- Validate detection rules against the produced telemetry and track coverage\n- Guarantee no residual infrastructure remains after testing\n\n## MITRE ATT&CK Mapping\n\n| ID | Name | Use in this skill |\n|----|------|-------------------|\n| T1078 | Valid Accounts | Emulation runs as a valid cloud identity; many techniques abuse legitimate credentials\u002FAPI access |\n| T1078.004 | Valid Accounts: Cloud Accounts | e.g. `aws.credential-access.ec2-steal-instance-credentials` produces cloud-account abuse telemetry |\n| T1580 | Cloud Infrastructure Discovery | Discovery-tactic techniques such as `aws.discovery.*` |\n| T1530 | Data from Cloud Storage | Exfiltration techniques such as `aws.exfiltration.ec2-share-ebs-snapshot` |\n| T1098 | Account Manipulation | Persistence techniques such as `aws.persistence.iam-create-admin-user` |\n\n## Workflow\n\n### 1. Confirm identity and list the technique catalog\nAlways confirm which account you are about to attack, then browse the catalog.\n```bash\naws sts get-caller-identity\nstratus list\n# Filter to a single platform\nstratus list --platform aws\n# Filter by MITRE ATT&CK tactic\nstratus list --mitre-attack-tactic credential-access\n```\n\n### 2. Inspect a specific technique before running it\nRead exactly what a technique will do and which detonation\u002Ftelemetry it produces.\n```bash\nstratus show aws.credential-access.ec2-steal-instance-credentials\n```\n\n### 3. Warm up prerequisite infrastructure\nProvision the prerequisites with embedded Terraform without performing the attack yet.\n```bash\nstratus warmup aws.credential-access.ec2-steal-instance-credentials\nstratus status\n```\n\n### 4. Detonate the technique\nExecute the malicious actions; this is what your detections must catch. Warmup is implicit if not already done.\n```bash\nstratus detonate aws.credential-access.ec2-steal-instance-credentials\n# Detonate and force a re-warmup in one step\nstratus detonate aws.persistence.iam-create-admin-user --force\n```\n\n### 5. Inspect status and the telemetry generated\nCheck lifecycle state, then pull the corresponding control-plane logs to confirm the attack landed.\n```bash\nstratus status\n# Pull recent CloudTrail events to verify the detonation\naws cloudtrail lookup-events \\\n  --lookup-attributes AttributeKey=EventName,AttributeValue=CreateAccessKey \\\n  --max-results 10\n```\n\n### 6. Validate the detection\nConfirm your SIEM\u002Fdetection fired. Example: query Athena\u002FCloudTrail or check GuardDuty findings.\n```bash\naws guardduty list-findings --detector-id \"$DETECTOR_ID\" \\\n  --finding-criteria '{\"Criterion\":{\"updatedAt\":{\"GreaterThanOrEqual\":'\"$(date -d '-1 hour' +%s)\"'000}}}'\n```\n\n### 7. Revert side effects to re-detonate\nUndo the detonation while keeping prerequisites so you can iterate on a detection.\n```bash\nstratus revert aws.credential-access.ec2-steal-instance-credentials\nstratus detonate aws.credential-access.ec2-steal-instance-credentials   # run again\n```\n\n### 8. Clean up all infrastructure\nTear down everything a technique created. Always finish here.\n```bash\nstratus cleanup aws.credential-access.ec2-steal-instance-credentials\n# Nuke everything Stratus ever provisioned in this account\nstratus cleanup --all\nstratus status   # confirm COLD state for all techniques\n```\n\n### 9. Drive it programmatically for coverage runs\nLoop over a tactic to measure detection coverage, then clean up. See `scripts\u002Fagent.py`.\n```bash\npython scripts\u002Fagent.py --platform aws --tactic credential-access --detonate --cleanup\n```\n\n## Tools and Resources\n\n| Resource | Purpose | Link |\n|----------|---------|------|\n| Stratus Red Team GitHub | Source, releases, technique source | https:\u002F\u002Fgithub.com\u002FDataDog\u002Fstratus-red-team |\n| Stratus Red Team docs | Technique catalog and lifecycle reference | https:\u002F\u002Fstratus-red-team.cloud |\n| Attack technique list | Full per-platform technique IDs | https:\u002F\u002Fstratus-red-team.cloud\u002Fattack-techniques\u002Flist\u002F |\n| MITRE ATT&CK Cloud | Tactic\u002Ftechnique reference for mapping | https:\u002F\u002Fattack.mitre.org\u002Fmatrices\u002Fenterprise\u002Fcloud\u002F |\n| Atomic Red Team | Complementary endpoint emulation | https:\u002F\u002Fgithub.com\u002Fredcanaryco\u002Fatomic-red-team |\n\n## Detection-Validation Mapping\n\nFor purple-team value, pair each detonation with the telemetry and detection it should trigger:\n\n| Technique | Expected telemetry | Detection to validate |\n|-----------|--------------------|-----------------------|\n| `aws.credential-access.ec2-steal-instance-credentials` | CloudTrail use of role creds from a non-EC2 IP | GuardDuty `UnauthorizedAccess:IAMUser\u002FInstanceCredentialExfiltration` |\n| `aws.persistence.iam-create-admin-user` | `CreateUser` + `AttachUserPolicy` (AdministratorAccess) | CloudTrail\u002FSentinel rule on admin-policy attach |\n| `aws.exfiltration.ec2-share-ebs-snapshot` | `ModifySnapshotAttribute` sharing to external account | GuardDuty `Exfiltration:EC2\u002F...` \u002F custom rule |\n| `aws.discovery.ec2-enumerate-from-instance` | Burst of `Describe*` from instance role | Enumeration-burst detection |\n\nAfter detonation, confirm the alert fired end-to-end (source -> SIEM -> ticket). If it\ndid not, you have found a coverage gap; document it before cleaning up.\n\n## Cost and Safety Notes\n\n- Some techniques provision billable resources (EC2 instances, EBS snapshots). Always\n  run `stratus cleanup --all` and verify `stratus status` returns COLD.\n- Never run Stratus with production credentials; use a dedicated lab account\u002Fsubscription.\n- The state directory `~\u002F.stratus-red-team\u002F` holds Terraform state — preserve it until\n  cleanup completes, or you may strand resources.\n\n## Lifecycle State Reference\n\n| State | Meaning |\n|-------|---------|\n| COLD | No prerequisites provisioned; nothing to clean up |\n| WARM | Prerequisites provisioned but not yet detonated |\n| DETONATED | Attack actions performed; side effects present |\n\n## Validation Criteria\n\n- [ ] Stratus installed and `stratus list` returns the technique catalog\n- [ ] Target cloud identity confirmed via `sts get-caller-identity` \u002F equivalent\n- [ ] Technique inspected with `stratus show` before detonation\n- [ ] Warmup completed and status shows WARM\n- [ ] Detonation completed and status shows DETONATED\n- [ ] Generated telemetry located in CloudTrail\u002FGuardDuty\u002FSIEM\n- [ ] Detection rule confirmed to fire (or coverage gap documented)\n- [ ] Technique reverted and re-detonated to confirm repeatability\n- [ ] `stratus cleanup --all` run and status returns COLD for every technique\n- [ ] No orphaned billable resources remain in the account\n",{"name":5,"tags":49,"author":53,"domain":42,"license":15,"version":54,"nist_csf":55,"subdomain":27,"description":7,"mitre_attack":57},[50,32,27,51,31,52,37,35],"stratus-red-team","detection-validation","aws","mahipal","1.0",[56],"DE.CM-01",[58],"T1078","main","54a798831d2266a3ca61ce68a7acb80b81160d57","skills\u002Femulating-cloud-attacks-with-stratus-red-team",4395,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills","https:\u002F\u002Fmahipal.engineer\u002FAnthropic-Cybersecurity-Skills\u002F","https:\u002F\u002Fgithub.com\u002Fmukul975","Mahipal.engineer","🔐 Cybersecurity | 💻 Dev | 📷 Street Photographer\r\n🎓 MSc | 📚 Research & AI Security","2026-08-31 12:32:44",{"source":8,"skillName":5,"commands":70,"prompt":80,"zipAvailable":81},[71,74,77],{"tool":72,"command":73},"npx","npx skills add mukul975\u002FAnthropic-Cybersecurity-Skills --skill emulating-cloud-attacks-with-stratus-red-team",{"tool":75,"command":76},"bunx","bunx skills add mukul975\u002FAnthropic-Cybersecurity-Skills --skill emulating-cloud-attacks-with-stratus-red-team",{"tool":78,"command":79},"pnpm","pnpm dlx skills add mukul975\u002FAnthropic-Cybersecurity-Skills --skill emulating-cloud-attacks-with-stratus-red-team","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Femulating-cloud-attacks-with-stratus-red-team\u002FSKILL.md",true,[83,88,94,98,102],{"path":84,"resourceType":84,"resourceTypeDesc":85,"sizeBytes":86,"sourceHtmlUrl":87},"LICENSE","许可证",11255,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Femulating-cloud-attacks-with-stratus-red-team\u002FLICENSE",{"path":89,"resourceType":90,"resourceTypeDesc":91,"sizeBytes":92,"sourceHtmlUrl":93},"manifest.json","REFERENCE","参考文档",521,"https:\u002F\u002Fgithub.com\u002Fjmagly\u002Faiwg\u002Fblob\u002Fmain\u002Fagentic\u002Fcode\u002Faddons\u002Fagent-loop\u002Fskills\u002Fagent-loop\u002Fmanifest.json",{"path":95,"resourceType":90,"resourceTypeDesc":91,"sizeBytes":96,"sourceHtmlUrl":97},"references\u002Fapi-reference.md",2429,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Femulating-cloud-attacks-with-stratus-red-team\u002Freferences\u002Fapi-reference.md",{"path":99,"resourceType":90,"resourceTypeDesc":91,"sizeBytes":100,"sourceHtmlUrl":101},"references\u002Fstandards.md",1252,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Femulating-cloud-attacks-with-stratus-red-team\u002Freferences\u002Fstandards.md",{"path":103,"resourceType":104,"resourceTypeDesc":105,"sizeBytes":106,"sourceHtmlUrl":107},"scripts\u002Fagent.py","SCRIPT","脚本",5196,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Femulating-cloud-attacks-with-stratus-red-team\u002Fscripts\u002Fagent.py",[109,135,159,186,212,239],{"skillNo":110,"name":111,"nameZh":6,"description":112,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":113,"categories":114,"keywords":116,"publishedAt":44},"01M6AGDM3HJXTKXX15ZZ0ZVCJ3","verifying-build-provenance-with-slsa-sigstore","Verifies artifact signatures and SLSA provenance using Sigstore's cosign (verify, verify-attestation, verify-blob-attestation) and slsa-verifier (verify-artifact), enforcing keyless OIDC builder identity and source repo against SLSA Build levels. Use in CI\u002FCD before deploying artifacts, when consuming third-party attestations, establishing a SLSA Build L3 pipeline, or confirming provenance during incident response or admission control.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fverifying-build-provenance-with-slsa-sigstore\u002FSKILL.md",[115],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[117,118,119,120,43,42,121,122,123,124,125,126,127,128,129,130,131,132,133,134],"sigstore","provenance","slsa","verifying build provenance with slsa sigstore","incident response","identity","pr","code","artifacts","ci","supply-chain","pipeline","supply-chain-security","t1195","attestation","code-signing","cosign","keyless",{"skillNo":136,"name":137,"nameZh":6,"description":138,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":139,"categories":140,"keywords":142,"publishedAt":44},"01M6AGDGBPWYVZ2F11GFKJ4HZ9","validating-tpm-measured-boot-attestation","Verifies TPM 2.0 measured-boot integrity and remote attestation with tpm2-tools -- reading PCRs (tpm2_pcrread), replaying the boot event log, generating and checking signed quotes (tpm2_quote\u002Ftpm2_checkquote), and sealing secrets to a PCR policy. Use to confirm a system booted trusted firmware\u002Fkernel for Zero Trust device posture, detect boot-chain tampering via PCR drift, or build a golden-value baseline for fleet attestation.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fvalidating-tpm-measured-boot-attestation\u002FSKILL.md",[141],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[143,131,144,145,43,146,42,123,147,148,149,150,151,152,153,154,155,156,157,158],"boot","TPM","validating tpm measured boot attestation","policy","verification","ZeRO","firmware","Tools","measured-boot","PCR","integrity","secrets","remote-attestation","tpm2-tools","integrity-verification","trusted-computing",{"skillNo":160,"name":161,"nameZh":6,"description":162,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":163,"categories":164,"keywords":169,"publishedAt":44},"01M6AGDCW0Y4FXZ3362GT1941M","validating-backup-integrity-for-recovery","Validates backup integrity through cryptographic hash verification, automated restore testing, corruption detection, and recoverability checks to confirm backups are reliable for disaster recovery and ransomware response. Use before relying on backups for recovery, when building post-backup validation pipelines, auditing backup infrastructure for compliance, or checking immutable\u002Fair-gapped backups for silent corruption or tampering.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fvalidating-backup-integrity-for-recovery\u002FSKILL.md",[165,168],{"categoryNo":166,"categoryName":167,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[153,170,171,172,173,42,174,175,147,176,177,178,179,180,181,28,182,183,184,185],"backup","recovery","validating backup integrity for recovery","testing","infrastructure","validation","compliance","hash-verification","incident-response","ransomware","cryptocurrency","detection","t1490","immutable","disaster-recovery","restore-testing",{"skillNo":187,"name":188,"nameZh":6,"description":189,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":190,"categories":191,"keywords":193,"publishedAt":44},"01M6AGD9GBG2KZ336AE763J3WH","triaging-windows-with-kape","Runs KAPE (Kroll Artifact Parser and Extractor) to collect targeted forensic artifacts (registry hives, $MFT, event logs, prefetch, browser data) via Targets and parse them with Modules wrapping Eric Zimmerman's EZ Tools (PECmd, MFTECmd, RECmd). Use during early incident containment\u002Ftriage when full disk imaging is impractical but a defensible, parseable Windows artifact set is needed quickly, including at-scale remote collection.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Ftriaging-windows-with-kape\u002FSKILL.md",[192],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[194,195,196,42,197,198,199,200,201,202,203,204,205,206,207,208,150,209,210,211],"windows","kape","triaging windows with kape","registry","browser","logs","windows-forensics","dfir","mft","mftecmd","data","prefetch","eric-zimmerman","digital-forensics","SET","collection","pecmd","artifact-collection",{"skillNo":213,"name":214,"nameZh":6,"description":215,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":216,"categories":217,"keywords":219,"publishedAt":44},"01M6AGD5PW5J4EVZM958WD74ZQ","triaging-vulnerabilities-with-ssvc-framework","Triages and prioritizes vulnerabilities with CISA's Stakeholder-Specific Vulnerability Categorization (SSVC) decision tree, weighing exploitation status (via the CISA KEV catalog and FIRST EPSS API), technical impact, automatability, and mission prevalence to output Track\u002FTrack*\u002FAttend\u002FAct decisions. Use when prioritizing vulnerability scan results (OpenVAS, Nessus, Qualys) for remediation planning beyond raw CVSS scores.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Ftriaging-vulnerabilities-with-ssvc-framework\u002FSKILL.md",[218],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[220,221,222,42,223,224,225,226,227,228,229,230,231,232,233,234,235,236,237,238],"vulnerabilities","framework","triaging vulnerabilities with ssvc framework","status","planning","CISA","vulnerability-management","risk-management","nessus","qualys","openvas","cvss","remediation","risk","vulnerability","api","prioritization","ssvc","decision-tree",{"skillNo":240,"name":241,"nameZh":6,"description":242,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":243,"categories":244,"keywords":246,"publishedAt":44},"01M6AGD24TTQQM4CXG69E3B9TJ","triaging-security-incident","Performs initial triage of security incidents using the NIST SP 800-61r3 and SANS PICERL frameworks, classifying incident type, assigning priority by business impact, and routing to the appropriate response team. Use when a SIEM\u002FEDR alert needs human classification, concurrent alerts must be prioritized, or a user report or threat-intel IOC match requires initial incident categorization.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Ftriaging-security-incident\u002FSKILL.md",[245],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[43,247,42,248,249,250,251,252,253,254,255,28,256,182,257,258,259,260,261,262],"triaging security incident","siem","file","ioc","soc","NIST-800-61","NIST","severity","edr","execution","analysis","classification","severity-classification","incident-triage","SANS-PICERL","SOC-operations"]