Compliant Device Bypass - 알아야 할 모든 것!

지금까지 무슨 일이 있었나?

• 2024년 12월 Yuya Chudo는 Black Hat Europe 컨퍼런스에서 “Unveiling the Power of Intune: Leveraging Intune for Breaking Into Your Cloud and On-Premise”라는 발표를 했습니다. 이 세션에서 그는 Entra ID의 문서화되지 않은 “FOCI 기능”과 결합하여 device compliance에 대한 Conditional Access(CA)의 하드코딩되고 거의 알려지지 않은 제외 항목을 악용하는 방법을 보여주었습니다. 발표에서 그는 또한 이 동작이 의도된 것이며 새 디바이스의 Intune Enrollment를 성공적으로 수행하는 데 필요하다는 Microsoft MSRC(VULN-123240)의 답변도 소개했습니다.
• 컨퍼런스 며칠 후 Sunny Chau는 함께 발행된 블로그 글과 함께 개념 증명 도구 TokenSmith를 공개했으며, 이로 인해 이 기법이 더 넓은 대상에게 알려지게 되었습니다.
• 이에 더해 PowerShell로 작성된 PoC도 공개되었습니다.
• 12월 말부터 저희 glueckkanja AG는 이 기법을 어떻게 예방하고 탐지할 수 있는지 조사해 왔습니다. 이 블로그 글에서 공격에 관한 몇 가지 인사이트를 공유하고 완화 및 탐지 방안을 논의하고자 합니다.

TL;DR

Conditional Access에는 특정 문제를 해결하기 위해 특정 Grant Controls/Conditions에 대한 내장 제외 항목이 포함된 리소스들이 있습니다. 그중 하나가 device compliance에 대한 Company Portal App의 제외로, 이는 디바이스가 compliant로 간주되기 전에 Intune에 등록되어야 하는 닭이 먼저냐 달걀이 먼저냐 문제를 해결하기 위한 것입니다. 이 동작은 여기에 문서화되어 있습니다. 즉, CA 정책이 “All resources”에 대해 Device Compliance를 강제하더라도 관리되지 않는 디바이스에서 이 앱에 대한 access token과 refresh token을 얻을 수 있다는 뜻입니다.

{: .post__screenshot}

Microsoft는 Family of Client IDs(FOCI)라는 기능을 구현했는데, 이는 Microsoft OAuth 클라이언트 애플리케이션 그룹이 자신의 refresh token을 사용하여 해당 패밀리 내 다른 클라이언트로서 access token을 획득할 수 있게 합니다. 이는 OAuth2 표준에서는 허용되지 않는 동작입니다. 자세한 내용은 Secureworks의 원본 연구를 참고하세요. Company Portal App은 “패밀리 멤버”이므로, 이를 위해 요청된 Refresh Token은 패밀리 내 다른 앱의 토큰을 얻는 데 사용될 수 있습니다.

FOCI 기능은 제한적이며, 클라이언트 id와 리소스 간의 consent는 명시적으로 구성되고 부여되어야 합니다. Company Portal App의 경우 이 consent는 특히 제한된 scope로 Microsoft Graph에 접근하는 것과 현재 사용자의 권한으로 Azure AD Graph API에 접근하는 것 등에 대해 부여되어 있습니다. 즉, Company Portal refresh token은 예를 들어 scope user_impersonation로 Azure AD Graph API access token을 얻는 데 사용될 수 있으며, 이를 통해 AADInternals나 ROADrecon 같은 도구로 많은 작업을 수행할 수 있습니다.

공격을 실행하려면 공격자는 피해자의 유효한 자격 증명과 Conditional Access가 요구할 경우 MFA를 수행할 수 있는 능력, 또는 유효한 refresh token이 필요합니다.

어떤 위험과 blast radius가 존재하는가?

compliance 제외의 영향을 받는 리소스(scope)는 무엇인가?

