특권 AD 사용자를 식별하고 보호하기 위한 10가지 방법

특권 계정을 손상시키는 것은 대부분의 사이버 공격에서 두 번째로 중요한 목표입니다. 공격자가 특권 액세스를 확보하면, 정보 자산을 훔치거나 암호화하거나 비즈니스 운영을 중단하는 등 최종 목표를 달성할 수 있습니다. 일반적으로 사이버 범죄자는 로컬 머신에서 낮은 권한의 계정을 손상시켜 네트워크 내 거점(발판)을 마련합니다. 이후 다양한 기술을 사용해 조직의 민감한 데이터와 시스템에 접근하는 데 필요한 더 높은 권한의 계정을 장악하려고 시도합니다. Active Directory (AD) 환경에서 진짜 목표는 도메인 관리자(Domain Administrator) 계정이지만, 경우에 따라서는 어떤 특권 계정이라도 충분한 경우가 많습니다.

권한 관리의 핵심 요소

특권 액세스 권한을 가진 공격자는AD domain을(를) 통해 거의 자유롭게 이동하며 가장 소중한 IT 리소스에 접근할 수 있습니다. 따라서 보안과 규정 준수를 유지하려면 AD 환경의 모든 특권 계정에 대해 강력한 Identity governance(신원 거버넌스) 및 access management(접근 관리)를 구축하는 것이 필수입니다.

구체적으로 시스템과 데이터의 보안을 보장하려면 두 가지 핵심 구성 요소가 필요합니다:

• 어떤 사용자가 어떤 IT 자산에 대해 어떤 권한을 보유하는지 파악
• 어떤 계정이 처음으로 특권 액세스 권한을 획득했는지 감지

privileged access management 를(을) 한 번만 수행하면 끝나는 작업으로 생각하면 안 됩니다. 사용자가 신규로 등록되고 역할이 바뀌며 IT 환경이 발전함에 따라 그룹의 권한과 구성원 자격이 변경되며, 보안 팀은 악의적이거나 기타 부적절한 변화를 감지할 수 있어야 합니다. is not a one-time endeavor. As users are onboarded and shift roles and the IT environment evolves, group entitlements and memberships change, and security teams need to spot any changes that could be malicious or otherwise improper.

다음은 권한이 있는 사용자 계정을 침해로부터 보호하는 데 사용할 수 있는 상위 10가지 방법입니다. 이 방법들은 승인되지 않은 사용자가 AD에 대한 권한 있는 액세스를 획득하지 못하도록 하기 위한 포괄적인 보안 전략의 일부입니다.

1. Domain Admins와 같은 내장 권한 그룹을 면밀히 관리하세요.

Administrators, Domain Admins, Enterprise Admins, Schema Admins 같은 기본 AD 권한 그룹은 시작하기에 가장 명확한 지점입니다. 다음 단계는 각 Windows 엔드포인트에 있는 Local Administrators 그룹으로, 해당 시스템에 대한 권한 있는 액세스를 제공합니다.

이러한 각 그룹의 구성원을 식별하는 것은 Active Directory Users & Computers (ADUC)에서 그룹의 Membership Property 탭을 확인하는 것만큼이나 쉽습니다.Get-ADGroupMember PowerShell cmdlet을 아래 스크린샷처럼 사용하는 방법도 있습니다. 여러 그룹을 빠르게 분석해야 할 때 선호되는 방법입니다.

그룹 구성원에 대한 정기적인 검토는 해당 시점의 그룹 상태에 대해서만 통찰을 제공한다는 점을 염두에 두세요. 그럼에도 불구하고, 시작하기에 좋은 출발점입니다.

2. 권한이 높은(Privileged) 그룹 안에 중첩된 그룹이 있는지 확인하세요.

