다음 표는 윈도우에서 제공하는 애플리케이션별 로그 저장 위치에 대한 정보를 표로 정리한 것이다. 각각의 애플리케이션의 자세한 옵션항목은 속성에서 확인할 수 있다.

로깅 속성에 따라 로그 보관 기관과 로그 파일 관리 방식을 설정할 수 있다. 간혹 침해사고분석을 하다보면 로그 파일 크기를 제한해서 분석에 필요한 로그가 없는 경우가 있다. 이런 경우는 로깅 옵션에 파일 크기를 작게 설정해 두어서 그렇다.

웹 로그 형식은 웹 서버의 종류(아파치, 톰캣, IIS, Resin)에 따라 다양한 형태로 기록된다. 이는 로그에 기록되는 항목과 옵션 항목의 기록 순서가 틀릴 수도 있다는 의미이다. 로그 형식의 대표적인 종류는 아파치 로그 형식인 Common Log Format와 앞서 여러분이 살펴본 윈도우의 W3C 형식이 있고, 이외에도 로그를 기록하는 형식은 다양하다. (IISW3C, NCSA, IIS, IISODBC, BIN, IISMSID, HTTPERR, URLSCAN, CSV 등)

표 웹 애플리케이션 로그 샘플

윈도우 시스템 경로에 있는 Temp 디렉터리에 애플리케이션이나 기타 프로그램 관련 임시 파일 및 로그가 저장 된다. 일부 악성코드는 설치 로그를 Temp 폴더에 저장하기 때문에 로그 점검 시 system.tmp 파일도 점검하는 것을 놓치면 안된다.

백도어 프로그램 중 하나인 HKDOOR는 공격 대상 시스템에 악성코드를 감염 시키는 과정이 system.tmp 파일에 기록된다. 다음 로그가 실제 악성코드를 시스템에 설치하면서 발생한 로그다.

윈도우에서 제공되는 방화벽은 로깅이 가능하다. 다음은 윈도우에서 자체 방화벽 로그를 설정하는 방법이다. 허용 로그를 기록하여 침해사고가 발생했을 때 네트워크 통신 내역을 분석 정보로 활용 할 수 있다.

네트워크 통신 정보는 재부팅 되거나 통신이 종료되면 사리지는 정보다. 하지만 방화벽 로깅을 통해서 분석에 활용할 수 있게 된다.

사전식 대입공격이라 함은 흔히 무작위 대입공격, 또는 패스워드 추측공격으로 침입탐지 시스템이나 패킷 분석 시 자주 나타나는 공격 유형 중 하나 이다.

자주 보이는 만큼 대비를 많이 하여 실제 위험도는 낮지만 방심하면 언제든지 공격을 당할 수 있다.

이번에 소개할 사례도 잠깐의 방심으로 침해가 발생한 사례다. 해당 침해사고는 시스템 침입이 발생되고 CERT팀으로 시스템 점검 의뢰가 접수 되었다.

확인된 증상으로는 시스템에서 아웃바운드로 비정상 트래픽이 발생하고, 시스템에 파일들이 생성되었다는 내용 이다.

시스템 분석을 위해 IDC로 이동하였고, 이동 후 시스템 관리자를 통해 시스템 운영현황과 구성을 파악하였다.

특정 Application 관련 서버로 사용하기 위해 시스템을 재설치 하였고 재설치 후 인터넷 연결 1시간 만에 이상 증상이 발생 되었음을 전달 받았다. 침해가 발생한 시스템이 설치된 네트워크에는 F/W등의 네트워크 보안 장비가 설치 되지 않았었다.

시스템 점검을 위해 침해사고가 발생된 것으로 의심되는 시스템 하드를 별도의 서버에 마운트하여 분석을 시작하였다.

시스템을 마운트 하고 가장 먼저 점검 시스템의 실행 명령 내역을 점검 하였다. 확인 결과 여러 사이트에서 파일을 다운로드 하였고, 파일을 다운로드 후 피해 시스템에서 실행 시킨 흔적이 확인 되었다.

실행된 명령 내역을 살펴 보니 특정 사이트의 URL을 통해 압축된 프로그램을 다운받아 압축을 풀고 파일에 포함된 스크립트 파일을 실행 시키는 행위가 반복적으로 나타났다.

