확인된 공격이 위험한지 아닌지 검증하는 방법은 크게 2 가지로 구분된다. 동적 분석과 정적 분석이 있다. 동적 분석은 공격 행위나 악성 프로그램을 다시 재현하여 실제 어떤 위험을 미치는지 검증하는 방법이고, 정적 분석은 재현 없이 공격 구문 또는 악성 프로그램의 바이너리 코드만을 가지고 위험 여부를 확인하는 방법이다.
공격재현
네트워크를 통해서 이뤄지는 많은 수의 공격들 중 대부분은 무작위 대상으로 취약점 여부를 시도하는 경우가 많다. 그렇기 때문에 보안 솔루션이나 시스템 로그에서 위협의 징후가 포착되었다면 실제 위협이 되는지 여부에 대해 재현을 통해 점검을 진행해야 한다.
2013년 발생했던 취약점 공격 중 위험도가 매우 높았던 공격이 아파치 취약점을 이용했던 공격이 CVE-2013-[1]2251이다. 당시 많은 수의 아파치 서버들이 해당 공격에 취약했고, 빠른 시간에 공격이 자동화된 형태로 확산 되었다.
실제 기업이나 조직에서는 해당 공격에 의한 피해를 막기 위해 운영 중인 소프트웨어의 취약점을 점검했다. 점검하는 방식은 동일한 공격 방식에 취약점 확인을 위해 특정 사이트로 리다이렉션을 시켜서 명령이 실행 되는지 확인을 통해 취약 여부를 가늠했다.
http://[target]/action.do?redirect:[redirecturl]
이처럼 공격 구문이 확보가 가능한 경우에는 동일한 방식으로 재현을 통해 운영하는 시스템의 취약점이 존재하는지 쉽게 확인 할 수 있다.
공격 유형 분석
공격 유형 분석은 체계적으로 위협에 대응하기 위해 필요한 항목 이다. 앞서 얘기 했듯이 보안 분석가는 이벤트 분석을 통해 공격 유형 및 위험도를 평가한다. 공격 유형에 맞는 대응 방안을 수립해 일관된 위협 대응 정책을 유지 한다.
공격단계별 구분
공격자는 목적 시스템에 침투하기 위해 정보를 수집하는 단계를 거친다. 이후 수집된 정보를 이용해 취약 시스템을 공격하고, 권한을 획득하는 과정을 거친다.
침입탐지시스템 이벤트 분석 시 현재 공격이 어떤 단계에 포함되는지 정의하여 대응 우선 순위를 정의 한다. 우선 순위에 따라서 대응 방식이 달라진다. 공격이 정보 수집 단계에 해당하면 사전 예방 활동에 초점을 맞춰서 사고 발생을 예방한다. 공격이 성공 또는 확산되는 상황이라면 최대한 피해복구에 초점을 맞춰 대응 한다.
다음은 단계별 공격 유형과 분석 및 대응에 필요한 점검 항목이다.
단계
공격유형
관련 이벤트 점검 및 결과
정보수집단계
Network Scan Web Scan TCP/UDP Port Scan
서비스(포트) 활성 여부에 대해 확인 시도 공격 대상 시스템에 영향이 없거나, 위험이 적은 이벤트, 분석 우선 순위가 낮다.
취약점공격단계
Email 첨부파일 Anomaly Traffic SQL Injection OS Command Injection Cross Site Scripting directory-traversal Web 취약점공격 Buffer Overflow Application 취약점공격
이벤트 분석 시 실제 공격을 시도하는 단계로 취약점공격 단계에서 공격이 성공하면 침해사고로 이어진다. 실패한 공격과 성공한 공격을 구분하는데 초점을 맞춰 분석한다. 기본 계정 또는 패스워드 취약여부 확인애플리케이션 사용여부 점검관리되지 않는 애플리케이션 점검공격 명령 실행 테스트공격 시도한 버전 및 대상 시스템 버전확인
공격성공단계
Backdoor Trojan Spyware BotNet
공격이 성공한 단계에서는 이전 단계의 취약점 공격 단계에서 실패 또는 성공한 IP가 탐지된 내역이 대부분 존재 한다. 이전 단계로 거슬러 올라가 공격 유형과 공격 대상 범위를 파악 한다 최초 이벤트 분석 시 해킹 또는 침해사고 시 자주 발생되는 시그니처에 대해 선 검색을 통해 분석 시간을 단축 한다
윈도우 시스템 점검 시 각종 애플리케이션 로그와 함께 점검하는 중요한 로그가 이벤트 로그다. 시스템점검 시 초기에 파일로 수집하는 항목 중 하나이기도 하다.
일반적으로 이벤트 로그를 점검하는 방법은 점검 대상 시스템의 로그를 파일로 저장(확장자 evt)해 점검 PC에서 불러와 분석 한다. 점검 과정에서 발생할 변경 사항을 최소화 하고, 원본 파일 손상을 막기 위해 위와 같은 방식으로 점검 한다.
그림 윈도우 이벤트 뷰어
애플리케이션 로그와 마찬가지로 이벤트 로그에 대한 기본적인 형식과 각 항목에 대한 이해가 있으면 좀더 효율적으로 분석 작업이 가능하다. 특히 이벤트 로그의 경우 이벤트 ID별로 각각이 의미하는 내용이 틀리다. 기본적으로 Windows Server 제품군 운영 체제를 실행하는 컴퓨터는 다음과 같은 세 가지 종류의 로그에 이벤트를 기록한다. 사용자의 로그인 성공/실패를 기록하는 보안로그, 시스템 구동 중에 발생되는 응용프로그램의 오류 및 특이 사항을 기록하는 응용프로그램, 드라이버 충돌 및 오류관련 로그를 기록하는 시스템 로그 총 3개의 이벤트 로그를 기록 한다.
로그 종류
설명
응용프로그램 로그
응용 프로그램 로그에는 응용 프로그램이나 프로그램에서 기록한 이벤트가 포함됩니다. 예를 들어 데이터베이스 프로그램에서 응용 프로그램 로그에 파일 오류를 기록할 수 있습니다. 로그할 이벤트는 응용 프로그램 개발자가 결정합니다.
보안 로그
보안 로그에는 파일이나 다른 개체 만들기, 열기 또는 삭제 등의 리소스 사용과 관련된 이벤트뿐만 아니라 올바른 로그온 시도 및 잘못된 로그온 시도와 같은 이벤트가 기록됩니다. 예를 들어 로그온 감사를 사용하는 경우 시스템에 로그온하려는 시도가 보안 로그에 기록됩니다.
시스템 로그
시스템 로그에는 Windows 시스템 구성 요소에서 기록한 이벤트가 포함됩니다. 예를 들어 시스템을 시작하는 동안 드라이버나 다른 시스템 구성 요소의 로드에 실패하면 시스템 로그에 기록됩니다. 시스템 구성 요소가 기록하는 이벤트 유형은 서버에 의해 미리 정해져 있습니다.
표 윈도우 기본 이벤트 로그
언급한 로그 외에도 사용 프로그램이나 환경에 따라 이벤트 로그에 추가적으로 다른 종류의 로그가 생길 수 있다. 예를 들어 윈도우 운영체제에 디렉터리 서비스를 운영하거나 파일 복제 서비스(파일서버)를 운영할 경우 해당 로그가 추가적으로 발생된다.
디렉터리 서비스 로그
디렉터리 서비스 로그에는 Windows Active Directory 서비스에서 기록한 이벤트가 포함됩니다. 예를 들어 서버와 글로벌 카탈로그 사이의 연결 문제는 디렉터리 서비스 로그에 기록됩니다.
파일 복제 서비스 로그
파일 복제 서비스 로그에는 Windows 파일 복제 서비스에서 기록한 이벤트가 포함됩니다. 예를 들어 도메인 컨트롤러가 시스템 볼륨 변경 정보로 업데이트되고 있는 동안 발생하는 파일 복제 실패와 이벤트는 파일 복제 로그에 기록됩니다.
DNS 서버 로그
DNS 서버 로그에는 Windows DNS 서비스에서 기록한 이벤트가 포함됩니다.
표 윈도우 추가 이벤트 로그
윈도우 이벤트 로그는 Windows를 시작할 때 이벤트 로그 서비스가 자동으로 시작된다. 또한 이벤트 로그에 대해 접근 권한을 설정할 수 있어서 그룹정책 편집기(gpedit.msc)를 이용해 이벤트 로그에 대한 엑세스 사용 권한을 설정 할 수 있다. 로그 훼손을 막기 위해 사용하면 좋다.
윈도우와 마찬가지로 리눅스도 여러 종류의 로그가 존재한다. OS에 의해 발생되는 로그는 물론 애플리케이션에 의해 로그가 발생하는 것은 유사하다. 일반적인 로그 종류를 살펴보면 다음과 같다.
가장 대표적인 애플리케이션 로그가 웹 로그다. 윈도우의 대표적인 애플리케이션인 인터넷정보서비스(IIS) 웹 서버 로그를 살펴보자.
IIS 로그는 속성 설정을 통해 실제 기록하고자 하는 로그항목을 선택적으로 사용할 수 있다. 로깅 속성에서 제공하는 로깅 옵션을 살펴보면 다음 표와 같다. (옵션의 버전에 따라 차이가 있다)
옵션항목
설명
기본설정
날짜
작업이 발생한 날짜를 기록
Yes
시간
작업이 발생한 시간을 기록
Yes
클라이언트 IP 주소
서버에 액세스한 클라이언트의 IP 주소를 기록
Yes
사용자 이름
서버에 액세스한 인증된 사용자의 이름을 기록. 하이픈(-)으로 표시되는 익명 사용자는 포함되지 않는다.
Yes
서비스 이름
클라이언트에서 액세스한 인터넷 서비스 및 인스턴스 번호를 기록
No
서버 이름
로그 항목이 생성된 서버의 이름을 기록
No
서버 IP
로그 항목이 생성된 서버의 IP 주소를 기록
Yes
서버 포트
클라이언트가 연결된 포트 번호를 기록
Yes
메서드
클라이언트가 시도한 작업(예: GET 명령)을 기록
Yes
URI 스템
액세스한 리소스(예: HTML 페이지, CGI 프로그램, 또는 스크립트)를 기록
Yes
URI 쿼리
클라이언트가 시도한 쿼리(있는 경우), 즉 클라이언트에서 찾으려고 한 하나 이상의 검색 문자열을 기록
Yes
프로토콜 상태
HTTP 또는 FTP 항목을 기준으로 작업 상태를 기록
Yes
프로토콜 하위 상태
HTTP 항목을 기준으로 작업의 추가 상태를 기록.
Yes
Win32 상태
Microsoft_ Windows (R) 운영 체제에서 사용하는 항목을 기준으로 작업 상태를 기록
Yes
보낸 바이트 수
서버에서 보낸 바이트 수를 기록
No
받은 바이트 수
서버에서 받은 바이트 수를 기록
No
걸린 시간
작업을 완료하는 데 걸린 시간을 기록. ODBC 로깅을 제외한 모든 로그 형식에서 걸린 시간은 다음과 같은 기술적인 문제에 따라 밀리초 단위로 기록된다. 클라이언트 요청 타임스탬프는 HTTP.sys(커널 모드 드라이버)가 요청을 분석하기 전에 첫 번째 바이트를 받을 때 초기화되고 IIS에서 보내기가 완료되면(마지막 보내기) 중지 된다. 걸린 시간은 네트워크를 통한 시간은 반영 되지않는다.
No
프로토콜 버전
클라이언트에서 사용하는 프로토콜(HTTP, FTP) 버전을 기록 HTTP의 경우 HTTP 1.0 또는 HTTP 1.1
No
호스트
호스트 헤더의 내용을 기록
No
사용자 에이전트
클라이언트에 사용되는 브라우저를 기록
Yes
쿠키
보내거나 받은 쿠키의 내용(있는 경우)을 기록
No
참조 페이지
사용자가 방문한 이전 사이트를 기록
No
표 IIS 웹 로그 형식 자료(마이크로소프트)
IIS에서 기록하는 웹 로그가 어떤 것들이고, 또 내용은 무엇인지 알아야 여러분이 로그를 점검하거나 분석할 때 정확하고 효과적으로 분석 할 수 있다. 예를 들어 웹 요청 중에 메소드 형식이 틀린 웹 로그를 검색한다고 가정해보자. 로그를 검색하기 위해서는 메소드가 무엇이고 메소드가 로그에 기록되는지 알아야 한다. 다음과 같은 로그를 찾는다고 가정하자.
물론 로그 파일을 열어 각행을 일일이 검색할 수 있다. 하지만 로그 사이즈에 따라서 일일이 검색하기 불가능할 수 있다.
효과적으로 로그를 분석하기 위해 대부분 로그 분석 툴을 이용하게 된다. 이때 웹 로그 형식을 이해하고 검색을 통해 원하는 결과를 빠른 시간에 찾는 것이 로그 분석의 핵심이다.
다음은 아파치 웹 로그 형식을 표로 설명한 자료다. IIS로깅 옵션과 마찬가지로 클라이언트 IP에서부터 시간, 메소드, 쿠키정보, 헤더정보 등 로그에 기록되는 정보는 다양하다.
다음은 아파치에 기록된 로그 예제다.
127.0.0.1 - frank [10/Oct/2000:13:55:36 -0700] "GET /apache_pb.gif HTTP/1.0" 200 2326
예제 로그의 각각의 정보들이 의미하는 내용은 다음과 같다.
127.0.0.1 (%h)
서버에 요청을 한 클라이언트(원격 호스트)의 IP 주소이다. HostnameLookups가 On이라면 호스트명을 찾아서 IP 주소 자리에 대신 쓴다. 그러나 이 설정은 서버를 매우 느리게 할 수 있으므로 추천하지 않는다. 호스트명을 알려면 대신 나중에 logresolve와 같은 로그를 처리하는 프로그램을 사용하는 것이 좋다. 여기에 나온 IP 주소는 사용자가 사용하는 컴퓨터 주소가 아닐 수 있다. 프록시 서버가 사용자와 서버사이에 존재한다면, 원래 컴퓨터 주소가 아니라 프록시의 주소가 기록될 것이다.
– (%l)
출력에서 “빼기기호”는 요청한 정보가 없음을 나타낸다. 이 경우 여기에 나올 정보는 클라이언트 컴퓨터의 identd가 제공할 클라이언트의 RFC 1413 신원이다. 이 정보는 매우 믿을 수 없기때문에, 긴밀히 관리되는 내부 네트웍이 아니라면 절대로 이 정보를 사용하면 안된다. IdentityCheck가 On이 아니라면 아파치 웹서버는 이 정보를 알아보려고 시도하지도 않는다.
frank (%u)
이는 HTTP 인증으로 알아낸 문서를 요청한 사용자의 userid이다. 보통 이 값은 CGI 스크립트에게 REMOTE_USER 환경변수로 넘겨진다. 요청의 상태코드가 401이라면 (아래 참고) 사용자가 아직 인증을 거치지 않았으므로 이 값을 믿으면 안된다. 문서를 암호로 보호하지 않는다면 이 항목은 이전 항목과 같이 “-“이다.
[10/Oct/2000:13:55:36 -0700] (%t)
서버가 요청처리를 마친 시간. 형식은: [day/month/year:hour:minute:second zone] day = 숫자 2개 month = 숫자 3개 year = 숫자 4개 hour = 숫자 2개 minute = 숫자 2개 second = 숫자 2개 zone = (`+’ | `-‘) 숫자 4개 로그 형식문자열에 %{format}t를 사용하여 다른 형식으로 시간을 출력할 수 있다. format은 C 표준 라이브러리의 strftime(3)과 같다.
“GET /apache_pb.gif HTTP/1.0″ (\”%r\”)
클라이언트의 요청줄이 쌍따옴표로 묶여있다. 요청줄은 매우 유용한 정보를 담고 있다. 첫째, 클라이언트가 사용한 메써드는 GET이다. 둘째, 클라이언트는 자원 /apache_pb.gif를 요청한다. 세번째, 클라이언트는 HTTP/1.0 프로토콜을 사용한다. 요청줄의 여러 부분을 따로 로그할 수도 있다. 예를 들어, 형식문자열 “%m %U%q %H”은 “%r”과 똑같이 메써드, 경로, 질의문자열, 프로토콜을 로그한다.
200 (%>s)
이는 서버가 클라이언트에게 보내는 상태코드이다. 이 정보는 (2로 시작하는 코드) 요청이 성공하였는지, (4로 시작하는 코드) 클라이언트에 오류가 있는지, (5로 시작하는 코드) 서버에 오류가 있는지 알려주므로 매우 중요하다. 상태코드의 전체 목록은 HTTP 규약 (RFC2616 section 10)에서 찾을 수 있다.
2326 (%b)
마지막 항목은 응답 헤더를 제외하고 클라이언트에게 보내는 내용의 크기를 나타낸다. 클라이언트에게 보내는 내용이 없다면 이 값은 “-“이다. 내용이 없는 경우 “0”을 로그하려면 대신 %B를 사용한다.
표 아파치 웹 로그 설명
예제에서 살펴본 항목 외 아파치 웹 서버에서 기록 가능한 항목이다.
형식 문자열
설명
%%
퍼센트 기호 (아파치 2.0.44 이후)
%a
원격 IP-주소
%A
(서버) IP-주소
%B
HTTP 헤더를 제외한 전송 바이트수.
%b
HTTP 헤더를 제외한 전송 바이트수. CLF 형식과 같이 전송한 내용이 없는 경우 0 대신 ‘-‘가 나온다.
%{Foobar}C
서버가 수신한 요청에서 Foobar 쿠키의 내용.
%D
요청을 처리하는데 걸린 시간 (마이크로초 단위).
%{FOOBAR}e
환경변수 FOOBAR의 내용
%f
파일명
%h
원격 호스트
%H
요청 프로토콜
%{Foobar}i
서버가 수신한 요청에서 Foobar 헤더의 내용.
%l
(있다면 identd가 제공한) 원격 로그인명. IdentityCheck가 On이 아니면 빼기기호를 기록한다.
%m
요청 메써드
%{Foobar}n
다른 모듈이 기록한 Foobar 노트(note) 내용.
%{Foobar}o
응답의 Foobar 헤더 내용.
%p
요청을 서비스하는 서버의 정규 포트
%P
요청을 서비스하는 자식의 프로세스 ID.
%{format}P
요청을 서비스하는 자식의 프로세스 ID 혹은 쓰레드 ID. format에는 pid와 tid가 가능하다. (아파치 2.0.46 이후)
%q
질의문자열 (질의문자열이 있다면 앞에 ?를 붙이고, 없다면 빈 문자열)
%r
요청의 첫번째 줄
%s
상태(status). 내부 리다이렉션된 요청의 경우 *원래* 요청의 상태이다. 최종 요청의 상태는 %…>s.
%t
common log format 시간 형식(표준 영어 형식)의 시간
%{format}t
strftime(3) 형식 format의 시간. (지역시간일 수 있음)
%T
요청을 처리하는데 걸린 시간 (초 단위).
%u
원격 사용자 (auth가 제공하며, 상태(%s)가 401인 경우 이상한 값을 나올 수 있음)
%U
질의문자열을 제외한 요청 URL 경로.
%v
요청을 서비스한 서버의 정규 ServerName.
%V
UseCanonicalName 설정에 따른 서버명.
%X
응답을 마쳤을때 연결 상태. X = 응답을 마치기 전에 연결이 끊어졌다. + = 응답을 보낸후에도 연결이 살아있다(keep alive). – = 응답을 보낸후 연결이 끊어졌다. (아파치 1.3 후반 버전에서 이 지시어는 %…c였지만, 전통적인 ssl %…{var}c 문법과 겹쳐서 변경했다.)
%I
요청과 헤더를 포함한 수신 바이트수로 0일 수 없다. 이를 사용하려면 mod_logio가 필요하다.
%O
헤더를 포함한 송신 바이트수로 0일 수 없다. 이를 사용하려면 mod_logio가 필요하다.
표 아파치 웹 로그 형식 [1]
아파치 로그 형식을 파악했으니 앞서 소개했던 로그 검색 예제를 참고해 여러분이 분석 시 상황에 맞게 원하는 결과를 검색하기 바란다.
운영체제 로그
SSH를 통한 로그인 시도에서부터 시스템에 마지막으로 로그인 했던 내역까지 시스템에 남아 있는 로그를 통해 확인이 가능하다. 대부분의 사전식 대입 시도는 “secure” 로그를 통해 확인이 가능하다. 시스템 로그 분석 시 점검하는 항목을 확인해 보자.
시스템에 로그인한 계정 정보를 점검해보자. wtmp로그는 시스템에 로그인, 로그아웃 내역을 누적해서 기록한다. 해당 항목을 통해 시스템에 로그인한 사용자, IP, 로그인 시간에 대해 확인이 가능하다. 침해사고 발생 시 공격자에 발생한 로그인 내역 분석 시 활용한다.
네트워크와 로그를 통해 분석에 필요한 정보를 충분히 확보한 후에는 이벤트 분석 작업을 수행 한다. 수집된 정보의 양이 많은 경우는 효율적인 분석을 위해 먼저 데이터를 가공하는 작업이 선행되기도 한다.
선별된 정보를 분석해 위협 징후를 확인 하고, 침해사고완 연관된 일련의 정보들을 조합 한다. 분석 과정에서는 공격과 관련된 특징으로 정보를 선별하거나 통계학적인 관점에서 임계치를 기준으로 정보를 분석 한다. 만약 침해사고와 관련된 근거 정보를 충분히 확보 할 수 없다면 정보 수집 과정을 반복할 필요가 있다. 처음 수집할 정보를 선별하는 과정에서 정보 수집 범위가 잘못됐을 수도 있고, 혹은 수집된 정보를 가공하는 과정에서 정보가 누락 됐을 수 도 있다. 이런 경우 처음 정보 수집 대상을 다시 한번 검토하고 제외된 대상에 대한 정보 재가공을 통해 분석 작업을 반복 한다.
분석 방법이 결정 되었다면 필요한 증거를 수집하게 된다. 침해사고분석에 필요한 정보는 크게 2가지 종류로 나뉜다. 보안솔루션이나 시스템에서 파일 형태로 기록하는 정보가 있고, 네트워크 통신 트래픽에서 수집되는 정보가 있다. 먼저 네트워크 통신 트래픽에서 수집되는 정보를 살펴보자.
트래픽 정보를 생각하면 우리는 단순히 패킷 캡처 파일을 떠올린다. 하지만 캡처된 파일을 좀더 자세히 살펴보면 좀더 세분화 할 수 있다.
네트워크 트래픽(Network Traffic) 분석 정보
다음 표는 네트워크 트래픽을 통해 수집할 수 있는 분석 항목 이다. 개별 항목들은 상용 또는 오픈 소스 기반의 솔루션을 통해 수집 또는 자동 분석이 가능한 항목이다.
구분
수집 항목
주요 분석 항목
통신 패킷
로우 패킷(Raw packet)
페이로드(Packet Payload)헤더정보(Packet Header)
세션 정보
트래픽 플로우(Traffic flow)
세션 연결 시간통신량(bytes, packet counts)
애플리케이션 통신
애플리케이션 파라미터
애플리케이션 정보애플리케이션 변수공격 구문
표 네트워크 트래픽 수집 항목
로그 파일 형태의 분석정보
로그 파일의 분석 정보는 좁은 의미로 해석하면 우리가 자주 사용하는 PC나 노트북 또는 서버 장비에서 기록하는 정보를 의미한다. 각각의 장비에는 운영체제가 동작하고 운영체제에 따라 관련 로그를 기록한다. 침해사고가 발생하면 운영체제에서 기록하는 로그를 수집해 이상 징후 분석에 활용 한다. 운영체제에는 사용자가 필요에 따라 설치한 응용프로그램이 동작한다. 개별 응용프로그램은 동작과 관련된 로그를 기록하게 되고 이 또한 위협 분석 시 수집되는 정보다.
구분
수집 항목
주요 분석 항목
윈도우
시스템 보안 이벤트 레지스트리 정보
이벤트 ID중요 레지스트리 수정 항목
리눅스
운영체제 로그 애플리케이션 로그
Secure 로그
애플리케이션
웹 로그
응답코드
표 로그수집항목
대표적인 엔드포인트 시스템으로 윈도우와 리눅스가 있다. 윈도우 로그는 크게 운영체제자체의 로그와 애플리케이션에 의해 발생되는 로그로 구분해 볼 수 있다. 윈도우에서 운영체제 로그의 가장 대표적인 로그는 이벤트로그다. 컴퓨터관리의 이벤트 뷰어를 통해 확인이 가능한데 운영체제의 보안로그와 시스템 로그를 제공한다. 이벤트 로그의 로그 형식과 종류에 대해서는 자세히 살펴보자.
운영체제 정보
OS에 대한 버전 정보를 수집하자. 각 버전별 지원되는 명령이나 서비스 팩에 따른 미묘한 차이가 존재 하기 때문에 이러한 차이를 사전에 확인하고 침해사고분석 시 반영한다. 일부 경우 OS버전이나 서비스팩 등의 차이로 결과가 틀려지거나 결과나 나오지 않을 수도 있다.
운영체제 버전 확인은 점검 대상 시스템 기본 정보 수집 중 하나이다. 먼저 윈도우의 경우자제적으로 제공되는 ver명령을 이용해서 운영체제 버전을 간단하게 확인할 수 있다. cmd명령 창에서 ver명령을 입력하면 아래 그림과 같이 버전 정보를 확인 할 수 있다.
그림 윈도우 버전 확인(ver)
좀더 자세한 정보를 확인할 때는 시작->실행 winver입력을 하여 운영체제와 서비스팩 정보까지 확인 한다
버전 정보를 확인하는 이유는 시스템에 영향을 미치는 취약점을 확인하기 위해서다. 공개된 취약점 공격 도구의 경우 OS나 응용프로그램 버전에 따라 영향 여부가 틀려진다.
winver 내장 명령을 사용할 경우 GUI기반으로 결과를 확인 할 수 있다. 이 경우 텍스트 기반으로 자동 스크립트 점검을 할 경우에는 문제가 발생한다. 이때 psinfo.exe 명령을 이용해서 텍스트 기반으로 결과를 확인할 수 있다. Sysinternals에서 제작된 툴 모음에 포함된다.
리눅스에서는 ‘uname’ 명령을 이용해 시스템 정보를 확인 한다. 커널 버전과 OS정보를 확인할 수 있고, 리눅스의 경우 Exploit마다 취약한 Kernel 버전이 있기 때문에 로컬 또는 원격에서 Exploit공격을 시도할 때 버전 정보가 중요하게 쓰인다.
$uname –a Linux ubuntu 2.6.31-14-generic #48-Ubuntu SMP Fri Oct 16 14:04:26 UTC 2009 i686 GNU/Linux
파일시스템정보
파일 시스템 정보는 넓은 의미에 흔히 말하는 C, D, E 등의 파티션 정보나 물리적 디스크 정보를 말한다. 단순 시스템 경로 파악하거나 할당되지 않은 디스크 공간이 있는지 등을 확인한다. 일부 악성코드의 경우 비데이터 영역에 악성코드를 삽입해 구동되는 경우도 있다. 이러한 경우는 일반적인 점검으로 확인이 어렵고, 디스크 이미지를 추출해서 별도의 분석 툴을 이용해 물리 디스크 전체에 대한 점검을 진행해야 한다.
파일 시스템 구조를 알면 직접 디스크상에서 삭제된 파일, 악성코드, 숨김 파일 등을 분석할 수 있다. 좀더 상세한 분석이 필요하거나 법적 증거로 제출하기 위해서는 디스크 이미지를 추출해 분석해야 한다. 이 작업을 위해서는 전용 분석툴이 필요하다.
윈도우는 ‘컴퓨터 관리’ 메뉴에서 논리구조인 파티션과 물리구조인 디스크 정보를 확인할 수 있다.
리눅스 시스템의 경우는 ‘df’ 명령을 이용해 파티션 정보와 물리적 디스크 정보를 확인 할 수 있다.
IP정보 수집은 네트워크 관련된 기본 정보를 수집하는 과정이다. IP 정보 수집을 통해 현재 시스템의 네트워크 할당 정보를 확인한다. 간혹 한 개의 시스템에 2개의 다른 IP를 부여해 사용하기도 한다. 이 경우 공격자가 접근한 경로가 2개로 나뉘게 된다. 시스템에 부여된 IP 확인해 침해발생 시 추가로 접근 시도 가능성이 있는 내부 IP대역을 확인 한다. 통상 특정 시스템에 침해사고가 발생할 경우 해당 IP의 동일 서브넷에 포함되는 시스템의 경우 일단 침해가능성에 대해 의심해봐야 한다. 수집된 물리주소(Mac Address)는 ARP 스푸핑 공격 시 공격 시스템을 확인하기 위한 용도로 사용된다.
IP정보 확인을 윈도우는 명령 창에서 ‘ipconfig’ 명령을 이용해 확인 가능하다. 리눅스 시스템에서는 ifconfig 명령을 이용해 시스템에 할당된 IP를 확인 할 수 있다.
설치프로그램목록
설치 프로그램 목록은 악성코드 설치 확인이나 정상 소프트웨어 이지만 의도하지 않게 설치된 프로그램이 있는지 점검하고 침해사고와의 연관성을 확인하기 위해 점검 한다.
설치된 프로그램을 점검하는 관점은 설치된 소프트웨어 중 외부와 통신을 위해 사용하거나 시스템을 제어할 수 있는 권한을 가진 소프트웨어에 대해 살펴 보고, 해당 프로그램이 설치된 경우 설치 일자, 설치 계정, 수정일자 등을 이용해 침해사고를 분석하는데 실마리로 이용하게 된다.
윈도우에서 쉽게 확인하는 방법은 제어판의 “프로그램 추가/제거”를 실행 시켜 확인하는 것이다. 이 때 프로그램뿐만 아니라 윈도우 구성요소에 대해서도 확인이 가능하다. 이러한 방법은 GUI기반으로 이뤄지기 때문에 자동화된 스크립트로 결과를 저장하기 어렵다. 분석가가 직접 실행시켜서 눈으로 확인하는 방법이다. 프로그램 목록을 텍스트로 추출해서 일괄 분석에 사용하려면 레지스트리 정보를 이용해 추출 할 수 있다.
패키지정보
그림 프로그램 추가 제거
리눅스는 rpm명령을 이용해 다음과 같이 설치된 프로그램을 확인 할 수 있다. 관리자나 사용자가 설치한적 없는 프로그램이 깔려 있다면 공격자에 의해 설치된 것인지 의심해볼 수 있다.
윈도우의 경우 작업 스케줄러 구동 로그를 확인하여 스케줄러 작업을 통해 구동되었던 내역을 수집 할 수 있다. 해당 파일은 %SystemRoot%\tasks\SchedLgU.txt 경로에 존재한다.
작업 스케줄에 등록되어 구동을 시도하는 악성 코드나 비정상 서비스를 확인 할 수 있다.
“작업 스케줄러 서비스” 6.1.7600.16385 (win7_rtm.090713-1255) “작업 스케줄러 서비스” 2015-07-24 오후 4:52:26에 시작 “작업 스케줄러 서비스” 6.1.7600.16385 (win7_rtm.090713-1255) [ ***** 이 선 위에 가장 최근 항목이 있습니다 ***** ]
그림 시스템 구동 정보
명령 창을 통해서 수집 가능한 정보는 스크립트를 제작해서 하나의 파일에 추출 가능하다. 다음 샘플은 윈도우에서 기본 정보를 수집하는데 사용할 수 있는 점검 스크립트 파일이다.
이번에는 시그니처를 기반으로 공격을 찾아내는 방법에 대해서 살펴보자. 사실 시그니처가 있는 공격은 좀더 찾기가 쉽다. 앞서 비정상 상황을 구분하는 방식은 제로데이 공격과 같이 시그니처가 없거나 어떤 공격으로 들어 왔는지 모르는 경우에 접근하는 방법이다.
상대적으로 탐지 솔루션에서 패턴 매칭을 통해 정의된 시그니처명으로 이벤트가 탐지 되기 때문에 탐지된 이벤트만 확인하면 된다. 주로 해킹과 연관된 특징으로 검색 한다. 백도어와 연관된 경우 파일 명으로 접근이 가능하고, 명령을 실행할 경우에는 공격자가 자주 사용하는 명령어를 위주로 접근 한다.
그림 시그니처 기반
다음은 침해사고가 발생한 과정을 기술한 내용이다.
톰캣 서버에 접속하여 톰캣 서버의 관리자 페이지에 ‘job.war’라는 백도어 프로그램을 올렸다.올린 백도어 프로그램에 접속한 다음 1) ‘ipconfig’, ‘arp’, ‘netview’라는 명령어를 실행하여 IP 주소 등 시스템 정보를 획득하고, 2) ‘FX.EXE’라는 명령어를 실행하여 3389 포트(port)의 터미널 서비스를 기동하고, 3)’LCX.EXE’라는 명령어를 실행하여….……생략…..
공격자가 어떻게 접근했고, 어떤 명령을 실행했는지 기술되어 있다. 실제 침해가 발생 했을 때 앞서 언급된 ‘LCX.EXE’, ‘arp’ 등이 우리가 시그니처 기반으로 침해 흔적을 분석할 때 사용되는 키워드가 된다. 해당 키워드로 수집된 정보에서 일치하는 로그를 찾아낸다.
시그니처를 기반으로 탐지된 로그를 보면서 같이 분석해 보자. 다음은 시스템 명령 실행과 관련된 침입탐지시스템 로그다.
탐지시간
2015-11-05 11:27:28 KST
시그니처명
Microsoft_Windows_Shell_Banner
탐지건수
1
출발지IP
10.10.10.1
출발지포트
14072
도착지IP
172.16.20.114
도착지포트
53
프로토콜
Domain
배너
Microsoft Windows [Version 5.2.3790]..(C) Copyright 1985-2003 Microsoft Corp…..C:\WINDOWS\ime>
표 침입탐지시스템 로그 1
탐지시간
2015-11-05 11:27:47 KST
시그니처명
Microsoft_Windows_Shell_Banner
탐지건수
1
출발지IP
10.10.10.1
출발지포트
14073
도착지IP
172.16.20.114
도착지포트
80
프로토콜
http
배너
Microsoft Windows [Version 5.2.3790]..(C) Copyright 1985-2003 Microsoft Corp…..C:\WINDOWS\ime>
표 침입탐지시스템 로그 2
윈도우 환경에서 텔넷과 같은 서비스에 접속하게 되면 다음 그림과 같은 명령창이 생긴다.
그림 윈도우 쉘
탐지된 시그니처는 네트워크 통신 패킷에 윈도우 명령창이 발생하면 탐지된다.
탐지된 로그에 어떤 숨은 의미가 있을지 생각해보자. 탐지 로그를 분석하기 위해서는 먼저 로그 분석에 앞서 탐지된 시그니처에 대한 이해가 필요하다.
예제로 사용한 침입탐지로그는 공격자가 백도어 통신을 할 때 탐지되기도 하지만 텔넷과 같은 정상 통신 과정에서도 탐지된다. 그렇다면 예제로 설명한 탐지 로그에 차이점이 무엇인지 생각해보다.
탐지 로그를 자세히 살펴 보자. 탐지된 로그의 도착지 통신 포트가 80번 포트와 53번 포트다. 일반적으로 80번 포트는 웹 서비스에 사용되는 포트이고, 53번 포트는 도메인 네임 서비스(DNS)에 사용된다. 만약 정상 통신이라고 한다면 23번 텔넷 표준 포트를 이용했을 것이다. 공격자는 방화벽과 같은 접근 제어 시스템을 우회하기 위해 통신이 자유로운 80번과 53번 포트를 이용했을 가능성이 높다.
침해사고분석에 증거가 되는 확실한 정황을 찾았다면 실마리를 푸는 열쇠가 되기도 한다. 사례를 하나 더 살펴보자.
그림 SMB실행접근
탐지된 로그는 넷바이오스 통신을 통해 시스템 명령이 실행 되면 탐지 된다. 일반적으로 윈도우 서버를 서비스 목적으로 사용하는 기업에서 배치 작업을 실행하거나 일괄 명령 실행을 수행하는 경우 탐지될 수 있다.
이벤트 탐지 내역을 살펴보자. 접근한 통신 포트는 넷바이오스 통신에 사용되는 TCP 포트이고, 사용자 administrator도 특별한 이상한 점을 발견하지 못했다. 그렇다면 어떻게 위협을 구분할 수 있을까?
이번에는 실행된 파일명을 살펴보자. psexe.exe 파일이 실행되었다. 앞서 2장에서도 소개 했던 윈도우용 명령 실행 프로그램 이다. 넷바이오스 연결을 통해 배치 파일을 실행 시키거나 예약작업에 사용할 파일에 접근하는 경우는 있어도 명령을 실행 시키는 일은 드물다.
일반적인 사용 형태가 아니라면 상세하게 확인해 볼 필요가 있다.
그림 넷바이오스명령실행
해킹을 시도하는 공격자는 한번에 자기가 필요한 정보를 피해 시스템에서 훔쳐가지 않는다. 많은 과정과 여러 명령어를 실행하면서 정보 수집을 하고, 필요한 정보를 훔쳐간다.
이 과정에서 많은 명령이 실행되고 파일들이 생성되거나 실행된다. 여러분이 분석하는 로그에 공격자의 흔적이 분명히 남게 된다.
위협 분석 방법론은 쉽게 얘기해서 어떻게 분석을 할지 정의 하는 것이다. 가장 대표적인 분석 방법론으로 블랙리스트 방식과 화이트리스트 방식이 있다. 먼저 블랙리스트 방식은 기존에 위험하다고 알려져 있는 키워드나 이벤트를 중심으로 수집된 정보를 분석하는 방법이다. 방대한 정보에서 정해진 정보만을 검색하기 때문에 상대적으로 분석 소요 시간이 짧다. 하지만 알려진 정보를 가지고 검색하기 때문에 언노운[1] 공격은 찾아내기 어렵다. 반대로 화이트 리스트 방식은 확인된 정상 범주의 정보를 제외한 모든 정보를 분석하는 방법이다. 블랙리스트 방식에 비해 분석할 양도 많고 분석 시간도 많이 소요 된다. 하지만 언노운 공격도 분석이 가능한 방법이다.
분석한 이벤트가 왜 공격인가에 대해서 정의하기 위해서는 먼저 왜 공격이 아닌지 알고 있어야 한다. 다시 말해 정상 통신이나 정상 행위가 무엇인지 알고 있어야 한다. 보안을 입문하는 사람들에게 기본을 강조하는 이유이기도 하다. 애플리케이션이나 네트워크 통신이 어떻게 이뤄지는지 알고 있다면 정상 통신과 비정상 통신을 구분할 수 있다.
텔넷이나 SSH, 원격데스크탑 연결 등 사용자 대화 방식(user interaction) 기반 통신은 해킹에 자주 사용되는 통신 방식이다.
다음 표는 침입탐지시스템에서 추출한 침입탐지 이벤트에 대한 정보를 요약한 표다.
탐지항목
탐지정보
이벤트 수집 기간
3개월
탐지 시그니처 이름
TCP_Invalid_SACK
출발지 IP
10.0.0.1
출발지 포트
랜덤
도착지 IP
랜덤
도착지 포트
랜덤
총합
1441 건
표 IDS 이벤트 분석 정보 요약
TCP_Invalid_SACK 라는 침입탐지시스템 시그니처는 비정상 SYN 패킷과 ACK 패킷에 의해 발생된다. 일반적으로 TCP 통신은 프로토콜에 정해진 방법으로 필요한 통신 패킷을 주고 받는다. 하지만 통신에 사용되는 프로그램이나 네트워크 특성에 따라 정해진 프로토콜과 다른 방식으로 통신하는 현상이 발생한다. TCP_Invalid_SACK 시그니처는 이러한 현상을 기록한다.
이러한 이유로 공격자가 비표준 방식의 프로그램을 사용할 때도 통신 내역이 탐지된다. 물론 탐지된 정보에는 공격자의 통신만 기록되진 않는다. 탐지된 1441건의 이벤트에 공격자가 통신한 횟수는 소수일 것이다. 보안 분석가는 이벤트 분석을 통해 소수의 공격 탐지 건수를 찾아야 한다.
정상 통신과 비정상 통신을 구분하기 위해 먼저 전체 통신 내역을 하나의 큰 그림으로 정리할 필요가 있다. 각각의 날짜에 어떤 포트들이 사용됐고, 사용된 횟수를 누적한 정보를 표로 정리할 수 있다.
포트 통신 통계
표를 작성하는 과정은 유튜브 영상을 참고 할 수 있다.
이제 추출한 로그에서 어떤 공격이 발생했는지 같이 분석해 보자.
정상 통신과 비정상 통신의 차이가 무엇 일까?
그 차이를 구분하기 위해서는 여러분들은 정상 통신과 비정상 통신의 기준을 만들어야 한다. 정상과 비정상 통신의 차이를 접속횟수라는 기준으로 가정해 보자. 좀더 구체적으로 이전보다 갑자기 접속횟수가 4배 이상 증가된 경우 비정상 통신으로 가정해 보자.
앞서 표로 만들었던 통신 포트 통계를 다시 살펴보면 이상한 현상이 눈에 들어 올 것이다.
포트 통계 표에 22, 1501, 8002번 포트의 접속 횟수가 비정상적으로 증가 하거나 감소한 것으로 알 수 있다. 여기까지는 분석하는 사람의 가설에 의한 의심이고 정확한 분석을 위해서는 상세한 내역을 보고 판단하자.
각각의 통신 내역을 상세하게 살펴보자.
먼저 22번 포트의 통신 내역을 살펴보자. 의심스러운 통신 내용 중 어느 것을 먼저 볼지는 분석하는 사람들의 의도에 따라 적절히 판단하자.
이번 경우에는 사용자가 시스템에 명령(user interaction)을 주고 받을 수 있는 SSH통신이 위험도가 높기 때문에 SSH접근 내역에 대한 분석을 먼저 진행 했다.
엑셀로 추출한 로그를 분석할 때는 원본 정보가 변경되는 것을 막기 위해 파일을 복사해서 작업하거나 파일에 새로운 시트를 추가하고 복사한 정보를 가공하자.
분석할 정보가 22번 포트 통신에 대한 내용이기 때문에 나머지 통신에 대해서는 일단 제외 처리한다. 엑셀의 필터 메뉴를 이용해서 22번을 제외하고 모든 숨긴 후 탐지로그를 복사한다.
그림 SSH 탐지 로그 분석
도착지 포트(Target Port) 22번 포트에 대해서만 별도로 추출했기 때문에 이제 날짜별로 공격대상이 어떻게 이뤄지는지 살펴 보자.
날짜와 도착지 IP 컬럼만 선택해서 새로운 시트에 복사하고, 피벗 테이블을 작성한다.
그림 공격대상 분석
22번 포트로 통신한 도착지 IP에 대한 현황 정리가 완료 되었다. 하나의 출발지 IP에서 여러 도착지 IP에 접근을 했고, 접근을 시도했던 날짜도 19일에 집중되어 있다.
19일 날짜에 접속된 통신 내역을 다시 한번 상세하게 살펴본다.
19일에 발생된 침입탐지 로그만 선택해서 새로운 시트에 복사 한다. 복사한 로그를 다시 한번 피벗 테이블을 이용해서 시간대별 통신한 도착지 IP를 정리한다.
피벗 테이블을 만드는 방법은 다음 순서로 진행 한다.
피벗 테이블을 생성하고 행 필드에 시간을 끌어서 이동
열 필드에 Target IP를 끌어서 이동
값 필드에 Target IP를 끌어서 이동
그림 시간대별 통신 분석 1그림 시간대별 통신 분석 2
완성된 테이블을 살펴보자. 새벽 4시를 시작으로 서로 다른 시스템에 1~2회씩 통신이 약 30초에서 1분 간격으로 이뤄졌다.
이렇게 통신이 발생될 수 있는 유형은 대표적으로 다음 2가지 형태가 있다.
예약된 작업에 의해 정기 점검
스캐닝 프로그램에 의한 네트워크 포트 스캔 시도
예약된 작업의 경우는 매주 지정 요일이나 매달 지정날짜에 발생하기 때문에 해당되지 않는다. 스캐닝에 의한 접근 시도일 가능 성이 높다. 내부 시스템간에 스캐닝이 발생했다는 것은 출발지 IP가 공격자에 장악됐을 가능성이 매우 높다. 공격에 사용된 내부 시스템을 찾아낸 것이다.
공격자는 백도어가 설치된 내부 시스템(10.0.0.1)을 경유해 2차 공격을 수행했다.
사전에 수집했던 로그인 정보를 이용해 단순 스캔이 아닌 시스템 로그인에 성공했고, 접속한 시스템에 공격 스크립트를 실행했다.
공격자는 공격 스크립트를 통해 하드디스크에 ‘PRINCIPES’ 문자열로 채워서 디스크를 못쓰게 만드는 명령을 실행했다.
많은 탐지 로그 중에서 이전 대비 급격한 통신 횟수의 변화가 생긴 로그를 의심 행위로 간주했다. 짧은 시간(수초 간격)에 다수의 시스템에 접속한 시스템 로그를 추출했고, 상세 분석을 통해 공격자에 의한 시스템 피해를 확인했다.
특정 문구가 아닌 횟수 변화를 이용해 공격을 구분하는 방법이 임계치 기반의 분석 방법이다.
임계치 기반의 상관 분석을 위해서는 기본 프로파일 정보가 필요하다. 프로파일을 정의 하는 방법은 정상 상황을 정의하고 이에 벗어나는 상황을 분리한다.
앞서 살펴본 예제에서는 정상 상황의 통신은 꾸준하게 통신이 발생한다라는 프로파일을 정의 한 것이다. 이를 기준으로 꾸준하기 않은, 즉 “접속횟수가 이전보다 N배 이상 차이가 나는 것”을 의심스런 통신으로 정의 했다.
프로파일 정의에 사용될 수 있는 정보
매시간 외부와 주고 받는 최대 트래픽 수치
매일 외부와 주고 받는 최대 트래픽 수치
비업무 시간 외부와 통신하는 내부 시스템 수
외부로 중요한 데이터가 유출되었다고 가정해 보자. 해당 데이터는 일반적으로 주고 받는 파일보다 매우 큰 파일이라고 했을 때, 아래 그래프와 같이 평상 시 트래픽을 벗어나 급증한 그래프는 해당 가설을 입증하는 데이터가 될 수 있다.
그림 임계치 기반 분석
통계학적인 관점에서 접근하는 방법으로 침입탐지시스템 로그를 이용해 다음과 같이 이상 통신에 대한 기준을 정의할 수 있다.
공격자/피해자 분석
시스템에 이상이 발생하거나 악성코드가 설치된 시점을 기준으로 관련 이벤트를 검색하고 검색한 이벤트를 이용해 공격 대상을 추출한다. 특정 사건이 발생된 시간이 확인되면 이전에 발생한 이벤트를 분석한다. 침해사고가 발생되면 공격자에 대해 역추적하는 과정이다.
최초 공격을 위해 사전 공격 시점이 언제인지 분석을 하고, 이 후 취약점을 이용해 공격이 성공한 시점을 찾는다.
예제를 살펴보자. 침입탐지시스템 로그에서 공격을 시도한 IP와 공격자가 사용한 취약점을 분석하는 과정이다.
피해를 받은 대상 시스템을 구분하기 위해 침입탐지시스템 로그에서 공격 대상별로 이벤트 발생 시간을 목록화 한다. 단순 스캔 시도한 탐지 로그를 제외하고 대상 시스템을 목록화 한다.
다음 표처럼 대상 시스템 목록과 각각의 대상 시스템이 8월 한달 동안 공격 받았던 취약점 종류(탐지수), 공격자 IP 종류를 목록화 한다.
대상시스템
탐지수
공격자IP 종류
최초 이벤트 발생 시간
최종 이벤트 발생 시간
타켓시스템1
9994
4550
2015-08-01 0:00
2015-08-30 15:00
타켓시스템2
6519
2433
2015-08-01 0:00
2015-08-30 15:00
타켓시스템3
75
1
2015-08-01 0:00
2015-08-30 14:00
타켓시스템4
74
1
2015-08-01 0:00
2015-08-30 14:00
타켓시스템5
9878
1495
2015-08-01 0:00
2015-08-30 15:00
타켓시스템8
128426
8277
2015-08-01 0:00
2015-08-30 15:00
타켓시스템6
79
12
2015-08-02 0:00
2015-08-29 0:00
타켓시스템9
107
2
2015-08-03 13:00
2015-08-27 15:00
타켓시스템7
1
1
2015-08-05 15:00
2015-08-05 15:00
타켓시스템12
7
1
2015-08-06 0:00
2015-08-27 23:00
타켓시스템10
16
4
2015-08-06 16:00
2015-08-29 19:00
타켓시스템11
9
1
2015-08-07 19:00
2015-08-25 10:00
표 공격 대상 시스템 목록
반대로 공격을 시도했던 공격자 IP를 목록화 하고, 침해사고 원인을 역추적하는 방법도 있다.
앞서 보안 위협 분석을 위해 어떠한 정보가 필요한지와 필요한 정보를 수집하는 방법을 살펴 봤다. 이번 장에서는 수집한 정보를 분석해 위협이 되는 이벤트와 그렇지 않은 이벤트를 구분하는 방법을 살펴 볼 것이다.
일반적으로 보안분석가가 보안 위협을 구분하는 과정은 다음과 같다. 보안 위협이나 피해 형태에 따라 필요한 방법론을 정의 하고, 방법론에 적합한 증거를 수집한다. 수집한 증거는 가공 과정을 거쳐 분석에 필요한 정보를 찾아낸다. 분석된 결과는 업무프로세스에 따라 보고 과정을 거쳐 최종적으로 의사 결정자에 의해 결론을 정의 한다.
분석에 사용될 방법론은 위협을 구분하고, 식별하기 위해 어떤 방법을 사용할지 정의 하는 것이다. 공격과 관련된 알려진 특징을 이용할 수도 있고, 수집된 정보를 가공해 통계적인 수치를 이용해 위협을 식별할 수도 있다.
필요한 분석 방법에 따라 수집되는 정보도 차이가 난다. 공격의 특징을 이용해 위협을 분석하기 위해서는 시그니처 기반의 탐지 정보가 필요하지만 통계정보를 이용하기 위해서는 수치화된 정보가 필요 하다.
필요한 정보가 수집이 완료되면 데이터를 가공해서 불필요하거나 분석 우선 순위가 낮은 데이터를 제외한다. 처음부터 끝까지 모든 정보를 분석하면 좋겠지만 제한된 시간과 자원을 가지고 분석하기 때문에 효율적으로 작업 해야 한다.
데이터가공까지 완료되면 위협을 식별하고 식별된 위협 결과에 따라 피해범위와 대응방안을 수립한다. 분석가에게 중요한 역량은 IT보안사고와 연관된 원인을 정확히 규명하고 사고로 인한 피해 범위를 정확히 파악하는 것이다. 분석가의 결론으로 기업이나 조직에 미치는 피해 범위를 정의한다.
분석된 내용은 보고서로 작성해서 대응방안과 함께 의사결정자에게 제공한다. 분석 결과는 의사 결정에 필요한 필수 정보로 사용된다.
정보보안 통합 솔루션 플랫폼을 이용해 애플리케이션 로그, 시스템 로그, 보안 솔루션 로그 등 다양한 이기종 장비에 대한 통합 분석이 가능하다. 보안 업무 수행 시 가장 많은 리소스를 소모하는 과정은 사고 발생 조사 과정에서 보안 이벤트 분석이다. 단편적으로 남아 있는 보안 로그를 사고 분석가나 관제팀에서 추적하면 연결고리를 찾아 분석하기 때문에 시간이 많이 소요된다. 대규모 사고 발생 시 사고분석에 오랜 시간이 걸리는 원인도 이러한 로그를 찾아 추적하고 분석하는데 시간이 많이 소요되기 때문이다.
SIEM 제품과 같은 통합 보안 솔루션은 다양한 보안로그와 시스템로그를 통합해 이상 탐지 및 사이버 보안 위협 탐지 기능을 제공한다. 대표적인 통합 플랫폼인 Elasticsearch Security 제품의 무료버전을 설치해 보자. 트라이얼 기능을 이용해 임시로 유료 기능도 활용해 볼 수 있다.
Elasticsearch Security 플랫폼은 XDR 플랫폼으로서 엔드포인트 컴포넌트인 EDR 에이전트와 중앙관리 서버(Fleet)를 포함해서 다음과 같이 구성된다. Elasticsearch 엔진과 Kibaba(키바나), 플릿(Fleet) 서버를 통해 XDR 플랫폼으로 실시간 보안 위협 탐지와 예방, 대응 기능을 제공한다.
윈도우, 리눅스 계열 운영체제에 따라 필요한 설치 파일을 다운받아 설치를 진행한다. 우분투 기반의 운영체제에서 데비안 패키지 파일을 이용해 설치하는 과정을 살펴 본다. 설치 후 30일 동안 트라이얼 라이센스를 적용하면 모든 기능을 활용하거나 테스트할 수 있다. 설치 가이드 설명을 참고해서 데비안 패키지 파일을 다운로드 받는다. 설치 환경에 따라 설치 패키지 파일명이 다르다. 맥운영 체제 기반의 가상 환경에서 설치를 하기 위해 amd64 버전이 아닌 arm64 버전의 설치 파일을 다운로드 받았다. 설치 시 플랫폼에 따라 필요한 설치 파일은 링크[1]에서 직접 확인 후 다운로드 가능하다.
설치 파일 다운로드가 완료되면 패키지 설치 명령을 통해 설치를 진행한다. 명령 실행 시 설치 파일명은 다운받은 파일명에 맞게 적용한다.
sudo dpkg -i elasticsearch-9.0.0-amd64.deb
설치가 완료되면 시스템 데몬은 다시 적용하고 재부팅 이후에도 Elasticsearch 서비스가 동작하도록 등록한다. 명령은 설치 CLI 화면에 내용을 복사해서 실행한다.
그림 Elasticsearch 설정
설치 과정에서 elastic 계정 패스워드를 별도로 메모한다. 키바나(Kibana) 설치 후 시스템 로그인 과정에 인증 정보가 필요하다.
그림 Elasticsearch 설치정보
설치가 완료되면 서비스를 시작하고 정상적으로 실행되었는지 확인한다.
그림 Elasticsearch 서비스 시작
서비스 상태가 실행상태를 확인하면 설치가 완료된다. Elasticsearch 설치가 완료되면 키바나(Kibana)를 설치한다. 키바나는 사용자가 Elasticsearch SIEM 기능을 운영하기 위해 필요한 웹 기반의 사용자 GUI 이다. Kibana GUI의 주요 기능은 다음과 같다.
데이터 시각화: 로그, 대시보드
보안 룰 설정 및 경보 설정
자산 정보 관리 및 RISK 관리
보안 경고 및 사고 조사
클라우드 보안 관리
그림 키바나 대시보드 예제
키바나 설치 파일은 링크[1]를 통해 다운로드 한다. 데비안 패키지 파일을 다운받기 위해 설치 파일 종류를 선택한다.
정상 구동이 이뤄지면 키바나 설정 파일을 수정한다. 키바나 서버에 원격으로 접근하기 위해서 설정을 변경하다.
# vi /etc/kibana/kibana.yml
설정 파일의 “server.host” 항목을 호스트 IP 또는 0.0.0.0 으로 설정하면 원격에서 접근이 가능하다. 키바나에 원격 접근을 허용하는 경우 권한 없는 사용자의 접근을 제안하기 위해 시스템에 대한 Iptable을 활용하거나 네트워크 기반의 접근 제어를 적용하는 작업이 선행되어야 한다. 기타 설정 항목들은 향후 필요한 경우 개별 수정 할 수 있다.
그림 키바나 원격접근 설정
Elasticsearch와 키바나의 설정이 변경되면 변경된 설정을 적용하기 위해 서비스를 재시작해야 한다.
키바나의 사용시 민감한 데이터를 보호하기 위한 암호화 키를 적용할 수 있다. Root 권한으로 키바나 암호화 키를 생성한다.
BPFDoor 는 Linux용으로 특별히 제작된 백도어 입니다. 이 백도어의 목적은 공격 대상 환경에 반복적으로 재진입하기 위해 장기간 시스템에 숨겨진 백도어 역할을 수행 합니다. 특히 BPF를 비롯한 여러 기술을 활용하여 최대한 은밀하게 작동하도록 설계 되어 있습니다.
패시브 형태로 백도어가 동작하기 때문에 평상시 가동 시간이 높은 서버나 기기, IoT/SCADA, 또는 인터넷에 접속 가능한 클라우드 시스템에 설치되도록 설계되었습니다. 특히 서비스 특성 상 메인터넌스나 재부팅이 어려운 시스템에 지속적으로 상주하여 공격자의 백도어 역할을 수행 합니다. 공격 프로그램에서 사용하는 파일은 임시 폴더에 저장되므로 서버가 재부팅 되거나 종료될 경우 백도어가 손실됩니다.
이 악성코드가 시스템에서 발견될 경우, 초기 접근(1단계) 또는 사후 공격(2단계) 페이로드가 여전히 존재하고 환경의 다른 곳에서 활성화되어 있을 가능성이 높다고 가정해야 합니다. 이 백도어는 은밀하게 침투하여 탐지되지 않을 모든 기회를 포착합니다. 샘플 코드를 통해 확인된 BPFDoor의 동작 과정 입니다.
예외 샘플 분석
주목할 점은 1~4단계가 나타나지 않는 샘플이 하나 있다는 것입니다 . 이 샘플은 초기 이름을 하드코딩된 값으로 변경하지 않고, 배치된 위치에서 실행하며, 그 외에는 동일한 동작을 모델링합니다.
실행 시 바이너리는 자신을 /dev/shm/에 복사합니다. 임시 파일 시스템인 /dev/shm은 공유 메모리를 의미하며, 프로세스 간 효율적인 통신 수단으로 사용되는 임시 파일 저장 공간입니다.
프로세스 이름을 하드코딩된 프로세스 이름인 kdmtmpflush로 변경합니다.
-init 플래그로 자신을 초기화하고 자신을 fork합니다. Linux에서 fork는 호출 프로세스를 복제하여 새 프로세스를 생성하는 것을 의미합니다.
자신을 위한 새로운 프로세스 환경을 생성하고 기존 프로세스를 제거하며, 새 프로세스 이름을 설정(스푸핑)합니다. 마치 마스크를 쓴 것처럼 시스템에 나타나는 방식을 변경합니다. 프로세스는 여전히 kdmtmpflush이지만, ps를 실행하면 설정된 값을 볼 수 있습니다.
/var/run에 프로세스 ID(PID) 파일을 생성합니다. PID 파일은 연관된 프로그램의 프로세스 정보를 담고 있는 텍스트 파일로, 다중 시작을 방지하고, 상주 상태를 표시하며, 프로그램이 스스로를 중지하는 데 사용됩니다. 이 파일은 또 다른 임시 파일 저장 공간인 /var/run에 있습니다.
원시 네트워크 소켓을 생성합니다. Linux에서 소켓은 네트워크 통신의 엔드포인트로, 패킷의 모든 섹션을 세부적으로 지정할 수 있도록 하여 사용자가 인터넷(IP) 수준에서 자체 전송 계층 프로토콜을 구현할 수 있도록 합니다.
원시 소켓에 BPF 필터를 설정합니다. BPF를 사용하면 사용자 공간 프로그램이 모든 소켓에 필터를 연결하여 특정 유형의 데이터가 소켓을 통해 들어오도록 허용하거나 거부할 수 있습니다.
들어오는 패킷을 관찰합니다
BPF 필터와 일치하고 필요한 데이터를 포함하는 패킷이 관찰되면 처리를 위해 백도어로 전달됩니다.
현재 프로세스를 다시 포크합니다.
포크된 프로세스의 작업 디렉토리를 /로 변경합니다.
포크된 프로세스의 이름을 하드코딩된 값으로 변경(스푸핑)합니다.
“매직 패킷”에 전송된 비밀번호 또는 비밀번호의 존재 여부에 따라 백도어는 역방향 셸을 제공하거나 바인드 셸을 설정하거나 ping을 다시 보냅니다.
아래에서 Elastic의 Analyzer View를 활용하여 BPFDoor 프로세스 트리를 시각적으로 확인할 수 있습니다. 첫 번째 이미지는 백도어(즉, 리버스 셸, 바인드 셸 또는 핑백)가 실제로 사용되기 전의 트리를 보여주고, 두 번째 이미지는 리버스 셸이 연결되고 익스플로잇 후 활동을 수행한 후의 트리를 보여줍니다.
그림 BPFDoor 초기 호출 프로세스 트리의 Elastic Analyzer 뷰
그림 Reverse Shell연결 및 공격 성공 후 BPFDoor의 Elastic Analyzer 뷰
원격 스캔 방식: TCP, UDP, ICMP 혼합 방식으로 포트 연결 시도 (예: 68/UDP → 53/UDP)
포트리스닝 없는 역접속 방식: 백도어는 포트를 열지 않고 “매직 패킷” 수신 시명령 실행
은폐 기법: 프로세스 이름 위장, 표준 스트림 닫기, 루트 권한으로 메모리 상 실행
Elastic Security Team은 BPFDoor 맬웨어를 분석하는 데 도움이 되는 몇 가지 도구를 만들었습니다. BPFDoor 스캐너를 사용하면 BPFDoor 맬웨어에 감염된 호스트를 스캔할 수 있으며, BPFDoor 구성 추출기를 사용하면 맬웨어의 구성이나 하드코딩된 값을 추론하여 추가 분석, 추가 시그니처 개발 또는 클라이언트를 활용한 백도어 연결에 사용할 수 있는 추가 관찰 결과를 얻을 수 있습니다.
BPFDoor 백도어가 왜 그렇게 오랫동안 사용되면서 숨겨진 채로 남아 있었는지를 알기 위해 동작 방식을 설명 했습니다. Linux 운영체제의 이상 프로세스 대해 잘 모르거나 자세히 살펴보지 않았다면 쉽게 탐지되지 않을 것입니다. 탐지를 피하기 위해 은밀하게 동작하지만, 행위 기반 탐지 방식과 시그니처 기반 탐지 방식을 통해 충분히 탐지와 차단이 가능 합니다.
Elastic Endpoint 제품인 Elastic Defend에서 대응 과정을 살펴 보겠습니다.
악성코드 초기 실행 시 관찰된 동작에 주목 합니다. 특히 이상행위는 공유 메모리 위치인 /dev/shm 디렉터리에서 발견 되었습니다. 이 디렉터리는 Linux의 기본 임시 파일 시스템 위치로, RAM을 저장 공간으로 사용하며, 이 디렉터리에서 바이너리가 실행되거나 네트워크 연결을 생성하는 것은 실제로 매우 드뭅니다.
두 번째로 /var/run에 특정 PID 파일이 생성을 통해 악성코드 탐지 및 예방 입니다. Osquery 통합 기능을 통해 /var/run 디렉터리에 드랍된 PID 파일이 완전히 비어있는 것을 발견했습니다. 드랍 파일 자체가 악의적인 것은 아니지만, PID 파일 크기가 0이거나 10바이트 정도인 경우는 드물기 때문에 이러한 비정상적인 동작을 탐지하기 위한 추가 탐지 Rule을 만들었습니다.
침해사고 분석 시 시스템에 동작 중인 프로세스를 확인하는 과정이다. 침해사고에서 발견되는 공통점 중 하나가 악성코드다. 이 악성코드는 별도로 실행되기도 하지만 많은 수의 악성코드가 시스템에 구동중인 기존 프로세스를 감염시킨다. 시스템에서 구동중인 프로세스가 정상인지 비정상인지를 판단해야 한다. 점검 방법은 운영체제에서 제공하는 기본적인 프로세스에 대한 정보를 활용할 수도 있고, 백신프로그램을 이용해 검사를 해볼 수도 있다.
감염된 프로세스에서 사용중인 파일을 찾는 작업이 쉽지는 않다. 프로세스에서 사용하고 있는 파일들이 생각보가 많을 것이다. 프로세스에서 참조하는 많은 파일들이 정상 파일인지 확인해야 하고, 감염된 프로세스가 외부로 통신을 하고 있으면 통신목적을 확인해야 한다. 프로세스를 뜯어보기 위해 어떤 과정이 필요하고, 어떤 툴을 사용하는지 방법을 소개하고자 한다. 물론 책에서 소개한 방법이나 프로그램 외에도 많은 방법이 있다. 자신의 스타일에 맞는 방법이나 프로그램을 이용할 것을 추천 한다.
악성코드에 감염된 시스템에서 채증 또는 확보한 파일은 분석 전용 시스템으로 이동해 분석하자.
프로세스 정보 수집
침해사고 분석 시 프로세스 정보를 수집하기 전에 전반적인 시스템 정보를 다시 한번 확인한다. PSINFO 프로그램을 이용해 시스템 기본 정보를 확인한다.
기본 정보를 확인하는 목적은 단순한 정보에 침해의 중요한 실마리가 되는 정보들이 숨어 있기 때문이다. 예를 들어 업타임(Uptime) 정보는 시스템이 기동된지 얼마의 시간이 지났는지 정보를 제공 한다. 일부 악성코드의 경우 시스템에서 프로세스를 감염시키는 과정에서 얘상치못한 프로세스 또는 시스템 오류를 발생시키곤 한다. 이때 장비가 재부팅되기도 한다.
최초 악성코드 감염은 시스템이 기동되고 운영중인 상태에서 발생한다. 이 경우 다른 프로세스들과 기동 시간을 비교해보면 중간에 시작된 프로세스들이 생기는되 이러한 프로세스를 먼저 살펴볼 필요가 있다.
업타임 정보외에도 응용프로그램들의 버전 정보나 운영체제의 버전 정보도 확인할 필요가 있다. 기본에서 시작하면 복잡한 침해사고도 의외로 쉽게 풀린다.
리눅스에서는 ‘uptime’ 명령을 실행해서 윈도우에서와 동일한 정보를 수집 할 수 있다. 다음은 ‘uptime’ 명령을 실행한 예제이다.
이제 본격적으로 프로세스 리스트를 확인해 보자. PSLIST 툴을 이용해 점검 대상 시스템에 구동 중인 프로세스 리스트를 수집하자. PSLIST 툴은 각 프로세스의 PID, Elapsed Time(프로세스가 시작되어 현재까지 경과된 시간), CPU Time(CPU 사용 시간) 정보등을 확인할 수 있다. 다음은 툴을 실행시켰을 때 보여지는 각각의 항목에 대한 설명이니 참고하자.
항목
설명
Pri
우선순위
Thd
쓰레드수
Hnd
핸들수
VM
가상메모리
WS
워킹셋
Priv
Private 가상메모리
Priv Pk
Private 가상메모리 최대치
Faults
Page Faults
NonP
Non-Paged 풀
Page
Paged 풀
Cswtch
Context Switches
표 PSLIST 점검 항목
Elapsed Time은 해당 프로세스가 시작된 시점에 따라 차이가 발생된다. 일반적으로 주요 프로세스는 윈도우 시작 시 구동되기 때문에 윈도우 시작 시간과 거의 동일하다. 운영체제 업타임과 비교해서 시작 시 실행된 프로세스와 운영체제 구동 후 중간에 실행된 프로세스 정보 할 수 있다. 프로세스 PID의 경우도 시스템 시작 후 시간이 지날수록 실행되는 프로세스의 PID번호가 높아진다.
그림 PSLIST 실행
악성코드에 의해 생성된 프로세스 또는 감염된 프로세스 확인을 위해서는 프로세스에 대한 정보를 알고 있어야 한다. 하지만 프로세스는 구동 중인 환경에 따라 사용되는 종류도 다양하고, 특정 시스템에만 존재하는 프로세스도 있기 때문에 모든 프로세스에 대한 정보를 알고 있기는 힘든 것이 사실이다.
윈도우의 경우 다 음표와 같이 사이트를 통해 기본적인 프로세스에 대한 정보를 제공한다. 프로세스 점검 시 활용하면 도움이 될 것이다. 표는 윈도우를 기준으로 한 기본 프로세스에 대한 정보이다.
프로세스 이름
설명
Csrss.exe (작업관리자에서 종료 불가)
Win32.sys가 Win32 subsystem의 커널모드 부분인데 비해서 Csrss.exe는 사용자모드 부분이다. Csrss는 Client/Server Run-time SubSystem의 약자로 항상 돌고 있어야 하는 필수 subsystem 중 하나이다. 콘솔 창, 쓰레드 생성 및 제거 및 16비드 가상 도스 환경의 일부를 관리한다.
Explorer.exe (작업관리자에서 종료 가능)
작업관리줄, 바탕화면 등과 같은 사용자 셸로서 Windows의 작동에 있어 필수적인 요소가 아니며 시스템에서 아무런 부작용 없이 작업관리자에서 종료 및 재시작이 가능하다.
Internat.exe (작업관리자에서 종료 가능)
시스템 시작과 함께 구동되는 프로세스로 사용자가 지정한 여러가지 입력 로케일 (HKEY_USERS.DEFAULTKeyboard LayoutPreload키에서 뽑아낸다)을 구동한다. 시스템 트레이에 “EN” 아이콘을 띄움으로써 사용자가 입력로케일간에 변환을 손쉽게 할 수 있도록 한다. 작업관리자를 통해 이 프로세스를 종료하면 “EN” 아이콘도 disable되는 것처럼 보이지만 제어판을 통해 입력로케일간의 변환이 가능하다.
Lsass.exe(작업관리자에서 종료 불가)
로컬 보안 인증 서버로서 Winlogon 서비스가 사용자를 인증하는데 필요한 프로세스를 만들어 내고 이 프로세스는 Msgina.dll과 같은 인증 패키지를 이용함으로써 수행된다. 인증이 성공하면 Lsass는 해당 사용자의 Access Token을 생성하고 이를 이용해 초기 셸이 구동된다. 동 사용자가 초기화하는 다른 프로세스들은 이 Access Token의 지위/속성을 승계한다.
Mstask.exe (작업관리자에서 종료 불가)
사용자가 미리 지정한 시간에 작업을 실행시키는 Task Scheduler Service
Smss.exe (작업관리자에서 종료 불가)
사용자 세션을 시작시키는 세션 관리자 subsystem으로서 시스템 쓰레드에 의해 초기화되며 Winlogon 및 Win32 (Csrss.exe) 프로세스를 구동하고 시스템 변수를 설정하는 등의 다양한 활동을 담당한다. 이들 프로세스를 구동시킨 다음 Winlogon이나 Csrss가 종료할 때까지 대기하되, 종료가 정상적으로 이루어지는 경우엔 시스템이 종료하고 그렇지 않은 경우엔 시스템을 반응없음(Hang)상태로 만든다.
Spoolsrv.exe (작업관리자에서 종료 불가)
스풀된 프린트/팩스 작업을 책임지는 spooler service
Svchost.exe (작업관리자에서 종료 불가)
DLL로부터 구동되는 다른 프로세스들에 대한 호스트로서 작동하는 generic process이기 때문에 2개 이상이 생길 수도 있다. Svchost.exe를 이용하는 프로세스들의 명세를 확인하려면 윈2000 CD에 있는 Tlist.exe를 이용하면 되고 구문은 명령 프롬프트에서 tlist -s 이다.
Services.exe (작업관리자에서 종료 불가)
시스템 서비스들을 시작/종료/상호작용하는 역할을 담당하는 Service Control Manager
System (작업관리자에서 종료 불가)
대부분의 시스템 커널모드 쓰레드들이 System 프로세스로서 실행된다.
System Idle Process (작업관리자에서 종료 불가)
각각의 프로세서(CPU)에서 돌고 있는 단일 쓰레드로서 시스템이 다른 쓰레드들을 프로세싱하지 않을 때 프로세서 타임을 관리하는 역할을 수행한다. 작업관리자에서 이 프로세스가 프로세서 타임의 대부분을 차지해야 시스템이 빠른 속도를 낼 수 있다.
Taskmgr.exe(작업관리자에서 종료 가능)
작업관리자를 위한 프로세스
Winlogon.exe(작업관리자에서 종료 불가)
사용자 로그온 및 로그오프를 관리하는 프로세스로서 사용자가 Ctrl+Alt+Del를 눌러서 보안 대화상자를 띄울 때만 활성화된다.
Winmgmt.exe(작업관리자에서 종료 불가)
윈2000에서 클라이언트 관리의 핵심 구성요소로서 클라이언트 응용프로그램이 처음 연결될 경우 또는 관리 응용프로그램이 서비스를 요청할 때 초기화된다. 작업관리자에서 종료할 수 없는 프로세스들의 대부분은 Resource Kit 유틸인 Kill.exe를 이용하여 종료가 가능하지만 system failure나 기타 다른 부작용을 야기할 수 있다.
표 기본 프로세스 정보
한가지 분석 팁은 점검 대상과 동일한 버전의 깨끗한 상태의 운영체제를 설치해 프로세스 리스트를 점검 대상 시스템과 비교하는 방법이 있다. 설치하기가 어렵다면 기존의 설치된 시스템을 활용할 수도 있다.
프로세스 리스트를 좀더 유기적으로 분석하기 위해서는 앞서 PSLIST실행 결과를 의존관계에 따라 확인하는 방법이 있다. 방법은 PSLIST 실행 시 옵션 선택을 통해 가능하다. –t 옵션을 이용하면 단순 리스트업이 아닌 자식과 부모 프로세스로 구분해 트리형태로 표시한다. 악성코드가 어떤 프로세스를 만들었고, 악성코드에 의해 생성된 하위 프로세스를 확인 할 수 있다. 다음이 실제 확인해본 결과다.
그림 PSLIST 실행 옵션
필요에 따라 PSLIST에서 제공하는 옵션을 확인해 적절히 사용하면 프로세스 정보 분석에 도움이 된다. 윈도우의 경우에 프로세스 분석 시 GUI형태로 제공되는 툴도 있다. PSLIST를 통해 확인이 어려운 부분은 추가로 툴을 이용해 분석 시 활용한다.
윈도우에서 “pslist –t”를 이용해 확인한 결과와 동일한 결과를 리눅스에서 ‘pstree’ 명령을 통해 얻을 수 있다. PS명령의 옵션을 이용하여 확인도 가능 하다. (ps –ejH, ps axjf)
‘pstree’ 명령을 이용해 히든프로세스 정보까지 확인 가능하다. 명령 실행 시 h옵션을 이용해 확인한다. 다음은 히든프로세스를 확인한 결과 화면 이다. 동일한 시스템에서 명령을 실행 시켰지만 옵션에 따라 결과를 다르게 나타난다. 그림의 왼쪽은 pstree 명령을 실행 시킨 결과이고 오른쪽은 ‘-h’ 옵션을 사용한 결과다. 동일한 bash 프로세스도 보여지는 결과가 다른다.
그림 pstree 실행 비교
w명령은 현재 로그인한 정보와 함께 사용자별 실행 중인 프로세스 정보까지 확인이 가능 하다.
다음은 w명령이 표시하는 목록에 대한 설명 이다
항목
설명
User
로그인한 사용자 이름
TTY
teletype – TTY는 타자기 형태의 키보드와 부착형 프린터 등을 갖춘 장치를 의미, tty값이 0또는 양수인 경우 콘솔을 통해 로그을한 것을 의미, tty항목이 pts로 표기 또는 ttyp#일 경우 네트워크를 통한 로그온이다.
From
네트워크를 통한 연결일 경우 원격지 IP주소, 콘솔을 통한 로그인일 경우는 표기하지 않음
Login@
최종 로그인 시간 표기
Idle
마지막으로 행위 후 활동을 얼마나 멈추고 있는지 나타낸다. 예를 들어 “w”명령을 입력한 후 5초 동안 아무런 입력이나 출력을 하지 않았다면 해당 시간이 5초로 표기된다. 2:14pm 5.00s 0.00s 0.00s -bash
JCPU
TTY항목에 나열된 각각의 로그인(네트워크 또는 콘솔)에서 사용한 CPU사용 시간 합이다. 지나간 백그라운드 잡은 포함하지 않고, 현재 걸려있는 백그라운드 잡은 합산 시간에 포함된다.
해커에 의해 시스템을 공격 받게 되면 그 흔적이 남게 된다. 운영체제와 네트워크 트래픽에 남아 있는 공격자의 흔적이 무엇인지 살펴 보자. 공격 흔적을 찾기 위해서 특정 툴이나, 내장 명령, 스크립트 등을 이용해 시스템에서 정보를 추출 할 것이다. 정보 추출을 위해 필요한 옵션과 분석 시 도움되는 정보들을 살펴보자.
운영체제 메모리에 올라와 있는 정보나 네트워크 통신 정보들은 시간이 지나면 사라지는 정보다. 휘발성 정보가 무엇이고, 어떤 흔적이 남아 있는지 살펴보자.
세션 정보 수집
시스템에 남아 있는 정보 중 네트워크 통신 정보는 연결이 종료되면 사라진다. 키로깅 프로그램이나 백도어 프로그램은 피해 시스템에서 수집한 정보를 전송 하기 위해 외부와 통신을 해야 한다. 외부와 통신하기 위해 피해 시스템에 설치된 악의적인 프로그램은 프로세스를 생성한다. 백도어가 사용하는 프로세스를 확인하면 사용되는 파일과 통신 대상 정보를 알아 낼 수 있다.
정보를 수집할 때는 시스템의 내장 명령이 조작되었을 가능성이 있기 때문에 점검에 사용할 실행 프로그램을 따로 준비하는 게 좋다.
시스템간에 연결된 통신을 세션이라고 부른다. 이 세션 정보를 수집하기 위해 ‘netstat.exe’ 명령을 이용한다. 명령 옵션은 다음과 같다.
-a: 모든 연결 및 수신 대기 포트를 표시합니다. -o: 각 연결의 소유자 프로세스 ID를 표시합니다. -n 주소 및 포트 번호를 숫자 형식으로 표시합니다.
‘ao’ 옵션과 함께 명령을 실행 시키면 다음과 같은 결과 화면이 출력 된다. 현재 시스템에서 연결된 모든 세션 정보가 화면에 출력된다.
그림 세션별 PID
확인된 전체 세션 목록을 점검하여 비정상 세션이나 사용하지 않는 세션을 추출하고, 해당되는 PID(프로세스ID)를 통해 의심되는 프로세스를 점검한다. 이 경우 순간적으로 통신을 맺고 바로 세션을 끊는 경우 확인이 어려울 수 있다.
일부 악성코드는 히든프로세스로 시스템에서 대기 하고 있다 일정 주기나 특정 조건에 의해 세션을 연결하여 통신을 시도하고, 통신이 완료되면 세션을 종료한다.
일회성으로 연결을 맺고 금방 사라지는 세션을 점검하기 위해 실시간 모니터링 프로그램을 이용한다. 실시간 프로세스 모니터링은 TCPVIew , Seem(구Ekinx) 프로그램을 이용하여 확인 할 수 있다. 자동스크립트를 이용해 주기적으로 세션 정보를 저장해 일괄 확인하는 방법도 가능하다.
GUI 기반의 모티터링 프로그램을 실행시키면 다음 그림처럼 현재 시스템에 형성된 세션 정보를 출력한다. 세션 정보는 1초마다 자동 업데이트 된다. 업데이트 주기는 사용자가 메뉴에서 변경 할 수 있다.
그림 실시간 프로세스 모니터툴
실시간 모니터링 프로그램을 이용하면 외부로 연결을 시도하거나 내부로 연결을 시도하는 IP 정보를 확인하여 연관된 프로세스를 추출 할 수 있다. 윈도우처럼 리눅스도 동일하게 확인 가능하다. 필요에 따라 옵션항목을 조절해 사용 할 수 있다.
생성된 세션이 비정상이거나 시스템과 관련이 없을 경우 해당 프로세스에 대해 좀더 자세히 점검하고, 실제로 프로세스가 사용중인 파일에 대해 점검한다. 다음으로 세션을 유발 시킨 실행 파일을 확인하는 방법을 살펴보자.
세션별 실행파일
윈도우 실행파일 별로 PID번호와 현재 연결 상태, Local&Remote IP, Port정보를 점검 한다. 프로세스정보와 함께 분석한다. 악성 코드에 의한 연결 인지 정상 통신인지 확인한다. 점검은 윈도우 내장 명령이 아닌 별도의 무료 프로그램을 이용해 점검 할 수 있다.
tcpvcon을 다운받아 윈도우 명령 창에서 다음과 같이 실행 한다.
tcpvcon -n /accepteula
프로그램을 실행시키면 아래처럼 실행 파일별 PID정보와 연결 상태 및 상세 정보를 확인 할 수 있다.
세션 정보를 수집하는 방법을 살펴 봤다. 이번에는 여러분이 수집한 통신 연결 정보와 상세 실행 파일 정보를 활용하는 방법을 살펴 보자.
침해사고 분석에 어떻게 활용될 수 있는지 다음 사례를 같이 살펴 보자.
사례 분석
스팸 메일이 유포되었던 시스템을 분석했던 사례다.
침해가 발생한 시스템에서 특정 수신인을 대상으로 스팸 메일이 발송 되었다. 침해사고가 발생한 시스템이 중간 경유 시스템으로 이용되었는지 여부에 대한 분석을 진행 했다.
점검 대상 시스템은 윈도우 운영체제가 사용되고 있었다. 네트워크 방화벽에서 웹 서비스를 제외한 원격 접근은 불가능 하였다. 서비스 확인 시 웹 서비스 외 추가 서비스는 구동하지 않았다.
스팸 메일이 발송된 원인을 조사하기 위해 침입탐지시스템(Intrusion Detection System) 탐지 로그를 확인 하던 중 의심스런 통신 내역이 확인 되었다. 사용하지 않는 암호화 통신(SSL, Secure Sockets Layer)통신이 발생된 것이 확인 되었다. 상세 분석 시 점검 대상 시스템을 통해 해외 웹 메일 사이트에 접근 내역이 확인 됐다. HTTPS 통신을 통해 외부 웹 메일 서비스를 이용하였다.
프록시 설정이 의심되었고, 점검 결과 스팸 메일이 발송된 시스템을 거쳐 웹 메일 사이트에 접속하였고, 웹 서비스에서는 스팸 발송자를 해당 IP로 지목했던 것이다.
익명 웹 프록시 설정이 활성화 돼있을 경우 해당 시스템을 통해 타 사이트로 접근이 가능하게 되고, 이 경우 아래와 같은 구조로 중간(B Server)에서 중계 역할을 한다.
공격자 -> 중간 경유 서버(프록시서버) -> 웹 사이트
분석한 시스템은 중간 경우 서버에 해당 된다. 웹 사이트에는 공격자 IP가 아니라 중간 경유 서버 정보가 남는다. 참고로 익명 프록시 설정이 열리게 되면 해당 정보는 익명 프록시 서버 목록에 올라간다. 이 정보는 관리자가 의도하지 않은 피해를 유발할게 될 수 있다.
그림 익명 프록시 허용 서버 목록
스팸 발송 IP로 의심된 서버는 익명 프록시 허용으로 피해가 발생한 것이다. 자 그럼 프록시 서버로 이용된 사실을 어떻게 확인했는지 살펴 보자.
점검항목
분석 결과
세션 정보
다수의 웹 서비스 세션이 확인80번 출발지 포트 아웃바운드 연결불특정 다수 사용자가 경유를 통해 타 사이트로 접근
취약 경로 분석
익명 프록시 접근 허용
로그점검
제공하지 않는 서비스 로그 확인경유로 인한 외부 서비스 URL 제공 로그
표 점검 요약
세션 분석 결과 다수의 아웃바운드 통신이 확인 됐다. 다수의 FIN_WAIT_2 상태가 확인 됐다.
FIN_WAIT_2 상태는 통신을 종료하는 과정에서 FIN 패킷을 전송하고 상대방에서 ACK를 수신하지 못해 기다리고 있는 상태를 의미 한다. 다음 그림에서 FIN을 보내고 두 번째 단계로 ACK와 FIN요청을 받아야 되는데 ACK 응답이 오지 않아 기다리고 있는 상태가 FIN_WAIT_2다.
일반적으로 웹 서버는 클라이언트에서 FIN 요청을 보내면 ACK 응답을 보낸다.
하지만 이 경우 웹 서버가 마치 클라이언트처럼 웹 서버에 FIN 요청을 보내고 또 다른 웹 서버의 응답을 기다리고 있었다(FIN_WAIT_2). 통신을 주고 받는 주체가 반대로 보였다. 이 정보를 기반으로 프록시 설정을 의심했다.
