Azure 디바이스 코드 공격: 악용부터 탐지까지

TL; DR

무엇이다 : 디바이스 코드 피싱은 공격자가 마이크로소프트에 대한 합법적인 디바이스 코드 인증 흐름을 시작하는 OAuth 악용 기법입니다. Entra ID그런 다음 사용자가 생성된 코드를 실제 login.microsoft.com/devicelogin 페이지에 입력하도록 유도하여 공격자는 암호를 캡처하지 않고도 유효한 액세스 토큰을 얻습니다. 

왜 문제 : 국가 차원의 공격 기법(2024년 8월부터 활동 중인 러시아 연계 STORM-2372)에서 불과 1년도 안 되어 일반적인 공격 도구로 변모했습니다. 2026년 4월 마이크로소프트가 공개한 EvilTokens PhaaS 툴킷은 전체 공격 과정을 자동화하여 15분 코드 만료 시간을 무력화하고 24시간마다 10~15개의 맞춤형 캠페인을 실행합니다. 

탐지하기 어려운 이유: 가짜 로그인 페이지도 없고, 도메인을 도용한 공격도 없으며, 자격 증명 탈취도 없고, 악성 페이로드도 없습니다. 관련된 URL은 login.microsoft.com/devicelogin뿐입니다. 피해자의 실제 기기에서 MFA(다단계 인증)가 성공적으로 완료되므로 이메일 게이트웨이, EDR(전망 관리 시스템) 또는 신원 보호 제품이 탐지하도록 학습된 모든 신호는 이상 없음으로 판정됩니다. 

AiTM과의 차이점은 다음과 같습니다. 중간자 공격(AiTM)은 가짜 로그인 페이지를 프록시하여 세션 쿠키를 탈취합니다. 반면, 장치 코드 피싱은 프록시를 완전히 건너뛰고 피해자가 실제 Microsoft 페이지에서 인증하므로 탐지, 차단 또는 제거할 수 있는 AiTM 인프라가 존재하지 않습니다. 

코어 검출 신호: 인증 방법이 장치 코드이고, 액세스하는 리소스가 Microsoft 자체 클라이언트(예: Azure CLI, Microsoft Office)이며, 로그인이 비정상적인 위치에서 수행되거나 일반적으로 장치 코드를 사용하여 인증하지 않는 주체에 의해 수행되는 경우 성공적인 로그인이 발생합니다. 정상적인 최종 사용자 워크플로에서는 이러한 패턴이 거의 발생하지 않으므로, 많은 조직에서는 이러한 패턴이 발생할 때마다 조사를 진행해야 합니다. 

감지 시 즉각적인 대응: 사용자의 접근 권한을 즉시 취소하십시오(참조). Microsoft의 문서해당 사용자의 계정을 비활성화하고 역할 할당을 제거하십시오. 새로 고침 토큰을 취소해도 이미 발급된 액세스 토큰은 무효화되지 않으며 만료될 때까지 유효합니다. 의심스러운 세션에서 발생하는 악성 활동을 추적하십시오. 토큰 취소만으로는 충분하지 않습니다. 공격자가 이미 지속성을 확보했을 수 있습니다.

주요 정책 조치: 문서화된 업무상 필요성이 없는 사용자 그룹에 대해서는 조건부 액세스를 통해 장치 코드 인증 흐름을 차단하십시오. 마이크로소프트의 지침에서도 이를 권장하고 있습니다. 대부분의 기업 사용자(대부분의 개발자 포함)는 실제로 이러한 방식으로 인증하는 경우가 거의 없습니다. 장치 코드 인증이 정말로 필요한 경우에는 지오펜싱을 통해 신뢰할 수 있는 위치로 제한하십시오. 

보안팀이 기기 코드 피싱에 대해 알아야 할 사항

러시아 국가와 연계된 국가 주도 위협 행위자(STORM-2372)가 2024년 8월부터 전 세계 정부 기관, 방위 산업체, NGO, 통신, 에너지 및 의료 기관을 대상으로 기기 코드 피싱 공격을 감행하고 있습니다. 

이는 마이크로소프트가 패치할 수 있는 취약점이 아니라, 모든 주요 ID 공급자가 지원하는 OAuth 2.0 장치 코드 프로토콜의 설계 특성으로 인한 것입니다. 이 공격은 이러한 특성을 우회합니다. MFA (피해자가 자발적으로 완료하기 때문에) 보안 도구가 의심스러운 인프라를 탐지할 만한 흔적을 남기지 않고 (유일한 URL은 microsoft.com임), 생성된 토큰은 비밀번호 재설정 후에도 유지됩니다. 일반적인 이메일 게이트웨이, CASB 및 URL 스캐너는 공격 링크를 안전하다고 평가합니다. is 안전합니다. 마이크로소프트 자체 로그인 페이지로 연결됩니다. 

