Active Directory 보안 모니터링의 네 가지 과제

공격자들이 자격 증명과 데이터에 침투하기 위한 새로운 전술을 끊임없이 개발하는 가운데, Active Directory (AD)에서 악의적인 활동의 징후가 있는지 모니터링하는 것이 그 어느 때보다 중요해졌습니다.

많은 조직이 도움을 받기 위해 보안 정보 및 이벤트 관리 (SIEM) 제품을 찾습니다. 하지만 이러한 솔루션은 매우 강력할 수는 있어도 결국 Windows 이벤트 로그에 의존합니다. Windows 이벤트 로그는 다루기가 복잡할 뿐 아니라, 몇 가지 핵심 AD 공격 벡터를 모니터링하는 데 필요한 정보를 제공하지 못합니다.

이 블로그에서는 Active Directory 보안을 위한 주요 과제 4가지를 살펴보고, 이를 해결하기 위해 이벤트 로그를 사용하는 데 한계가 있음을 설명합니다.

과제 1. 그룹 구성원 변경 사항 모니터링

Active Directory 보안 그룹은 사용자에게 데이터, 컴퓨터(기기), 애플리케이션 등 IT 리소스에 대한 액세스를 부여하는 가장 주요한 방법입니다. 공격자가 환경 내에서 측면 이동을 진행할수록, 종종 손상시킨 계정을 새로운 보안 그룹에 추가해 추가 권한을 얻기도 하므로 보안 그룹 구성원의 변경 사항을 추적하는 것이 매우 중요합니다.

특권 액세스를 제공하는 그룹에 대한 변경 사항을 추적하는 것은 특히 중요합니다. 여기에는 Domain Admins, Enterprise Admins, Schema Admins 같은 기본 제공 그룹뿐 아니라, 조직에서 만들어 고위 권한(상승된 액세스 권한)을 제공하는 모든 보안 그룹이 포함됩니다.

이벤트 로그가 수집하는 내용 — 그리고 그 한계

Active Directory는 이벤트 로그에서 보안 그룹에 대한 변경 사항을 추적합니다. 예를 들어 사용자가 Domain Admins 그룹에 추가되면 AD는 아래에 표시된 것과 같은 이벤트를 생성하며, 여기에는 다음과 같은 핵심 세부 정보가 포함됩니다:

• 변경을 수행한 사용자의 ID
• 변경된 개체의 DN과 클래스
• 변경 유형(이 경우에는 구성원이 추가됨)

그림 1. 보안 그룹이 수정되었음을 보여주는 예시 이벤트

하지만 이벤트 로그에는 몇 가지 중요한 한계가 있습니다:

• · 변경이 어디에서 발생했는지에 대한 기록이 없음 — 이벤트 로그는 그룹 멤버십 변경의 원본(출처)을 기록하지 않습니다. 점프 서버 또는 도메인 컨트롤러(DC)에서 Domain Admins 그룹이 변경되는 것은 정상일 수 있지만, 관리 권한이 없는 워크스테이션이나 다른 인터넷에 노출된 장비에서의 변경은 공격의 징후일 수 있습니다. 변경 원본에 대한 세부 정보가 없으면 비정상적인 위치에서 발생한 변경을 알림으로 탐지하는 것이 불가능합니다.
• · 실질적인(유효한) 그룹 멤버십을 모니터링하지 못함 — Active Directory는 그룹의 ‘직접 멤버십’ 변경만 로그로 남깁니다. 하지만 그룹은 멤버로 다른 그룹을 포함할 수 있습니다. 따라서 그룹의 멤버십 변경을 제대로 모니터링하려면, 해당 그룹 자체와 그 안에 중첩된 모든 그룹을 함께 모니터링해야 합니다.
• · 이벤트 간 불일치 — 로그에 기록되는 이벤트는 그룹이 어떤 방식으로 변경되었는지에 따라 달라집니다. 예를 들어 Active Directory Service Interfaces(ADSI)를 사용해 사용자를 그룹에 추가하면, 이벤트 로그에는 기존 그룹 멤버마다 1개의 제거 이벤트가 표시된 다음, 각 그룹 멤버를 다시 추가하는 이벤트 1개씩이 이어지고, 마지막으로 새 사용자를 추가하는 이벤트가 표시됩니다. 따라서 멤버가 50명인 그룹에 사용자를 추가하면 101개의 이벤트 로그 항목이 생성됩니다. 또한 변경이 LDAP을 사용해 수행된 경우 개체의 distinguished name 대신 GUID가 나열될 수 있습니다. 이러한 불일치는 SIEM 제품에서 혼란과 잘못된 정보로 이어질 수 있으며, 수집된 데이터에 대해 효과적으로 동작하는 규칙을 만들기가 극도로 어렵게 만듭니다.

과제 2. 그룹 정책(Group Policy) 변경 사항 모니터링

