포포포포렌식 #3

#1. 메모리 분석

#1-1. 운영체제 버전?

보통 침해사고가 터졌을 때 따로 해당 pc의 ip주소와 운영체제 버전 정보 등을 따로 가져오는 것이 일반적이다.

하지만 이 정보를 얻지 못한 경우, 메모리 덤프에서도 운영체제의 버전 획득이 가능하다.

< imageinfo 옵션 >

< kdbgscan 옵션 >

inp : volatility -f 메모리덤프 imageinfo

inp : volatility -f 메모리덤프 kdbgscan

volatility의 imageinfo, kdbgscan 옵션을 이용하여 운영체제 정보를 획득할 수 있다.

Win7SP0x86, Win7SP1x86을 확인할 수 있다.

#1-2. 메모리 사본 확보 시간(한국 시간)은?

지금까지는 파일의 변경 시간을 가지고 판단하였다.

< 메모리 덤프 속성 정보 >

보면 마지막 수정 시간을 확인할 수 있다. 이는 volatility의 프로세스 정보 확인을 통해 알 수 있다.

< psscan 옵션 >

inp : volatility -f 메모리덤프 --profile=Win7SP0x86 psscan

volatility의 psscan의 결과를 조금 보기 좋게 변경한 그림이다.

보면 DumpIt.exe 라는 프로세스가 목록에 올라와 있는데 이 프로세스가 메모리 덤프를 만든 프로세스이다.

보면 Timecreated 시간이 2014-02-03 12:31:34 UTC+0000으로 되어있다. 한국 시간은 UTC+09이다.

파일 시간상으로는 2014-02-03_07:33:12인데 프로세스 시작 시간은 2014-02-03_21:31:34이다.

#1-3. 메모리 사본시 사용한 사용자 이름은?

확인 방법은 여러 가지가 있을 법 한데 여기서 사용한 방법은

DumpIt 경로 파악, 현재 레지스트리 유저 파악 등이 있다.

< volatility - userassist >

inp : volatility -f 메모리덤프 --profile=Win7SP0x86 usrassist

userassist의 일부분이다. 이전 과제에서 userassist는 프리패치와 함께 사용자가 주로사용하거나 최근 사용한 프로그램을 알 수 있다고 했다. 보면 메모리 덤프를 획득할 때 사용한 DumpIt.exe가 Users하위의 Tek Defense경로 하위 바탕화면에 존재한다.

보통 Users 경로 하위에는 사용자의 계정이 존재하므로 Tek Defense라는 사용자로 획득을 한 것을 알 수 있으며 아래 ntuser.dat을 보았을 때도 같은 Tek Defense라는 계정을 확인할 수 있다.

< rekall - users >

추가로 rekall을 이용하여 유저 정보를 파악한 화면이다. 유저는 Administrator, Guest, Tek Defense가 있다.

윈도우를 설치하면 기본적으로 Administrator와 Geust가 생성되지만 통상적으로는 사용하지 않는다.

또 위 정보에서 보았을 때 Administrator는 LastLoginTime이 2010년도이고 Guest는 아예 존재하지 않는다.

Tek Defense만이 DumpIt을 실행 시켰던 시간 대역에 존재하므로 Tek Defense 계정에서 사용하였음을 파악할 수 있다.

++

추가로 rekall의 peinfo를 사용하면 해당 프로그램의 사용자를 확인할 수 있다.

#1-4. 메모리 사본에 사용한 도구와 버전은?

DumpIt이라는 프로그램이 메모리 사본에 이용되었다는 것을 안 것은 이번 침해사고 대응 덕분에 알게 되었다.

일단 DumpIt이라는 프로그램을 사용하여 메모리 사본을 획득 하였다고 해도 버전을 알기 위해서는 해당 프로그램을 얻어야 한다.

메모리에서 프로세스목록에 있는 DumpIt을 직접 획득하여 프로그램화 하고 버전을 확인하면 된다.

< volatility - pslit >

inp : volatility -f 메모리덤프 --profile=Win7SP0x86 pslist

