그림으로 이해하는 NTLM과 Kerberos ── 왜 인증은 NTLM으로 「떨어지는가」

「우리 회사는 Kerberos 환경입니다」라고 말하는 사내 네트워크에서도, 감사 로그를 뽑아 보면 반드시 NTLM이 나타납니다. 게다가 나타나는 것은 대체로 Kerberos를 지원할 것 같은 앱입니다.

왜 그렇게 되는지는 두 프로토콜이 「무엇을 증명하려 하는지」를 나란히 놓고 보면 한눈에 알 수 있습니다. 이 글은 NTLM과 Kerberos의 동작을 그림으로 짚어 보고, 어떤 조건에서 NTLM으로 떨어지는지, 그리고 왜 마이크로소프트가 NTLM을 그만두려 하는지를 공식 문서의 근거와 함께 정리한 것입니다.

자사 환경의 점검 절차(감사 정책 설정, 이벤트 추적 방법, 고치는 순서)는 짝을 이루는 글 「NTLM 사용 중단으로 업무 앱이 멈출까」에 정리해 두었습니다.

1. 먼저 결론

• NTLM은 「비밀번호의 해시를 가지고 있다는 것」만 증명합니다. 자격 증명은 도메인 이름과 사용자 이름, 그리고 비밀번호의 일방향 해시이며,¹ 지금의 Windows가 사용하는 NTLMv2에서는 그 해시에서 유도한 키로 「서버의 챌린지+시각+클라이언트 쪽 챌린지+타깃 정보」에 대한 HMAC을 계산해 돌려줍니다(2.2절).²
• Kerberos는 「누가, 어느 서비스에 대해」를 증명합니다. 접속 대상 서비스 이름(SPN)을 키로 삼아 티켓을 발급하므로, 수신처가 다른 티켓은 쓸 수 없습니다.³
• 결정적인 차이는 세 가지입니다. 상호 인증의 유무, (도메인 계정 인증에서) 서버가 도메인 컨트롤러에 문의하는지 여부, 위임이 가능한지 여부. 모두 마이크로소프트가 명시하고 있습니다(5장).⁴
• NTLM으로 떨어지는 가장 큰 이유는 「이름」입니다. Kerberos는 접속 대상의 이름에서 SPN을 찾지 못하면 시작되지 않습니다. IP 주소 직접 입력, SPN 미등록, 워크그룹, DC에 도달할 수 없는 경로가 4대 요인입니다(6장).⁵⁶
• 「Kerberos가 실패한다」와 「NTLM으로 떨어진다」는 서로 다른 현상입니다. 전자는 Kerberos가 선택된 상태에서 오류가 나는 것(시각 어긋남 등)으로, 인증 자체가 멈춥니다. 후자는 Kerberos를 시작하지 못한 채 조용히 NTLM으로 전환되는 것으로, 업무는 그대로 돌아갑니다. 장애 분석은 이 두 갈래에서 시작하십시오(6.5절).⁷
• 릴레이 공격이 성립하는 것은 NTLM에 「누구에 대해 인증하고 있는지」를 묶어 두는 구조가 없기 때문입니다. Pass-the-Hash가 성립하는 것은 인증에 필요한 것이 해시 그 자체이기 때문입니다(7장).⁸¹
• NTLMv1은 이미 삭제되었습니다. Windows 11 버전 24H2와 Windows Server 2025가 대상입니다. NTLMv2는 비권장이지만 아직 동작합니다(8장).⁹
• 앱이 써야 할 것은 Negotiate입니다. Negotiate는 Kerberos와 NTLM 중 하나를 고르며, 인증에 관여하는 시스템 중 어느 하나라도 Kerberos를 쓸 수 없는 경우를 제외하면 Kerberos를 선택합니다.¹

그림의 실선은 항상 성립하는 관계, 점선은 조건이 붙는 관계입니다(성립 조건은 상세 페이지의 관계별 설명에 적혀 있습니다). 관계 전체 목록(총 35건, 근거와 확신도 포함)과 주요 개념의 정의는 지식 맵 상세 페이지에 정리되어 있습니다(일본어). 데이터: JSON-LD / Turtle

2. NTLM은 무엇을 하고 있는가

NTLM(Windows Challenge/Response)은 이름 그대로 챌린지/응답 방식의 인증 프로토콜입니다. 마이크로소프트의 설명을 요약하면, 자격 증명은 대화형 로그온 시 얻은 도메인 이름과 사용자 이름, 그리고 비밀번호의 일방향 해시로 구성되고(해시되는 것은 비밀번호뿐입니다), 비밀번호를 회선에 흘리지 않고 인증하기 위해 인증을 요청하는 쪽이 「안전하게 보관된 NTLM 자격 증명에 접근할 수 있음」을 증명하는 계산을 수행합니다.¹

여기서 중요한 것은 인증의 재료가 비밀번호 그 자체가 아니라 비밀번호의 해시라는 점입니다. 이 한 가지가 뒤에서 볼 Pass-the-Hash의 성립 조건이 됩니다.

2.1. 도메인 계정이라면 3자가 등장한다

이미 로그온한 사용자가 도메인 계정으로 서버상의 리소스에 접근하는 상황(비대화형 인증)에서는 클라이언트·서버·도메인 컨트롤러 3자가 관여합니다. 이때 서버 자신은 인증 계산을 하지 않고, 도메인 컨트롤러가 대신 계산해 준다는 점이 특징입니다.¹

sequenceDiagram
    autonumber
    participant C as 클라이언트
    participant S as 서버
    participant DC as 도메인 컨트롤러

    Note over C: 로그온 시 비밀번호의<br/>해시를 계산하고, 비밀번호 본체는 폐기
    C->>S: 사용자 이름(평문)
    S->>C: 8바이트 난수(챌린지)
    Note over C: 챌린지를<br/>비밀번호의 해시로 암호화
    C->>S: 응답
    S->>DC: 사용자 이름 / 챌린지 / 응답
    Note over DC: SAM에서 해시를 꺼내<br/>같은 계산을 한다
    DC-->>S: 일치하면 인증 성공
    S-->>C: 접근을 허용

