디바이스 코드 피싱은 공격자가 정당한 Microsoft 인증 URI와 발급 코드를 조합해 사용자를 유도하는 방식이다. 사용자는 별도 애플리케이션 권한 동의 없이 MFA 인증만 완료하면 공격자가 Bearer 토큰을 탈취한다. OAuth 애플리케이션의 권한 승인(Consent)과 달리 작업 계정에서는 권한 동의 화면이 뜨지 않아 사용자가 무방비 상태로 인증을 진행하기 쉽다. 기업 IT 관리자와 보안 운영팀은 Microsoft 365와 Entra ID 환경에서 이 흐름을 신속히 식별하고 차단 정책으로 보완해야 한다.
디바이스 코드 플로우의 기술적 정의와 정상 사용 사례
디바이스 코드(Device Code) 플로우는 TV, 프린터, IoT 기기 등 브라우저나 키보드 입력이 제한된 환경을 위한 OAuth 2.0 인증 방식이다. 클라이언트 기기는 인증 서버에서 디바이스 코드와 사용자 코드를 받고, 사용자는 별도 기기 브라우저에서 해당 코드를 입력해 인증을 마친다. 인증이 끝나면 원래 기기가 토큰을 받아 Microsoft 365 등 서비스를 정상적으로 호출한다. 입력 인터페이스가 없는 장치의 간소화된 인증이 설계 목적이지만, 정교한 사회공학과 결합하면 디바이스 코드 피싱 위협의 핵심 벡터로 작용한다.
디바이스 코드 피싱 공격 시나리오 단계별 분석
공격자는 Token Tactics 같은 전용 도구로 디바이스 코드와 인증 URL을 만든다. 그 뒤 Teams 메시지, LinkedIn, 이메일 등 다양한 채널로 피해자에게 코드 입력을 유도한다. 사용자가 지시대로 정상적인 Microsoft 로그인 페이지에 접속해 코드를 입력하면, 시스템은 기존 인증 세션 상태에 따라 별도 로그인 화면을 보여주거나 건너뛴다. 사용자가 MFA(예: Authenticator 앱 키) 등으로 인증을 최종 승인하는 순간, 공격자 세션에는 해당 사용자의 Bearer 토큰과 부여된 권한 범위(Scope)가 즉시 발급된다. 이 토큰으로 공격자는 Microsoft Graph API를 통해 메일 조회, 파일 접근 등 해당 사용자 권한 범위에 맞는 활동을 수행한다.
사용자 동의 동작의 차이: 디바이스 코드 로그인 vs OAuth 권한 승인
많은 보안 담당자는 디바이스 코드 인증 시 OAuth 애플리케이션 권한 동의 화면이 반드시 뜬다고 오해한다. 실제 디바이스 코드 로그인 동작과 구분해야 한다. 업무 및 학교 계정 환경에서 디바이스 코드 인증은 별도의 권한 동의(Consent) 창을 항상 보여주지 않는다. 사용자가 낯선 애플리케이션의 권한 요청을 명시적으로 승인하지 않더라도, 단순히 인증 절차만 마치면 공격자에게 토큰을 넘겨주는 구조다. 사용자가 우연히 낯선 앱의 권한 요청을 추가로 승인하면 피해 범위가 커질 수 있다. 사용자 안내와 앱 동의 정책을 별도로 점검해야 한다.
Entra ID Conditional Access를 통한 디바이스 코드 플로우 차단 방법
Microsoft는 보안 강화를 위해 디바이스 코드 플로우를 최대한 차단하고, 불가피한 레거시 도구 등 문서화되어 보호된 사례에만 예외적으로 허용할 것을 권고한다. Entra 관리 센터의 조건부 액세스(Conditional Access) 정책으로 해당 인증 흐름을 차단한다.
정책 설정 단계별 검증 및 배포 절차
- Entra 관리 센터에서
Entra ID > Conditional Access > Policies > New policy경로로 새 정책을 만든다. - 대상 사용자는 원칙적으로 모든 사용자(
All users)로 설정하고, 비상 접근 계정(Exempt accounts)은 예외 목록에 넣는다. - 리소스 범위는 모든 클라우드 앱(
All cloud apps)으로 설정해 보호 대상을 최대로 넓힌다. Conditions > Authentication flows섹션에서Device code flow를 선택해 정책 적용 조건을 정한다.Grant탭에서Block access를 선택하고 정책 상태를 활성화한다.
Report-only 모드를 활용한 안전한 적용 가이드
운영 환경에 바로 Block 정책을 적용하면, Teams 디바이스나 특정 VIP 장치가 디바이스 코드 플로우에 의존해 업무 생산성에 영향을 줄 수 있다. 정책 배포 전 Report-only 모드를 먼저 적용해 잠재적 영향도를 평가해야 한다. 리포트 모드에서 생성된 세션 로그를 분석해 실제 차단 대상이 되는 정상 트래픽을 식별한 뒤, 예외 규칙을 세분화한 상태에서 운영 모드로 전환한다. 이것이 표준 배포 절차다.
| 검증 항목 | 설정 기준 | 예외 관리 포인트 |
|---|---|---|
| 대상 사용자 | 전체 사용자(All users) | 비상 계정(Exempt) 및 서비스 계정 제외 |
| 적용 리소스 | 모든 클라우드 앱 | 원칙적으로 모든 리소스 적용 권장(예외 설정 시 보호 범위 확인) |
| 인증 흐름 조건 | Device code flow 선택 | 기존 인증 방식과 혼동하지 않도록 검증 |
| 액션 정책 | Block access | Report-only 모드로 사전 영향도 분석 필수 |
정상 서비스 예외 관리 및 지속적 모니터링
조건부 액세스 정책 운영 후에도 지속적인 로그 검증이 필요하다. 보안 운영팀은 인증 실패 로그와 세션 정보를 교차 분석해 차단된 디바이스 코드 요청이 실제 피싱 행위인지 정상 레거시 호환 요청인지 구분해야 한다. 특히 Teams 디바이스나 특정 IoT 관제 시스템이 의존하던 인증 경로는 반드시 문서화한 뒤 예외 정책으로 분리 관리한다. 디바이스 코드 피싱 위협은 정식 Microsoft 도메인과 인증 URI를 활용하는 Living-off-the-land 특성 때문에 전통적인 도메인 블로킹만으로는 대응이 한계가 있다. Entra ID의 조건부 액세스와 토큰 세션 무효화 절차를 결합한 다층 방어 체계가 필수적이다. IT 관리자는 정기적인 시나리오 기반 테스트와 사용자 대상 인증 코드 입력 금지 교육으로 조직의 제로트러스트 체계를 공고히 한다.