스크립트를 실행 시키면서 IP 대역을 인자값으로 사용하는 것도 확인 할 수 있었다.

실행된 명령내역을 점검하며 다운로드 한 파일들은 별도로 다운로드 하여 시스템 점검과 툴분석을 병행 하였다.

시스템 침해 경로는 시스템로그를 통해 쉽게 찾을 수 있었다.

침해시스템에 구동중인 SSH 서비스를 대상으로 특정 IP에서 사전식 대입공격이 이뤄졌고, 단 4번만의 시도로 접속이 성공된 것이 확인 되었다.

다음은 실제 침해발생 시스템의 secure 로그다. 사전식 대입공격을 시도한지 4번만에 로그인 패스워드 획득에 성공한다. “Accepted password” 로그는 성공적으로 로그인이 이뤄지면 남는 로그다.

총 15회 대입공격을 시도 하였다.

공격 성공은 4번째 시도에 이뤄졌고, 사전식 대입 공격툴은 준비한 사전파일의 모든 계정 패스워드를 시도하고 공격을 종료 하였다.

분석 과정에서 피해 시스템을 공격한 툴이 공격자에 의해 피해 시스템에도 다운로드 한 것을 분석과정에서 확인 하였다. 공격자는 동일한 방식으로 시스템을 공격하고 성공하면 동일한 프로그램을 다운로드 하고 또 다른 시스템을 공격하는 방식으로 공격을 진행하고 있는 것으로 추정 되었다.

해당 프로그램의 사전파일의 4번째 패스워드가 실제로 피해시스템에서 설치 시 설정된 패스워드와 동일한 것으로 확인 되었다. 침해사고가 발생된 시스템에 초기 패스워드가 쉬운 패스워드로 설정되었고, 이 상태에서 인터넷에 연결되어 “흔히” 발생하는 사전식 대입 공격에 의해 시스템 침해가 발생된 것이.

해당 시스템은 점검 후 재포맷을 하고, 패스워드에 대해서도 강화된 패스워드로 변경하여 설정 되었다. 실제 필드에서 침해사고로 시스템을 분석하다 보면 금번 사례와 같이 사소한 실수로 시스템이 공격자에 의해 장악되는 경우를 자주 보게 된다.

항상 공격은 어렵고 복잡한 경로를 통해 이뤄지는 것보다 허술하거나 관리가 소홀한 곳을 통해 이뤄진다.

시스템 로그 중 secure로그나 auth.log로그에는 로그인 성공, 실패 내역이 기록된다. 사전식 대입공격이 발생하면 시스템에 다량의 로그인 실패가 발생되기 때문에 공격을 시도한 내역에 대해 확인이 가능하다. 실제로 사전식 대입 공격으로 침해가 발생되었던 시스템의 로그를 함께 살펴보자.

사전식 대입 공격으로 침해가 발생되었고, 해당 로그가 secure로그를 통해 확인 되었다. 로그를 살펴보면 특정 IP(123.xxx.xxx.68)에서 tty타입이 SSH(SSH접속 시도)로 인증이 실패되었다. 인증을 시도한 사용자는 root였다. 해당 IP에서 몇차례의 인증 실패 후 굵게 표시된 부분을 보면 ‘Accepted password for root’ 구문이 로그에 기록된 것을 확인 할 수 있다. 해당 구문이 root유저의 패스워드 인증이 성공되었다는 로그다. 공격자는 사전식 대입 공격을 통해 여러 번의 패스워드 대입 시도를 통해 root계정으로 로그인이 성공했다. 참고로 사전식 대입 공격 시 정해진 사전파일의 모든 계정정보를 대입하고 프로그램이 종료되기 때문에 아래 로그와 같이 인증이 성공한 후에도 인증 실패된 로그가 계속 남아 있다.

다음은 우분투에 기록된 SSH로그인 로그다. 동일하게 인증을 시도한 계정과 원격 IP, 인증 성공 여부를 확인 할 수 있다.

운영체제에서 남기는 시스템 로그 중 로그인 내역과 로그인 시도가 실패 했을 때, 성공했을 때 로그 기록을 예제로 살펴 보았다.