그림 1: NTLM의 비대화형 인증(도메인 계정의 경우)

마이크로소프트가 개념으로 제시하는 절차는 다음과 같습니다(실제 계산은 뒤에서 말하듯 NTLMv2에서 달라지지만, 등장 인물과 역할 분담은 이 그림 그대로입니다).¹

1. (대화형 인증만) 사용자가 도메인 이름·사용자 이름·비밀번호를 입력한다. 클라이언트는 비밀번호의 암호학적 해시를 계산하고, 실제 비밀번호는 폐기한다.
2. 클라이언트는 사용자 이름을 평문으로 서버에 보낸다.
3. 서버는 8바이트 난수(챌린지, nonce)를 생성해 클라이언트에 보낸다.
4. 클라이언트는 이 챌린지를 사용자 비밀번호의 해시로 암호화하고, 결과(응답)를 돌려준다.
5. 서버는 사용자 이름·클라이언트에 보낸 챌린지·받은 응답의 세 가지를 도메인 컨트롤러에 보낸다.
6. 도메인 컨트롤러는 사용자 이름에서 SAM 데이터베이스의 비밀번호 해시를 꺼내, 그것으로 챌린지를 암호화한다.
7. 스스로 계산한 결과와 클라이언트의 응답을 비교해, 동일하면 인증 성공.

2.2. 실제 계산 ── NTLMv2는 한 단계 더 복잡하다

위의 7단계는 마이크로소프트가 개요 페이지에서 설명하는 기본형입니다. 지금의 Windows가 실제로 쓰는 NTLMv2는 「챌린지를 비밀번호의 해시로 암호화한다」보다 한 단 더 복잡합니다. 사양([MS-NLMP])에서는 다음과 같이 정의되어 있습니다.²

• 응답 키는 NTOWFv2 = HMAC_MD5( MD4(UNICODE(비밀번호)), 대문자로 만든 사용자 이름 + 도메인 이름 )
• 클라이언트는 응답 버전·시각·클라이언트 쪽에서 생성한 8바이트 챌린지·타깃 정보(AV 쌍)를 연결한 temp를 만든다
• 응답의 핵이 되는 NTProofStr = HMAC_MD5( 응답 키, 서버의 챌린지 + temp )

재료와 처리 흐름만 꺼내면 다음 한 장입니다.

flowchart TD
    PW["비밀번호"] --> MD4["MD4(UNICODE(비밀번호))<br/>= NT 해시"]
    UD["대문자로 만든 사용자 이름<br/>+ 도메인 이름"] --> H1["HMAC_MD5"]
    MD4 -->|"이것을 키로 쓴다"| H1
    H1 --> KEY["응답 키 NTOWFv2"]

    MAT["응답 버전 / 시각 /<br/>클라이언트 쪽 8바이트 챌린지 /<br/>타깃 정보(AV 쌍)"] --> TEMP["temp"]

    SC["서버의 챌린지"] --> H2["HMAC_MD5"]
    TEMP --> H2
    KEY -->|"이것을 키로 쓴다"| H2
    H2 --> PROOF["NTProofStr"]
    PROOF --> RESP["NtChallengeResponse<br/>= NTProofStr + temp"]
    TEMP --> RESP

그림 2: NTLMv2의 응답이 만들어지기까지(비밀번호 → NT 해시 → 응답 키 → HMAC)

즉 실제로는 서버의 챌린지뿐 아니라 클라이언트 쪽 난수·시각·수신처 정보까지 섞은 HMAC을 계산합니다. 검증 쪽도 같은 계산을 재현합니다. 계정이 Active Directory에 있으면 챌린지와 응답의 쌍을 도메인 컨트롤러로 보내 검증하고, 서버에 로컬인 계정이라면 서버가 스스로 보관하는 OWF로 기대값을 계산합니다.²

이 글의 논의에서 중요한 것은, 복잡해져도 다음 두 가지는 변하지 않는다는 점입니다.

1. 키의 재료는 지금도 비밀번호의 해시입니다. NTOWFv2의 출발점은 MD4(UNICODE(비밀번호)), 즉 NT 해시 그 자체입니다.² 그래서 Pass-the-Hash가 성립합니다(7.2절).
2. 클라이언트는 서버가 진짜인지를 검증하지 않습니다. NTLM에는 상호 인증이 없다는 마이크로소프트의 설명은 NTLMv2에서도 바뀌지 않습니다.⁴

이후 설명은 이 두 가지 위에 올라갑니다.

2.3. 로컬 계정이라면 둘만으로 끝난다

로컬 계정의 경우에는 이 그림의 오른쪽이 사라집니다. 리소스 서버는 계정이 도메인 계정이면 그 도메인의 도메인 컨트롤러에 있는 인증 서비스에 문의하지만, 로컬 계정이면 로컬 계정 데이터베이스를 참조합니다.¹⁰ 즉 워크그룹 컴퓨터나, 파일 서버의 로컬 계정으로 공유에 연결하는 경우에는 도메인 컨트롤러가 등장하지 않고, 서버가 자신의 SAM을 보고 스스로 판정하는 둘만의 주고받기가 됩니다.

이 차이는 6.3절에서 다루는 「로컬 계정이라서 Kerberos를 쓸 수 없다」는 의존 관계 점검으로 직결됩니다. 도메인 컨트롤러의 감사 로그를 봐도 이 경로의 NTLM은 나오지 않습니다.

2.4. 이 설계에서 나오는 세 가지 귀결

그림 1을 보면, 나중에 문제가 되는 성질이 그대로 읽힙니다.

• 서버는 클라이언트에게 아무것도 증명하지 않는다. 주고받기는 일방통행이고, 서버가 「나는 진짜다」를 보이는 절차가 어디에도 없습니다.
• 서버는 스스로 해시를 가지고 있을 때만 판정할 수 있다. 리소스 서버는 새 액세스 토큰이 필요할 때마다, 도메인 계정이면 도메인 컨트롤러의 인증 서비스에 문의하고, 로컬 계정이면 로컬 계정 데이터베이스를 참조해야 합니다.¹⁰ 도메인 계정 인증이 도메인 컨트롤러에 의존하는 것은 이 때문입니다.
• 응답은 「그 챌린지에 한해서」이지만, 수신처를 묶지 않는다. 챌린지가 매번 다르므로 같은 응답을 재사용할 수는 없습니다. 그러나 「이 응답은 어느 서버 앞인가」를 증명하는 요소가 없으므로, 다른 서버로 가로채여도 알아채지 못합니다.