중첩된 그룹이 해당 구성원에게 특권 그룹의 모든 액세스 권한을 부여하므로, 특권 그룹에 구성원으로 포함된 다른 그룹이 있는지 반드시 확인해야 합니다. 예를 들어 아래 스크린샷에서 Domain Admins 그룹의 구성원 중 하나가 LabPowerUsers라는 그룹임을 확인할 수 있습니다. 즉, LabPowerUsers 그룹의 어떤 구성원이든 도메인 전반에 대해 관리자 권한을 갖게 됩니다.

가능한 한 그룹 중첩을 피해야 하며, 특히 특권 그룹 내부에서는 더욱 그렇습니다. 공격자에게는 경보가 울릴 위험이 더 낮은 방식으로 중요 리소스와 데이터를 접근할 수 있는 방법을 제공하기 때문입니다. 공격자는 부모 특권 그룹에 직접 계정을 추가하는 대신, 자신이 제어하는 계정을 중첩 그룹에 추가합니다. 부모 특권 그룹은 더 면밀하게 모니터링될 수 있기 때문입니다.

앞에서 설명한 것처럼 Get-ADGroupMember cmdlet은 조회한 그룹의 즉시 구성원만을 표시하므로, 중첩된 그룹은 나열하지만 해당 그룹의 구성원은 표시하지 않습니다. 중첩된 그룹의 구성원도 함께 표시하려면 아래에 빨간색으로 표시된 LDAP 필터를 사용하는 방법이 있습니다:

      param([string]$groupDn )
