개요
현재 Microsofts에서 제공하는 도구 모음인 Sysinternalsuite에는 Sysmon이라는 도구가 있다. Sysmon은 윈도우 운영체제에서 높은 수준의 모니터링을 제공한다. 백그라운드에서 실행되며 모니터링 결과를 이벤트 로그에 기록한다. 이러한 유용한 기능을 제공하는 Sysmon은 많이 알려져 있으나 그 결과가 이벤트 로그에 저장되기 때문에 실시간으로 결과값을 보는 것이 기존 SIEM이나 다른 장비에 연동하기 어렵다면 모니터링이 불편하였다. 하지만, 오픈소스인 ELK Stack의 다양한 기능을 이용한다면 이점을 커버할 수 있다.
이번 포스팅에서는 Sysmon에 대하여 알아보고 생성블로그관리된 로그를 ELK Stack을 통해 모니터링 하는 방법에 대하여 알아보고자 한다.
Sysmon 설치
우선적으로 이번 프로젝트에 중심이 될 Sysmon을 설치한다. https://docs.microsoft.com/en-us/sysinternals/downloads/sysmon에 설치한다.
다운 받은 Sysmon을 압축 해제하고 Command 창을 이용하여 설치한다. Sysmon 설치와 관련한 옵션은 “-h” 옵션을 통해 자세히 확인할 수 있다.
[그림 1] Sysmon64.exe -h
Sysmon을 더 유용하게 사용하기 위해서는 config 파일을 이용하여야 한다. 직접 설정하는 방법도 있으나 이미 github를 이용해 공개된 Sysmon config파일을 이용하는 방법을 추천한다. 부족한 부분은 제외하고 추가할 부분을 추가하여 설정이 가능하다.
설정 파일은 공개된 github(https://github.com/SwiftOnSecurity/sysmon-config)에서 다운로드 하였다.
설치 명령은 다음과 같다.
| Sysmon64.exe -accepteula -i C:\Users\Administrator\Desktop\Sysmon\sysmonconfig-export.xml -l -n |
[그림 2] Sysmon 설치
최초 설치에는 “-I” 옵션을 사용했으나 이후 설정파일에 변경이 있다면 “-c” 옵션으로 변경된 옵션을 적용할 수 있다.
설치가 끝나면 자동으로 Sysmon이 작동이 되는데 비스타 이후 버전은 Applications and Services Logs/Microsoft/Windows/Sysmon/Operational 경로에 Sysmon로그가 쌓이며 이전 버전은 System event 로그에 쌓이게 된다. 윈도우에서 기본으로 제공하는 이벤트 뷰어로 확인이 가능하다.
[그림 3] EventLog
Sysmon의 이벤트 로그는 다음과 같이 저장되며 의미를 가진다.
| Event ID | 설명 |
| 1 | 프로세스 생성 |
| 2 | 프로세스가 파일 생성시간을 변경 |
| 3 | 네트워크 연결 |
| 4 | Sysmon 서비스 상태 변경 |
| 5 | 프로세스 종료 |
| 6 | 드라이버 로드 |
| 7 | 이미지 로드 (“-l” 옵션으로 활성화 필요) |
| 8 | 다른 프로세스에서 스레드 생성 |
| 9 | RawAccessRead 탐지 (프로세스가 “\\.\” 표기법 이용하여 드라이브 접근시) |
| 10 | 특정 프로세스가 다른 프로세스 Access (ex. Mimikatz > lsass.exe) |
| 11 | 파일 생성 (생성 및 덮어쓰기) |
| 12 | 레지스트리 이벤트 (키 값 생성 및 삭제) |
| 13 | 레지스트리 이벤트 (DWORD 및 QWORD 유형의 레지스트리 값 수정) |
| 14 | 레지스트리 이벤트 (키 및 값 이름 변경) |
| 15 | FileCreateStreamHash (파일 다운로드와 관련된 Zone.identifier 확인) |
| 17 | PipeEvent (파이프 생성) |
| 18 | PipeEvent (파이프 연결) |
| 19 | WmiEventFilter 활동이 감지 됨 (악성코드 실행시 사용될 가능성 있음) |
| 20 | WmiEventConsumer 활동이 감지 됨 |
| 21 | WmiEventConsumerToFilter 활동이 감지 됨 |
| 255 | Sysmon 오류 |
[표 1] Sysmon Event ID
ELK란 Elasticsearch, Logstash, Kibana의 3가지 오픈소스를 부르는 말이다.
| Elasticsarch : 분산 검색 엔진, 데이터 저장
Logstash : 입력 값 필터링 Kibana : 시각화 도구 Beats : 시스템 정보 및 파일 로그 전달 등의 기능 |
위에 4가지 도구를 이용하여 Sysmon 모니터링 도구를 만들고자 한다. 기본적으로 ELK를 설치하는 방법은 지난 포스팅에서 설명하였기 때문에 자세한 ELK 설치 방법에 대해서는 따로 언급하지 않고 설정과 관련된 부분을 다루려고 한다. 설치와 관련된 정보는 ELK 스택의 사이트(https://www.elastic.co)에서 얻을 수 있다.
전체적인 구성도는 Sysmon을 설치한 파일에 Winlogbeats를 설치하고 해당 데이터를 ELK가 설치된 서버로 전송하는 방식이다. 각각 Logstash는 5044포트로 데이터를 받아 Elasticsearch로 보내고 Kibana의 5601포트로 결과값을 확인 가능하다.
[그림 4] Sysmon + ELK 구성도
Beats 설정
Beats는 경량 로그 수신기로 여러 종류가 있다. 이 중 Winlogbeats는 Eventlog를 전달해주는 역할을 한다. Sysmon을 전달하기 위해서 Sysmon이 설정된 시스템에 Winlogbeats를 설치하고 다음과 같이 설정 파일을 변경해준다. 설정 파일의 내용은 다음과 같다. (winlogbeat.yml)
[그림 5] Winlogbeat.yml
아래와 같은 명령어로 실행이 가능하며 ELK 사이트에서 서비스로 등록하는 방식을 참고하면 서비스로 등록하여 사용이 가능하다.
| C:\Users\Administrator\Desktop\winlogbeat>.\winlogbeat.exe -c .\winlogbeat.yml -e |
Logstash 설정
Beats로 전달 받은 데이터를 더욱 효율적으로 보기 위해 Logstash를 이용하여 각각의 값에 항목을 지정해 준다. Logstash의 필터링은 Logstash의 conf 파일을 수정하여 만들 수 있다.
Sysmon의 데이터 중에 의미있는 값을 선별하게 위해 conf 파일을 작성하였다. 하지만 이는 사용자의 설정에 따라 변경되어야하며 필터링으로 인해 더 다양한 이벤트를 탐지할 수 있다.
이벤트에 대한 conf파일을 만들기 위해서는 우선 입력되는 데이터에 대하여 확인하는 것이 중요하다.
입력되는 데이터는 다음과 같다.
[그림 6] Winlogbeat 입력값
입력되는 데이터 부분중 특히 message부분에서 의미있는 값을 찾아낼 수 있다. X-pack 설치후 활용이 가능한 Grok Debugger나 웹페이지 http://grokdebug.herokuapp.com/를 이용하여 Grok 표현식을 통해 message 부분에서 특정 부분을 추출해서 사용할 수 있다.
[그림 7] Grok Debugger – Xpack
input {
beats {
port => 5044
}
}
filter {
if ([event_data][hashes][altsha1]) {
mutate {
split => [“[event_data][hashes][altsha1]” , “=”]
add_field => { “[event_data][hashes][sha1]” => “%{[event_data][hashes][altsha1]][1]}” }
remove_field => [ “[event_data][hashes][altsha1]”]
}
}
if ([event_data][hashes][altmd5]) {
mutate {
split => [“[event_data][hashes][altmd5]” , “=”]
add_field => { “[event_data][hashes][md5]” => “%{[event_data][hashes][altmd5]][1]}” }
remove_field => [ “[event_data][hashes][altmd5]”]
}
}
if ([event_data][hashes][altsha256]) {
mutate {
split => [“[event_data][hashes][altsha256]” , “=”]
add_field => { “[event_data][hashes][sha256]” => “%{[event_data][hashes][altsha256]][1]}” }
remove_field => [ “[event_data][hashes][altsha256]”]
}
}
if ([event_data][hashes][altimphash]) {
mutate {
split => [“[event_data][hashes][altimphash]” , “=”]
add_field => { “[event_data][hashes][imphash]” => “%{[event_data][hashes][altimphash]][1]}” }
remove_field => [ “[event_data][hashes][altimphash]”]
}
}
if ([event_id] == 1) {
grok {
match => { “message” => “http://%{IP:[remote_ip]}/%{GREEDYDATA:[event_data][powershell_file]}'” }
}
}
}
output {
stdout { codec => rubydebug }
elasticsearch {
hosts => [“localhost:9200”]
index => “logstash-winlogs”
}
}
[그림 8] logstash – sysmon.conf (참조: http://www.ubersec.com/2017/12/14/sysmon-elk-monitoring-integration-and-apt34-tools/)
Kibana 설정
입력된 데이터를 시각화하는 Kibana에서는 Sysmon 로그를 이용하여 대시보드를 만들어 볼 수 있다. Kibana의 index-pattern은 Logstash에서 설정한 output의 index 부분으로 정의된다.
[그림 9] Kibana – Discover
이렇게 index된 데이터를 불러와서 Kibana Visualize 작업을 실시한 후 여러 개의 Visualize가 모여서 나만의 Dashboard를 만들 수 있다.
[그림 10] Kibana – Dashboard
X-pack에서 추가된 머신 러닝 기능과 담당자의 메일 등으로 Alert가 가능한 6.0 이상의 버전을 이용하면 더 효율적으로 사용이 가능하다.
[그림 11] Kibana -Xpack 이상 행위 탐지
결론
추가적으로 Windows의 감사정책 및 이벤트 로그를 변경하면 Sysmon에서 로깅하는 데이터 이외에도 의미 있는 데이터를 얻을 수가 있다. 이렇게 전달되는 데이터가 다양해지면 이를 ELK를 이용하여 더 많은 이상행위를 탐지할 수 있다.
이번 포스팅에서 소개한 Sysmon과 ELK가 백신이 함께 시스템을 방어한다면 탐지가 어려운 APT 공격에 충분한 대응 방안이 될 수 있다고 생각한다. 최소한의 비용으로 증가되는 위협에 대응해보자.
참조
https://docs.microsoft.com/en-us/sysinternals/downloads/sysmon
https://github.com/SwiftOnSecurity/sysmon-config
https://cyberwardog.blogspot.kr/2017/03/building-sysmon-dashboard-with-elk-stack.html
http://www.ubersec.com/2017/12/14/sysmon-elk-monitoring-integration-and-apt34-tools/