침해 후 공격자들은 10분 이내에 영구 장치를 등록하고, Microsoft Graph를 통해 조직 구조를 파악하고, 고가치 대상(재무, 임원, 관리직)을 필터링하고, 숨겨진 받은 편지함 규칙을 만들고, 송금 내역과 임원 서신을 유출하는 등 비즈니스 이메일 침해 및 금융 사기의 주요 자료를 탈취하는 것으로 관찰되었습니다. 

즉각적인 조직적 조치: 명시적으로 요구하지 않는 모든 사용자에 대해 조건부 액세스를 통한 장치 코드 인증 흐름을 차단하고, 사고 대응 플레이북에는 OAuth 토큰 해지(단순한 비밀번호 재설정이 아님) 기능이 포함되어 있으며, 중요 계정에 대한 토큰 바인딩을 배포합니다. 전체 의사 결정 프레임워크는 아래 전략적 권장 사항을 참조하십시오.

피싱 URL이 microsoft.com이라면 어떻게 해야 할까요?

디바이스 코드 피싱은 마이크로소프트의 OAuth 디바이스 코드 흐름 구현을 악용하는 토큰 탈취 기법입니다. 일반적인 피싱 공격과는 달리, 공격자는 피해자를 실제 마이크로소프트 URL로 유도합니다. 유사 도메인이나 리버스 프록시, 또는 타이포스쿼트가 아닙니다. 피해자는 실제 마이크로소프트 로그인 페이지에 접속하여 다단계 인증(MFA)을 완료하고 정상적인 성공 화면을 보게 됩니다. 하지만 피해자에게 권한을 부여하는 추가 인증 수단인 인증 토큰은 완전히 다른 컴퓨터에 있는 공격자에게 조용히 전송됩니다. 자격 증명 탈취도, 세션 하이재킹도, 탐지하거나 차단해야 할 공격자 인프라도 없습니다. 그저 설계된 대로 작동하는 정상적인 OAuth 흐름일 뿐이며, 단지 잘못된 대상에게 전달될 뿐입니다. 

오늘날 이 취약점은 대규모로 악용되고 있으며, 근본적인 결함은 OAuth 표준 자체에 있지만, Entra ID'의 구현 방식이 바로 이를 무기화하기 쉽게 만드는 요인입니다. 마이크로소프트는 이를 다음과 같이 설명했습니다. STORM-2372에 대한 지속적인 캠페인러시아 국가 이익과 연계된 것으로 중간 정도의 신뢰도를 가진 위협 행위자로 평가되는 단체입니다. 이 단체는 적어도 2024년 8월부터 여러 대륙에 걸쳐 정부 기관, 방위 산업체, NGO, 통신 사업자, 에너지 회사 및 의료 기관을 표적으로 삼아 왔습니다. 2026년 4월, 마이크로소프트는 상당한 규모의 공격 확대를 기록했습니다. 기기 코드 악용을 처음부터 끝까지 자동화하는 AI 기반 피싱 서비스(PhaaS) 툴킷인 EvilTokens의 등장즉석에서 실시간 코드를 생성하여 15분 만료 시간을 무력화하고, 생성형 AI를 사용하여 초개인화된 미끼를 만들고, 24시간마다 10~15개의 서로 다른 캠페인을 실행하는 방식입니다. 이 기술은 1년도 채 안 되어 국가 차원의 전문 공격 기법에서 일반적인 공격 도구로 변모했습니다.  

이 블로그 게시물에서는 프로토콜 수준에서 이 공격이 정확히 어떻게 작동하는지 분석하고, 실제 시스템을 사용한 시뮬레이션을 통해 자세히 살펴보겠습니다. Entra ID 로그 캡처를 제공하고, 현재 자체 환경에서 실행할 수 있는 KQL 헌트 쿼리를 제공하며, 공격으로 생성된 로그에서 파생된 탐지 로직을 확장합니다. 

디바이스 코드 흐름은 어떻게 되나요?

2019년 8월에 발표된 RFC 8628에 정의된 OAuth 2.0 장치 권한 부여(Device Authorization Grant)는 브라우저가 없거나 입력 기능이 제한적인 장치(스마트 TV, 게임 콘솔, IoT 센서, 디지털 사이니지, 회의실 하드웨어, Azure CLI 또는 AWS CloudShell과 같은 CLI 도구 등)를 위해 설계된 인증 흐름입니다. 사용자는 장치에서 직접 로그인하는 대신 짧은 영숫자 코드와 URL을 받게 됩니다. 사용자는 별도의 장치(일반적으로 휴대폰이나 노트북)에서 해당 URL을 열고 코드를 입력하여 다단계 인증(MFA)을 포함한 인증을 완료합니다. 그동안 원래 장치는 백그라운드에서 권한 부여 서버를 주기적으로 확인하고 사용자가 승인하면 액세스 토큰을 수신합니다. 

