NTLM 해시 생성기

NTLM 해시는 입력값을 UTF-16LE(문자당 2바이트, 리틀 엔디언)로 인코딩한 뒤 MD4 메시지 다이제스트 알고리즘에 통과시켜 계산됩니다 — 이 단일 패스, 솔트 없는 연산이 Microsoft Windows가 NT 4.0 이후로 비밀번호 검증값을 저장하는 데 사용해 온 NTLM 해싱 방식의 전부입니다. 이 도구는 정확히 같은 연산을 브라우저 안에서 순수 자바스크립트로 로컬 실행하므로 입력한 어떤 값도 서버로 전송되지 않습니다. 이 도구는 Active Directory 해시 덤프 검증, hashcat이나 Mimikatz 출력 형식 확인, CTF 및 펜테스팅 실습 문제 풀이 등 정당한 보안 작업을 위한 것이며, 소유하고 있지 않거나 테스트 권한이 없는 계정을 공격하기 위한 것이 아닙니다.

이 도구는 무엇인가요?

NTLM(NT LAN Manager)은 Microsoft의 레거시 챌린지-응답 인증 프로토콜로, 지금도 로컬 Windows 계정 로그인과 많은 Active Directory 환경의 폴백 방식으로 사용됩니다. 흔히 "NTLM 해시"라 불리는 비밀번호 검증값은 Microsoft의 MS-NLMP 프로토콜 명세에서 `MD4(UTF-16-LE(password))`로 정의됩니다: 먼저 비밀번호를 UTF-16 리틀 엔디언으로 인코딩하고(UTF-8과 달리 모든 문자가 2바이트가 됩니다), 그 바이트 시퀀스를 RFC 1320의 MD4 알고리즘으로 한 번 해싱합니다.

UTF-16LE 단계는 NTLM을 직접 재구현할 때 가장 흔히 틀리는 부분입니다: 문자열의 UTF-8 바이트를 해싱하면 눈에 보이는 텍스트는 똑같아 보여도 완전히 다른, 잘못된 다이제스트가 나옵니다. 이 도구는 인코딩을 올바르게 수행하므로 출력값이 Windows가 실제로 저장하는 값, 그리고 hashcat(모드 1000)이나 Mimikatz가 기대하는 값과 일치합니다.

NTLM은 현대적인 비밀번호 해싱 설계보다 앞서 만들어졌기 때문에, 크래킹을 늦추기 위해 나중에 고안된 보호 장치가 전혀 없습니다: 사용자별 솔트도, 조정 가능한 작업 계수도, 의도적인 반복도 없습니다. 단일 MD4 패스이므로 계산이 매우 빠른데, 이는 레거시 호환성 면에서는 편리하지만 무차별 대입 공격이나 사전 공격에 저항하는 데는 치명적입니다.

왜 사용해야 할까요?

승인된 펜테스트에서 NTDS.dit 덤프를 막 추출했는데, 클라이언트에게 보고하기 전에 특정 해시가 후보 비밀번호와 실제로 일치하는지 빠르게 확인해야 할 때.
MS-NLMP 파서를 다른 프로그래밍 언어로 다시 작성 중인데, 코드 출력을 한 줄씩 대조할 수 있는 확실히 정확한 참조 해시가 필요할 때.
직접 운영하는 CTF 랩에서 hashcat(`-m 1000`) 연습용 워드리스트를 준비하는데, 실제 데이터셋에 명령을 실행하기 전에 테스트할 유효한 NTLM 해시 샘플이 필요할 때.
정식 레드팀 자격 증명 감사 중 Mimikatz 출력이 수상해 보여서, 이상 여부를 결론짓기 전에 독립적으로 교차 검증하고 싶을 때.
100% 로컬 처리: 입력값이 브라우저를 벗어나지 않으므로 승인된 평가에서 민감한 자격 증명을 다루더라도 안전합니다.

사용 방법

