gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2026-07-28 22:51:09 -07:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['', 'src/pentesting-cloud/azure-security/az-lateral-movement

Browse Source
This commit is contained in:
Translator
2026-03-17 19:20:51 +00:00
parent dddca4a88b
commit fe51fc3c65
2 changed files with 134 additions and 76 deletions
Download Patch File Download Diff File Expand all files Collapse all files
src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-exchange-hybrid-impersonation.md
+18 -18
View File
@@ -4,44 +4,44 @@
## 기본 정보
레거시 Exchange Hybrid 설계에서는 on-prem Exchange 배포가 Exchange Online에서 사용되는 동일한 Entra 애플리케이션 아이덴티티로 인증할 수 있었습니다. 공격자가 Exchange 서버를 침해해 hybrid certificate private key를 추출하고 OAuth client-credentials flow를 수행하면, Exchange Online 권한 컨텍스트를 가진 first-party 토큰을 획득할 수 있었습니다.
레거시 Exchange Hybrid 설계에서는 on-prem Exchange 배포가 Exchange Online에서 사용되는 동일한 Entra 애플리케이션 아이덴티티로 인증할 수 있었습니다. 공격자가 Exchange 서버를 침해하고 hybrid certificate private key를 추출한 다음 OAuth client-credentials 흐름을 수행하면, Exchange Online 권한 컨텍스트를 가진 first-party tokens를 획득할 수 있었습니다.
실제 위험은 단순한 사서함 접근에 국한되지 않았습니다. Exchange Online이 광범위한 백엔드 신뢰 관계를 가지므로, 이 아이덴티티는 추가적인 Microsoft 365 서비스와 상호작용할 수 있었고, 과거 동작에서는 더 깊은 테넌트 침해로 이어질 수 있었습니다.
실제 위험은 메일박스 접근에만 국한되지 않았습니다. Exchange Online이 광범위한 백엔드 신뢰 관계를 가지고 있었기 때문에, 이 아이덴티티는 추가적인 Microsoft 365 서비스와 상호작용할 수 있었고, 이전 동작에서는 더 깊은 tenant 침해로 악용될 수 있었습니다.
## 공격 경로 및 기술적 흐름
## 공격 경로 및 기술 흐름
### Exchange를 통한 Federation 구성 수정
과거에는 Exchange 토큰이 도메인/페더레이션 설정을 쓸 수 있는 권한을 가지고 있었습니다. 공격자 관점에서 이는 토큰 서명 인증서 목록이나 온프레미스 페더레이션 인프라에서 오는 MFA-claim 수락을 제어하는 구성 플래그 등, 페더레이션 신뢰 데이터를 직접 조작할 수 있게 했습니다.
Exchange tokens는 과거에 도메인/페더레이션 설정을 쓸 수 있는 권한을 갖고 있었습니다. 공격자 관점에서는 이는 token-signing certificate 목록과 on-prem federation 인프라에서의 MFA-claim 수용을 제어하는 구성 플래그를 포함해 페더레이션 도메인 신뢰 데이터를 직접 조작할 수 있게 했습니다.
즉, 침해된 Exchange Hybrid 서버는 클라우드 측에서 페더레이션 구성을 변경해 ADFS-style impersonation을 준비하거나 강화하는 데 사용될 수 있었고, 공격자가 온프레미스 Exchange 침해에서 시작했더라도 해당 작업이 가능했습니다.
즉, 침해된 Exchange Hybrid 서버는 공격자가 최초 침해를 on-prem Exchange에서 시작했더라도 클라우드 측에서 federation config를 변경해 ADFS-style impersonation을 준비하거나 강화하는 데 사용될 수 있었습니다.
### ACS Actor Tokens 및 서비스 간 Impersonation
### ACS Actor Tokens and Service-to-Service Impersonation
Exchange의 하이브리드 인증 경로는 `trustedfordelegation=true`로 설정된 Access Control Service (ACS) actor tokens을 사용했습니다. 그런 actor token은 공격자가 제어하는 섹션에 대상 사용자 아이덴티티를 담은 두 번째의 서명되지 않은 서비스 토큰에 포함되었습니다. 외부 토큰이 서명되지 않았고 actor token이 광범위하게 위임되었기 때문에, 호출자는 재인증 없이 대상 사용자를 교체할 수 있었습니다.
Exchange의 hybrid auth 경로는 `trustedfordelegation=true`가 설정된 Access Control Service (ACS) actor tokens를 사용했습니다. 그 actor tokens는 공격자가 제어하는 섹션에 대상 사용자 아이덴티티를 담은 두 번째 서명되지 않은 service token 안에 포함되었습니다. 외부 토큰이 서명되지 않았고 actor token이 광범위하게 위임되었기 때문에, 호출자는 재인증 없이 대상 사용자를 교체할 수 있었습니다.
실무에서는 actor token을 획득하면 공격자는 수명 기간이 긴(보통 약 24시간) 임퍼소네이션 원시 수단을 가지게 되었고, 그 수명 중간에 취소하기가 어려웠습니다. 이는 Exchange Online 및 SharePoint/OneDrive APIs 전반에 걸친 사용자 임퍼소네이션을 가능하게 했고, 고가치 데이터 유출을 허용했습니다.
실무적으로 actor token을 획득하면 공격자는 수명 중간에 취소하기 어려운 장기간의 impersonation primitive(일반적으로 약 24시간)를 가졌습니다. 이는 Exchange Online 및 SharePoint/OneDrive APIs 전반에서 사용자 impersonation을 가능하게 하여 고가치 데이터 유출을 초래할 수 있었습니다.
역사적으로 같은 패턴은 victim의 `netId` 값을 사용해 impersonation 토큰을 만들어 `graph.windows.net`에도 작동했습니다. 이는 임의 사용자로서 직접 Entra administrative action을 수행하게 해 전체 테넌트 장악 워크플로우(예: 새로운 Global Administrator 계정 생성)를 가능하게 했습니다.
역사적으로 같은 패턴은 피해자의 `netId` 값을 사용해 impersonation token을 구축함으로써 `graph.windows.net`에도 작동했습니다. 이는 임의 사용자로서 직접적인 Entra 관리 작업을 가능하게 했고 전체-tenant 탈취 워크플로(예: 새로운 Global Administrator 계정 생성)를 수행할 수 있게 했습니다.
## 더 이상 작동하지 않는 것
Exchange Hybrid actor tokens을 통한 `graph.windows.net` impersonation 경로는 수정되었습니다. 이 특정 토큰 경로에 대한 이전의 "Exchange에서 임의 Entra 관리자 권한으로의 Graph 체인"은 제거된 것으로 간주해야 합니다.
Exchange Hybrid actor tokens를 통한 `graph.windows.net` impersonation 경로는 수정되었습니다. 이 특정 토큰 경로에 대한 이전의 "Exchange → 임의 Entra admin over Graph" 체인은 더 이상 존재하지 않는 것으로 간주해야 합니다.
공격 문서화 시 가장 중요한 보정은 다음과 같습니다: Exchange/SharePoint 임퍼소네이션 위험과 이제 패치된 Graph 임퍼소네이션 권한 상승을 분리해서 기록하십시오.
이 점은 공격을 문서화할 때 가장 중요한 수정사항입니다: Exchange/SharePoint impersonation 위험은 이제 패치된 Graph impersonation 권한 상승과 구분해서 다루어야 합니다.
## 실무에서 여전히 중요할 수 있는 사항
## 실제로 여전히 문제가 될 수 있는 것
조직이 여전히 공유 신뢰와 노출된 인증서 자료를 가진 오래되었거나 불완전한 하이브리드 구성을 운영하고 있다면, Exchange/SharePoint 임퍼소네이션의 영향은 여전히 심각할 수 있습니다. 테넌트 설정 및 마이그레이션 상태에 따라 페더레이션 구성 오용 측면도 여전히 관련성이 있을 수 있습니다.
조직이 여전히 공유 신뢰와 노출된 certificate 정보를 가진 오래되었거나 불완전한 hybrid 구성을 운영 중이라면, Exchange/SharePoint impersonation 영향은 여전히 심각할 수 있습니다. 페더레이션 구성 남용 관점도 tenant 설정 및 마이그레이션 상태에 따라 여전히 관련성이 있을 수 있습니다.
Microsoft의 장기적인 완화책은 온프레미스와 Exchange Online 아이덴티티를 분리해 shared-service-principal 신뢰 경로가 더 이상 존재하지 않게 하는 것입니다. 해당 마이그레이션을 완료한 환경은 이 공격 표면을 실질적으로 줄입니다.
Microsoft의 장기 완화책은 on-prem과 Exchange Online 아이덴티티를 분리하여 shared-service-principal 신뢰 경로가 더 이상 존재하지 않게 하는 것입니다. 해당 마이그레이션을 완료한 환경은 이 공격 표면을 실질적으로 줄입니다.
## 탐지 참고사항
## 탐지 노트
이 기법이 악용될 때, 감사 이벤트는 사용자 프린시펄 네임이 임퍼소네이트된 사용자를 가리키지만 디스플레이/소스 컨텍스트는 Exchange Online 활동을 가리키는 아이덴티티 불일치를 보여줄 수 있습니다. 그런 혼합된 아이덴티티 패턴은 높은 가치의 헌팅 시그널이지만, 방어자들은 오탐을 줄이기 위해 합법적인 Exchange-admin 워크플로우를 기준선화해야 합니다.
이 기법이 악용되면 감사 이벤트에서 user principal name이 모방된 사용자에 해당하는 반면 표시/출처 컨텍스트는 Exchange Online 활동을 가리키는 식의 아이덴티티 불일치가 나타날 수 있습니다. 이러한 혼합된 아이덴티티 패턴은 높은 가치의 헌팅 신호지만, 수비자는 오탐을 줄이기 위해 정상적인 Exchange-admin 워크플로를 기준선으로 설정해야 합니다.
## 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}}
src/pentesting-cloud/workspace-security/gws-google-platforms-phishing/README.md
+116 -58
View File
@@ -2,7 +2,7 @@
{{#include ../../../banners/hacktricks-training.md}}
## Generic Phishing Methodology
## 일반적인 Phishing 방법론
{{#ref}}
https://book.hacktricks.wiki/en/generic-methodologies-and-resources/phishing-methodology/index.html
@@ -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**. 그런 다음 사용자에게 전송될 이메일을 수정하여 **링크를 추가할 수 있습니다.** 이메일은 **google 주소에서 발송되므로**, 보기에는 **정상적으로(legit)** 보이며 사람들이 링크를 클릭할 수 있습니다.
또한 **FROM** 주소를 **Google 그룹 이메일**로 설정하여 **그룹 내 사용자에게 더 많은 이메일을 보낼 수 있습니다**, 다음 이미지와 같이 **`google--support@googlegroups.com`** 그룹이 생성되고 **그룹의 모든 구성원에게 이메일이 전송되었습니다** (동의 없이 추가된 구성원들).
It's also possible to set the **FROM** address as the **Google group email** to send **more emails to the users inside the group**, like in the following image where the group **`google--support@googlegroups.com`** was created and an **email was sent to all the members** of the group (that were added without any consent)
<figure><img src="../../../images/image (5) (1).png" alt=""><figcaption></figcaption></figure>
## Google Chat Phishing
이메일 주소만 있으면 사람과 **채팅을 시작하거나** **대화 초대**를 보낼 수 있습니다. 또한 **Space를 생성**할 수 있으며, 이름은 아무거나 지정할 수 있습니다 (예: "Google Support") 그리고 **구성원을 초대**할 수 있습니다. 그들이 수락하면 Google Support와 대화하고 있다고 생각할 수 있습니다:
이메일 주소만 알고 있어도 상대와 **채팅을 시작(start a chat)**하거나 **대화 초대(invitation to talk)**를 보낼 수 있습니다. 또한 원하는 이름(예: "Google Support")으로 설정 가능한 **Space**를 생성하고 멤버를 **invite**할 수 있습니다. 상대가 수락하면 Google Support와 대화하고 있다고 생각할 수 있습니다:
<figure><img src="../../../images/image (6).png" alt=""><figcaption></figcaption></figure>
> [!TIP]
> **하지만 제 테스트에서는 초대된 구성원들이 초대를 받지 못했습니다.**
> **내 테스트에서는 초대받은 멤버들이 초대장을 아예 받지 못했습니다.**
과거에 이 방법이 어떻게 작동했는지 확인할 수 있습니다: [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.\
요즘은 이 방식이 동작하지 않지만, 피해자 이메일에 문서 접근 권한을 **부여하면** Google이 해당 사실을 알리는 이메일을 보냅니다. 누군가를 mention했을 때 표시되는 메시지는 다음과 같습니다:
<figure><img src="../../../images/image (7).png" alt=""><figcaption></figcaption></figure>
> [!TIP]
> 피해자는 외부 문서가 공유되었다는 알림 이메일이 그들의 이메일에 도달하지 않도록 하는 보호 메커니즘을 가질 수 있습니다.
> 피해자 측에 외부 문서가 공유되었다는 알림 이메일이 수신되지 않도록 하는 보호 메커니즘이 있을 수 있습니다.
## 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. 이벤트를 신뢰할 만하게 보이게 만들고 **읽어야 할 내용이 있다**는 코멘트와 제목을 넣으세요 (여기에 **phishing link** 포함).
이것은 "사람 해고"라는 회의 제목으로 브라우저에 나타날 경고입니다. 따라서 더 피싱 같은 제목을 설정할 수 있습니다 (그리고 심지어 이메일과 연결된 이름을 변경할 수 있습니다).
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).
<figure><img src="../../../images/image (8).png" alt=""><figcaption></figcaption></figure>
덜 의심스럽게 보이도록 하려면:
To make it look less suspicious:
- **수신자가 초대된 다른 사람들을 볼 수 없도록 설정하세요.**
- **이벤트에 대한 알림 이메일을 보내지 마세요.** 그러면 사람들은 5분 후 회의에 대한 경고만 보고 그 링크를 읽어야 한다고 생각할 것입니다.
- API를 사용하여 **사람들이** 이벤트를 **수락했다고 설정하고** 심지어 그들의 이름으로 **댓글을 생성**할 수 있는 것으로 보입니다.
- **수신자가 다른 초대자를 볼 수 없도록** 설정하세요.
- **이벤트 알림 이메일을 발송하지 마세요.** 그러면 사람들은 단지 5분 뒤의 회의 알림과 해당 링크를 읽어야 한다는 것만 보게 됩니다.
- Apparently using the API you can set to **True** that **people** have **accepted** the event and even create **comments on their behalf**.
## 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`**.\
다음과 같은 코드로 공격자는 이 페이지에서 도메인에 계속 접근하면서 임의의 콘텐츠를 로드하게 만들 수 있습니다:
```javascript
function doGet() {
return HtmlService.createHtmlOutput(
@@ -62,100 +62,158 @@ 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:
<figure><img src="../../../images/image (4) (1).png" alt=""><figcaption></figcaption></figure>
> [!TIP]
> 콘텐츠가 iframe 내에서 로드될 때 경고가 나타날 것입니다.
> 컨텐츠가 iframe 내부에 로드되므로 경고가 나타납니다.
## App Scripts OAuth 피싱
## App Scripts OAuth Phishing
문서에 연결된 App Scripts를 생성하여 피해자의 OAuth 토큰에 접근하려고 시도할 수 있습니다. 자세한 내용은 다음을 확인하세요:
It's possible to create App Scripts attached to documents to try to get access over a victims OAuth token, for more information check:
{{#ref}}
gws-app-scripts.md
{{#endref}}
## OAuth 앱 피싱
## OAuth Apps Phishing
이전의 기술 중 어떤 것이든 사용자가 **Google OAuth 애플리케이션**에 접근하도록 유도할 수 있으며, 이 애플리케이션은 사용자에게 **접근**을 **요청**할 것입니다. 사용자가 **출처**를 **신뢰**하면 **애플리케이션**도 **신뢰**할 수 있습니다(비록 높은 권한의 권한을 요청하더라도).
앞서 설명한 기법들은 사용자가 **Google OAuth application**에 접근하도록 유도할 수 있으며, 애플리케이션이 사용자에게 일부 권한을 요청할 수 있습니다. 사용자가 출처를 신뢰하면(높은 권한을 요구하더라도) 애플리케이션을 신뢰할 가능성이 있습니다.
> [!NOTE]
> Google은 여러 경우에 애플리케이션이 신뢰할 수 없다는 경고를 요청하는 불쾌한 프롬프트를 표시하며, Workspace 관리자는 사용자가 OAuth 애플리케이션을 수락하는 것을 방지할 수 있습니다.
> Google은 여러 경우에 애플리케이션이 신뢰할 수 없다는 경고를 표시하는 보기 흉한 프롬프트를 보여주며, Workspace 관리자는 사용자가 OAuth 애플리케이션을 수락하지 못하도록 제한할 수도 있습니다.
**Google**은 여러 **Google 서비스**(Gmail, Drive, GCP...)와 **사용자를 대신하여 상호작용**할 수 있는 애플리케이션을 생성할 수 있도록 허용합니다.
Google은 사용자 대신 여러 Google 서비스(Gmail, Drive, GCP...)와 상호작용할 수 있는 애플리케이션을 생성할 수 있도록 허용합니다.
다른 사용자를 대신하여 **작동**하는 애플리케이션을 생성할 때, 개발자는 **GCP 내에서 OAuth 앱**을 생성하고 애플리케이션이 사용자 데이터에 접근하는 데 필요한 범위(권한)를 지정해야 합니다.\
사용자가 해당 **애플리케이션**을 **사용**하고자 할 때, 그들은 애플리케이션이 범위에 지정된 데이터에 접근할 것임을 **수락**하라는 **프롬프트**를 받게 됩니다.
다른 사용자를 대신해 동작하는 애플리케이션을 만들려면 개발자는 GCP 내에서 OAuth 앱을 생성하고 애플리케이션이 사용자 데이터에 접근하기 위해 필요한 scopes(권한)를 지정해야 합니다. 사용자가 해당 애플리케이션을 사용하려고 하면, scopes에 명시된 데이터에 애플리케이션이 접근하는 것을 수락할지 묻는 프롬프트가 표시됩니다.
이는 비기술적 사용자가 **민감한 정보에 접근하는 애플리케이션**을 사용하도록 **피싱**하는 매우 매력적인 방법입니다. 그들은 결과를 이해하지 못할 수 있습니다. 그러나 조직 계정에서는 이러한 일이 발생하지 않도록 방지할 수 있는 방법이 있습니다.
이는 비기술 사용자를 민감한 정보에 접근하는 애플리케이션 사용으로 유도하는 매우 효과적인 피싱 수법입니다. 다만 조직 계정에서는 이를 방지할 수 있는 방법들이 존재합니다.
### 인증되지 않은 앱 프롬프트
### Unverified App prompt
앞서 언급했듯이, Google은 항상 사용자가 애플리케이션에 대한 권한을 수락하도록 **프롬프트를 표시**합니다. 그러나 애플리케이션이 **위험한** 것으로 간주되면, Google은 **먼저** **위험하다는** **프롬프트**를 표시하여 사용자가 애플리케이션에 권한을 부여하는 것을 **더 어렵게** 만듭니다.
언급했듯이, google은 사용자가 애플리케이션에 부여하는 권한을 수락하도록 항상 프롬프트를 표시합니다. 그러나 애플리케이션이 위험하다고 판단되면 google은 먼저 위험하다는 프롬프트를 보여 사용자가 권한을 부여하기 더 어렵게 만듭니다.
이 프롬프트는 다음과 같은 앱에서 나타납니다:
This prompt appears in apps that:
- 개인 데이터에 접근할 수 있는 범위를 사용하는 앱(Gmail, Drive, GCP, BigQuery...)
- 사용자 수가 100명 미만인 앱(100명 이상의 앱은 인증되지 않은 프롬프트를 표시하지 않기 위해 검토 프로세스가 필요함)
- Use any scope that can access 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) you can find a list of all the Google OAuth scopes.
- **cloud-platform**: **Google Cloud Platform** 서비스 전반에 걸쳐 데이터를 보고 관리합니다. GCP에서 사용자를 가장할 수 있습니다.
- **admin.directory.user.readonly**: 조직의 GSuite 디렉토리를 보고 다운로드합니다. 모든 사용자의 이름, 전화번호, 캘린더 URL을 가져옵니다.
- **cloud-platform**: Google Cloud Platform 서비스 전반의 데이터를 조회하고 관리할 수 있습니다. GCP에서 사용자를 가장(impersonate)할 수 있습니다.
- **admin.directory.user.readonly**: 조직의 GSuite 디렉터리를 조회하고 다운로드할 수 있습니다. 모든 사용자의 이름, 전화번호, 캘린더 URL 등을 얻을 수 있습니다.
### OAuth 앱 생성
### Create an OAuth App
**OAuth 클라이언트 ID 생성 시작**
**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 might be interesting you have already compromised a user of the organization and you are creating this App to phish another one.
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**.
- This page is divided in non sensitive permissions, sensitive permissions and restricted permissions. Eveytime you add a new permisison it's added on its category. Depending on the requested permissions different prompt will appear to the user indicating how sensitive these permissions are.
- 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 클라이언트 ID**를 사용하여 **웹 애플리케이션에 대한 자격 증명**을 가져옵니다:
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. 필요한 **Javascript 출처** 및 **리디렉션 URI**를 설정합니다.
- 테스트를 위해 **`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_id>" --client-secret "<client_secret>"
```
**`http://localhost:8000`**로 이동하여 Google로 로그인 버튼을 클릭하면, 다음과 같은 메시지가 **표시됩니다**:
`http://localhost:8000`로 이동하여 Login with Google 버튼을 클릭하면 다음과 같은 메시지가 표시됩니다:
<figure><img src="../../../images/image (333).png" alt=""><figcaption></figcaption></figure>
애플리케이션은 쉽게 사용할 수 있는 **액세스 및 새로 고침 토큰**을 보여줍니다. **이 토큰을 사용하는 방법에 대한** 자세한 정보는 다음을 확인하세요:
애플리케이션은 쉽게 사용할 수 있는 **access and refresh token**을 표시합니다. 이 토큰 사용 방법에 대한 자세한 내용은 다음을 확인하세요:
{{#ref}}
../../gcp-security/gcp-persistence/gcp-non-svc-persistence.md
{{#endref}}
#### `glcoud` 사용하기
#### Using `glcoud`
웹 콘솔 대신 gcloud를 사용하여 무언가를 할 수 있습니다. 확인하세요:
웹 콘솔 대신 gcloud를 사용해 수행할 수 있는 작업이 있습니다. 확인:
{{#ref}}
../../gcp-security/gcp-privilege-escalation/gcp-clientauthconfig-privesc.md
{{#endref}}
#### OAuth app protections
기본적으로 Workspace 조직 내부의 모든 사용자는 **any OAuth app with any permissions을 수락할 수 있도록 구성**되어 있지만, 이를 Sign in with Google에 필요한 기본 정보만 요청하는 앱으로 제한하거나 타사 앱을 허용하지 않도록 설정할 수 있습니다.
또한 외부 third-party apps를 신뢰하지 않도록 제한하더라도 조직 내부에서 생성된 앱을 **trust any internal apps** 하도록 허용할 수 있습니다. 이 신뢰는 **default**로 구성되어 있습니다.
<figure><img src="../../../images/workspace_oauth.png" alt=""><figcaption></figcaption></figure>
### OAuth Consent Grant Abuse: Detection & Response (Admin Reports)
사용자가 OAuth app을 승인하면 Google Workspace는 이를 **Admin Reports OAuth Token Audit Activity** (application name `token`)에 `events.name`이 `authorize`로 설정된 이벤트로 기록합니다. 이러한 이벤트는 consent phishing을 탐지하고 부여된 client ID와 scopes를 추적하는 데 가장 좋은 텔레메트리입니다.
Key fields to extract from the audit event:
- `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의 인벤토리를 구축한 다음, 새롭거나 드문 동의에 대해 경고를 설정하세요.
```bash
gam all users print tokens todrive
```
**탐지 아이디어 (new/rare app + risky scopes):**
- `client_id`가 **승인된 allowlist에 없고** **최근 X일 동안 확인되지 않은 경우** (예: 90) 경보.
- 부여된 `scope`에 **고위험 또는 희귀** 스코프가 포함되어 있는 경우 경보 — 특히 대량 데이터 접근이나 공급망 영향이 가능한 스코프, 예:
- `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 <client_id>
```
- Admin Console에서 OAuth client ID를 차단하여 애플리케이션의 Google 데이터 접근 권한을 취소하세요.
**Threat hunting pivots:**
- N명 미만의 사용자가 동의한 외부 앱을 나열하세요 (채택률이 낮음).
- 앱 이름, 게시자, permissions/scopes, 및 고유 application ID를 검토하세요.
- 갑자기 위험한 permissions를 사용하는 휴면 앱을 찾아보세요 (내부 phishing이나 데이터 도용과 같은 이후 공격 가능성).
**완화 조치:**
- 모든 타사 앱 접근을 제한하세요 (관리자 승인만 허용).
- 제한된 액세스만 허용하여 사용자가 기본 “Sign in with Google” 프로필 정보에만 동의할 수 있게 하세요.
## 참고자료
- [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 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}}