이 흐름은 널리 지지받고 있습니다: 마이크로소프트 Entra IDGoogle, GitHub, Okta 및 대부분의 주요 ID 공급자가 이를 구현하며 Azure CLI(`az login`)의 기본 로그인 방식입니다. 일상적인 웹 애플리케이션에서 가장 일반적인 OAuth 흐름은 아니지만, 헤드리스 환경이나 입력이 제한된 환경에서 표준 메커니즘으로 사용되며 엔터프라이즈 툴링, DevOps 파이프라인 및 소비자 스트리밍 플랫폼 전반에서 활발하게 사용되고 있습니다. 

설계상의 위험은 표준 자체에 내재되어 있지만, Entra ID이러한 구현 방식은 문제를 더욱 악화시키기 때문에 실제 존재하는 모든 피싱 키트가 마이크로소프트를 표적으로 삼는 것입니다. 마이크로소프트 자체도 이제 명시적으로 필요하지 않은 모든 곳에서 조건부 액세스를 통해 해당 흐름을 차단할 것을 권장합니다. 

결정적인 설계 결함: device_code는 폴링 장치와 인증 사용자 간의 유일한 연결 고리입니다. Microsoft는 폴링 장치가 사용자가 인증하려는 장치인지 여부를 확인하지 않습니다. 장치 ID, 네트워크 위치, 신뢰 상태 등을 전혀 검사하지 않습니다. device_code를 가지고 있고 이를 폴링하는 사용자가 토큰을 획득합니다. 

공격 분석

디바이스 코드 흐름을 편리하게 사용할 수 있게 해주는 바로 그 편리함이 악용될 수 있는 요인이기도 합니다. 프로토콜이 폴링 장치를 인증 사용자와 직접 연결하지 않기 때문에, 유효한 디바이스 코드를 획득한 공격자는 피해자가 로그인을 완료하는 순간, 사용자 몰래 액세스 및 갱신 토큰을 탈취할 수 있습니다. 피싱 인프라도, 자격 증명 가로채기도, 다단계 인증(MFA) 우회도 필요 없습니다. 그저 마이크로소프트의 정식 로그인 페이지가 설계된 목적대로 작동하지만, 악의적인 목적으로 사용될 뿐입니다. 

공격자들이 이 흐름을 어떻게 무기화하는가

마이크로소프트의 디바이스 코드 엔드포인트는 설계상 개방형입니다. 클라이언트 비밀 키도, 디바이스 등록도, 소유 증명도 필요하지 않습니다.

공격자는 잘 알려진 Microsoft 클라이언트 ID(Azure CLI, Microsoft Office 또는 기타 Microsoft 공식 공개 클라이언트)를 사용하여 인증되지 않은 POST 요청을 한 번만 보내면 즉시 유효한 장치 코드를 수신할 수 있습니다. 이러한 공식 클라이언트 ID는 기본적으로 신뢰되고, 광범위한 권한 범위에 대해 사전 동의가 되어 있으며, 항상 사용 가능하므로 공격자에게는 더할 나위 없이 유리합니다. 공격자는 대상 도메인을 식별한 후 테넌트 ID를 쉽게 얻을 수 있습니다. 

curl -X POST https://login.microsoftonline.com/<tenant-id>/oauth2/v2.0/devicecode \ 
  -d "client_id=04b07795-8ddb-461a-bbee-02f9e1bf7b46&scope=https://management.azure.com/.default" 

공격자는 인증 URL과 사용자 코드를 팀즈 회의 초대, 문서 공유 알림, IT 보안 경고 등과 같은 그럴듯한 미끼로 위장하여 이메일, 팀즈, WhatsApp, Signal 또는 기타 수단을 통해 전송합니다. STORM-2372는 특히 팀즈 회의 알림과 WhatsApp 그룹 초대를 사칭하는 것으로 확인되었습니다. 피해자가 이메일을 읽는 동안 공격자의 스크립트는 이미 폴링을 시작합니다. 피해자가 인증을 완료하는 순간, 폴링 루프는 전체 토큰 쌍을 수신합니다. 

기존 보안 제어가 실패하는 이유

기기 코드 피싱이 특히 위험한 이유는 기존의 여러 방어 체계를 동시에 무력화시키기 때문입니다. 

마이크로소프트의 ID 플랫폼 입장에서 보면, 이는 완전히 합법적인 로그인이었습니다. 