먼저 불필요한 프로세스는 획득할 필요가 없으므로 획득에 필요한 DumpIt의 PID를 확인한다.

pslist 옵션에서 확인을 하면 되며 DumpIt의 PID는 3060이다.

< volatility - pslist >

inp : volatility -f 메모리덤프 --profile=Win7SP0x86 -D 저장경로 -p PID

먼저 procdump 명령을 준다.

volatility -f 덤프파일 --profile=운영체제정보 procdump -D 저장경로 -p pid

이런식으로 해주면 된다. DumpIt은 윈도우 계열이므로 윈도우에서 확인을 해 보았다.

< 생성된 파일 & DumpIt 실행화면 >

procdump로 DumpIt을 프로그램화 시키면 위에처럼 'execute.PID번호.exe' 형태로 파일이 추출된다.

하지만 여기서 프로세스를 추출하여도 실제로 실행을 할 수는 없다. 위 화면은 기존에 보유하고 있던 DumpIt을 실행시킨 화면이다. 보면 콘솔에서 실행을 시키는 방식이다. 따라서 커맨드 명령을 추적하면 알아낼 수 있다.

< volatility - consoles >

inp : volatility -f 메모리덤프 --profile=Win7SP0x86 consoles

위에서 실제 DumpIt을 사용했을때와 같은 화면이다. 프로세스를 싱행시키고 위에 부분에 보면 버전을 확인할 수 있다.

메모리덤프에 사용된 DumpIt의 버전은 v1.3.2.20110401이다.

#1-5 a. 네트워크 연결 상태를 확인하라

volatility에서 확인할 수 있는 네트워크 관련 기능은 connections, connscan, netscan, sockets, sockscan이 있는데 이 중에 netscan을 제외한 다른 기능들은 win7에서는 지원을 하지 않는다. 따라서 netscan을 이용하였다.

< volatility - netscan>

inp : volatilty -f 메모리덤프 --profile=Win7SP0x86 netscan

netscan을 통해 나온 결과물을 보기 좋게 수정한 화면이다.

보면 대부분 system이나 windows에서 기본적으로 이행되는 svchost, services등의 프로세스가 가지는 네트워크인데 제일 아래줄을 보 연결이 끊어진 tcp연결이 하나 있다. 연결이 끊어져서 다른 정보는 확인할 수 없지만 외부로 연결한 아이피 주소가 176.106.48.182라는 것을 확인할 수 있다.

#1-5 b. 여러 후킹 상태를 확인하라

후킹 정보를 확인할 수 있는 volatility의 기능은 apihook이다. user, kernel모드에서 api hooking 정보를 확인할 수 있다.

< apihooks 결과 일부 >

inp : volatility -f 메모리덤프 --profile=Win7SP0x86 apihooks

보면 후킹에 이용된 프로세스명과 이용된 모듈이 victim module로 나온다. 위처럼 svchost, explorer등이 있었는데 아래에서 악성 프로세스라고 의심을 했던 runddl32.exe에도 여러 dll들을 후킹한 흔적을 확인할 수 있었다.

< runddl32.exe의 후킹 >

runddl32.exe와 관련된 후킹은 총 19가지로 나오며 일부를 보기 좋게 수정한 화면이다. 보면 Victim module은 URLMON.DLL로 이 dll파일을 후킹한 것으로 파악되며 사용한 function이 다양하게 나온다. 이외에도 iertutil.dll, WININET.dll이 사용된 것으로 파악된다.

< rekall - messagehooks >

rekall을 이용하여 메시지 후킹 정보를 확인한 화면인데 runddl32.exe를 보면 스레드에 상관없이 키보드 메시지를 후킹하는 것으로 보아서 키로깅 기능이 가능할 것이다.

#1-5 c. 프로세스 인젝션 상태를 확인하라

후킹 정보와 마찬가지로 volatility의 기능 중 malfind를 사용하면 된다. 아니면 dllist, dlldump, ldrmodules등을 이용하여 악성코드로 의심되는 프로세스와 관련된 dll들을 분석하면 된다.

