Endpoint
zeek이 우리망 내에 떠도는 로그들을 수집하여 중앙관제서버(SplunkServer)로 넘겨줍니다. 중앙관제서버는 그 로그들을 분석합니다(http, dns, ...). WebServer에서 발생하는 트래픽 또한 zeek이 받아서 중앙관제서버로 넘겨줍니다.
=> **마지막으로 Sysmon!!**
그림에서 ZeekIDS, WebServer, Sysmon과 같은 것들을 endpoint라고 하는데, 밑에 더이상 부착되는 시스템이 없는 마지막 지점이라고 해서 endpoint 라고 합니다. endpoint는 서버보다는 클라이언트 PC를 의미하는 경우가 많습니다. 요즘 서버들은 리눅스 베이스로 설치되어 있는데, 직원들이 사용하는 PC들은 윈도우인 경우가 많습니다. 우리 직원들이 사용하고 있는 PC에서 발생하는 로그들을 Splunk로 보내면 Splunk는 윈도우 사용자들의 로그들을 분석합니다. 우리 직원들 PC에 이러한 변화가 있구나를 분석합니다.
=> 아래 설명/실습에서 윈도우 pc를 사용하고 있는 것들을 endpoint라고 지칭
Sysmon
- Microsoft의 Sysinternal suite에 포함된 시스템 모니터링 도구
- 기본 윈도우 이벤트 로그로는 한계가 있는 프로세스 생성, 네트워크 연결, 파일 생성 시간 변경 등의 정보를 추출한 후 윈도우 이벤트 저장소에 저장
- 이벤트 기반 정보가 아닌 '행동 기반 정보'를 수집하여 이벤트 저장소에 저장
Sysmon 기능
- 실행 프로세스와 부모 프로세스의 로그를 저장(자식 프로세스가 누구에 의해서 실행되었는지 확인 가능)
- 실행 프로그램의 해시값을 기록하여 무결성 확인 가능
- 네트워크 연결 시 IP 주소, 포트번호, 호스트명, 포트명 등을 기록
- 레지스트리에서 환경설정이 변경된 경우 자동으로 다시 읽어들임
Sysmon 설치
1. 파일 다운로드 후 설치
1) C드라이브에 Sysmon.zip 압축해제
Sysmon 다운로드 : https://learn.microsoft.com/ko-kr/sysinternals/downloads/sysmon
2) cmd 창을 관리자 권한으로 실행 및 이벤트 뷰어 열기
C:\Windows\system32>cd c:/sysmon
c:\Sysmon>dir
2. sysmon 활성화
1) 명령어 입력 > c:\Sysmon>sysmon64.exe -accepteula -i
2) 이벤트 뷰어에 Sysmon 폴더 생성된 것을 확인
이벤트 뷰어 > 응용 프로그램 및 서비스 로그 > Microsoft > Windows > Sysmon
=> Windows 로그는 Windows10 자체의 운영에 대한 로그들
=> 응용 프로그램 및 서비스 로그는 사용자가 설치한 개별적 프로그램들에 대한 로그들(특정 애플리케이션 로그)
=> 로그를 자세히 보면 프로세스가 언제 생성/종료 되었는지, 시스템에서 어떠한 작업들이 진행되었는지 확인 가능
=> 로그 하나를 클릭하고 하단을 보면 로그이름, 원본, 이벤트, 수준 등을 볼 수 있는데, 이것이 로그필드명이라고 보면 됨
Sysmon 생성 이벤트 목록
ID | 이벤트 이름 | 활용 방안 |
1 | Process creation | 새로운 프로세스가 만들어지면 생성되는 로그 프로세스가 실행되었을 때 사용된 명령어의 전체 줄을 이벤트로 기록 |
2 | A proccess changed a file creation time | 프로세스가 파일 생성시간을 수정시 기록 공격자가 백도어 파일을 설치하면서 운영체제 파일을 위장하는 것을 탐지 가능 |
3 | Network Connection | 호스트에서 TCP/UDP 연결기록을 로그로 생성 어떤 프로세스가 네트워크 접속을 시도했는지 파악할 수 있고 IP주소, 호스트명, 포트번호 등 정보를 제공 |
5 | Process terminated | 프로세스가 종료되면 로그 생성 |
Sysmon 설정
- 윈도우 운영체제에 설치되는 시스템 모니터링 도구
- 프로세스 생성/종료, 파일 생성/수정 시간 기록, 네트워크 설정 정보(IP, Port Number, ...)
=> 윈도우는 Splunk Forwarder가 있는데, 이는 agent임. 보통 ZeekIDS나 WebServer는 rsyslog로 로그가 넘어갈 수 있지만 agent를 통해서 로그정보를 넘기는 경우도 있음
=> 윈도우에서는 agent를 설치하여 agent를 통해서 sysmon로그를 SplunkServer로 넘겨줘야함
=> 실습에서는 Forwarder를 통해서 sysmon 로그 정보들이 SplunkServer로 넘어왔다는 전제하에 로그분석을 진행할 예정
1) C:\Program Files\Splunk\var\lib\splunk 디렉토리 열기
2) 해당 디렉토리에 sysmon.taz 압축 해제
=> 해당 디렉토리는 $SPLUNK_DB 인덱스 저장소임
3) indexs.conf 파일에서 sysmon index 관련 환경설정
3-1) C:\Program Files\Splunk\etc\apps\search\local 디렉토리로 이동
3-2) indexes.conf 파일 수정
4) Splunk server 재시작
설정-시스템-서버 컨트롤-Splunk 다시시작 클릭
5) sysmon 로그 검색
검색 > index=sysmon
=> 로그가 잘 로딩됨ㅎㅎ
PC 이상 징후 분석
1. 비정상 폴더에서 exe 파일 실행
2. 파일 실행 후 원본 파일 삭제
3. 실행 후 네트워크 접속 다수 발생
4. 네트워크 Shell 실행
=> Endpoint, 즉 PC에서는 악성코드가 반영이 돼서 실제 실행이 되는 최종목적지이기 때문에 이런 목록들을 추적할 수 있음
1. 비정상 폴더에서 exe 파일 실행
● 윈도우 실행파일 위치
C:\Program Files, C:\Program Files(x86), C:\Windows, C:\Window\system32
=> 로그에서 파일의 실행경로를 검색했을 때, 휴지통에서 실행되었다면 이는 비정상이므로 관제 대상이 됨
=> 비정상적인 위치에서 실행되었다면 이는 악성코드가 실행되었다고 추측할 수 있음
● 일반적으로 공격에 사용되는 악성코드는 단독 실행 파일로 동작
: 다운받은 악성코드가 처음부터 실행파일 위치(시스템폴더)에 설치되지 않음
● 최초 실행 폴더를 탐지하는 방법이 중요함!!
=> 인터넷으로 다운받은 파일이 최초로 실행되는 폴더를 탐지하여 악성코드 유포지를 탐지
index=sysmon sourcetype="WinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1
(CurrentDirectory!="*Program FIles*" AND CurrentDirectory!="*system32*")
(Image!="*system32*" AND Image!="*Program FIles*" AND Image!="*SysWOW64*")
[ search index=sysmon sourcetype="WinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1
| rare CurrentDirectory limit=10 showperc=f showcount=f] | table Image
=> sysmon 저장소에 있는 로그 대상으로 검색, sourcetype은 "WinEventLog:Microsoft-Windows-Sysmon/Operational” 형태 필드와 일치하는 로그들을 검색, 프로세스 실행이 된 파일들의 로그들을 검색
** EventCode = 1은 프로세스 생성을 의미(정상적으로 실행되었음을 의미)
=> 디렉토리명이 profgramfiles, system32 또는 관련된 이름을 가진 로그들은 검색대상에서 제외(프로그램이 실행된 디렉토리가 시스템폴더가 아닌 것을 검색 -> 이곳에 있는 것들은 정상적인 것들이기 때문에)
=> 위에서 필터링한 로그들(정상로그 제외) 중에서 자주 사용하지 않는 희귀한 위치에 있는 로그들을 검색. 이 부분은 서브 쿼리!! CurrentDirectory 값 중에 특이한 값 찾기
** [search]는 하위 검색을 나타내는 2차 검색. 하위검색을 사용하는 이유는 검색범위를 줄이기 위함
=> 결과는 테이블로 출력
=> 로그자체에서 실행파일이 있는 것을 확인
=> 특이점 : 첫번째 줄에 있는 것은 휴지통에서 실행됨을 확인(RECYCLE은 휴지통)
=> 휴지통에 악성코드를 넣어놓는 것은 공격성이 있는 파일임을 추측
2. 파일 실행 후 원본 파일 삭제
● 하드디스크에 저장된 악성코드는 프로세스 상태가 되어야 PC들을 감염시킬 수 있음
● 악성코드 파일 실행 후 원본파일을 디스크에서 삭제해서 분석을 회피하기도 함(프로그램 실행 후 원본 파일을 디스크에서 삭제하는 행위는 정상적이지 않음)
=> A라는 파일이 실행되었는데 실행 후 해당 파일이 삭제가 되었다면 의심
=> 예를 들어, A파일이 실행되어 B를 실행하고, 자기자신은 흔적을 남기지 않기 위해 A를 삭제하는 경우가 있음
**프로그램과 프로세스의 차이**
프로그램
- 하드디스크에 저장됨
- 정적인 상태
- 저장 매체에 존재하는 실행 가능한 코드
프로세스 : 실행 중인 프로그램으로 메모리에 로드되어 실행되고 있는 상태,
프로세스 : 프로그램이 CPU와 RAM을 만나서 실행 중인 프로그램이 됨.
=> 하드디스크에 저장된 악성코드가 RAM으로 상주되면서 CPU를 만나 프로세스가 되면서(실행되면서) 원본 파일을 삭제하는 행위를 할 수 있음(비정상적 행위)
loading : 하드디스크에 저장되어 잇는 파일을 RAM으로 이동하는 작업
saving : RAM에 있는 내용을 하드디스크에 저장하는 행위
index=sysmon sourcetype="WinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1 ParentImage="C:\\windows\\explorer.exe"
[ search index=sysmon sourcetype="WinEventLog:Microsoft-Windows-Sysmon/Operational"
| where NOT isnull(Image) AND NOT isnull(ParentImage)
| search CommandLine="* del *"
| table ParentImage
| rename ParentImage AS Image] | table Image
=> 파일탐색기에서 실행된 것 검색
** C:\\windows\\explorer.exe : 파일탐색기
=> CommandLine에 del이 포함되어 있는 파일 원본을 테이블로 추출
=> 즉, 특정 프로세스에서 del 명령어를 실행한 프로세스를 식별
=> 운영체제 기능 중 파일 관리는 파일시스템을 통해 관리하는데 보통 윈도우는 파일 탐색기를 통해 파일을 관리함
=> 코드 해석 : 방금 전에 파일 탐색기에서 실행한 파일이 곧바로 삭제되었다면, 삭제된 파일의 원본위치를 출력해줘
=> 실행되자마자 삭제된 파일들
** ParentImage : 프로그램을 실행시킨 위치가 어딘지 파악
=> 파일 탐색기는 하드디스크에 저장된 파일일까? yes!!
3. 실행 후 네트워크 접속 다수 발생
● 과다접속을 유발하는 트래픽 검색
● 실행경로가 아닌 곳에서 실행되는 프로세스 검색
=> 어떤 파일이 실행이 되었는데, 이 파일이 실행되자마자 연속적으로 다른 다수의 접속이 진행이 되는 경우 악성코드가 실행되는 것이라고 추측
=> 파일을 실행하는 순간에 여러 장소에 동시에 접속하려는 네트워크 접속 흔적이 남아있다면 과다접속 또한 일종의 악성코드의 실행이라고 추측
index=sysmon sourcetype="WinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1
(Image!="C:\\Windows*" AND Image!="*Program FIles*")
[ search index=sysmon sourcetype="WinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=3
(DestinationIp!="10.0.0.0/8" AND DestinationIp!="172.16.0.0/12" AND DestinationIp!="192.168.0.0/16")
| stats count(DestinationIp) AS total_count dc(DestinationIp) AS uniq_count by Image
| where total_count > 50 OR uniq_count > 20
| table Image] | table Image
=> sysmon 저장소에 있는 로그 대상으로 검색, sourcetype은 "WinEventLog:Microsoft-Windows-Sysmon/Operational” 형태 필드와 일치하는 로그들을 검색, 프로세스 실행이 된 파일들의 로그들을 검색
=> 실행파일 위치가 시스템 폴더인 것들은 제외(시스템 폴더에서 실행되는 것은 정상이므로 제외)
=> 네트워크 로그들(IP, 호스트명, 포트번호 등 어딘가에 접속되어 있을 때 남기는 로그 정보)만 검색
** EventCode = 3 : 네트워크 정보 로그
=> 네트워크 주소 중에 destinationIp가 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0./16인 것들은 제외하고 검색
: 사설 IP는 검색대상에서 제외, 보통 사내망은 사설IP 사용, 외부로 나가는 트래픽이 아닌 내부 통신에 사용되는 것들은 제외
: 목적지가 공인IP인 로그들만 검색하겠다는 의미
: 사내망의 어떤 PC가 외부로 나가는 트래픽을 감지, 즉, 네트워크 관련 실행파일이 외부로 향하는 경우를 검색
: 이는 악성코드의 감염이나 외부 C&C (Command and Control) 서버와의 통신을 검색하는데 사용될 수 있음
=> Image를 기준으로 외부로 향하는 패킷들의 개수가 50번, 해당필드에서 고유값을 가지는 로그 수가 20개를 초과하는 것들을 테이블로 추출
* count : 함수는 특정 필드에 대한 전체 이벤트 수를 계산
* dc : 해당 필드에서 고유한 값을 가지는 이벤트의 수를 계산
4. 네트워크 Shell 실행
● netsh.exe : 현재 실행 중인 컴퓨터의 네트워크 구성을 표시하거나 수정할 수 있는 명령줄 스크립팅 유틸리티
* Command-Line Scripting(명령줄 스크립팅 유틸리티) : 여러 명령어를 순차적으로 실행하여 자동화된 작업을 수행하는 프로세스
index=sysmon sourcetype="WinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1
| where match(Image, "netsh.exe$")
| where NOT isnull(ParentImage)
| table ParentImage, Image, CommandLine
=> 정확하게 실행된 파일이 netsh.exe 이름을 가지고 있다면 아래줄 실행
=> 하드디스크에서 실행되는 것은 아닌(파일탐색기에서 실행된 것이 아닌), 즉, 웹과 같은 uri를 통해서 실행된 것들을 검색
=> 쉘 프로그램이 실행된 것 찾기
=> 시그니처로 하는 방법도 있는데, 그러면 IDS 사용하는것이 좋음
=> 웹쉘이 실행되었는지를 확인하려면 웹쉘의 파일명을 알고 있어야함
=> 웹쉘의 경우 웹쉘 파일명을 기반으로 검색(정확하게 특정 파일명이 실행되는지를 확인)