• MFA가 우회된 것이 아니라 활용된 것입니다. 피해자는 정상적으로 MFA를 완료합니다. 결과적으로 생성되는 토큰에는 mfaAuthenticated=true가 포함됩니다.
• 탐지할 공격자 인프라가 없습니다. 공격 체인의 유일한 URL은 microsoft.com이며, 모든 위협 인텔리전스 피드에서 완벽한 평판을 유지하고 유효한 EV 인증서가 있습니다. 이메일 게이트웨이, CASB, URL 샌드박스 및 프록시 안전 링크 재작성 기능 모두 해당 URL을 검사하고 안전하다고 반환합니다.
• 새로 고침 토큰은 비밀번호 재설정 후에도 유지됩니다. AiTM 공격에서 탈취되는 세션 쿠키와 달리, OAuth 새로 고침 토큰은 장기간 여러 기기에서 접근 권한을 유지하도록 설계되었습니다. 사용자의 상호 작용이나 다단계 인증(MFA) 재인증 절차 없이도 조용히 새 액세스 토큰으로 교환될 수 있습니다. 피해자의 비밀번호를 재설정해도 새로 고침 토큰은 취소되지 않으며, 공격자는 토큰이 명시적으로 취소되지 않는 한 계속해서 접근 권한을 유지합니다.
• 포렌식 흔적은 최소화되어 있습니다. 로그인 로그에는 위험 수준 = 없음, MFA = 성공으로 기록된 성공적인 로그인 내역이 나타납니다. 여러 번의 로그인 실패, 자격 증명 변경, 의심스러운 객체 생성 등의 기록은 없습니다. 유일한 잠재적 위험 신호는 예상치 못한 IP 주소에서 발생한 비대화형 토큰 갱신뿐이며, 이는 특별히 모니터링하는 경우에만 발생합니다. 

중요: 이는 중간자 공격(AiTM)이 아닙니다. EvilProxy와 같은 AiTM 도구는 리버스 프록시를 통해 세션을 가로채 MFA 인증 후 쿠키를 캡처합니다. 이를 위해서는 공격자가 제어하는 ​​인프라(도메인, 인증서, 활성 서버)가 필요하며, 이러한 인프라는 모두 포렌식 흔적을 남깁니다. 반면, 디바이스 코드 피싱은 단 하나의 HTTP POST 요청과 그럴듯한 이메일만으로 가능합니다. 이렇게 얻은 토큰은 세션 쿠키보다 수명이 길고 적용 범위가 넓으며, 조사하거나 차단해야 할 공격자 인프라가 전혀 없습니다.

공격자 관점: 단계별 흐름

전체 공격 과정을 보여주기 위해, 전용 연구용 테넌트(glich.net)를 사용하는 통제된 실험실 환경에서 이를 재현했습니다. 시뮬레이션은 helpdesk@glich.net으로 위장한 공격자가 roni@glich.net 사용자를 대상으로, 기기 코드 피싱 미끼를 사용하는 상황을 모델링합니다. 자격 증명 확인 요청. 

1단계: 장치 코드 생성

공격자는 POST 요청을 보냅니다. Entra IDAzure CLI의 공개 클라이언트 ID를 사용하는 장치 인증 엔드포인트는 장치 코드와 사용자 코드를 수신하고 즉시 토큰 엔드포인트 폴링을 시작합니다. 

2단계: 피싱 미끼 제작 및 전달

공격자는 긴급한 것처럼 보이는 이메일(Teams 회의 초대, 자격 증명 확인 요청 또는 IT 보안 경고로 위장)에 장치 코드와 login.microsoft.com/devicelogin URL을 포함시킵니다. 

3단계: 사용자 승인

사용자는 이메일을 수신하고 공격자에게 접근 권한을 부여합니다. 

피해자가 브라우저에 코드와 자격 증명을 입력하면 폴링 루프가 토큰을 수집합니다. 

4단계: 착취 후 단계

유효한 액세스 토큰과 장기간 갱신 토큰을 확보한 공격자는 피해자의 Microsoft 365 환경에 대한 인증된 액세스 권한을 얻었으며, 시간은 계속 흘러가고 있습니다. Microsoft의 2026월 XNUMX일 분석 AI 기반 장치 코드 피싱 캠페인(2025년 2월에 처음 보고된 STORM-2372 활동의 직접적인 진화)을 분석한 결과, 위협 행위자들이 실제 상황에서 실행하는 침해 후 플레이북이 문서화되었습니다. 그 진행 과정은 일관된 패턴을 따릅니다. 

영구 저장을 위한 장치 등록 

일부 사례에서는 최초 침해 발생 후 10분 이내에 공격자가 탈취된 계정에 새 기기를 등록하여 기본 새로 고침 토큰(PRT)을 생성했습니다. PRT는 개별 토큰이 취소되더라도 유지되는 장기적인 SSO(Single Sign-On) 액세스 권한을 제공하여, 공격자가 탈취된 새로 고침 토큰만으로는 탐지 및 복구가 훨씬 어려운 지속적인 접근 권한을 확보할 수 있도록 합니다. 

마이크로소프트 그래프 정찰 

공격자들은 탈취한 토큰을 사용하여 마이크로소프트 그래프 API에 쿼리를 보내 조직 내부 구조, 사용자 역할 및 권한 할당을 프로그래밍 방식으로 매핑했습니다. 이러한 자동화된 정찰을 통해 공격자들은 어떤 해킹된 계정이 민감한 리소스에 접근 권한을 가지고 있는지, 그리고 그 접근 권한이 어디에 있는지를 신속하게 파악할 수 있었습니다. 권한 에스컬레이션 가능했다. 

고가치 목표물 필터링 

