NTLM 폐지로 업무 앱이 멈추는가 ── 감사 로그를 얻는 방법과 의존을 없애는 순서

“NTLM이 폐지된다고 하던데, 우리 회사는 괜찮을까”──2024년 6월에 마이크로소프트가 NTLM의 모든 버전을 비권장(deprecated)으로 발표한 이후, 이런 질문을 받는 일이 늘었습니다. 답은, 괜찮은지 여부는 조사하면 알 수 있고, 지금 조사하면 늦지 않습니다.

NTLM의 폐지는 “어느 날 패치가 적용되어 전사가 멈추는” 종류의 변경이 아닙니다. OS를 새롭게 할 때마다 조금씩 좁혀지는 변경이며, 게다가 아직 NTLM이 동작하고 있는 지금만, “자사의 어디가 NTLM에 의존하고 있는지”를 안전하게 목록화할 수 있습니다. 전부 멈춘 뒤에 고장난 곳을 찾는 것은 가장 해서는 안 될 순서입니다.

이 글은 그 목록을 만들어 없애 나가기 위한 실무 절차에 초점을 맞춥니다. 프로토콜의 구조 그 자체(왜 NTLM이 위험한지, 왜 Kerberos로 떨어지지 않는지)는 짝을 이루는 글 “그림으로 이해하는 NTLM과 Kerberos ── 왜 인증은 NTLM으로 “떨어지는”가“로 나누었습니다.

1. 먼저 결론

• NTLM은 2024년 6월에 비권장이 되었습니다. 대상은 LANMAN·NTLMv1·NTLMv2를 포함한 모든 버전이며, “더 이상 적극적인 기능 개발은 하지 않는다”는 선언입니다. 동시에 “차기 Windows Server와 다음 연차 릴리스의 Windows에서도 NTLM 사용은 계속 동작한다”고도 적혀 있습니다.¹
• 이미 제거된 부분이 있습니다. NTLMv1은 Windows 11 버전 24H2와 Windows Server 2025에서 제거되었습니다.¹
• 폐지는 3단계로 진행됩니다. 1단계가 이용 현황 가시화와 감사, 2단계(2026년 하반기)가 NTLM에 의존할 수밖에 없는 상황을 없애기 위한 기능(IAKerb, 로컬 KDC), 3단계가 차기 주요 릴리스에서의 네트워크 NTLM 인증 기본 비활성화입니다.²
• 지금 해야 할 일은 하나뿐입니다. 감사 모드를 돌려 “어느 단말의, 어느 앱이, 어느 서버에 대해” NTLM을 사용하고 있는지 목록을 만드는 것입니다(4장).
• 도메인 계정 조사는 도메인 컨트롤러에서 시작합니다. 이벤트 8004 → 멤버 서버의 8003 → 클라이언트의 8001 순서로 따라가면 마지막에 앱 이름까지 도달합니다(4.2절). 다만 로컬 계정으로의 인증은 도메인 컨트롤러를 거치지 않으므로 8004가 발생하지 않습니다. 이 경로는 서버 측 8003과 클라이언트 측 8001에서 수집합니다.³
• 원인의 대부분은 “이름”입니다. IP 주소 직접 지정과 SPN 미등록이 두 가지 큰 요인이며, 둘 다 앱을 다시 만들지 않고도 고칠 수 있습니다(5장).³²
• 1대만으로 안전하게 시험하는 방법이 있습니다. Windows 11 24H2 / Windows Server 2025라면 NET USE \\server\share /BLOCKNTLM으로 정책을 전혀 바꾸지 않고 “NTLM 없이 연결되는지”를 확인할 수 있습니다(7장).⁴
• 자체 개발 앱은 NTLM을 명시한 부분을 Negotiate로 바꿉니다. 마이크로소프트 자신이 “NTLM 보안 패키지에 직접 접근하지 말라”고 적고 있습니다(8장).⁵

2. “비권장”은 무엇을 의미하는가

먼저 용어를 정리해 둡니다. 여기를 애매하게 둔 채 사내에 설명하면 “이제 못 쓴다더라”와 “아직 몇 년은 괜찮다더라”가 동시에 퍼져 이야기가 혼란스러워집니다.

마이크로소프트의 비권장 기능 목록에 실린 NTLM 관련 기술을 요약하면 다음 3가지입니다.¹

1. LANMAN, NTLMv1, NTLMv2를 포함한 모든 버전의 NTLM이 적극적인 기능 개발 대상에서 제외되어 있으며 비권장입니다.
2. NTLM 사용은 차기 Windows Server와 다음 연차 릴리스의 Windows에서도 계속 동작합니다.
3. NTLM 호출은 Negotiate 호출로 대체해야 합니다. Negotiate는 Kerberos로 인증을 시도하고, 필요할 때만 NTLM으로 폴백합니다.

그리고 업데이트 정보로서 NTLMv1은 Windows 11 버전 24H2 및 Windows Server 2025에서 제거되었다는 점이 추가되어 있습니다.¹

즉 현재 상태는 “비권장(deprecated)”이며 “제거(removed)”가 아닙니다. 다만 NTLMv1만은 비권장을 지나 이미 제거 단계에 들어갔습니다. 오래된 복합기나 NAS가 NTLMv1로만 인증할 수 있는 경우, Windows 11 24H2로의 업데이트가 그대로 장애가 됩니다. 이는 미래의 이야기가 아니라 지금 일어나고 있는 이야기입니다.

또 하나 짚어 두어야 할 것은, NTLM에는 “대체가 존재하지 않는 용도”가 남아 있다는 점입니다. 마이크로소프트는 워크그룹 구성의 시스템에서의 Windows 인증과, 도메인 컨트롤러 이외에서의 로컬 로그온 인증에는 여전히 NTLM이 사용되고 있으며 사용되어야 한다고 명시하고 있습니다.⁶ 2단계에서 예정된 로컬 KDC는 바로 이 “로컬 계정을 위해 NTLM이 필요하다”는 구멍을 메우기 위한 기능입니다.²

2.1. 3단계의 현재 상황

폐지 로드맵은 3단계입니다. 시점에 의존하는 정보이므로 기준일을 함께 정리합니다(아래 표는 2026년 7월 시점의 상황입니다).

이 표에서 확인해야 할 것은 지금 자신의 손으로 움직일 수 있는 것은 1단계뿐이라는 점입니다. 2단계의 기능은 6장의 판단표에서 “해결책이 될 수 있다”고 적은 부분이 있지만, 어느 쪽이든 제공 상황 확인이 전제입니다. 제공 시기는 바뀔 수 있으므로, 이 표의 내용은 자사가 판단하는 시점에 반드시 다시 확인하세요.

3. 왜 사라지는가 ── 3분만

이행 판단 자료로서 최소한만 짚습니다. 자세한 그림 설명은 짝을 이루는 글에 맡깁니다.

마이크로소프트는 정책 설정 문서에서 NTLM 및 NTLMv2 인증은 SMB 릴레이, 중간자 공격, 무차별 대입 공격을 포함한 다양한 악의적 공격에 취약하다고 명확히 적고 있습니다.⁷ 근본에 있는 것은 Kerberos와 비교해 이야기되는 다음 성질입니다.⁸

