AuthCodeFix aka ConsentFix

연말이 다가오면 으레 그렇듯, 새로운 취약점이나 교묘한 공격 벡터가 등장하고 방어자들은 사용자를 보호하기 위해 분주해집니다. 그러는 동안 다른 공격자와 레드팀은 이를 예의주시하며 자신들의 기법에 반영합니다.

올해는 PushSecurity가 “ConsentFix”라고 명명한 공격을 탐지했습니다. 이는 ClickFix 공격이 진화한 형태로, 사용자가 공격자에게 사실상 Entra 왕국의 열쇠를 넘겨주는 URI를 전달하도록 유도합니다. 실제 공격에서 사용된 방식은 사용자가 직접 복사해 붙여넣는 동작에 의존했습니다. 며칠 지나지 않아 John Hammond가 복사·붙여넣기가 더 이상 필요 없는 개선된 버전의 공격을 시연하는 영상을 공개했는데, 이 버전에서는 사용자가 인증 코드를 공격자에게 단순히 드래그 앤 드롭하기만 하면 됩니다.

이 공격이 왜 작동하며 디바이스 규정 준수 및 기타 조건부 액세스 요구 사항을 우회하는 것처럼 보이는지 기술적 세부 사항을 살펴보면, 결국 OAuth 2.0 인증 코드 흐름에 다다르게 됩니다.

공격자는 “Microsoft Azure CLI” 클라이언트와 “Azure Resource Manager” 리소스를 대상으로 하는 Microsoft Entra 로그인 URI를 생성하고, 사용자가 악성 웹사이트를 방문할 때 이 URI를 엽니다.

인증 코드 흐름에 대응해 보면, 이는 Azure CLI와 같은 네이티브 퍼블릭 앱이 사용자를 인증하기 위해 일반적으로 호출하는 첫 번째 단계에 해당합니다. 애플리케이션은 실행되는 컴퓨터에서 임의의 높은 포트로 리스너를 생성합니다. 이 포트는 이른바 회신 URI(reply URI)로 사용됩니다.

예를 들어 TokenTacticsV2를 사용하거나 URI를 직접 만들어 이를 손쉽게 직접 재현해 볼 수 있습니다.