공격자들은 무차별적으로 모든 해킹된 계정을 공격하는 대신, 금융, 경영 또는 관리직에 있는 고가치 인물들을 대상으로 공격 대상을 선별했습니다. 이러한 선택적 접근 방식을 통해 해킹 후 가장 침해적인 활동을 잠재적 이익이 가장 큰 계정에 집중시켰습니다. 

악성 메일의 지속성을 위한 받은 편지함 규칙 

공격자들은 특정 대상을 위해 Microsoft Office 애플리케이션을 사용하여 수신 이메일을 перенаправление, 숨기거나 삭제하는 받은 편지함 규칙을 만들었습니다. 이러한 규칙은 두 가지 목적을 달성했습니다. 첫째, 반복적인 로그인 없이 이메일 통신에 지속적으로 접근할 수 있도록 하고, 둘째, 피해자로부터 침해 증거를 숨기는 것입니다(예: 보안 경고 또는 암호 재설정 알림 자동 삭제). 

표적 이메일 유출 

가장 침해적인 활동은 금융 권한을 가진 사용자들을 대상으로 이루어졌습니다. 공격자들은 이메일 통신 내용을 심층적으로 검색하여 송금 내역, 미결제 청구서, 임원 서신 등 기업 이메일 침해(BEC) 및 금융 사기의 주요 소재가 되는 정보들을 집중적으로 노렸습니다. 

탐지를 피하기 위한 실행 지연 

모든 공격자가 즉시 행동에 나선 것은 아닙니다. 관찰된 여러 사례에서 공격자들은 최초 침해 후 몇 시간 동안 아무런 사후 조치를 취하지 않고 기다렸습니다. 이는 의도적인 회피 전략으로, 의심스러운 인증 이벤트와 로그상의 악성 활동을 분리하여 방어자가 시간적 상관관계를 파악하기 어렵게 만듭니다. 악성 활동이 시작될 무렵에는 해당 활동을 가능하게 한 인증 이벤트는 이미 단기적인 분류 대기열과 실시간 경고 시스템에서 벗어난 상태입니다. 방어자는 침해 발생 후 0일(T+0)에 의심스러운 로그인 시도를 검토하면서 후속 활동이 없다고 판단하고 이를 무해한 것으로 간주하여 종료할 수 있습니다. 그러나 공격자는 몇 시간 후, 원래 경고 메시지가 더 이상 화면에 표시되지 않을 때 데이터 유출을 시작할 수 있습니다. 이처럼 접근과 행동 사이에 의도적인 시간적 간격을 두는 것이 디바이스 코드 피싱 공격이 시간 기반 탐지에 특히 저항력이 있는 이유입니다. 즉, 방어자가 장기간에 걸쳐 명시적으로 상관관계를 분석하지 않는 한, 침해와 그 영향은 동일한 조사 기간에 나타나지 않습니다. 

수비수 관점: 로그에서 무엇을 살펴봐야 할까요?

위협 헌터와 SOC 분석가를 위한 실질적인 정보입니다. Entra ID 로그 캡처를 통해 정확히 무엇을 찾아야 하는지 알 수 있습니다. 

우리는 포착했다 Entra ID 이 흐름에 의해 생성된 로그인 로그 항목입니다. 공격자의 폴링 요청(반복적인 authorization_pending 응답)은 전혀 로그에 기록되지 않습니다. 토큰 발급이 성공적으로 완료된 경우에만 항목이 생성되며, 두 개의 탭으로 나뉘어 표시됩니다. 

항목 1: 상호작용형 (브라우저/피해자 측)

피해자는 microsoft.com/devicelogin에 접속하여 인증 코드를 승인했습니다. 이전 세션 기록을 통해 MFA(다단계 인증)가 완료되었으며, 피해자는 "승인" 버튼을 클릭하는 것 외에는 아무런 불편함도 느끼지 못했습니다. 

항목 2: 비대화형(클라이언트/공격자 측 폴링)

나란히 비교

탐지 기준은 명확합니다. 두 항목 모두 동일한 상관 ID를 공유하지만 사용자 에이전트와 IP 주소가 다릅니다. 브라우저 로그는 Mac의 Chrome을 보여주고, 폴링 로그는 curl을 보여줍니다. 실제 공격 상황에서는 이러한 차이점, 특히 지리적 차이가 잠재적으로 불가능한 이동이나 의심스러운 출처를 시사하는 경우, 이러한 로그 쌍이 경고 시스템을 구축하는 핵심 신호가 됩니다. 

폴링 측 IP를 위협 인텔리전스 피드, IP 평판 목록, 의심스러운 사용자 에이전트 값(로그의 "curl" 예시 등) 및 ASN 메타데이터와 연동하여 보강하면 탐지력이 더욱 강화됩니다. 공격자 인프라는 호스팅 제공업체, 상용 VPN 또는 사용자 네트워크에 합법적으로 존재하지 않는 ASN에서 시작되는 경우가 많습니다. 알려진 악성 ASN으로 확인되거나 블랙리스트에 등재된 폴링 IP는 IP 불일치가 없더라도 높은 신뢰도의 공격 지표로 간주됩니다.