< malfind 옵션 >

inp : volatility -f 메모리덤프 --profile=Win7SP0x86 maflind  -p 1524 -D 저장경로

pid값을 1524로 주고 mafind를 시행한 화면이다. pid 1524는 runddl32.exe의 pid이다. 또 -D 옵션으로 저장경로를 주게되면 injected된 바이너리를 얻을 수 있다. 여기서는 process.0x84536030.0x220000.dmp라는 이름으로 생성되었다.

만약 injected된 dll이나 기타 데이터가 패킹이 되어 있다고 하더라도 여기서 나오는 데이터의 경우 메모리에 상주된 후의 데이터 이기 때문에 패킹이 풀린 바이너리 값을 얻을 수 있다.

#1-6. 수상하게 생각하는 프로세스와 그 이유는?

< pslist - runddl32.exe >

보면 runddl32.exe라는 프로세스가 목록에 올라와있다. 작업 관리자를 보면 주로 올라와있는 rundll32.exe를 가장한 프로세스가 아닌가 싶다. 그 이외에 프로세스 목록에서 알 수 있는 특이한 프로세스는 없었다.

#1-7. 수상한 프로세스의 핸들과 뮤턴트를 살펴보고 특이사항은?

핸들과 뮤턴트를 확인하기 전에 프로세스에서 핸들이란 무엇일까?

핸들은 파일, 레지스트리 키, 뮤텍스 프로세스 또는 스레드와 같은 커널 객체의 열린 인스턴스에 대한 참조라고 한다.

(ref 메모리 포렌식:혜지원)

뮤턴트는 위에서 사용된 메모리에서 KMUTANT 객체를 확인하는 것인데 KMUTANT는 윈도우 커널에서 뮤텍스를 관리하는 구조체이다. 각자의 뮤텍스는 고유의 이름을 가지는 뮤텍스를 만들 수 있고 이 목록이 있는 곳이 KMUTANT일 것이다.

먼저 프로세스 핸들을 확인해 보았다.

< runddl32.exe handles 일부 >

inp : volatility -f 메모리덤프 --profile=Win7SP0x86 handles -p 1524

runddl32.exe의 핸들을 보기위해 -p 옵션에 1524를 넣어준다.

일단 이상하게 생각되는 것은 Thread이벤트로 TID XX PID 1896, TID XX PID 1316이 확인되었다. PID 1896, 1316은 각각 notepad.exe, svchost.exe였다. runddl32.exe가 notepad와 svchost에 어떠한 관여를 하지 않나 싶다.

< runddl32.exe의 handles와 mutantscan 일부 >

inp : volatility -f 메모리덤프 --profile=Win7SP0x86 mutantscan

runddl32.exe의 핸들중에 mutant 이벤트로 위처럼 DC_MUTEX-KHNEW06을 확인할 수 있고 mutantscan을 통해 해당 뮤텍스 offset과 사용횟수를 파악할 수 있다. DC_MUTEX-KHNEW06은 그냥 여기서 사용한 뮤텍스 이름이라고 한다.

실제 악성코드의 경우 사용된 뮤텍스를 가지고 판단을 하는 경우도 있다고 한다.

#1-8. 악성코드의 종류에 대해 알아보아라.

프로세스의 덤프가 제대로 이루어 지지 않아서 분석을 하지 못하였다. 여기까지 확인한 정보를 바탕으로 보면 프로세스가 실행되면 notepad에 어떠한 처리를 하며 dllinjection을 하고 네트워크를 이용한다.

< rekall - peinfo >

runddl32.exe의 peinfo 화면이다.

실제 실행은 되지 않으며 Runtime Error를 띄우지만 위처럼 Remote Service Application이라는 메시지 박스도 띄우며 종료된다.

원격 서비스로 위장하여 실행이 되지 않나 싶다.

#1-9. 악성코드의 생성일자는?