• 상호 인증이 없습니다. NTLM에서는 클라이언트가 서버의 신원을 검증하는 것도, 서버가 다른 서버의 신원을 검증하는 것도 불가능합니다. NTLM은 “서버는 진짜다”라고 가정할 수 있는 네트워크 환경을 위해 설계된 것입니다. Kerberos는 그 가정을 두지 않습니다. 이 차이가 가짜 서버에 인증 정보를 보내게 만드는 릴레이 공격의 성립 조건이 됩니다.
• 서버가 매번 도메인 컨트롤러에 문의합니다(도메인 계정의 경우). NTLM에서는 애플리케이션 서버가 도메인 계정 클라이언트를 인증할 때마다 도메인 컨트롤러에 접속해야 합니다(서버에 로컬인 계정이라면 서버가 자신의 계정 데이터베이스를 참조해 판정합니다).⁶ Kerberos에서는 갱신 가능한 세션 티켓이 이 통과 인증을 대체하며, 서버는 PAC(권한 속성 인증서) 검증이 필요한 경우를 제외하고는 도메인 컨트롤러에 갈 필요가 없습니다.
• 인증 자료가 비밀번호 해시 그 자체입니다. NTLM 자격 증명은 도메인 이름·사용자 이름·비밀번호의 단방향 해시로 구성되며, 클라이언트는 이 해시로 챌린지를 암호화해 응답을 반환합니다.⁵ 해시를 훔치면 평문 비밀번호를 몰라도 위장할 수 있다는 성질이 여기서 나옵니다.

“상호 인증이 없다”의 실무적 의미는, SMB 공유에 연결하려고 했을 뿐인데 가짜 서버에 인증 정보를 넘겨줄 수 있다는 것입니다. 마이크로소프트가 SMB 클라이언트 측 NTLM 차단 기능을 마련한 이유도 “악의적인 서버에 NTLM 요청을 보내게 하는 수법을 막기 위해서”라고 설명되어 있습니다.⁴

4. 감사 ── 어디에서 NTLM이 사용되고 있는지 목록화하기

여기가 본론입니다. 마이크로소프트 가이드도 제한 정책을 구현하기 전에 현재의 NTLM 인증 트래픽 상태를 발견하고 감사하는 것이 필요하다고 명시하고 있습니다.⁹

4.1. 감사 모드 활성화하기

설정할 것은 3가지 정책입니다. 위치는 모두 컴퓨터 구성\Windows 설정\보안 설정\로컬 정책\보안 옵션이며, 재시작은 필요하지 않습니다. 로컬에 저장한 경우도, 그룹 정책으로 배포한 경우도 설정이 적용된 시점에 활성화됩니다.⁷

다만 “재시작이 필요 없다”와 “즉시 전체 단말에 적용된다”는 별개입니다. 도메인 GPO로 배포하는 경우, GPO를 저장한 시점에 갱신되는 것은 AD/SYSVOL상의 정책뿐이며, 각 단말이 실제로 감사를 시작하는 것은 다음 백그라운드 갱신이나 gpupdate /force를 실행한 이후입니다. 감사 기간의 시작점은 “GPO를 저장한 일시”가 아니라 “대상 단말에 적용이 완료된 일시”로 계산하세요. 이 부분을 착각하면 첫 집계만 대상 단말 수가 적게 나오는 형태로 결과가 왜곡됩니다.

세 번째인 “원격 서버로의 송신 NTLM 트래픽”에는 모두 허용 / 모두 감사 / 모두 거부 / 정의되지 않음이라는 4가지 값이 있으며, 정의되지 않음은 “모두 허용”과 같은 취급입니다. 마이크로소프트의 권장 사항도 명확해서, 갑자기 “모두 거부”를 선택하지 말고 먼저 “모두 감사”로 설정해 운영 로그를 확인하고, 어느 서버가 인증 요청을 받고 있는지 파악한 뒤에 예외 목록을 만들라는 것입니다.⁷

기록 위치는 이벤트 뷰어 > 애플리케이션 및 서비스 로그 > Microsoft > Windows > NTLM(Microsoft-Windows-NTLM/Operational)입니다. 이 감사에는 대응하는 보안 감사 이벤트 정책이 존재하지 않으므로 보안 로그가 아닌 이 채널을 봅니다.⁷

현장에서 가장 헷갈리기 쉬운 것이 “어느 머신에, 어느 정책을 넣고, 어느 이벤트를 보는가”의 대응 관계입니다. 위 표의 3가지 정책을 ①②③이라 하고 체크리스트로 만들었습니다.

로그는 어느 머신에서든 동일한 Microsoft-Windows-NTLM/Operational입니다. ①은 도메인 컨트롤러에만 적용되며, ②③을 빠뜨린 단말은 “NTLM을 사용하지 않는 단말”이 아니라 “기록하지 않는 단말”이 됩니다. 이 차이가 집계를 왜곡시키는 가장 큰 원인입니다.

주의: 감사 모드는 기록만 할 뿐 아무것도 차단하지 않습니다. 한편 대수가 많은 환경에서는 로그양이 단숨에 늘어납니다. 이벤트 수집(WEF)을 사용하지 않는 경우, 로그 크기 상한과 보존 기간을 먼저 재검토한 후 활성화하세요. 마이크로소프트 가이드도 환경의 복잡성에 따라 분석에 몇 개월이 걸릴 수 있다고 밝히고 있습니다.³

4.2. 추적은 “도메인 컨트롤러에서 하류로”

수집된 이벤트를 어떻게 읽을지에는 정해진 순서가 있습니다. 마이크로소프트 가이드가 제시하는 추적 경로는 다음과 같습니다.³

flowchart TD
    DC["도메인 컨트롤러<br/>이벤트 8004"]
    MS["멤버 서버<br/>이벤트 8003"]
    CL["클라이언트<br/>이벤트 8001"]
    APP["원인 애플리케이션"]

    DC -->|"보안 채널 이름 =<br/>조사할 서버"| MS
    MS -->|"워크스테이션 이름 =<br/>조사할 클라이언트"| CL
    CL -->|"클라이언트 프로세스 이름"| APP
    MS -.->|"PID가 4(SYSTEM)라면<br/>SMB 경유"| CL

그림 1: NTLM 감사 이벤트 추적 순서

각 이벤트에서 확인해야 할 항목은 다음과 같습니다.³

이 경로에서 특히 가치가 있는 것은 8001의 “대상 서버”와 “클라이언트 프로세스 이름”입니다. 전자는 “왜 Kerberos가 되지 않았는가”를, 후자는 “누가 원인인가”를 직접 알려줍니다. 마이크로소프트 가이드도 이 정보로 사용자가 웹 서버의 IP 주소에 접속하고 있어 Kerberos를 사용할 수 있었을 NetBIOS 이름이나 FQDN을 사용하지 않고 있다는 사실을 특정할 수 있다고 설명하고 있습니다.³

