diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-exchange-hybrid-impersonation.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-exchange-hybrid-impersonation.md index 0c4d1b899..80bf23d08 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-exchange-hybrid-impersonation.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-exchange-hybrid-impersonation.md @@ -4,44 +4,44 @@ ## बुनियादी जानकारी -पुराने Exchange Hybrid डिज़ाइनों में, on-prem Exchange deployment उसी Entra application identity के रूप में authenticate कर सकता था जिसका इस्तेमाल Exchange Online करता था। अगर कोई attacker Exchange server को compromise कर ले, hybrid certificate का private key extract कर ले, और OAuth client-credentials flow करे, तो वह Exchange Online privilege context वाले first-party tokens प्राप्त कर सकता था। +पुराने Exchange Hybrid डिजाइनों में, on-prem Exchange deployment उसी Entra application identity के रूप में authenticate कर सकती थी जो Exchange Online द्वारा उपयोग की जाती थी। यदि एक attacker ने Exchange सर्वर compromise कर लिया, hybrid certificate private key निकाल ली, और एक OAuth client-credentials flow किया, तो वे Exchange Online privilege context वाले first-party tokens प्राप्त कर सकते थे। -व्यवहारिक जोखिम सिर्फ mailbox access तक सीमित नहीं था। चूंकि Exchange Online के पास व्यापक back-end trust relationships थीं, यह identity अतिरिक्त Microsoft 365 सेवाओं के साथ interact कर सकती थी और पुराने व्यवहार में, इसे deeper tenant compromise के लिए leverage किया जा सकता था। +व्यावहारिक जोखिम केवल mailbox पहुँच तक सीमित नहीं था। क्योंकि Exchange Online का बैक-एंड पर व्यापक ट्रस्ट रिश्ते थे, यह identity अतिरिक्त Microsoft 365 सेवाओं के साथ इंटरैक्ट कर सकती थी और पुराने व्यवहार में इसे गहरे tenant compromise के लिए भी उपयोग किया जा सकता था। -## हमला मार्ग और तकनीकी प्रवाह +## हमले के रास्ते और तकनीकी प्रवाह -### Exchange के माध्यम से Federation Configuration बदलना +### Exchange के माध्यम से Federation कॉन्फ़िगरेशन में बदलाव -Exchange tokens historically में domain/federation settings लिखने की permissions रखते थे। एक attacker के नजरिए से, इससे federated domain trust data का सीधे manipulation संभव था, जिसमें token-signing certificate lists और वे configuration flags शामिल थे जो on-prem federation infrastructure से आने वाले MFA-claim की acceptance को नियंत्रित करते थे। +Exchange tokens ऐतिहासिक रूप से domain/federation settings लिखने की permissions रखते थे। हमलावर के दृष्टिकोण से, इससे federated domain trust डेटा, जैसे token-signing certificate lists और उन configuration flags का सीधे समायोजन संभव हो जाता था जो on-prem federation infrastructure से आने वाले MFA-claim की स्वीकार्यता को नियंत्रित करते थे। -इसका मतलब यह था कि compromise किया गया Exchange Hybrid server क्लाउड साइड से federation config बदलकर ADFS-style impersonation का staging या reinforcement करने के लिए इस्तेमाल किया जा सकता था, भले ही attacker ने केवल on-prem Exchange compromise से ही शुरुआत की हो। +इसका मतलब है कि compromised Exchange Hybrid server का उपयोग cloud साइड से federation config बदलकर ADFS-style impersonation को stage या मजबूत करने के लिए किया जा सकता था, भले ही attacker सिर्फ on-prem Exchange compromise से शुरू हुआ हो। ### ACS Actor Tokens और Service-to-Service Impersonation -Exchange के hybrid auth path ने Access Control Service (ACS) actor tokens का उपयोग किया जिनमें `trustedfordelegation=true` था। उन actor tokens को फिर एक दूसरे, unsigned service token में embed किया जाता था जो target user identity को attacker-controlled section में रखता था। चूँकि outer token unsigned था और actor token व्यापक रूप से delegated था, caller बिना फिर से authenticate किए target users को swap कर सकता था। +Exchange का hybrid auth path Access Control Service (ACS) actor tokens का उपयोग करता था जिनमें `trustedfordelegation=true` था। उन actor tokens को फिर एक दूसरे, unsigned service token में embed किया जाता था जो target user identity को attacker-controlled सेक्शन में रखता था। चूंकि outer token unsigned था और actor token व्यापक रूप से delegated था, caller बिना पुनः प्रमाणीकृत किए target users बदल सकता था। -व्यवहार में, एक बार actor token प्राप्त हो जाने पर, attacker के पास एक long-lived impersonation primitive (आमतौर पर ~24 घंटे) था जिसे उसके जीवनकाल के बीच revoke करना मुश्किल होता था। इससे Exchange Online और SharePoint/OneDrive APIs में user impersonation संभव हुआ, जिसमें high-value data exfiltration भी शामिल था। +व्यवहार में, एक बार actor token प्राप्त हो जाने पर, attacker के पास एक long-lived impersonation primitive होता था (आम तौर पर लगभग 24 hours) जिसे lifetime के बीच में revoke करना मुश्किल होता था। इससे Exchange Online और SharePoint/OneDrive APIs में user impersonation संभव हो जाती थी, जिसमें high-value data exfiltration भी शामिल था। -ऐतिहासिक रूप से, वही पैटर्न `graph.windows.net` के खिलाफ भी काम करता था, जहाँ victim के `netId` वैल्यू के साथ impersonation token बनाकर सीधे Entra administrative action arbitrary users के रूप में की जा सकती थी और full-tenant takeover workflows संभव होते थे (उदाहरण के लिए, नया Global Administrator account बनाना)। +ऐतिहासिक रूप से, यही पैटर्न `graph.windows.net` के खिलाफ भी काम करता था, जहां victim के `netId` मान के साथ एक impersonation token बनाया जाता था। इससे arbitrary users के रूप में सीधे Entra administrative action मिल सकती थी और full-tenant takeover workflows सक्षम होते थे (उदाहरण के लिए, एक नया Global Administrator account बनाना)। ## अब क्या काम नहीं करता -Exchange Hybrid actor tokens के माध्यम से `graph.windows.net` impersonation path को ठीक कर दिया गया है। पुराने "Exchange to arbitrary Entra admin over Graph" chain को इस विशिष्ट token route के लिए हटाया गया माना जाना चाहिए। +`graph.windows.net` impersonation path जो Exchange Hybrid actor tokens के माध्यम से था, उसे ठीक कर दिया गया है। पुराना "Exchange to arbitrary Entra admin over Graph" chain इस विशिष्ट token route के लिए हटा हुआ माना जाना चाहिए। -यह इस attack का डॉक्युमेंट करते समय सबसे महत्वपूर्ण सुधार है: Exchange/SharePoint impersonation जोखिम को अब-पैच किये गए Graph impersonation escalation से अलग रखें। +यह attack का दस्तावेजीकरण करते समय सबसे महत्वपूर्ण सुधार है: Exchange/SharePoint impersonation जोखिम को अब-पैच्ड Graph impersonation escalation से अलग रखें। ## व्यवहार में क्या अभी भी मायने रखता है -यदि कोई संगठन अभी भी shared trust और exposed certificate material के साथ पुरानी या incomplete hybrid configuration चला रहा है, तो Exchange/SharePoint impersonation का प्रभाव गंभीर रह सकता है। federation-configuration abuse वाला कोण भी tenant के setup और migration state पर निर्भर करते हुए प्रासंगिक रह सकता है। +यदि कोई संगठन अभी भी साझा ट्रस्ट और exposed certificate material वाले पुराने या अधूरे hybrid configuration चला रहा है, तो Exchange/SharePoint impersonation का प्रभाव गंभीर बना रह सकता है। federation-configuration abuse कोण भी tenant setup और migration स्थिति पर निर्भर करते हुए प्रासंगिक रह सकता है। -Microsoft की लंबी अवधि की mitigation on-prem और Exchange Online identities को अलग करना है ताकि shared-service-principal trust path मौजूद न रहे। जिन वातावरणों ने वह migration पूरा कर लिया है, वे इस attack surface को महत्वपूर्ण रूप से घटाते हैं। +Microsoft का दीर्घकालिक निवारण on-prem और Exchange Online identities को अलग करना है ताकि shared-service-principal trust path मौजूद न रहे। जिन वातावरणों ने वह migration पूरा कर लिया है वे इस attack surface को महत्वपूर्ण रूप से कम कर देते हैं। ## डिटेक्शन नोट्स -जब इस technique का दुरुपयोग होता है, तो audit events में identity mismatches दिख सकते हैं जहाँ user principal name impersonated user से मेल खाता है जबकि display/source context Exchange Online activity की ओर इशारा करता है। यह mixed identity पैटर्न एक उच्च-मूल्य का hunting signal है, हालांकि defenders को false positives कम करने के लिए legitimate Exchange-admin workflows का baseline बनाना चाहिए। +जब इस technique का दुरुपयोग होता है, audit events में identity mismatches दिख सकते हैं जहाँ user principal name एक impersonated user के अनुरूप होता है जबकि display/source context Exchange Online गतिविधि की ओर इशारा करता है। यह mixed identity पैटर्न एक उच्च-मूल्य वाली hunting signal है, हालांकि defenders को false positives कम करने के लिए legitimate Exchange-admin workflows का baseline लेना चाहिए। -## References +## संदर्भ -- https://www.youtube.com/watch?v=rzfAutv6sB8 +- [https://www.youtube.com/watch?v=rzfAutv6sB8](https://www.youtube.com/watch?v=rzfAutv6sB8) {{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/workspace-security/gws-google-platforms-phishing/README.md b/src/pentesting-cloud/workspace-security/gws-google-platforms-phishing/README.md index bb950ca7b..611d0ae9b 100644 --- a/src/pentesting-cloud/workspace-security/gws-google-platforms-phishing/README.md +++ b/src/pentesting-cloud/workspace-security/gws-google-platforms-phishing/README.md @@ -10,51 +10,51 @@ https://book.hacktricks.wiki/en/generic-methodologies-and-resources/phishing-met ## Google Groups Phishing -स्पष्ट रूप से, डिफ़ॉल्ट रूप से, workspace सदस्यों [**समूह बना सकते हैं**](https://groups.google.com/all-groups) **और लोगों को आमंत्रित कर सकते हैं**। आप फिर उस ईमेल को संशोधित कर सकते हैं जो उपयोगकर्ता को भेजा जाएगा **कुछ लिंक जोड़कर।** **ईमेल एक गूगल पते से आएगा**, इसलिए यह **वैध** लगेगा और लोग लिंक पर क्लिक कर सकते हैं। +Apparently, by default, in workspace members [**can create groups**](https://groups.google.com/all-groups) **and invite people to them**. आप फिर उस ईमेल को संशोधित कर सकते हैं जो उपयोगकर्ता को भेजी जाएगी, **कुछ links जोड़कर।** वह **ईमेल एक google address से आएगी**, इसलिए यह **legit** लगेगी और लोग उस लिंक पर क्लिक कर सकते हैं। -यह भी संभव है कि **FROM** पते को **Google समूह ईमेल** के रूप में सेट किया जाए ताकि **समूह के अंदर उपयोगकर्ताओं को अधिक ईमेल भेजे जा सकें**, जैसे कि निम्नलिखित छवि में जहां समूह **`google--support@googlegroups.com`** बनाया गया था और समूह के सभी सदस्यों को **ईमेल भेजा गया** (जो बिना किसी सहमति के जोड़े गए थे) +यह भी संभव है कि **FROM** address को **Google group email** के रूप में सेट किया जाए ताकि समूह के अंदर के उपयोगकर्ताओं को **और अधिक ईमेल भेजी जा सकें**, जैसा कि नीचे की तस्वीर में जहाँ समूह **`google--support@googlegroups.com`** बनाया गया था और समूह के सभी सदस्यों को एक **ईमेल भेजी गई थी** (जो बिना किसी सहमति के जोड़े गए थे)
## Google Chat Phishing -आप किसी व्यक्ति के साथ **चैट शुरू करने** में सक्षम हो सकते हैं बस उनके ईमेल पते को लेकर या **बात करने के लिए आमंत्रण भेज सकते हैं**। इसके अलावा, यह संभव है कि **एक स्पेस बनाएँ** जिसका कोई भी नाम हो सकता है (जैसे "Google Support") और इसमें सदस्यों को **आमंत्रित करें**। यदि वे स्वीकार करते हैं तो वे सोच सकते हैं कि वे Google Support से बात कर रहे हैं: +You might be able to either **start a chat** with a person just having their email address or send an **invitation to talk**. Moreover, it's possible to **create a Space** that can have any name (e.g. "Google Support") and **invite** members to it. If they accept they might think that they are talking to Google Support:
> [!TIP] -> **हालांकि, मेरे परीक्षण में आमंत्रित सदस्यों को तो आमंत्रण भी नहीं मिला।** +> मेरे परीक्षण में हालांकि आमंत्रित सदस्यों को invitation भी प्राप्त नहीं हुआ। -आप देख सकते हैं कि यह पहले कैसे काम करता था: [https://www.youtube.com/watch?v=KTVHLolz6cE\&t=904s](https://www.youtube.com/watch?v=KTVHLolz6cE&t=904s) +You can check how this worked in the past in: [https://www.youtube.com/watch?v=KTVHLolz6cE\&t=904s](https://www.youtube.com/watch?v=KTVHLolz6cE&t=904s) ## Google Doc Phishing -पहले यह संभव था कि एक **स्पष्ट रूप से वैध दस्तावेज़** बनाया जाए और एक टिप्पणी में **कुछ ईमेल (जैसे @user@gmail.com)** का उल्लेख किया जाए। Google **उस ईमेल पते पर एक ईमेल भेजता था** यह सूचित करते हुए कि उन्हें दस्तावेज़ में उल्लेखित किया गया था।\ -आजकल, यह काम नहीं करता लेकिन यदि आप **शिकार को दस्तावेज़ तक पहुंच देते हैं** तो Google एक ईमेल भेजेगा जो यह संकेत करेगा। यह वह संदेश है जो तब दिखाई देता है जब आप किसी का उल्लेख करते हैं: +In the past it was possible to create an **apparently legitimate document** and the in a comment **mention some email (like @user@gmail.com)**. Google **sent an email to that email address** notifying that they were mentioned in the document.\ +Nowadays, this doesn't work but if you **give the victim email access to the document** Google will send an email indicating so. This is the message that appears when you mention someone:
> [!TIP] -> शिकारियों के पास सुरक्षा तंत्र हो सकता है जो यह अनुमति नहीं देता कि यह ईमेल उनके ईमेल तक पहुंचे जो यह संकेत करते हैं कि एक बाहरी दस्तावेज़ उनके साथ साझा किया गया था। +> Victims के पास सुरक्षा तंत्र हो सकते हैं जो बाहरी दस्तावेज़ साझा किए जाने की सूचनाएँ उनके ईमेल तक नहीं पहुँचने देतीं। ## Google Calendar Phishing -आप **एक कैलेंडर इवेंट** बना सकते हैं और जितने भी ईमेल पते हैं उन सभी को जोड़ सकते हैं जिनका आप हमला कर रहे हैं। इस कैलेंडर इवेंट को **वर्तमान समय से 5 या 15 मिनट** में शेड्यूल करें। इवेंट को वैध दिखाने के लिए बनाएं और **एक टिप्पणी और एक शीर्षक डालें जो यह संकेत करे कि उन्हें कुछ पढ़ना है** (साथ में **फिशिंग लिंक**). +You can **create a calendar event** and add as many email address of the company you are attacking as you have. Schedule this calendar event in **5 or 15 min** from the current time. Make the event look legit and **put a comment and a title indicating that they need to read something** (with the **phishing link**). -यह वह चेतावनी है जो ब्राउज़र में "Firing People" मीटिंग शीर्षक के साथ दिखाई देगी, इसलिए आप एक अधिक फिशिंग जैसा शीर्षक सेट कर सकते हैं (और यहां तक कि अपने ईमेल से जुड़े नाम को भी बदल सकते हैं)। +This is the alert that will appear in the browser with a meeting title "Firing People", so you could set a more phishing like title (and even change the name associated with your email).
-इसे कम संदिग्ध दिखाने के लिए: +To make it look less suspicious: -- इसे इस तरह सेट करें कि **प्राप्तकर्ता अन्य आमंत्रित लोगों को न देख सकें** -- **ईवेंट के बारे में सूचनाएं न भेजें**। फिर, लोग केवल 5 मिनट में एक मीटिंग के बारे में अपनी चेतावनी देखेंगे और उन्हें उस लिंक को पढ़ने की आवश्यकता होगी। -- स्पष्ट रूप से API का उपयोग करके आप **सत्य** सेट कर सकते हैं कि **लोगों ने** इवेंट को **स्वीकृत** किया है और यहां तक कि उनके पक्ष में **टिप्पणियाँ भी बना सकते हैं**। +- ऐसा सेट करें कि **receivers अन्य आमंत्रित लोगों को नहीं देख सकें** +- इवेंट के बारे में सूचित करने वाली ईमेल **मत भेजें**। फिर लोग केवल 5 मिनट में होने वाली मीटिंग की चेतावनी देखेंगे और यह कि उन्हें वह लिंक पढ़ना है। +- दिखाई देता है कि API का उपयोग करके आप सेट कर सकते हैं कि **people** ने इवेंट को **True / accepted** किया है और यहां तक कि उनकी ओर से **comments** भी बना सकते हैं। ## App Scripts Redirect Phishing -यह संभव है कि [https://script.google.com/](https://script.google.com/) में एक स्क्रिप्ट बनाई जाए और **इसे एक वेब एप्लिकेशन के रूप में उजागर किया जाए जो सभी के लिए सुलभ हो** जो वैध डोमेन **`script.google.com`** का उपयोग करेगा।\ -इसके साथ कुछ कोड जैसे निम्नलिखित एक हमलावर को इस पृष्ठ में मनमाने सामग्री को लोड करने के लिए स्क्रिप्ट बनाने की अनुमति दे सकता है बिना डोमेन तक पहुंच को रोके: +It's possible to create a script in [https://script.google.com/](https://script.google.com/) and **expose it as a web application accessible by everyone** that will use the legit domain **`script.google.com`**.\ +नीचे दिए गए जैसे कुछ code के साथ एक attacker उस script को इस पृष्ठ में arbitrary content लोड करने के लिए बना सकता है बिना domain तक पहुँचने को रोके: ```javascript function doGet() { return HtmlService.createHtmlOutput( @@ -62,100 +62,159 @@ return HtmlService.createHtmlOutput( ).setXFrameOptionsMode(HtmlService.XFrameOptionsMode.ALLOWALL) } ``` -उदाहरण के लिए [https://script.google.com/macros/s/AKfycbwuLlzo0PUaT63G33MtE6TbGUNmTKXCK12o59RKC7WLkgBTyltaS3gYuH_ZscKQTJDC/exec](https://script.google.com/macros/s/AKfycbwuLlzo0PUaT63G33MtE6TbGUNmTKXCK12o59RKC7WLkgBTyltaS3gYuH_ZscKQTJDC/exec) पर पहुँचने पर आप देखेंगे: +For example accessing [https://script.google.com/macros/s/AKfycbwuLlzo0PUaT63G33MtE6TbGUNmTKXCK12o59RKC7WLkgBTyltaS3gYuH_ZscKQTJDC/exec](https://script.google.com/macros/s/AKfycbwuLlzo0PUaT63G33MtE6TbGUNmTKXCK12o59RKC7WLkgBTyltaS3gYuH_ZscKQTJDC/exec) you will see:
> [!TIP] -> ध्यान दें कि जब सामग्री एक iframe के अंदर लोड होती है तो एक चेतावनी दिखाई देगी। +> ध्यान दें कि कंटेंट iframe के अंदर लोड होने पर एक चेतावनी दिखाई देगी। -## ऐप स्क्रिप्ट OAuth फ़िशिंग +## App Scripts OAuth Phishing -ऐप स्क्रिप्ट बनाना संभव है जो दस्तावेज़ों से जुड़े होते हैं ताकि पीड़ित के OAuth टोकन तक पहुँच प्राप्त करने की कोशिश की जा सके, अधिक जानकारी के लिए देखें: +यह संभव है कि दस्तावेज़ों से जुड़े App Scripts बनाकर पीड़ित के OAuth token तक पहुँच प्राप्त करने की कोशिश की जाए, अधिक जानकारी के लिए देखें: {{#ref}} gws-app-scripts.md {{#endref}} -## OAuth ऐप्स फ़िशिंग +## OAuth Apps Phishing -पिछले किसी भी तकनीक का उपयोग उपयोगकर्ता को एक **Google OAuth एप्लिकेशन** तक पहुँचने के लिए किया जा सकता है जो उपयोगकर्ता से कुछ **एक्सेस** **अनुरोध** करेगा। यदि उपयोगकर्ता **स्रोत** पर **विश्वास** करता है तो वह **एप्लिकेशन** पर भी **विश्वास** कर सकता है (भले ही यह उच्च विशेषाधिकार प्राप्त अनुमतियों के लिए पूछ रहा हो)। +Any of the previous techniques might be used to make the user access a **Google OAuth application** that will **request** the user some **access**. If the user **trusts** the **source** he might **trust** the **application** (even if it's asking for high privileged permissions). > [!NOTE] -> ध्यान दें कि Google कई मामलों में एक भद्दा प्रॉम्प्ट प्रस्तुत करता है जो चेतावनी देता है कि एप्लिकेशन अविश्वसनीय है और Workspace प्रशासक यहां तक कि लोगों को OAuth एप्लिकेशन स्वीकार करने से रोक सकते हैं। +> ध्यान दें कि Google कई मामलों में एक खराब दिखने वाला prompt दिखाता है जो बताता है कि application untrusted है और Workspace admins यहाँ तक कि लोगों को OAuth applications स्वीकार करने से रोक भी सकते हैं। -**Google** उपयोगकर्ताओं की ओर से कई **Google सेवाओं** के साथ **संवाद करने** के लिए एप्लिकेशन बनाने की अनुमति देता है: Gmail, Drive, GCP... +**Google** ऐसे applications बनाने की अनुमति देता है जो कई **Google services** के साथ उपयोगकर्ताओं की ओर से इंटरैक्ट कर सकें: Gmail, Drive, GCP... -जब किसी एप्लिकेशन को **अन्य उपयोगकर्ताओं की ओर से कार्य करने** के लिए बनाया जाता है, तो डेवलपर को **GCP के अंदर एक OAuth ऐप** बनाना होगा और उन स्कोप (अनुमतियों) को निर्दिष्ट करना होगा जिनकी ऐप को उपयोगकर्ताओं के डेटा तक पहुँचने की आवश्यकता है।\ -जब एक **उपयोगकर्ता** उस **एप्लिकेशन** का **उपयोग** करना चाहता है, तो उन्हें **स्वीकृति** देने के लिए **प्रॉम्प्ट** किया जाएगा कि एप्लिकेशन उनके डेटा तक पहुँच प्राप्त करेगा जो स्कोप में निर्दिष्ट है। +When creating an application to **act on behalf other users**, the developer needs to create an **OAuth app inside GCP** and indicate the scopes (permissions) the app needs to access the users data.\ +When a **user** wants to **use** that **application**, they will be **prompted** to **accept** that the application will have access to their data specified in the scopes. -यह **फिशिंग** गैर-तकनीकी उपयोगकर्ताओं को **संवेदनशील जानकारी तक पहुँचने वाले एप्लिकेशन** का उपयोग करने के लिए एक बहुत ही आकर्षक तरीका है क्योंकि वे परिणामों को नहीं समझ सकते। हालाँकि, संगठनों के खातों में, इसे होने से रोकने के तरीके हैं। +This is a very juicy way to **phish** non-technical users into using **applications that access sensitive information** because they might not understand the consequences. However, in organizations accounts, there are ways to prevent this from happening. -### अविश्वसनीय ऐप प्रॉम्प्ट +### Unverified App prompt -जैसा कि उल्लेख किया गया था, Google हमेशा उपयोगकर्ता को **अनुमतियों को स्वीकार करने के लिए प्रॉम्प्ट** करेगा जो वे एप्लिकेशन को अपनी ओर से दे रहे हैं। हालाँकि, यदि एप्लिकेशन को **खतरनाक** माना जाता है, तो Google पहले **प्रॉम्प्ट** दिखाएगा जो यह संकेत देगा कि यह **खतरनाक** है और उपयोगकर्ता के लिए ऐप को अनुमतियाँ देने में **अधिक कठिनाई** पैदा करेगा। +As it was mentioned, Google will always present a **prompt to the user to accept** the permissions they are giving the application on their behalf. However, if the application is considered **dangerous**, Google will show **first** a **prompt** indicating that it's **dangerous** and **making it more difficult** for the user to grant the permissions to the app. -यह प्रॉम्प्ट उन ऐप्स में दिखाई देता है: +This prompt appears in apps that: -- कोई भी स्कोप जो निजी डेटा (Gmail, Drive, GCP, BigQuery...) तक पहुँच सकता है -- 100 से कम उपयोगकर्ताओं वाले ऐप्स (100 से अधिक उपयोगकर्ताओं वाले ऐप्स के लिए एक समीक्षा प्रक्रिया भी आवश्यक है ताकि अविश्वसनीय प्रॉम्प्ट दिखाना बंद किया जा सके) +- कोई भी ऐसा scope उपयोग करते हैं जो private data (Gmail, Drive, GCP, BigQuery...) तक पहुँच सकता हो +- Apps with less than 100 users (apps > 100 a review process is also needed to stop showing the unverified prompt) -### दिलचस्प स्कोप +### Interesting Scopes -[**यहाँ**](https://developers.google.com/identity/protocols/oauth2/scopes) आप सभी Google OAuth स्कोप की सूची पा सकते हैं। +[**Here**](https://developers.google.com/identity/protocols/oauth2/scopes) पर आप सभी Google OAuth scopes की सूची पा सकते हैं। -- **cloud-platform**: अपने डेटा को **Google Cloud Platform** सेवाओं के बीच देखें और प्रबंधित करें। आप GCP में उपयोगकर्ता का प्रतिनिधित्व कर सकते हैं। -- **admin.directory.user.readonly**: अपने संगठन के GSuite निर्देशिका को देखें और डाउनलोड करें। सभी उपयोगकर्ताओं के नाम, फोन, कैलेंडर यूआरएल प्राप्त करें। +- **cloud-platform**: अपने डेटा को **Google Cloud Platform** सेवाओं में देखें और प्रबंधित करें। आप GCP में उपयोगकर्ता की impersonate कर सकते हैं। +- **admin.directory.user.readonly**: अपने संगठन की GSuite directory देखें और डाउनलोड करें। सभी उपयोगकर्ताओं के नाम, फोन, calendar URLs प्राप्त करें। -### एक OAuth ऐप बनाएं +### Create an OAuth App -**OAuth क्लाइंट आईडी बनाना शुरू करें** +**Start creating an OAuth Client ID** -1. [https://console.cloud.google.com/apis/credentials/oauthclient](https://console.cloud.google.com/apis/credentials/oauthclient) पर जाएं और सहमति स्क्रीन को कॉन्फ़िगर करने पर क्लिक करें। -2. फिर, आपसे पूछा जाएगा कि **उपयोगकर्ता प्रकार** **आंतरिक** (केवल आपके संगठन के लोगों के लिए) है या **बाहरी**। उस विकल्प का चयन करें जो आपकी आवश्यकताओं के अनुसार हो -- आंतरिक तब दिलचस्प हो सकता है जब आपने पहले ही संगठन के एक उपयोगकर्ता को समझौता कर लिया है और आप इस ऐप को दूसरे को फिश करने के लिए बना रहे हैं। -3. ऐप को एक **नाम** दें, एक **समर्थन ईमेल** (ध्यान दें कि आप खुद को थोड़ा और अनाम करने के लिए एक गूगल ग्रुप ईमेल सेट कर सकते हैं), एक **लोगो**, **अधिकृत डोमेन** और **अपडेट्स** के लिए एक और **ईमेल** दें। -4. **OAuth स्कोप** का **चयन** करें। -- यह पृष्ठ गैर-संवेदनशील अनुमतियों, संवेदनशील अनुमतियों और प्रतिबंधित अनुमतियों में विभाजित है। हर बार जब आप एक नई अनुमति जोड़ते हैं, तो यह उसकी श्रेणी में जोड़ी जाती है। अनुरोधित अनुमतियों के आधार पर उपयोगकर्ता को विभिन्न प्रॉम्प्ट दिखाई देंगे जो यह संकेत देते हैं कि ये अनुमतियाँ कितनी संवेदनशील हैं। -- दोनों **`admin.directory.user.readonly`** और **`cloud-platform`** संवेदनशील अनुमतियाँ हैं। -5. **परीक्षण उपयोगकर्ताओं को जोड़ें।** जब तक ऐप की स्थिति परीक्षण में है, केवल ये उपयोगकर्ता ऐप तक पहुँचने में सक्षम होंगे इसलिए सुनिश्चित करें कि **उस ईमेल को जोड़ें जिसे आप फिश करने जा रहे हैं**। +1. Go to [https://console.cloud.google.com/apis/credentials/oauthclient](https://console.cloud.google.com/apis/credentials/oauthclient) and click on configure the consent screen. +2. Then, you will be asked if the **user type** is **internal** (only for people in your org) or **external**. Select the one that suits your needs +- Internal उपयोगी हो सकता है यदि आपने पहले से किसी organization के user को compromise कर लिया है और आप इस App को किसी और को phish करने के लिए बना रहे हैं। +3. Give a **name** to the app, a **support email** (note that you can set a googlegroup email to try to anonymize yourself a bit more), a **logo**, **authorized domains** and another **email** for **updates**. +4. **Select** the **OAuth scopes**. +- यह पृष्ठ non sensitive permissions, sensitive permissions और restricted permissions में विभाजित है। हर बार जब आप कोई नया permission जोड़ते हैं यह अपनी श्रेणी में जोड़ा जाता है। अनुरोधित permissions के आधार पर उपयोगकर्ता को अलग-अलग prompt दिखाई देंगे जो बताती हैं कि ये permissions कितनी संवेदनशील हैं। +- Both **`admin.directory.user.readonly`** and **`cloud-platform`** are sensitive permissions. +5. **Add the test users.** As long as the status of the app is testing, only these users are going to be able to access the app so make sure to **add the email you are going to be phishing**. -अब हम **पिछले बनाए गए OAuth क्लाइंट आईडी** का उपयोग करके **वेब एप्लिकेशन के लिए क्रेडेंशियल्स प्राप्त करें**: +Now let's get **credentials for a web application** using the **previously created OAuth Client ID**: -1. [https://console.cloud.google.com/apis/credentials/oauthclient](https://console.cloud.google.com/apis/credentials/oauthclient) पर वापस जाएं, इस बार एक अलग विकल्प दिखाई देगा। -2. **वेब एप्लिकेशन के लिए क्रेडेंशियल्स बनाने** का चयन करें -3. आवश्यक **जावास्क्रिप्ट मूल** और **रीडायरेक्ट यूआरआई** सेट करें -- आप परीक्षण के लिए दोनों में कुछ ऐसा सेट कर सकते हैं जैसे **`http://localhost:8000/callback`** -4. अपने एप्लिकेशन के **क्रेडेंशियल्स** प्राप्त करें +1. Go back to [https://console.cloud.google.com/apis/credentials/oauthclient](https://console.cloud.google.com/apis/credentials/oauthclient), a different option will appear this time. +2. Select to **create credentials for a Web application** +3. Set needed **Javascript origins** and **redirect URIs** +- You can set in both something like **`http://localhost:8000/callback`** for testing +4. Get your application **credentials** -अंत में, चलिए **एक वेब एप्लिकेशन चलाते हैं जो OAuth एप्लिकेशन क्रेडेंशियल्स का उपयोग करेगा**। आप एक उदाहरण [https://github.com/carlospolop/gcp_oauth_phishing_example](https://github.com/carlospolop/gcp_oauth_phishing_example) में पा सकते हैं। +Finally, lets **run a web application that will use the OAuth application credentials**. You can find an example in [https://github.com/carlospolop/gcp_oauth_phishing_example](https://github.com/carlospolop/gcp_oauth_phishing_example). ```bash git clone ttps://github.com/carlospolop/gcp_oauth_phishing_example cd gcp_oauth_phishing_example pip install flask requests google-auth-oauthlib python3 app.py --client-id "" --client-secret "" ``` -**`http://localhost:8000`** पर जाएं और Google के साथ लॉगिन बटन पर क्लिक करें, आपको इस तरह का एक संदेश **प्रदर्शित** किया जाएगा: +`http://localhost:8000` पर जाएँ, Login with Google बटन पर क्लिक करें, आपको इस जैसी एक संदेश दिखाई देगा:
-ऐप्लिकेशन **एक्सेस और रिफ्रेश टोकन** दिखाएगा जिसे आसानी से उपयोग किया जा सकता है। **इन टोकनों का उपयोग कैसे करें, इसकी अधिक जानकारी के लिए देखें**: +Application दिखाएगा **access and refresh token** जिन्हें आसानी से इस्तेमाल किया जा सकता है। इन tokens को कैसे इस्तेमाल करना है, इसके बारे में अधिक जानकारी के लिए देखें: {{#ref}} ../../gcp-security/gcp-persistence/gcp-non-svc-persistence.md {{#endref}} -#### `glcoud` का उपयोग करना +#### Using `glcoud` -वेब कंसोल के बजाय gcloud का उपयोग करके कुछ करना संभव है, देखें: +web console के बजाय `glcoud` का उपयोग करके कुछ किया जा सकता है, देखें: {{#ref}} ../../gcp-security/gcp-privilege-escalation/gcp-clientauthconfig-privesc.md {{#endref}} +#### OAuth app protections + +डिफ़ॉल्ट रूप से यह कॉन्फ़िगर किया गया है कि किसी भी Workspace संगठन के अंदर कोई भी user **can accecpt any OAuth app with any permissions**, पर इन्हें केवल उन apps तक सीमित करना संभव है जो Sign in with Google के लिए जरूरी basic info ही request करते हैं या किसी भी third-party apps को अनुमति न देना। + +इसके अलावा, बाहरी third-party apps पर भरोसा न करने की अनुमति न देने के बावजूद, किसी भी internal apps (organization के अंदर बनाई गई apps) को **trust any internal apps** करने की अनुमति दी जा सकती है। यह trust **default** रूप से कॉन्फ़िगर होता है। + +
+ +### OAuth Consent Grant Abuse: Detection & Response (Admin Reports) + +जब कोई user किसी OAuth app को authorize करता है, तो Google Workspace इसे **Admin Reports OAuth Token Audit Activity** (application name `token`) में रिकॉर्ड करता है, जहाँ `events.name` `authorize` पर सेट होता है। ये events consent phishing को detect करने और granted client ID और scopes को ट्रैक करने के लिए सबसे अच्छी telemetry हैं। + +Audit event से extract करने वाले मुख्य fields: + +- `id.time`, `id.customerId` +- `actor.email`, `actor.profileId` +- `ipAddress`, `networkInfo.regionCode`, `networkInfo.subdivisionCode` +- `events[0]['parameters']` values for `client_id`, `app_name`, `scope`, `scope_data` + +**Baseline first (reduce noise):** मौजूदा client IDs और scopes का inventory बनाएं, फिर नए/दुर्लभ consents पर alert करें। +```bash +gam all users print tokens todrive +``` +**डिटेक्शन विचार (new/rare app + risky scopes):** + +- अलर्ट अगर एक `client_id` **अनुमोदित allowlist में नहीं है** और **पिछले X दिनों में नहीं देखा गया है** (उदा., 90). +- अलर्ट अगर दिए गए `scope` में **उच्च-जोखिम या दुर्लभ** scopes शामिल हैं, विशेषकर वे जो बड़े पैमाने पर डेटा एक्सेस या सप्लाई-चेन पर प्रभाव की अनुमति देते हैं, जैसे: +- `https://mail.google.com/` +- `https://www.googleapis.com/auth/gmail.readonly` +- `https://www.googleapis.com/auth/drive` +- `https://www.googleapis.com/auth/drive.readonly` +- `https://www.googleapis.com/auth/chat.messages` +- `https://www.googleapis.com/auth/chromewebstore` +```text +client_id NOT IN approved_client_ids +AND client_id NOT IN last_seen_90d +AND scope CONTAINS any(high_risk_scopes OR rare_scopes) +``` +**प्रतिक्रिया / शमन:** + +- दुष्ट OAuth client ID के लिए tokens को रद्द करें: +```bash +gam all users delete tokens clientId +``` +- Admin Console में OAuth client ID को ब्लॉक करें — एप्लिकेशन की Google data तक पहुँच रद्द करके। + +**Threat hunting pivots:** + +- N से कम users द्वारा consent किए गए external apps की सूची बनाएं (दुर्लभ अपनाना)। +- app name, publisher, permissions/scopes, और unique application ID की समीक्षा करें। +- ऐसे dormant apps खोजें जो अचानक risky permissions का उपयोग करने लगे (संभावित follow-on actions जैसे internal phishing या data theft)। + +**Mitigations:** + +- सभी third-party app access को सीमित करें (केवल admin-approved)। +- सीमित access की अनुमति दें ताकि users केवल basic “Sign in with Google” profile info के लिए ही consent कर सकें। + ## संदर्भ - [https://www.youtube-nocookie.com/embed/6AsVUS79gLw](https://www.youtube-nocookie.com/embed/6AsVUS79gLw) - Matthew Bryant - Hacking G Suite: The Power of Dark Apps Script Magic -- [https://www.youtube.com/watch?v=KTVHLolz6cE](https://www.youtube.com/watch?v=KTVHLolz6cE) - Mike Felch और Beau Bullock - OK Google, How do I Red Team GSuite? +- [https://www.youtube.com/watch?v=KTVHLolz6cE](https://www.youtube.com/watch?v=KTVHLolz6cE) - Mike Felch and Beau Bullock - OK Google, How do I Red Team GSuite? +- [https://redcanary.com/blog/threat-detection/google-workspace-oauth-attack/](https://redcanary.com/blog/threat-detection/google-workspace-oauth-attack/) +- [https://github.com/GAM-team/GAM](https://github.com/GAM-team/GAM) {{#include ../../../banners/hacktricks-training.md}}