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

src/pentesting-cloud/pentesting-cloud-methodology.md

@@ -4,41 +4,41 @@
 
 <figure><img src="../images/CLOUD-logo-letters.svg" alt=""><figcaption></figcaption></figure>
 
-## मूल कार्यप्रणाली
+## बुनियादी कार्यप्रणाली
 
-हर क्लाउड की अपनी विशेषताएँ होती हैं लेकिन सामान्य तौर पर कुछ **सामान्य चीज़ें जिन्हें एक pentester को जांचना चाहिए** होती हैं जब एक क्लाउड वातावरण की जाँच की जा रही हो:
+प्रत्येक क्लाउड की अपनी विशेषताएँ होती हैं लेकिन सामान्यतः कुछ **सामान्य बातें हैं जो एक pentester को जांचनी चाहिए** जब क्लाउड पर्यावरण का परीक्षण कर रहा हो:
 
-- **बेंचमार्क जांच**
-- यह आपको वातावरण का **आकार समझने** और **उपयोग की जा रही सेवाओं** का पता लगाने में मदद करेगा
-- यह आपको कुछ **त्वरित गलत कॉन्फ़िगरेशन** भी खोजने की अनुमति देगा क्योंकि आप इन परीक्षणों में से अधिकांश **स्वचालित टूल्स** के साथ चला सकते हैं
+- **बेंचमार्क चेक्स**
+- यह आपकी मदद करेगा **पर्यावरण के आकार** और **उपयोग की जाने वाली सेवाओं** को समझने में
+- यह आपको कुछ **त्वरित misconfigurations** खोजने में भी मदद करेगा क्योंकि आप इनमें से अधिकांश परीक्षण **automated tools** के साथ कर सकते हैं
 - **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 होगी तो उसे कौन सी संवेदनशील जानकारी और एक्सेस मिलेंगे।
+- यदि आपने बेंचमार्क टेस्ट सही तरीके से किए हैं तो यहाँ शायद ज्यादा misconfigurations नहीं मिलेंगे, पर कुछ ऐसे मिल सकते हैं जिन्हें बेंचमार्क टेस्ट में नहीं देखा गया था।
+- यह आपको बताएगा कि क्लाउड env में **ठीक-ठीक क्या इस्तेमाल हो रहा है**
+- यह अगले चरणों में बहुत मदद करेगा
+- **Check exposed assets**
+- यह पिछले सेक्शन के दौरान भी किया जा सकता है, आपको **हर उस चीज़ का पता लगाना होगा जो किसी न किसी तरह से Internet के लिए सम्भवतः exposed है** और उसे कैसे access किया जा सकता है।
+- यहाँ मैं **मैनुअली एक्सपोज्ड infrastructure** की बात कर रहा हूँ जैसे instances जिनमें web pages या अन्य ports एक्सपोज़ हैं, और साथ ही उन अन्य **cloud managed services** के बारे में जो एक्सपोज़ होने के लिए configure की जा सकती हैं (जैसे DBs या buckets)
+- फिर आपको चेक करना चाहिए **क्या वह resource एक्सपोज़ हो सकता है या नहीं** (गोपनीय जानकारी? vulnerabilities? exposed service में misconfigurations?)
+- **Check permissions**
+- यहाँ आपको **क्लाउड के अंदर हर role/user की सभी permissions** पता करनी चाहिए और वे कैसे उपयोग हो रहे हैं
+- बहुत सारे **highly privileged** (सब कुछ नियंत्रित करने वाले) accounts? Generated keys जो उपयोग नहीं हो रहे?... इनमें से अधिकांश चेक पहले से बेंचमार्क टेस्ट में किए जाने चाहिए थे
+- यदि क्लाइंट OpenID या SAML या कोई अन्य **federation** उपयोग कर रहा है तो आपको उनसे और **जानकारी** माँगनी पड़ सकती है कि **प्रत्येक role कैसे assign किया जा रहा है** (यह एक जैसा नहीं है कि admin role 1 user को assign है या 100 को)
+- यह सिर्फ यह पता लगाने के लिए पर्याप्त नहीं है कि किस user के पास **admin** permissions "\*:\*". हैं। बहुत सारी **अन्य permissions** भी हैं जो उपयोग की जाने वाली सेवाओं के आधार पर बहुत **संवेदनशील** हो सकती हैं।
+- इसके अलावा, permissions का दुरुपयोग करके अनुसरण करने योग्य **potential privesc** तरीके भी होते हैं। इन सभी चीज़ों को ध्यान में रखा जाना चाहिए और जितना संभव हो उतने privesc paths रिपोर्ट किए जाने चाहिए।
+- **Check Integrations**
+- यह बहुत संभव है कि **अन्य क्लाउड्स या SaaS के साथ integrations** क्लाउड env के अंदर इस्तेमाल हो रहे हों।
+- उस क्लाउड के लिए **जो आप ऑडिट कर रहे हैं** अन्य platform के साथ integrations के लिए आपको यह सूचित करना चाहिए **कि किसके पास उस integration का (ab)use करने का access है** और आपको पूछना चाहिए कि किया जा रहा action कितना **संवेदनशील** है।\
+उदाहरण के लिए, कौन AWS bucket में लिख सकता है जहाँ से GCP data ले रहा है (पूछें कि GCP में उस data का उपचार करते समय action कितना संवेदनशील है)।
+- जिस क्लाउड को आप ऑडिट कर रहे हैं उसके अंदर से external platforms से होने वाले **integrations** के लिए, आपको पूछना चाहिए **बाहरी रूप से किसके पास उस integration का (ab)use करने का access है** और जाँचना चाहिए कि वह data कैसे उपयोग हो रहा है।\
+उदाहरण के लिए, यदि कोई service GCR में host किए गए Docker image का उपयोग कर रही है, तो आपको पूछना चाहिए कि किसके पास उसे modify करने का access है और वह image जब AWS क्लाउड के अंदर execute होगा तो उसे कौन-सी संवेदनशील जानकारी और access मिलेंगे।
 
