strings 필드의 순서가 실패 이벤트와 다르다. 실패 이벤트는 5, 10, 19번째 필드에 ID, 로그온 유형, IP 정보가 위치하고 있지만 성공 이벤트는 5, 8, 18번째 필드에 위치한다. (헷갈림 주의) 4월 한 달간 로그온에 성공한 로그온 유형과 ID 및 IP의 발생 현황을 확인해보자.
① select to_string(timewritten, 'dd일'), extract_token(strings,8,'|'),
extract_token(strings,5,'|'), extract_token(strings,18,'|'), count(*)
② from security
③ where to_string(timewritten, 'yyyy-MM') = '2016-04'
and eventid = 4624
④ group by to_string(timewritten, 'dd일'), extract_token(strings,8,'|'),
extract_token(strings,5,'|'), extract_token(strings,18,'|')
조회 결과를 피벗 테이블로 정리한 후, 로그온 유형별 ID 발생 현황을 확인한 결과는 다음과 같다.
 |
| 로그온 유형별 ID 발생 현황 |
다섯 가지 로그온 유형(0:시스템 시작, 2:콘솔 로그온, 3:네트워크 로그온, 5:서비스 로그온, 7:컴퓨터 잠금 해제)이 발생했다. '서비스 로그온(5)'이 약간 생소할 수 있는데, Windows 시스템에서 구동되는 모든 서비스는 프로세스를 실행하는 계정이 지정되어 있다. 제일 많이 발생할 수 밖에 없음.
 |
| 서비스 관리자(services.msc) |
역시 핵심은 네트워크 로그온이다. 네트워크란 놈만 없었다면 이런 고생을 할 필요가 없을텐데(..) 그랬다면 보안에 신경써야 할 상황이란 게 아예 발생하지 않겠지?
 |
| 톰 크루즈 형님만 조심하면 됨 |
일단 3개의 ID(itl, Administrator, ANONYMOUS LOGON)가 네트워크 로그온에 성공했다. ID별로 어디서 왔나 확인해보자. 필터링 기능을 이용하면 간단하다.
 |
| '로그온 유형 3' 필터링 |
 |
| '로그온 유형 3' 필터링 결과 |
필터링만으로도 충분히 확인할 수 있지만 필터링 결과를 이용해서 다시 피벗 테이블을 생성하면 뭔가 더 있어 보이는 보고서를 만들 수도 있다. (차트를 그려주면 더 있어 보임)
'ANONYMOUS LOGON'이 가장 많은데, 동일 네트워크에 속한 Windows끼리는 사용자의 의도와 무관하게 네트워크 공유 서비스에 의한 시스템 차원의 익명 접속이 자동으로 발생하며, 이 때 'ANONYMOUS LOGON' 계정이 사용된다.
옛날에는 익명 접속을 이용해서 시스템 정보를 긁어온다거나 하는 게 가능했지만 이것도 막힌 지 꽤 됐다. 아무 것도 하지 않고 숨만 쉬는 접속이라고 보면 됨. 결국 남는 건 'itl' 계정뿐이다. ('Administrator'는 접니다)
'itl' 계정이 뭘 했는지 살펴보자. 이벤트 로그는 일반적으로 '주체(Subject)'와 주체의 행위가 적용되는 '대상 개체(Target)' 정보로 나뉘며, '주체 계정' 정보는 두 번째 strings 필드에 위치한다.
두 번째 strings 필드의 값이 'itl'인 정보를 조회한 결과는 다음과 같으며, message 필드에서 마침표(.)로 끝나는 첫 번째 문장만을 확인하기 위해 'extract_token(message,0,'.')' 구문을 사용했다.
① select eventid, extract_token(message,0,'.'), count(*)
② from d:\security_1604.evtx
③ where to_string(timewritten, 'yyyy-MM') = '2016-04'
and extract_token(strings,1,'|') = 'itl'
④ group by eventid, extract_token(message,0,'.')
네트워크 공유 자원에 접근했다가 로그오프한 것까지는 좋은데 왠 사용자 계정 변경? 해킹인가? 해당 이벤트 로그를 살펴보자.
이런, '주체'와 '대상 개체'의 순서가 반대다. 이벤트 로그의 필드 순서가 로그 성격에 따라 다르다는 것. 찾아보면 필드 구성 자체가 다른 경우도 꽤 된다. 처음부터 LogParser 접근을 염두에 두고 개발하진 않았을 테니 어쩔 수 없는 상황.
데이터베이스 구축 시 가장 중요하면서도 어려운 작업이 바로 데이터 필드를 일목요연하게 정리하는 '데이터 정규화'라고 할 수 있다. 그리고 필드가 일관된 규칙으로 정규화됐을 때, SQL은 최고의 데이터 분석 성능을 보여준다.
그러나 필드 구성이 다른 데이터, 뒤죽박죽 섞인 데이터는 당연히 SQL로 할 수 있는 게 별로 없다. 어떻게 하면 'itl' 계정이 주체로 활동한 내역만을 확인할 수 있을까? 이벤트 뷰어에는 필터링 기능을 있다.
이벤트 뷰어에서 'XML > 수동 쿼리 편집'을 선택한 후, '<Select Path="Security">'과 '</Select>' 사이에 '*[EventData[Data[@Name='SubjectUsername']='itl']]' 형식의 xpath 구문을 입력하면 모든 이벤트에서 필드 위치와 상관없이 원하는 필드만의 검색이 가능하다.
 |
| 수동 필터링 |
 |
| 수동 필터링 결과 |
확인 결과 'itl' 계정이 주체적으로 발생시킨 이벤트는 5140, 5145 뿐이다. 모두 '파일 공유' 관련 이벤트. 4634, 4738 이벤트는 'itl' 계정이 '대상 개체'이기 때문에 검색되지 않는다. 불편하지만 수동 검색이라도 되니 그나마 다행.
to be continued..
관련 글
댓글 없음:
댓글 쓰기