또한 도메인 컨트롤러에 8004가 발생하지 않는 경우도 있습니다. 로컬 사용자 계정으로 파일 서버에 접속하는 경우, 그 인증은 도메인 컨트롤러를 거치지 않기 때문입니다.³ “DC 로그를 봤더니 적었으니 괜찮다”고 판단해서는 안 됩니다.

4.3. PowerShell로 집계하기

이벤트 뷰어 GUI로 수천 건을 보는 것은 현실적이지 않으므로 Get-WinEvent로 정리합니다. 먼저 그 머신에 어떤 이벤트가 몇 건 발생했는지 확인합니다.

# NTLM/Operational 이벤트를 ID별로 집계한다(관리자 권한으로 실행)
Get-WinEvent -FilterHashtable @{
    LogName   = 'Microsoft-Windows-NTLM/Operational'
    StartTime = (Get-Date).AddDays(-7)
} -ErrorAction SilentlyContinue |
    Group-Object Id |
    Sort-Object Count -Descending |
    Select-Object Count, @{ N = 'EventId'; E = { $_.Name } }

이벤트가 발생하고 있음을 확인했다면, 클라이언트 측의 8001을 “접속 대상 서버 × 호출한 프로세스”로 묶습니다. 이벤트의 필드 구성은 이벤트 ID마다 다르므로 먼저 1건을 Format-List로 열어 구조를 확인한 후에 인덱스를 정하는 것이 안전합니다.

# 먼저 1건만 내용을 확인한다
$sample = Get-WinEvent -FilterHashtable @{
    LogName = 'Microsoft-Windows-NTLM/Operational'
    Id      = 8001
} -MaxEvents 1

$sample | Format-List TimeCreated, Id, Message
# 구조화된 필드를 볼 경우
([xml]$sample.ToXml()).Event.EventData.Data |
    Select-Object Name, '#text'

구조를 알았다면 XML의 Name 속성으로 값을 꺼내 집계합니다. 속성 이름은 OS 버전에 따라 차이가 있으므로 이름으로 조회하는 편이 위치 지정보다 덜 깨집니다.

# 최근 7일간의 8001을 "접속 대상 × 호출한 프로세스"로 집계한다
$events = Get-WinEvent -FilterHashtable @{
    LogName   = 'Microsoft-Windows-NTLM/Operational'
    Id        = 8001
    StartTime = (Get-Date).AddDays(-7)
} -ErrorAction SilentlyContinue

$rows = foreach ($e in $events) {
    $data = @{}
    foreach ($d in ([xml]$e.ToXml()).Event.EventData.Data) {
        $data[$d.Name] = $d.'#text'
    }
    [pscustomobject]@{
        Time    = $e.TimeCreated
        # 실제로 존재한 필드 이름만 우선순위를 정해 가져온다
        Target  = @('TargetName', 'TargetServer', 'ServerName') |
                  Where-Object { $data.ContainsKey($_) } |
                  ForEach-Object { $data[$_] } | Select-Object -First 1
        Process = @('ClientProcessName', 'ProcessName', 'ApplicationName') |
                  Where-Object { $data.ContainsKey($_) } |
                  ForEach-Object { $data[$_] } | Select-Object -First 1
    }
}

$rows | Group-Object Target, Process |
    Sort-Object Count -Descending |
    Select-Object Count, Name

마지막 집계는 Count(건수)와 Name(접속 대상, 호출한 프로세스를 쉼표로 연결한 것) 2개 열로 반환됩니다. 즉 출력은 이런 형태입니다(값은 설명을 위한 예시입니다).

Count Name
----- ----
  412 192.168.1.10, System
  118 fileserver.corp.example.com, System
   57 192.168.1.24, MyBizApp.exe
    9 legacy-nas, System

봐야 할 것은 Name의 앞부분, 즉 접속 대상입니다. 행마다 읽는 방법은 다음과 같습니다.

건수의 절대값 자체에는 그다지 의미가 없습니다. “IP 주소 대상 행이 상위에 오는가”, “실행 파일 이름까지 특정된 행이 몇 개인가” 이 2가지를 보세요. 전자는 고치면 확실히 줄어드는 의존이며, 후자는 담당자를 배정할 수 있는 의존입니다.

필드 이름은 OS 버전에 따라 차이가 있으므로 후보를 우선순위가 있는 배열로 나열하고, 실제로 존재하는 것만 가져오는 형태로 되어 있습니다. 여기서 -match 'Process'와 같은 부분 일치를 사용하면 ClientProcessId와 같은 PID 필드까지 걸려서 실행 파일 이름이 아니라 매번 바뀌는 PID로 집계해 버리는 일이 있습니다(해시 테이블의 키 순서는 정해져 있지 않으므로 어느 쪽이 잡힐지도 일정하지 않습니다). Process 열이 전부 비게 되면 후보 이름이 실제 스키마와 맞지 않는다는 신호이므로 앞 단계에서 확인한 이름을 배열에 추가하세요.

여러 대에서 수집한다면 PowerShell Remoting으로 병렬로 돌리는 것이 빠릅니다(“PowerShell Remoting(WinRM) 입문”). Get-WinEvent의 필터링은 -FilterHashtable을 쓰는지 여부에 따라 소요 시간이 크게 달라지므로, 그 요령은 “Get-WinEvent로 이벤트 로그를 실무적으로 조사하기“에 정리해 두었습니다.

4.4. 보안 로그 쪽에서 보기 ── NTLMv1이 아직 사용되고 있지 않은가

NTLM/Operational과는 별도로 보안 로그의 로그온 이벤트에서 NTLM 버전을 확인하는 방법도 있습니다. 절차는 보안 로그에서 “인증 패키지”를 검색하고 각 이벤트의 “자세한 인증 정보”를 보는 것입니다.³

자세한 인증 정보:
    로그온 프로세스:            NtLmSsp
    인증 패키지:                NTLM
    전송된 서비스:              -
    패키지 이름(NTLM만 해당):   NTLM V1
    키 길이:                    128

이 “패키지 이름(NTLM만 해당)”이 NTLM 프로토콜군 중 어느 하위 프로토콜이 사용되었는지를 나타냅니다.³ NTLM V1이 나오는 호스트는 그대로 Windows 11 24H2 / Windows Server 2025로 올리면 인증이 통하지 않게 될 후보입니다. NTLMv1은 이 버전들에서 제거되었기 때문입니다.¹ 감사를 돌릴 때 이 관점만은 우선순위를 높여 수집하세요.

4.5. PID가 4(SYSTEM)뿐이라 진행할 수 없을 때

감사를 시작하면 거의 반드시 이 벽에 부딪힙니다. SMB(공유 폴더)처럼 리디렉터를 경유해 통신하는 앱에서는 인증을 요청하는 주체가 커널 모드 리디렉터가 되므로 이벤트에 남는 PID는 항상 4(SYSTEM)가 됩니다.³

마이크로소프트 가이드가 제시하는 대처법은 다음과 같습니다.³

