WIN LOGON Event

Article

이번 특정 케이스를 수행하면서 Event Log에서 로그인이 되는 현상을 발견할 수 있었다. 그중 Anonymous Logon 으로 로그온 되는 현상을 확인해 볼 수 있었는데 그 원인을 파악하는데 어려움이 있었다. 이번 글에서는 어느 상황에서 이벤트 로그에 Anonymous Logon이 생성되는지를 확인해 보고, 로그온 유형 중 어떤 상황에서 NTLM v1 과 NTLM v2를 이용하는지 실험을 통해 알아낸 점을 공유하도록 한다. 실험과 글 내용은 모두 Windows 10 을 기반으로 한다는 점을 참고해서 보면 좋을거 같다.
먼저 간단하게 이벤트 로그에 대해서 설명하고 넘어가면, 파일시스템이 아닌 Windows 운영체제에서 시스템을 사용하면서 발생하는 H/W 및 S/W의 다양한 이벤트에 대한 기록을 이야기한다. Windows Vista/2008 이후 버전부터는 evt 파일이 아닌 evtx 파일을 사용하고 있으며, 이 과정에서 저장방식이 BXML 형태로 바뀌었다. 다음과 같은 구조로 저장이 된다.
추출되는 데이터 형식은 다음과 같음
Attribute
Description
Source
이벤트를 기록한 소프트웨어
Event ID
이벤트에 대한 고유 값
Level
이벤트의 중요도 (정보, 경고, 오류, 심각, 성공 감사, 실패 감사)
User
이벤트 발생에 대한 사용자 이름
Operational Code
응용프로그램에서 이벤트가 발생하였을 때 활동이나 시점을 식별하는 값
Log
이벤트가 기록된 로그의 이름
Task Category
이벤트 게시자의 하위 구성요소 또는 활동을 표현하는데 사용
Keywords
이벤트를 검색하거나 필터링하는데 사용할 수 있는 범위
Computer
이벤트가 발생한 CPU 이름
Date & Time
이벤트가 기록된 시간 (64bit - LE)
Process ID
이벤트를 생성하는 프로세스에 대한 ID
Thread ID
이벤트를 생성하는 Thread 의 ID
이 중 Event ID 가 로그온, 로그오프에 사용되는 ID들을 모아본 표가 아래와 같다.
Category
Type
ID
Description
로그온
Security
4624
계정 로그온 성공
Security
4625
계정 로그온 실패
특수 로그온
Security
4672
특수 권한을 새 로그온에 할당
원격 로그온
Security
4648
명시적 자격 증명을 사용하여 로그온 시도
로그오프
Security
4634
계정 로그오프 (로그온 세션 소멸)
Security
4647
사용자가 로그오프 시작
그중 특수 로그온은 신규 로인에 부여된 특수 권한을 의미하며 이는 시스템 계정과 연계되어 프로세스를 더 높은 수준으로 높이는데 사용될 수 있다.
가끔 아래 사진처럼 사용자 계정과 연동되는 경우가 있는데 이때는 중요하지 않은 계정을 통해서 네트워크의 중요한 계정에 액세스를 시도하는 것을 의심할 수 있다.
현재 상황에서는 dbadmin 이라는 계정 이름이 의심스러운 경우이다.
이러한 의심스러운 계정을 파악한 다음, 해당 계정의 로그인 정황을 확인하기 위해 이벤트 ID 4624를 보았을 때 보안 ID가 NULL SID 인것을 확인할 수 있었다. 이러한 보안 아이디가 언제 NULL SID 인지를 식별하는 것이 첫번째 다룰 부분이다.
두번째로 다룰 부분은 계정 이름이다. 현재 원하는 목적은 dbadmin 에 해당하는 계정 이름을 확인하는 것이었으나, 유사한 형태의 계정 이름과 보안 ID가 모두 ANONYMOUS LOGON 으로 처리된 로그들을 여럿 확인할 수 있었다. 이 경우, 사용자 이름을 ANONYMOUS LOGON으로 설정한 것은 아니라는 것을 유추할 수 있기 때문에 어떤 경우에 ANONYMOUS LOGON 으로 설정되는지 확인해 보는 것이 두번째로 다룰 부분이다.
마지막으로는 인증 세부 정보에 대한 순수한 궁금증이 생겨서 알아보는 부분으로 인증 방법으로 NTLM을 사용하는 것을 대부분의 Windows 환경에서 확인할 수 있는데, 어떤 경우에서 NTLM v1 패키지를 활용하고, 어떤 경우에서 NTLM v2 패키지를 확인하는지 알아낸 다음 이를 통해서 얻을 수 있는 정보가 있다면 향후 분석에서 유의미하게 적용할 수 있을 기대를 가지고 분석하여 설명하는 내용을 마지막으로 다루게 된다.

