[Case Study 1부] DDoS 공격에 이용되는 좀비 PC 어떻게 감염될까

메모리 덤프(Memory Dump) 분석을 통한 침해 사고 대응

2011년 3월, 다시 한번 악성코드를 사용한 DDoS 공격이 발생했다. 이번 DDoS 공격에 사용한 악성코드는 공격자가 원하는 형태로 명령을 할당 받고, 그에 따라 움직이는 등 갈수록 지능화 되어가고 있는 모습을 보여 주었다. 지능화와 더불어, 최근의 악성코드는 하드디스크에 별도의 파일을 작성하지 않고, 메모리(Memory)에 직접 로드되어 실행되는 것도 존재한다. 이러한 경우, 침해 조사시 하드디스크의 물리적인 이미지만을 조사하여서는 어떠한 증거도 찾을 수 없는 일이 발생한다. 이러한 문제점을 해결하기 위한 방안으로 메모리 덤프 분석을 통한 방법이 주목받고 있다.

메모리 덤프 분석은 해당 시스템에서 직접 분석을 수행 하는 경우(Live Response), 루트킷 등에 의해 조작된 프로세스 관련 API에 영향을 받지 않는다는 장점이 있다. 즉, 침해사고를 당한 시스템의 메모리에 있는 정보를 그대로 추출하며, 분석가의 컴퓨터에서 작업을 수행하여 침해당한 시스템의 프로세스 관련 API를 사용하지 않고 분석을 수행할 수 있는 것이다. 또한, 실행 후 삭제되었지만 메모리에만 남아 있는 정보를 얻을 가능성도 존재한다. CPU로 전송되기 이전에 암호화된 코드들은 복호화되어 메모리에 로드되는데, 이러한 점도 메모리 덤프 분석시 얻을 수 있는 장점이 될 수 있다.

월간 ‘안’ 2011년 4월호에서는 총 2부에 걸쳐 메모리 분석을 통한 침해 사고 대응에 대해 소개하고자 한다. 1부에서는 침해 사고와 동일한 시나리오로 통해 악성코드를 감염 및 동작시켜, DDoS 공격에 사용되는 좀비(Zombie) PC가 어떠한 형태로 감염되었는지 알아보자. 또한 메모리 분석을 통해 어떻게 악성코드를 검출해 낼 수 있는지에 대해 살펴본다.
이어 2부에서는 메모리 덤프 파일 분석 중 메모리 덤프에서 프로세스 정보를 추출하는 방법에 대해서 별도로 자세히 소개한다. 

침해 사고 분석 시나리오
우선 실제 고객사에서 발생하였던 침해 사고를 재현하여 메모리 덤프를 어떻게 획득할 수 있는지 알아본다. 또한 HBGary Responder라는 상용 툴을 사용하여 침해 사고 분석을 재현해 보겠다.
침해 시스템은 메일로 전파된 악성코드에 감염되어 있었다. 이 악성코드는 DDoS 공격을 유발하는 악성코드로 IRC를 통해 주기적으로 C&C(Command & Control) 서버에 접근했다. 

 

[그림 1] 침해 시나리오

침해 사고가 발생한 시스템과 동일한 상태를 재현하기 위해 악성코드를 이메일을 통해 발송하고, 공격 대상 서버에서 이메일에 첨부된 악성코드를 다운로드 받은 후 실행했다.
이 환경에서 메모리 덤프를 수집하여 주요 증거를 획득하고, 어떻게 증거가 수집되는지 확인해보자.

분석은 다음 순서와 같이 진행된다.
1. 메모리 덤프 수집
2. 메모리 덤프 파일 분석
3. 하드디스크 이미지 분석
4. 메모리 덤프 시각화를 통한 효과적인 분석