그룹 정책(Group Policy) 설정은 Active Directory 도메인 전반의 사용자와 컴퓨터에 영향을 미치며, 예를 들어 시스템에 대한 관리 권한이 있는 사용자가 누구인지가 포함됩니다. 그룹 정책 개체(Group Policy object) (GPO) 하나의 변경만으로도 심각한 보안 영향이 발생하거나 운영 환경의 장애(가동 중단)가 유발될 수 있으므로, 이러한 변경 사항을 모니터링하는 것은 매우 중요합니다.

이벤트 로그가 포착하는 내용 — 그리고 그 한계

그룹 정책(Group Policy)이 변경되면 그림 2에 표시된 것과 같은 이벤트가 기록됩니다. 이 이벤트는 변경을 누가 수행했는지, 그리고 GPO의 식별자(Identifier)와 같은 유용한 정보를 제공합니다.

그림 2. 그룹 정책(Group Policy) 변경에 대해 기록된 이벤트

하지만 이러한 이벤트에는 다음과 같은 중요한 정보가 누락되어 있습니다:

• · 무엇의 설정이 변경되었는지와 변경 전·후 값에 대한 세부 정보 — GPO는 기본 제공 및 사용자 지정 설정 수백 가지를 지원합니다. 변경으로 인해 사용자용 기본 브라우저 홈페이지가 수정되거나, 중요 장치에 대한 관리 권한을 모든 사용자에게 제공할 수도 있습니다. 그러나 이벤트 로그에는 변경된 설정과 변경 후 내용이 제대로 기록되지 않습니다.
• · 변경의 원천(출처) — 보안 그룹의 변경과 마찬가지로, 그룹 정책(Group Policy) 변경을 기록하는 이벤트는 변경이 어디에서 발생했는지(어떤 경로에서 왔는지) 정보를 제공하지 않습니다. 대부분의 GPO 변경은 소수의 위치에서만 발생해야 하며, 비정상적인 위치에서 발생한 변경을 식별할 수 있어야 공격을 신속하게 탐지할 수 있습니다.

과제 3. 디렉터리 읽기 모니터링

Active Directory를 안전하게 보호하기 위한 또 하나의 핵심 작업은 사용자 계정이 AD 객체를 어떻게 읽고 나열(열거)하는지 모니터링하는 것입니다. 네트워크에 침투하기 위한 발판을 마련하려는 공격자는 흔히 중요 계정, 그룹, 서버를 열거하여 권한 상승으로 이어지고 궁극적으로는 민감한 데이터로 연결되는 공격 경로를 파악합니다. 의심스러운 읽기 이벤트를 모니터링하면 이러한 정찰 활동을 탐지하고, 너무 늦기 전에 공격을 중단할 수 있습니다.

이벤트 로그가 수집하는 내용 — 그리고 그 한계

누가 Active Directory를 탐색하는지 확인할 수 있도록, 이벤트 로그는 읽기 활동을 캡처합니다. 이 이벤트는 사용자 계정, 읽히는 개체, 수행 중인 작업 유형에 대한 세부 정보를 Figure 3과 같이 보여줍니다:

그림 3. Domain Admins의 속성이 읽힌 것을 보여주는 이벤트

하지만 이러한 이벤트를 사용해 의심스러운 활동을 감시하려고 하면 여러 가지 단점이 있습니다:

• 너무 많은 노이즈 — 읽기 이벤트를 로깅하면 이벤트 로그에 노이즈가 너무 많이 쌓여 가치 있는 정보를 찾기가 거의 불가능해집니다. 실제로 사용자가 그룹을 확인하는 한 번의 사례만으로도 로그에 수십 개, 심지어 수백 개의 이벤트가 생성될 수 있으며, 이 때문에 정상적인 이벤트가 대부분인 상황에서 의심스러운 활동을 찾아내기가 거의 불가능합니다.
• 읽기가 발생한 출처에 대한 기록이 없음 — 또한 읽기 이벤트가 어디에서 시작되었는지 알 방법이 없습니다. 보안 그룹과 GPO의 변경에서 확인했듯이, 읽기 이벤트가 어떤 컴퓨터에서 발생했는지를 아는 것은 해당 행위가 단순한 무해한 읽기인지, 또는 정찰 목적의 악의적인 행위인지 판단하는 데 결정적으로 중요한 정보입니다.
• 액세스 거부 이벤트가 너무 많음 — 또한 볼 권한이 없는 정보를 보려는 시도를 하는 사용자를 찾아내는 것도 매우 중요합니다. 예를 들어 Active Directory는 컴퓨터 특성에 관리 계정의 평문 비밀번호를 저장할 수 있으므로, 이러한 특성을 읽으려는 사용자 계정은 특권 자격 증명을 손상시키려는 시도일 수 있습니다. 하지만 안타깝게도 어떤 계정이든 어떤 목적이든 객체를 보기만 하면, 의도적으로 해당 특성을 읽지 않았더라도 읽을 권한이 없는 모든 특성에 대해 액세스 실패 이벤트가 생성됩니다. 무고한 이벤트의 바다 속에서 정말로 의심스러운 실패 액세스 이벤트를 찾아내려는 것은 실행 가능한 전략이 아닙니다.
• LDAP 쿼리를 손쉽게 모니터링할 방법이 없음 — LDAP 쿼리는 사용자, 그룹, 컴퓨터를 찾아내기 위해 Active Directory를 탐색하는 데 흔히 사용됩니다. 하지만 안타깝게도 Microsoft는 발행된 쿼리와 그 쿼리가 어디에서 왔는지 확인할 수 있도록 LDAP 쿼리를 쉽게 모니터링하는 방법을 제공하지 않습니다. 이러한 문제 때문에 진단 수준의 LDAP 모니터링을 켜더라도 얻는 가치가 크지 않습니다. 실제로 Microsoft에서는 이벤트 로그에 엄청난 양의 노이즈가 발생하므로 이를 권장하지 않습니다.