해시하려는 비밀번호나 문자열을 입력창에 입력하세요.
"Generate NTLM Hash"를 클릭하세요.
32자리 16진수 NTLM 해시를 확인하세요(Windows와 대부분의 크래킹 도구가 표시하는 방식과 맞춰 기본값은 대문자이며, 소문자로 보려면 체크를 해제하세요).
"Copy"를 클릭해 해시를 클립보드에 복사하세요.

예시

입력

password

결과

8846F7EAEE8FB117AD06BDD830B7586C

이는 잘 알려져 있고 독립적으로 검증 가능한 테스트 벡터입니다: 문자열 그대로 "password"의 NTLM 해시는 항상 8846F7EAEE8FB117AD06BDD830B7586C입니다. 이 값을 다른 올바른 NTLM 구현의 출력과 대조해 확인할 수 있습니다.

NTLM vs 현대적 비밀번호 해싱

아래 표는 NTLM이 여전히 구형 Windows 및 Active Directory 인프라에 내장되어 있음에도 왜 신규 시스템 보호에는 구식으로 간주되는지를 보여줍니다.

속성	NTLM	bcrypt / scrypt / Argon2
기반 알고리즘	단일 MD4 패스	조정 가능한 비용을 가진 목적 특화 느린 해시
솔트	없음 — 동일한 비밀번호는 항상 동일하게 해시됨	비밀번호마다 고유한 무작위 솔트
반복 / 스트레칭	없음	시간이 지남에 따라 늘릴 수 있는 조정 가능한 작업 계수
무차별 대입 저항성	매우 약함 — 현대 GPU에서 초당 수십억 회 시도	시도마다 의도적으로 비용이 큼
여전히 사용되는 곳	구형 Windows 인증, Active Directory 폴백	신규 애플리케이션, 현재의 모범 사례

빠른 검증 워크플로

실제 데이터의 결과를 신뢰하기 전에, 항상 테스트 벡터 "password"의 해시를 먼저 계산해서 8846F7EAEE8FB117AD06BDD830B7586C와 대조해보세요.
hashcat 모드 1000의 출력과 비교할 때는 해시의 대소문자를 먼저 통일하세요 — 해시 자체는 동일해도 대소문자 차이 때문에 문자열 비교가 실패한 것처럼 보일 수 있습니다.
직접 작성한 코드의 구현을 검증하려면 일반 라틴 문자뿐 아니라 비ASCII 문자가 포함된 비밀번호도 테스트해보세요 — UTF-16LE 인코딩 버그가 가장 자주 나타나는 지점입니다.
나중에 다른 NTLM 도구나 라이브러리를 다시 검증해야 할 때 빠르게 참고할 수 있도록, 테스트 벡터의 해시 결과를 개인 메모에 저장해두세요.

자주 묻는 질문

NTLM 해시란 정확히 무엇인가요?

Windows가 NT LAN Manager 인증을 위해 계산하고 저장하는 비밀번호 검증값으로, Microsoft의 MS-NLMP 명세에서 MD4(UTF-16LE(password))로 정의됩니다 — 비밀번호를 UTF-16 리틀 엔디언 바이트로 인코딩한 뒤 MD4를 한 번 적용한 것입니다. 항상 128비트이며 16진수 32자로 표시됩니다.

왜 UTF-8이나 ASCII가 아니라 UTF-16LE인가요?

Windows는 NT가 설계될 때부터 내부적으로 텍스트를 UTF-16LE로 저장해 왔기 때문에, 비밀번호도 해싱 전에 같은 방식으로 인코딩합니다. 'a' 같은 일반 ASCII 문자를 포함해 모든 문자가 2바이트(리틀 엔디언 바이트 순서)가 되며, 'a'는 0x61 한 바이트가 아니라 0x61 0x00이 됩니다. 같은 문자열의 UTF-8 바이트를 해싱하면 완전히 다른, 틀린 결과가 나오는데, 이는 NTLM을 처음부터 직접 구현할 때 가장 흔히 발생하는 버그입니다.

오늘날 NTLM을 사용해도 안전한가요?