로그 종류 및 설명은 다음을 참고 하기 바란다.

보안로그를 이용해 컴퓨터 사용 시간 계산하기

앞서 설명한 보안 로그에서 로그온 이벤트와 로그오프 이벤트(이벤트 ID 528, 551)를 이용해 컴퓨터에 로그인해 사용한 시간을 추측이 가능해 진다. 아래 표는 사용자가 컴퓨터에 로그인 후 로그오프한 감사 로그다.

로그를 통해 최초 2014-03-05 오전 12:28:13에 BigRoot사용자가 로그인해 2014-03-05 오전 12:37:20에 로그오프 한 것을 확인 할 수 있다. 사용자는 대략 10분 가량 시스템을 사용한 것을 확인 할 수 있다.

프로그램 실행 추적

이번에는 보안 로그에 기록되는 프로세스 정보를 이용해 실행된 코드를 확인하는 방법이다. 보안 로그 중에 이벤트 ID 593 로그는 특정 사용자가 정상적으로 종료한 프로세스 정보를 기록 한다.

이벤트 ID 593 로그에는 종료한 프로세스 ID와 사용자 이름, 도메인 정보, 로그온 ID가 기록된다. 실제 로그 샘플을 보면 다음과 같다

이벤트 ID 593 샘플 로그에 기록된 정보는 넷바이오스 연결을 통해 프로그램이 실행된 내역이 기록되었다. 프로세스 ID는 3456이고, 이미지 파일로 “C:\WINDOWS\IME\sl.exe” 파일이 사용되었다. 일반적으로 IME폴더에는 sl.exe 실행파일이 존재하지 않는다. 해당 파일은 침해시스템에 공격자가 저장해둔 악성 코드이고, 시스템에 침입한 공격자가 넷바이오스 연결을 통해 sl.exe파일을 실행한 것이다. 실제로 해당 사례는 넷바이오스 연결 후 pstool을 이용해 시스템 명령을 실행했던 사례다.

다음 이벤트 로그는 cmd.exe를 이용해 프로세스 ID 4580이 관리자 계정에 의해 실행된 로그다. 앞선 로그와 차이점은 sl.exe를 실행시킨 사용자는 “ADMIN-DB$”이고, “cmd.exe”를 실행시킨 사용자는 administrator다. 사용자에 “ADMIN-DB$”라고 기록되는 것은 공유목록 이름이며, 넷바이로스 연결을 통해 프로그램이 실행되었다는 의미다.

넷바이오스 연결 보안로그

일반적으로 넷바이오스 연결을 하면 3가지 유형의 보안 로그가 발생 된다. 공통점은 로그온 유형이 3번이고 출발지 IP정보와 컴퓨터 이름이 포함된 로그가 기록 된다는 것이다.

del 옵션을 이용해 연결을 끊게 되면 로그오프(ID 538) 로그가 기록된다.

실행한 명령: net use \\IP /del

원격 명령 실행 로그

넷바이오스(netbiois) 연결을 통해 시스템 명령을 실행하면 윈도우 이벤트 로그에 기록된다. sysinternals 패키지에 있는 프로그램을 이용해서 확인해 보자.

다음은 ‘psexec’ 명령을 실행한 후 이벤트 로그를 확인한 내용 이다.

설명 부분에 “PsExec 서비스가 실행 상태로 들어갔습니다.” 구문이 기록 되는데 이는 pstool 툴에 포함된 ‘psexec’ 명령을 이용해 원격 시스템에 명령을 실행한 것이다.

이벤트 삭제 로그

간혹 공격자가 추적을 방해하기 위해 로그를 삭제 하기도 한다. 로그를 삭제한 행위도 보안로그에 기록되기 때문에 로그가 삭제 되었는지 여부를 점검 할 수 있다.

침해사고나 시스템분석 시 가장 많은 정보를 가지고 있는 항목이 로그다. 실제 시스템 분석 시 가장 많은 시간을 사용하는 부분이 로그를 분석하는 작업이다.

윈도우 시스템에서 발생되는 모든 로그는 이벤트 로그에 남는다. 윈도우의 이벤트 로그를 통해 공격자가 원격으로 접속한 IP 주소나 중요한 접근 정보가 발견되기도 한다. 해킹 흔적이 남기 때문에 공격자에 의해 삭제되기도 한다.