공격자는 앞서 설명한 대로 다른 FOCI 애플리케이션을 위한 토큰을 요청할 수 있는 옵션이 있습니다. 그러나 Microsoft는 특정 리소스 애플리케이션의 여러 API 권한 scope에 대한 토큰 접근에 대해서만 device compliance 요구사항에 대한 우회를 구현했습니다. 특히 다음의 위임된 API 권한이 민감하며 공격자에게 관심 대상입니다:

부여된 권한은 애플리케이션 자체를 위한 것이 아니므로, 그 영향은 호출자(사용자 계정)의 권한과 어떤 위임된 permission scope가 해당 scope에서 API 호출을 실행하도록 인가되었는지에 따라 달라집니다.

앞서 제시된 위임된 permission scope의 심각성과 민감한 API를 호출할 수 있는 잠재적 인가를 좀 더 자세히 살펴보겠습니다.

어떤 권한과 위임된 scope가 치명적인가?

Azure AD Graph API

이 레거시 프로그래밍 인터페이스는 Entra ID(Azure AD)의 디렉터리 설정과 객체를 관리하기 위한 많은 API를 제공합니다. 여기에는 Conditional Access 정책, 디렉터리 역할, 그룹 및 디바이스에 대한 CRUD, 그리고 암호 변경과 같은 로그인한 사용자에 대한 작업이 포함됩니다. 지원되는 모든 작업의 전체 목록은 Azure AD Graph API 레퍼런스에서 확인할 수 있습니다. 이 API는 Microsoft의 최신 발표에 따라 2025년 6월 30일에 완전히 폐기됩니다.

할당된 위임 scope “user_impersonation”은 애플리케이션(이 경우 Company Portal)이 사용자를 대신하여 행동할 수 있게 합니다. 따라서 로그인한 사용자가 Entra 객체, scope 또는 디렉터리 수준에 대해 가진 모든 권한이 API 호출의 인가로 사용될 수 있습니다. 사용자는 Entra ID 객체(애플리케이션, 그룹 또는 기타 객체)의 소유자이거나, Entra ID 역할 할당을 통해 권한을 부여받았을 수 있습니다. 활성화된 높은 권한의 역할 할당이 있는 경우, 이는 공격자가 객체를 수정하거나 테넌트를 손상시킬 수 있게 합니다. 최소한, 아무런 권한이 없더라도 기본 사용자 권한만으로도 테넌트 내 디렉터리 객체에 대한 광범위한 정찰과 열거가 가능합니다.

따라서 Azure AD Graph API를 악용하는 시나리오와 그 영향은 영향을 받은 사용자의 활성 또는 영구 할당된 권한에 따라 달라집니다. Microsoft 365 서비스에 접근하는 API(예: OneDrive 유출용)는 Azure AD Graph에 포함되지 않습니다.

Microsoft Graph API

Azure AD Graph와 비교했을 때, Microsoft Graph API에 대한 위임 scope는 특정 scope로 제한됩니다. OpenID scope(openid, email, profile) 및 사용자를 대신한 기본 읽기 작업(ServicePrincipalEndpoint.Read.All, User.Read)이 포함됩니다.

“Device.Read.All"을 사용하여 기본 권한으로 Microsoft Graph의 “device” 엔드포인트를 호출하면 모든 디바이스 객체를 나열하고 읽을 수 있습니다. 이는 공격자가 디바이스 객체에 대한 통찰을 얻는 데 도움이 될 수 있습니다.

“Intune Administrator”가 할당되었거나 Microsoft Intune RBAC에서 어떤 위임을 받은 사용자가 손상된 경우, 다음의 부여된 위임 API 권한은 문제가 될 수 있습니다:

• ”DeviceManagementConfiguration.Read.All”
• “DeviceManagementConfiguration.ReadWrite.All”

이러한 위임 권한은 예를 들어 Device Compliance 및 Configuration 정책에 대한 CRUD 작업뿐만 아니라, 대상 디바이스에서 추가적인 악의적 활동을 위한 Management Scripts 배포도 허용합니다.

Device Registration Service