3. 왜 서버는 도메인 컨트롤러에 묻는가

도메인 계정 인증에서는 비밀번호의 해시를 가지고 있는 쪽이 도메인 컨트롤러 쪽 계정 데이터베이스뿐입니다. 리소스 서버는 그 사용자의 해시를 모르므로 혼자서는 검증할 수 없습니다. 그래서 인증할 때마다 도메인 컨트롤러에 문의하는(패스스루 인증) 일이 필요합니다.¹⁰¹(로컬 계정이라면 서버는 자신의 SAM을 조회해 스스로 판정합니다. 도메인 컨트롤러 의존이라는 아래 이야기는 도메인 계정인 경우의 이야기입니다.)

이는 안전 면에서도 운영 면에서도 대가가 있습니다. 마이크로소프트는 Kerberos 이전의 NTLM 인증에서는 애플리케이션 서버가 클라이언트나 서비스를 인증할 때마다 도메인 컨트롤러에 접속해야 했다는 데 비해, Kerberos에서는 갱신 가능한 세션 티켓이 패스스루 인증을 대체하고, 서버는 PAC(권한 특성 인증서) 검증이 필요한 경우를 제외하면 도메인 컨트롤러로 갈 필요가 없다고 설명합니다.⁴

즉 Kerberos로의 이전은 보안 이야기인 동시에, 도메인 컨트롤러에 대한 의존을 줄이는 이야기이기도 합니다.

4. Kerberos는 무엇을 하고 있는가

Kerberos의 발상은 NTLM과 분명히 다릅니다. 인증할 때마다 본인 확인을 다시 하는 것이 아니라, 처음에 한 번만 본인 확인을 하고 「티켓」을 받은 뒤, 이후에는 그 티켓을 보여 주는 방식입니다.

KDC(키 배포 센터)는 도메인 컨트롤러 위에서 동작하며, Active Directory Domain Services의 데이터베이스를 보안 계정 데이터베이스로 사용합니다.⁴

sequenceDiagram
    autonumber
    participant C as 클라이언트
    participant KDC as KDC (도메인 컨트롤러)
    participant S as 서비스 (SPN으로 식별)

    Note over C,KDC: AS 교환 ── 본인 확인과 TGT 취득
    C->>KDC: KRB_AS_REQ<br/>(사용자 이름 + 장기 키로 암호화한 시각)
    Note over KDC: 장기 키로 복호화되면 본인
    KDC-->>C: KRB_AS_REP<br/>TGT(krbtgt의 키로 암호화) + 세션 키

    Note over C,KDC: TGS 교환 ── 서비스 티켓 취득
    C->>KDC: KRB_TGS_REQ<br/>(TGT + 접속 대상의 SPN + 인증자)
    Note over KDC: SPN에서 서비스 계정을 찾아<br/>그 장기 키로 티켓을 암호화
    KDC-->>C: KRB_TGS_REP<br/>서비스 티켓 + 세션 키

    Note over C,S: AP 교환 ── 서비스에 제시
    C->>S: KRB_AP_REQ<br/>(서비스 티켓 + 인증자)
    Note over S: 자신의 장기 키로 복호화할 수 있다<br/>= 자기 앞의 티켓
    S-->>C: KRB_AP_REP(상호 인증을 요청한 경우)

그림 3: Kerberos의 세 가지 교환(AS / TGS / AP)

범례 ── AS = Authentication Service(인증 서비스), TGS = Ticket Granting Service(티켓 허가 서비스), AP = Application(애플리케이션). 메시지 이름의 _REQ는 요청, _REP는 응답입니다. 예를 들어 KRB_TGS_REQ는 「티켓 허가 서비스에 대한 요청」을 뜻합니다.

4.1. AS 교환 ── 한 번의 본인 확인

클라이언트는 KDC에 사용자 이름·도메인 이름과, 자신의 장기 키(비밀번호에서 도출되는 키)로 암호화한 타임스탬프를 보냅니다. 이것이 사전 인증(pre-authentication)입니다. KDC는 그 장기 키로 복호화할 수 있고, 게다가 타임스탬프가 타당하면 「본인이다」라고 판단합니다.³

KDC는 TGT(티켓 허가 티켓)를 돌려줍니다. TGT는 KDC 자신의 장기 키(krbtgt 계정의 키)로 암호화되어 있으므로, 클라이언트는 내용을 읽을 수 없습니다. 함께, 클라이언트와 KDC 사이에서 쓰는 세션 키가 클라이언트의 장기 키로 암호화되어 전달됩니다.³

여기서 짚어 둘 것은 타임스탬프가 인증의 일부가 되어 있다는 점입니다. Kerberos가 시각 동기화에 엄격한 것은 이 때문이며, 기본값으로 허용되는 시각 차이는 5분입니다.⁷ 여기를 벗어나면 사전 인증이 통과되지 않고, Kerberos 인증 자체가 오류로 실패합니다(Windows의 시각 동기화는 「Windows의 시각 동기화(w32time) 가이드」에 정리해 두었습니다). 이 「Kerberos가 실패한다」와 「NTLM으로 떨어진다」는 별개입니다. 구분은 6.4절에서 다룹니다.

4.2. TGS 교환 ── 「어느 서비스에 연결하는가」를 신고한다

여기가 NTLM과의 결정적 분기점입니다. 클라이언트는 연결하려는 서비스의 이름(SPN)을 KDC에 알리고, TGT와 인증자를 붙여 서비스 티켓을 요청합니다.³

KDC는 그 SPN에 대응하는 서비스 계정을 찾아, 그 계정의 장기 키로 서비스 티켓을 암호화해 돌려줍니다.³ 그래서,

