테넌트에 영향을 미치는 위험한 애플리케이션 권한

Microsoft는 Entra ID에서 애플리케이션을 통해 API를 노출하여 타사 애플리케이션이 Microsoft Entra ID 자체, Microsoft 365(O365), Azure 클라우드 등에서 작업을 수행하도록 허용합니다. "API 권한"은 이러한 API에 대한 액세스를 보호하며 해당 권한이 필요한 서비스 주체에게만 제공되어야 합니다. 이 권한 승인을 "애플리케이션 역할 할당" 또는 "동의 부여"라고 합니다.

일부 Microsoft API의 특정 권한(아래 참조)은 Microsoft Entra 테넌트 전체에 심각한 위협이 될 수 있습니다​. 이러한 권한을 보유한 서비스 주체는 전역 관리자와 같은 강력한 관리자 역할을 가진 사용자보다 더 강력하면서도 눈에는 덜 띄기 때문입니다. 이것을 악용하면 공격자는 다단계 인증(MFA)을 우회하고 사용자 비밀번호를 초기화해도 공격자를 차단할 수 있습니다.

이 권한이 정상적으로 부여되면 테넌트의 공격 표면이 넓어집니다. 권한이 정상적이지 않은 경우, 권한을 상승하려는 악의적인 시도이거나 지속적 방법일 수 있습니다.

Microsoft Entra ID에는 두 가지 유형의 API 권한이 있습니다(Microsoft 설명서 권한 및 동의 개요 참조).

• 애플리케이션 권한: 이 위험 노출 지표는 이 첫 번째 유형을 검사합니다.​ 환경에 중요한 데이터에 대한 위협은 관련 위험 노출 지표 "데이터에 영향을 미치는 위험한 애플리케이션 권한"을 참조하십시오. 관리자가 동의하고 권한은 테넌트 전체에 적용됩니다. Microsoft의 설명에 따르면:

애플리케이션 권한은 로그인한 사용자 없이 실행되는 앱이 사용합니다. 예를 들어 백그라운드 서비스 또는 데몬으로 실행되는 앱입니다. 애플리케이션 권한은 관리자만 동의할 수 있습니다.

• 위임된 권한: 관련 위험 노출 지표 "테넌트에 영향을 미치는 위험한 위임된 권한"을 참조하십시오.

이 위험 노출 지표(IoE)는 서비스 주체에 관해서만 보고합니다. API 권한은 사용자가 아니라 서비스 주체에만 적용되기 때문입니다.

이 IoE는 Microsoft Graph API 및 레거시 Azure AD Graph API에 대한 액세스를 허용하는 다음과 같은 위험한 권한을 추적합니다.