프로그램의 생성 시간은 mft 테이블을 조회하면 알 수 있는데 volatility와 rekall에서 각각 mftparser, mftdump옵션을 이용하면 된다.

< volatility - mftparser >

volatility의 mftparser에서 runddl의 mft정보를 가져온 그림이다.

보면 파일의 MAC시간을 알아낼 수 있다.

Modified Time : 2013-12-18_22:40:20 UTC+0000

Access Time : 2014-02-03_12:27_17 UTC+0000

Created Time : 2014-02-03_12:27:17 UTC+0000

여기서 Modified Time의 시점이 더 이전인 이유는 Access, Created Time은 피해 PC에 생성되고, 접근된 시간이지만 Modified Time은 이 프로그램 자체가 수정된 마지막 시간을 의미하기 때문이다.

< rekall - mftdump >

rekall의 mftdump에서 runddl의 정보를 가져온 그림이다.

volatility와 비교를 해 보면 MAC 정보는 보다 한눈에 알 수 있지만 프로그램의 상세 경로와 기타 정보등을 알기 위해서는 volatility가 더 용이한 것 같다.

#1-10. 악성코드 감염일자를 추정해보고, 그 이유를 말하라.

감염일자는 2014-02-03 일 것이다. 통상적으로 AppData/Local/Temp에 존재하는 데이터는 인터넷으로 다운로드 받는 동시에 실행을 시킨 임시 프로그램들이 저장되는 장소이며 프로그램이 PC에 생성된 일자가 위처럼 되어 있으며 프로세스 실행 시간을 봐도 같은 날짜이기 때문이다.

#1-11. 악성코드의 설정(옵션) 상태에 대하여 말하라.

부모 프로세스가 존재하지 않아 어떠한 설정으로 실행되었는지 파악할 수 없었다.

#1-12. 악성코드가 연결하는 서버가 있다면 서버 주소를 말하라.

악성코드의 네트워크 관련사항은 다음과 같다.

피해 PC에서 서버 소켓을 생성한다. -> 클라이언트(해커)가 접속을 요청한다.

하지만 무작정 해커가 들어올 순 없고 먼저 피해PC에서 해커의 PC로 접속을 요청할 것이다.

< runddl - string 일부 >

runddl32.exe의 스트링값을 추출해 보면 위처럼 127.0.0.1:1604라는 데이터를 얻을 수 있다.

< volatility - netscan >

#1-5 a. 네트워크 연결 정보에서도 확인하였던 그림인데 보면 176.106.48.182:1604로 Foreign Address를 확인할 수 있다.

결과적으로 피해PC에서 1604 포트를 열어놓는 소켓을 생성하였고 위 아이피주소에서 접근을 한 것이므로 여기서 나타내는 아이피 주소가 악성코드의 행위에 연결되는 서버라고 할 수 있다.

#1-13. 악성코드가 감염상태 유지를 위해 사용한 방법을 말하라.

#1-14. 악성코드 존재를 감추기 위해 사용한 방법은?

hidefolder 등 함수를 사용하는것은 파악하였으나 정확한 로직은 파악하지 못하였다.

#1-15. 악성코드의 감염 경로는?

인터넷 브라우저를 통하여 감염 되었다고는 추정하고 있으나 명확한 증거는 찾지 못하였다.

#2. 오픈소스 혹은 상업적 이용에 제한이 없는 포렌식 도구 아무거나 하나 잡고 조사해오기.

옛날부터 여러 부분에서 유용하게 사용하는 FTK Imager를 조사하였다.

AccessData사에서 제공을 해주며 설치 등은 무료이므로 생략.

전체 기능은 매우 방대하기 때문에 물리 이미지, 덤프 사용등에 관련한 내용을 소개하도록 한다.

< FTK Imager 메인 >

간단하다. 왼쪽에 Evidence Tree는 윈도우 탐색기처럼 디렉토리들을 트리 형식으로 나타내준다. 우상단은 윈도우 탐색기의 상세부분과 비슷하다. 좌하단은 직접 물리 디스크에서 원하는 데이터만을 뽑아서 새로운 증거물로 목록을 만들 수 있다.