• SPN을 찾지 못하면 티켓은 발급되지 않습니다. 서비스 계정에 SPN이 등록되어 있지 않으면 KDC는 상대를 특정할 수 없습니다. 접속 대상을 IP 주소로 지정한 경우에도, 기본값에서는 Kerberos가 시도되지 않습니다(6.1절).
• 티켓은 「그 수신처 전용」입니다. 다른 서비스의 장기 키로는 복호화할 수 없으므로, 수신처를 바꿔 재사용할 수 없습니다.

4.3. AP 교환 ── 서비스에 제시와 상호 인증

클라이언트는 서비스 티켓과 인증자를 서비스에 제시합니다. 서비스는 자신의 장기 키로 티켓을 복호화하고, 안의 세션 키와 권한 부여 정보를 꺼냅니다. 복호화된 것 자체가 「이 티켓은 내 앞이다」의 증명이 됩니다.³

클라이언트가 상호 인증을 요청한 경우, 서비스는 받은 타임스탬프를 세션 키로 암호화해 돌려줍니다. 클라이언트는 그것을 검증함으로써 상대가 진짜 서비스임을 확인할 수 있습니다.³ NTLM에는 없는 절차입니다.

5. 결정적인 차이

「위임」행은 실무에서는 더 갈라집니다. 위임에는 제한 없는 위임·제한된 위임(constrained delegation)·리소스 기반 제한된 위임(RBCD) 같은 종류가 있고, 프론트엔드 Web 앱에서 백엔드 SQL Server로 사용자의 자격으로 연결하는 구성에서는 무엇을 고를지가 설계상의 논점이 됩니다. 이 글에서는 들어가지 않지만, Kerberos 위임을 조사할 때의 다음 검색어로 기억해 두십시오.

이 표의 아래 두 행이 그대로 「NTLM으로 떨어지는 이유」가 됩니다. Kerberos의 강점(수신처를 묶는다, 상대를 검증한다)은 이름이 올바르게 찾아진다는 것 위에 성립하기 때문입니다.

6. 왜 NTLM으로 「떨어지는가」

애플리케이션이 직접 NTLM을 지정하지 않아도 NTLM은 쓰입니다. Negotiate가 그렇게 동작하기 때문입니다. 마이크로소프트의 설명에서는 Negotiate는 Kerberos와 NTLM 중 하나를 선택하고, 인증에 관여하는 시스템 중 어느 하나라도 Kerberos를 쓸 수 없는 경우를 제외하면 Kerberos를 선택합니다.¹

즉 「NTLM이 되었다」는 대부분의 경우 「Kerberos를 쓸 수 없었다」의 다른 말입니다.

flowchart TD
    START["Negotiate 로 인증을 시작"]
    Q1{"도메인의<br/>계정인가?"}
    Q2{"접속 대상 이름에서<br/>SPN 을 만들 수 있는가?"}
    Q3{"그 SPN 은<br/>등록되어 있는가?"}
    Q4{"KDC 에<br/>도달하는가?"}
    KRB["Kerberos 로 인증"]
    NTLM["NTLM 으로 폴백"]

    START --> Q1
    Q1 -->|"아니요<br/>(워크그룹 / 로컬 계정)"| NTLM
    Q1 -->|예| Q2
    Q2 -->|"아니요<br/>(IP 주소 직접 입력)"| NTLM
    Q2 -->|예| Q3
    Q3 -->|"아니요<br/>(SPN 미등록 / 별칭으로 접근)"| NTLM
    Q3 -->|예| Q4
    Q4 -->|"아니요<br/>(거점 / VPN / FW)"| NTLM
    Q4 -->|예| KRB

그림 4: Negotiate가 NTLM으로 떨어지는 분기

4대 요인을 조건·이유·고치는 방법의 3열로 먼저 늘어놓습니다. 자세한 내용은 6.1절 이후에서 다룹니다.

6.1. IP 주소로 접속하고 있다

가장 많은 원인입니다. 마이크로소프트는 기본값에서는 호스트 이름이 IP 주소인 경우, Windows는 그 호스트에 대해 Kerberos 인증을 시도하지 않고 NTLM 등 유효한 다른 인증 프로토콜로 폴백한다고 명시합니다.¹¹ 감사 가이드 쪽에서도, 이벤트 8001의 「대상 서버」가 NetBIOS 형식도 FQDN 형식도 아니면 Kerberos는 사용되지 않는다고 적혀 있습니다.⁵

그리고 그렇게 되어 버리는 이유도 들어 있습니다. 설정 실수나 벤더 문서 때문에 DNS 이름이 아니라 IP 주소를 쓰는 애플리케이션입니다.⁵ 「이름 확인이 불안정해서」라고 과거에 IP로 바꿔 둔 설정이 그대로 남아 있는 경우도 실무에서는 매우 많이 봅니다.

다만 이것은 기본 동작이지 절대 제약은 아닙니다. Windows 10 버전 1507 및 Windows Server 2016 이후에는 SPN의 호스트 이름으로 IP 주소를 쓸 수 있게 하는 구조가 있습니다. 클라이언트 쪽 레지스트리 값 TryIPSPN을 1로 한 다음, Setspn -s <서비스 클래스>/<IP 주소> <계정> 형태로 IP 주소의 SPN을 수동 등록하면, IP 주소 앞으로도 Kerberos가 성립합니다. 등록하는 것은 클라이언트가 실제로 요구하는 서비스 클래스이며, 공유 폴더처럼 HOST에 매핑되는 것은 host/192.168.1.1로 충분하지만, Web이면 HTTP/192.168.1.1, SQL Server이면 MSSQLSvc/192.168.1.1:1433처럼 포트까지 포함한 다른 SPN이 필요합니다. host/만 등록해도, 요구되는 SPN과 일치하지 않으면 Kerberos는 성립하지 않습니다. 마이크로소프트는 이 기능을 바로 NTLM 비활성화의 영향을 줄이기 위한 것으로 자리매김합니다.¹¹