1. NTLM 자격 증명을 보내는 클라이언트(8001의 “컴퓨터”)에 프로세스 감시 도구를 설치한다.
2. 상대 서버의 컴퓨터 이름과 IP 주소 양쪽으로 경로를 필터링한다. 장시간 수집이 필요하다면 백그라운드 모드로 돌린다.
3. 수집 결과를 서버 측 이벤트 8003의 타임스탬프와 대조한다. 사용자·경로·인증 식별자가 대응하므로 여기서 호출한 애플리케이션을 특정할 수 있다.

도구는 Process Monitor(ProcMon)입니다. 필터 거는 방법과 읽는 방법은 “Process Monitor(ProcMon) 실전 가이드“에 정리해 두었습니다.

실무 요령을 하나 덧붙이면, 이 단계까지 이벤트 로그만으로 “어느 단말인지”를 완전히 좁힌 다음, 그 단말 1대에만 ProcMon을 거는 것이 압도적으로 빠릅니다. 전체 단말에 ProcMon을 배포하는 것은 현실적이지 않습니다.

5. NTLM으로 떨어지는 전형적인 패턴

감사로 위치를 알아냈다면 다음은 원인 분류입니다. 마이크로소프트 가이드는 이론상 Kerberos를 지원하면서도 NTLM을 사용해 버리는 애플리케이션으로 다음 4가지를 들고 있습니다.³

• 다양한 보안 구성이나 공급자를 선택할 수 있는 애플리케이션
• SPN(서비스 사용자 이름)이 올바르게 구성되어 있지 않은 애플리케이션
• 설정 오류나 공급업체 문서 때문에 DNS 이름이 아닌 IP 주소를 사용하는 애플리케이션
• 레거시 코드베이스를 가지고 있어 NTLM 전용 부분이 남아 있는 애플리케이션

마이크로소프트 재팬 지원 블로그는 NTLM이 사용되는 대표적인 원인으로 IP 주소 지정에 의한 서버 접근, Kerberos에 필요한 포트가 방화벽으로 제한된 경우, SPN 미등록, 신뢰 관계 대상에 대한 인증, 워크그룹 환경에서의 인증을 들고 있습니다.²

이를 현장에서 만나는 형태로 정리하면 다음 표가 됩니다. 오른쪽 2개 열은 우선순위를 정하기 위한 기준입니다. “영향 범위”는 멈췄을 때 곤란한 범위를, “수정 용이성”은 자사 판단만으로 고칠 수 있는지를 나타냅니다. 이 2가지를 알면 그대로 계획서의 착수 순서가 됩니다.

착수 순서는 이 2개 열로부터 기계적으로 정해집니다.

1. 영향 범위와 관계없이 최우선인 것은 NTLMv1밖에 못 쓰는 장치와 NTLM V1이 기록된 호스트입니다(4.4절). 여기만은 “기한이 이미 왔기” 때문에 우선순위 계산 밖에 둡니다.¹
2. 다음이 영향 범위=큼 그리고 수정 용이성=높음, 즉 IP 주소 직접 지정입니다. 건수가 많고 자사 판단만으로 고칠 수 있습니다. 첫 한 달은 여기에 집중하세요.
3. 그다음이 수정 용이성=중인 SPN 관련. 이름 통일과 세트로 진행합니다.
4. 수정 용이성=낮음인 것(장치 의존, 경로, 2단계 대기)은 착수가 늦어지는 것이 아니라 리드 타임이 길 뿐이므로 공급업체 문의와 예산 확보만은 1~3과 병행해 먼저 시작합니다.

“바로 고칠 수 있음“과 “SPN 등록으로 해결“로 분류된 것이 감사 결과의 대부분을 차지할 것입니다. 여기를 없애는 것만으로 남는 예외는 상당히 줄어듭니다.

6. 고치는 방법 판단표

7. SMB의 NTLM 차단 ── 실제 확인의 지름길

감사 로그는 “사용되고 있다”는 것은 알려주지만 “멈추면 어떻게 되는지”는 알려주지 않습니다. 여기서 도움이 되는 것이 Windows Server 2025와 Windows 11 버전 24H2에서 추가된 SMB 클라이언트 측 NTLM 차단입니다.⁴

이 기능은 SMB 클라이언트가 원격으로의 송신 접속에서 NTLM 인증을 사용하는 것을 차단합니다. 마이크로소프트는 이로 인해 악의적인 서버로 NTLM 요청을 보내게 하는 수법을 막고 무차별 대입·크래킹·Pass-the-Hash 공격에 대항할 수 있다고 하며, 나아가 조직의 인증 프로토콜을 Kerberos로 전환하는 데 NTLM 차단이 필요하다고 자리매김하고 있습니다. 동시에 NTLM을 완전히 비활성화하지 않고도 이 보호 계층만 활성화할 수 있다고도 적혀 있습니다.⁴

전제 조건은 다음 2가지입니다.⁴

• SMB 클라이언트가 Windows Server 2025 이상 또는 Windows 11 버전 24H2 이상일 것
• 접속 대상 SMB 서버가 Kerberos를 사용할 수 있을 것(SMB 서버 측 OS는 PKU2U나 Kerberos를 사용할 수 있는 것이면 무엇이든 상관없음)

7.1. 먼저 1대·1개 연결만으로 시험하기

갑자기 정책을 배포하는 것이 아니라 연결 단위로 차단을 지정할 수 있다는 점을 활용합니다. 이것이 실제 확인의 지름길입니다.

# 그 연결만 NTLM을 금지하고 연결해 본다(연결되면 그 공유는 NTLM 없이도 충분함)
NET USE \\fileserver.corp.example.com\share /BLOCKNTLM

# PowerShell 매핑으로도 같은 것을 할 수 있다
New-SmbMapping -RemotePath \\fileserver.corp.example.com\share -BlockNTLM $true

연결되면 그 경로는 NTLM 없이 성립한다는 뜻입니다. 실패하면 그곳이 NTLM 의존 지점입니다. 정책을 전혀 바꾸지 않고 1개 연결씩 “실제 환경에서 멈추는지”를 확인할 수 있으므로 감사 로그를 뒷받침하는 데 적합합니다.

결과 확인처는 3곳입니다. (1) 연결의 성공 여부는 명령 결과 그 자체로, 성공하면 매핑이 만들어져 net use 목록과 Get-SmbConnection -ServerName <서버 이름>에 나타나고, 실패하면 오류로 끝나 매핑은 남지 않습니다. (2) 정말로 NTLM이 원인인지는 아래 절차 3(플래그 없이 연결)과 짝지어 판단합니다. 플래그 없이도 실패한다면 다른 문제입니다. (3) 무엇으로 인증했는지까지 확정하고 싶다면 이 절 마지막에서 설명하는 방법(klist와 서버 측 보안 로그)을 사용하세요. 오류 메시지 문구만으로 NTLM 의존이라고 단정하지 마세요.

다만 이 확인에는 절차가 필요합니다. 아무 생각 없이 실행하면 양쪽 방향으로 오판합니다.

