NOTLogon: 권한이 낮은 컴퓨터가 도메인에 DoS를 가하는 방법

Silverfort 발견하다 Active Directory NOTLogon(CVE-2025-47978)으로 알려진 서비스 거부(DoS) 취약점
Silverfort 영상
Windows Kerberos DoS 블로그 타일

개요

The Silverfort 보안 연구팀은 모든 Windows 도메인 컨트롤러가 사용하는 핵심 구성 요소인 Microsoft Netlogon 프로토콜에서 서비스 거부(DoS) 취약점을 발견했습니다. 이 취약점은 NOTLogon으로 명명되었으며, Microsoft는 Windows Kerberos 서비스 거부 취약점, 허용 최소한의 권한이 있는 도메인에 가입된 모든 머신 도메인 컨트롤러를 충돌시키고 전체 재부팅을 유발하는 특수하게 조작된 인증 요청을 보냅니다.

이 취약점은 높은 권한을 요구하지 않습니다. 표준 네트워크 접근 권한과 취약한 컴퓨터 계정만 있으면 됩니다. 일반적인 기업 환경에서는 권한이 낮은 사용자라면 누구나 기본적으로 이러한 계정을 생성할 수 있습니다.

이 충돌은 Windows의 핵심 보안 프로세스인 LSASS에 영향을 미치고 광범위한 중단을 초래합니다. Active Directory 서비스사용자 로그인, 정책 적용, 인증 종속 리소스 등이 포함됩니다. Microsoft는 이 취약점에 CVE 등급 6.5를 부여했으며, 2025년 47978월 8일 패치 화요일의 일환으로 CVE-2025-XNUMX에 대한 수정 사항을 발표했습니다. 모든 도메인 컨트롤러에 이 업데이트를 즉시 배포하고 서비스 및 컴퓨터 계정에 대한 액세스 제어를 강화할 것을 강력히 권장합니다.

AI를 통한 취약점 발견

보안 연구원이 가장 먼저 고려해야 할 가장 어려운 질문 중 하나는 취약점을 발견할 가능성이 가장 높은 곳이 어디인가입니다. 연구원들은 방대한 양의 데이터, 코드, 문서를 면밀히 검토한 후, 더 깊이 조사할 적절한 부분을 선택합니다. 프로세스 속도를 높이고 AI의 한계를 시험하기 위해, 저희는 LLM을 사용하여 이전 릴리스 노트와 새 릴리스 노트를 비교하여 잠재적인 결함을 파악했습니다. 이러한 접근 방식을 통해 최근 제로데이 취약점이 발견되었습니다. Active Directory 서비스 거부 취약점.

DoS 취약점의 작동 방식

Netlogon 원격 프로토콜(MS-NRPC)은 Windows 도메인 기반 네트워킹의 핵심 요소로, 사용자와 컴퓨터를 인증하고 도메인 구성원과 도메인 컨트롤러(DC) 간의 보안 채널을 유지하는 데 사용됩니다. 권한이 부여된 위치와 지속적인 네트워크 연결을 고려할 때, Netlogon의 권한 상승 취약점은 비권한 에스컬레이션 취약점조차도 치명적일 수 있습니다.

우리가 생각할 때 인증 취약점을 악용할 경우, 공격자가 권한을 상승시키거나, 자격 증명을 훔치거나, 원격 코드를 실행하는 것으로 상상하는 경우가 많습니다. 하지만 가장 파괴적인 위협 중 일부는 순전히 파괴적일 수 있습니다. 즉, 접근 차단, 서비스 중단, 도메인 전체 운영 중단 등을 초래할 수 있습니다. 이 글에서는 Netlogon 프로토콜의 핵심 시스템을 불안정하게 만들거나 비활성화할 수 있는 서비스 거부(DoS) 취약점인 NOTLogon을 알아봅니다. Active Directory 세션 협상 및 상태 처리의 결함을 악용하여 작업을 수행합니다.

넷로그온 101

NOTLogon의 의미를 이해하려면 Microsoft 도메인 기반 보안 아키텍처의 핵심 요소인 Netlogon 프로토콜을 이해해야 합니다. Netlogon 원격 프로토콜(MS-NRPC)은 도메인에 가입된 컴퓨터와 도메인 컨트롤러(DC)에서 사용하는 권한 있는 인증 및 채널 설정 프로토콜입니다. Windows NT에 도입되어 오늘날에도 여전히 활발하게 사용되고 있는 Netlogon은 컴퓨터 계정 인증, 인증 브로커 역할, 암호 순환 지원, 그리고 중요한 여러 가지 민감한 작업 지원 등 원격 도메인 기능을 지원합니다. Active Directory 하부 구조.