그렇다고 이것이 첫 번째 선택은 아닙니다. 마이크로소프트 스스로 IP 주소는 일시적인 것이며 리스 만료와 갱신에 따른 충돌이나 인증 실패를 부를 수 있어 보통은 호스트 이름 대신 쓰지 않고, IP 주소 기반 SPN 등록은 수작업이며 DNS 기반 호스트 이름으로 전환하는 것이 불가능한 경우에만 써야 한다고 합니다.¹¹ 감사에서 나온 IP 주소 직접 입력은 먼저 FQDN으로 고치는 것을 생각하십시오. TryIPSPN은 그것이 도저히 안 되는 상대에 대한 최후 수단입니다.

6.2. SPN이 등록되어 있지 않다

두 번째로 많은 원인입니다. 마이크로소프트는 Kerberos를 지원해도 NTLM을 쓰게 되는 앱의 유형으로 SPN이 올바르게 구성되어 있지 않은 애플리케이션을 듭니다.⁵

그림 3의 TGS 교환에서 본 대로, KDC는 SPN에서 서비스 계정을 찾아 티켓을 암호화합니다. SPN이 없으면 KDC는 「그 서비스의 키」를 특정할 수 없습니다. DNS 별칭(CNAME)이나 독자 호스트 이름으로 접근하는 경우에도, 그 이름의 SPN이 등록되어 있지 않으면 같은 일이 일어납니다. 앱은 올바르게 동작하는데 이름만 등록부에 없는 상태입니다.

6.3. 애초에 Active Directory 밖에 있다

워크그룹 구성의 단말기나 로컬 계정으로의 공유 접근은 Kerberos의 범위 밖입니다. 마이크로소프트도 워크그룹 구성원으로 구성된 시스템의 Windows 인증과, 도메인 컨트롤러 이외에서의 로컬 로그온 인증에는 NTLM이 쓰이며, 쓰여야 한다고 합니다.¹⁰

여기가 NTLM을 「단순히 금지」할 수 없는 이유입니다. 2단계에서 예정된 로컬 KDC는 바로 이 구멍을 메우기 위한 기능입니다.⁶ 다만 메워지는 것은 대응하는 Windows끼리인 경우뿐이라고 생각하십시오. 오래된 Windows나 NAS·복합기 같은 타사 장비가 상대인 로컬 계정 인증은, 로컬 KDC가 와도 자동으로 Kerberos가 되지 않습니다. 이 분류는 실무편의 5장·6장에서 다룹니다.

6.4. KDC에 닿지 않는다

거점이나 VPN 너머로 도메인 컨트롤러에 도달하지 못하거나, Kerberos에 필요한 포트가 방화벽으로 막혀 있는 경로 문제에서도 폴백이 일어납니다.⁶ KDC와 말할 수 없으면 티켓을 받을 방법이 없으므로, Negotiate는 남은 선택인 NTLM을 고릅니다.

6.5. 「Kerberos의 실패」와 「NTLM으로의 떨어짐」을 혼동하지 않는다

마지막으로, 헷갈리기 쉽지만 별개인 이야기를 구분해 둡니다. 여기까지의 6.1〜6.4는 모두 「Kerberos를 시작하지 못했다」는 경우입니다. 시작하지 못하므로 Negotiate는 NTLM을 고릅니다.

한편 Kerberos가 선택된 뒤 그 위에서 실패한 경우는 이야기가 다릅니다. 대표 예가 시각 어긋남입니다. SPN을 찾을 수 있고 KDC에도 닿아 있으면 Negotiate는 먼저 Kerberos를 고릅니다. 그다음 시각이 허용 차(기본 5분)를 넘으면 사전 인증이 통과되지 않고 Kerberos 오류로 실패합니다.⁷ 고른 프로토콜이 실패했다고 해서 Negotiate가 자동으로 NTLM으로 바꿔 다시 시도하는 것은 아닙니다(애플리케이션이 명시적으로 다른 방식으로 재시도하는 경우는 제외합니다).

실무상의 의미는 단순합니다. 시각 어긋남 장애를 이벤트 8001을 찾아 쫓아도 나오지 않습니다. 증상도 다릅니다.

「NTLM으로 떨어지고 있는지, Kerberos가 깨져 있는지」를 먼저 나눈 뒤 조사하십시오.

7. 공격에서 본 차이 ── 릴레이와 Pass-the-Hash

마이크로소프트는 정책 설정 문서에서 NTLM 및 NTLMv2 인증은 SMB 릴레이, 중간자 공격, 무차별 대입 공격을 포함한 다양한 악의적 공격에 취약하다고 명시합니다.⁸ 왜 그렇게 되는지는 그림 1을 보면 설명할 수 있습니다.

7.1. 릴레이 공격 ── 수신처를 묶지 않는 것의 귀결

sequenceDiagram
    autonumber
    participant V as 피해자의 PC
    participant A as 공격자의 서버
    participant T as 진짜 서버

    Note over V,A: 공격자의 서버로 유도한다
    V->>A: 인증을 시작(사용자 이름)
    A->>T: 같은 사용자로 인증을 시작
    T-->>A: 챌린지
    A-->>V: 그 챌린지를 그대로 전달
    Note over V: 진짜 서버에서 온 것인지<br/>구별할 수 없다
    V->>A: 응답(해시에서 온 키로 계산)
    A->>T: 그 응답을 그대로 전달
    Note over T: 서명도 channel binding 도<br/>요구하지 않는 경우
    T-->>A: 인증 성공 → 피해자로 연결 확립

그림 5: NTLM 릴레이의 성립(서명·채널 바인딩이 없는 상대인 경우)

공격자는 비밀번호도 해시도 알 필요가 없습니다. 챌린지와 응답을 오른쪽에서 왼쪽으로 흘리기만 하면 됩니다. 이것이 성립하는 것은, 클라이언트 쪽에 「이 응답이 정말로 의도한 상대에게 전달되고 있는가」를 확인할 수단이 없기 때문입니다.

다만 어떤 상대에게든 중계가 통하는 것은 아닙니다. 중계된 주고받기가 쓸 수 있는 세션이 되는지는 접속 대상의 방어에 달렸습니다.