사용자가 Entra ID에 성공적으로 로그인하면 회신 URI(예: http://localhost:3001)로 리디렉션됩니다. 정상적인 시나리오에서는 이제 Azure CLI가 이 URI로의 호출을 수신하고, 리디렉션에 포함된 중요하고 민감한 정보를 받게 됩니다.

• code
  이는 authorization_code로, 애플리케이션이 이를 사용해 액세스 토큰, ID 토큰, 그리고 선택적으로 새로 고침 토큰으로 구성된 전달자(bearer) 토큰을 요청합니다.
  문서에 따르면 이 코드는 약 10분 동안 유효하며 그 안에 사용(redeem)해야 합니다.
• state
  이는 선택적 매개변수이며, 애플리케이션은 요청과 응답에서 이 값이 동일한지 확인해야 합니다.

공격 시나리오에서도 사용자는 마찬가지로 리디렉션되지만, localhost에서 실행 중인 애플리케이션이 없기 때문에 브라우저에 오류가 발생합니다.

하지만 이 URI에는 여전히 민감한 정보가 담겨 있으며, 바로 이것이 공격자가 사용자로부터 얻고자 하는 것입니다. 사용자가 이에 응하면 공격자는 이제 토큰 자료를 사용(redeem)하고, 이어서 액세스 토큰과 새로 고침 토큰을 이용해 리소스, 이 경우에는 Azure Resource Manager에 접근할 수 있습니다.

이 스크린샷에서는 사용자가 제공한 URI를 이용해 전달자 토큰을 획득하는 방법을 확인할 수 있습니다.

탐지 기능을 테스트하려면 마지막 단계를 반드시 다른 네트워크의 다른 시스템에서 실행하십시오.

탐지 아티팩트

공격을 재현하고 SigninLogs와 AADNonInteractiveUserSignInLogs를 확인하면, 이 하나의 로그인 활동에 대해 두 개의 이벤트를 볼 수 있습니다. 첫 번째 이벤트는 실제 사용자 로그인을 나타내고, 두 번째 이벤트는 공격자의 인프라에서 비롯된 것입니다.

가장 큰 차이는 첫 번째 이벤트가 대화형(interactive) 로그인 이벤트인 반면 두 번째는 비대화형(non-interactive)이라는 점입니다. 이는 인증 흐름의 두 단계, 즉 먼저 사용자, 그다음 애플리케이션(이 경우에는 공격자)에 해당합니다.

Azure CLI의 정상적인 동작이라면 두 로그인 이벤트가 모두 동일한 IP 주소에서 발생합니다. 그러나 이 경우 IP 주소가 서로 다르고 서로 다른 국가에서 발생합니다. 물론 후자는 신뢰할 수 있는 지표가 아닙니다. 공격자가 흔적을 감추기 위해 피해자와 같은 국가에 있을 수도 있기 때문입니다.

누락된 연결 고리

이 두 이벤트를 연결할 적절한 방법을 찾을 때 가장 먼저 떠오른 자연스러운 아이디어는 고유 토큰 식별자(UTI)를 확인하는 것이었습니다. 그러나 Microsoft는 인증 코드 UTI와 전달자 토큰 UTI에 서로 다른 값을 사용하므로, 이 방식은 신뢰할 수 있는 연결 고리로 작동하지 않습니다.

그러나 SessionId는 두 이벤트 사이의 좋은 연결 고리입니다. 다만 이는 장기간 유지되는 ID이므로, 정상적인 조합을 포함해 이러한 이벤트 조합이 여러 개 들어 있을 수 있습니다.

인증 코드 흐름의 제약에 대한 추가 지식과 사용자 ID 및 애플리케이션 ID를 추가 연결 고리로 활용하면, 시간을 중요한 탐지 요소로 사용할 수 있습니다.

• 두 이벤트가 동일한 SessionId를 공유합니다
• 두 이벤트가 동일한 ApplicationId를 공유합니다
• 두 이벤트가 동일한 UserId를 공유합니다
• 두 번째 이벤트는 반드시 첫 번째 이벤트 이후에 발생해야 합니다
• 두 번째 이벤트는 첫 번째 이벤트 이후 약 10분의 시간 창 이내에 발생해야 합니다. Microsoft가 "[...] they expire after about 10 minutes"라고 명시하고 있으므로 정확히 10분을 사용해서는 안 됩니다
• 그다음에 이어지는 이벤트가 아니라, 바로 다음의 두 번째 이벤트만 고려해야 합니다

재미있는 사실
ResourceIdentity는 좋은 연결 고리가 아닙니다. 리소스는 인증 코드에 바인딩되어 있지 않아 공격자가 변경할 수 있기 때문입니다. 반면 대상 애플리케이션 ID는 변경할 수 없습니다.

노이즈 줄이기

이러한 지식만으로도 잘 작동하는 탐지를 구성할 수 있었지만, 그 안에는 정상 활동에 의한 오탐(benign positive)도 섞여 있었습니다. 요즘 개발자들은 로컬 인스턴스처럼 보이지만 로그에서는 비정상적인 로그인 패턴을 남기는 클라우드 리소스를 사용합니다.

핵심적인 차이는 시간 요소입니다. 이 공격은 사용자가 URI를 복사·붙여넣거나 드래그 앤 드롭하는 상호작용을 필요로 하는 반면, 오탐 경고의 원인으로 확인된 GitHub Codespace 사용 사례는 완전히 자동화되어 있으며 단 몇 초 이내에 인증 코드를 사용(redeem)합니다.

따라서 이 인증 과정을 몇 초 이내에 완료하는 것은 대부분 정상 활동으로 간주하여 걸러낼 수 있습니다.

또 다른 노이즈 원인은 인터넷 트래픽의 송신 지점(egress point)이 바뀌는 경우일 수 있으며, 특히 SD-WAN, ZTNA 또는 Secure Web Gateway 시나리오에서 그렇습니다.

영향을 받는 퍼스트 파티 애플리케이션

최초 보고서에서는 악용된 애플리케이션으로 “Microsoft Azure CLI”를 제시하지만, 모든 테넌트에는 사전 동의(pre-consent)가 부여되어 있고 localhost를 리디렉션으로 제공하는 다양한 Microsoft 퍼스트 파티 앱이 많이 존재합니다. 그리고 이들만 대상이 되는 것은 아닙니다. 공격자는 공개적으로 확인(resolve)되지 않는 회신 테스트·개발 URL도 악용할 수 있습니다.

다음은 리소스에 대해 높은 수준의 사전 동의 권한을 함께 가진 대표적인 애플리케이션 목록입니다.

• Microsoft Azure CLI (04b07795-8ddb-461a-bbee-02f9e1bf7b46)
• Microsoft Azure PowerShell (1950a258-227b-4e31-a9cf-717495945fc2)
• Visual Studio (04f0c124-f2bc-4f59-8241-bf6df9866bbd)
• Visual Studio Code (aebc6443-996d-45c2-90f0-388ff96faa56)
• MS Teams PowerShell Cmdlets (12128f48-ec9e-42f0-b203-ea49fb6af367)

이러한 앱의 전체 목록은 이제 동료 Fabian Bader가 EntraScopes.com에 포함해 두었습니다.

완화 및 보호 조치

공격 표면과 대상 범위 제한

옵션 1: 사용자 할당 요구

사전 요구 사항:

• Microsoft Graph API 또는 PowerShell을 사용해 영향을 받는 퍼스트 파티 앱의 서비스 주체(service principal)를 추가합니다
• Microsoft Graph API 또는 PowerShell을 사용해 서비스 주체 개체에 사용자 할당 요구 사항을 적용합니다
• 액세스 패키지(Access Packages), PIM-for-Groups(적시 액세스용), 또는 이 둘의 조합을 통해 요청 시 사용자를 할당하는 프로세스를 마련합니다.

// Example for Microsoft Graph PowerShell
Connect-MgGraph -Identity
$AppId = "04b07795-8ddb-461a-bbee-02f9e1bf7b46" // Microsoft Azure CLI
$sp = Get-MgServicePrincipal -Filter "appId eq '$AppId'"
Update-MgServicePrincipal -ServicePrincipalId $sp.Id -AppRoleAssignmentRequired:$false

이점:

• 액세스 패키지 또는 수동 그룹 멤버십을 통해 사용자 할당을 관리하여 이 공격 기법에 대한 노출을 제한할 수 있습니다.
• 적격 그룹 멤버십 할당과 결합한 적시(just-in-time) 액세스를 제공하는 옵션으로, CLI 도구에 대한 임시 액세스를 허용하여 공격 표면을 더욱 줄일 수 있습니다.
• 조건부 액세스 정책을 평가하기 전에 적용됩니다.
• 다른 시나리오의 공격 표면도 함께 제한합니다.

단점:

• 특정 사용자로만 범위를 지정할 수 있으며, 특정 디바이스 사용과 같은 다른 요구 사항과 결합할 수 없습니다
• 모든 정상 CLI 도구 사용자를 식별해야 합니다
• 이전 로그인 기록을 검토하여 부작용과 조직에 미치는 영향을 신중하게 평가해야 합니다.

옵션 2: 조건부 액세스 정책을 사용한 액세스 차단

사전 요구 사항:

• “Microsoft Graph Command Line Tools”와 “Windows Azure Service Management API”를 대상으로 지정하여, 정상 사용자를 제외한 CLI 도구 액세스를 차단하는 조건부 액세스 정책을 만듭니다
• 제외 대상은 수동으로 또는 권한 관리(예: 액세스 패키지)를 통해 그룹 멤버십으로 관리합니다.

이점:

• 정상적이지 않거나 권한이 없는 사용자에 대한 토큰 발급을 방지합니다.
• 디바이스나 네트워크와 같은 추가 조건을 기반으로 세분화된 범위 지정을 허용합니다.

단점:

• 모든 정상 CLI 도구 사용자를 식별하여 제외해야 합니다.
• 이전 로그인 기록을 검토하고 보고서 전용(report-only) 모드에서 정책을 평가하여 부작용과 조직에 미치는 영향을 신중하게 평가해야 합니다.

인증 코드 흐름에 의한 토큰 발급 차단

사전 요구 사항:

• Microsoft Entra ID P1 라이선스
• Windows 플랫폼의 Entra ID 등록 디바이스, 하이브리드 또는 Entra ID 조인 디바이스
• Azure CLI, Azure PowerShell, Microsoft Graph PowerShell에서 Web Account Manager(WAM)를 활성화합니다(최신 버전에서는 기본값)
• 다음을 대상으로 조건부 액세스를 구성합니다:
  • 다음 앱을 대상으로 하는 클라우드 앱 지정:
    • Office 365 Exchange Online
    • Office 365 SharePoint Online
    • Microsoft Teams Services
  • 모바일 앱 및 데스크톱 클라이언트 아래의 클라이언트 앱에서 토큰 보호를 요구하도록 설정합니다.
  • 정책 대상 지정을 위해 _디바이스 플랫폼_으로 _Windows_를 선택합니다

이점:

Microsoft Entra의 토큰 보호는 소유 증명(proof-of-possession, PoP)을 요구하며, 이는 클라이언트가 Windows의 Web Account Manager(WAM)와 같은 신뢰할 수 있는 토큰 브로커와 직접 통신할 때만 적용될 수 있습니다. 브라우저는 이러한 보안 채널을 설정할 수 없기 때문에, 브라우저에서 시작된 인증 코드 흐름은 토큰 보호 정책에 따라 차단됩니다.

정책이 브로커가 관리하는 PoP를 요구하는 토큰 보호를 적용하면, 브라우저로 반환된 인증 코드는 사용(redeem)될 수 없습니다. 코드를 토큰으로 교환하는 과정에서 브라우저가 요구되는 브로커 서명 증명을 생성할 수 없기 때문입니다.

이 경우, 애플리케이션이 토큰 보호로 보호될 수 있는 한 AuthCodeFix를 이용한 공격은 완전히 완화됩니다.

아래 스크린샷에서 볼 수 있듯이, 토큰 보호는 피해자가 피싱 동작을 통해 시작한 인증 코드 흐름의 사용(redemption)을 성공적으로 완화합니다.

단점:

• 공식적으로 지원되는 리소스는 다음뿐입니다:
  • Office 365 Exchange Online
  • Office 365 SharePoint Online
  • Microsoft Teams Services
    
    Microsoft Graph API는 앞서 언급한 리소스를 통해 간접적으로 포함되며 Microsoft Graph PowerShell은 지원되는 클라이언트로 명시되어 있습니다. 저희는 테스트에서 이 시나리오에 대한 공격이 완화된다는 것을 확인할 수 있었습니다. “Windows Azure Service Management API”는 지원되는 리소스로 명시되어 있지 않습니다. 두 CLI 클라이언트(Azure CLI와 Azure PowerShell) 모두 토큰 보호를 사용하기 위한 클라이언트 측 요구 사항인 WAM을 지원합니다. Microsoft는 블로그 게시물을 통해 Azure 관리 시나리오로 토큰 보호 기능을 확장하겠다고 발표했습니다.
• Microsoft Graph PowerShell의 일부 버그로 인해 WAM 통합을 일시적으로 비활성화해야 하는 경우가 있습니다
• 이전 로그인 기록을 검토하고 보고서 전용 모드에서 정책을 평가하여 부작용과 조직에 미치는 영향을 신중하게 평가해야 합니다. 클라우드 앱 대상 지정은 Microsoft 365에 대한 생산성 액세스에도 영향을 미칩니다.
• 지원되는 플랫폼과 Entra ID 통합 디바이스에서만 사용할 수 있어 적용 범위가 제한적입니다.

규정 준수 네트워크 검사 또는 신뢰할 수 있는 네트워크를 통한 추가 토큰 발급 차단

옵션: Global Secure Access로 규정 준수 네트워크 외부의 액세스 차단

사전 요구 사항:

• Entra ID P1 라이선스
• Windows, macOS, Android 및 iOS 플랫폼의 Entra ID 등록 디바이스, 하이브리드 또는 Entra ID 조인 디바이스
• 영향을 받는 모든 클라이언트의 Global Secure Access 클라이언트, 그리고 M365 트래픽 프로필에 대해 활성화된 Entra Internet Access
• 네트워크 규정 준수 검사를 적용하는 조건부 액세스 정책은 모든 클라우드 앱에 적용해야 합니다

이점:

신뢰할 수 있는 네트워크 검사를 적용하여 추가 토큰 발급을 차단합니다. 이 완화 조치는 공격자가 인증 코드 흐름에서 얻은 새로 고침 토큰을 사용해 새 토큰을 획득하지 못하도록 보장합니다. 그러나 인증 코드의 최초 사용(redemption)이나 첫 번째 액세스 토큰의 발급은 막지 못합니다. 이 토큰은 원래 피해자가 요청한 것이므로 규정 준수 네트워크 외부에서도 유효한 상태로 남습니다.

규정 준수 네트워크 조건과 함께 GSA를 적용하면 다른 토큰 재생(Token Replay) 시나리오도 차단되며, 탐지와 헌팅에 매우 유용한 추가 로그가 생성됩니다.

단점:

• Global Secure Access 클라이언트가 배포된 사용자와 디바이스에만 적용됩니다
• Entra ID 통합 디바이스에서만 사용할 수 있어 적용 범위가 제한적입니다
• CA를 통해 규정 준수 네트워크를 적용할 때는 닭이 먼저냐 달걀이 먼저냐 하는 문제를 피하기 위해 Intune과 같은 일부 제외 항목이 필요합니다. 배포 전에 상세한 테스트가 필요합니다

헌팅 쿼리

GSA 클라이언트 배포(NetworkAccessTraffic 로그 수집 포함)와 WAM 인증 활용 등 토큰 탈취 완화를 위한 모든 사전 요구 사항이 충족되면, 위협 헌팅과 검증을 위한 추가 옵션을 확보하게 됩니다.

헌팅 또는 탐지 결과 신뢰도 검증을 위한 GSA 로그와 WAM 인증 활용

이 헌팅 쿼리는 Global Secure Access(GSA)의 NetworkAccessTraffic 로그를 활용합니다. 이 로그에는 Microsoft Entra 토큰 엔드포인트와의 통신을 시작한 프로세스가 포함되어 있습니다. 이를 통해 토큰 요청이 브라우저에서 직접 발생했는지, 그리고 GSA 네트워크 외부에서 추가 토큰 요청이 있었는지를 판단할 수 있습니다.

이 쿼리는 사전 요구 사항이 충족될 때만 작동하며 신뢰할 수 있는 결과를 제공합니다. 그렇지 않으면 오탐률이 높아집니다.

이것이 중요한 이유: Windows 디바이스에서 Web Account Manager(WAM)를 사용해 CLI 또는 PowerShell 모듈을 통해 로그인하면, 해당 흐름에는 브라우저 기반 인증 코드가 관여하지 않습니다. 이 로그인 동작은 최신 버전에서 기본값입니다. 따라서 시작 프로세스가 브라우저 실행 파일(예: msedge.exe)이라면 이는 의심스러운 활동의 강력한 지표입니다. macOS에서는 플랫폼 SSO를 사용할 때 회사 포털(Company Portal) 앱(com.microsoft.CompanyPortalMac.ssoextension)이 프로세스를 시작합니다.

토큰 바인딩과 PoP: WAM 인증은 일반적으로 소유 증명(PoP)을 적용하여 토큰을 디바이스에 바인딩합니다. 공격자는 PoP 없이는 추가로 바인딩된 토큰을 발급할 수 없으므로, 바인딩되지 않은 새로 고침 토큰은 또 다른 강력한 지표입니다.

제한 사항: 언급된 모든 신호는 접근하는 디바이스가 Microsoft Entra ID에 등록되었거나 조인된 경우에만 사용할 수 있습니다.

신뢰도 점수 로직: 이 쿼리는 여러 신호를 결합하여 신뢰도 점수를 계산합니다:

• 토큰 요청을 시작하는 브라우저 프로세스의 존재 여부.
• 바인딩되지 않은 토큰으로의 다운그레이드 탐지.
• 로그인 간 네트워크 공급자 변경(규정 준수에서 비규정 준수로의 변경 포함).

이러한 신호는 쿼리에서 활동을 헌팅하거나, 앞선 탐지를 기반으로 사고 발생 시 신뢰도 점수를 도출하는 데 사용할 수 있습니다.

조건에 따라 다음과 같은 점수가 표시됩니다:

매우 높은 신뢰도 점수는 NetworkAccessTraffic 로그가 토큰 요청을 시작하는 대신 익숙한 브라우저 프로세스를 나타내고, 바인딩되지 않은 토큰으로의 다운그레이드가 탐지된 경우에 표시됩니다.

높은 신뢰도 점수는 로그인이 다른 네트워크 공급자(ASN)와 바인딩되지 않은 토큰이 관련된 비규정 준수 네트워크에서 발생한 경우에 표시됩니다.

중간 신뢰도 점수는 네트워크 공급자와 규정 준수 네트워크의 변경만 확인되고, 사용된 토큰 유형의 변경이 함께 확인된 경우에 표시됩니다.

헌팅 쿼리의 최신 버전은 GitHub에서 확인할 수 있습니다.

발급된 토큰에 의한 활동 헌팅

조사 범위를 로그인 이벤트를 넘어 공격자가 발급한 토큰을 사용해 수행된 활동까지 확장하는 것을 고려해야 합니다. 동료 Thomas Naunheim은 이러한 확장된 헌팅 과정에 도움이 되는 MicrosoftCloudActivity라는 KQL 함수를 공개했습니다. 또한 영향을 받은 SessionId를 앞선 헌팅에서 확인된 의심스러운 UniqueId 값과 연관시켜 더 깊이 분석할 수 있습니다.

이 예시에서 공격자는 공격 중에 획득한 새로 고침 토큰을 이용해 Microsoft Graph API용 액세스 토큰을 발급했습니다. 이후 이 토큰은 피해자가 소유한 애플리케이션에 클라이언트 비밀(client secret)을 추가함으로써 지속적인 액세스와 측면 이동(lateral movement)을 유지하는 데 사용되었습니다. 이 쿼리는 토큰 보호 상태와 해당 작업이 Global Secure Access 네트워크 외부에서 발생했는지 여부를 포함해 Graph API 작업에 대한 세부 정보를 제공합니다.

추가 자료

• ConsentFix: OAuth 동의 권한을 가로채는 브라우저 네이티브 ClickFix 유형 공격 분석 - PushSecurity
• 엔드포인트에서 ID로의 해킹(Microsoft 365): “ConsentFix” - YouTube
• Microsoft ID 플랫폼과 OAuth 2.0 인증 코드 흐름
• entrascpes.com의 Microsoft Azure CLI