$s = new-object system.directoryservices.directorysearcher
$s.searchroot = new-object system.directoryservices.directoryentry
$s.filter = “(&(memberOf:1.2.840.113556.1.4.1941:=$groupDn))”
$s.propertiestoload.add(“name”)
$s.propertiestoload.add(“objectclass”)
$r = $s.FindAll()
foreach ($e in $r)
{Write-Host
$e.Properties.objectclass[$e.Properties.objectclass.Count-1]:
$e.properties.name
      

이 코드를 스크립트(.GetNestedMembers.ps1)로 저장하면, 원하는 그룹의 고유 이름(Distinguished Name)을 지정하여 아래와 같이 실행할 수 있습니다:

      .GetNestedMembers.ps1 -groupDn “CN=Administrators,CN=Builtin,DC=lab,DC=local”
      

출력에는 그룹의 이름과 구성원이 나열됩니다:

      group : Domain Admins
user : bosshogg
user : azuresync
user : Barry Vista
user : Randy Smith
user : AdminService
      

스크립팅에 따르는 번거로움과 비용 없이, 상승된 권한에 대해 빠르게 가시성을 확보하기 위해 많은 조직이 Netwrix PAM solution 같은 제3자 Privileged Access Management (PAM) 도구에 투자하기로 선택합니다.

3. 조직 구성 단위(OU) 권한에 주의하세요.

사용자는 그룹 멤버십을 통해 권한을 획득하는 것 외에도 조직 단위 수준에서 제어 권한을 위임받을 수 있습니다. 아래 스크린샷은 한 그룹이 Sales OU에 대한 권한을 위임받는 모습을 보여줍니다. 해당 그룹의 모든 구성원은 Sales OU에 있는 어떤 그룹의 멤버십도 수정하는 것을 포함하여 선택된 작업을 수행할 수 있습니다.

OU 권한을 추적하는 일은 상속 때문에 복잡해집니다. NTFS 보안에서와 마찬가지로 상위 OU의 권한이 하위 OU와 리프 개체로 전파됩니다. 이로 인해 많은 사용자가 발견하기 어려운 높은 권한을 보유하게 될 수 있으며, 아래 스크린샷은 Sales OU의 모든 하위 OU와 리프 개체를 보여줍니다.

상위 OU에서 상속을 끊을 수는 있지만, 그렇게 하면 예를 들어 관리자가 자신이 책임지는 개체를 관리하지 못하는 등 문제가 발생할 수 있습니다.

디렉터리 개체에 액세스할 때마다 감사 이벤트를 생성하려면 AD Group Policy 를 사용할 수 있습니다. Computer Configuration > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Audit Policies > DS Access 를 선택한 다음 Audit Directory Service Changes 를 아래와 같이 구성합니다.

이 감사를 활성화하면 로그 항목이 방대하게 생성될 수 있으므로, 감사 로그를 수동으로 검토하는 데는 상당한 시간이 걸립니다. 또한 로그 항목에는 어떤 권한이 할당되는지가 명확히 표시되지 않으며, 특정 OU에 대한 권한을 검토해야 한다는 사실만 나타낼 뿐입니다.

4. 도메인 컨트롤러(DC)에서 관리자에 준하는 권한이 있는지 확인하세요.

도메인 컨트롤러는 Windows Server 운영 체제를 실행하고 중요한 인증 및 권한 부여 서비스를 제공하는 특수 장비입니다. 따라서 DC에서 관리자 수준의 권한을 가진 계정을 확인하는 것이 중요합니다. 예를 들어 서비스 계정에 DC에서 파일을 백업하거나 복원할 권한이 부여될 수 있습니다. 공격자는 오픈 소스 도구인 Mimikatz 를 사용해 해당 계정의 비밀번호 해시를 찾아낸 다음, 평문 비밀번호를 크래킹하여 이러한 계정을 손상시킬 수 있습니다.

다음 기준을 바탕으로 어떤 계정에 이러한 권한이 있는지 확인할 수 있습니다.

• 기본 도메인 컨트롤러 정책 검토
• PowerShell 스크립트 사용
• 예: PAM 도구를 사용하면 Netwrix PAM solutions

5. 다른 계정에 대해 암호 재설정 권한이 있는 사용자를 찾아내세요.

사용자 계정의 암호를 재설정할 수 있는 권한은 위협 행위자들이 매우 선호합니다. 계정의 암호를 재설정하면 해당 계정에 대한 통제권을 획득할 수 있기 때문입니다. 이 권한은 Full Control 권한에 포함되어 있습니다. 또한 아래와 같이 Delegation of Control 마법사를 사용해 다른 사용자의 암호를 재설정할 수 있는 특정 권한을 위임할 수도 있습니다:

아래 예에서 PC Support 그룹의 구성원은 도메인 관리자 계정의 암호를 재설정할 권한을 가지고 있습니다. 따라서 공격자가 PC support 그룹의 어떤 구성원 계정이든 손상시키면, 쉽게 도메인 전체 수준의 높은 권한을 획득할 수 있습니다.

누가 이 권한을 가지고 있는지 확인하려고 모든 OU와 사용자 개체를 수동으로 일일이 살펴보는 작업은 시간이 많이 걸리고 실수도 발생하기 쉽습니다. 또한 모든 암호 재설정 활동을 수동으로 감사하려는 시도도 마찬가지로 비현실적입니다. Netwrix AD security 제품을 사용하면 암호 재설정 권한이 있는 계정이 무엇인지 쉽게 확인할 수 있습니다. 아래 스크린샷은 prod.net 도메인의 1,000명의 사용자의 암호를 15명의 서로 다른 개인이 재설정할 수 있는 환경을 보여줍니다:

6. 권한이 높은 서비스 계정의 사용을 모니터링합니다.

이전에 소개한 팁에서는 관리자와 동등한 수준의 권한을 DC에 대해 갖는 서비스 계정을 감시할 필요가 있다고 언급했습니다. 하지만 서비스 계정과 관련된 위험은 DC에만 국한되지 않습니다. Exchange, SQL Server, 백업 솔루션, 기타 비즈니스 애플리케이션 같은 업무 부하는 종종 관리 권한을 보유한 서비스 계정에서 실행되며, 그러한 계정의 자격 증명을 아는 누구든지 악의적인 목적으로 이를 사용할 수 있습니다.

서비스 계정의 비밀번호는 정기적으로 변경되지 않거나, 아예 변경되지 않는 경우도 많아서 실제로 누가 그 비밀번호를 알고 있는지 불명확한 경우가 많습니다. 서비스 계정 비밀번호를 정기적으로 교체하더라도, 이러한 계정의 로그인 활동을 감사하여, 부여된 서비스에 대해서만 사용되고 도메인 컨트롤러에 대한 대화형 로그인 같은 불법 활동에는 사용되지 않도록 해야 합니다.

DC의 보안 로그를 사용해 서비스 계정이 부적절하게 사용되고 있는지 판단하려면, 여러 조각의 퍼즐을 맞추듯 정보를 종합해야 합니다. 예를 들어 이벤트 4768은 Kerberos 인증 티켓이 요청되었음을 보여주고, 4672는 새 로그온에 대해 특별 권한이 부여되었음을 나타내지만, 이를 이벤트 4624(계정이 성공적으로 로그온됨)와 상호 연관시켜야 합니다.

7. DC에 적용되거나, 도메인 특권 액세스가 있는 애플리케이션을 실행하는 서버에 적용되는 GPO에 대해 쓰기 권한이 있는 사용자를 파악합니다.

그룹 정책(Group Policy)은 DC, 애플리케이션 서버, Windows 엔드포인트와 같은 사용자와 시스템을 모두 관리하는 데 강력한 도구입니다. 그래서 공격자들은 이를 장악하려고 시도하며, 어떤 Group Policy 개체(GPO)에 누가 쓰기 권한을 가지고 있는지 반드시 모니터링해야 합니다.

시작점으로는 도메인 루트 또는 도메인 컨트롤러 OU에 연결된 모든 GPO의 권한을 검토하는 것이 좋습니다. 아래에 표시된 것처럼 기본 도메인 컨트롤러 정책(Default Domain Controllers policy)의 위임(Delegation) 탭을 확인하면 쉽게 수행할 수 있습니다.

8. AD 관리 솔루션에 접근할 수 있는 모든 사용자 계정을 식별합니다.

많은 조직이 AD 관리 작업을 간소화하기 위해 타사 솔루션을 사용합니다. 이러한 솔루션은 때때로, 공격자가 특권 액세스(권한 상승)를 획득하려는 경우에 공격 방법 두 가지를 가능하게 할 수 있습니다.

• 첫 번째는 솔루션의 관리 기능을 가능하게 하기 위해, AD 전체 또는 일부에 대해 특권 액세스 권한이 부여된 서비스 계정이나 프록시 계정을 사용하는 것입니다.
• 두 번째 방법은 관리 솔루션에 권한이 할당된 모든 계정을 사용합니다. 여기서 하위 권한 사용자에게 AD 계정의 일부 집합에 대해 특권 작업을 수행할 수 있는 권한이 부여될 수 있습니다(예: 다른 사용자의 비밀번호 재설정). 위임 수준에 따라, 이와 같은 계정을 장악하는 것은 Domain Admin이 되는 것과 마찬가지로 효과적일 수 있습니다.

이러한 위험을 가시화하려면 사용 중인 모든 관리 애플리케이션을 파악(인벤토리)해야 합니다. 해당 애플리케이션은 종종 도메인 컨트롤러에 상주해 있지 않다는 점에 유의하세요. 그런 다음 특권 액세스 권한이 있는 모든 서비스 및 프록시 계정을 식별하고, 이 계정들이 무엇을 수행하는지 모니터링해야 합니다. 대부분의 관리 솔루션은 부적절한 행위를 모니터링하기 위해 감사 추적(audit trail)을 설정할 수 있는 수단을 제공합니다. 이러한 애플리케이션에서 생성되는 알림은 SIEM 솔루션으로도 전달(파이프)할 수 있습니다.

또는 Netwrix Auditor 가 Windows 서버에서 하드웨어와 소프트웨어의 모든 변경 사항, 예약 작업, 애플리케이션, 네트워크 설정 등 그 밖의 내용을 자세히 정리한 일일 활동 요약을 전송할 수 있습니다. 아래는 설치된 모든 애플리케이션을 보여주는 스크린샷입니다:

9. 가상화 인프라 관리자도 잊지 마세요.

가상 AD 환경을 보호하려면 가상 인프라에 대해 특권 액세스 권한을 가진 계정이 무엇인지 알아야 합니다. DC 또는 멤버 서버를 호스팅하는 가상 환경을 관리하는 모든 사람은 물리 머신에 대한 관리자와 동등한 수준의 액세스 권한을 가진다는 점을 기억하세요.

예를 들어 Hyper-V를 실행 중인 경우, Hyper-V Administrators 로컬 그룹의 구성원은 게스트 운영 체제에서 관리자 수준의 액세스 권한을 가집니다. 마찬가지로 VMware 환경에서는 ESXi 시스템의 root 사용자도 동일한 수준의 액세스 권한을 가집니다. 또한 멤버 서버가 AD를 호스팅하지 않더라도, AD 권한을 가진 어떤 관리 애플리케이션이나 서비스 계정이든 동일한 위험을 초래합니다.

10. 관리자가 자격 증명 아티팩트를 남기지 못하도록 방지합니다.

사용자가 시스템에 로그온하면, 사용자가 로그오프한 뒤에도 자격 증명 정보의 일부가 종종 남아 있습니다. 이 정보에는 평문 비밀번호, 비밀번호 해시, NTLM 해시, Kerberos 티켓이 포함될 수 있습니다. Mimikatz 같은 도구를 사용하면 공격자는 서버와 워크스테이션의 메모리에 남아 있는 이러한 아티팩트를 쉽게 악용하여 권한 계정으로 인증할 수 있습니다. 예를 들어 평문 비밀번호는 그대로 재사용할 수 있고, 해시는 인증 요청의 일부로 전달되며, 추가 해킹 도구를 사용해 다른 시스템에 대한 액세스를 확보할 수 있습니다.

안타깝게도 어떤 머신에 특권 자격 증명 아티팩트가 있는지 식별하는 것은 거의 불가능합니다. 따라서 핵심은 특권 사용자가 어디에 로그온하고 있는지 파악하는 데 두어야 합니다.

앞서 언급했듯이, 현재 사용 중인 어떤 Windows 시스템에서든 특권이 있는 것으로 알려진 그룹에 대해 이벤트 ID 4627 (Special privileges assigned to new logon)을 모니터링할 수 있습니다. 또한 DC에서 이벤트 ID 4769 (A Kerberos service ticket was requested)를 모니터링하여 특권 로그온을 식별할 수 있습니다.

특권 계정이 어떻게 사용되고 있는지 파악한 후에는 WDigest 설정이 일반 텍스트 비밀번호가 메모리에 저장되지 않도록 해야 합니다. 또한 사용자 워크스테이션에서 특권 계정이 사용되지 못하게 하여 자격 증명을 안전하게 유지하고, 최종 사용자 문제를 해결하기 위해 Local Admin 권한이 있는 계정을 사용해야 합니다.

특권 계정을 단단히 관리하기

특권 사용자 계정은 로컬 Admin 권한이 있는 단일 머신 계정부터 전체 Domain Admin 권한이 있는 계정까지, 공격자들에 의해 정기적으로 표적이 됩니다. 침해와 서비스 중단을 방지하려면 어떤 사용자가 특권 사용자인지 파악하고, 특권 액세스에 영향을 줄 수 있는 변경 사항을 모니터링해야 합니다. 하지만 기본 제공 도구에 의존하면 평가와 모니터링이 시간이 많이 걸리고 오류가 발생하기 쉬운 프로세스가 됩니다. 특권 계정을 손상(compromise)과 오용(misuse)으로부터 보호하기 위해 필요한 신뢰할 수 있는 24/7 모니터링을 제공하려면 자동화된 제3자 도구가 필요합니다. Netwrix suite of solutions 는 privilege escalation 시도와 특권 남용을 탐지하고 차단하는 데 필요한 가시성을 제공합니다.