1. 메모리 덤프 수집
증거를 수집할 때 기본적으로 “The order of volatility(OOV)”라는 법칙에 따라 진행하게 된다. OOV란 휘발성이 높은 정보를 휘발성이 낮은 정보보다 먼저 수집해야 한다는 법칙이다. 우선적으로 가장 상태 변화가 많은 메모리를 먼저 수집하며, 기타 네트워크 연결과 같이 실시간으로 변동되는 사항에 대해 먼저 수집을 진행한다.

그럼, 메모리 덤프 수집 방법에 대해서 알아보자. 공개된 메모리 덤프 툴은 많이 있지만, 여기에서는 HBGary에서 상용으로 제공하는 FastDump Pro를 사용하여 메모리 덤프를 수집해보도록 한다.

여러 메모리 덤프 툴은 지원하는 총 메모리 크기에 차이가 있으며, 지원하는 윈도우 버전에도 차이가 있다. 따라서 분석하고자 하는 대상에 맞는 툴을 적절히 선택해야 한다. 참고로 앞서 언급한 FastDump Pro는 현재 대부분의 윈도우 버전에서 사용이 가능하다.
Fastdump Pro는 [그림 2]의 명령어로 메모리 덤프를 수집할 수 있으며, 결과 파일은 사용 중인 메모리의 크기와 동일하다. [그림 2]의 명령어를 실행시키는 경우 현재 운영중인 시스템의 메모리에 기록된 모든 내용이 MemDump.dd라는 파일에 저장되게 된다.

실행 방법 : FDPro.exe 메모리를_저장할_파일_이름
예 : C:\>FDPro.exe MemDump.dd

[그림 2] Memory Dump

이 과정을 통해 메모리 덤프 파일을 획득한 후, 해당 파일을 이용하여 어떠한 정보들을 얻을 수 있는지 알아보자.

2. 메모리 덤프 파일 분석
여기에서는 앞서 얻은 메모리 덤프를 이용하여 어떠한 정보들을 얻을 수 있는지를 살펴본다. 여러 메모리 분석 도구가 존재하지만 대부분의 윈도우 버전에서 분석이 가능한 상용 소프트웨어 HBGary Responder 2를 사용하여 분석을 진행하겠다.
HBGary Responder 2는 메모리에 저장되어 있는 하드웨어 관련 정보(IDT_ENTRY)와 운영체제에서 사용되는 정보(프로세스, 네트워크 연결, 레지스트리 등)를 보여준다. 또한 특정 프로세스에서 사용되는 메모리 내역을 분석하여 해당 프로세스에서 사용하는 API를 추출해 낸다. 특히, 이 API 정보 및 패턴을 사용하여 프로세스의 악성 여부를 판단하는 DDNA(Digital DNA)라는 기능을 제공하고 있다.

[그림 3]에서 아래 그림에서 상자로 표시된 부분이 DDNA를 나타낸 결과이다. 이번에 침해 시나리오는 [그림 3]에 표시된 두 번째 PID(Process identifier) 1452와 관계가 있으며, 자동 분석 툴에서도 악성으로 의심되는 것으로 판단하고 있다.
 

[그림 3] HBGary Responder 실행 화면

[그림 3]에서 왼쪽 탭을 살펴보면 메모리를 통해 추출할 수 있는 많은 정보들이 존재함을 알 수 있다. 문자열과 심볼, 로드된 모듈, 현재 열려있는 파일들, 네트워크 연결, 드라이버 그리고 인터넷 사용 기록 등 침해 사고 분석시 큰 도움을 줄 수 있는 정보들이 기록되어 있다.
여기에서 살펴볼 내용은 공격자의 행위 즉, 컴퓨터의 입장에서 살펴보면 하나의 ‘프로세스’에 대한 정보다. 프로세스를 살펴보면 공격자가 어떠한 행위를 하였는지, 어떠한 악성코드나 악의적인 서비스가 실행되고 있는지 등을 파악할 수 있다.
메모리 덤프에서 어떻게 공격자의 행위를 파악할 수 있는 정보를 추출할 수 있는 지 이해하기 위해서는 윈도우 커널 및 메모리 구조 등에 대해 많은 지식이 필요하다. 이 내용은 복잡하고 난해한 내용으로, 2부에서 자세히 다루도록 하겠다. 분석 도구는 수동으로 점검하는 경우에 불편한 점을 단순히 자동화한 것에 불가하다. 따라서 침해사고 분석가 입장에서 해당 툴이 어떠한 원리로 정보를 추출했는지 모른다면, 그 결과에 대해 객관성을 부여하기 어렵다.