• SMB 서명을 요구하는 상대에는 통하지 않습니다. 마이크로소프트는 SMB의 모든 메시지에 붙는 서명이 메시지 전체의 해시를 포함하며, 송신자와 수신자의 신원을 확인하기 때문에 릴레이 공격을 막는다고 명시합니다.¹² 참고로 도메인 컨트롤러는 기본값으로 연결을 걸어 오는 쪽에 SMB 서명을 요구합니다.¹²
• Extended Protection for Authentication(채널 바인딩)을 강제하는 서비스에도 통하지 않습니다. 인증을 그 아래 TLS 채널에 묶기 때문에, 다른 채널로 중계한 인증이 통과되지 않게 됩니다.

즉 그림 5가 그리는 것은 서명도 채널 바인딩도 걸려 있지 않고 NTLM을 받아들이는 상대라는 조건에서의 성립 경로입니다. 뒤집으면, 이것은 실무에서 지금 당장 취할 수 있는 조치가 있다는 뜻이기도 합니다. NTLM 점검과 병행해 SMB 서명 요구 현황을 확인해 둘 가치가 있습니다.

Kerberos에서는 애초에 같은 형태의 중계를 할 수 없습니다. 서비스 티켓은 수신처 서비스의 장기 키로 암호화되어 있기 때문에, 다른 서비스에 가져가도 복호화할 수 없습니다.³ 게다가 클라이언트는 상호 인증으로 상대가 진짜인지를 확인할 수 있습니다.⁴

마이크로소프트가 SMB 클라이언트 쪽 NTLM 차단을 마련한 이유도 바로 이것입니다. 악의 있는 서버로 NTLM 요청을 보내게 하는 수법을 막는 것이 목적이라고 설명되어 있습니다.¹³ 참고로 SMB 서명 주변의 권장으로 마이크로소프트는, 세션 키가 강한 상태에서 시작되도록 NTLMv2가 아니라 Kerberos를 쓸 것, 그리고 IP 주소나 CNAME 레코드로 공유에 접속하지 말 것(그러면 Kerberos가 아니라 NTLM이 쓰이므로)도 듭니다.¹² 6.1절·6.2절과 같은 이야기입니다.

7.2. Pass-the-Hash ── 해시가 비밀번호와 등가라는 것

flowchart LR
    P["비밀번호"] -->|"일방향 해시"| H["비밀번호의 해시"]
    H -->|"응답 키를 도출하고<br/>HMAC 을 계산"| R["응답"]
    R --> AUTH["인증 성공"]
    STEAL["단말기에서<br/>해시를 탈취"] --> H
    NOTE["평문 비밀번호는<br/>불필요"] -.-> STEAL

그림 6: 인증에 필요한 것은 해시이지, 평문 비밀번호가 아니다

NTLM 자격 증명의 재료는 비밀번호의 일방향 해시입니다.¹ NTLMv2에서는 그 MD4(UNICODE(비밀번호))를 키로 응답 키를 도출하고, 다시 그 키로 HMAC을 계산해 응답을 만듭니다.² 계산의 형태가 바뀌어도 출발점이 해시라는 점은 변하지 않습니다. 즉 인증에 필요한 것은 해시이지, 평문 비밀번호가 아닙니다.

이 귀결은 운영상 매우 무거운 의미를 갖습니다. 비밀번호를 길고 복잡하게 해도, 해시를 훔치는 경로는 막히지 않습니다. 마이크로소프트도 SMB의 NTLM 차단이 맞서는 공격으로 무차별 대입·크래킹과 나란히 Pass-the-Hash를 듭니다.¹³

Kerberos에도 장기 키는 존재하지만, 일상 인증에서 오가는 것은 유효 기간이 있는 티켓과 세션 키입니다.³ 도난당했을 때의 유효 범위가 다릅니다.

8. NTLMv1·NTLMv2와 「삭제」

NTLM은 하나의 프로토콜이 아니라, LAN Manager 버전 1·2와 NTLM 버전 1·2를 포함하는 인증 프로토콜 무리입니다.¹⁰

현재 취급은 다음과 같이 갈라집니다.

즉 「NTLMv2니까 당분간 방치해도 된다」가 아닙니다. 다만 우선순위는 분명하고, NTLMv1밖에 말하지 못하는 장비나 호스트가 최우선입니다. 감사에서 NTLM V1이 기록된 호스트는, 그대로 새 Windows로 올리면 인증이 통과되지 않게 됩니다. 버전을 구분하는 방법(보안 로그의 「패키지 이름 (NTLM만)」을 보는 것)은 실무편 글의 4.4절에서 다룹니다.⁵

참고로 NTLM을 제한하는 감사 및 차단 정책은 NTLMv1과 NTLMv2 양쪽에 같은 효과를 갖습니다.⁵ 제한을 걸 때 버전으로 동작이 바뀌지는 않습니다.

9. 앞으로 어떻게 되는가

마이크로소프트가 제시하는 방향은 세 가지입니다.

첫 번째는 애플리케이션 쪽에서 Negotiate를 쓰는 것입니다. NTLM 호출은 Negotiate 호출로 바꿔야 한다는 것이 비권장 고지 그 자체에 포함된 지시입니다.⁹ 애플리케이션은 NTLM 보안 패키지에 직접 접근해서는 안 된다고도 명시되어 있습니다.¹

두 번째는 NTLM이 필요해지는 장면 자체를 줄이는 것입니다. 2단계(2026년 후반)에 예정된 IAKerb와 로컬 KDC가 이에 해당합니다.⁶ 6.3절에서 본 「로컬 계정이라서 Kerberos를 쓸 수 없다」「도메인 컨트롤러에 닿지 않아서 Kerberos를 쓸 수 없다」는 두 구멍을 프로토콜 쪽에서 메우러 가는 시도입니다. 다만 메워지는 범위에는 한계가 있습니다. IAKerb가 푸는 것은 도메인 컨트롤러에 대한 도달성이며, 상대의 대응 가능 여부가 아닙니다. 로컬 KDC도 대응하는 Windows끼리가 아니면 효과가 없습니다. 타사 NAS나 복합기가 상대라면 2단계를 기다려도 상황은 바뀌지 않으므로, 장비 갱신·도메인 참가·다른 프로토콜로의 전환·예외 관리 중 하나를 스스로 골라야 합니다.

