서버 (비)신뢰 계정

userAccountControl 조작을 통한 Active Directory 지속성

최근 그룹 Managed Service Accounts (gMSA, gMSAs)에 대해 조사를 해오고, 정보를 얻기 위해 MS-SAMR 프로토콜 명세서를 읽고 있었습니다. 그러다 우연히 userAccountControl 섹션에서 흥미로운 정보를 발견했고, 그걸 테스트하느라 하던 일을 멈추게 되었습니다:

본질적으로 UF_SERVER_TRUST_ACCOUNT 비트가 컴퓨터 개체의 userAccountControl 속성에 설정되면, 그다음 Active Directory는 동일한 개체의 primaryGroupId를 Domain Controllers 그룹의 RID로 설정해야 합니다. 따라서 단순히 userAccountControl 값을 변경하는 것만으로도 컴퓨터 개체에 도메인 컨트롤러의 권한을 부여할 수 있습니다.

행동(동작) 확인

저희는 연구실에서 Domain Admin 계정을 사용해 테스트를 시작했고, 먼저 도메인 컨트롤러에 대한 기본 userAccountControl 값인 0x82000(10진수 532480)을 사용해 보았습니다. 이 값은 SERVER_TRUST_ACCOUNT(0x2000, 10진수 8192)와 TRUSTED_FOR_DELEGATION(0x80000, 10진수 524288) 비트 플래그의 합입니다.

userAccountControl 값을 변경한 후, primaryGroupId 가 516(도메인 컨트롤러 그룹의 RID)으로 업데이트되는 것을 확인했으며, 정말 좋은 출발입니다! 다음으로는 SERVER_TRUST_ACCOUNT 비트만 필요한지 알아보기 위해, 다시 userAccountControl 속성을 8192로 설정해 시도했습니다.

따라서 우리는 프로토콜 명세의 정확성을 확인했으며, primaryGroupId 를 변경하게 하는 것은 오직 SERVER_TRUST_ACCOUNT 비트뿐임을 확인했습니다.

필요한 권한 조사

우리는 악용 가능한 잠재적 경로를 고려하기 시작합니다. userAccountControl 속성을 수정하는 능력만 필요하다면, 흥미로운 권한 상승 기법일 수 있습니다. 우리는 userAccountControl 속성을 수정할 수 있는 권한만 가진 권한이 없는 계정으로 테스트를 시작했지만, 곧바로 액세스 거부 오류에 직면했습니다.

알고 보니 MS-SAMR 문서에서 몇 줄만 더 읽었어야 했습니다. userAccountControl 속성의 5절에서는 특정 userAccountControl 비트를 설정하는 데 필요한 추가 권한을 설명합니다. userAccountControl 의 UF_SERVER_TRUST_ACCOUNT 비트를 설정하려면 행위자에게 도메인 개체에 대해 DS-Install-Replica ("도메인에서 복제본 추가/제거") 권한이 부여되어 있어야 합니다.

우리는 권한이 없는 사용자에게 이 권한을 부여한 뒤 테스트를 다시 시도했습니다.

권한이 없는 사용자에게 컴퓨터에 대한 쓰기 userAccountControl 권한과 도메인 개체에 대한 DS-Install-Replica 권한을 부여한 후, 테스트는 성공했습니다.

기본적으로 DS-Install-Replica 권한은 “Domain Admins” 및 “Enterprise Admins” 그룹에 부여됩니다. 따라서 설정이 제대로 되어 있지 않은 환경을 제외하면, 이 방식은 권한 상승(Privilege Escalation) 벡터를 의미하지는 않습니다. 하지만 필요한 권한이 제한적이기 때문에, 우리는 도메인 지속성(domain persistence)을 위한 애플리케이션(용도)에 대해 생각하기 시작했습니다.

도메인 지속성을 위한 용도(애플리케이션)