• AdministrativeUnit.ReadWrite.All: 공격자가RMAU(Restricted Management Administrative Unit)에서 전역 관리자를 제거한 다음, 다른 권한과 합쳐진 경우 비밀번호를 재설정하도록 허용합니다.
• Application.ReadWrite.All: 공격자가 더 많은 권한 있는 애플리케이션에 인증 자격 증명을 주입하도록 허용하여 가장을 통해 최대 전역 관리자까지 무단 액세스할 수 있게 합니다.
• Application.ReadWrite.OwnedBy: 이것은 Application.ReadWrite.All과 같지만, 보고된 서비스 주체가 소유한 서비스 주체에만 적용됩니다.
• AppRoleAssignment.ReadWrite.All: 공격자가 자신에게 RoleManagement.ReadWrite.Directory 권한을 부여하도록 허용합니다.
• DeviceManagementConfiguration.ReadWrite.All: 공격자가 악성 관리 스크립트를 배포하여 Intune에서 관리하는 장치를 침해하게 합니다. 관련 내용은 Mandiant의 Intune에서 탈취까지: Entra ID 네이티브 환경의 내부 확산 이동 및 권한 상승을 위한 Intune 권한 악용을 참조하십시오. 이렇게 하면 관리자가 Intune에서 관리하는 장치를 사용하는 경우 권한을 전역 관리자로 상승할 수 있습니다.
• DeviceManagementRBAC.ReadWrite.All: 공격자가 자신이 관리하는 계정에 권한이 있는 Intune 역할을 할당하도록 허용하여 Intune 장치에서 임의의 명령을 실행할 수 있게 합니다(DeviceManagementConfiguration.ReadWrite.All의 설명 참조).
• Directory.ReadWrite.All: 공격자가 역할을 할당할 수 없는 그룹에 자신을 멤버로 추가하도록 허용하여 Azure 클라우드에서 권한을 얻을 가능성이 있습니다. 이렇게 하면 Azure 리소스를 통해 전환할 수 있고, 그러면 Entra ID에서 전역 관리자로 권한 상승하거나(예: 관리형 ID를 통해) 심지어 Active Directory의 도메인 관리자로도 권한을 상승할 수 있습니다(예: Azure에서 호스팅되는 도메인 컨트롤러 VM을 통해).
• EntitlementManagement.ReadWrite.All: 공격자가 전역 관리자 역할을 부여하는 액세스 패키지의 할당 정책을 업데이트하여 승인 없이 역할을 요청할 수 있도록 허용합니다.
• Group.ReadWrite.All: Directory.ReadWrite.All과 같습니다.
• GroupMember.ReadWrite.All: Directory.ReadWrite.All과 같습니다.
• Organization.ReadWrite.All: 공격자가 Entra ID에 신뢰할 수 있는 루트 인증서를 추가하여 모든 사용자로(전역 관리자에 할당된 사용자 포함) 인증할 수 있도록 허용합니다. 이렇게 하려면 인증서 기반 인증(CBA)을 사용하거나, 이것이 사용 설정되어 있지 않은 경우 Policy.ReadWrite.AuthenticationMethod 권한을 사용해 미리 CBA를 사용 설정해야 합니다.
• Policy.ReadWrite.AuthenticationMethod: 공격자가 임시 액세스 패스(TAP) 인증 방법을 사용할 수 있게 합니다. 이 방법은 이 권한과 결합되었을 때 UserAuthenticationMethod.ReadWrite.All 권한을 악용하기 위한 필수 조건입니다. 또는 공격자가 이 권한을 이용하여 인증서 기반 인증(CBA)을 사용해 Organization.ReadWrite.All 권한을 악용할 수 있습니다.
• Policy.ReadWrite.PermissionGrant: 공격자가 통제된 서비스 주체에 대하여 권한 부여 정책을 만들어 RoleManagement.ReadWrite.Directory 권한을 부여하고 악용하게 합니다.
• PrivilegedAccess.ReadWrite.AzureADGroup: 공격자가 통제된 사용자 계정을 전역 관리자 역할에 할당된 그룹의 멤버로 추가하도록 허용합니다.
• PrivilegedAssignmentSchedule.ReadWrite.AzureADGroup: PrivilegedAccess.ReadWrite.AzureADGroup과 같습니다.
• PrivilegedEligibilitySchedule.ReadWrite.AzureADGroup: 공격자가 통제된 사용자 계정을 전역 관리자 역할에 할당된 그룹에 대하여 적격으로 설정한 다음 멤버십을 활성화해 권한을 상승할 수 있게 합니다.
• RoleAssignmentSchedule.ReadWrite.Directory: 공격자가 활성 PIM 역할 할당을 만들어 통제된 사용자 계정에 전역 관리자 역할을 할당하도록 합니다.
• RoleEligibilitySchedule.ReadWrite.Directory: 공격자가 통제된 사용자 계정을 전역 관리자 역할에 적격으로 설정한 다음 활성화하여 권한을 상승하도록 합니다.
• RoleManagement.ReadWrite.Directory: 공격자가 자기 자신을 전역 관리자 역할로 상승하도록 허용합니다.
• RoleManagementPolicy.ReadWrite.AzureADGroup: 공격자가 MFA 요구 사항이나 관리자 승인과 같은 그룹 역할 할당과 활성화 제한 사항을 제거하여 PrivilegedAccess.ReadWrite.AzureADGroup, PrivilegedAssignmentSchedule.ReadWrite.AzureADGroup 또는 PrivilegedEligibilitySchedule.ReadWrite.AzureADGroup을 활용한 다음 엄격한 PIM 설정이 있는 테넌트에서 그러한 권한과 같은 경로를 따를 수 있도록 합니다.
• RoleManagementPolicy.ReadWrite.Directory: 공격자가 Entra 역할 할당과 활성화 제한 사항(예: MFA 요구 사항이나 관리자 승인)을 제거하여 RoleAssignmentSchedule.ReadWrite.Directory 또는 RoleEligibilitySchedule.ReadWrite.Directory를 활용하고, 엄격한 PIM 설정이 있는 테넌트에서 그러한 권한과 같은 경로를 따를 수 있도록 합니다.
• User.DeleteRestore.All: 공격자가 테넌트의 모든 사용자 계정을 삭제하고, 계정을 사용할 수 없게 만든 다음 비상 계정 중 하나를 복원하려면 랜섬을 지불하라고 요구할 수 있도록 합니다. 이것은 전역 관리자로의 상승을 허용하지는 않지만, 액세스를 중단시킵니다.
• User.EnableDisableAccount.All: 공격자가 테넌트의 모든 사용자 계정을 사용 중지하고, 계정을 사용할 수 없게 만든 다음 비상 계정 중 하나를 복원하려면 랜섬을 지불하라고 요구할 수 있도록 합니다. 이것은 전역 관리자로의 상승을 허용하지는 않지만, 액세스를 중단시킵니다.
• User.ReadWrite.All: 공격자가 통제된 사용자 계정의 중요한 속성(예: "직원 ID" 및 "부서")을 편집하여 할당된 권한이 있는 Azure 권한을 포함한 동적 그룹(해당 IoE 참조)의 멤버로 설정할 수 있도록 합니다. 그런 다음 Azure 리소스를 활용하여 궁극적으로 전역 관리자로 상승할 수 있습니다.
• User-PasswordProfile.ReadWrite.All: Directory.ReadWrite.All과 같습니다.
• UserAuthenticationMethod.ReadWrite.All: 공격자가 임시 액세스 패스(TAP)를 만들어 테넌트의 모든 사용자 계정을 장악할 수 있도록 합니다. TAP가 이미 사용으로 설정되지 않은 경우, 이것을 Policy.ReadWrite.AuthenticationMethod와 합쳐 TAP를 해당 테넌트의 인증 방법으로 사용 설정해야 합니다(해당 IoE 참조).

