[도서] 인프라보안 - 15장: Windows 이벤트 로그와 Linux 로그 분석

계정 하나 만들었을 뿐인데 로그가 다섯 개 터진다

이번 챕터에서 제일 먼저 눈에 들어온 건 계정 생성 흐름이었다. 직관적으로는 "계정 만들면 로그 하나 생기겠지" 싶은데, 실제로는 그렇지 않더라. 사용자가 UI에서 계정 추가 버튼 한 번 누르면 Windows가 내부적으로 이런 순서로 이벤트를 쭉 찍는다.

4720(계정 생성) → 4722(계정 활성화) → 4738(계정 변경) → 4732(그룹 추가) → 4724(비밀번호 설정)

4720 로그를 보면 새로 만들어진 계정 이름과 그 계정을 만든 주체의 Security ID, Logon ID까지 같이 기록된다. 근데 여기서 흥미로운 게 있다. 4720 로그에서 Account Disabled가 보이더라도 바로 뒤따라오는 4722에서 "A user account was enabled"라고 나오니까, 비활성화 상태로 생겼다가 곧바로 켜진 게 정상 흐름이다. 처음엔 이게 이상해 보였는데 순서를 알고 나면 납득이 된다.

침해사고 관점에서 보면 이 흐름이 왜 중요한지 금방 와닿는다. 해커가 서버에 침입해서 자기 전용 계정을 몰래 만들 때도 똑같이 이 패턴이 찍힌다. 더 신경 쓰이는 건 4738이 계정 변경 시에도 발생하고 4732는 그룹 추가 때도 터진다는 거다. 그러니까 기존에 멀쩡히 있던 계정을 Administrators 그룹에 슬쩍 집어넣어도 4732가 찍히는데, 이때 Group Name이 Administrators인지 Users인지를 확인하는 게 핵심이다. 계정 삭제는 4733으로 그룹에서 빠지고 4726으로 실제 삭제가 기록되는데, 4726에는 어떤 계정이 사라졌는지 이름이 구체적으로 남는다.

RDP 로그인 하나에 이벤트 코드가 4개 붙는다

로그인 분석 파트도 꽤 인상적이었다. RDP로 접속하는 정상적인 케이스 하나를 추적하면 이 순서로 로그가 쌓인다.

4776 → 4648 → 4624 → 4672

4776은 자격증명 검증을 시도했다는 로그다. Error Code가 0x0이면 존재하는 계정, 0xC0000064면 계정이 없다는 뜻이고, 0xC000006A면 계정은 맞는데 비밀번호가 틀렸다는 거다. 이 에러 코드 표를 봐두면 나중에 브루트포스 공격 흔적을 읽을 때 바로 구분이 된다. Keywords가 Audit Failure로 찍히면 그 자체가 실패 로그인이라는 신호다.

실제로 침해 대응할 때 가장 중점적으로 봐야 하는 건 4624라고 책에서 강조하는데, 여기서 Logon Type 숫자가 중요하다. Type 10이면 RDP 원격 접속, Type 3이면 SMB 네트워크 로그인이다. 그리고 Source Network Address에 외부 IP가 찍혀 있는데 내부망에서 들어왔어야 할 서버라면 그게 바로 이상 징후다. 뒤따라오는 4672에는 해당 계정이 어떤 권한을 들고 로그인했는지까지 나오는데, SeDebugPrivilege나 SeTakeOwnershipPrivilege 같은 게 보이면 관리자급 권한으로 들어온 거다.

사실 실무에서 잘 안 보이는 케이스가 하나 있는데, 작업 끝낸 뒤 로그아웃 안 하고 RDP 창만 X로 닫는 경우다. 이러면 4647 대신 4779가 찍히고, 나중에 다시 들어올 때 4778이 생성된다. 세션이 끊긴 게 아니라 살아있는 거라서, 이 패턴을 모르면 해커가 세션을 재활용하는 상황도 놓칠 수 있다.

로그 노이즈: 이벤트 필터링 문제

챕터 후반부에 불필요한 로그 필터링 얘기가 나오는데, 이게 생각보다 심각한 문제더라. 로컬 보안 정책에서 전체 이벤트 수집을 켜고 Windows 2012 서버를 한 시간 놔뒀더니 Splunk에서 집계한 EventCode 분포가 4658이 24.9%, 4689가 21.2%, 4688이 21.1%를 차지했다. 세 개 합치면 전체의 거의 70%다.

4658은 오브젝트 핸들을 닫을 때 발생하는데, 탐색기로 파일 속성창 열었다 닫는 것만으로도 터진다. 4689는 프로세스 종료인데 제어판 닫기만 해도 발생한다. 이것들을 다 쌓으면 정작 봐야 할 4624, 4720, 4732 같은 로그가 노이즈에 파묻힌다. 그래서 Advanced Audit Policy Configuration으로 가서 필요한 카테고리만 골라 켜는 게 중요하다는 거다. Object Access를 통째로 켜두면 모든 오브젝트 접근이 다 찍히므로 실무에서는 세부 항목별로 조정이 필요하다.

스케줄러 등록 로그도 눈에 띄었다. 이벤트 코드 4698로 기록되는데, 스케줄러 내용이 XML 통째로 들어간다. 해커들이 지속성 유지를 위해 스케줄러에 악성 스크립트를 심는 걸 생각하면, 이 로그에서 Command 태그 안에 뭐가 들어있는지 보는 게 꽤 중요한 체크포인트가 된다. 이 로그를 수집하려면 로컬 보안 정책에서 Audit object access를 Success, Failure 둘 다 켜야 한다는 점도 기억해 둘 필요가 있다.