이 권한을 통해 공격자는 디바이스를 Entra ID에 join하거나 등록할 수 있습니다. 이는 다시 디바이스를 Intune에 등록할 수 있게 하며, Intune 구성에 따라 더 많은 보호된 서비스에 접근할 수 있는 유효하고 compliant한 디바이스를 확보할 수 있게 합니다.

기타 FOCI 애플리케이션

예를 들어 Azure Resource Manager API와 같은 다른 권한 있는 인터페이스에 대한 접근 요청도 FOCI의 범위 안에 있으며 공격자의 관심 대상입니다. 그러나 이 리소스는 여전히 보호되어 있으며 Conditional Access grant control “compliant device”에 대해 우회되지 않습니다.

이 공격 기법을 탐지할 수 있는가?

위에서 설명했듯이 가장 큰 위험은 MS Graph와 Azure AD Graph에 대한 접근에서 비롯됩니다.

이 경우 항상 Microsoft Intune Company Portal App의 애플리케이션 ID가 사용되므로, 탐지를 만드는 주요 과제는 예를 들어 디바이스 등록과 같은 정당한 사용을 배제하는 것입니다. 저희 관찰에 따르면 정당한 사용은 세션에서 어떤 리소스에 먼저 접근하는지로 구성됩니다 → 공격의 경우 일반적으로 MS Graph 또는 Azure AD Graph입니다.

다음은 저희가 다양한 규모의 여러 환경에서 테스트한, 작동하는 탐지입니다:

의심스러운 활동을 탐지하면 어떻게 대응해야 하는가?

다음을 포함하는 정의된 플레이북을 사용하여 인시던트 대응 프로세스를 시작하세요:

• 손상된 사용자의 의심스럽거나 비정상적인 활동에 대한 헌팅
  • sessionId 기반으로 IP 주소와 UserAgent를 포함한 Resource Application에 대한 비대화형 로그인 요약
  • Microsoft Entra Audit Logs에 해당 사용자나 IP 주소에 의한 치명적인 작업(예: 소유한 앱 등록에 자격 증명 추가)이 나타나는지 확인
  • 해당 세션에서 사용자가 디바이스를 등록했는지 식별
  • 애플리케이션 “Company Portal”과 영향을 받은 사용자에 의한 작업에 대해 Intune audit log 확인
• 영향을 받은 엔터티에 관련된 경고 헌팅
  • AlertEvidence 테이블에서 엔터티를 조회하여 SessionId, IP 주소, 사용자 기반의 다른 경고 식별
• Exposure Management에서 (권한 기준으로) 사용자의 심각성 식별
• 헌팅 결과를 검토하고 해당 작업이 디바이스 등록의 일부로서 정당한 것이었는지 확인
• 초기 접근 벡터를 식별하고 사용자의 자격 증명을, 필요한 경우 디바이스를 재설정

공격을 완화할 수 있는가?

구성된 제외는 Intune 등록에 필요하기 때문에, Microsoft 365의 다른 부분을 손상시키지 않는 완화책은 없습니다. Azure AD Graph 리소스에 대한 접근은 직접 scope를 지정하거나 차단할 수 없습니다. grant control로 “Block”을 사용하는 Conditional Access 정책은 접근을 막지만 다른 영향이 있을 수 있습니다.

하지만 완화를 위해서는 이 Conditional Access 우회가 완전한 공격이 아니라는 점을 이해하는 것이 중요합니다. 이는 한 단계로서 일련의 공격을 가능하게 하는 기법입니다.

공격 경로는 다음과 같을 수 있습니다:

1. Phishing과 AiTM을 통한 계정 손상
2. Conditional Access 우회
3. 예를 들어 ROADrecon, GraphRunner 또는 AADInternals를 사용한 정찰
4. Intune에 등록된 새로 등록된 디바이스를 통한 Lateral Movement, Privilege Escalation 또는 Persistence

Intune 등록을 손상시키지 않고는 Conditional Access 우회를 완화할 수 없으므로, 공격 경로의 다른 단계에서 완화책을 구현하고 합리적인 탐지도 구현하는 것이 매우 타당합니다.