악성 프로세스란 사용자의 의지와 상관없이 시스템에 설치되거나 하드디스크에 남아있는 파일에 의해 실행 중인 프로세스라고 볼 수 있다. 프로세스가 실행될 경우 PID(Process identifier)를 부여받게 되며 종료가 될 때까지 계속 부여받은 PID를 사용한다. 침해 당한 시스템의 메모리 덤프 분석 결과 DDNA의 점수(주황색)가 높은 프로세스를 확인해 보았다. 그 결과, 1452라는 PID를 사용하고 있는 svchost.exe가 악성으로 판단되었다.
 

[그림 4] 프로세스 확인

svchost.exe는 네트워크를 이용한 서비스를 운영하는데 필요한 파일이다. 정상적인 경우, 이 파일의 부모 프로세스는 Services.exe이다. 처음 부팅할 때 자동으로 실행되며 정상적으로 svchost.exe가 실행된 경우, svchost.exe의 부모 프로세스는 services.exe이며, 다른 svchost.exe 모두 동일한 PPID(Parent Process ID) 값을 가진다. 
 

[그림 5] 부모 ID가 다른 svchost.exe
메모리 덤프에서 네트워크와 관련된 오브젝트를 추출하여, PID 1452를 가진 svchost.exe는 IP 208.XXX.XXX.XXX에 TCP Port 80을 사용하여 연결 요청을 시도하는 것을 확인하였다. 
 

[그림 6] 악성코드가 접근하는 IP 정보
대부분 svchost.exe는 실행 가능한 파일이 별도로 존재하며, 이 파일이 svchost.exe를 이용하여 외부와 통신한다. 그러므로 정확한 분석을 위해 svchost.exe를 사용하는 실행 가능한 파일을 찾아야 한다. PID 1452와 관련된 실행 파일을 조사한 결과 악의적인 프로세스로 동작한 svchost.exe는 mssrv32.exe로 인해 실행된 것을 확인할 수 있다.
 

[그림 7] mssrv32.exe
[그림 8]에서 볼 수 있듯이 해당 파일을 안철수연구소 자동 분석도구에서 확인 결과 IRCBot으로 확인되었다.
 

[그림 8] 안철수연구소 자동 분석 도구

3. 하드디스크 이미지 분석
이 항목에서는 메모리 덤프에서 발견된 정보를 바탕으로, 디스크에서 증거를 찾아보는 시간을 갖겠다.
우선 메모리 분석 도구를 사용하여 밝혀낸 사실을 바탕으로 하드디스크 이미지로부터 해당 정보를 확인해보자. 이때 사용하는 분석 도구는 엔케이스 포렌식(Encase Forensic)이나 FTK 툴킷(Toolkit)과 같은 포렌식 전용 소프트웨어를 사용한다. 여기에서는 엔케이스 포렌식을 이용하여 증거물을 확인하는 방법에 대해서 살펴보도록 한다.
앞선 메모리 분석 과정에서 mssrv32.exe 파일이 악성코드임이 밝혀졌으며, 엔케이스에서 이 파일 이름을 키워드로 등록하여 검색할 수 있다. 검색 결과, [그림 9]와 같이 mssrv32.exe 파일이 검색되었으며 동일한 파일이 _bot.exe라는 이름으로 존재함을 확인하였다(동일한 해쉬 값).
 

