Azure에서 가상화된 도메인 컨트롤러에 대한 간접 공격 경로 발견

Netwrix 보안 연구팀에서는 Entra ID 평가를 위해 고객을 지원하면서 이미 온프레미스에서 AD 계층화를 완료한 것을 알고 있었습니다. 또한 Azure에 가상화된 도메인 컨트롤러가 있다는 것도 알았지만, 어떤 Windows 서버가 실제 DC인지 파악하기 어려웠습니다. Azure Run Command가 SYSTEM 권한으로 명령을 실행할 수 있다는 점을 알아내어 이를 활용해 정찰하고 DC를 식별했습니다.

이 게시물에 표시된 모든 내용(스크린샷, 기기 이름, 사용자 이름)은 기술 시연을 위해 나중에 재구성한 실험실 환경에서 가져온 것입니다. 고객 데이터는 포함되어 있지 않습니다.

참고로, 마이크로소프트 문서에서는 Run Command를 VM 에이전트를 통해 Windows VM 내에서 PowerShell 스크립트를 실행하는 방법으로 설명하며, 주로 접근 권한이나 네트워크 문제 해결 같은 일반 관리 작업에 사용됩니다. 다만, 어떤 종류의 VM인지 확인하지는 않습니다. 도메인 컨트롤러에서도 다른 VM과 동일하게 문제없이 실행됩니다.

우리는 Claude와 함께 여러 Windows 컴퓨터에서 한 번에 명령을 실행할 수 있는 PowerShell 스크립트를 작성하기로 했습니다. Run Command 콘솔에서 VM을 하나씩 클릭하는 대신입니다. 이를 위해 필요한 권한은 Virtual Machine Contributor 이상에 포함된 Microsoft.Compute/virtualMachines/runCommand/action 권한뿐입니다.

요령은 각 Invoke-AzVMRunCommand 호출을 일반적인 Start-Job 대신 ThreadJob 내에서 실행하는 것입니다. Start-Job은 VM마다 새 PowerShell 프로세스를 생성하고 매번 Az 모듈을 다시 로드하므로, 몇 대 이상의 머신에서 빠르게 느려집니다. ThreadJob은 같은 프로세스 내의 스레드에서 실행되므로 여러 개를 동시에 실행해도 거의 추가 비용이 들지 않습니다. 발견한 모든 VM을 큐에 보관하고 한 번에 실행되는 수를 고정(기본 20)하여 유지합니다. 하나가 끝나는 즉시 빈 자리를 채우며, 전체 배치가 완료될 때까지 기다리지 않습니다.

포털을 통해 한 번에 한 대의 컴퓨터에서 whoami를 실행하는 모습은 다음과 같습니다:

이제 PowerShell 스크립트를 통해 구독 내 모든 VM에 대해 동시에 실행되는 동일한 명령입니다:

이 작업이 완료되면 다음 단계는 DC를 찾는 것이었습니다. 확인 방법은 간단합니다: 실행 명령을 통해 실행 중인 모든 Windows VM에서 Get-Service NTDS를 실행하세요. NTDS는 AD DS 데이터베이스를 실행하는 서비스이므로, 실행 중이라면 해당 머신은 도메인 컨트롤러입니다.

한 VM이 명확히 실행 중이었지만, Run Command는 응답하지 않고 오류가 발생했습니다. 반면 구독 내 다른 모든 VM은 정상적으로 응답했습니다. 이름만으로도 강력한 단서였습니다. Run Command 실패는 보안이 철저히 강화된 도메인 컨트롤러에서 예상되는 상황과 정확히 일치합니다. 이 오류를 그대로 받아들이고 넘어갔다면 구독 내 도메인 컨트롤러가 없다고 보고하는 셈이었을 것입니다.

오류를 신뢰하는 대신 AD에 직접 문의했습니다. Run Command가 여전히 접근할 수 있는 도메인에 가입된 모든 VM은 LDAP를 통해 AD를 쿼리하는 데 사용됩니다. Active Directory 모듈은 필요 없으며, 도메인에 가입된 모든 컴퓨터에서 작동하는 내장 PowerShell 타입 가속기 [adsisearcher]만 필요합니다.

이 검사는 SERVER_TRUST_ACCOUNT라는 userAccountControl 비트로 값은 8192입니다. AD는 컴퓨터가 DC로 승격된 후에만 이 값을 설정합니다. 여기에 두 가지 검사를 추가했습니다: 기본 그룹 516(“Domain Controllers” 그룹)과 구성 파티션의 일치하는 NTDS 설정 객체입니다.

