[Focus In-depth] 볼라틸리티를 이용한 메모리 분석 사례
컴퓨터 포렌식은 최근 몇 년 사이 침해 사고 대응과 분석 과정에서 중요한 기술적 분석 및 조사 기법으로 주목을 받고 있다. 그 동안 월간 ‘안’에서도 다양한 포렌식 기법을 소개해 왔으며, 앞으로 2회에 걸쳐 메모리 포렌식 기법을 집중적으로 살펴보려고 한다. 메모리 포렌식은 휘발성이 강하지만 고유의 독특한 정보가 많이 존재하는 물리적인 램(RAM)에 남아 있는 악성코드 감염과 관련된 다양한 흔적을 분석하는 기법이다
1부_ 메모리 포렌식의 필요성과 공개용 메모리 분석 SW 소개 (2014년 2월호)
2부_ 볼라틸리티를 이용한 메모리 분석 사례 (이번 호)
볼라틸리티(Volatility)를 이용한 메모리 분석 사례
지금부터 소개할 볼라틸리티를 이용한 메모리 분석 사례는 실제 악성코드에 감염된 윈도 시스템에서 생성한 메모리 덤프 파일을 대상으로 이루어졌다. 전체적인 메모리 분석 과정은 앞서 지난 호에서 언급한 6 단계의 메모리 분석 방법론에 따라 이루어졌다.
Backdoor/Win32.Rbot.R327
(a.k.a Win32/IRCBot.worm.variant, W32.IRCBot, Backdoor.Win32.Rbot.aftu)
해당 Backdoor/Win32.Rbot.R327는 몇 년 전 지속적으로 그 변형이 발견되었던, IRCBot 웜의 변형 중 하나이다. 일반적으로 IRCBot 웜 변형들은 감염된 윈도 시스템에서 리버스 커넥션(Reverse Connection)을 통해 인터넷에 존재하는 악성코드 제작자 또는 유포자가 개설한 IRC 채널로부터 다양한 악의적인 공격 명령을 수신하여 이를 실행한다.
IRCBot 웜에 감염된 윈도 시스템에서 생성한 메모리 덤프 파일을 백트랙 운영체제에 설치되어 있는 볼라틸리티의 ‘imageinfo’ 명령으로 [그림 1]과 같이 감염된 시스템의 윈도 버전과 메모리 덤프 파일의 생성 시각을 확인한다.
[그림 1] ‘imageinfo’ 명령으로 윈도 버전과 메모리 덤프 파일 생성 시각 확인
‘imageinfo’ 명령으로 확인한 윈도 운영체제 버전을 바탕으로 향후 분석 방향이 수립되었다면, [그림 2]와 같이 ‘psscan’ 명령과 ‘pslist’ 명령이 조합된 ‘psxview’ 명령을 이용하여 메모리 덤프 파일을 생성한 윈도 시스템에서 은폐 기능으로 동작하는 프로세스가 존재하는지 확인한다.
[그림 2] ‘psxview’ 명령으로 은폐된 프로세스가 있는지 확인
[그림 2]에서는 ‘pslist’와 ‘psscan’에서 모두 ‘True’가 검색 되었으므로, 해당 윈도 시스템에서는 은폐형 기능으로 동작하는 프로세스는 존재하지 않는 것으로 판단 할 수 있다.
또한 메모리 덤프 파일을 생성할 당시에 감염된 윈도 시스템에서 동작 중인 프로세스의 생성 시간과 이미 종료된 프로세스의 종료 시간 정보를 획득 할 수 있는 ‘psscan’ 명령으로 [그림 3]과 같이 프로세스와 관련 추가적인 정보를 획득한다.
[그림 3] ‘psscan’ 명령으로 프로세스와 관련된 추가 정보 획득
그리고, 실행 중인 프로세스의 상관 관계 정보를 획득하기 위해 [그림 4]와 같이 ‘pstree’ 명령으로 추가적인 정보를 획득한다.
[그림 4] ‘pstree’ 명령으로 프로세스의 상관 관계 정보 획득
[그림 4]에 존재하는 붉은색 박스의 프로세스 항목을 확인 해보면 의심스러운 사항이 발견된다. 일반적으로 윈도 시스템에서 실행 중인 시스템 프로세스는 트리(Tree) 구조에서 시스템(System) 이라는 부모 프로세스 항목에 자식 프로세스 구조를 가지게 된다.
하지만 붉은색 박스의 ssms.exe 프로세스는 다른 시스템 프로세스와 상관 관계를 가지고 있지 않으면서, 시스템 프로세스와 유사한 파일명을 가지고 있다. 이를 의심스러운 프로세스로 추정 해 볼 수 있다.
그 다음으로는 메모리 덤프 파일을 생성할 당시의 감염된 윈도 시스템에서 발생하였던 네트워크 접속 관련 정보들을 획득하기 위해 [그림 5]와 같이 ‘connections’ 명령을 실행한다.
[그림 5] ‘connections’ 명령을 통해 네트워크 연결 정보 획득
[그림 5]에 존재하는 붉은색 박스를 살펴보면, 악성코드에 감염된 윈도 시스템은 메모리 덤프 파일을 생성할 당시에 프로세스 아이디(PID) 240번 프로세스에 의해 외부 인터넷에 존재하는 87.117.252.150 시스템의 65146번 포트로 접속 중인 상태이다.
외부 인터넷에 존재하는 시스템과 접속 중인 PID 240번인 프로세스를 확인 하기 위해 [그림 5]를 다시 확인 해보면, 이는 최초 의심스러운 프로세스로 추정했던 ssms.exe 프로세스인 것을 알 수 있다.
앞서 PID 240번 프로세스인 ssms.exe가 외부 인터넷에 존재하는 시스템과 접속 중이며, 시스템 프로세스 구조상 의심스러운 부분이 있다는 것을 확인했다. 해당 의심스러운 프로세스가 실제 악성코드가 정확한지 확인하기 위해 메모리 덤프 파일에서 [그림 6]과 같이 “procexedump” 명령을 실행한다.
해당 명령은 특정 프로세스의 메모리 영역 전체를 파일 형태로 추출할 수 있으며, 볼라틸리티에 의해 추출된 파일명은 executable.[PID].exe 형태를 가지게 된다.
[그림 6] ‘procexedump’ 명령으로 특정 프로세스 메모리 영역을 파일 형태로 추출
여기에서 주의할 점은 특정 프로세스 메모리 영역 전체를 파일 형태로 추출 할 수 있다고 하여, 추출한 해당 파일을 다른 윈도 시스템에서 실행을 통해 동적 분석을 수행 할 수는 없다.
이는 일반적으로 메모리에 적재된 파일들을 메모리 덤프를 통해 추출 해 낼 경우, 실제 디스크상에 존재하는 파일의 PE(Portable Executable) 파일 형식에서 IAT(Import Address Table)가 손상되어 실제 윈도 시스템에서는 정상적으로 실행 되지 않기 때문이다.
그러므로, 메모리 덤프를 통해 추출해낸 파일의 경우에는 인위적으로 IAT를 보정해주는 과정을 거쳐야 한다. 하지만, 해당 과정에 대한 설명은 본 원고의 주제를 벗어나는 부분임으로 다루지 않도록 한다.
의심스러운 프로세스인 ssms.exe의 메모리 영역 전체를 ‘procexedump’ 명령을 통해 파일 형태로 추출한 executable.240.exe에서, 사람이 읽을 수 있는 문자열들을 추출하기 위해 [그림 7]과 같이 백트랙에 포함된 ‘string’ 명령을 이용하여 임의로 텍스트 파일을 생성한다.
[그림 7] ‘string’ 명령으로 파일 형태의 프로세스 메모리 영역에서 문자열 추출
사람이 읽을 수 있는 문자열을 추출해 낸 텍스트 파일을 열어보면, [그림 7]과 같이 일반적으로 IRC 채널 접속을 위해 사용하는 IRC 명령어와 함께 윈도 시스템에 존재하는 레지스트리 키를 발견하게 된다.
[그림 8] ‘string’ 명령으로 파일 형태의 텍스트 파일에서 발견된 문자열
해당 단계에서 발견된 IRC 명령어와 레지스트리 및 다른 관련 문자열을 조합해 볼 때 PID 240번 프로세스인 ssms.exe는 기존에 많이 발견되었던 IRCBot 웜의 변형 중 하나일 것으로 판단할 수 있다.
[그림 8]에서 발견한 IRC 관련 명령어를 [그림 9]과 같이 “yara” 명령어를 이용하여 PID 240번을 가지는 ssms.exe 프로세스 메모리 전체 영역을 검색 해보면, 기존에 많이 발견되었던 IRCBot에서 사용되는 문자열을 추가적으로 발견할 수 있다.
[그림 9] ’yara’ 명령으로 특정 프로세스 메모리 영역에서 문자열 검색
그리고, 해당 IRCBot 웜 변형이 윈도 시스템의 레지스트리에서 어떠한 부분에 자신과 관련된 키를 생성하였는지 확인 하기 위해, 메모리 덤프 파일에 존재하는 윈도 레지스트리 관련 정보를 추출하는 ‘printkey’ 명령과 함께 인자 값으로 [그림 10]에서 추출한 윈도 레지스트리 관련 문자열을 사용했다.
[그림 10] ‘printkey’ 명령으로 의심스러운 프로세스를 생성한 윈도 레지스트리 키 검색
이 과정에서 [그림 10]과 같이 윈도 시스템에서 일반적으로 악성코드가 자동 실행을 위해 많이 사용하는 레지스트리 위치에 ‘윈도 업데이트(Windows Update)’라는 키를 생성하고 자신을 데이터로 생성한 것을 확인 할 수 있다.
Trojan/Win32.Oficla
(a.k.a Win-Trojan/Oficla.82432.C, Trojan.Sasfis, Trojan.Win32.Oficla.bv)
Trojan/Win32.Oficla는 기존에 알려진 브레도랩(Bredolab) 트로이목마 변형 중 하나로서, 금융 정보 탈취를 목적으로 제작 및 유포되는 제우스(Zeus)와 스파이아이(SpyEye)의 소스코드(Source Code)에서 파생되어 제작되어진 형태이다.
그리고, 정상 시스템 프로세스인 svchost.exe 또는 explorer.exe의 프로세스 메모리 영역 중 하나 또는 그 이상의 쓰레드 영역을 생성하여 자신의 코드 또는 전체를 코드를 인젝션하여 동작한다. 감염이 성공적으로 이루어지면 외부 인터넷에 악성코드 제작자 또는 유포자가 생성한 C&C(Command and Control) 시스템으로부터 명령을 수신하여 다른 악성코드 다운로드 후 실행하는 기능 등을 수행한다.
Oficla 트로이목마에 감염된 윈도 시스템에서 생성한 메모리 덤프 파일을 백트랙 운영체제에 설치되어 있는 볼라틸리티의 “imageinfo” 명령으로 [그림 11]와 같이 감염된 시스템의 윈도 버전과 메모리 덤프 파일의 생성 시각을 확인한다.
[그림 11] ‘imageinfo’ 명령으로 윈도 버전과 메모리 덤프 파일 생성 시각 확인
‘imageinfo’ 명령으로 확인한 윈도 운영체제 버전을 바탕으로 향후 분석 방향이 수립되었다면, [그림 12]와 같이 ‘psscan’ 명령과 ‘pslist’ 명령이 조합된 ‘psxview’ 명령을 이용하여 메모리 덤프 파일을 생성한 윈도 시스템에서 은폐 기능으로 동작하는 프로세스가 존재하는지 확인한다.
[그림 12] ‘psxview’ 명령으로 은폐된 프로세스 존재 여부 분석
[그림 12]에서는 ‘pslist’와 ‘psscan’에서 모두 ‘True’가 검색 되었으므로, 해당 윈도 시스템에서는 은폐 기능으로 동작하는 프로세스는 존재하지 않는 것으로 판단할 수 있다.
메모리 덤프 파일을 생성 할 당시에 감염된 윈도 시스템에서 동작 중인 프로세스의 생성 시간과 이미 종료된 프로세스의 종료 시간 정보를 획득 할 수 있는 ‘psscan’ 명령으로 [그림 13]과 같이 프로세스와 관련 추가적인 정보를 획득한다.
[그림 13] ‘psscan’ 명령으로 프로세스와 관련 추가 정보 획득
그리고, 실행 중인 프로세스의 상관 관계 정보를 획득하기 위해 [그림 14]와 같이 ‘pstree’ 명령으로 추가적인 정보를 획득한다.
[그림 14] ‘pstree’ 명령으로 프로세스의 상관 관계 정보 획득
[그림 14]에 존재하는 붉은색 박스의 프로세스 항목을 확인 해보면 의심스러운 사항이 발견된다. 일반적으로 윈도 시스템에서 실행 중인 시스템 프로세스는 트리(Tree) 구조에서 시스템(System) 이라는 부모 프로세스 항목에 자식 프로세스 구조를 가지게 된다.
하지만 붉은색 박스의 svchost.exe 프로세스는 다른 시스템 프로세스와 상관 관계를 가지고 있지 않으면서, 시스템 프로세스와 동일한 프로세스 명을 가지고 있음으로 이를 의심스러운 프로세스로 추정 해 볼 수 있다.
그 다음으로는 메모리 덤프 파일을 생성할 당시의 감염된 윈도우 시스템에서 발생하였던 네트워크 접속 관련 정보들을 획득하기 위해, ‘connections’ 명령을 실행했다. 하지만, 그 당시에 외부 인터넷에 존재하는 시스템에 접속 중인 활성화 상태의 프로세스는 존재하지 않았다.
추가적으로, 이미 종료된 네트워크 접속 상태 정보들을 획득하기 위해 [그림 15]와 같이 ‘connscan’ 명령을 통해, 외부 네트워크로 접속했던 프로세스 리스트를 확인했다.
[그림 15] ‘connscan’ 명령을 통해 네트워크 연결 정보 획득
이 과정에서 최초 [그림 14]에서 의심스러운 프로세스로 추정했던 PID 192번 프로세스인 svchost.exe가 외부 네트워크로 접속을 하였던 흔적이 발견되었다.
해당 의심스러운 프로세스가 실제 악성코드가 정확한지 확인하기 위해 메모리 덤프 파일에서 첫 번째 분석 사례에서 언급한 [그림 6]과 같이 의심스러운 프로세스인 svchost.exe의 메모리 영역 전체를 ‘procexedump’ 명령을 통해 파일 형태로 추출했다.
그 이후, 사람이 읽을 수 있는 문자열을 추출하기 위해 파일에서 첫 번째 사례에서 언급한 [그림 7]과 같이 백트랙에 포함되어 있는 ‘string’ 명령을 이용하여 임의로 텍스트 파일을 생성하여, 문자열을 확인했다. 그러나 특별히 악성코드로 의심 할 수 있는 문자열을 확인하지 못했다.
의심스러운 프로세스인 svchost.exe의 메모리 영역 전체가 악성코드가 아닐 수도 있음으로, 해당 프로세스 메모리 영역에 코드 인젝션이 발생 한 것을 확인 하기 위해, [그림 16]와 같이 “malfind” 명령을 통해 PID 192번의 의심스러운 프로세스인 svchost.exe의 메모리 영역을 검사했다.
[그림 16] ‘malfind’ 명령을 이용해 특정 프로세스 메모리 영역의 코드 인젝션 정보 획득
이 과정에서 svchost.exe의 메모리 영역의 0x90000 주소에서 특정 코드가 인젝션이 된 것이 발견되었다. 해당 프로세스 메모리 영역에서 발견된 코드 인젝션에 대한 추가 정보 획득을 위해 [그림 17]과 같이 ‘volshell’ 명령을 실행 한 후 ‘CC’ 명령으로 PID 192번 svchost.exe의 메모리 영역을 호출하였다.
[그림 17] ‘volshell’ 명령 실행 후 ‘CC’ 명령으로 PID 192번 svchost.exe의 메모리 영역 호출
그리고, ‘volshell’ 명령 창에서 [그림 18]과 같이 ‘db’ 명령을 실행하여, 앞서 언급한 [그림 16]에서 확인한 코드 인젝션이 시작되는 0x90000 주소부터 호출하는 메모리 크기를 조금씩 늘려나가며 분석을 진행하였다.
[그림 18] ‘volshell’ 명령 실행 후 ‘db’ 명령으로 0x90000에서 640 바이트만큼 호출
크기를 조금씩 늘려나가며 분석하는 과정에서, 640 바이트(byte) 크기만큼 호출한 영역에서 [그림 18]의 붉은색 박스에서와 같이 의심스러운 문자열들을 확인 할 수 있었다. 인젝션 된 메모리 영역에서 “1.tmp” 이라는 문자열이 존재하므로 코드 인젝션이 DLL 파일에 의해 발생한 것으로 추정 할 수 있다.
의심스러운 프로세스로 추정했던 PID 192번 svchost.exe의 메모리 영역에 대한 모듈(module) 정보를 획득하기 위해 [그림 19]와 같이 “ldrmodules” 명령을 실행하여 로드 되었거나 인젝션 되어 있는 DLL 파일을 확인했다.
[그림 19] ‘ldrmodules’ 명령을 실행하여 로드 되거나 인젝션된 DLL 파일
이 과정에서 앞서 언급한 [그림 18]에서 발견된 [그림 19]의 붉은색 박스와 동일한 ‘1.tmp’ 파일이 PID 192번 svchost.exe의 쓰레드 영역에도 로드된 것을 확인 할 수 있었다. 여기에서 발견된 ‘1.tmp’가 악성코드인지 정확히 확인하기 위해 해당 ‘1.tmp’ 파일의 메모리 영역을 파일 형태로 추출이 필요하다. 이를 위해 [그림 20]과 같이 ‘dlldump’ 명령으로 ‘1.tmp’의 메모리 영역인 0x10000000부터 파일 형태로 추출하였다.
[그림 20] ‘dlldump’ 명령으로 ‘1.tmp’의 메모리 영역인 0x10000000부터 파일 형태로 추출
의심스러운 파일인 ‘1.tmp’의 메모리 영역 전체를 ‘dlldump’ 명령을 통해 파일 형태로 추출한 후, 사람이 읽을 수 있는 문자열을 추출하기 위해 [그림 21]과 같이 백트랙에 포함되어 있는 ‘string’ 명령을 이용하여 임의로 텍스트 파일을 생성한다.
[그림 21] ‘string’ 명령으로 파일 형태로 추출된 ‘1.tmp’ 메모리 영역에서 문자열 추출
사람이 읽을 수 있는 문자열을 추출 해낸 텍스트 파일을 열면, [그림 22]와 같이 특정 웹 사이트 주소 관련 문자열이 발견된다.
[그림 22] ‘1.tmp’로부터 추출한 파일에서 발견된 특정 웹 사이트 문자열
[그림 22]에서 발견한 특정 웹 사이트 주소를 [그림 23]과 같이 ‘yara’ 명령어 키워드에 특정 웹사이트 주소를 이용하여 전체 메모리 덤프 파일을 대상으로 검색 해보면, 코드 인젝션이 발생한 PID 192번 프로세스인 svchost.exe만이 검색된다.
[그림 23] ‘yara’ 명령으로 메모리 덤프 전체 영역에서 특정 웹 사이트 문자열 검색
이러한 일련의 분석 과정을 정리하자면, 최초 의심스러운 프로세스였던 PID 192번 svchost.exe에는 ‘1.tmp’ 라는 악성코드로 판단되는 파일이 ㅆ레드로 인젝션되어 svchost.exe 프로세스를 이용하여 외부 특정 시스템으로 역 접속을 시도했던 것으로 판단할 수 있다.
맺음말
앞서 우리는 컴퓨터 포렌식이 침해 사고 대응과 분석이 이루어지는 과정에서 어떠한 역할을 하는지 살펴보고, 여기서 다시 멀웨어 포렌식이라는 새로운 기술적인 영역이 악성코드의 감염 경로와 악성코드로 의심되는 파일들을 추출하기 위해 어떠한 세부 기술들이 사용되는지 알 수 있었다.
이러한 세부 기술들 중에서 메모리 분석을 위한 메모리 포렌식이 무엇이며, 어떠한 소프트웨어들로 분석이 가능한지도 알 수 있다. 그 중에서도 메모리 분석을 위해 가장 많이 사용되는 소프트웨어 중 하나인 볼라틸리티가 무엇이며, 볼라틸리티를 이용하여 실제 악성코드에 감염된 시스템에서 생성한 메모리 덤프 파일들의 분석 과정과 사례들을 살펴보았다.
볼라틸리티를 이용한 메모리 포렌식 분석 사례들을 통해 일련의 과정들을 살펴보면, 메모리 분석의 장ㆍ단점이 존재한다.
우선, 메모리 포렌식 분석은 메모리에만 존재하는 휘발성 정보들로부터 악성코드 감염 시스템에서 발생한 다양한 정황적 정보를 확보할 수 있음을 알 수 있다. 그리고 생성한 메모리 덤프 파일을 대상으로 추후에라도 다양한 메모리 분석 툴과 기법을 이용하여 반복적인 적용과 검토가 가능 하다는 장점이 존재한다.
이 외에도 메모리 포렌식 분석에 사용된 볼라틸리티와 관련 플러그인들 모두가 파이선으로 제작되어, 운영체제에 따른 제약을 받고 사용이 가능한 확장성이 뛰어나고, 시스템적인 자동화와 같은 부가적인 응용성이 뛰어나다고 볼 수 있다.
이러한 장점들이 존재하지만 메모리 포렌식 분석만으로는 악성코드에 감염된 시스템을 완벽하게 분석하기에는 많은 어려움이 따른다. 그러므로, 최초 앞부분에서 언급하였던 다른 멀웨어 포렌식 기법들과 병행이 되어야만이 조금 더 자세하게 분석을 진행 할 수 있다.
그리고, 볼라틸리티를 이용한 메모리 포렌식 분석에서는 메모리 덤프 파일에 존재하는 윈도 레지스트리 정보를 분석하기에는 많은 어려움이 따른다. 볼라틸리티를 이용한 메모리 분석 사례에서는 언급되지 않았지만 사용자와 커널 모드에서 은폐 기법을 사용하는 악성코드에 의해 생성된 프로세스 영역을 볼라틸리티에서는 은폐된 프로세스로 탐지는 가능하다. 하지만, 다른 형태와 기법 등으로 추가적인 분석을 진행하기에는 많은 제약이 따른다.
하지만, 전체적인 메모리 포렌식과 관련된 기술의 발전이 빠르게 진행되고 있다. 또한 다양한 컴퓨터 포렌식커뮤니티에서 이와 관련된 논의들이 자주 이루어지고, 메모리 포렌식만을 전문으로 하는 컨퍼런스가 해마다 개최되고 있다는 점에서 메모리 포렌식 기술의 발전은 긍정적이라고 할 수 있다.
그러므로, 향후에는 침해 사고 대응과 분석 과정에서 메모리 포렌식 분석이 차지하는 비중은 점점 커질 것이며, 이와 관련된 다양한 소프트웨어와 분석 기법들을 많이 등장하리라 판단된다. @
[참고 문헌]
인사이드 윈도우 포렌식 (Windows Forensic Analysis 2/e, 2009년), 할랜 카비 저, 정상민, 정명주 역, 박병익 감수, BJ 퍼블릭, 2010년
제 1장 실시간 대응: 휘발성 데이터 수집
제 2장 실시간 대응: 데이터 분석
제 3장 윈도우 메모리 분석
■ 윈도 포렌식 실전 가이드, 고원봉 저, 한빛 미디어, 2010년
1장 라이브 리스폰스
2장 메모리 분석
■ 악성코드와 멀웨어 포렌식 (Malware Forensics, 2008년), 제임스 아퀼리나, 에이헨 케이시, 카메론 말린 저, 박재호 역,
에이콘, 2012년
01장 멀웨어 사고 대응: 동작 중인 윈도우 시스템에서 휘발성 자료 수집과 검사
03장 메모리 포렌식: 멀웨어 관련 증거물에 대한 물리적 메모리 덤프와 프로세스 메모리 덤프 분석
■ 표적형 공격 보안 가이드, APT 공격, 실전 방어 및 대응 (HYOUTEKIGATA KOUGEKI SECURITY GUIDE, 2013년),
이와이 히로키 저, 박선필 역, BJ 퍼블릭, 2013년
6장 초동 대응
6-1 스냅샷 취득
■ Mastering Windows Network Forensics and Investigation, Second Edition, Steve Anson, Steve Bunting, Ryan Johnson, Scott Pearson 저, Sybex, 2012년
Chapter 6 Live-Analysis Techniques
■ Malware Forensics Field Guide for Windows System – Digital Forensics Field Guides, Cameron H. Malin, Eoghan Casey, James M. Aquilina 저, Syngress, 2012년
Chapter 2 Memory Forensics – Analyzing Physical and Process Memory Dumps for Malware Artifacts
■ SANS Forensic 508 Advanced Computer Forensic Analysis And Incident Response, Rob Lee 저, SANS Institute, 2011년
508.2 Live Response and Complex Evidence Acquisition
Windows Live Response
■ Virtual Forensics: A Discussion of Virtual Machines Related to Forensics Analysis
http://www.forensicfocus.com/downloads/virtual-machines-forensics-analysis.pdf
■ FATKit: A Framework for the Extraction and Analysis of Digital Forensic Data from Volatile System Memory
http://www.4tphi.net/fatkit/papers/dfrwswip.pdf
■ Volatools: Integrating Volatile Memory Forensics into the Digital Investigation Process
http://www.blackhat.com/presentations/bh-dc-07/Walters/Paper/bh-dc-07-Walters-WP.pdf
■ Open Memory Forensics Workshop (OMFW)
https://www.volatilesystems.com/volatility/omfw/Walters_OMFW_2008.pdf
■ Windows Memory Dump Analysis Volatility Plugin 을 이용한 Windows Memory Dump 분석
http://ls-al.org/wp-content/uploads/2012/07/volatility-plugin-manual11.pdf
- AhnLabASEC 분석팀 장영준 선임연구원