Appendix L: Events to monitor

https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/plan/appendix-l–events-to-monitor

리눅스에서는 ‘logs’ 폴더 및에 기록되는 시스템 로그에 모든 사용자의 행적이 남는다. 시스템 명령 실행에서부터 인증 내역까지 분석에 필요한 정보를 확인한 수 있다.

시스템에 침입하기 위해 어플리케이션을 대상으로 취약점을 공격한다. 최근에는 FTP, Telenet, SMTP등의 애플리케이션이 아닌 HTTP를 대상으로 공격이 가장 많이 발생하고, 실제로도 HTTP를 통해 침해가 많이 발생된다. 그래서 침해사고분석의 해결실마리가 웹 로그를 통해 많이 발견된다.

시스템에서 제공되는 로그 종류를 알아야 분석 시 시스템에서 제공되는 로그를 활용할 수 있다.

보안로그에 기록되는 이벤트는 각각 로그 유형에 따라 이벤트 ID 가 부여 된다. 이 이벤트 ID는 시스템의 보안과 관련있는 설정 변경이나 계정 로그인 실패/성공 등의 정보를 구분 한다.

실제 침해사고가 발생해 시스템을 점검할 경우 보안 로그 분석 시 엄청난 양의 보안 로그를 분석해야 하는 경우가 대부분 이다. 이런 경우 이벤트 ID를 이용해 필요한 데이터를 따로 추출해 로그를 분석 한다. 분석 시에는 앞서 소개한 로그 분석 프로그램을 이용해 이벤트 ID별로 필터링 하여 검색한다.

마이크로소프트에서 제공되는 윈도우 이벤트 ID를 잠깐 살펴보자. 500번대와 관련된 이벤트 로그는 대부분이 로그온과 관련된 로그다. 다음이 간단하게 이벤트 ID와 해당 이벤트에 대한 설명이다. 추가로 이벤트 ID별로 자세한 설명을 책의 마지막에 추가 하였으니 좀더 많은 내용을 검색하고자 하면 참고하기 바란다.

이벤트 ID에 대한 추가 자료는 별첨을 참고하자.

좀더 이벤트 아이디에 대해 자세히 살펴보자. 이벤트 ID중 538번(사용자 로그오프) 로그를 자세히 살펴보자. 해당 이벤트 로그의 이벤트 범주는 다음과 같이 로그온/로그오프 유형에 해당된다. 해당 항목의 경우 로그온 유형이 기록이 된다. 로그온 유형은 시스템에 사용자가 접근한 방식을 의미 하는데 방식을 구분해 보면 크게 시스템에 연결된 키보드와 마우스를 통해 시작화면에서 로그인 하거나 네트워크 연결을 통해 원격으로 시스템에 로그인 하는 경우를 의미한다.

로그온 유형에 표기된 숫자는 각각이 다른 의미를 갖는다. 숫자에 따라 시스템에 로그온/로그오프한 유형이 정의되어 있다. 아래 표가 로그온 유형에 대한 설명 이다.

보안 이벤트를 분석하는 방법도 앞서 소개한 애플리케이션 로그분석과 마찬가지로 로그 형식에 대한 사전 지식이 필요하다. 이벤트로그 각 항목에 대해 의미를 알지 못하고는 정확한 로그 분석이 어렵다.

프로세스 분석을 통해 악성코드를 식별한 사례를 살펴 보자.

백도어 통신이 확인되었고, 통신 연결에 사용된 백도어 프로그램을 찾기 위해 프로세스 점검을 수행 하였다.

악성코드에 감염된 프로세스를 찾기 위해 프로세스 점검을 진행 하였다. 프로세스 중 시스템 부팅 시간과 차이가 발생하는 프로세스를 확인했다. 프로세스 이름은 ‘svchost’ 이고 프로세스 번호는 836번으로 확인됐다.

윈도우에서 svchost 프로세스는 시스템 프로세스다. 윈도우의 여러 서비스를 관리하는 프로세스다. 대부분 윈도우 부팅 시 프로세스가가 올라오기 때문에 부팅 시간과 차이가 나지 않는다. 하지만 중간에 실행된 경우 시간 차이가 발생한다.