한 가지는, 일치하는 호스트 이름만으로는 이 VM인지, 심지어 Azure에 있는지조차 증명하지 못합니다. 이름은 변하거나 잘리거나 때로 재사용됩니다. 그래서 먼저 IP를 확인합니다. 도메인 내부에서 DC의 호스트 이름을 IP로 해석하고, Azure가 해당 VM에 대해 보고하는 사설 IP와 비교합니다. 이 IP는 기계가 실제로 Azure에서 실행 중일 때만 존재하므로, 여기서 일치하면 매우 확실합니다. DNS가 해석되지 않으면 호스트 이름 비교로 대체하지만, 이름은 IP와 달리 변할 수 있어 신뢰도가 낮다고 봅니다.

이전에 오류가 발생한 머신이 도메인 컨트롤러임을 확실히 확인한 후, 진짜 질문은 누가 SYSTEM 권한으로 임의 명령을 실행할 수 있느냐는 것이었습니다. 이런 접근 권한은 Tier-0에 해당하기 때문입니다. 도메인 관리자 권한을 가진 사람이 아닙니다; 고객은 이미 계층 구조를 통해 이를 확인했습니다. 특정 VM에 대한 Azure 권한을 가진 사람이며, Run Command는 AD의 어떤 것도 신경 쓰지 않고 Azure RBAC만 중요시합니다.

이것이 어떻게 보이는지입니다. 몇몇 사용자가 여러 번 나타나며(역할별로 한 줄씩), 그룹 하나와 두 개의 서비스 주체가 함께 있고, 모두 체인 어딘가에 Owner 또는 Contributor 권한이 있으며, 대부분은 VM에 직접 할당된 것이 아니라 구독에서 상속된 것입니다. 이들 모두는 도메인 컨트롤러에 대해 Run Command를 호출하고 SYSTEM 권한으로 코드를 실행할 수 있습니다. 이 모든 것은 실제로 온프레미스 Domain Admins에 누가 있는지와는 관련이 없습니다.

이 시점에서 스크립트는 이 데이터를 기반으로 BloodHound 스타일의 그래프를 생성하여 어떤 보안 주체가 Azure의 가상 도메인 컨트롤러로 직접 또는 간접 경로를 가지고 있는지 시각화할지 묻습니다. 우리 실험실에서는 DC로 가는 경로가 있는 주체가 12개이며, 대부분은 VM에 직접 할당된 것이 아니라 구독에서 상속된 것입니다. 노드를 클릭하면 사이드바에서 그것이 무엇인지, 어떻게 도달했는지, 그룹 멤버십까지 자세히 보여줍니다. 따라서 "3명 멤버"라고 표시된 그룹 노드는 단순한 숫자가 아닙니다. 실제로 누가 속해 있는지 볼 수 있습니다.

추천

Azure에서 도메인 컨트롤러에 VM 리소스에 Tier-0-OnPrem-AD 같은 태그를 지정하세요. 당연해 보이지만, 우리가 살펴본 대부분 환경에서는 하지 않아 처음에 태그로 필터링하는 대신 식별하는 데 많은 노력이 필요했습니다. 태그가 지정되면 해당 태그가 있는 항목에 대해 새 소유자 또는 기여자 할당을 거부하거나 변경 시 알림을 설정하는 정책을 만들 수 있습니다.

태깅은 앞으로 무슨 일이 일어나는지 알려줄 뿐입니다. 이미 존재하는 문제를 해결하지는 않습니다. 우리가 살펴본 모든 환경은 시간이 지남에 따라 이 VM들에 권한이 누적되었으며, 대부분은 리소스 그룹이나 구독에서 상속된 것이지 직접 할당된 것은 아닙니다. 그래서 쉽게 간과되기 쉽습니다.현재 누가 접근 권한을 가지고 있는지 확인하고, 각 사용자와 서비스 주체에게 도메인 컨트롤러인 서버에서 여전히 소유자 또는 기여자 권한이 필요한지 물어보세요.

설정이 완료되면, 필터링은 티어 열을 추가하거나 필터 바에 Tier-0-OnPrem-AD를 입력하는 것뿐이며, 모든 DC가 표시됩니다. 스크립트가 필요 없습니다. 전체 열거 파이프라인이 필요했던 작업이 이제 팀 누구나 두 번의 클릭으로 필터링할 수 있습니다.

참고 문헌

1. Microsoft Learn: Azure의 Windows VM에서 실행 명령 작업을 사용하여 스크립트 실행
   https://learn.microsoft.com/en-us/azure/virtual-machines/windows/run-command
2. Microsoft Learn: 가상 머신용 Azure 인스턴스 메타데이터 서비스
   https://learn.microsoft.com/en-us/azure/virtual-machines/instance-metadata-service