Netlogon 프로토콜의 가장 중요하지만 종종 간과되는 역할 중 하나는 Windows 도메인 환경 내에서 인증 브로커 역할을 하는 것입니다. Netlogon은 일반적으로 컴퓨터 계정의 보안 채널 설정과 관련이 있지만, 사용자 인증 요청을 처리하기 위해 로컬 보안 기관 하위 시스템 서비스(LSASS)와 도메인 컨트롤러 간의 중개자 역할도 합니다. 사용자가 네트워크를 통해 원격 애플리케이션에 로그인할 때, 자격 증명의 유효성을 검사해야 하는 경우 LSASS는 Netlogon에 인증을 위임합니다. Active DirectoryNetlogon은 요청을 NetrLogonSamLogon이라는 프로토콜별 메시지로 캡슐화하여 적절한 도메인 컨트롤러로 전달하고, 협상 및 응답을 투명하게 처리합니다. 이를 패스스루 인증이라고 합니다.

패스스루 인증 예제

Netlogon은 어떤 종류의 인증 시나리오를 지원합니까?

Netlogon은 NETLOGON_LEVEL 공용체(공식 명칭: NETLOGON_LOGON_INFO_CLASS)를 통해 다양한 인증 시나리오를 지원합니다. 이 공용체는 사용자 및 서비스 자격 증명의 패키징 및 전달 방식을 정의합니다. MS-NRPC 사양에 따르면 지원되는 수준은 다음과 같습니다.

NetlogonInteractiveInformation: 사용자가 워크스테이션에서 자격 증명을 입력하는 대화형 로그온의 경우(예: Ctrl+Alt+Del). 이 수준에서는 챌린지/응답 검증(일반적으로 NTLM 또는 Kerberos)를 DC로 전송합니다.