$server = 'fileserver.corp.example.com'

# 1. 그 서버로의 매핑을 "하나도 남김없이" 해제한다
#    다른 공유가 하나라도 남아 있으면 서버 단위 세션이 계속 살아 있는다
net use | Select-String $server              # 먼저 무엇이 연결되어 있는지 본다
net use \\$server\share  /delete
net use \\$server\other  /delete             # 같은 서버의 다른 공유도 모두

# 2. 세션이 정말로 사라졌는지 확인한다(비어질 때까지 다음으로 진행하지 않는다)
Get-SmbConnection -ServerName $server

# 3. 먼저 플래그 없이 연결되는지 확인한다(여기서 실패하면 NTLM 이외의 문제)
net use \\$server\share
net use \\$server\share /delete
Get-SmbConnection -ServerName $server        # 여기서도 비운 상태로 되돌린다

# 4. 그런 다음 /BLOCKNTLM을 붙여 시도한다
net use \\$server\share /BLOCKNTLM

• 절차 1~2가 필요한 이유: SMB 세션은 공유 단위가 아니라 서버 단위입니다. 그 서버로의 인증된 세션이 남아 있으면 리디렉터는 인증을 다시 하지 않고 이를 재사용합니다. /BLOCKNTLM이 효과를 발휘하는 것은 그 매핑을 위해 이루어지는 인증뿐이며, 이미 확립된 세션(NTLM으로 맺어졌을 수도 있는 것)을 거슬러 검증하지는 않습니다. 즉 테스트 대상 공유만 /delete 하는 것으로는 불충분합니다. 같은 서버의 다른 공유가 연결된 채로 있으면 NTLM 의존이 있는데도 성공해 버립니다. Get-SmbConnection이 아무것도 반환하지 않는 상태까지 낮추세요. 자신의 매핑 이외에도 상주 앱이나 백업 작업이 세션을 잡고 있는 경우가 있습니다. 확실하게 하려면 그 서버에 한 번도 연결한 적 없는 단말에서 시도하는 것이 가장 빠릅니다.
• 절차 3이 필요한 이유: 이름 해석 실패, 자격 증명 오류, 공유 자체에 대한 접근 권한 부족으로도 /BLOCKNTLM 붙은 실행은 실패합니다. 플래그 없이도 실패한다면 그것은 NTLM 의존이 아니라 다른 문제입니다.

여기서 말할 수 있는 것은 “NTLM이 필요하지 않았다”까지이며 “Kerberos로 인증되었다”까지는 말할 수 없다는 점에 주의하세요. 이 기능의 전제 조건은 “Kerberos를 사용할 수 있는 SMB 서버”이지만, 접속 대상은 PKU2U를 사용할 수 있는 OS여도 된다고 되어 있습니다.⁴ 즉 성공한 이유가 Kerberos가 아니라 PKU2U일 가능성이 남습니다. 도메인에 참가한 파일 서버가 상대라면 대체로 문제가 되지 않지만, 실제로 무엇으로 인증했는지까지 확정하고 싶을 때는 연결 후 클라이언트에서 klist를 실행해 해당 서버의 cifs/ 티켓이 취득되어 있는지 보거나, 서버 측 보안 로그에서 로그온 이벤트의 인증 패키지(4.4절)를 확인하세요.

7.2. 단말 단위로 활성화하기

뒷받침이 끝났다면 파일럿 단말에서 단말 전체 차단으로 진행합니다.⁴

# SMB 클라이언트 전체에서 NTLM을 차단한다(관리자 권한)
Set-SmbClientConfiguration -BlockNTLM $true

그룹 정책의 경우 컴퓨터 구성 > 관리 템플릿 > 네트워크 > Lanman 워크스테이션의 “NTLM 차단(LM, NTLM, NTLMv2)”을 활성화합니다.⁴

7.3. 아무래도 남는 상대는 예외 목록으로

도메인에 참가하지 않은 SMB 서버 등, 아무래도 NTLM이 필요한 상대는 예외로 둘 수 있습니다. 그룹 정책의 Lanman 워크스테이션 > NTLM 서버 예외 목록 차단을 활성화하고, 허용할 상대의 IP 주소·NetBIOS 이름·FQDN을 나열합니다.⁴

예외 목록 자체를 만드는 PowerShell 명령이 마련되어 있지 않으므로 처음에는 그룹 정책 편집기에서 설정해야 하지만, 일단 만든 후의 개별 추가는 레지스트리 조작으로 할 수 있습니다.⁴

# 기존 예외 목록에 항목을 추가한다
$params = @{
  Path = "HKLM:\SOFTWARE\Policies\Microsoft\Windows\LanmanWorkstation"
  Name = "BlockNTLMServerExceptionList"
}
$Entries = "192.168.10.10", "corp.contoso.com", "CORP"

$CurrentValue = (Get-ItemProperty @params -ErrorAction SilentlyContinue).BlockNTLMServerExceptionList
$params["Value"] = if ($null -eq $CurrentValue) { $Entries }
                   else { $CurrentValue + $Entries }
Set-ItemProperty @params

주의: 마이크로소프트 문서에 실린 예제는, 값이 아직 존재하지 않는 경우의 분기가 @("")를 설정하는 것으로 되어 있어 추가하려던 항목이 그대로 버려집니다.⁴ 처음 실행 시 예외가 하나도 들어가지 않고, 두 번째 실행에서 비로소 들어가는 동작이 되므로, 위 코드에서는 아직 만들어지지 않은 경우에도 추가 대상을 그대로 기록하도록 하고 있습니다. 다만 애초에 이 레지스트리 값은 그룹 정책이 관리하는 영역입니다. 영구적인 예외는 그룹 정책 쪽에서 관리하고, 이 조작은 긴급 시 임시 대응에 그치세요. 다음 정책 적용 시 덮어써집니다.

주의: 이 기능은 SMB 클라이언트 측 기능입니다.⁴ SMB 이외의 경로(자사 앱의 HTTP 통신, SQL Server 접속, WinRM 등)의 NTLM은 이것으로는 멈추지 않습니다. 그쪽은 5장의 분류에 따라 개별적으로 없애야 합니다.

8. 개발자 관점에서 본 NTLM ── Negotiate 사용하기

자사에서 Windows 앱을 만들고 있다면 고칠 곳은 명확합니다. 마이크로소프트는 다음과 같이 명시하고 있습니다.⁵

애플리케이션은 NTLM 보안 패키지에 직접 접근해서는 안 됩니다. 대신 Negotiate 보안 패키지를 사용해야 합니다. Negotiate는 인증에 관련된 시스템이 지원한다면 더 고도의 보안 프로토콜을 이용할 수 있게 해 줍니다. 현재 Negotiate 보안 패키지는 Kerberos와 NTLM 중 하나를 선택합니다. Negotiate는 인증에 관련된 시스템 중 하나라도 Kerberos를 사용할 수 없는 경우를 제외하고는 Kerberos를 선택합니다.