세 번째는 기본값을 바꾸는 것입니다. 3단계에서는 차기 메이저 릴리스에서 네트워크 NTLM 인증이 기본으로 비활성화되는 계획입니다.⁶ 다만 정책으로 다시 활성화할 수 있다는 전제도 제시되어 있습니다.

이 순서에는 의미가 있습니다. 「쓸 이유를 없앤 다음 기본값을 바꾼다」는 순서이므로, 지금 자사에 남은 NTLM 의존 가운데 2단계에서 해결을 기대할 수 있는 것(대응하는 Windows끼리의 로컬 계정 인증, DC 도달성)과, 스스로 고쳐야 하는 것(IP 주소 직접 입력, SPN 미등록, 그리고 오래된 Windows나 타사 장비가 상대인 로컬 계정 인증)을 나눠 두면 쓸데없는 작업을 하지 않아도 됩니다. 마지막 것을 「2단계 대기」로 분류해 버리면, 기본 비활성화가 왔을 때 장애로 표면화합니다. 분류의 구체적인 절차는 실무편에 정리했습니다.

10. 정리

• NTLM은 「비밀번호의 해시를 가지고 있다는 것」을 챌린지/응답으로 증명하는 프로토콜입니다. 판정은 도메인 계정이면 도메인 컨트롤러가 대행하고, 로컬 계정이면 서버 자신이 자신의 SAM을 조회해 수행합니다.¹¹⁰
• Kerberos는 「누가, 어느 서비스에 대해」를 증명합니다. 서비스 티켓은 수신처 서비스의 장기 키로 암호화되므로, 수신처를 바꿔 재사용할 수 없습니다.³
• 결정적인 차이는 상호 인증의 유무, 인증할 때마다의 DC 문의, 위임의 가능 여부입니다.⁴
• NTLM으로 떨어지는 것은 거의 「Kerberos를 시작하지 못했을」 때입니다. IP 주소 직접 입력, SPN 미등록, Active Directory 밖, KDC에 닿지 않음, 이 네 가지가 주된 원인입니다.⁵⁶¹¹
• 한편 시각 어긋남처럼 Kerberos가 선택된 뒤에 실패하는 문제는 NTLM으로의 떨어짐이 아니라 인증 오류로 나타납니다. 이벤트 8001을 찾아도 나오지 않습니다.⁷
• 릴레이 공격이 성립하는 것은 NTLM의 응답이 수신처를 묶지 않기 때문입니다. Pass-the-Hash가 성립하는 것은 인증에 필요한 것이 해시 그 자체이기 때문입니다.⁸¹¹³
• NTLMv1은 이미 삭제됨(Windows 11 24H2 / Windows Server 2025), NTLMv2를 포함한 전 버전이 비권장입니다.⁹
• 앱이 써야 할 것은 Negotiate입니다. 그 위에서 접속 대상 이름을 FQDN으로 맞추고 SPN을 등록하는 것이, Kerberos를 성립시키는 실무의 내용이 됩니다.¹⁵

관련 글

• NTLM 사용 중단으로 업무 앱이 멈출까 ── 감사 로그를 모으는 방법과, 의존을 없애는 순서
• 네트워크 드라이브와 UNC 경로의 함정 ── 업무 앱에서 파일 서버(공유 폴더)를 다루는 실무
• Windows의 시각 동기화(w32time) 가이드
• Get-WinEvent로 이벤트 로그를 실무에서 조사하기 ── 필터링 속도가 조사 시간을 가른다
• PowerShell에서 자격 정보를 안전하게 다루기 ── 스크립트에서 평문 비밀번호를 없애기
• Windows의 TPM이란 무엇인가 ── 그림으로 보는 「키를 밖으로 내보내지 않는 금고」와 측정 부팅
• 정보보안 10대 위협 2026 ── 순위를 읽는 법과, 중소기업이 실제로 대비해야 할 것

관련 상담 영역

合同会社小村ソフト에서는 인증 방식 재검토에 따른 Windows 업무 앱 수정과, Kerberos/NTLM 주변 인증 문제의 원인 조사를 다룹니다.

• Windows 앱 개발
• 결함 조사·원인 분석
• 기존 자산 활용·이전 지원
• 문의

참고 링크

관련 기사

같은 태그를 공유하는 최신 기사입니다. 더 가까운 주제로 지식을 넓힐 수 있습니다.

관련 토픽

이 기사와 가까운 토픽 페이지입니다. 기사를 출발점 삼아 관련 서비스와 다른 기사로 이어집니다.

이 주제와 연결되는 서비스

이 기사는 다음 서비스 페이지로 이어집니다. 가까운 입구부터 확인해 주세요.

자주 묻는 질문

이 기사 주제에 대해 상담 시 자주 나오는 질문을 모았습니다.

NTLM과 Kerberos는 결국 무엇이 다른가요?

가장 큰 차이는 「상대를 확인할 수 있는가」입니다. 마이크로소프트는 NTLM에서는 클라이언트가 서버의 신원을 검증할 수도, 어떤 서버가 다른 서버의 신원을 검증할 수도 없다고 명시하고 있습니다. NTLM은 「서버는 진짜다」라고 가정할 수 있는 환경을 위해 설계된 것이고, Kerberos는 그런 가정을 두지 않습니다. 두 번째 차이는 서버가 도메인 컨트롤러에 문의해야 하는지 여부입니다. NTLM에서는 도메인 계정으로 인증하는 경우, 애플리케이션 서버는 클라이언트를 인증할 때마다 도메인 컨트롤러에 접속합니다(서버에 로컬인 계정이라면 서버가 자신의 계정 데이터베이스를 조회해 스스로 판정하므로 도메인 컨트롤러는 등장하지 않습니다). Kerberos에서는 갱신 가능한 세션 티켓이 이 패스스루 인증을 대체하기 때문에, 서버는 PAC 검증이 필요한 경우를 제외하면 도메인 컨트롤러로 가지 않습니다. 세 번째는 Kerberos가 서비스에 의한 위임(클라이언트를 대신해 다른 서비스에 접속하는 구조)을 지원한다는 점입니다.