NetlogonNetworkInformation: 대화형 로그온 후 SMB 또는 RPC 리소스에 액세스하는 것과 같은 네트워크 로그온의 경우. 자격 증명(예: NTLM 토큰은 사용자에게 묻지 않고 투명하게 다시 전송됩니다.

NetlogonServiceInformation: Windows 서비스가 도메인 자격 증명을 사용하여 리소스에 액세스하는 데 사용되는 서비스 계정 로그온의 경우입니다.

전이 수준(대화형, 네트워크형, 서비스형): 위의 변형은 신뢰 관계가 있는 도메인 전체에 자격 증명이 전파되는 교차 도메인 또는 신뢰 바인딩 인증을 가능하게 합니다. 예: NetlogonInteractiveTransitiveInformation, NetlogonNetworkTransitiveInformation, NetlogonServiceTransitiveInformation.

NetlogonGenericInformation: NTLM, Digest를 포함한 일반 패스스루 인증의 경우 Kerberos PAC 검증은 서버가 사용자 자격 증명을 수락하고 검증을 위해 DC에 전달하는 방식입니다.

Netlogon은 어떻게 발전하고 있나요?

NTLM이 공식적으로 사용 중단됨에 따라 Microsoft는 29년 2024월 19일에 네트워크 티켓 로그온 사양을 공개했으며, 2024년 XNUMX월 XNUMX일에 출시된 MS-NRPC 업데이트에서 이를 마무리했습니다. 이 향상된 기능을 통해 서비스는 NetrLogonSamLogonEx RPC를 사용하여 미리 발급된 Kerberos 티켓을 도메인 컨트롤러에 제공할 수 있으므로 원래 클라이언트가 DC에 직접 연결할 필요가 없습니다.

이 시나리오는 티켓 검증이 오프라인 또는 중개자를 통해 수행될 수 있는 LocalKDC와 같은 향후 기능을 지원합니다. 이 시나리오는 권한이 부여된 RPC 경로 내에서 티켓 구문 분석, PAC 검증 및 위임된 신뢰 처리를 위한 새로운 로직을 도입하므로, 네트워크 티켓 로그온 메커니즘의 보안 경계와 오용 가능성을 평가하기 위해 분석을 시작했습니다.

새로운 네트워크 티켓 로그온 시나리오에 대한 우리의 여정은 NetrLogonSamLogonEx RPC 호출이라는 전달 메커니즘에서 시작되었습니다. Microsoft는 원래 로그온 흐름을 일반화하기 위해 이 호출을 도입했지만, 2024년 XNUMX월부터 NETLOGON_TICKET_LOGON_INFO 구조체를 수용하여 완전히 새로운 인증 경로를 지원합니다. 이는 네트워크 티켓 로그온 시나리오의 핵심입니다.—원래 클라이언트가 DC와 직접 상호 작용할 필요 없이, 서비스가 도메인 컨트롤러에 Kerberos 티켓을 제출하여 유효성 검사를 수행할 수 있도록 합니다.

NETLOGON_TICKET_LOGON_INFO 사양에 주의를 기울였더니 곧바로 복잡성과 모호성에 직면했습니다. 특히 ServiceTicket과 AdditionalTicket이라는 두 필드에 주목했습니다. 두 필드 모두 PUCHAR 버퍼(Windows API 프로그래밍에서 원시 바이트 배열을 나타내는 포인터 유형으로, 본질적으로 임의 길이의 부호 없는 문자 버퍼를 가리키는 주소)로 선언되었습니다. ServiceTicket의 역할은 "서비스 티켓을 포함하는 부호 없는 문자 배열에 대한 포인터"로 명확하게 정의되어 있었습니다. 아주 간단했습니다.

MS-NRPC RFC의 NETLOGON_TICKET_LOGON_INFO 구조

하지만 AdditionalTicket은 훨씬 더 모호했습니다. 사양에는 "서비스 티켓이 User2User 티켓인 경우, 세션 키의 소스로 사용되는 티켓 부여 티켓(TGT)도 제공해야 합니다."라고 명시되어 있습니다. 이는 답변보다 더 많은 의문을 불러일으켰습니다. 티켓이 U2U 시나리오를 나타내지 않는 한 이 필드는 선택 사항일까요? 예상되는 콘텐츠는 항상 TGT일까요? 다른 티켓 유형도 유효할 수 있을까요? 문제를 더 복잡하게 만드는 것은, 함께 제공되는 AdditionalTicketLength 필드가 "권한 부여 소스인 Kerberos 서비스 티켓의 길이"로 설명되어 있다는 것입니다. 버퍼에 TGT가 포함되어야 하는 경우, 이는 모순되는 설명입니다.

문서의 명확성이 부족했기 때문에 실험에 착수했습니다. 구조를 수동으로 구축하고 완전히 패치된 도메인 컨트롤러로 제어된 요청을 전송하기 시작했습니다. Netlogon과 같은 권한이 있는 RPC를 처리할 때는 구현 방식이 사양보다 더 중요한 경우가 많습니다.

NetrLogonSamLogonEx를 실행하기 위한 최소 요건은 도메인에 등록된 머신 계정이며, 이는 컴퓨터 또는 서버를 나타냅니다. 특히, 기본적으로 각 사용자는 도메인에 최대 10개의 머신 계정을 생성할 수 있습니다. Active Directory 도메인. 즉, 약한 사용자라도 Netlogon 인터페이스에 바인딩하고 도메인 컨트롤러에 네트워크 티켓 로그온을 수행할 수 있습니다.

충돌: 네트워크 티켓 로그인이 중단되는 곳

작동하는 NETLOGON_TICKET_LOGON_INFO 구조체를 생성한 후, NetrLogonSamLogonEx를 사용하여 도메인 컨트롤러에 표준 네트워크 티켓 로그온 요청을 전송했습니다. 이 요청에는 예상대로 유효한 서비스 티켓이 포함되어 있었습니다. Netlogon 호출은 STATUS_SUCCESS를 반환했지만, 응답에 포함된 KerberosError 필드에는 STATUS_INSUFFICIENT_RESOURCES가 포함되어 있었습니다. 겉보기에 유효한 요청인데도 이상하고 의심스러운 결과였습니다.

더 자세히 조사하기 위해 구조 퍼징을 시작했습니다. ServiceTicket을 완전히 생략하면 예상했던 STATUS_INVALID_PARAMETER가 반환되었습니다. 그러나 AdditionalTicket 필드를 대상으로 빈 버퍼로 전송하자 도메인 컨트롤러에서 충돌이 발생했습니다.

LSASS 충돌로 인해 전체 시스템 장애가 발생하고 도메인 컨트롤러가 재부팅됩니다.

크래시 덤프는 AdditionalTicket 버퍼를 Kerberos KERB_TICKET ASN.1 구조체로 디코딩하는 KdcUnpackAdditionalTgt라는 함수를 가리켰습니다. 치명적인 문제는 이 함수가 디코딩을 시도하기 전에 입력 버퍼가 비어 있지 않고 올바르게 구성되었는지 확인하지 못했다는 것입니다. 이로 인해 인증 및 보안 정책 적용을 제어하는 ​​Windows 프로세스인 LSASS 내에서 NULL 역참조가 발생했습니다.

LSASS는 보호된 프로세스이므로 충돌로 인해 전체 시스템 장애가 발생하고 도메인 컨트롤러가 재부팅되었습니다. 악용에 필요한 최소 요구 사항을 파악하기 위해 유효한 서비스 티켓이 필요한지 테스트했습니다. 그것은 아니었다.—ServiceTicket이 평가되기 전에 취약한 코드 경로에 도달합니다. 더 중요한 것은 높은 권한이 필요하지 않다는 것입니다. 네트워크 액세스와 취약한 컴퓨터 계정만으로도 충돌을 유발하기에 충분합니다.

이는 새로운 네트워크 티켓 로그온 시나리오로 인해 도입된 서비스 거부 취약점인 NOTLogon의 핵심을 형성합니다. 새로 추가된 버퍼 핸들러에서 유효성 검사가 부족하기 때문에 잘못된 RPC 호출 하나로도 도메인 컨트롤러가 불안정해질 수 있습니다. 이는 기업 환경에서 심각한 안정성 및 가용성 위협을 초래할 수 있습니다.

혼란 조성: 의미와 완화책

NOTLogon의 영향은 간단하면서도 심각합니다. 유효한 컴퓨터 계정과 정교하게 조작된 RPC 메시지만 있으면 공격자는 도메인 컨트롤러(핵심 기능을 담당하는 시스템)를 원격으로 손상시킬 수 있습니다. Active Directory인증, 권한 부여, 그룹 정책 적용 및 서비스 티켓 발급을 포함합니다. 모든 도메인 컨트롤러가 작동 중단되면 도메인이 사실상 마비되어 리소스 접근이 차단되고, 사용자 로그인이 중단되며, 중앙 집중식 ID에 의존하는 모든 구성 요소가 중단됩니다.

높은 권한이 필요하지 않습니다. 네트워크 액세스와 취약한 컴퓨터 계정만 있으면 됩니다. 자격 증명 관리가 제대로 이루어지지 않거나 워크스테이션과 도메인 컨트롤러 간의 세그먼테이션이 부족한 환경에서 NOTLogon은 운영 중단을 유발하는 저비용 고영향 벡터가 됩니다.

최신 버전을 설치하는 것이 좋습니다. Microsoft Patch Tuesday 업데이트가 8년 2025월 XNUMX일에 출시되었습니다.여기에는 CVE-2025-47978에 대한 수정 사항이 포함되어 있습니다. 이 문제는 Netlogon 서비스 자체에 있으므로 조직은 모든 ​​도메인 컨트롤러에 지체 없이 패치를 적용해야 합니다. 동시에 관리자는 컴퓨터 계정을 감사하고 강화해야 합니다. 도메인 컨트롤러에 대한 네트워크 액세스 제한특히 Netlogon RPC 흐름을 시작할 수 있는 서비스 계정 액세스를 제한하고 모니터링합니다.

보다 안전한 신원 보안 태세를 구축하는 방법 Active Directory

이 취약점 패치를 강력히 권장합니다. 하지만 이와 동시에 각 팀은 머신 계정을 감사 및 강화하고, 도메인 컨트롤러에 대한 접근을 제한하며, 특히 Netlogon RPC 흐름을 시작할 수 있는 서비스 계정의 접근을 제한하고 모니터링해야 합니다. Active Directory (AD)는 대부분 조직 네트워크의 중추이므로 공격자가 이를 악용하여 중요 데이터에 무단으로 액세스하는 위협을 줄이기 위해 보안 위생을 유지하는 것이 필수적입니다. Silverfort 청소하는 데 도움이 될 수 있습니다 Active Directory 다음을 포함한 다양한 방법으로 기술 부채를 줄이세요.

  • 폭로 숨겨진 관리자 계정 (일명 섀도우 관리자) 및 공격 영역을 조용히 확장할 수 있는 잘못된 구성.
  • 위험한 관행 식별 및 제거(예: NTLMv1 사용법 그리고 오래된 서비스 계정 기본 도구에서는 감지되지 않는 것들입니다.
  • 방어하다 은밀한 신원 기반 공격, 처럼 케르베로스팅 및 인쇄 스풀러 악용 사례가 확대되기 전에 예방하세요.

NOTLogon은 새로운 프로토콜 기능, 특히 권한 인증 서비스가 하룻밤 사이에 공격 대상이 될 수 있음을 일깨워줍니다. 보안 유지는 단순히 패치 적용에만 국한되지 않습니다. 우리가 매일 사용하는 기반 시스템을 철저히 점검하는 것이 중요합니다.

강화 방법에 대해 자세히 알아보려면 Active Directory 자세, 가이드를 다운로드하세요.AD 위생을 강화하는 5가지 방법. "

우리는 신원 보안을 한층 더 강화하기로 했습니다.

무엇이 가능한지 알아보세요.

데모를 설정하여 확인하세요 Silverfort 실제 사용 중인 ID 보안 플랫폼입니다.

새로운 영웅 (1)

Silverfort Fabrix Security를 ​​인수합니다.

런타임 시 자율적인 ID 보안 제공

심층 컨텍스트와 AI의 속도를 활용하여 모든 사람, 기계 및 에이전트의 신원을 보호하도록 설계된 최초의 자율 런타임 액세스 제어 엔진을 개척했습니다.