가능성과 영향을 줄이기 위해 다른 통제 수단의 강도를 높이고 다음을 조속히 구현할 것을 권장합니다:

• Conditional Access를 통해 “All Users”와 “All Cloud Apps”에 대해 MFA를 강제하세요. Device Compliance만 강제하는 경우, 이 기법에서는 Single Factor Authentication으로 충분합니다.
• 규칙 세트에서 Device Compliance 또는 MFA를 사용하지 말고, 항상 둘 다 강제하세요! OR를 사용하면 compliant 디바이스에 대한 모든 접근을 제한할 수 없는데, MFA가 scope에 포함된 access token만으로도 테넌트에 접근하기에 충분하기 때문입니다.
• Security Information Registration을 Compliant Devices, Phishing Resistant Authentication 또는 TAP로 제한하세요. 저희 테스트에서는 Security Info Registration에 대한 Device Compliance를 우회하지 못했습니다.
• 디바이스 Join 또는 Register에 대해 Phishing Resistant Authentication 또는 TAP를 요구하세요. 그렇지 않으면 예를 들어 AADInternals와 이 기법으로 디바이스를 등록하는 것이 가능합니다.
• Microsoft Intune Enrollment에 대해 MFA와 “Sign-in frequency every time”을 요구하세요. 이는 공격자가 새 디바이스를 Intune에 등록하기 위해 신선한 자격 증명을 사용할 수 있는 시간 범위를 제한합니다.

  🚧 주의: Sign-in frequency every time = 5분마다 Microsoft는 Conditional Access 정책에서 “every time”을 선택하면 사용자가 5분에 한 번보다 더 자주 프롬프트를 받지 않도록 5분의 clock skew를 고려합니다.

• Intune Enrollment 제한에서 개인 소유 디바이스를 차단하세요. 이러한 제한이 없으면 공격자가 새 디바이스를 등록하여 추가적인 발판을 확보할 수 있습니다.
• Intune에서 디바이스에 compliance 정책이 할당되지 않은 경우 device compliance가 실패하도록 설정하세요. 기본적으로 각 디바이스는 실제로 정책이 적용되지 않았더라도 compliant로 간주됩니다. 이를 변경하여 device compliance 정책을 필수 요건으로 만드세요.

장기적으로는 Windows Hello for Business와 Passkey(macOS Platform SSO를 사용하는 Platform Credentials 포함)와 같은 암호 없는 phishing 저항 인증을 배포하는 데 투자할 것을 권장합니다. 이를 통해 이후 phishing 저항 인증을 강제하고 AiTM 공격을 차단할 수 있습니다. 암호 대신, 예를 들어 새 디바이스나 직원 온보딩과 같은 제한된 시간과 시나리오에서 Temporary Access Pass(TAP)의 사용을 허용하세요. 다양한 사용 사례에서 TAP 사용을 지원하기 위해 저희는 MyWorkID를 만들었습니다.

결론

Entra ID의 Zero Trust 엔진인 Conditional Access는 그 자체로도 이미 복잡합니다. Microsoft가 Entra 백엔드에 추가한 내장 제외 항목은 많은 사람들이 정책과 보호의 영향을 이해하기를 더욱 어렵게 만듭니다. 그럼에도 Zero Trust와 심층 방어의 개념은 여전히 유효합니다.

device compliance 정책은 대부분의 AiTM 공격을 막고, multi-factor authentication은 유출되거나 다른 방식으로 손상된 자격 증명을 공격자가 악용하기 어렵게 만듭니다.

이러한 모든 보안 조치는 서로를 대체하는 것이 아니라 함께 사용되어야 합니다. 이는 방어 수단 중 하나가 변조되거나 뚫리더라도 안전한 환경을 보장합니다.

잠재적 악용을 확실히 탐지하기 위해 Microsoft Defender XDR에 제공된 탐지를 배포할 것을 강력히 권장합니다. SOC가 이러한 인시던트를 조사할 준비가 되어 있는지 확인하고 필요한 플레이북을 제공하세요.