[windows] 윈도우 로컬 환경 로그온 과정 상세 분석 1 - NTLM
예전에 리눅스 데스크탑 환경 관련 글을 포스팅한적이 있다. 해당 포스팅에서 GUI의 각 구성요소별 기능을 소개했다. 당연하지만 윈도우에서도 사용자 인증을 위한 절차가 존재한다. 간단하게 생각해보면, 가장 먼저 로그인 화면이 존재하고 비밀번호를 입력해 인증이 성공하면 explorer가 실제 GUI 사용자 환경을 로드한다. 이 과정에서 사용자 인증정보는 어떻게 처리되고 어디에 기록되는 걸까? 하는 당연한 의문이 생긴다. 그래서 한번 추적하고 정리해보았다.
1. 로컬 환경에서 사용자 인증 절차
위에서 설명한 절차들은 실제로 아래 이미지와 같은 절차를 거친다.
먼저 로그인화면에서 인증 절차를 거친 후 사용자 계정으로 확인되면 권한이 부여된 토큰을 발행하고 사용자별 환경설정을 로드한다.
그럼 이 때 사용자 인증정보는 어디에 저장되어 이런 인증 절차를 확인하는 걸까?
2. SAM Registry Hive
레지스트리는 윈도우 운영체제 구동을 위한 설정 값들이 저장되어있는 일종의 데이터베이스다. regedit 를 열어서 볼수도 있지만 다른 도구를 사용하거나 raw data를 직접 읽어볼 수도 있다. 또한 우리가 읽을 수 있다는 의미는 이 데이터들이 '파일'의 형태로 저장되어 있다는 의미와도 같다.
HKEY_LOCAL_MACHINE 하위 하이브들이 존재하는 경로는 C:/windows/system32/config 경로다. 아래 사진처럼 직접 레지스트리를 찾아볼 수 있다.
위에서도 볼 수 있지만 SAM 과 같은 일부 레지스트리 하이브는 일반 사용자나 관리자 권한으로는 내부 데이터들을 읽을 수 없으며 'system' 권한이 필요하다. 이 권한에 대한 이야기는 필자가 다른 글에서 소개한 바 있다. 이는 이러한 중요한 자원에 접근할 수 있는 권한을 제한해 보안을 강화하려는 마이크로 소프트의 의도라고 생각된다.
아무튼 사용자의 인증정보 계정명, SID, RID, NTLM 해시, 그외 등등 정보들이 모두 이 SAM 에 기록된다. 즉 이 데이터를 까볼 수 있다면 우리는 사용자 인증에 대한 정보들을 알 수 있다는 의미가 된다. 그럼 어떻게 이걸 까볼수있을까?
3. 사용자 인증 절차 로직
로컬사용자 환경과 AD(Active Directory)환경에는 큰 차이점이 존재한다. 이 글에서는 로컬 사용자 환경에 대해서만 다루겠다.
우선 전체 러프한 흐름은 다음과 같다.
예전 버전에서는 NTLM 해시가 한 번 암호화 되어 기록된다 본 적이 있는데, 현재 윈도우 11 23H2 22631.4602 에서는 무려 2번 암호화가 되어 SAM 레지스트리에 기록된다. 그래서 우리는 두 번의 복호화 과정을 거쳐야 하고, 이 복호화 과정을 거치지 위해 system registry hive에서 bootkey 를 추출해야한다.
3-1. BootKey 획득(Syskey)
위 그림에서 BootKey 획득 단계에 보이는 JD, Skew1, GBG, Data 키는 system registry hive 내부에 존재하는 키로 상위 키의 경로는 HKLM\SYSTEM\CurrentControlSet\Control\Lsa 이다.
해당 네 개 키를 확인할 수 있다. 그리고 네 개 키에 존재하는 값이 아니라 classname 을 확인해야 한다.
레지스트리 구성을 간단하게 설명해보자면 다음과 같다.
- root key에서부터 시작되어 모든 키는 하위 키를 가질 수 있다.
- 키에는 이름 : 데이터 쌍을 가진 여러 데이터가 존재할 수 있다.
- 키는 class name이라는 별도의 별명(alias)을 가질 수 있다.
그리고 이 class name은 레지스트리 편집기와 같은 도구에서는 확인할 수 없고, 레지스트리 하이프 파일을 수동으로 파싱하거나, 또는 파싱해주는 도구를 사용해야 볼 수 있다.
이 네개 레지스트리 키의 class name을 추출한 후 연접하면 16byte 의 결과를 얻을 수 있다. 다만 이는 scramble 된 결과이다. 즉 우리는 이 값을 scramble 되기 전의 상태로 되돌려야 한다. 즉 아래 리스트에 적힌 순서대로 이 boot key를 재배열 해주면 된다.
BOOTKEY_PBOX = [
0x8, 0x5, 0x4, 0x2,
0xB, 0x9, 0xD, 0x3,
0x0, 0x6, 0x1, 0xC,
0xE, 0xA, 0xF, 0x7
]자 이과정을 거치고나면 여러분들은 진짜 bootkey를 얻어냈다. 단, NTLM 해시를 복호화 하기 위해서는 이 bootkey를 복호화해 syskey 를 얻어내는 과정이 필요하다.
복호화에 필요한 데이터는 SAM 레지스트리의 SAM\SAM\Domains\Account 키의 F 데이터로부터 확인할 수 있다.
16:32 바이트 영역이 IV(salt), 32:64 바이트 영역이 Data 가 된다. 자 이제 복호화를 할 수 있다.
bootkey -> key
IV(salt) -> IV
Data -> Data 로 AES CBC 복호화를 수행하면 우리는 syskey 를 손에넣을 수 있다.
3-2. RID 확인하기
SAM/SAM/Domains/Account/Users 키의 하위 경로에는 사용자 계정에 관한 인증정보들을 RID 키로 구분해 저장하고 있다. 이것이 무슨말이냐 한다면 바로 다음 표와 같다.
| HEX | DEC | ETC |
| 000001F4 | 500 | administrator 계정 |
| 000003E9 | 1001 | (비밀) |
| 000003EA | 1002 | troll 계정 |
Users 키의 하위 키의 16진수는 각 계정의 RID이며 이는 사용자별로 부여되는 고유 식별자다. 그리고 V 데이터 안에는 우리가 그토록 찾아헤매던 사용자 계정 정보와 암호화된 NTLM 해시가 잠들어있다.
3-3. Account 확인하기
앞서 V 안에는 사용자 계정 정보가 있다고 했다. 사용자 계정을 찾기 위해서는 사용자 계정 데이터의 offset과 길이 정보를 알아야 한다. 이 또한 V 안에서 찾을 수 있다.
V 값에서 0x0C-0x10 까지는 account 의 위치에 대한 offset 값이고, 0x10-0x14 까지는 account length에 대한 값이다. 이를 little endian으로 읽으면
account offset : 0x10C
account length : 0xA 임을 알 수 있다.
단 account offset에는 추가적으로 offset 0xCC를 더해주어야 한다. 즉 실제로는
account offset : 0x10C + 0xCC = 0x1D8
account length : 0xA
가 된다. 실제로 그런지 한번 확인해보자.
정확하게 0x1D8 위치에서 troll 이라는 계정을 찾을 수 있고 길이는 0xA=10 인것을 알 수 있다.
3-4. NTLM 해시 확인하기
위에서 사용자의 RID와 Account 정보를 확인했다. 이제 대망의 NTLM 차례다.
NTLM 또한 V내부에 account 정보 처럼 offset과 그 길이 정보를 저장하고 있다.
NTLM offset : 0xA8-0xAB
NTLM length : 0xAC-0xAF 가 된다. 단, 여기서 NTLM offset에도 0xCC의 offset 값을 주가로 더해주어야 한다.
따라서 실제 값은 다음과 같다.
NTLM offset = 0x174 + 0xCC = 0x240
NTLM length = 0x38
즉 바로 이 영역이 우리가 찾고자 하는 NTLM 해시라 할 수 있다. 그런데 조금 이상하다 MD4 해싱은 128비트, 즉 32 바이트여야 하는데 56(0x38)바이트로 확인된다. 이는 NTLM 해시가 암호화 되어있으며, 복호화 데이터를 포함하고 있기 때문이다.
3-4. NTLM 해시 복호화 하기
복호화 방법은 윈도우 os의 build version에 따라 다소 차이가 존재한다. 필자는 현재 26100 이므로
복호화에는 NTLM iv, encrypted NTLM, rid, syskey 네 개 정보가 필요하다.
iv는 위에서 확인한 56 byte의 데이터 중 [8:24] 영역, 실제 암호화된 NTLM은 [25:40] 으로
실제 이 영역의 값이 사용된다. (참고로 NTLM은 이중 암호화 되어있다. 그래서 두번 풀어야 한다)
위 영역에서 앞의 16 bytes를 Initial Vector, 뒤의 16 Bytes를 chipper text로 사용하고 앞서 찾았던 syskey를 key로 사용해 AES CBC모드로 복호화를 하면 한번 암호화된 NTLM 해시가 나타난다. 아래 코드를 보자. 첫 번째 복호화 과정이다.
이후에 한번 암호화된 NTLM을 다시 복호화 하면 온전하게 복호화된 NTLM 해시를 알 수 있다.
두 번 째 복호화에서는 한번 암호화된(한번 복호화된) 해시 와 rid가 사용된다.
조금 복잡하기 때문에 순서를 먼저 정리하고 설명하도록 하겠다.
1. rid 값을 little endian으로 변환한다.
2. [1] 에서 확인한 값을 [0,1,2,3,0,1,2], [3,0,1,2,3,0,1] 순서로 섞어서 배치한다.
3. [2] 에서 얻은 두 개 배열은 7 bytes 길이를 가지기 때문에 DES 복호화를 위해 8 bytes 로 확장하며 홀수 패리티 추가
4. 16 Bytes 길이의 암호화된 NTLM 해시를 8 Bytes 길이로 분리,
5. 8 Bytes로 확장된 배열과 8 Bytes로 나누어진 NTLM 해시를 DES ECB 모드로 복호화(각각 앞에 것, 뒤에 것 끼리 복호화)
6. 복호화된 두 문자열을 합치면 NTLM 복호화 완료.
다음 코드를 보자. 두 번째 복호화의 전체 과정이다.
아래 코드는 7 Bytes 데이터를 8 Bytes로 확장하며 홀수 패리티를 추가하는 코드다.
3-5. 복호화 결과 확인
troll 계정의 password는 troltiger다. 해당 값을 ntlm 해싱하면 다음과 같은 값을 확인할 수 있다.
필자가 작성한 코드로 확인한 결과다.
성공적으로 복호화한 것을 확인할 수 있다!
4. NTLM 인증 후 과정
NTLM 인증 후에도 많은 절차가 남아있다. 다만 이 글에서 정리하려고 하니 너무 길어 짧게 정리하고 넘어가겠다.
Access Token 생성
커널 모드에서 보안 토큰을 생성한다. 이 토큰에는 SID, 권한 목록, 로그인 타입, 프로파일 경로 등 다양한 정보가 포함된다.
LSA로 인증 상태 전달
LSA(Local Security Authority Subsystem Service, lsass.exe)가 토큰을 받아 인증 세션 등록
LUID 생성, Login Unique ID 생성
내부 로그온 세션 테이블에 저장
Windows 세션/데스크탑 생성
winlogon.exe 프로세스가 세션 생성 요청
사용자 세션 ID 배정, 윈도우 스테이션 및 데스크탑 객체 생성
사용자 프로필 로드
%Userprofile% 경로 생성
NTUSER.dat 레지스트리 하이브 로드(필자가 로그온 이벤트 분석 글에서 레지스트리 이벤트에서 ntuser 적재 여부로 로그온 성공 여부를 추정할 수 있다고 했다)
그룹 정책 적용(GPO, gpedit 에서 설정)
로그온 완료
explorer.exe 등 쉘 시작
security event 4624 등록
5. 마무리하며..
해당 복호화 작업에 약 1주일 정도 매달렸던것 같다. 사실 NTLM을 이용한 인증과정에는 많은 취약점이 존재한다. 실제로 필자가 분석했던 사고 중 Pass the Hash 공격으로 AD서버 침투 후 Domain Controller 정보를 탈취해 내부에 랜섬웨어를 퍼트린 공격도 있었다. 마소는 윈도우 11을 업데이트하며 이런 NTLM을 사용하는 인증 방법은 폐지할 것이라고는 하는데.. 과연..
6. 참조
- 0xCC 오프셋을 더하는 이유
https://learn.microsoft.com/en-us/archive/msdn-technet-forums/6e3c4486-f3a1-4d4e-9f5c-bdacdb245cfd
How are NTLM hashes stored under the V key in the SAM?
How are NTLM hashes stored under the V key in the SAM? Article 05/01/2018 In this article --> Question Tuesday, May 1, 2018 3:10 AM I have the registry key Computer\HKEY_LOCAL_MACHINE\SAM\SAM\Domains\Account\Users\000003E9 I know that the NTLM password has
learn.microsoft.com
https://www.passcape.com/index.php?section=docsys&cmd=details&id=23
LSA Secrets in Windows
Windows LSA secrets What are LSA secrets? What is stored in LSA secrets? Where are LSA secrets stored? LSA Secrets in detail CurrVal and OldVal data structure Encrypting LSA secrets in Windows 2000, XP, 2003 Encrypting secrets in Windows Vista, Windows 7 R
www.passcape.com
https://www.synacktiv.com/publications/lsa-secrets-revisiting-secretsdump