# Azure Entra ID 로그인 로그 우회 취약점 세 번째와 네 번째 사례 공개

> Clean Markdown view of GeekNews topic #27715. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=27715](https://news.hada.io/topic?id=27715)
- GeekNews Markdown: [https://news.hada.io/topic/27715.md](https://news.hada.io/topic/27715.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-03-22T06:33:25+09:00
- Updated: 2026-03-22T06:33:25+09:00
- Original source: [trustedsec.com](https://trustedsec.com/blog/full-disclosure-a-third-and-fourth-azure-sign-in-log-bypass-found)
- Points: 1
- Comments: 1

## Topic Body

- 2023년 이후 **Azure Entra ID 로그인 로그 우회 취약점**이 총 4건 발견되었으며, 최근 두 건은 **정상 토큰 발급이 가능한 심각한 문제**로 확인됨
- **GraphGoblin**은 OAuth2 ROPC 흐름에서 `scope` 파라미터를 반복 입력해 **로그 생성을 우회**하며, **Graph******는 5만 자 이상의 User-Agent 문자열로 **로그를 완전히 누락**시킴
- 두 취약점 모두 **SQL 컬럼 길이 초과로 인한 로깅 실패**가 원인으로 지목되었고, Microsoft는 보고 후 수정 완료
- Microsoft는 이번 문제를 **‘중간(Medium)’ 수준**으로 분류해 **보상이나 공식 인정 없이 조용히 수정**, CVSS 기준으로는 **High(7.5~8.7점)** 수준으로 평가됨
- 반복된 입력값 검증 실패로 인한 결함이 지속되고 있어, **로그 교차 검증 및 KQL 기반 탐지 규칙 강화**가 보안 담당자에게 필수 과제로 지적됨

---

### Azure Entra ID 로그인 로그 우회 취약점 공개
- 2023년 이후 **Azure Entra ID 로그인 로그 우회 취약점**이 총 4건 발견됨
  - 초기 두 건은 비밀번호 유효성만 확인 가능했으나, 최근 두 건은 **정상 토큰 발급**까지 가능한 심각한 수준의 문제
  - 모든 취약점은 현재 Microsoft에 의해 수정 완료
- ## GraphNinja 및 GraphGhost 요약
  - **GraphNinja**: 다른 테넌트의 엔드포인트를 지정해 로그인 시도 시, 비밀번호 유효 여부를 알 수 있으나 로그가 생성되지 않음
    - 공격자는 외부 테넌트로 인증 요청을 보내고 응답을 통해 비밀번호가 맞는지 확인 가능
    - Microsoft는 이후 이 문제를 해결하기 위해 추가 로깅을 도입
  - **GraphGhost**: 잘못된 Client ID를 사용하면 인증 흐름이 비밀번호 검증 이후 실패하며, 로그에는 실패로만 표시됨
    - 비밀번호가 맞았다는 정보는 관리자 로그에 남지 않음
    - Microsoft는 로그인 로그에 비밀번호 검증 여부를 추가하여 수정
- ## GraphGoblin 취약점
  - **GraphGoblin**은 OAuth2 ROPC 흐름에서 `scope` 파라미터를 반복 입력해 로그 생성을 우회함
    - `"openid openid openid ..."` 형태로 수천 번 반복 입력 시 정상 토큰이 발급되지만 **Entra ID 로그인 로그에는 아무 기록도 남지 않음**
  - 원인은 **SQL 컬럼 길이 초과로 인한 INSERT 실패**로 지목됨
    - 반복된 스코프 문자열이 데이터베이스 필드 길이를 초과해 로그 저장이 실패한 것으로 추정
  - Microsoft는 문제 재현에 어려움을 겪었으나, 영상 증거 제공 후 수정 완료
- ## Graph****** (User-Agent 기반 우회)
  - **User-Agent 필드에 50,000자 이상의 긴 문자열을 입력**하면 로그가 생성되지 않음
    - 인증 요청은 정상 처리되어 토큰이 발급되지만 로그는 완전히 누락
    - SQL 컬럼 길이 초과로 인한 로깅 실패로 추정
  - 2025년 9월 28일 발견되어 10월 8일 Microsoft가 보고 전 이미 수정 완료
- ## 타임라인 요약
  - 2025-09-20: GraphGoblin 최초 발견
  - 2025-09-26: Microsoft에 GraphGoblin 보고
  - 2025-09-28: Graph****** 발견
  - 2025-10-08: Graph****** 수정 완료
  - 2025-11-21: Microsoft가 GraphGoblin 재현 성공 및 수정 시작

### Microsoft의 대응 및 평가
- Microsoft는 이번 취약점을 **‘중간(Medium)’ 수준**으로 분류하고 **보상이나 공개 인정을 하지 않음**
  - 이전 두 건(2023~2024년)에는 보상 지급 및 인정이 있었음
  - 이번에는 **정상 토큰이 발급되는 심각한 문제임에도 불구하고 중요하지 않다고 평가**
- CVSS v3.1 기준 **7.5점(High)**, v4.0 기준 **8.7점(High)** 으로 평가됨
  - **Integrity(무결성)** 손상으로 인해 높은 점수 산출
  - 로그 누락은 보안 컴포넌트의 직접적 손상으로 간주됨
- Microsoft는 문제 재현 후 2주 만에 수정 완료
  - 과거 GraphNinja 수정에는 7개월, GraphGhost는 5개월 소요

### 로그 우회 탐지 방법
- **KQL 쿼리**를 통해 Graph Activity 로그와 Sign-In 로그의 **Session ID** 또는 **UniqueTokenIdentifier**를 비교
  - Graph Activity에는 존재하지만 Sign-In 로그에는 없는 세션은 우회된 로그인으로 판단 가능
  - 단, **E5 라이선스**가 있어야 Graph Activity 로그 수집 가능
- 예시 KQL 쿼리:
  ```
  MicrosoftGraphActivityLogs
  | where TimeGenerated > ago(8d)
  | join kind=leftanti (union isfuzzy=true
  SigninLogs,
  AADNonInteractiveUserSignInLogs,
  AADServicePrincipalSignInLogs,
  AADManagedIdentitySignInLogs,
  MicrosoftServicePrincipalSignInLogs
  | where TimeGenerated > ago(90d)
  | summarize arg_max(TimeGenerated, *) by UniqueTokenIdentifier
  )
  on $left.SignInActivityId == $right.UniqueTokenIdentifier
  ```
  - 필요 시 `SessionId` 기준으로 비교 가능
  - 탐지 결과를 기반으로 **Azure Log Search Alert Rule** 설정 가능

### 네 가지 로그인 로그 우회 요약
| 발견 시점 | 방식 | 토큰 발급 여부 | Microsoft 인정 여부 |
|------------|---------------------------------------------|----------------|----------------|
| 2023-08 / 2024-05 | 외부 테넌트 ID 지정으로 비밀번호 검증 로그 미생성 | X | X |
| 2024-12 / 2025-04 | 잘못된 Client ID로 인증 실패 유도 | X | X |
| 2025-09-20 | 스코프 반복 입력으로 SQL 컬럼 오버플로 | O | X |
| 2025-09-28 | 긴 User-Agent 문자열로 SQL 컬럼 오버플로 | O | N/A |

### Microsoft 보안 프로세스에 대한 비판
- ## Entra ID 로그인 로깅 기능의 다수 파라미터에서 결함 발견
  - `tenant ID`, `client ID`, `scope`, `user-agent` 등 핵심 필드에서 반복적 취약점 발생
  - 단순한 **입력값 검증 실패**로 인한 문제로, 복잡한 공격이 아님
  - Microsoft의 **보안 검토 및 품질 관리 부재** 지적
  - 수년간 동일 영역에서 유사한 결함이 반복
  - AI 코드 생성 도입 여부나 코드 관리 과정에서의 누락 가능성 제기
- ## 공개 투명성 부족
  - 네 건 모두 CVE 미발급, 공식 공지 없음
  - Microsoft가 CNA로서 자사 취약점 공개 여부를 독점적으로 결정

### 결론
- Azure Entra ID의 로그인 로그는 **전 세계 조직의 침입 탐지 핵심 데이터**
  - 로그 누락 시 공격 탐지 체계 전체가 무력화될 수 있음
- 발견된 네 가지 취약점은 모두 **간단한 입력값 퍼징(fuzzing)** 으로 탐지 가능했던 수준
- Microsoft는 이러한 반복적 결함에 대해 **공개적 설명과 투명한 보안 검토 절차 강화**가 필요함
- 관리자와 보안 담당자는 **로그 교차 검증 및 KQL 기반 탐지 규칙**을 통해 방어 체계를 보완해야 함

## Comments



### Comment 53527

- Author: neo
- Created: 2026-03-22T06:33:25+09:00
- Points: 1

###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47448994) 
- CISA가 발표한 **Microsoft 침해 사건 보고서**를 떠올리게 됨  
  국가 지원 해커가 Microsoft를 뚫고 미 국무부 등 여러 기관에 침투한 사건이었음  
  놀라운 점은 Microsoft가 아니라 국무부의 한 **시스템 관리자**가 메일 로그 이상을 발견해 침입을 찾아냈다는 것임  
  [CISA 보고서 링크](https://www.cisa.gov/sites/default/files/2024-03/CSRB%20Revi...)  
  - CISA 같은 기관들도 이미 **DOGE**에 의해 무력화된 느낌임  
  - Azure 보안은 예전부터 **농담 수준**이었음  
    Windows 시절의 문제를 그대로 클라우드로 옮겨왔고, 테넌트 간 격리 실패 사건이 두 번이나 있었음  
    관련 기사: [Azure’s Security Vulnerabilities Are Out of Control](https://www.lastweekinaws.com/blog/azures_vulnerabilities_ar...) / [Microsoft comes under blistering criticism for “grossly irresponsible” security](https://arstechnica.com/security/2023/08/microsoft-cloud-sec...)  
  - 그 시절엔 미국에 진짜 **사이버 방어 전문가**들이 있었음  

- ProPublica와 ArsTechnica가 Azure를 정면 비판한 기사에서, 연방 사이버 전문가들이 Microsoft 클라우드를 “형편없다”고 표현했다고 함  
  [기사 링크](https://arstechnica.com/information-technology/2026/03/feder...)  
  - 실제로는 한 전문가가 **문서 품질**을 그렇게 표현했는데, ProPublica가 Azure 전체로 확대 해석한 것 같음  
  - Ars는 단순히 **라이선스 재게시**한 것뿐임  
  - 내가 아는 Azure 보안 엔지니어들은 거의 **멘탈 붕괴** 상태임. 약 12명 중 절반은 번아웃, 나머지는 역량이 너무 낮음  
  - Bloomberg나 CNBC는 이 사건을 다루지 않았음. 누군가 **언론 연결망**으로 알려줬으면 함  

- 지금의 사이버보안 상태는 **문명 전체가 의존하는 시스템**치고는 너무 허술함  
  마치 구멍 난 배를 덕트테이프로 막고 대양으로 나가는 꼴임  
  - 더 심각한 건, 업계가 그 구멍을 막겠다며 **기관총 탑**을 더 세우자는 식으로 대응한다는 점임  

- SQL 로그 관련 논의에서, 공격자가 너무 긴 입력을 보내 **컬럼 길이 초과**로 INSERT가 실패한 상황으로 보임  
  그 결과 로그인 시도 기록이 남지 않았다는 설명임  
  - 두 서비스가 따로 동작하는 구조였음. 검증 서비스가 실패를 감지하고 로그 서비스에 기록을 요청했지만, 로그 서비스가 실패해도 검증 서비스는 그대로 응답을 보냈음  
    인증 흐름이 너무 **복잡하게 설계된 구조적 문제**로 보임  

- Azure의 **감사 로그**가 실제 동작과 다르게 기록된 경험이 있음  
  클라이언트 시크릿을 삭제했는데, UI는 B를 지운다고 했지만 API는 A만 남기는 식으로 동작함  
  결국 로그에는 내가 한 것처럼 기록됐지만 실제로는 시스템 버그였음  
  이런 경험 이후로 Azure 로그뿐 아니라 **감사 로그 전반에 대한 신뢰**가 흔들렸음  
  법정에서 증거로 쓰기엔 위험하다고 생각함  
  - 그래서 나는 변경 전 **확인 단계**를 반드시 거치는 UI를 선호함. ‘비디오게임식’ 자동 저장 인터페이스는 너무 위험함  
  - Azure 포털(신버전, 구버전 포함)은 **버그 투성이**라 놀랍지도 않음. 버튼 하나 잘못 눌러 다른 객체가 바뀌는 경우도 있음  
  - 이 사례는 동시 편집 환경에서 **set 연산 vs delete 연산**의 위험성을 보여주는 좋은 교육 예시임. 로그는 정확했지만 UI 설계가 문제였음  
  - 결국 사용자는 단지 **의도를 표현**할 뿐, 실제 실행은 프런트엔드가 제어한다는 점이 무섭게 느껴짐  

- 최근 EntraID 취약점들에 비하면 **로그 우회**는 덜 중요해 보임  
  - 하지만 핵심 인증 로그가 ‘best-effort’로만 작동한다면, **보안 감사의 근거**로는 심각한 문제임  
  - 결국 성공적이고 은밀한 공격은 **여러 취약점의 협업**으로 이루어지는 법임  

- Microsoft가 **Notepad**에도 치명적 취약점을 넣은 적이 있으니, 이런 일은 놀랍지 않음  

- 예전에 Azure VPN을 평가했을 때, 연결 성공/실패 로그가 전혀 남지 않았음  
  문제를 제기하자 Microsoft는 “그걸 **새 기능 요청**으로 등록하라”고 했음  
  그때 Azure에 대한 **신뢰를 완전히 잃음**. 시간이 지나도 나아지지 않고 오히려 악화되는 느낌임  

- IT 관리자들이 Microsoft를 계속 쓰는 이유는 **선택지가 없기 때문**임  
  - 나처럼 .NET 기반 LOB 앱과 각종 SaaS를 관리해야 하는 환경에서는 Microsoft 솔루션이 가장 현실적인 선택임  
    예산도 적고 인력도 부족하니, 그냥 **급여 받고 퇴근할 수 있는 수준**으로만 유지함  
  - 젊은 관리자들은 Microsoft를 **싫어하는 경향**이 강함. 세대 차이일 수도 있음  
  - “**아무도 X를 사서 해고된 적은 없다**”는 말처럼, Microsoft 선택은 커리어 리스크가 적음  

- Microsoft가 Azure 취약점 재현에 실패해 **영상 증거**를 요청했을 때, 단 한 줄의 **curl 명령어**로 보여줬다는 점이 인상적이었음  
  정말 통쾌한 순간이었음