Kerberos를 지원할 텐데 왜 NTLM이 되어 버리나요?

Kerberos는 「접속 대상의 이름」을 키로 삼아 티켓을 발급하는 구조이므로, 이름을 찾을 수 없으면 성립하지 않습니다. 클라이언트는 접속 대상의 SPN(서비스 주체 이름)을 KDC에 제시해 서비스 티켓을 요청하는데, 기본값에서는 호스트 이름이 IP 주소인 경우 Windows는 Kerberos 인증을 시도하지 않으며, 서비스 계정에 SPN이 등록되어 있지 않으면 KDC는 티켓을 발급할 수 없습니다. 마이크로소프트의 감사 가이드에도 이벤트 8001의 「대상 서버」가 NetBIOS 이름도 FQDN 형식도 아니면 Kerberos는 사용되지 않는다고 나와 있습니다(IP 주소의 경우, 클라이언트에 TryIPSPN을 설정하고 IP 주소의 SPN을 수동으로 등록하면 예외적으로 Kerberos를 성립시킬 수 있지만, DNS 이름으로 바꿀 수 없을 때의 최후 수단으로 여겨집니다). 그 밖에 워크그룹 컴퓨터나 로컬 계정으로의 인증(애초에 Active Directory 바깥), 도메인 컨트롤러에 도달할 수 없는 거점, 신뢰 관계가 없는 상대에 대한 인증도 Kerberos가 성립하지 않는 조건입니다. Negotiate는 Kerberos를 쓸 수 없을 때 NTLM을 선택하므로, 이런 경우에 「떨어지게」 됩니다.

NTLM 릴레이 공격이란 무엇인가요? 왜 성립하나요?

공격자가 자신의 서버로 피해자를 유도하고, 거기 도착한 NTLM 인증 교환을 그대로 진짜 서버로 중계해 피해자로 위장하는 공격입니다. 성립하는 이유는 NTLM의 챌린지/응답에 「누구에 대해 인증하고 있는지」를 묶어 두는 구조가 없기 때문입니다. 클라이언트는 서버가 낸 챌린지를 바탕으로 응답을 계산해 돌려줄 뿐이고, 그 응답이 진짜 서버 앞으로 가는 것인지 공격자가 중계한 것인지를 클라이언트 쪽에서 확인할 수단이 없습니다. 마이크로소프트 스스로도 NTLM 및 NTLMv2 인증이 SMB 릴레이, 중간자 공격, 무차별 대입 공격을 포함한 다양한 악의적 공격에 취약하다고 정책 설정 문서에 명시하고 있습니다. 다만 어떤 상대에게든 중계가 통하는 것은 아닙니다. 접속 대상이 SMB 서명을 요구한다면 서명이 송신자와 수신자의 신원을 확인하기 때문에 릴레이는 성립하지 않고, Extended Protection for Authentication(채널 바인딩)을 강제하는 서비스에서도 마찬가지입니다. 뒤집어 말하면, 서명도 channel binding도 걸려 있지 않고 NTLM을 받아들이는 상대가 표적이 됩니다. Kerberos에서는 서비스 티켓이 해당 서비스의 장기 키로 암호화되어 있어, 수신처가 다른 티켓을 다른 서비스로 가져가도 복호화할 수 없습니다.

Pass-the-Hash는 비밀번호를 해독하지 않아도 위장할 수 있다는 뜻인가요?

그렇습니다. NTLM의 자격 증명은 도메인 이름과 사용자 이름, 그리고 비밀번호의 일방향 해시로 구성됩니다. 지금의 Windows가 사용하는 NTLMv2에서는 응답 키가 비밀번호의 MD4 해시(NT 해시)를 키로 하는 HMAC으로 도출되고, 그 키로 서버의 챌린지·시각·클라이언트 쪽 챌린지·타깃 정보를 합친 것에 대한 HMAC을 계산합니다. 단순히 챌린지를 암호화하는 것만은 아니지만, 출발점이 비밀번호의 해시라는 점은 변하지 않습니다. 즉 인증에 필요한 것은 해시이지 평문 비밀번호가 아닙니다. 따라서 단말기의 메모리 등에서 해시를 빼낼 수 있었던 공격자는 비밀번호를 해독하지 않고도 그 사용자로 인증할 수 있게 됩니다. 비밀번호를 길고 복잡하게 해도 이 경로는 막히지 않습니다. 마이크로소프트가 SMB 클라이언트 쪽의 NTLM 차단 기능을 마련한 이유 중 하나로도 Pass-the-Hash 공격에 대한 대응이 꼽힙니다.

NTLMv2를 쓰고 있으면 당분간은 안전한가요?

NTLMv2는 NTLMv1보다 강력하긴 하지만, 비권장 대상에서 벗어나 있지는 않습니다. 마이크로소프트의 비권장 기능 목록은 LANMAN, NTLMv1, NTLMv2를 포함한 모든 버전의 NTLM이 적극적인 기능 개발 대상에서 제외되어 있으며 비권장이라고 밝히고 있습니다. 제한 정책의 동작도 마찬가지로, 감사 및 차단 정책은 두 버전에 대해 동일한 효과를 갖는다고 설명되어 있습니다. 한편 NTLMv1에 대해서는 취급이 다른데, 비권장이 아니라 삭제 단계에 들어가 있어 Windows 11 버전 24H2 및 Windows Server 2025부터는 삭제되었습니다. 따라서 「NTLMv2니까 당분간 방치해도 된다」가 아니라 「NTLMv1은 지금 당장 기한, NTLMv2는 기본 비활성화를 향해 정리를 진행한다」는 정리가 됩니다.

저자 프로필

기사 저자의 프로필 페이지입니다.

Go Komura

합동회사 코무라소프트 대표

Windows 소프트웨어 개발, 기술 상담, 장애 조사를 중심으로 재현이 어려운 장애 조사와 기존 자산이 남아 있는 프로젝트에 강점이 있습니다.