-## Multi-Cloud टूल्स
+## Multi-Cloud tools
 
-कई टूल्स हैं जिनका उपयोग विभिन्न क्लाउड परिवेशों का परीक्षण करने के लिए किया जा सकता है। इनसे संबंधित इंस्टॉलेशन चरण और लिंक इस खंड में दिए जाएंगे।
+ऐसे कई tools हैं जिनका उपयोग विभिन्न क्लाउड environments को टेस्ट करने के लिए किया जा सकता है। इस सेक्शन में installation steps और links बताए जाएंगे।
 
 ### [PurplePanda](https://github.com/carlospolop/purplepanda)
 
-एक टूल जो क्लाउड्स और क्लाउड्स/SaaS के पार **bad configurations और privesc path** की पहचान करने के लिए है।
+A tool to **identify bad configurations and privesc path in clouds and across clouds/SaaS.**
 
 {{#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** को सपोर्ट करता है। प्रत्येक provider को कॉन्फ़िगर करने का तरीका देखें: [https://docs.prowler.cloud/en/latest/#aws](https://docs.prowler.cloud/en/latest/#aws)
 ```bash
 # Install
 pip install prowler
@@ -170,7 +170,7 @@ steampipe check all
 
 <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 इनसाइट्स** (useful for enumerating services) देखने के लिए उपयोग करें: [https://github.com/turbot/steampipe-mod-gcp-insights](https://github.com/turbot/steampipe-mod-gcp-insights)
+**अन्य GCP insights** (सेवाओं को enumerate करने के लिए उपयोगी) जाँचने के लिए उपयोग करें: [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 code जाँचने के लिए: [https://github.com/turbot/steampipe-mod-terraform-gcp-compliance](https://github.com/turbot/steampipe-mod-terraform-gcp-compliance)
 
-Steampipe के अन्य GCP plugins: [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" }}
@@ -227,22 +227,22 @@ steampipe check all --export=/tmp/output4.json
 ```
 Terraform AWS code देखने के लिए: [https://github.com/turbot/steampipe-mod-terraform-aws-compliance](https://github.com/turbot/steampipe-mod-terraform-aws-compliance)
 
-Steampipe के अधिक AWS plugins: [https://github.com/orgs/turbot/repositories?q=aws](https://github.com/orgs/turbot/repositories?q=aws)
+Steampipe के और AWS प्लगइन्स: [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। **Azure** में कुछ अतिरिक्त कॉन्फ़िगरेशन्स चाहिए ताकि **Client Id** प्राप्त किया जा सके।
+Nessus में _**Audit Cloud Infrastructure**_ स्कैन है जो इनका समर्थन करता है: AWS, Azure, Office 365, Rackspace, Salesforce. एक **Client Id** प्राप्त करने के लिए **Azure** में कुछ अतिरिक्त कॉन्फ़िगरेशन की आवश्यकता होती है।
 
 ### [**cloudlist**](https://github.com/projectdiscovery/cloudlist)
 
-Cloudlist एक **मल्टी-क्लाउड टूल है जो Assets प्राप्त करता है** (Hostnames, IP Addresses) जो Cloud Providers से होता है।
+Cloudlist Cloud Providers से Assets (Hostnames, IP Addresses) प्राप्त करने के लिए एक **multi-cloud tool for getting Assets** है।
 
 {{#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 applications, security controls और अन्य शामिल हैं, और इन्हें Neo4j database द्वारा समर्थित एक सहज ग्राफ़ दृश्य में प्रस्तुत करता है।
+Starbase सेवाओं और प्रणालियों — जिनमें क्लाउड इन्फ्रास्ट्रक्चर, SaaS applications, सुरक्षा नियंत्रण और अन्य शामिल हैं — से संपत्तियाँ और संबंध इकट्ठा करता है और उन्हें Neo4j डेटाबेस द्वारा समर्थित एक सहज ग्राफ दृश्य में प्रस्तुत करता है।
 
 {{#tabs }}
 {{#tab name="Install" }}
@@ -361,7 +361,7 @@ uri: bolt://localhost:7687
 
 ### [**SkyArk**](https://github.com/cyberark/SkyArk)
 
-स्कैन किए गए AWS या Azure environment में सबसे अधिक privileged users की खोज करें, जिसमें AWS Shadow Admins भी शामिल हैं। यह powershell का उपयोग करता है।
+स्कैन किए गए AWS या Azure environment में सबसे अधिक privileged users का पता लगाएं, जिनमें AWS Shadow Admins भी शामिल हैं। यह powershell का उपयोग करता है।
 ```bash
 Import-Module .\SkyArk.ps1 -force
 Start-AzureStealth
@@ -372,13 +372,13 @@ Scan-AzureAdmins
 ```
 ### [Cloud Brute](https://github.com/0xsha/CloudBrute)
 
-एक टूल जो किसी कंपनी (target) के infrastructure, files और apps को शीर्ष क्लाउड प्रदाताओं (Amazon, Google, Microsoft, DigitalOcean, Alibaba, Vultr, Linode) पर खोजने के लिए है।
+एक टूल जो top cloud providers (Amazon, Google, Microsoft, DigitalOcean, Alibaba, Vultr, Linode) पर किसी company (target) की infrastructure, files और apps खोजने के लिए है।
 
 ### [CloudFox](https://github.com/BishopFox/cloudfox)
 
-- CloudFox एक टूल है जो क्लाउड infrastructure में exploitable attack paths खोजने के लिए है (वर्तमान में केवल AWS & Azure समर्थित हैं, GCP जल्द आ रहा है)।
-- यह एक enumeration tool है जिसे manual pentesting की पूरकता के लिए बनाया गया है।
-- यह क्लाउड environment के भीतर कोई भी data बनाता या संशोधित नहीं करता।
+- CloudFox cloud infrastructure में exploitable attack paths खोजने के लिए एक टूल है (वर्तमान में केवल AWS & Azure समर्थित हैं, GCP जल्द जोड़ा जाएगा)।
+- यह एक enumeration टूल है जो manual pentesting की पूरकता के लिए बनाया गया है।
+- यह cloud environment के भीतर किसी भी डेटा को create या modify नहीं करता।
 
 ### More lists of cloud security tools
 
@@ -412,11 +412,10 @@ azure-security/
 
 ### Attack Graph
 
-[**Stormspotter** ](https://github.com/Azure/Stormspotter) Azure subscription में resources का “attack graph” बनाता है। यह red teams और pentesters को एक tenant के भीतर attack surface और pivot opportunities को visualize करने में सक्षम बनाता है, और आपके defenders को incident response के काम को तेजी से व्यवस्थित और प्राथमिकता देने में अतिरिक्त गति देता/देती है।
+[**Stormspotter** ](https://github.com/Azure/Stormspotter) Azure subscription में resources का “attack graph” बनाता है। यह red teams और pentesters को tenant के भीतर attack surface और pivot अवसरों को दृश्य रूप से देखने में सक्षम बनाता है, और आपके defenders को incident response कार्यों को तेजी से व्यवस्थित और प्राथमिकता देने में बहुत मदद करता है।
 
 ### Office365
 
-आपको **Global Admin** या कम से कम **Global Admin Reader** की आवश्यकता होती है (हालाँकि ध्यान दें कि Global Admin Reader थोड़ी सीमित है)। हालांकि, ये सीमाएँ कुछ PS modules में दिखाई देती हैं और इन्हें **वेब एप्लिकेशन के माध्यम से** फीचर्स तक पहुँच कर बायपास किया जा सकता है।
-
+आपको **Global Admin** या कम से कम **Global Admin Reader** की आवश्यकता है (ध्यान दें कि Global Admin Reader कुछ हद तक सीमित है)। हालाँकि, ये सीमाएँ कुछ PS modules में दिखाई देती हैं और इन्हें features को **via the web application** के माध्यम से एक्सेस करके बायपास किया जा सकता है।
 
 {{#include ../banners/hacktricks-training.md}}