사용자 환경에서 기기 코드 피싱을 탐지합니다.

위협 분석가를 위한 정보: Azure Monitor, Microsoft Sentinel 또는 KQL 호환 SIEM에 대한 KQL 쿼리를 복사하여 붙여넣으세요. 

다음 KQL 쿼리를 사용하여 기기 코드 피싱 활동을 탐지할 수 있습니다. Entra ID 로그인 로그입니다. 이 로그는 Azure Monitor, Microsoft Sentinel 또는 KQL 호환 SIEM에서 바로 복사하여 붙여넣을 수 있도록 설계되었습니다. 

목표는 T+0에 최대한 가까운 시점에 기기 코드 악용을 포착하는 것입니다. 아래 각 쿼리는 비정상적인 기기 코드 사용 패턴, 대화형 및 폴링 방식 간의 IP 또는 사용자 에이전트 불일치, 활성 캠페인을 나타낼 수 있는 대량 코드 생성 등 서로 다른 신호를 대상으로 합니다. 

1. 상관관계 분석을 위해 모든 장치 코드 흐름 이벤트를 표시합니다.

이 쿼리는 모든 장치 코드 흐름의 두 부분(대화형 및 비상호작용형)을 모두 검색합니다. CorrelationId를 기준으로 정렬하거나 결합하여 두 부분을 나란히 비교하고 핵심 탐지 신호인 IP 또는 사용자 에이전트 불일치를 찾습니다. 

SigninLogs 
| where AuthenticationProtocol == "deviceCode" 
    or OriginalTransferMethod == "deviceCodeFlow" 
| project CorrelationId, UserPrincipalName, IPAddress, UserAgent, 
          IsInteractive, TimeGenerated, AppDisplayName, 
          AuthenticationProtocol 
| order by CorrelationId, TimeGenerated asc

2. 레그 간 IP 주소 불일치가 있는 장치 코드 흐름을 감지합니다.

이 쿼리는 CorrelationId를 기준으로 각 장치 코드 흐름의 대화형 및 비대화형 항목을 결합하고 IP 주소가 다른 흐름을 표시합니다. 이는 폴링 클라이언트가 인증 브라우저와 동일한 장치 또는 위치가 아니라는 강력한 지표입니다. 보다 정확한 경고를 위해서는 폴링 IP에 ASN 조회 및 위협 인텔리전스 피드를 추가하여 정보를 보강할 수 있습니다. 예를 들어, 폴링 IP가 호스팅 제공업체, 상용 VPN 또는 블랙리스트에 등록된 IP 범위에 속하는 경우, IP 주소가 동일한 국가에 있더라도 해당 흐름에 플래그를 지정할 수 있습니다. 

let interactive = SigninLogs 
| where AuthenticationProtocol == "deviceCode" 
    and IsInteractive == true 
| project CorrelationId, UserPrincipalName, BrowserIP = IPAddress, 
          BrowserUA = UserAgent, TimeGenerated; 
let polling = AADNonInteractiveUserSignInLogs 
| join kind=inner interactive on CorrelationId 
| project CorrelationId, PollingIP = IPAddress, PollingUA = UserAgent; 
interactive 
| join kind=inner polling on CorrelationId 
//| where BrowserIP != PollingIP 
| project TimeGenerated, UserPrincipalName, BrowserIP, BrowserUA, 
          PollingIP, PollingUA, CorrelationId 

3. 단일 애플리케이션에서 대량의 장치 코드 생성을 모니터링합니다.

기기 코드 피싱 공격을 실행하는 공격자는 짧은 시간 내에 많은 코드를 생성합니다. 이 쿼리는 지난 24시간 동안 서로 다른 사용자 간에 비정상적으로 많은 기기 코드 흐름이 발생한 애플리케이션을 찾아냅니다. 

SigninLogs 
| where TimeGenerated > ago(24h) 
| where AuthenticationProtocol == "deviceCode" 
    or OriginalTransferMethod == "deviceCodeFlow" 
| summarize DistinctUsers = dcount(UserPrincipalName), 
            FlowCount = count() 
    by AppDisplayName, AppId 
| where DistinctUsers > 3  // adjust threshold to your environment 
| order by DistinctUsers desc

환경의 기준선에 맞게 임계값과 시간 범위를 조정하십시오. Azure CLI 또는 IoT 장치 온보딩과 같이 장치 코드 흐름을 합법적으로 사용하는 조직은 정상 작동하는 클라이언트 ID 목록을 작성하고 해당 클라이언트를 제외해야 합니다. 

의심스러운 로그 쌍이 발견되었습니다. 이제 어떻게 해야 할까요?

사용자 에이전트 불일치가 있는 모든 성공적인 디바이스 코드 플로우가 악의적인 것은 아닙니다. 개발자가 원격 서버에서 `az login`을 실행하고 자신의 노트북에서 인증하는 것과 같은 정상적인 시나리오도 존재합니다. 문제를 상위 부서로 보고하기 전에 먼저 조사하십시오. 그러나 로그 쌍에서 악용의 징후(익숙하지 않은 폴링 IP, 호스팅 제공업체 ASN, 디바이스 코드 플로우를 시작하지 않은 사용자)가 나타나는 경우, 토큰 탈취로 간주하고 다음 단계를 즉시 실행하십시오. 