프로세스 점검을 통해 의심스러운 프로세스를 확인 하였다. 프로세스 번호가 836번인 프로세스가 악성코드에 감염된 것으로 의심 되었고, 이를 확인하게 상세한 분석작업을 진행 했다.

836 프로세스에서 사용중인 파일을 점검 했다. 다음은 836번 프로세스에서 사용하던 파일 목록 이다.

동적 링크 라이브러리(DLL) 파일 중 의심스러운 파일이 확인 되었다. 파일명은 ‘tcpipt.dll’ 이다.

‘system32’ 폴더에는 ‘tcpipt.dll’ 파일이 존재 하지 않는다. DLL 파일에 대해 좀더 확인하기 위해 추가 분석을 수행 하였다.

어떤 목적으로 프로세스에 로드되었는지 확인해야 한다. 그러기 위해서는 해당 코드가 어떤 기능을 하는지 확인해야 하는데 이는 코드상의 API 사용내역을 통해 대략적으로 확인할 수 있다. PEiD 프로그램을 이용해 API를 확인 할 수 있다.

사용중인 API는 사용자 계정을 컨트롤 하거나 FTP통신에 필요한 API, 레지스트리 수정에 필요한 API 등이 확인 되었다.

사용된 API를 통해 기능을 유추해 보면 사용자 컨트롤이 가능하고, 레지스트리와 파일에 대한 제어 그리고 FTP 통신으로 데이터 전송이 가능하다.

여기까지만 봐도 전형적인 백도어 프로그램들이 제공하는 기능이다. 백도어 파일이 확실시 되고 좀더 정확한 시그니처를 찾기 위해 문자열을 확인 해보자.

많은 수의 악성코드가 파일명만 바꿔 사용하기 때문에 파일에서 악성코드를 확인할 수 있는 특징을 찾아낼 경우 해당 파일의 기능에 대해 좀더 정확히 파악할 수 있다. 주로 확인되는 정보는 프로그램 정보, 제작자 정보, 공격대상, C&C 서버 IP 등을 확인 할 수 있다.

문자열 추출은 ‘Bin Text’ 라는 프로그램을 이용해 확인할 수 있다. 문자열 추출 과정은 악성코드에 하드코딩 형태로 입력된 값을 확인한다.

tcpipt.dll 파일에 포함된 문자열 검색에서 ZXSHELL 구문이 확인 되었다. ZXSHELL은 중국에서 제작된 백도어 프로그램으로 C&C및 원격터미널 등 다양한 기능을 제공하는 툴이다.

분석 결과 공격자는 ZXSHELL 파일을 시스템에 실행 시켰다. 감염된 프로세스를 이용해 중국 IP를 사용하는 공격자와 통신을 연결 하고 감염 시스템 정보를 전송 하였다. 다음은 백도어 파일이 전송한 피해 시스템의 운영체제 정보다. 윈도우 버전 정보와 시스템 IP 정보, CPU 및 메모리 용량 정보를 전송했다.

공격자가 시스템 리소스 정보까지 수집하는 이유는 대규모 서비스 거부 공격(DDoS)을 수행할 때 시스템 사양이 높은 좀비 PC를 활용하기 위해서다.

Cport[1] 프로그램을 이용해 프로세스별 포트 정보를 점검 한다. GUI기반 프로그램으로 포트와 프로세스 정보를 매핑하여 사용자에게 보여주는 툴이다.

IP정보, 포트정보, 프로세스 정보, 파일 정보, 사용자 정보를 한 화면에서 보여 주기 때문에 종합적으로 분석 할 때 유용하게 사용 할 수 있다.

GUI기반이지만 옵션을 이용해 텍스트로 정보를 추출할 수 있기 때문에 스크립트를 이용해 점검도 가능하다. 사용은 다음과 같이 사용 가능하다.

다음이 툴을 실행시킨 결과 일부다. 점검한 프로세스 이름(mstsc.exe)과 해당 프로세스가 사용하고 있는 실행 파일과 IP, Port 정보 등을 추출한다.