위에 메뉴아이콘 5가지를 빨간 박스로 체크했는데 왼쪽부터 차례대로 다음과 같다.

1. 1개의 물리 디스크 가져오기

2. 모든 물리 디스크 가져오기

3. 이미지 덤프 마운팅

4. 1개의 Evidence 제거

5. 모든 Evidence 제거

Encase와 같이 포렌식을 중점으로 만든 프로그램이므로 Evidence라는 단어가 들어가 있다.

위 화면은 2번 메뉴를 통해 현재 연결된 모든 물리 디스크를 증거물로 올려 놓은 화면이다.

PHSICALDRIVE0,1은 디스크 자체를 증거물로 올려놓은 것이고 아래 C,D,E,F는 디스크 0,1을 논리적으로 나뉜 파티션단위로 읽어오는 것이다. 데이터 복구나 파일 추출에서는 논리적으로 읽어오는 것이 일반적이다.

< Add Evidence 메뉴 >

1번의 아이콘을 클릭하거나 File - Add Evidence Item 메뉴를 사용하면 위처럼 나오게 된다. 물리 드라이브, 논리 드라이브, 이미지, 폴더 등으로 나뉘어서 증거물로 올려놓고 확인할 수 있다.

< 실제 사용 화면 >

USB 디스크를 읽었으며 /새 폴더 를 읽어들인 화면이다. [root]폴더가 해당 디스크의 최상위경로이다.

좌상단을 보면 경로들이 트리 구조로 나온 것을 확인할 수 있다.

우상단을 보면 현재 선택한 '새 폴더' 하위의 목록을 확인할 수 있다.

그 중에 'Downloads - 복사본.zip', 'DumpIt - 복사본.exe'에는 아이콘에 X표시가 되어있다. 이는 파일이 삭제 되었다는 의미이다.

FTK Imager는 윈도우에서 파일을 제거 하였더라도 이처럼 디스크에는 남아있으므로 복구가 가능하다.

원하는 파일을 오른쪽 클릭하면 위처럼 나오게 되는데 'Export Files...' 항목을 선택하면 현재 디스크에 파일을 추출할 수 있다.

'Downloads - 복사본.zip'은 일반적은 Delete를 이용하여 휴지통으로 간 경우.

'DumpIt - 복사본.exe'는 휴지통으로 가지 않는 Shift + Delete를 이용한 경우이지만 상관없이 복구 가능하다.

좌하단을 보면 두개의 항목이 새로 생겼는데 이는 직접 우상단에서 원하는 데이터만을 'Add to Custom Content Image' 항목을 이용하여 새로운 증거물로 만들기 위해 선택한 것이다.

실제로 usb에 포렌식 툴이기 때문에 usb로 담아다니며 사용이 가능하며 덤프가 필요한 PC의 필요 데이터만을 수집할 수 있다.

통상적으로 mft, logfile 등을 수집하는데 실제 악성코드라고 판단이 되는 경우, 이 프로그램을 이용하여 숨김처리 되거나 일반 삭제된 파일을 복구하여 수집할 수 있어 파일 포렌식 관점에서 상당히 유용하지 않나 싶다.

ref 

http://www.codeengn.com/archive/Forensic/Volatility%20command%202.1%20%5B%EB%B3%B4%EC%95%88%ED%94%84%EB%A1%9C%EC%A0%9D%ED%8A%B8,%20%EC%9D%B4%EC%8A%B9%EC%A4%80%5D.pdf

http://www.codeengn.com/archive/Forensic/Volatility%20Plugin%20%EC%9D%84%20%EC%9D%B4%EC%9A%A9%ED%95%9C%20Windows%20Memory%20Dump%20%EB%B6%84%EC%84%9D%20%5BDeok9%5D.pdf

http://apollo89.com/wordpress/?p=6989

http://ucs.dongguk.edu/jiwon_choi/Memory%20Forensic%20Analysis.pdf