Skip to main content

create-attack-technique

Create or review Stratus Red Team attack techniques. Use when asked to add, create, or implement a new attack technique for AWS, Azure, GCP, Entra ID, EKS, or Kubernetes in the stratus-red-team project. Also use when reviewing PRs or code that implements attack techniques — the guidelines serve as a review checklist.

跳到安装

来源信息

仓库
DataDog/stratus-red-team
最近来源活动
2026年9月11日 12:01
检测到的 SKILL.md 语言
英语
星标
2,398
分支
324

安装方式

默认使用会先检查来源的 Prompt;你也可以切换为直接命令,或下载本地副本。

检查来源文件

决定是否安装前,请先阅读 SKILL.md,以及 SkillsMP 当前展示的配套文件。

文件资源管理器
3 个文件

正在显示 SKILL.md

SKILL.md
来源说明 · 只读预览
name
create-attack-technique
description
Create or review Stratus Red Team attack techniques. Use when asked to add, create, or implement a new attack technique for AWS, Azure, GCP, Entra ID, EKS, or Kubernetes in the stratus-red-team project. Also use when reviewing PRs or code that implements attack techniques — the guidelines serve as a review checklist.
## Overview Each attack technique is composed of two files, which should be stored in `v2/internal/attacktechniques/<platform>/<mitre-attack-tactic>/<name>` (e.g., `v2/internal/attacktechniques/aws/defense-evasion/cloudtrail-delete/`): - `main.go`, containing the imperative attack logic - most of the time, `main.tf` containing prerequisite infrastructure. The lifecycle of an attack technique in Stratus Red Team is: - COLD - WARM: The prerequisite infrastructure is ready. - DETONATED: The attack technique was detonated. ## Guiding principles - An attack technique should be granular, meaning that it should emulate a single step of an attack. - Good: Share an EBS snapshot with an external AWS account. - Bad: Use an IAM access key to perform privilege escalation, run discovery commands, take an EBS snapshot of an instance, share the EBS snapshot with an external AWS account. - Techniques should emulate plausible and documented attacker behavior - An attack technique should not be dependent on the state of the cloud environment it's run against. ## Instructions When **creating** a new technique, follow the workflow below step by step. When **reviewing** a PR or existing technique, use the guidelines below as a checklist to verify correctness and consistency. ### Create the prerequisite infrastructure in the Terraform file #### Provider versions and configurations to use See [references/provider-configs.md](references/provider-configs.md) for the required Terraform provider blocks for each platform (AWS, Azure, Entra ID, GCP, Kubernetes). #### Concurrent detonation: use var.correlation.short in resource names A `variable "correlation"` block is **automatically injected** alongside your `main.tf` at warmup time — you do not need to declare it. It provides: - `var.correlation.id` — the full correlation UUID (used in tags/labels for signal matching) - `var.correlation.short` — an 8-character short form, safe to embed in resource names **Every resource with a globally or region-scoped name must embed `var.correlation.short`** so that concurrent executions of the same technique do not collide. The standard pattern is: ```hcl locals { resource_prefix = "stratus-red-team-<technique-name>-${var.correlation.short}" } resource "aws_iam_role" "role" { name = "${local.resource_prefix}-role" } ``` #### Go-created detonation artifacts If the technique creates resources **in Go** (not Terraform) during `detonate`, their names must also carry the correlation short ID. Since the Go code cannot access `var.correlation.short` directly, expose it as a Terraform output and read it from `params`: ```hcl output "warmup_short_id" { value = var.correlation.short } ``` ```go func detonate(params map[string]string, providers stratus.CloudProviders) error { shortID := params["warmup_short_id"] resourceName := fmt.Sprintf("my-technique-%s", shortID) // ... } ``` This value is persisted at warmup and read back at detonate/revert, so it stays stable across commands even when no correlation ID is set. When you're done, format your Terraform file using: ```bash terraform fmt -write v2/internal/attacktechniques/<platform>/<tactic>/<name>/main.tf ``` #### Use of outputs - Any outputs you defined will be passed to the Go file, which can consume them from the `detonate` and `revert` functions, e.g. `params["output_name"]`. - The value of the `display` output is displayed back to the user on the CLI. Example: ```hcl output "display" { value = format("%s Secrets Manager secrets ready", local.num_secrets) } ``` ### Write the Go detonation code #### Skeleton See `assets/sample-attack-technique.go` #### Guidelines for Go detonation code - As much as possible, use the official cloud providers' Go SDK. - For AWS, use the AWS SDK for Go v2. - Leverage methods from the injected 'providers' objects to instantiate cloud providers' SDK. Examples below - AWS CloudTrail: `cloudtrail.NewFromConfig(providers.AWS().GetConnection())` - Azure Network: `client, err := armnetwork.NewClientFactory(providers.Azure().SubscriptionID, providers.Azure().GetCredentials(), providers.Azure().ClientOptions)` - GCP IAM: `service, err := iam.NewService(ctx, providers.GCP().Options())` #### Error handling - Always return errors from `detonate` and `revert` — never use `log.Fatalf()`. - Use `fmt.Errorf("failed to <action>: %w", err)` for error wrapping. - Log the operation being attempted before making the API call with `log.Println`. #### Revert function If the detonation is reversible, implement a `revert` function that undoes the changes made by `detonate`. This allows the technique to be cleaned up after use. The `revert` function has the same signature as `detonate`: `func revert(params map[string]string, providers stratus.CloudProviders) error`. See `assets/sample-attack-technique.go` for an example. #### Guideline for documentation fields - `ID` should always be of the form `platform.mitre-attack-tactic.name`, e.g. `aws.defense-evasion.cloudtrail-delete` - `FriendlyName` should always start with a verb, and be in the infinitive form. - Bad: `S3 ransomware`, `Creates S3 ransomware` - Good: `Simulate S3 ransomware` - `Description` should contain at least an intro sentence and a Warm-up, Detonation, References section. "References" should ideally be examples of usage/sightings of this technique in the wild, or relevant cloud provider documentation. Example: ``` Establishes persistence by creating a service account key on an existing service account. Warm-up: - Create a service account Detonation: - Create a new key for the service account References: - https://expel.com/blog/incident-report-spotting-an-attacker-in-gcp/ - https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/ ``` - `Detection` should describe how to detect this technique, including relevant CloudTrail/audit log event names and any managed detection rules (e.g. GuardDuty finding types). Use HTML for formatting since it renders in the docs. Example: ``` Identify when a CloudTrail trail is disabled, through CloudTrail's <code>StopLogging</code> event. GuardDuty also provides a dedicated finding type, <a href="https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-iam.html#stealth-iam-cloudtrailloggingdisabled">Stealth:IAMUser/CloudTrailLoggingDisabled</a>. ``` - `IsIdempotent`: set to `true` if the detonation can be called multiple times without side effects. #### Add your new Go file to the imported attack techniques Add a new import corresponding to your new Go file in `v2/internal/attacktechniques/main.go`. #### Format your go code Run: ``` cd v2 # if you're not already in there go fmt ./... ``` ### Autogenerate docs ``` make docs ``` ## DON'T - Don't persist anything in the Go detonation code. The revert and detonate methods are called in different runs, so they cannot use variables to share state.
在 GitHub 查看