이것이 지속성(persistence)을 위한 흥미로운 방법인지 평가하면서, 우리는 몇 가지 요소를 고려했습니다. 즉, 제한된 범위의 권한만 필요하다는 점, 이러한 권한이 일반적으로 검토되지 않는다는 점, (objectClass=computer) 계정은 만들기 쉽다는 점, 컴퓨터는 자주 검토되지 않는다는 점(많은 조직이 오래된 컴퓨터 개체로 어려움을 겪습니다), 그리고 이 메커니즘을 악용하기가 쉽고 흔적이 오래가지 않는다는 점입니다.

이 메커니즘을 구성하려면 몇 가지 간단한 단계만 필요합니다:

1. 가짜 컴퓨터, MSA 또는 gMSA 계정을 생성합니다. 기존 계정을 사용할 수도 있지만, 지속성 메커니즘의 효과는 비밀번호 변경 주기에 의해 제한됩니다. 다만, 이미 존재하지만 오래된(더 이상 사용되지 않는) 컴퓨터 계정은 매력적인 대상이 될 수 있습니다.
2. 손상된 일반 사용자, 그룹, 또는 잘 알려진 엔터티에 “Add/remove replica in domain” 권한을 부여합니다. 우리는 공격자가 어떤 일반 사용자 계정이라도 손상시킨 뒤 도메인 지배력을 다시 확보할 수 있도록 “Authenticated Users”를 사용했습니다.
3. 컴퓨터 개체에 대해 “Write userAccountControl” 권한을 위 단계와 동일한 엔터티에 부여합니다.

알려진 암호로 컴퓨터 계정 만들기

당연해 보이지만, 모두가 알려진 암호로 컴퓨터 계정을 만들 수 있다는 기능을 반드시 알고 있는 것은 아닙니다. 예를 들어 New-ADComputer 또는 New-ADServiceAccount cmdlet을 사용합니다:

New-ADComputer “ComputerName” -AccountPassword (ConvertTo-SecureString -AsPlainText -Force “Password”)

평문 비밀번호를 아는 것은 몇 가지 이유에서 유리합니다. 가장 중요한 점은 ConvertTo-NTHash 및 ConvertTo-KerberosKey cmdlet을 사용해 Michael Grafnetter의 DSInternals PowerShell 모듈로 NTLM, AES-128, AES-256 해시를 계산할 수 있다는 것입니다. 공격자가 백도어를 악용하기로 선택하면, 해당 권한을 사용하려고 컴퓨터 계정으로 인증해야 하며 이는 overpass-the-hash 기법으로 수행됩니다. NTLM과 AES 해시를 지정하면 대부분의 overpass-the-hash 탐지를 회피할 수 있습니다.

도메인 지배력 되찾기

계정과 권한을 준비한 후, 공격자가 관리자 자격 증명에 대한 접근을 잃거나 네트워크에서 퇴출당하더라도, 도메인 지배력을 다시 확보하려면 일반 사용자 중 아무나 한 명을 손상시키기만 하면 됩니다.

어떤 사용자 계정이든 공격자는 준비해 둔 컴퓨터의 userAccountControl 속성을 0x2000(8192)으로 수정하기만 하면 됩니다. 이 수정은 또한 causes 즉각적인 복제를 발생시키므로, 공격자는 특정 도메인 컨트롤러를 표적으로 삼을 필요가 없습니다. userAccountControl 구성이 완료되면, 공격자는 도메인 컨트롤러 권한을 사용해 도메인을 손상시킬 수 있습니다.

예를 들어 공격자는 컴퓨터 계정을 사용해 DCSync 를 수행하고 krbtgt 비밀번호 해시를 손상시킬 수 있습니다. 복제가 도메인 컨트롤러에서 온 것처럼 보이기 때문에 대부분의 DCSync 위협 탐지는 이 활동을 탐지하지 못합니다. 공격자가 krbtgt 시크릿을 복제하면, 단순히 userAccountControl 를 다시 0x1000(4096)으로 되돌리면 컴퓨터 계정은 일반 컴퓨터 계정처럼 보이게 됩니다.