과제 4. 인증 이벤트 추적

최근 자격 증명 기반 공격이 급증하면서, 인증 패턴을 모니터링하는 것은 손상된 계정을 식별하고 pass-the-hash 및 pass-the-ticket attacks, forged Kerberos tickets 또는 권한을 획득하고 민감한 데이터에 접근하는 데 사용되는 다른 익스플로잇의 징후를 파악하는 데 매우 중요합니다.

이벤트 로그가 기록하는 내용 — 그리고 한계

Active Directory는 도메인 컨트롤러, 멤버 서버 및 워크스테이션에서 사용자 로그온 및 인증 활동을 모니터링하기 위해 이벤트를 캡처하며, 다음 표에 나열된 항목을 포함합니다:

이러한 이벤트는 유용한 정보를 일부 제공하지만, 다음과 같은 한계 때문에 인증 기반 공격을 효과적으로 식별할 수 있는 방법을 제공하지는 못합니다:

• 너무 많은 노이즈 — 사용자가 어떤 컴퓨터에든 로그인할 때마다 이벤트가 생성되며, 이는 일반적으로 엄청난 양의 활동입니다. 그 밖에도 많은 이벤트가 내부적으로 생성됩니다. 예를 들어 사용자가 AD 도메인에 조인된 멤버 서버에 로그인하면, 서버가 그룹 정책 정보를 가져오기 위해 DC에 연결을 시작하고, 그 결과 DC의 이벤트 로그에 로그온/로그오프 이벤트가 나타납니다. 도메인 컨트롤러에 대한 중요한 로그인 활동을 무시하지 않고서는 일반 사용자 로그인 활동의 로깅을 비활성화할 방법이 없습니다.
• DC에서 로그온 유형에 대한 기록이 없음 — DC의 로그온 이벤트에 대해 로그온 유형을 추적하지 않습니다. 이는 계정이 적절한 방식으로 사용되고 있는지 판단하는 데 매우 귀중한 맥락입니다. 예를 들어 원격 데스크톱을 통해 로그인한 사용자와 매핑된 네트워크 드라이브를 통한 네트워크 로그인을 쉽게 구분할 방법이 없습니다. 따라서 모든 멤버 서버에서 로그를 수집하고 이를 DC의 로그와 상호 연관시키려는 작업이 필요합니다.
• 프로토콜별 세부 정보 부족 — 이벤트에는 그 밖의 유용한 정보도 누락되어 있습니다. 예를 들어 Kerberos 인증 이벤트는 티켓 수명 및 갱신 수명 타임스탬프를 기록하지 않는데, 이는 Golden Ticket exploit에 사용된 위조 티켓을 판단하는 데 유용한 지표입니다. 마찬가지로 NTLM 로그는 사용된 NTLM 버전을 지정하지 않으며, 이 정보는 더 안전한 프로토콜을 우선하기 위해 기존의 오래된 NTLM 버전을 비활성화할 수 있는지 여부를 판단하는 데 가치가 있습니다.

Netwrix가 도와드릴 수 있는 방법

앞서 살펴본 것처럼 이벤트 로그만으로는 공격을 신속하게 탐지하고 효과적으로 대응하기에 부족합니다. 종단 간 보호를 위해 Netwrix Active Directory security solution을 고려해 보세요. 이를 통해 다음을 수행할 수 있습니다:

• 심층적인 위험 평가를 통해 보안 취약 지점을 선제적으로 파악하세요.
• 비용이 많이 드는 중단 시간과 업무 중단을 최소화하세요.
• 가장 고도화된 위협도 제때 신속히 포착하고 빠르게 대응하세요.