create-attack-technique

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 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:

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:

output "warmup_short_id" {
  value = var.correlation.short
}

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:

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:

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.