국내 기업 엔트라이디(Entra ID) 환경에서 디바이스 코드 피싱을 의심할 때 가장 먼저 봐야 할 로그 패턴이 있다. 바로 동일한 상관관계 ID(CorrelationId)를 쓰면서 IP 주소와 사용자 에이전트가 다른 대화형, 비대화형 로그인 쌍이다. 비대화형 로그인 소스 IP가 마지막 대화형 로그인과 국가나 ASN이 다르거나, 신뢰할 수 없는 호스팅 및 프록시 네트워크에서 발생했다면 핵심 위험 지표로 간주하고 즉시 모니터링해야 한다.
디바이스 코드 피싱 작동 원리 엔트라이디 탐지 전략
디바이스 코드 플로우와 피싱 공격 구조
디바이스 코드(Device Code) 플로우는 TV, 프린터, IoT처럼 입력 장치가 부족한 환경에서 쓰는 OAuth 2.0 인증 방식이다. 사용자가 다른 기기 브라우저에서 인증을 마치면 원래 기기가 토큰을 받아 서비스를 쓰도록 설계됐다. 공격자는 이 정상 절차를 노린다. 서비스에서 디바이스 코드를 받아 회의 초대나 문서 확인 요청으로 위장해 피해자에게 보낸다. 피해자가 안내된 6자리 코드를 login.microsoft.com/devicelogin 페이지에 넣으면, 공격자는 암호 없이 유효한 액세스 토큰을 뺏을 수 있다.
엔트라이디 로그인 로그 분석: 대화형 vs 비대화형
Entra ID는 디바이스 코드 플로우가 돌아갈 때 로그 항목 두 개를 만든다. 첫 번째는 대화형 로그인(Interactive Login)인데, 피해자 브라우저 세션이 microsoft.com/devicelogin에서 코드를 승인한 활동을 담는다. 두 번째는 비대화형 로그인(Non-Interactive Login)으로, 승인 뒤 공격자의 폴링 클라이언트에 토큰이 전달되는 시점을 기록한다. AuthenticationProtocol이 deviceCode이거나 OriginalTransferMethod가 deviceCodeFlow인 이벤트를 골라내면 이 인증 흐름을 파악할 수 있다. 공격자가 반복적으로 보내는 폴링 요청(authorization_pending 응답)은 로그에 남지 않는다. 토큰 발급이 성공적으로 완료된 시점에만 로그 항목이 생긴다는 점을 기억하자.
핵심 로그 패턴과 위험 지표
디바이스 코드 피싱을 잡으려면 다음 핵심 패턴과 지표를 집중적으로 봐야 한다.
- 동일 상관관계 ID 공유 및 환경 불일치: 대화형과 비대화형 로그가 CorrelationId를 공유하지만 IP 주소와 사용자 에이전트가 완전히 다르다면 핵심 탐지 신호다. 브라우저 로그는 Mac Chrome을 쓰고 폴링 로그는
curl같은 자동화 도구를 나타낼 수 있으며, 지리적으로 이동할 수 없는 거리 차이도 의심스러운 출처를 시사한다. - 세션 ID 재사용 및 MFA 우회: 짧은 시간 안에 서로 다른 IP 주소에서 세션 ID 하나가 재사용되거나, MFA 없이 디바이스 코드 흐름이 실행됐다면 토큰 리플레이나 OAuth 피싱, 중간자 공격(AiTM)으로 본다.
- 비정상적 발생 빈도: 단일 애플리케이션에서 짧은 시간 안에 디바이스 코드 플로우가 몰리거나, 여러 사용자에게 걸쳐 대량으로 발생한다면 활성 피싱 캠페인으로 평가한다.
- 폴링 측 IP 위험도 평가: 비대화형 로그 소스 IP가 마지막 대화형 로그인과 국가·ASN이 다르거나, 블랙리스트 IP·호스팅 제공업체·주거용 프록시 네트워크에서 발생했다면 신뢰도 높은 위험 지표다. 폴링 측 IP를 위협 인텔리전스 피드, IP 평판 목록, ASN 메타데이터와 연동하면 탐지 정확도를 높인다.
탐지 후 즉각 대응 절차
이상 징후가 보이면 즉시 다음 대응 절차를 실행한다.
- 접근 권한 취소 및 계정 비활성화: 해당 사용자 접근 권한을 바로 취소하고 계정을 비활성화한 뒤 역할 할당을 제거한다.
- 활성 세션 강제 재평가: 새로 고침 토큰을 취소해도 이미 발급된 액세스 토큰은 만료될 때까지 유효하므로, 사용자의 모든 활성 세션을 강제로 다시 평가해야 한다.
- 지속성 메커니즘 점검: 새로 등록된 기기, 받은 편지함 규칙, OAuth 앱 동의 권한, 동일 세션에서 이뤄진 기타 작업을 자세히 조사한다.
- 토큰 유지 위험 인지: 디바이스 코드 피싱으로 얻은 새로 고침 토큰은 비밀번호를 바꿔도 유지될 수 있으므로, 장기적인 계정 탈취 시나리오로 가정하고 격리 조치를 취한다.
조건부 액세스와 사전 방어 정책
탐지뿐만 아니라 사전 방어를 위해 Entra ID 조건부 액세스(Conditional Access) 정책을 최적화해야 한다. Microsoft는 디바이스 코드 인증이 꼭 필요하지 않은 사용자에겐 이 인증 흐름을 조건부 액세스로 차단하라고 권장한다. 이 정책을 바꾸면 대부분 직원에 대한 공격 가능성을 원천 차단한다. 여기에 비정상 IP, 위치, 디바이스 상태 같은 위험 신호를 보면 추가 인증을 요구하는 조건부 액세스 규칙을 구성한다. 세션 재사용 탐지 및 미검증 애플리케이션의 고위험 권한 요청 제한, 관리자 승인 절차 도입도 필수다.
| 로그 구분 | 주요 기록 내용 | 탐지 시 확인해야 할 핵심 필드 |
|---|---|---|
| 대화형 로그인(Interactive) | 브라우저 세션의 코드 승인 활동 | CorrelationId, ClientAppType, IPAddress, UserAgent |
| 비대화형 로그인(Non-Interactive) | 토큰 발급 및 폴링 클라이언트 전달 | CorrelationId, ClientAppType, IPAddress, UserAgent |
| 인증 프로토콜 식별 | 디바이스 코드 플로우 사용 여부 | AuthenticationProtocol == "deviceCode", OriginalTransferMethod == "deviceCodeFlow" |
디바이스 코드 피싱은 합법적인 인증 인프라를 악용하므로 전통적인 비밀번호 스푸핑 탐지 방식으로는 식별이 쉽지 않다. 상관관계 ID 기반의 로그 쌍 분석과 지리적·네트워크 메타데이터 연동이 핵심이다. 지속적인 로그 모니터링과 조건부 액세스 정책을 수시로 수정해 M365 환경의 공격 표면(Attack Surface)을 반드시 줄여야 한다.