1. 모든 새로 고침 토큰을 즉시 취소하십시오. 

사용자의 접근 권한을 즉시 취소하십시오(참조). 마이크로소프트의 문서해당 사용자의 계정을 비활성화하고 역할 할당을 제거합니다. 이렇게 하면 모든 활성 새로 고침 토큰이 무효화되어 공격자가 몰래 새 액세스 토큰을 획득할 수 없게 됩니다. 비밀번호를 재설정하기 전에 이 작업을 수행해야 합니다. 비밀번호 재설정만으로는 OAuth 새로 고침 토큰이 취소되지 않습니다. 

2. 활성 세션 종료 

새로 고침 토큰을 취소해도 이미 발급된 액세스 토큰은 무효화되지 않습니다. 액세스 토큰은 만료될 때까지 유효합니다. 테넌트에서 CAE(지속적 액세스 평가)를 사용하는 경우, 캐시된 토큰을 삭제하려면 사용자의 모든 활성 세션을 강제로 다시 평가해야 합니다. CAE를 사용하지 않는 워크로드의 경우, 사용자의 세션을 취소하십시오. Entra ID (사용자 → 세션 취소)를 통해 Microsoft 365 서비스 전체에 캐시된 토큰을 무효화할 수 있습니다. 

3. 지속성 메커니즘을 확인합니다. 

새로 등록된 기기, 받은 편지함 규칙, OAuth 앱 동의 및 동일 세션에서 수행된 기타 모든 작업을 주시하십시오. 특히 기기 등록(기본 새로 고침 토큰 생성), 메일을 전달, 리디렉션 또는 삭제하는 받은 편지함 규칙, 인증 방법 변경(예: MFA에 새 전화번호 추가)에 주의를 기울이십시오. 토큰 취소만으로는 충분하지 않습니다. 공격자가 이미 지속성을 확보했을 수 있으므로 사용자가 인식하지 못하는 모든 항목을 제거해야 합니다. 

4. 포함 측면 운동 

해킹당한 사용자가 권한 있는 역할(전역 관리자, Exchange 관리자 등)을 보유하거나 민감한 리소스에 대한 액세스 권한이 있는 경우, 조사가 진행되는 동안 조건부 액세스를 통해 해당 계정에 대한 액세스를 제한하십시오. 공격자가 탈취한 토큰을 사용하여 SharePoint, Teams 또는 Azure 리소스에 액세스했는지 확인하십시오. 통합 감사 로그 및 Microsoft Graph 활동 로그에서 액세스 범위를 확인할 수 있습니다. 

5. 증거를 보존하고 SOC에 알리십시오. 

관련 로그인 로그 항목(상관 ID로 연결된 대화형 및 비대화형 항목 모두), 사용자의 최근 감사 로그 활동, 그리고 삭제한 받은 편지함 규칙 또는 장치 등록 정보를 내보내십시오. 이러한 자료는 영향 범위를 파악하고 향후 사고 보고 요건을 충족하는 데 매우 중요합니다.

권장 사항 및 모범 사례

전략적 권장 사항

경영진과 보안 책임자에게 가장 중요한 정책 결정 사항입니다. 

• 명시적으로 장치 코드 인증이 필요하지 않은 모든 사용자에 대해 장치 코드 인증 흐름을 차단하십시오. 이는 조건부 액세스 정책 변경으로, 대부분의 직원에 대한 공격 가능성을 완전히 제거합니다.
• 사고 대응 플레이북을 업데이트하여 비밀번호 재설정과 함께 OAuth 토큰 폐기를 필수 단계로 포함시키세요. 비밀번호 재설정만으로는 갱신 토큰이 폐기되지 않습니다. 토큰이 명시적으로 폐기되지 않는 한 공격자는 무기한으로 접근 권한을 유지합니다.
• 임원, 재무 담당자, 관리자 등 중요 계정에는 토큰 바인딩(토큰 보호)을 우선적으로 적용하십시오. 이 기능은 일반적으로 Windows에서 사용할 수 있으며(iOS/macOS에서는 미리 보기 가능), 도난당한 기기의 코드 유출로 인한 토큰 재사용을 방지하는 가장 강력한 심층 방어 수단입니다.
• 테넌트 내에서 디바이스 코드 흐름이 활성화된 애플리케이션을 감사하세요. 많은 조직에서 의도치 않게 디바이스 코드 권한이 부여된 OAuth 앱을 사용하고 있습니다. 이러한 문제를 최소화하는 것이 빠른 해결책입니다.
• 보안 운영팀이 대화형 로그인 로그뿐만 아니라 비대화형 로그인 로그도 모니터링하고 있는지 확인하십시오. 공격자의 토큰 갱신 활동은 비대화형 로그에만 나타나는데, 많은 보안 운영 센터(SOC)에서 이러한 로그를 정기적으로 검토하지 않습니다.