아니요, Microsoft 스스로도 가능하다면 Kerberos로 전환할 것을 권장합니다. NTLM은 솔트가 없어서 동일한 비밀번호는 모든 사용자와 모든 시스템에서 항상 동일한 해시를 만들어내므로 미리 계산된 레인보우 테이블 조회가 가능해집니다. 반복이나 작업 계수도 없이 솔트 없는 MD4 한 번뿐이므로, 현대 GPU는 탈취된 해시에 대해 초당 수십억 번의 시도를 할 수 있습니다. NTLM은 주로 구형 Windows 시스템 및 애플리케이션과의 레거시 호환성 때문에 남아 있습니다.

NTLM은 bcrypt, scrypt, Argon2 같은 현대적 비밀번호 해싱과 어떻게 다른가요?

현대적인 비밀번호 해셔는 의도적으로 느리고 솔트를 사용합니다: bcrypt, scrypt, Argon2는 각각 비밀번호마다 고유한 무작위 솔트를 추가하고, 하드웨어가 빨라짐에 따라 시간이 지나도 높일 수 있는 조정 가능한 비용 계수를 둡니다. 이는 대규모로도 무차별 대입 공격의 비용을 높이기 위한 것입니다. NTLM은 둘 다 하지 않습니다 — 오프라인 무차별 대입이 현실적인 위협 모델이 되기 전 시대에 설계되었고, 그 흔적이 그대로 남아 있습니다. 바로 이 때문에 NTLM은 오늘날 새로 만드는 어떤 것도 보호하는 데 쓰여서는 안 됩니다. 이 도구의 실제 용도는 기존 Windows 인프라와의 호환성 확인과 승인된 보안 테스트이지, 새 시스템을 구축하는 것이 아닙니다.

NTLM 해시 생성기의 정당한 사용 사례는 무엇인가요?

승인된 침투 테스트나 자격 증명 감사 중 SAM 데이터베이스나 NTDS.dit에서 추출한 해시를 검증하는 것, 직접 만든 도구나 스크립트가 MS-NLMP를 올바르게 구현했는지 확인하는 것, 직접 통제하는 랩 환경에서 hashcat(모드 1000)이나 Mimikatz 형식 호환성 테스트용 해시를 생성하는 것, NTLM을 명시적으로 다루는 CTF나 교육 실습을 진행하는 것 등입니다. 소유하고 있지 않거나 서면 승인 없이 테스트할 수 없는 계정이나 시스템을 공격하기 위해 이 도구를 사용하는 것은 정당한 사용이 아닙니다.

제 비밀번호나 입력값이 서버로 전송되나요?

아닙니다. MD4 계산은 브라우저 안에서 전부 자바스크립트로 실행됩니다 — MD4를 지원하는 브라우저 네이티브 API가 없기 때문에 이 페이지의 클라이언트 측 코드에 직접 구현되어 있으며, 입력한 어떤 값도 어디로도 전송되지 않습니다.

제가 계산한 NTLM 해시가 NTDS.dit 덤프의 해시와 일치하지 않는 이유는 무엇인가요?

가장 흔한 원인은 다른 구현체의 문자 인코딩 오류(예: UTF-16LE 대신 UTF-8 사용)이거나, 화면에 바로 보이지 않는 숨은 문자(불필요한 공백, 비표준 유니코드 문자)가 비밀번호에 포함된 경우입니다. 실제 해시를 비교하기 전에 먼저 테스트 벡터 "password"를 해싱해보세요 — 결과가 정확히 8846F7EAEE8FB117AD06BDD830B7586C이어야 도구가 올바르다는 것을 확인할 수 있습니다.

이 도구가 NTLM 해시를 계산만 하나요, 아니면 크랙(해독)도 할 수 있나요?

아니요 — 이 도구는 비밀번호를 해시로 바꾸는 순수한 일방향 계산기이며, 그 반대는 하지 않습니다. 이미 확보한 NTLM 해시를 (정당한 권한 하에) 크랙하려면 hashcat이나 John the Ripper 같은 전용 크래킹 도구가 필요합니다. 이런 도구는 여러 후보 비밀번호를 시도하며 해시를 비교합니다.