즉 “NTLM”이라고 적혀 있는 부분을 “Negotiate”로 바꾸는 것이 원칙입니다. 비권장 기능 목록의 기술도 동일하며, NTLM 호출은 Negotiate 호출로 대체해야 한다고 되어 있습니다.¹

8.1. .NET에서 흔한 “NTLM 명시”

// 나쁜 예: 인증 유형에 NTLM을 명시하고 있다
var credential = new NetworkCredential(user, password, domain);
var cache = new CredentialCache();
cache.Add(new Uri("http://intra.example.local/"), "NTLM", credential);

var handler = new HttpClientHandler { Credentials = cache };

// 좋은 예: 바꾸는 것은 인증 유형뿐. 자격 증명은 그대로 전달한다
var credential = new NetworkCredential(user, password, domain);
var cache = new CredentialCache();
cache.Add(new Uri("http://intra.example.local/"), "Negotiate", credential);

var handler = new HttpClientHandler { Credentials = cache };

여기서 바꾸는 것은 인증 유형 문자열뿐입니다. credential을 CredentialCache.DefaultNetworkCredentials로 교체하면 인증 프로토콜뿐만 아니라 인증하는 주체까지 바뀝니다. 지정했던 계정이 아니라 그 프로세스를 실행하고 있는 계정(서비스 계정이나 로그온 중인 사용자)으로 인증하러 가게 되어, 접속 대상의 권한 설정에 따라서는 동작하지 않게 됩니다. 프로토콜 교체와 자격 증명 재검토는 별개의 변경으로 나누어 진행하세요.

한편 애초에 로그온 중인 사용자의 자격 증명으로 인증하고 싶다면(통합 Windows 인증) 더 단순하게 작성할 수 있습니다. 이쪽은 “누구로서 인증할 것인가”를 의도적으로 바꾸는 경우의 작성법입니다.

// 통합 Windows 인증(현재 로그온 사용자로 인증한다)
var handler = new HttpClientHandler
{
    UseDefaultCredentials = true,
};

HttpClient 자체의 취급(using으로 감싸지 않기, 생성 패턴, 타임아웃 설계)은 “HttpClient를 using으로 감싸면 안 되는 이유“에 정리해 두었습니다.

SSPI를 직접 다뤄야 할 경우, .NET 7 이후에 추가된 System.Net.Security.NegotiateAuthentication을 사용하면 Negotiate를 통한 인증을 관리 코드에서 다룰 수 있습니다. 여기서도 패키지 이름에 NTLM을 지정하지 않는 것이 핵심입니다.

8.2. 코드보다 먼저 봐야 할 “접속 대상 표기 방식”

코드를 고쳐도 접속 대상이 IP 주소인 채라면 결국 NTLM으로 떨어집니다. 기본값에서는 호스트 이름이 IP 주소인 경우 Windows는 해당 호스트에 대해 Kerberos 인증을 시도하지 않고 NTLM 등 사용 가능한 다른 프로토콜로 폴백하기 때문입니다.¹⁰ 구체적으로는 다음을 조사하세요.

• 설정 파일(appsettings.json, App.config, ini 파일)에 적힌 서버 이름
• SQL Server 연결 문자열의 서버 지정(Data Source)
• UNC 경로를 조합하는 부분. 하드코딩된 IP 주소가 없는지
• 설치 프로그램이나 키팅 절차서의 기본값
• 과거 장애 대응에서 “이름 해석이 불안정해서”라며 IP로 고쳐 쓴 뒤 되돌리지 않은 부분

마지막 항목은 정말로 자주 발견됩니다. IP 주소 직접 지정은 당시에는 올바른 응급 처치였지만, 지금은 기술 부채입니다.

8.3. 서비스 측을 만들고 있다면

자체 개발한 Windows 서비스나 IIS 앱을 Kerberos로 받고 싶은 경우, 티켓을 복호화하는 계정에, 클라이언트가 접속에 사용하는 이름으로 SPN을 등록해야 합니다. SPN이 등록되지 않은 애플리케이션은 Kerberos 대응을 표방하고 있어도 NTLM으로 떨어진다는 대표적인 예로 마이크로소프트 자신이 들고 있는 그대로입니다.³

등록 대상을 “서비스를 실행하고 있는 계정”이라고 단순하게 생각하면 IIS에서 걸립니다. IIS의 Windows 인증은 기본값으로 커널 모드 인증이 활성화되어 있으며, 이때 Kerberos 티켓을 복호화하는 것은 애플리케이션 풀의 ID가 아니라 HTTP.sys가 사용하는 머신 계정입니다. 전용 도메인 계정으로 애플리케이션 풀을 실행하고 있다고 해서 그 계정에 사이트의 HTTP SPN을 등록하면 SPN 소유자와 실제로 복호화하는 계정이 어긋나 NTLM으로 떨어지기는커녕 KRB_AP_ERR_MODIFIED로 인증 자체가 실패합니다.

요점은 “SPN의 등록 대상과 티켓을 복호화하는 ID를 일치시키는” 것입니다. 취할 수 있는 형태는 다음 2가지입니다.

• 머신 계정으로 복호화한다(기본값 그대로): 사이트를 호스트 이름으로 공개하고 있다면 그 호스트 이름의 HTTP SPN을 머신 계정에 등록한다.
• 애플리케이션 풀 ID로 복호화한다: useAppPoolCredentials를 활성화한 후 HTTP SPN을 애플리케이션 풀의 계정에 등록한다.

어느 쪽을 선택할지는 여러 서버에서 같은 서비스 계정을 공유하고 있는지(공유하고 있다면 풀 ID 쪽이 다루기 쉽습니다)로 정해집니다. 또한 SPN은 하나의 계정에만 등록할 수 있으므로 전환할 때는 기존 등록 삭제를 잊지 마세요. 중복 등록은 Kerberos 인증 자체를 망가뜨립니다.

클라이언트로 위장해 다른 서버에 접근하는 설계(위임)를 채택하고 있는 경우, NTLM과 Kerberos에서 취급이 달라집니다. Kerberos는 서비스가 클라이언트를 대신해 다른 서비스에 접속하는 위임 메커니즘을 지원하지만, NTLM이 제공하는 것은 로컬에서의 위장에 필요한 인가 정보까지입니다.⁸ 위장 관련 구현은 “Windows 위장 토큰을 올바르게 다루기“에서 다루고 있습니다.

9. 단계적으로 조여 가는 로드맵

지금까지를 정리하면 진행 순서는 다음과 같습니다. 어느 단계든 “되돌릴 수 있는” 것이 조건입니다.

9.1. SMB를 멈춰도 그것은 NTLM 대책의 절반

4~6단계가 다루는 것은 SMB뿐입니다. 7장에서 언급했듯이 SMB 클라이언트의 NTLM 차단은 SMB 클라이언트 측 기능이며,⁴ 그 외의 경로에는 효과가 없습니다. 2단계에서 “HTTP로 인증하고 있다”, “SQL Server가 NTLM으로 되어 있다”, “WinRM이 NTLM을 사용하고 있다”고 분류한 것은 6단계까지 진행해도 손대지 않은 채 남습니다. 게다가 SMB의 예외 목록에도 실리지 않으므로 건수를 세어도 보이지 않습니다.