[그림 9] mssrv32.exe 생성 시간 및 해쉬 값
[그림 9]를 보면 _bot.exe의 생성 시간이 2010년 08월 10일 오전 10:20:06이고 mssrv32.exe의 생성시간이 2010년08월 10일 오전 10:20:14 인 것을 확인할 수 있다. 따라서 _bot.exe가 생성된 후 동일한 파일인 mssrv32.exe가 생성된 것을 알 수 있다. 
추가 분석을 위해서 생성 시간을 기초로 2010년 08월 10일에 생성된 파일 내역을 검색했으며, 비슷한 시간 대에 _bot.zip가 바탕 화면에 존재했던 것을 확인했다. 또한 _bot.zip의 내용을 살펴보니 _bot.exe가 압축된 상태로 존재했다.
 

[그림 10] _bot.zip 경로

이제 공격자가 어떠한 방식으로 _bot.zip을 생성 했는지에 대해 추적해보자. 사실 시스템에 파일을 생성하는 방법은 많은 경우의 수가 있다. 해당 서버가 웹 서버인 경우, 업로드 게시판을 사용하여 업로드 했을 수도 있으며, 기타 FTP나 SCP 등의 프로토콜을 사용했을 수도 있다. 또한 최근에는 공격 대상을 사전에 정한 후 사회 공학적 기법을 이용한 메일 전송으로 악성코드 감염 및 침해로 이어지는 사례도 존재한다. 따라서, 정확한 유입 경로 조사를 위해 확인해야 할 사항이 많다. 즉, 웹 서버인 경우에는 웹 접근 로그, 기타 FTP 서비스 관련 로그 등이 존재하며, 레지스트리에서 확인할 수 있는 IE History(인터넷 사용 기록)과 이메일 받은 편지함, 각종 윈도우 로그 등에 대해서 점검을 수행해야 한다.
공격 대상 PC는 웹 서버 등 기타 외부에서 접근 가능하지 않기 때문에 내부 사용자에 의한 해킹으로 우선 가정하고, 조사할 수 있는 증거들에 대해 분석을 진행했다. 내부 시스템에서 확인할 수 있는 레지스트리를 점검한 결과 특이 사항이 없었으며, 마지막으로 받은 메일에 대한 점검을 수행했다.
이를 통해 [그림 11]과 같이 관리자를 유혹할 만한 내용으로 악성코드를 첨부하여 메일을 보낸 것을 확인했으며, 관리자는 해당 메일을 받아 악성코드를 실행한 것으로 확인되었다.
 

[그림 11] _bot.zip이 전송된 메일

엔케이스에서 ‘재미있는 게임’이라고 수신된 메일을 발견할 수 있었다. 이 메일은 2010년 08월 10일 오전 10:18:28에 관리자에게 도착했으며, 관리자는 해당 파일을 2010년 08월 10일 10:19:00(_bot.exe의 File Created)에 다운로드 했다. 이후 2010년 08월 10일 10:20:06(_bot.exe의 File Created)에 압축을 바탕화면에 풀고 _bot.exe를 2010년 08월 10일 10:20:06(_bot.exe의 Last Accessed)에 실행했다.
 

[그림 12] _bot.exe와 _bot.zip의 타임라인(TimeLine)

 

실행된 파일(_bot.exe)은 2010년 08월 10일 10:20:07에 삭제되면서 2010년 08월 10일 10:20:14(mssrv32.exe File Created)에 c:\windows\system32\mssrv32.exe를 생성했다. mssrv32.exe는 생성되자마자 실행된 것을 알 수 있다.
 

[그림 13] mssrv32.exe 타임라인

 

하드디스크 이미지 분석 결과, 악성코드는 메일을 통해 유입된 것으로 조사가 마무리 되었으며 자세한 타임라인은 아래와 같다.