기법 자동화

이 방법의 잠재적 효과를 보여드리기 위해, 저는 GitHub에서 사용할 수 있는 두 가지 새 PowerShell 함수를 만들었습니다.

첫 번째 함수인 Add-ServerUntrustAccount 는 세 가지 설정 단계를 자동화합니다. 즉, 알려진 비밀번호로 가짜 컴퓨터 계정을 생성하고 “Authenticated Users”에 “Add/remove replica in domain” 및 “Write userAccountControl” 권한을 부여합니다.

두 번째 함수 Invoke-ServerUntrustAccount 는 백도어의 악용을 자동화하며, 권한이 없는 사용자(비특권 사용자)로 실행하도록 의도되었습니다. 이 함수는 userAccountControl 속성을 0x2000(8192)으로 설정한 다음, pass-the-hash를 사용해 가짜 컴퓨터 계정으로 인증하고, krbtgt 해시의 DCSync를 수행한 뒤, 마지막으로 userAccountControl 을 다시 0x1000(4096)으로 설정합니다.

메커니즘(수단) 탐지 및 악용 탐지

이와 기타 유사한 메커니즘을 찾아내기 위해, 조직에서는 민감한 Active Directory 권한을 정기적으로 감사(auditing)해야 합니다. 또한 “Add/remove replica in domain”과 같은 민감한 권한 변경 사항을 실시간으로 모니터링(또는 차단)하는 것도 유익합니다. 저희는 널리 사용되는 여러 오픈 소스 Active Directory 권한 감사 도구를 테스트했으며, AD ACL Scanner 가 공격자의 권한을 문제가 있는 것으로 정확하게 식별해 냈습니다.

Active Directory 이벤트 로그, 즉 이벤트 ID 5136 및 4662 는 ACL 변경 사항에 대한 기본적인 실시간 모니터링을 제공하며, 도메인 수준의 “Add/remove replica in domain” 권한을 탐지하는 데 사용할 수 있습니다. 다만 이러한 이벤트를 분석하는 과정은 간단하지 않습니다.

또한 사용되지 않아 오래된(stale) 컴퓨터 계정(및 MSA, gMSA 계정)을 찾아 제거하고, 네트워크의 실제 머신과 일치하지 않는 계정을 정리하는 것도 중요합니다. 예를 들어 PowerShell로 오래되었거나 사용되지 않는 컴퓨터 계정을 빠르게 찾을 수 있습니다(“-90”을 도메인의 최대 컴퓨터 계정 보관 기간으로 교체):

$Date = [DateTime]::Today.AddDays(-90); Get-ADComputer -Filter ‘(Enabled -eq $true) -and (PasswordLastSet -le $Date)’ | Select Name

악용 징후 탐지

이 기법을 적대자가 사용하는 것을 탐지하는 핵심은 userAccountControl 특성(attribute)의 변경 사항을 모니터링하는 데 있습니다. 이벤트 ID 4742 – Computer Account Management 를 사용하면 userAccountControl 값의 변경을 추적할 수 있습니다. userAccountControl 에서 비트 0x2000이 설정된 상태로, 예상되는 도메인 컨트롤러 승격(promotion) 밖에서 변경이 발생하는 것은 우려스러운 신호입니다.

정리

이러한 유형의 기법은 분명 치명적인 취약점만큼 심각하지는 않지만, 기업 환경에서는 자주 탐지되지 않으며 사고 대응 담당자의 업무를 더욱 어렵게 만들 수 있습니다. 우리가 테스트한 Active Directory 감사 도구에서 탐지율이 낮았다는 점을 고려할 때, 이는 쉽게 간과될 수 있는 덜 알려진 동작을 악용하는 흥미로운 기법이라고 생각합니다. 여러분의 의견과 질문을 환영하며, 특정 공격이 어떻게 작동하는지 더 알아볼 수 있는 Attack Catalog 로 안내하지 않는다면 책임을 다하지 못한 것이라 여깁니다.