MFA를 켜도 뚫린다. OAuth Device Code 피싱은 피해자가 진짜 microsoft.com에서 인증하지만 세션 토큰이 공격자에게 전달된다. 성공률 50%의 원리를 분석한다.
2025년 말, Microsoft는 주목할 만한 통계를 발표했다. 토큰 탈취 공격 피해 조직의 79%가 MFA를 제대로 적용하고 있었다. 비밀번호만으로는 부족하니 MFA를 켜라는 조언은 이제 보안의 상식이다. 그런데 MFA를 켜도 뚫리는 공격이 있다면?
2024년 8월부터 러시아 연계 위협 그룹 Storm-2372가 사용하기 시작한 OAuth Device Code 피싱은 피해자가 직접 MFA 인증을 완료하게 만드는 공격이다. 가짜 로그인 페이지도 없고, 피싱 도메인도 없다. 피해자는 진짜 microsoft.com에서 인증한다. 그런데 그 인증의 결과물은 공격자에게 전달된다.
일반 피싱 성공률이 2.7%인 반면, 이 기법의 성공률은 50% 이상이다. 18.5배 차이. 왜 이런 일이 가능한지, 공격자는 왜 이 방식을 선택하는지 분석한다.
OAuth 2.0 Device Authorization Grant(RFC 8628)는 키보드가 없는 기기를 위해 설계된 인증 방식이다.
스마트 TV에서 넷플릭스에 로그인하는 장면을 떠올려 보자. 리모컨으로 이메일과 비밀번호를 하나하나 입력하는 건 고통이다. 그래서 다른 방법을 쓴다.
간단하고 편리하다. 하지만 이 편리함 안에 치명적인 가정이 하나 숨어 있다. "코드를 요청한 사람 = 코드를 입력하는 사람" 이라는 가정이다.
정상적인 경우:
| 단계 | 동작 |
|---|---|
| 1 | 사용자가 스마트 TV에서 "로그인" 버튼을 누른다 |
| 2 | TV가 Microsoft에 디바이스 코드를 요청한다 |
| 3 | TV 화면에 코드(예: WDJB-MJHT)와 microsoft.com/devicelogin 주소가 표시된다 |
| 4 | 사용자가 스마트폰으로 해당 주소에 접속, 코드를 입력한다 |
| 5 | 사용자가 로그인 + MFA를 완료한다 |
| 6 | TV가 인증 토큰을 받아 로그인된다 |
공격자가 악용하는 경우:
| 단계 | 동작 |
|---|---|
| 1 | 공격자가 자신의 서버에서 디바이스 코드를 요청한다 |
| 2 | 공격자가 받은 코드를 피싱 이메일에 넣어 피해자에게 보낸다 |
| 3 | 피해자가 microsoft.com/devicelogin에 접속해 코드를 입력한다 |
| 4 | 피해자가 자신의 계정으로 로그인 + MFA를 완료한다 |
| 5 | 공격자의 서버가 인증 토큰을 받는다 |
| 6 | 공격자가 피해자의 이메일, 파일, Teams에 접근한다 |
차이가 보이는가? 1단계가 다르다. 코드를 요청한 주체가 사용자가 아니라 공격자다. 나머지 흐름은 동일하다. 피해자는 정상적인 인증 절차를 밟고 있다고 생각하지만, 그 결과물인 토큰은 공격자에게 간다.
OAuth 피싱 MFA 우회
일반적인 피싱은 micros0ft-login.com 같은 가짜 도메인을 만들어야 한다. URL을 확인하는 습관이 있는 사용자라면 걸러낼 수 있다. 이메일 보안 솔루션도 의심스러운 URL을 차단한다.
Device Code 피싱은 다르다. 피해자가 접속하는 주소는 microsoft.com/devicelogin — Microsoft가 운영하는 실제 페이지다. SSL 인증서도 Microsoft의 것이다. URL 필터링에 걸리지 않는다. "주소를 확인하라"는 보안 교육이 무력화된다.
AiTM(Adversary-in-the-Middle) 피싱은 공격자가 중간에서 트래픽을 가로채야 한다. 프록시 인프라를 구축하고 실시간으로 세션을 가로채야 한다. 기술적 복잡도가 높다.
Device Code 피싱은 프록시가 필요 없다. 피해자가 MFA를 완료하면, Microsoft가 직접 토큰을 발행한다. 그 토큰이 공격자의 앱으로 전달될 뿐이다. 공격자는 비밀번호도, MFA 코드도 볼 필요가 없다.
| 비교 항목 | Device Code 피싱 |
|---|---|
| 로그인 페이지 | 진짜 microsoft.com (일반 피싱: 가짜 도메인, AiTM: 프록시 경유) |
| MFA 대응 | 피해자가 직접 완료 (일반: 우회 불가, AiTM: 실시간 가로채기) |
| 인프라 복잡도 | 낮음 (일반: 낮음, AiTM: 높음) |
| URL 필터링 | 차단 불가 (일반: 차단 가능, AiTM: 일부 차단) |
| 성공률 | 50% 이상 (Microsoft DART 보고서 기준, 일반: 2.7%) |
공격이 한 번 성공하면 끝이 아니다. 공격자가 얻는 것은 두 가지 토큰이다.
Access Token — 즉시 사용 가능한 열쇠. 1시간 유효.
Refresh Token — 열쇠를 계속 복사할 수 있는 마스터 키. 90일 유효. 사용할 때마다 90일이 갱신된다. 89일째에 한 번만 사용하면 다시 90일. 사실상 무기한 접근이 가능하다.
더 심각한 것은 비밀번호를 바꿔도 토큰은 살아 있다는 점이다. 토큰은 비밀번호와 독립적으로 동작한다. 관리자가 명시적으로 토큰을 폐기(revoke)해야만 접근이 차단된다.
Microsoft가 "Storm-2372"로 명명한 러시아 연계 위협 그룹이 2024년 8월부터 이 기법을 사용하고 있다.
| 시기 | 사건 |
|---|---|
| 2024년 8월 | Storm-2372, Device Code 피싱 캠페인 시작 |
| 2025년 1월 | APT29(Midnight Blizzard)도 동일 기법 사용 확인 |
| 2025년 2월 | Microsoft, Storm-2372 공식 경보 발표 |
| 2025년 2월 14일 | Storm-2372, Authentication Broker 클라이언트 ID 악용으로 전술 진화 |
| 2025년 10월 | TA2723(금전 목적 그룹), 급여 명세서 주제로 대규모 캠페인 |
| 2025년 12월 | Proofpoint, "전례 없는 규모의 확산" 경고 |
Storm-2372의 전형적인 공격 시나리오:
TA2723은 더 직접적이다. "10월 급여명세서 수정본"이라는 제목의 이메일에 디바이스 코드를 포함시킨다. 피해자는 급여 문서를 확인하려고 코드를 입력하지만, 실제로는 Microsoft 365 전체 접근 권한을 넘기게 된다.
| 지표 | 수치 |
|---|---|
| 타겟 계정 수 | 약 3,000개 (Proofpoint) |
| 피해 M365 테넌트 | 900개 이상 (RH-ISAC) |
| 성공률 | 50% 이상 (Proofpoint) |
| 타겟 산업 | 정부, NGO, 국방, IT, 통신, 의료, 교육, 에너지 (Microsoft) |
공격자는 토큰으로 Microsoft Graph API를 호출한다. 합법적인 API 요청이므로 보안 솔루션에 정상 트래픽으로 보인다.
| 행위 | 설명 |
|---|---|
| 이메일 전체 열람 | Mail.Read 권한으로 받은편지함, 보낸편지함 전체 접근 |
| 이메일 발송 | Mail.Send 권한으로 피해자 명의 이메일 발송 (BEC 공격) |
| 파일 탈취 | Files.ReadWrite.All로 OneDrive, SharePoint 문서 다운로드 |
| 내부 피싱 확산 | 탈취한 계정으로 동료에게 새로운 Device Code 피싱 메일 발송 |
가장 효과적인 방어는 Device Code Flow 자체를 차단하는 것이다. 대부분의 조직에서 이 인증 방식이 필요한 경우는 드물다.
Microsoft Entra 관리센터 설정:
| 단계 | 설정 |
|---|---|
| 1 | Entra 관리센터 > 보호 > 조건부 액세스 > 정책 |
| 2 | 새 정책 만들기 |
| 3 | 사용자: 모든 사용자 (또는 특정 그룹) |
| 4 | 대상 리소스: 모든 클라우드 앱 |
| 5 | 조건 > 인증 흐름: "디바이스 코드 흐름" 선택 |
| 6 | 액세스 제어: 액세스 차단 |
| 7 | 정책 사용: 보고서 전용으로 먼저 테스트 후 활성화 |
Microsoft는 25일 이상 Device Code Flow를 사용하지 않은 조직에 대해 자동으로 차단 정책을 배포하기 시작했다.
조건부 액세스를 바로 적용하기 어렵다면, 로그 모니터링으로 이상 징후를 탐지할 수 있다.
Azure AD 로그인 로그에서 확인할 항목:
| 필드 | 확인 내용 |
|---|---|
| AuthenticationProtocol = deviceCode | Device Code Flow 사용 여부 |
| IPAddress | 예상 외 위치에서 토큰 사용 |
| DeviceDetail.isManaged = false | 관리되지 않는 기기에서 접근 |
의심 패턴:
토큰 탈취가 의심되면 즉시 다음 조치를 취해야 한다.
| 순서 | 조치 |
|---|---|
| 1 | Entra ID > 사용자 > 세션 철회로 토큰 폐기 |
| 2 | 비밀번호 재설정 (임시 비밀번호 발급 후 강제 변경) |
| 3 | Enterprise Applications에서 의심 앱 비활성화 |
| 4 | 공격자가 등록한 기기 삭제 |
| 5 | 메일 전달 규칙, 자동 삭제 규칙 확인 및 제거 |
비밀번호 재설정만으로는 부족하다. 토큰을 명시적으로 폐기해야 공격자의 접근이 차단된다.
"URL을 확인하라"는 교육은 이 공격에 효과가 없다. URL이 진짜이기 때문이다.
"MFA를 켜라"는 조언도 효과가 없다. 피해자가 직접 MFA를 완료하기 때문이다.
그렇다면 무엇을 가르쳐야 하는가?
"요청하지 않은 디바이스 코드는 입력하지 마라."
사용자가 스스로 시작하지 않은 인증 요청은 모두 의심해야 한다. 특히 이메일, 메신저로 전달받은 코드를 microsoft.com/devicelogin에 입력하라는 요청은 100% 피싱이다. 스마트 TV나 CLI 도구를 직접 사용하고 있지 않다면, 디바이스 코드를 입력할 이유가 없다.
OAuth 피싱이 MFA를 우회하는 이유는 인증 흐름 자체를 공격하기 때문이다. 사용자는 정상적인 Microsoft/Google 로그인 페이지에서 인증하고, MFA까지 완료한다. 하지만 최종 동의 화면에서 공격자의 앱에 토큰 발급을 승인하면, 공격자는 MFA 없이 사용자의 데이터에 접근할 수 있는 OAuth 토큰을 획득한다.
AI 활용 안내 이 글은 AI(Claude)의 도움을 받아 작성되었습니다. 인용된 통계와 사례는 참고 자료에 명시된 출처에 근거하며, 설명을 위한 일부 표현은 각색되었습니다.
면책 조항 본 글은 보안 인식 제고를 위한 교육 목적으로 작성되었습니다. 언급된 공격 기법을 실제로 시도하는 행위는 「정보통신망법」, 「형법」 등에 따라 처벌받을 수 있으며, 본 블로그는 이에 대한 법적 책임을 지지 않습니다.