이 IoE는 "Microsoft Entra AD 동기화 서비스" API의 다음 위험한 권한도 추적합니다.

• ADSynchronization.ReadWrite.All: 공격자가 문서화되지 않은 동기화 API를 호출할 수 있게 하여 하이브리드 사용자 계정을 수정하고 비밀번호를 재설정하도록 허용합니다.

정상 애플리케이션이라도 이러한 위험한 권한이 있으면 과도한 액세스를 요청할 가능성이 있습니다. 이것은 "불법적인 동의 부여"라고 알려진 피싱 공격을 시사할 수도 있습니다. 이 경우 공격자가 관리자로부터 동의를 얻는 데 성공합니다.

기본적으로 이 IoE는 사용 중지된 서비스 주체를 무시합니다. 공격자가 즉시 사용할 수 없기 때문입니다.

외부 참조:

• Andy Robbins - Azure API 권한 악용을 통한 Azure 권한 상승
• Andy Robbins - Directory.ReadWrite.All은 생각보다 강력하지 않다
• Carsten Sandker - Azure Active Directory 권한의 이해 II: 권한이 있는 액세스
• Dirk-jan Mollema - Azure AD 권한 상승 - 애플리케이션 관리자로서 기본 애플리케이션 권한 장악
• Emilien Socchi - 계층 0 권한(악용 가능성 이유 등 자세한 내용은 이 자료 참조)
• Huy Kha - 서비스 주체, 애플리케이션과 API 권한의 모든 것
• Lina Lau - Azure 애플리케이션을 백도어 공격하여 서비스 주체를 악용하는 방법
• Mandiant 레드 팀 - Intune에서 탈취까지: Entra ID 네이티브 환경의 내부 확산 이동 및 권한 상승을 위한 Intune 권한 악용
• Marius Solbakken Mellum - Entra ID에서 권한을 상승하는 의외의 방법
• Sahil Malik - 프로그래밍 방식으로 API에 관리자 동의를 부여하는 방법
• Stian A. Strysse - Microsoft Graph 앱 역할 할당에 숨겨진 위험은 무엇일까?