타임라인(TimeLine) 요약 2010-08-10 10:18:28 메일 도착 2010-08-10 10:19:00 _bot.zip 다운로드 2010-08-10 10:20:06 _bot.zip 압축 해제 2010-08-10 10:20:06 _bot.exe 생성 및 실행 2010-08-10 10:20:07 _bot.exe 삭제 2010-08-10 10:20:14 mssrv32.exe 생성 및 실행

4. 메모리 덤프 시각화를 통한 효과적인 분석
앞선 예제에서 메모리 덤프에서 프로세스에 대한 오브젝트 추출을 통해, 실행 중인 프로세스 목록을 획득할 수 있음을 알아보았다. 이번에는 추출 과정을 거쳐 얻어낸 프로세스 정보를 시각화해주는 프로그램을 사용하여 효과적인 분석이 가능함을 보여주고자 한다.
앞서 다루었던 시나리오에서도 부모 프로세스와 자식 프로세스와의 관계가 잘못된 것을 찾아, 악성 여부를 판단하였다. 이와 같이 프로세스 간의 상호 관계를 한눈에 파악할 수 있는 방법이 존재한다. 지금부터 Volatility Framework이라는 또 다른 메모리 분석 툴을 소개하고 Graphviz라는 툴을 이용하여 [그림 14]와 같이 프로세스 목록을 시각화 하는 방법에 대해서 살펴보자.
 

[그림 14] Graphviz

Volatility Framework에서는 Graphviz(http://www.graphviz.org/)라는 오픈소스 그래프 시각화 소프트웨어를 사용하여 그래프로 표시할 수 있도록 지원하고 있다. 이 과정에 대해서 간단하게 설명하겠다.

프로세스의 시각화를 위해서 메모리에서 EPROCESS 구조체를 추출할 수 있는 Volatility Plugin을 사용하여 진행한다. Volatility Framework에 포함된 psscan이라는 플러그인은 메모리에 존재하는 EPROCESS 구조체를 전부 조사하여 DKOM(Direct Kernel Object Manipulation) 등으로 숨겨진 프로세스도 밝혀낼 수 있는 장점이 있다. 이 플러그인은 결과물을 Graphviz의 DOT 형식으로 출력해 주며, 실행 명령어는 다음과 같다.

 

명령어 : python volatility psscan –d -f .\ evidence_1.dd > evidence_1.dot -d : Dot 파일 형식으로 결과를 출력할 때 사용 -f : 분석 대상 메모리 파일 지정

앞서 분석했던 시스템에서 획득한 메모리를 Volatility Framework의 Psscan 플러그인으로 처리해도 역시 동일한 결과를 얻을 수 있었다.  분석 결과, 정상적인 svchost.exe 파일은 sevices.exe의 자식 프로세스이지만, 실행된 악성코드(PID 1188)는 현재는 삭제된 PID 680에 의해 실행된 것을 알 수 있다.
 

[그림 15] 정상 파일 vs. 악성 파일

 

[그림 15]와 같이 시각화 하는 경우에 부모-자식 프로세스의 관계를 한눈에 파악할 수 있고, 프로세스 실행 시간 관계, 현재 상태 등을 한눈에 파악할 수 있어 좀 더 쉽게 메모리 분석을 수행할 수 있다.

지금까지 침해 사고를 재구성하여 메모리 덤프를 획득하고, 툴을 이용하여 분석해 보았다. 메모리에서는 프로세스 관련 구조체 및 네트워크 관련 구조체, 그리고 중요한 단서가 될 수 있는 문자열 등 많은 증거들이 존재한다. 앞서 설명했듯이 메모리 덤프 분석을 통해 물리적 하드디스크 분석시에 얻을 수 없는 여러 정보를 확인할 수 있으며, 루트킷 등의 영향을 받지 않는 등의 많은 장점이 존재한다. 현재 공개되는 메모리 분석 툴이 증가하고 있으며, 지원하는 OS도 계속 업데이트 되고 있다.@