Security ID

S → 문자열이 SID임을 의미
R → 개정 수준 표시
X → 식별자 기관 값
Y → 일련의 하위 자식 값
이는 구성원이 없는 그룹에 속해 있거나, SID 값을 알 수 없는 경우 자주 사용된다고 한다.
로그온이 일어나는 과정을 볼 때 SAM(Security Account Manager)에서 로그인에 입력된 정보와 데이터베이스에 저장된 정보를 비교하여 인증을 진행하는지 여부를 결정하고 SRM(Security Reference Monitor)로 전달하게 되는데 이때 SRM 이 SID를 부여하는 것이다. 부여된 SID에 기반하여 Windows 내부의 컨텐츠에 접근을 통제하게 된다.
NULL SID 는 인증을 통과하지 못해서 SRM에서 SID를 부여해주지 않은 경우에 나타나고, 주로 로그온 실패의 경우 많이 볼수 있는 것이다. NULL SID 가 의미하는 것이 무엇인지 알았으나, 현재 나타나는 현상은 로그온이 성공한 경우에 나타나는 NULL SID이기 때문에 이에 대한 원인을 파악하는 것이 주 목적이 되겠다.
먼저 첫번째 경우이다.
본 경우는 로그온을 하는 경우 공통적으로 나타나는 현상으로, 로그인 이전에 컴퓨터를 활성화하는 과정에서 생기는 로그이다. 위에서 설명한 논리대로 이 과정에서는 사용자 계정 정보를 입력받지 않았으니 SRM에서 SID를 현재 부여받지 않은 상태임을 알 수 있다.
해당 로그 이후 각종 드라이버들이 각자의 서비스 계정으로 로그인을 한다. 즉 컴퓨터를 키고 끄는 과정인 로그온 유형 0인 경우 이를 확인할 수 있다.
추가적으로 로그온 유형 3에 대해서도 알아보도록 하자 이 경우에 대해서 NULL SID 가 생성되는 이유는 유사한 이유이다. 로그인 이전, 비밀번호를 입력하는 창에서 이미 로그인을 하여 대상 컴퓨터와 연결은 되었으나, SRM에서 자격 증명인 SID를 획득하지 못해 NULL SID로 나오는 것을 확인할 수 있었다. RDP 연결뿐만 아니라, SMB 연결에서도 동일한 현상을 확인해 볼 수 있다.
즉 정상적으로 로그온이 이루지는 상황이라면 NULL SID 와 정상 계정이 쌍을 이뤄 Event Log를 생성하는 것을 확인하면 되겠다.

Account Name

본 파트에서는 계정 이름이 Anonymous Logon 으로 생성되는 이유에 대해서 알아보도록 한다. 일반적으로 발생하는 ANONYMOUS LOGON의 경우 동일 네트워크에 속한 Windows 끼리 네트워크 차원에서 익명 접속이 자동적으로 발생하며, 이때 해당 계정이 사용되는 것으로 알려져 있다.
정확히는 Windows NT RAS(Remote Access Service)에서 익명 로그인을 사용하여 사용자에게 RAS 연결을 설정할 수 있는 권한이 있는지의 여부를 확인하게 된다. 이 경우에 아래 사진처럼 이벤트 로그가 남게 되는 것이다.
물론 이와 같은 경우가 아니더라도, 3rd Party 서비스에 의해서도 이러한 로그가 생성될 수 있다.