전술적 권장 사항

보안 엔지니어 및 관리자를 위한 구현 수준 지침: 

조건부 액세스를 통해 장치 코드 흐름을 제한하거나 차단합니다.

조직에서 정당한 사용 사례(CLI 도구, IoT 장치, 회의실 하드웨어)에 대해 장치 코드 인증에 의존하지 않는 경우, 조건부 액세스 정책을 사용하여 해당 흐름을 완전히 차단하십시오. Entra ID모든 사용자 → 대상 리소스 → 모든 리소스(이전의 클라우드 앱) → 조건 → 인증 흐름 → 장치 코드 흐름을 '차단'으로 설정하는 정책을 생성합니다. 일부 팀에서 필요한 경우, 허용 정책을 특정 사용자 또는 그룹 및 알려진 장치 플랫폼으로만 제한하되, 기본 설정을 유지합니다. 최소 권한 원칙. 

토큰 도난을 방지하기 위한 관련 조치를 지시하십시오.

비밀번호 재설정만으로는 OAuth 새로 고침 토큰이 취소되지 않습니다. 계정 침해에 대한 대응 조치에는 다음이 포함되어야 합니다. (1) 사용자 접근 권한을 취소하고 계정을 비활성화합니다. (2) 모든 활성 CAE(지속적 접근 평가) 세션을 재평가합니다. (3) 사용자의 OAuth 앱 동의를 검토하고 알 수 없는 서비스 주체를 제거합니다. 이러한 조치를 취하지 않으면 공격자는 새로 고침 토큰이 만료될 때까지(기본값 기준 최대 90일) 접근 권한을 유지합니다. Entra ID 구성. 

지리적 이상 징후를 파악하기 위해 비대화형 로그인 로그를 모니터링합니다.

비대화형 로그인 탭 Entra ID 토큰 갱신 이벤트가 발생하는 지점입니다. 탈취한 갱신 토큰을 사용하는 공격자는 사용자의 기본 IP 주소 및 사용자 에이전트와 다른 IP 주소와 사용자 에이전트를 사용하여 비대화형 로그인을 시도합니다. 소스 IP가 사용자의 마지막 대화형 로그인과 다른 국가 또는 ASN에 있는 경우 비대화형 로그인에 대한 알림을 설정하십시오. 더 나아가 소스 IP를 위협 인텔리전스 피드 및 IP 평판 데이터베이스와 교차 참조하여 블랙리스트에 등록된 IP, 보안이 철저한 것으로 알려진 호스팅 제공업체 또는 주거용 프록시 네트워크에서 발생하는 폴링 또는 갱신 활동을 분석하면 지리적 위치에 관계없이 신뢰도가 높은 지표가 됩니다. 이러한 지리적 정보와의 조합은 공격자의 의도를 파악하는 데 매우 효과적입니다. 이상 감지 평판 기반 필터링은 기기 코드 토큰 도난을 감지하는 가장 빠르고 신뢰할 수 있는 신호입니다. 

기기 코드 피싱 공격에 대응하는 방법

디바이스 코드 피싱은 신원 위협 환경에 근본적인 변화를 가져왔습니다. 공격자는 인프라가 필요하지 않고, MFA는 우회하는 대신 악용되며, 비밀번호 재설정 후에도 접근 권한이 유지됩니다. 이 공격이 효과적인 이유는 실제 마이크로소프트 로그인 페이지, 실제 MFA 인증 프롬프트, 실제 인증 성공 화면처럼 보이기 때문입니다. 단지 토큰이 잘못된 기기로 전송될 뿐입니다. 

전략적 대응은 간단합니다. 불필요한 디바이스 코드 흐름을 차단하고, 침해사고 대응(IR) 플레이북에 토큰 폐기 절차를 포함시키며, 대부분의 조직에서 간과하는 비대화형 로그인 로그를 모니터링하는 것입니다. 이 글에서는 프로토콜 분석부터 로그 캡처, KQL 쿼리에 이르기까지 심층적인 기술 분석을 통해 보안 팀이 이러한 활동을 즉시 탐지하는 데 필요한 모든 정보를 제공합니다. 

OAuth 기반 신원 공격이 계속 진화함에 따라 기존 경계 보안 도구가 볼 수 있는 것과 신원 계층에서 발생하는 상황 간의 격차는 더욱 커질 것입니다. 프로토콜 수준의 보안에 투자하는 조직은 이러한 격차를 줄일 수 있습니다. 탐지 및 대응엔드포인트 및 네트워크 모니터링뿐만 아니라, 이러한 기술들이 공격 후 단계에 도달하기 전에 다음 진화 단계를 포착할 수 있는 주체는 바로 이들일 것입니다. 

Silverfort연구팀은 OAuth 기반 공격 기법의 진화를 지속적으로 추적하고 있습니다.