이를 조이는 것이 6b단계입니다. 사용하는 것은 4장에서 감사 모드로 만든 바로 그 3가지 정책입니다. 절차는 같은 형태를 따릅니다.¹¹

1. “원격 서버로의 송신 NTLM 트래픽”을 모두 감사로 둔 채, 남아 있는 접속 대상을 찾아낸다
2. 아무래도 필요한 상대를 “원격 서버 예외 추가”에 등록한다
3. 파일럿 단말에서 모두 거부로 전환하고 업무가 한 바퀴 도는 것을 기다린다
4. 문제가 없으면 전개한다

도메인 전체에 대해서는 “이 도메인에서의 NTLM 인증”을, 마찬가지로 감사 → 예외(“이 도메인에서의 서버 예외 추가”) → 거부 순서로 진행합니다.¹² 마이크로소프트도 거부 옵션을 선택하기 전에 대응하는 감사 정책을 같은 옵션으로 설정해 영향을 평가해야 한다고 밝히고 있습니다.¹²

“SMB를 차단했으니 NTLM 대책은 완료”가 아닙니다. 완료 지표로 삼으려면 SMB의 예외 목록과 NTLM 제한의 서버 예외 목록 양쪽을 세세요.

9.2. 감사 기간은 “일수”가 아니라 “업무 한 바퀴”로 정한다

1단계에서 가장 실패하기 쉬운 것이 기간을 정하는 방법입니다. “2주간 수집했으니 완료”로 해 버리면 그 2주 동안 실행되지 않은 처리는 목록에 실리지 않습니다. 그리고 실리지 않은 것은 6단계에서 차단을 배포한 뒤 처음으로 고장 납니다.

구체적으로 놓치기 쉬운 것은 다음과 같은 것들입니다.

• 월별·분기별 마감 처리. 월말 배치가 공유 폴더나 DB에 IP 주소 직접 지정으로 연결하고 있는 것이 전형적인 예입니다.
• 연간 처리. 재고 조사, 연도 전환, 결산 관련.
• 장애 시에만 지나가는 경로. 백업으로부터의 복구 절차, 대체 서버로의 전환, DR 훈련.
• 장기간 오프라인인 단말. 반출 PC, 장기 휴가 중인 담당자의 단말, 평소 전원이 꺼져 있는 예비기.
• 연간 몇 번밖에 사용하지 않는 업무 앱.

마이크로소프트 가이드 자신도 분석은 배포의 복잡성에 따라 몇 개월에 이를 수 있다고 밝히고 있습니다.³ 현실적인 기준은 다음 둘 중 하나입니다.

1. 업무가 한 바퀴 돌 때까지 감사를 계속 돌린다. 최소한 월말 마감을 1회, 가능하면 분기를 걸치도록 한다.
2. 저빈도 처리를 찾아내어 의도적으로 실행한다. 기간을 기다릴 수 없는 경우, 마감 처리나 DR 절차를 검증 환경에서 실행해 그 결과를 목록에 추가한다. “실행하지 않았으니 나오지 않았을 뿐”인 처리를, 담당자 청취로 먼저 나열해 두는 것이 핵심입니다.

어느 경우든 “이벤트가 나오지 않았다”와 “아직 실행되지 않았다”를 구별할 수 있는 상태로 만든 후 다음 단계로 진행하세요.

9.3. 단숨에 거부로 돌리지 않는다

여기서 “송신 NTLM 트래픽=모두 거부”로 단숨에 돌리지 않는 것이 핵심입니다. 마이크로소프트도 이 정책을 거부로 설정하면 다수의 NTLM 인증 요청이 실패해 생산성을 떨어뜨릴 수 있으므로, 구현 전에 “모두 감사”로 로그를 확인하고 서버 분석을 수행하며 제외할 예외 목록을 만들어야 한다고 밝히고 있습니다.⁷ 도메인 전체를 대상으로 하는 “이 도메인에서의 NTLM 인증” 정책에 대해서도 같은 경고가 적혀 있습니다.¹²

10. 정리

• NTLM은 2024년 6월에 모든 버전이 비권장이 되었습니다. 즉시 중단되는 변경이 아니라, 차기 Windows Server·다음 연차 릴리스의 Windows에서도 계속 동작한다고 되어 있습니다.¹
• 한편 NTLMv1은 이미 제거되었습니다(Windows 11 24H2 / Windows Server 2025). NTLMv1밖에 못 쓰는 장치와 NTLM V1이 기록되어 있는 호스트가 가장 가까운 기한입니다.¹
• 폐지는 3단계로, 1단계는 감사, 2단계(2026년 하반기)가 IAKerb와 로컬 KDC, 3단계가 기본 비활성화입니다.²
• 감사는 3가지 정책을 감사 모드로 하고 Microsoft-Windows-NTLM/Operational을 수집합니다. 도메인 계정이라면 DC의 8004 → 멤버 서버의 8003 → 클라이언트의 8001 순서로, 마지막에 앱 이름까지 도달합니다. 로컬 계정으로의 인증은 8004가 발생하지 않으므로 서버와 클라이언트의 이벤트에서 수집합니다.³⁷
• SMB 경유는 PID가 항상 4(SYSTEM)가 됩니다. 이벤트 로그로 단말까지 좁힌 다음, 그 1대를 ProcMon으로 추적하세요.³
• 원인의 대부분은 “이름”입니다. IP 주소 직접 지정과 SPN 미등록을 없애는 것만으로 남는 예외는 크게 줄어듭니다.³²
• NET USE \\server\share /BLOCKNTLM은 정책을 바꾸지 않고 1개 연결만으로 뒷받침할 수 있는 가장 안전한 확인 수단입니다.⁴
• 자체 개발 앱은 NTLM 명시를 Negotiate로 대체하고, 접속 대상 표기 방식을 FQDN으로 맞춥니다.⁵
• 예외 목록은 해결이 아니라 유예입니다. 건수가 매년 줄어들고 있는지를 지표로 삼으세요.

관련 글

• 그림으로 이해하는 NTLM과 Kerberos ── 왜 인증은 NTLM으로 ‘떨어지는가’
• 네트워크 드라이브와 UNC 경로의 함정 ── 업무 앱에서 파일 서버(공유 폴더)를 다루는 실무
• Get-WinEvent로 이벤트 로그를 실무적으로 조사하기 ── 필터링 속도가 조사 시간을 좌우한다
• Process Monitor(ProcMon) 실전 가이드 ── 「설정이 반영되지 않는다」「ACCESS DENIED」를 10분 만에 특정하기
• PowerShell Remoting(WinRM) 입문 ── 여러 대의 Windows를 일괄 관리하기
• PowerShell에서 자격 증명을 안전하게 다루기 ── 평문 비밀번호를 스크립트에서 추방한다
• WinForms/WPF 앱에 Entra ID 인증 넣기 ── MSAL.NET과 WAM 브로커 실무 구성
• Windows의 TPM이란 무엇인가 ── 그림으로 이해하는 ‘키를 밖으로 내보내지 않는 금고’와 측정 부팅