Certification Details

이번 파트에서는 어떤 경우에서 인증 세부 정보로 NTLM v1과 NTLM v2를 활용하는지 알아보려 한다. 그전에 NTLM 이 뭔지, NTLM v1, v2는 뭔지에 대해서 간략하게 설명하고 들어가도록 하겠다.
NTLM 이란 MS의 인증에 사용되는 Challenge & Response 방식의 인증으로, 사용자 암호나 그 해시를 전송하지 않는 방법이다. 그럼 v1 과 v2의 차이점은 무엇인지에 대해서 조사해 보자면 두가지 차이점이 있다.
1.
NTLM v1에서는 클라이언트 측에서 서버측으로 CPU 이름을 평문으로 전송하게 된다. NTLMv2 에서도 동일하게 CPU 이름을 평문으로 전송하나, 위조를 방지하기 위해 시간값(Timestamp)를 함께 전송한다.
2.
NTLM v1 에서는 Challenge & Response 구조에서 Challenge 길이가 16바이트로 고정되어 있었다. 하지만 NTLM v2에서부터는 Challenge 의 길이가 가변으로 바뀐것을 화인할 수 있다.
이러한 과정을 통해서 Replay Attack을 방지할 수 있게 된다. 그래도 NTLM v2에서는 대부분 유사한 구조를 NTLM v1에서 가져오므로 비슷한 취약점을 가지게 된다.
이 과정에서 생각해 볼 수 있는게 보안 수준의 RDP 연결에 따라 NTLM v2를 사용하는지 NTLM v1을 사용하는지 정해지는지에 대한 생각이 들었다. 기본옵션으로 체크되어 있는 “네트워크 수준 인증을 사용하여 원격 데스트톱을 실행하는 컵퓨터에서만 연결 허용” 을 해제한 상태로 접근하게 된다면 NTLM v1을 사용하는지 확인하고 싶었다. 실험을 통해 확인한 결과, 해당 옵션의 체크 여부와 관계 없이 모두 NTLM v2를 사용하는 것을 확인할 수 있었다.
NTLM 은 이전 버전의 윈도우에서 사용되게 되는데, Windows 95, WIndows 98 Windows NT 4.0 같은 버전에서 네트워크 인증 기능을 사용할때 NTLM v1 프로토콜을 사용하게 된다. 즉 Host 나 Client 둘중 하나가 이런 하위 버전의 윈도우를 사용하는 경우 NTLM v1 프로토콜을 사용할 수 있을 것 같다.
실험을 통해 확인한 결과 아래 경로상에서 인증 수준을 낮춰주게 된다면 RDP 접속 시 NTLM v1을 사용하는 것을 볼 수 있었다. 다른 경우에도 NTLM v1을 사용하는 경우를 파악할 수 있으면 원인 분석을 하는데 도움이 될 것 같다. 또한 NTLM v1으로 원격 접속 및 네트워크 연결 흔적이 존재한다면 이를 NTLM v2만 사용하도록 권고하는 것이 중요해 보인다.
로컬 그룹 정책 > 컴퓨터 구성 > Windows 설정 > 보안 설정 > 로컬 정책 > 보안 옵션 > 네트워크 보안: LAN Manager 인증 수준 속성
결론적으로 NTLM 이나 NT 인증과정이 NTLM v2보다 취약하기 때문에 이에 대한 설정을 필요로 한다면 좀더 안전하게 서버 운용을 할 수 있을것 같다. 위 값에 대한 설정은 이전에 언급한
로컬 그룹 정책 > 컴퓨터 구성 > Windows 설정 > 보안 설정 > 로컬 정책 > 보안 옵션 > 네트워크 보안: LAN Manager 인증 수준 속성
에서 변경할 수 있다. 변경하게 된다면 NTLM v1에 대한 인증은 이루어지지 않게 된다.

Reference