해당 권한을 가진 것으로 보고된 서비스 주체가 정상인지 판단하는 것​부터 시작합니다. 피싱 공격에서는 표시 이름을 스푸핑하는 것도 기술적으로 가능한 일이라는 점을 유의하시기 바랍니다. 서비스 주체가 알려진 소프트웨어 공급업체 소속인 것으로 보이는 경우, 보고된 애플리케이션 ID가 공급업체의 소속이 맞는지 확인을 요청합니다. 서비스 주체가 불법이고 알려진 애플리케이션 이름을 스푸핑하는 경우, 포렌식 분석​을 해야 합니다.

• 서비스 주체가 정상인 경우:

  • 주체의 소유자와 역할을 파악하여 이러한 위험한 권한이 필요한 것이 사실인지 평가합니다.
    • 내부 애플리케이션인 경우, Microsoft Graph API 설명서의 동의 및 권한 부여에 설명된 대로 기능을 평가하고 최소 권한 원칙을 따라 권한을 축소합니다. 이 참고 자료에는 각 API에 필요한 최소 권한이 명시되어 있습니다.
    • 타사 애플리케이션인 경우, 공급업체에 이의를 제기하여 필수 권한을 줄이거나, 적어도 그만한 권한이 필요한 이유를 문서로 기록하도록 합니다.
  • 심층 방어 수단으로, 필수 워크로드 ID 프리미엄 라이선스가 있는 경우 워크로드 ID용 조건부 액세스를 이용하는 방안도 고려할 만합니다. 이렇게 하면 고위험 주체를 신뢰할 수 있는, 알려진 위치로만 제한하고 위험한 로그인 기준으로 액세스를 제한할 수 있습니다.

• 애플리케이션 권한 은 항상 관리자 동의가 필수입니다. 이러한 관리자를 교육하여 의심스러운 애플리케이션과 중요한 권한(예: 테넌트 전체 애플리케이션 권한)을 알아볼 수 있도록 해야 합니다. 이것은 대규모 애플리케이션 거버넌스 노력의 일부분이어야 합니다.

• 불법적인 것으로 간주되는 권한은 제거하십시오. Tenable은 심층 포렌식 조사를 수행할 계획인 경우, 먼저 증거를 남겨둘 것을 권장합니다. Microsoft Entra 포털에는 엔터프라이즈 애플리케이션에 부여된 권한을 검토하는 전용 기능이 있습니다.

Microsoft에서는 2개의 가이드, 애플리케이션 동의 부여 조사를 수행하는 방법과 불법적 동의 부여를 탐지하여 수정하는 방법을 게시했습니다.

위험한 권한을 애플리케이션에서 제거하는 것이 아니라("앱 등록" 메뉴에 있음), 서비스 주체에서 제거해야 합니다(포털의 "엔터프라이즈 애플리케이션" 메뉴에 있음). 위험한 권한을 애플리케이션에서 제거하면 권한 요청만 삭제되고 실제 권한 할당에는 영향이 없습니다.

DeviceManagementConfiguration.ReadWrite.All 권한에 한해, 액세스 정책을 사용하여 여러 관리자 승인을 필수로 설정할 수 있습니다. 이 방법으로 접근하면 관리 스크립트를 만들거나 수정하려면 다른 계정의 유효성 검사를 거쳐야 하므로, 애플리케이션 하나 때문에 악성 변경 사항이 유입될 위험이 적어집니다.

마지막으로, Graph API 활동 로그를 사용으로 설정하여 Graph API 이벤트에 관한 상세한 정보를 수집하면 SOC 또는 SIEM이 의심스러운 활동을 식별하거나 공격이 발생할 때 포렌식 조사를 수행하는 데 도움이 됩니다. 이 외에, 특히 여기에 강조 표시된 고위험 서비스 주체를 위주로 서비스 주체 로그인을 모니터링하고 의심스러운 행동에 대한 알림을 구성하십시오.

이름: 테넌트에 영향을 미치는 위험한 애플리케이션 권한

코드명: DANGEROUS-APPLICATION-PERMISSIONS-AFFECTING-THE-TENANT

심각도: High

유형: Microsoft Entra ID Indicator of Exposure