redc

RedC — Red Team Infrastructure Multi-Cloud Automated Deployment

RedC is an open-source red team infrastructure multi-cloud automated deployment tool. It uses Terraform under the hood to manage cloud resources across 6+ cloud providers.

GitHub: https://github.com/wgpsec/redc Template Registry: https://redc.wgpsec.org

Security & Credentials

Credential Model

RedC reads cloud provider credentials from environment variables or a local config.yaml file managed by the redc CLI. Credentials are only passed to Terraform, which communicates directly with cloud provider APIs over HTTPS. No credentials are sent to the redc project, the template registry, or any third-party service.

The metadata declares ALICLOUD_ACCESS_KEY and ALICLOUD_SECRET_KEY as the example required env vars because Alibaba Cloud is the most commonly used provider. However, you should substitute these with the credentials for whichever single provider you actually use. The full list of provider-specific env vars that RedC/Terraform may read:

| Provider | Environment Variables | Notes | |----------|----------------------|-------| | Alibaba Cloud | ALICLOUD_ACCESS_KEY, ALICLOUD_SECRET_KEY, ALICLOUD_REGION | Declared in metadata | | AWS | AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_DEFAULT_REGION | Set only if using AWS | | Tencent Cloud | TENCENTCLOUD_SECRET_ID, TENCENTCLOUD_SECRET_KEY | Set only if using Tencent | | Volcengine | VOLCENGINE_ACCESS_KEY, VOLCENGINE_SECRET_KEY | Set only if using Volcengine | | Huawei Cloud | HW_ACCESS_KEY, HW_SECRET_KEY | Set only if using Huawei | | Azure | ARM_CLIENT_ID, ARM_CLIENT_SECRET, ARM_TENANT_ID, ARM_SUBSCRIPTION_ID | Set only if using Azure |

You do NOT need to set all of these. Only configure the env vars for the single provider you intend to deploy to. RedC will not attempt to read or use credentials for providers you are not deploying to.

Credential Best Practices

• Use scoped, short-lived credentials with minimal permissions (e.g., only ECS/EC2 create/delete, no IAM/billing access).
• Test in isolated/throwaway cloud accounts to avoid impacting production resources.
• Do NOT paste long-lived root/owner keys into chat — configure them via redc CLI or environment variables before using this skill.
• Prefer scoped IAM roles or temporary security tokens (e.g., AWS STS AssumeRole) over static AK/SK pairs.

Binary Verification

• Download redc only from official GitHub releases: https://github.com/wgpsec/redc/releases — verify SHA256 checksums listed in each release.
• Download terraform only from HashiCorp: https://developer.hashicorp.com/terraform/downloads — verify PGP signatures.

Template Safety — IMPORTANT

Templates define the actual cloud infrastructure that will be created. They may contain:

• remote-exec provisioners that run arbitrary scripts on created instances
• user_data / cloud-init scripts that execute on instance boot
• Security group rules that open network ports (e.g., 0.0.0.0/0 ingress)
• local-exec provisioners that run commands on your local machine

Before applying any template, you MUST:

1. Inspect the template source — Run get_template_info to view the template's main.tf, variables.tf, and other files. Read them to understand what resources will be created.
2. Use plan_case first — This runs terraform plan to show a preview of all resources that will be created, modified, or destroyed. Review the plan output before proceeding to start_case.
3. Audit registry templates — The official template repository is fully open-source at https://github.com/wgpsec/redc-template. Compare pulled templates against the source to ensure they have not been tampered with.
4. Do NOT blindly apply — Never run start_case without first reviewing the plan. This skill will always use plan_case before start_case to give you a chance to review.

MCP Server Exposure

• The built-in MCP server defaults to stdio transport (local only, no network exposure).
• The sse mode binds to a configurable address — always restrict it to 127.0.0.1 and do not expose it to untrusted networks.

When to Use This Skill

Use this skill when the user wants to:

• Deploy cloud infrastructure (ECS, EC2, CVM, proxy pools, C2 servers, etc.)
• Manage running cloud instances (start, stop, destroy)
• Execute commands on remote servers via SSH
• Check cloud account balances and billing
• Estimate deployment costs
• Schedule automated start/stop for cloud resources
• Manage multi-cloud provider profiles and credentials
• Use redc-compose for multi-service orchestrated deployments

Supported Cloud Providers

| Provider | Template Prefix | Description | |----------|----------------|-------------| | Alibaba Cloud (阿里云) | aliyun/ | ECS, proxy, VPC, etc. | | AWS | aws/ | EC2, proxy, etc. | | Tencent Cloud (腾讯云) | tencent/ | CVM, lighthouse, etc. | | Volcengine (火山引擎) | volcengine/ | ECS, etc. | | Huawei Cloud (华为云) | huaweicloud/ | ECS, etc. | | Azure | azure/ | VM, etc. |

Architecture

RedC has two modes:

1. CLI mode (redc binary) — command-line operations
2. GUI mode (redc-gui) — desktop application with built-in MCP server

The MCP server exposes all tools below. It can run in stdio or sse mode.

Tools

1. list_templates

List all available redc templates/images installed locally.

Command:

redc list

MCP Tool: list_templates

Returns template names, descriptions, versions, and supported providers.

2. search_templates

Search for templates in the official registry by keywords.

Command:

redc search <query>

MCP Tool: search_templates

• query (string, required): Search query (e.g., "aliyun", "proxy", "ecs")
• registry_url (string, optional): Registry base URL (default: https://redc.wgpsec.org)

3. pull_template

Download a template from the registry.

Command:

redc pull <template_name>

MCP Tool: pull_template

• template_name (string, required): Template name (e.g., "aliyun/ecs" or "aliyun/ecs:1.0.1")
• registry_url (string, optional): Registry base URL
• force (boolean, optional): Force re-download even if template exists

4. list_cases

List all cases (scenes/deployments) in the current project with their status.

Command:

redc ps

MCP Tool: list_cases

Returns case ID, name, status (created/running/stopped/error/terminated), template type, and creation time.

Status values:

• created — case planned but not yet applied
• running — infrastructure is live
• stopped — infrastructure destroyed, state preserved
• error — deployment failed
• terminated — spot instance was reclaimed

5. plan_case

Plan a new case from a template (preview resources without creating them).

Command:

redc plan <template_name> [--name <case_name>] [--var key=value ...]

MCP Tool: plan_case

• template_name (string, required): Template name (e.g., "aliyun/ecs")
• case_name (string, optional): Case name (auto-generated if not provided)
• vars (string, optional): Environment variables for the template

6. start_case

Start (apply) a case — creates the cloud infrastructure.

Command:

redc up <case_id>

MCP Tool: start_case

• case_id (string, required): Case ID to start

7. stop_case

Stop (destroy) a case — tears down the cloud infrastructure.

Command:

redc down <case_id>

MCP Tool: stop_case

• case_id (string, required): Case ID to stop

8. kill_case

Remove a case completely (destroy infrastructure + delete all local state).

Command:

redc rm <case_id>

MCP Tool: kill_case

• case_id (string, required): Case ID to remove

9. get_case_status

Get detailed status of a specific case.

MCP Tool: `get_case