그림으로 이해하는 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를 선택합니다.¹

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바이트 난수(챌린지, 논스)를 생성해 클라이언트에 보낸다.
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["UNICODE화된 비밀번호를 MD4 해시화<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. 로컬 계정이라면 2자로 완결된다

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

이 차이는 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) 같은 종류가 있으며, 프런트엔드 웹 앱에서 백엔드 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대 요인을 조건·이유·해결법 세 열로 먼저 정리해 둡니다. 상세는 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로 충분하지만, 웹이라면 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: 서명도 채널 바인딩도<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 앱 개발
• 불량 조사·원인 분석
• 기존 자산 활용·이전 지원
• 문의하기

참고 링크

</content>

관련 기사

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

관련 토픽

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

이 주제와 연결되는 서비스

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

자주 묻는 질문

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

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(채널 바인딩)을 강제하는 서비스에서도 마찬가지입니다. 뒤집어 말하면, 서명도 채널 바인딩도 걸려 있지 않고 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 소프트웨어 개발, 기술 상담, 장애 조사를 중심으로 재현이 어려운 장애 조사와 기존 자산이 남아 있는 프로젝트에 강점이 있습니다.