추출한 정보는 악성코드로 의심되는 프로세스가 외부 공격자와 통신을 시도하는지 혹은 의도하지 않은 트래픽을 발생시키는지 확인하기 위해서 사용 된다.

리눅스에서는 ‘netstat’ 명령에 p옵션을 이용해 확인 할 수 있다.

실행 파일에 대한 자세한 정보는 ‘ps’ 명령을 실행해 확인 할 수 있다.

로그온 세션 정보

윈도우 시스템의 경우 ‘logonsessions.exe’ 명령을 이용해 로그인한 사용자의 프로세스 정보를 확인할 수 있다. 역시 sysitnernals 패키지에 포함된다. SID 정보, 로그온 대상 시스템 정보, 현재 사용중인 프로세스 정보 등을 확인 할 수 있다.

실행은 logonsessions.exe 실행 시 p옵션을 이용해 확인 가능하고 출력되는 형태는 다음과 같다.

마지막 로그온 정보

윈도우 시스템에서 로그인한 정보를 수집한다. 이는 침해사고가 발생한 경우 시스템에 로그인한 시점을 확인해 침해사고 타임 테이블을 작성 합니다.

타임 테이블은 사건의 앞 뒤를 파악하고, 일련의 시간 흐름에 따라 일어난 현상을 정리하는 것으로 침해사고분석시 매우 중요한 자료가 된다. 침해사고분석 시 가장 먼저 할 것도 최초 침해사고가 발생한 시점, 즉 기준 시간을 확인하는 일이다. 기준 시작이 확인되면 해당 시간을 기준으로 시간 순서에 따라 이전에 어떤 행위가 발생했고, 이 후 어떤 일이 있었는지 확인해 타임테이블을 작성한다.

[1] https://www.nirsoft.net/utils/cports.html

전체 프로세스에 대한 확인 과정이 대략적으로 끝나면 확인된 프로세스 중 의심이 되는 프로세스에 대해 세부적인 조사가 필요할 것이다. 이번에 살펴볼 내용은 의심이 가거나 확인이 필요한 프로세스에 대해 어떤 명령에 의해 프로세스가 실행 되었는지 확인하는 방법이다.

각각의 프로세스를 실행시킨 명령어 확인은 중요 하다. 이는 명령어 확인을 통해 악성코드가 설치된 위치나 시스템 파일의 감염 여부를 확인 할 수 있는 중요한 단서가 되기 때문이다.

리눅스는 ps명령을 이용해 확인 가능하다. 악의적인 프로세스를 확인한 경우 해당 프로세스가 어떤 명령으로 실행 되었는지 볼 수 있다.

–axu 옵션을 이용하면 현재 점유중인 메모리 정보와 CPU정보를 확인할 수 있다.

–axu 옵션을 이용하면 현재 점유중인 메모리 정보와 CPU정보를 확인할 수 있다.

프로세스에서 사용하는 파일

앞서 프로세스를 실행 시킨 명령어를 확인하는 방법을 살펴 보았다. 이번에는 실행 파일 외에도 프로세스에서 사용하고 있는 파일을 확인해보자. 윈도우 시스템의 경우 주로 프로세스에서 사용하고 있는 DLL파일을 점검하게 된다. 윈도우 악성코드의 경우 DLL파일을 이용해 구동중인 프로세스를 감염시키기도 한다. 점검은 ‘handle.exe’ 명령을 이용한다. Sysinternals 패키지에 포함된다.

프로그램을 실행 시키면 앞의 그림과 같이 프로세스에서 사용중일 파일들을 확인 할 수 있고, 프로세스가 사용하는 개체 정보와 접근(읽기R, 쓰기W, 삭제D) 정보가 나타난다. 관련 옵션은 “handle -?” 명령을 이용해 확인하자.

프로세스 점검 과정을 통해 의심스러운 프로세스 목록을 확보 하고 프로세스가 사용하는 실행파일 경로를 확인한다. 확인된 실행 파일이 악성코드인지 분석한다.

윈도우 프로세스에서 사용하는 객체는 File 외에도 여러 가지가 있다. 윈도우 개체 종류는 다음 표를 참고 하기 바란다. (자료참고: Microsoft Windows Internals)