관련 상담 영역

합동회사 코무라소프트는 NTLM 의존 실태 조사와 Kerberos 전제로의 이행에 따르는 업무 앱 개수, 인증 관련 결함 조사를 다루고 있습니다.

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

참고 링크

</content>

관련 기사

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

관련 토픽

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

이 주제와 연결되는 서비스

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

자주 묻는 질문

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

NTLM이 폐지되면 언제부터 업무가 멈추나요?

"비권장(deprecated)" 공지만으로는 아무것도 멈추지 않습니다. 마이크로소프트는 2024년 6월에 NTLM의 모든 버전을 비권장으로 지정했지만, 당시 안내는 "차기 Windows Server와 다음 연차 릴리스의 Windows에서도 NTLM 사용은 계속 동작한다"는 것이었습니다. 이미 동작하지 않게 된 구체적인 변경은 Windows 11 버전 24H2와 Windows Server 2025에서의 NTLMv1 제거입니다. 향후 릴리스에서 네트워크 NTLM이 기본값으로 비활성화되는 계획은 공표되어 있지만, 그 시점에도 정책으로 다시 활성화할 수 있다고 되어 있습니다. 즉 "어느 날 갑자기 전사가 멈추는" 종류의 변경이 아니라, OS를 새롭게 할 때마다 조금씩 좁혀지는 종류의 변경입니다. 그렇기 때문에 멈춘 뒤에 조사하는 것이 아니라, 아직 NTLM이 동작하고 있는 동안 감사 로그로 의존 지점을 찾아 두는 것이 유일한 현실적인 대비입니다.

NTLM을 사용하고 있는 곳은 어떻게 목록화할 수 있나요?

그룹 정책의 "네트워크 보안: NTLM 제한" 계열 설정을 감사 모드로 하고 NTLM/Operational 로그를 수집합니다. 도메인 컨트롤러에 "이 도메인에서의 NTLM 인증 감사", 서버와 클라이언트에 "수신 NTLM 트래픽 감사"와 "원격 서버로의 송신 NTLM 트래픽=모두 감사"를 설정하면 이벤트 뷰어의 "애플리케이션 및 서비스 로그 > Microsoft > Windows > NTLM"에 이벤트가 기록됩니다. 도메인 계정으로의 인증이라면 추적 순서는 도메인 컨트롤러의 이벤트 8004에서 사용자와 접속 대상 서버(보안 채널 이름)를 특정하고, 그 서버의 이벤트 8003에서 프로세스 ID를 확인한 다음, 마지막으로 클라이언트의 이벤트 8001에서 "어느 앱이, 어느 서버 이름으로" 요청했는지 확정하는 것입니다. 이벤트 8001에는 대상 서버 이름과 클라이언트 프로세스 이름이 들어 있으므로 여기까지 오면 원인 앱을 알 수 있습니다. 다만 로컬 계정으로의 인증은 도메인 컨트롤러를 거치지 않으므로 8004가 발생하지 않습니다. 워크그룹 머신이나 파일 서버의 로컬 계정으로 공유에 연결하는 경로는 서버 측의 8003과 클라이언트 측의 8001에서 수집해야 합니다. 도메인 컨트롤러의 로그만 보고 "우리는 적다"고 판단하지 마세요.

감사를 해 보니 이벤트의 PID가 4(SYSTEM)뿐이라 어느 앱인지 알 수 없습니다.

SMB(공유 폴더) 경유 통신이기 때문입니다. SMB 인증은 커널 모드 리디렉터가 수행하므로 호출한 앱은 SMB 패킷 뒤에 숨어 버려서 이벤트에 남는 PID는 항상 4(SYSTEM)가 됩니다. 마이크로소프트 가이드도 이 경우를 명시하고 있으며, 대처법으로 이벤트가 발생한 클라이언트에서 Process Monitor(ProcMon)를 실행하고, 상대 서버의 컴퓨터 이름과 IP 주소로 경로를 필터링한 다음, 서버 측 이벤트 8003의 타임스탬프와 대조해 호출한 프로세스를 특정하는 절차를 안내하고 있습니다. 실무에서는 우선 "어느 단말인지"까지 이벤트 로그로 좁힌 다음, 그 단말만 ProcMon으로 추적하는 것이 빠릅니다.

Kerberos를 지원할 텐데도 앱이 NTLM으로 떨어지는 이유는 무엇인가요?

대부분은 이름의 문제입니다. 마이크로소프트 가이드는 이론상 Kerberos를 지원하면서도 NTLM을 사용해 버리는 앱으로, 보안 구성이나 공급자를 선택할 수 있는 앱, SPN(서비스 사용자 이름)이 올바르게 등록되어 있지 않은 앱, 설정 오류나 공급업체 절차서 때문에 DNS 이름이 아닌 IP 주소로 접속하고 있는 앱, 레거시 코드베이스에 NTLM 전용 부분이 남아 있는 앱, 이렇게 4가지를 들고 있습니다. 이벤트 8001의 "대상 서버"가 NetBIOS 이름도 FQDN도 아닌 형식(즉 IP 주소)이라면 기본 구성에서는 Kerberos가 사용되지 않습니다. IP 주소 직접 지정을 FQDN으로 바꾸고, 별칭으로 접속하고 있다면 그 이름으로 SPN을 등록하는 것이 첫 두 가지 조치입니다. 다만 아무래도 이름으로 바꿀 수 없는 경우에 대비해, 클라이언트에 TryIPSPN을 설정해 IP 주소의 SPN을 수동 등록하는 방법도 마련되어 있지만, 마이크로소프트 자신이 DNS 이름으로 변경이 불가능한 경우에만 한정해야 한다고 밝히고 있으므로 어디까지나 최후의 수단입니다.

자체 개발 중인 Windows 앱은 무엇을 고쳐야 하나요?

인증 패키지에 NTLM을 명시하고 있는 부분을 Negotiate로 대체합니다. 마이크로소프트는 "앱은 NTLM 보안 패키지에 직접 접근해서는 안 되며 Negotiate 패키지를 사용해야 한다"고 명시하고 있습니다. Negotiate는 Kerberos와 NTLM 중 하나를 선택하며, 인증에 관련된 시스템 중 하나라도 Kerberos를 사용할 수 없는 경우를 제외하고는 Kerberos를 선택합니다. .NET이라면 CredentialCache.Add에 전달하는 인증 유형을 "NTLM"에서 "Negotiate"로 바꾸는 것이 전형적인 수정입니다(인증 유형을 지정하는 것은 CredentialCache.Add이며, NetworkCredential의 생성자가 아닙니다). 아울러 접속 대상을 IP 주소나 hosts에 적은 별칭이 아닌 FQDN으로 지정하는 것, 자체 서비스를 Kerberos로 받으려면 그 서비스 계정에 SPN을 등록하는 것도 필요합니다.

저자 프로필

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

Go Komura

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

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