2. MBR

 하드디스크를 용도에 따라 여러 개의 파티션으로 나눌 수가 있다. 예를 들어 이전 (1)에 했던 포스팅에서 필자의 PC는 4개의 파티션으로 나뉘어져 있는 것을 확인할 수가 있었다. 하지만 스왑을 위한 파티션이나 윈도우 시스템 예약을 제외하면 칼리 리눅스와 윈도우가 있는 파티션 2개가 존재한다고 볼 수 있다. 이러한 각 파티션은 하나의 물리 디스크로부터 관리가 필요한데, 이러한 파티션을 MBR 구조로 관리한다.

 MBR은 저장 매체(물리 디스크)의 첫 번째 섹터에 위치하며 512Byte의 크기를 갖는다. 이는 446Byte의 Boot Code와 Partition Table 64 Byte, 그리고 Signature 2 Byte로 총 512Byte(0x200)의 크기를 갖는다. 여기서 64 Byte에서 하나의 파티션 마다 16 Byte로 정보를 나타내기 떄문에 총 4 개의 파티션으로 구성된다. 4개 이상의 파티션은 EBR로 관리한다.

 대략적인 컴퓨터의 부팅과정이다. 여기서 우리는 BIOS 이후 디스크의 MBR을 확인하고 부팅 가능한 파티션을 찾은 다음에 부팅을 하기 위해 VBR로 넘어가는 것을 알 수 있다. 이를 위하여 MBR의 구조에 대하여 더 상세히 알아보자. 자세하게는 아래와 같이 나타낼 수가 있다. 하지만 대부분의 문서해서는 코드 영역을 0x1BE까지로 보고 있으며 그 뒤로 파티션 테이블이 64 Bytes 마지막 Signature (0xAA55) 2Bytes로 형성되어 있다고 볼 수 있다.

 코드 영역은 흔히 Boot Code라 하며 파티션 테이블에서 부팅 가능한 파티션을 찾아 해당 파티션의 부트섹터(NTFS-VBR)를 호출하는 역할을 한다. 이제 파티션 테이블은 위에서 간략히 설명했지만 다시 설명하자면 총 64 Bytes로 16 Bytes씩 4개로 나뉘어 진다. 아래의 그림을 보자.

 그림과 같이 총 16 Bytes임을 볼 수가 있다. 각 항목에 대하여 설명을 하면 다음과 같다.

- Boot Flag : 부팅이 가능한 파티션인지 나타내는 값으로 0x80은 부팅이 가능, 0x00은 불가능을 의미한다.

- Starting CHS Address : CHS 시작 주소 위치를 나타낸다.

- Partition Type : 파티션의 종류에 따라 서로 다른 값을 같는다. ( [0x07 : exFAT, Unix, NTFS], [0x81 : Linux], [0x86 : FAT16])

- Ending CHS Address : CHS 마지막 주소 위치를 나타낸다.

- Starting LBA Address : LBA 시작 주소 위치를 나타낸다. 즉 해당 파티션이 시작되는 섹터의 위치를 나타내는 것이다.

- Size in Sector(Total Sector) : 파티션의 크기로 섹터 개수를 의미한다.

* CHS는 오래 전 주소를 나타내는 방식으로 점차 용량이 커짐에 따라 한계가 있기에 LBA(Local Block Area)로 방식을 대체하고 있는 추세이다.

 위 그림은 내 PC의 파티션 테이블을 나타내는 것이다. 총 4개의 색상으로 각 파티션을 표시하였다. 우선 부팅이 되는 부분은 Boot Flag가 0x80으로 설정되어 있는 부분으로 바로 세번째 파티션이다. 3번 째 파티션에서 Starting LBA Address를 따라 해당 섹터로 이동하면 해당 파티션이 존재한다. 따라서 세번째 파티션이 C:\여야 정상인 것이다. 하지만 해당 섹터로 가니 시스템 예약 파티션이 존재하고 있었다.

 아래의 그림은 현재 내 PC의 파티션 상태를 보여준다. 여기서 무엇인가 이상한 점이 보인다. 위의 그림에서 부팅이 가능한 것은 3번째 파티션이지만 아래의 그림과 같이 이 부분은 시스템 예약 파티션이라는 것을 알 수가 있다. 또한 실제 C:\는 00으로 설정되어있는 4번째 파티션의 주소에 위치하는 것을 확인할 수가 있었다. 왜 그런걸까? 찾아보아도 답이 나오지 않았다. 

 예상 되는 이야기는 2가지이다. 현재 나의 컴퓨터가 이상하거나 아니면 이것이 정상이라는 것. 시스템 예약 파티션은 윈도우 7부터 생성되는 영역으로 주로 비트락커 암호화를 위한 공간으로 사용된다고 한다. 그렇다면 당연히 암호화가 중요한 것이므로 저 부분을 지난 다음에 원래의 C:\를 지나는 것도 이야기가 된다. 아, 물론 지극히 개인적인 생각이니 흘려보내는 것이 지식에 좋을 것 같다. 

 다시 본론으로 돌아와 LBA를 통해 해당 오프셋으로 이동해보자. 우선 LBA addr이 0x79C1000 이므로 1섹터는 512(0x200) Bytes이므로 이 값을 곱해준다. 그렇게 나온 값은 0xF38200000으로 해당 주소로 이동해보자.

좌측의 C:\와 우측의 0xF38200000에 위치한 하드 디스크1이 모두 같은 내용임을 알 수가 있다. 이렇게 해당 파티션을 찾아갈 수가 있다.

EBR

 위에서 파티션이 4개보다 많을 경우에는 EBR을 통해서 관리한다고 말하였다. 이러한 EBR에 대해서도 알아보자. 사실 보통 사람들은 파티션을 1~4개 정도로 갖는 것이 평범하다. 하지만 5개 이상 가지고 있는 경우 헤매는 일이 발생하면 안되므로 이에 대해 학습해보자. 이 부분은 cappleblog.co.kr/590 를 중점적으로 참고하였다.

 이 분의 PC에서는 MBR을 통해 볼 수 있듯이 3개의 엔트리가 기록되어있는 것을 확인할 수가 있다. 첫 번째와 두 번째 엔트리의 경우 일반적인 NTFS의 파티션으로 위에서 내가 하였던 것과 같은 방법으로 접근하면 된다. 여기서 이 PC의 경우 파티션이 5개로 3번째 엔트리에 EBR의 위치가 나타나있는 것이다. EBR의 LBA 시작 주소가 0x8C00800 LBA 이므로 이는 오프셋 0x1180100000이 된다.

 위의 그림과 같이 해당 EBR로 이동하였다. 2개의 엔트리가 보이는 것을 확인할 수가 있는데 하나는 바로 Current Entry 정보로 바로 해당하는 EBR과 연결된 논리 드라이브에 대한 정보를 나타내며 다른 하나는 Next Entry 정보로 다음 EBR의 위치를 나타내는 것이다.

 즉, 해당 PC에선 5개의 파티션이 위치하므로 MBR에서 보았던 2개를 제외한 3개가 EBR에 존재하고 있다. 그러므로 이러한 EBR은 각 각 다음 EBR의 위치를 가리키고 있으므로 총 3개의 EBR이 존재하며, 마지막 EBR은 Next Entry에 정보가 비어있다. 만약 새로운 파티션이 추가되면 해당 부분의 EBR을 새로 가리키게 된다. EBR의 정보를 해석할 때 알아야 할 2가지 중요한 내용이 있다. 

 EBR에서 Current 엔트리는 현재 위치한 EBR을 기준으로 하면 된다. 그렇게 따라간 LBA엔 찾고자 했던 파티션의 시작 부분을 볼 수가 있다. Next 엔트리는 MBR을 통해 따라가 나온 첫 번째 EBR을 기준(위에선 0x1180100000)으로 다음 EBR이 있는 LBA가 나온다.

출처 및 참고

http://humanistcpu.blogspot.kr/2013/10/hxd-mbrmaster-boot-record.html    ; HxD MBR 구조 분석

http://cappleblog.co.kr/40      ; MBR 구조

http://cappleblog.co.kr/590    ; MBR 해석

http://forensic-proof.com/archives/2975    ; 시스템 예약 파티션 관련 내용

1. 개요

 파일 시스템이란 디지털 데이터를 효과적으로 관리하기 위해 파일을 체계적으로 기록하는 방식으로, 사용자에게 계층 구조로 데이터를 저장하도록 하는 방식을 말한다. 파일이 어디에 저장되어 있는지 조직화하고, 사용자의 데이터를 구조적으로 정의하도록 한다. 이는 파일을 빠르게 읽기, 쓰기, 삭제 등 기본적인 기능을 원활히 수행하도록 도와주며 사용자 영역이 아닌 커널 영역에서 동작한다.

 이론적인 내용을 먼저 설명하기 전에 직접 어떻게 생겼는지 확인해보자. 여기선 HxD를 통해 확인해볼 것이며, 관리자 권한을 통해 실행을 해야 디스크를 읽을 수가 있으므로 관리자 권한으로 HxD를 실행해보자.

 위의 그림과 같이 나타나는 것을 볼 수가 있다. 여기서 필자는 컴맹이므로 하나 하나가 모두 새로웠기에 다들 아는 이더라도 공부하면서 새로 알게 된 점까지 모두 설명할 것이다. 우선 위의 디스크 열기를 통해 확인하면 '논리 디스크'와 '물리 디스크'가 있는 것을 확인할 수가 있다. 무슨 차이인지 모른다. 내 컴퓨터에는 리눅스가 존재하긴 하지만 윈도우는 C:만 있을 뿐인데 저 물리 디스크도 C:\겠구나라고 생각했었다. 일단 둘다 열어보자.

 좌측은 위에서 '논리 디스크'라 되어 있던 '제목 없음(C:\)'를 나타내며 우측은 '물리 디스크'라 되어 있던 '하드 디스크 1'이다. 어떤 차이가 있는지를 확인해보자. 좌측은 흔히 윈도우에서 사용되는 NTFS라고 친절히 나와 있다. 우측은 왜 내가 알아 먹을 수 있는 문자열이 없는 것일까. 맨 끝으로 가서 확인해보자.

 좌측은 2C662FEFF0 까지 있지만 우측의 물리 디스크는 3B9E655FF0 까지 있는 것을 확인할 수가 있다. 즉 우측이 더 큰 용량을 가지고 있는 것이다. 이를 10진수로 변환하여 GB의 형태로 나타내면 좌측은 약 177GB, 우측은 약 238GB이다. 본인의 노트북은 256GB SSD를 사용하고 있다는 점과 약 60GB정도는 듀얼 부팅을 위한 리눅스에 사용되고 있는 용량이므로 이를 차감하면 딱 윈도우에 할당된 177GB가 나온다.

 따라서 논리 디스크라 함은 정말 C:\와 같은 부분을 나타내며, 물리 디스크는 정말 하드디스크를 통째로 나타내는 것이다. 그러므로 물리 디스크가 논리 디스크를 포함하고 있다고 볼 수가 있다. 이는 WinHex를 통해서도 확인이 가능했다.

 물리 디스크를 인식 했을 경우 HxD보다 더 상세하게 출력해주는 것을 확인할 수가 있다. 위의 그림을 보면 Start sectors부터 리눅스가 포함된 총 4개의 파티션을 볼 수가 있다. WInHex를 통해 추가로 알게 된 사실은 하나의 섹터(Sector)는 512Byte(0x200)라는 것을 알 수가 있었다.

* 참고로 클러스터란 섹터를 여러 개 모아 만든 논리적인 저장 단위로, 윈도우는 파일을 저장할 때 이 클러스터 단위로 파일을 저장한다. 그렇기에 슬랙이 형성된다. 다시 말해, 디스크의 최소 저장 단위인 섹터와 운영체제의 최소 저장 단위인 클러스터의 차이로 인해 드라이브 슬랙이 발생한다.

 위의 그림은 forensic-proof.com에서 캡쳐한 것으로 이에 따르면 대부분의 NTFS에서는 4KB = 4096 Byte가 하나의 클러스터 크기이다. 위에서 한 섹터에 512Byte인 것을 확인했으므로 이를 통해 나누면 8이므로, 하나의 클러스터에 8개의 섹터가 위치하고 있는 것을 알 수가 있다.

출처 및 참고

http://forensic-proof.com/archives/357

1. 요약

분석 대상은 tigger.exe가 실행 된 후의 메모리이며 환경은WinXP SP2 x86이다. 전체적인 분석 내용은 이후에 좀더 상세히 다루며, 본인이 여기선 조사했던 내용을 간략히 요약하고자 한다.

• Tigger.exe.pf, 329000.exe.pf, tmryqyrznr2.sys라는 의심스러운 MFT 흔적 발견
• Svchost.exe(pid=936)이 tmryqyrznr2.sys라는 문자열을 포함
• Svchost.exe(pid=936)과 관련된 파일에서 방화벽, 후킹에 대한 문자열과 함수 존재
• 329000.exe는 특정 파일, 드라이버, 지속성 위한 레지스트리 관련 함수와 문자열 존재
• 329000.exe는 Virustotal에서도 여러 엔진에서 악성코드가 판정

이와 같이 요약을 할 수가 있으며 이러한 내용에 대해 상세히 설명할 것이다. 순서는 위의 요약과는 다소 다를 수 있다.

2. 분석

분석 대상 환경은 WinXP SP2 x86이다. 분석 시작과 함께 Userassist를 통해 어떠한 프로그램이 실행되었는지 확인을 하여 대상을 좁혀보자. 결과는 아래의 그림과 같으며 tigger.exe가 2010년 8월 15일 19:25:52에 실행된 것을 확인할 수 있다.

Figure 1. Rekall - UserAssist

Pstree를 통해 메모리에서 실행 중이던 프로세스의 목록을 트리 형태로 확인해보자. 위에서 확인했던 tigger.exe가 보이지 않는 것을 확인할 수가 있다. 대신 비슷한 시간대에 실행된 wmiprvse.exe(pid=828)을 확인할 수가 있다. 그 부모프로세스와 그 상위 까지를 대상으로 진행하겠다.

* 추가 : svchost.exe (936)은 추후에 분석을 통해 의심되는 부분이라 생각되어 추가

Figure 2. Rekall - pstree

실행 중인 프로세스 외에 Volatility의 MFTparser Plugin을 통해 MFT 변화 또한 확인해보자. 아래의 그림은 시간대로 정렬하여 나타낸 결과이다.

Figure 3. MFT parser

Tigger.exe가 실행되고 10초 후 pf 파일이 생성되었으며 15초후 329000.exe와 329000.exe.pf가 생성되는 것을 확인할 수가 있다. 17초 후에는 Perfilb_Perfdata_33c.dat파일, 19초 후는 Netsh.exe의 pf파일이 마지막으로 tigger.exe를 실행하고 20초 후에는 tmryqyrznr2.sys가 MFT로 존재하는 것을 확인할 수가 있다.

Figure 4. MFT parser

Tigger.exe와 329000.exe, Netsh.exe는 위의 pstree에서 보았듯이 메모리에 같은 이름의 프로세스로 존재하지 않는 것을 확인할 수가 있다. sys파일의 경우 이름에서 나타나는 불규칙성에서 의심의 여지가 있다. 하지만 관련이 없을 수도 있으므로 추후에 확인을 해보자.

Figure 5. Rekall – unloaded_modules & modscan

우선 tmryqyrznr2.sys를 확인하기 위하여 메모리에 있는 모듈의 리스트를 modscan Plugin을 통해 확인을 하였지만 존재하지 않았다. 따라서 루트킷과 같은 악성코드의 경우 악성 행위를 하고 바로 언로드 시키는 경우도 있기에 언로드된 모듈을 unloaded_modules를 통해 확인했지만 보이지 않았다.

Figure 6. Volatility – yarascan

Volatility의 yarascan Plugin을 통해 해당 문자열(tmryqyrznr2)을 검색해보았다. 그 결과 pid 936인 svchost.exe에서 확인할 수가 있었다. 해당 프로세스를 추출하여 악의적인 행동을 하는지 확인해보자.

Figure 7. Rekall – procdump

Procdump를 통해 해당 프로세스를 추출하였다. 이제 이를 통해 VirusTotal의 백신 엔진들을 통해 악성코드로 의심되는 행위가 있는지를 확인해보자.

Figure 8. Virustotal – svchost.exe(936)

Virustotal을 통한 결과는 위의 그림과 같다. 56개의 엔진 중에서 한 곳에서만 악의적인 행위로 검출이 되었다. 별로 의심의 여지가 없어 보이지만 좀 더 살펴보고자 dumpfiles를 통해 pid 936에 해당하는 파일들을 추출해보았다.

Figure 9. Volatility – dumpfiles

여러 개의 파일이 추출된 것을 확인할 수가 있다. 이 파일들 중 .dat 파일을 위주로 살펴보았는데 의심스러운 문자열이 나타난 부분들을 뽑아 아래와 같이 정리하였다.

0x80fcb6c.dat의문자열은 Hookimports라는 문자열을 통해 후킹과 관련된 문자열들이 여러 부분 존재하는 것을 확인할 수가 있고 0xff3696b0.dat를 통해 Firewall과 관련된 문자열을 확인할 수가 있었다.

Figure 11. Rekall – filescan

이번에는 MFT를 통해 확인 했듯이 PF파일이 생성되었던 329000.exe를 분석해보자. 우선 filescan Plugin을 통해 해당 파일이 메모리에서 추출할 수 있는지를 확인해보았다. 그 결과 위와 같이 Offset이 나오는 걸 볼 수 있다.

Figure 12. Volatility – dumpfiles

Filescan을 통해 얻은 Physical Offset을 지정해주고 dumpfiles Plugin을 통해 추출해보자. 그 결과 2개의 파일이 추출에 성공하는 것을 확인할 수가 있다. 추출된 2개의 파일에 대한 정보는 아래의 표에 정리한 바와 같다.

32900.exe와 관련된 파일에 대해 추출을 성공하였으므로 이제 악의적인 행위를 하는지 확인을 해보자. 여기선 위에서와 같이 Virustotal을 통해 그 결과를 먼저 확인해보자.

Figure 14. Virustotal – 329000.exe

위의 결과와 같이 많은 부분에서 악성코드라 진단되는 것을 볼 수 있다. 어떠한 기능의 파일인지 확인하기 위해 간단하게 문자열과 포함하는 API에 대하여 확인해보자. 확인 결과 문자열과 API 모두 같은 것으로 나타났다.

위의 표를 보면 우선 API에서 파일을 찾기와 관련된 함수들과 읽고 쓰고 이동하는 것까지 확인할 수가 있다. 문자열을 보면 흥미로운 점이 있는데, 지속성을 유지하기 위한 레지스트리 키와 회사 이름이나 저작권에 있어 "Microsoft Corporation"이라는 것을 볼 수가 있다. 이는 윈도우의 일반적인 파일처럼 보이고자 Microsoft의 이름을 사용했다고 볼 수가 있다.

Figure 16. Rekall - filescan

이번에는 filescan을 통해 tmryqyrznr2.sys에 대해 Offset을 알아보자. 그 결과는 위와 같으며 이제 이 주소를 통해 해당 모듈을 추출하여 추가적인 분석을 진행해보자.

Figure 17. Volatility – dumpfiles

여기선 dumpfiles Plugin을 통해 추출을 시도하였다. 그 결과 화면은 위의 그림과 같지만 해당 파일이 생성되지 않는 현상이 나타났으며 그 이유 또한 알 수가 없었다. 따라서 추출이 불가능하므로 메모리에서 해당 파일의 흔적을 찾아보자.

Figure 18. Rekall – driverirp

위에 32900.exe 문자열에서 드라이버와 관련된 문자열이 존재하기도 하므로 driverscan을 통해 확인을 해보자. 그 결과 tmryqyrznr2.sys가 보이는 것을 확인할 수가 있다. 좀 더 상세히 확인하기 위하여 driverirp를 통해 확인한 결과는 아래와 같다.

Figure 19. Volatility – driverirp

출력된 결과를 보면 모든 부분이 0x00000000로 되어 있는 것을 확인할 수가 있다. 이는 해당 모듈이 메모리에 남아있지 않기에 사라진 것으로 보인다.

  3. 결론

위의 분석 작업을 통한 결과를 전체적으로 종합해보자. 우선 tigger.exe를 실행하고 MFT를 통해 근처 시간대를 확인한 결과 tigger.exe외에 329000.exe와 tmryqyrznr2.sys도 조사범위에 넣었고 분석 결과 329000.exe는 virustotal에서 본 것과 같이 악성코드라 판단할 수가 있다.

329000.exe는 어떠한 파일과 관련된 동작, 드라이버와 지속성을 위한 레지스트리 등과 관련된 함수와 문자열들을 포함하고 있다. tmryqyrznr2.sys는 메모리에 더 이상 존재하지 않기 때문에 추가적인 분석을 진행할 수가 없었다.

하지만 tmryqyrznr2이란 문자열을 yarascan을 통해 확인한 결과 svchost.exe(pid=936)에 해당 문자열이 존재함을 알 수가 있었고, 이를 토대로 해당 svchost.exe와 관련된 파일들을 dumpfiles를 통해 추출하였다. 그리고 몇 개의 파일에서 hookimports와 같은 후킹과 관련된 직접적인 문자열을 확인할 수가 있었다. 또한 Firewall과 관련된 문자열이나 함수 등을 통해 해당 프로세스가 방화벽과의 연관성을 가지는 것도 알 수가 있었다.

1. 개요

BlackEnergy는 러시아 해커에 의해 제작된 인기 있는 DdoS 공격을 위한 트로이 목마로 2008년 러시아 그루지아 사이버 공격에서 사용된 것으로 보고되어 악명을 얻었다.

얼마 후 BlackEnergy2가 개발 되었으며, 코드를 재작성하여 기존의 것과는 다르게 루트킷, 프로세스 인젝션, 강한 암호화와 모듈 구조를 가지고 있다. 주로 산업 공정, 기반 시설, 설비 등의 산업 제어 시스템을 대상으로 공격하고 있으며, 현재 원격 코드 실행, 네트워크 탐색, 데이터 수집 등의 기능을 수행하는 다양한 변종이 발생하고 있다.

  2. 분석

해당 이미지를 통해 어떠한 의심스러운 프로세스가 있는지를 확인해보자. 우선 pslist는 EPROCESS 구조 에 있는 ActiveProcessLinks를 통하여 어떠한 프로세스가 동작 중인지를 보여준다. 이에 따른 결과는 아래의 그림과 같다.

Figure 1 Rekall – pslist

크게 3가지의 프로세스에 대하여 붉은 선으로 표시하였다. 각 항목을 표시한 이유는 다음과 같다.

• 1e0f—(476) : 프로세스의 이름, 생성시간에서 의심스럽다 할 수 있음
• Cmd.exe(1572) : pid-476의 하위 프로세스라는 점에서 의심
• Explorer.exe(1724) : Explorer.exe의 부모 프로세스인 PID-1708이 존재하지 않음

이제 이를 기준으로 다른 부분을 확인해가며 점차 확인해야 할 범위를 줄여나가보자.

Figure 2 Rekall - Userassist

Userassist는 사용자가 어떠한 프로그램을 실행시켰는지를 확인할 수가 있으며, 위의 결과를 확인해보면 2010-08-15 19:21:25에 1e0f--.exe를 실행하였다는 것을 확인할 수가 있다. 이와 관련된 아티팩트로 MFT 또한 확인해보자.

Figure 3 Volatility - mftparser

여러 MFT 중에서 시간을 기준으로 의심스러운 3가지 항목이 나열되어있다. 우선 lkndcaccmjqb.sys, str.sys, 그리고 1e0f1b--.exe의 prefetch파일을 발견할 수가 있다. Prefetch파일은 해당 프로그램이 실행되었다는 것을 알려주는 것이며, 그 외에 두 개의 sys가 추가로 의심된다고 볼 수 있다.

Figure 4 Rekall – modscan

하지만 위의 모듈들을 확인하기 위하여 modscan을 통해 확인해본 결과 보이지가 않았다. 일단 이에 대해서는 아직 확인할 방법이 없으므로 다른 쪽에 기준을 맞추어 분석을 다시 진행해보자.

Figure 5 Rekall – Procdump

현재 프로세스 목록 중 가장 의심스러웠던 1e0f—에 대하여 분석을 해보기 위하여 추출하고자 하였다. 이에 쓰인 플러그인은 Rekall의 procdump로 해당하는 pid를 지정해주면 손쉽게 해당 프로세스를 추출할 수가 있다.

Figure 6 HxD – 1e0f1b--.exe

HxD로 열어서 확인을 해본 결과 해당 프로세스는 이미 종료되었기 때문에 해당하는 핸들 등이 메모리에서 해제된 상태이다. 따라서 모든 부분이 NULL로 채워져 있는 것을 확인할 수가 있다. 따라서 다른 부분에 초점을 맞추어야 할 것 같다.

Figure 7 Volatility – callbacks

Callback Plugin을 통해 확인한 결과는 위의 그림과 같다. 여기서 module 항목에 다른 것들과는 다르게 존재하는 항목을 볼 수가 있다. 바로 00004A2A이다. 결과를 보면 CreateThread에 4A2A모듈이 동작하고 있는 것을 통해, 스레드의 생성과 관련이 있음을 알 수가 있다.

Figure 8 Volatility – SSDT

추가로 SSDT (System Service Descriptor Table)는 커널 모드 함수에 대한 포인터를 포함하고 있다. 그러므로 악성코드는 이러한 SSDT 후킹을 할 수가 있으므로 확인해주어야 한다. 확인 결과는 위의 그림과 같으며 모듈 00004A2A가 많은 부분에서 SSDT에 적용되어 있는 것을 확인할 수가 있다.

Figure 9 Rekall – modscan

4A2A 모듈을 추출하기 위하여 해당하는 주소를 찾아보자. Modscan 플러그인을 통하여 4A2A의 베이스 주소를 확인할 수가 있다. 확인 결과 베이스 주소는 0xff0d1000이다. 이 주소를 가지고 모듈을 추출해보자.

Figure 10 Volatility – moddump

Moddump 플러그인을 통하여 위에서 확인했던 베이스 주소를 기반으로 모듈을 추출할 수가 있다. 위의 결과와 같이 성공했다는 문구를 확인할 수가 있지만, 어떠한 이유에서인지는 모르겠지만 추출된 해당파일이 나타나지 않았다. 따라서 추가적인 확인을 할 수가 없었다.

위에서 확인했던 바와 같이 4A2A 모듈은 스레드가 시작되거나 종료될 때 트리거 되는 것을 확인할 수가 있었다. 또한 SSDT가 후킹되었다는 것을 확인할 수 있으므로 threads에서 확인해보자. 결과는 아래의 그림과 같다.

Figure 11 Volatility – threads – HookedSSDT

그림에서와 같이 생성된 스레드들이 4A2A와 관련이 있음을 알 수가 있으며 각 스레드의 서비스 테이블이 4A2A모듈을 가리키고 있다. 그림 8에서 보았던 API 함수들과 같은 함수임을 알 수가 있다.

Figure 12 Rekall – Malfind

Malfind 플러그인을 통해 코드 인젝션이 되었는지를 확인할 수가 있다. 여기서는 독특하게 svchost.exe에 실행파일의 MZ헤더가 존재하는 것을 확인할 수가 있다. 따라서 이를 추출하여 확인하도록 해보자.

Figure 13 Volatility – dlldump

Dlldump를 통해 pid와 base address를 입력해주고 dump-dir을 통해 저장할 경로를 지정해주면 된다. 결과는 성공적으로 추출이 완료되었으며 이에 대해 분석해보자.

Figure 14 module.c30000.dll – string

문자열 추출 결과는 다음과 같다. 여기서 몇 가지 살펴보아야 할 것에 표시를 하였는데 우선 cmd.exe를 이용한다는 것과 그림 3(MFT parser)에서와 같이 str.sys가 존재하는 것을 확인할 수가 있다. 아래 바이러스 토탈의 결과를 보자.

Figure 15 Virustotal – module.c30000.dll

추출한 모듈을 바이러스 토탈에 확인해 본 결과 악성코드임에 많은 의심을 받는다. 존재하는 함수 중 DownloadFile부터 시작해 많은 부분 악의적인 기능을 하기에 충분한 요소가 있다.

Figure 16 svchost.exe(856) – handles

어떠한 핸들을 가지고 있는지 확인하기 위하여 handles 플러그인을 통해 File과 Mutant를 출력하였다. 우선 File에서 str.sys과 각 index.dat에 대한 핸들을 가지는 것을 확인할 수가 있다. 또한 Mutant를 통해 Encrypt 등을 확인할 수가 있다. 개인정보를 원격으로 추출할 수 있으므로 추가로 확인해보자.

Figure 17 Rekall – threads

Svchost.exe(856)의 Threads를 확인해보자. Rpcrt4와 관련하여 스레드가 존재하는 것을 확인할 수가 있다. RPC(Remote Procedure Call)는 별도의 원격 제어를 위한 코딩 없이 다른 주소 공간에서 함수나 프로시저를 실행할 수 있게 하는 프로세스 간 통신 기술이다. 다시 말해, 원격 프로시저 호출을 이용하면 프로그래머는 함수가 실행 프로그램에 로컬 위치에 있든 원격 위치에 있든 동일한 코드를 이용할 수 있다.

Index.dat는 IE 등을 통해 핸들에 들어가는 것이 정상이며 해당 프로세스가 이를 핸들로 가지고 있다는 점과, RPC가 있다는 점에서 충분히 악의적인 행위를 할 수가 있음을 의심할 수가 있다.

+ 수정 : index.dat과 rpc 관련 스레드를 가지는 svchost.exe가 악의적이다고만은 할 수가 없다. 정상적인 svchost.exe가 가질 수도 있음

Figure 18 Volatility – driverirp

Driverirp 플러그인은 IRP Table을 보기 위해 사용하는 명령어이며, 모듈을 이용한 Hooking된 IRP 함수 탐지하지만 항상 옳은 방법은 아니기에 –verbose 를 통해 구체적으로 확인을 해보자. 결과는 아래의 그림과 같다.

Figure 19 Volatility – driverirp –v

PUSH 명령어를 통해 인자를 주고 CALL 명령어를 통해 어떠한 기능의 주소를 호출하는 것을 확인할 수가 있다. 해당 인자 값은 0xffffffff이며 호출하는 함수의 명령어는 아래와 같다.

Figure 20 Volatility – Volshell

Volshell을 통해 디스어셈블 한 결과이다. 함수의 호출과 함께 어떠한 값을 스택에 Push하는 것을 확인할 수가 있고, 그 값은 0x46C825FF(우측)이다.

구체적으로 어떠한 기능을 하는지는 확인하지 못하였지만 icqogwp드라이버와 관련하여 해당 악성코드가 어떠한 기능을 하고 있다는 것을 알 수가 있다.

  3. 요약

지금까지 BlackEnergy2를 메모리 분석을 통해 분석해보았다. 전체적으로 확실한 기능에 대해서는 발견하지 못했지만 해당 메모리 덤프를 통해 알게 된 정보에 대하여 요약하고자 한다.

• 2010-08-15 19:21:25에 1e0fb1--.exe를 실행
• CallBack(스레드 관련)과 SSDT(그림8참고)에 대하여 4A2A 모듈이 후킹
• 악의적인 dll의 컨테이너 역할로 svchost.exe(856)이 동작
• 해당 DLL은 DownloadFile이나 cmd와 관련된 문자열이 존재
• Svchost.exe(856)이index.dat이나 RPC에 대하여 핸들과 스레드를 가짐
• 4A2A모듈이 icqogwp드라이버와 관련하여 어떠한 동작을 함

비록 실행했던 프로그램 1e0--.exe는 메모리에서 내려갔지만, 메모리에 남아 있는 다른 흔적들을 통하여 해당 악성코드의 기능에 대하여 유추할 수 있었다. 그림14와 같이 어떠한 API가 사용되었는지, 핸들이나 뮤턴트, 스레드, 드라이버 등을 살펴보므로 이에 대하여 확인할 수가 있었다.만약 본래의 프로세스가 메모리에 남아있었다면 추출하여 더욱 상세히 분석을 할 수 있었을 것이다.

참고

https://ko.wikipedia.org/wiki/원격_프로시저_호출

http://blog.naver.com/chogar/220226730293

1. 개요

 Coreflood는 미국에서 발생한 해킹사건에 쓰인 악성코드로 키보드의 동작을 기록하여 PC 사용자의 웹사이트 로그인이나 ID, 암호, 개인의 금융정보까지 빼낼 수 있는 프로그램이다.

 러시아 해커 그룹에 의해 만들어졌으며 2010년에 출시된 트로이 목마 및 Botnet으로 많은 금융기관과 대학, 그리고 병원과 정부 등도 감염되는 등의 막대한 피해를 입힌 악성코드이다.

 해당 문서에서는 Rekall과 Volatility를 통하여 Coreflood에 감염된 PC의 메모리를 통해 분석을 진행할 것이며 분석 대상 환경은 Windows XP SP2 x86이다.

2.분석

 해당 메모리를 Rekall을 통해 이미지를 열고 어떤 프로세스가 동작 중인지를 확인하며 이를 통해 이름이나 생성 및 종료 시간이 수상한 프로세스가 있는지를 확인해볼 것이다. 여기에는 은닉된 프로세스가 있을 수 있으므로 pslist가 아닌 psscan을 사용하였다.

그림 1. Rekall – psscan

 그림 1과 같이 몇 개의 의심되는 프로세스를 표시해보았다. 우선 실행된 시간이 2010-08-15인 프로세스에 초점을 맞추어 위 2개의 프로세스가 해당이 되며 cmd.exe의 경우 Vmware에 의한 것으로 해당 분석과는 상관이 없는 내용이므로 포함하지 않았다.

 현재 어떤 프로세스가 동작 중이었는지에 대해 확인을 했으므로 이제 사용자가 어떠한 프로그램을 실행시킨 것인지 확인을 해야 한다. 이에 대해서는 사용자가 응용프로그램을 실행시켰을 경우 레지스트리에 기록되는 UserAssist에 대하여 아래의 그림을 통해 확인을 해보자.

그림 2. Rekall – userassist

 Userassist엔 2010-08-15 18:10:58에 flashload.exe를 실행했다는 것을 확인할 수가 있으며, 그 다음엔 iexplore.exe가 실행되었다는 것을 확인할 수가 있다. 그림 1과 같이 실행 중인 프로세스에선 해당 이름을 확인할 수가 없으므로 해당 프로그램에 대하여 찾아보자.

그림 3. Volatility – MFTparser – logon.scr.pf

 이전에 의심스러웠던 logon.scr이 flashload.exe가 실행된 후 10분 가량 후에 실행되었다는 것을 확인할 수가 있다. 따라서 해당 프로세스가 아직 악의적인 프로세스인지 아닌지에 대하여 단정 짓기는 힘들다. 그렇다면 다른 방법으로 접근해보자..

그림 4. Rekall – messagehooks

 Messagehooks Plugin은 모든 데스크탑을 검색하여 글로벌 후킹을 열거한다. 결과를 보면 IEXPLORE.EXE가 4개의 전역 후킹 결과를 나타내는 것을 보이며 키보드와 마우스 모두 후킹되고 있는 것을 확인할 수가 있다.

그림 5 Volatility - ssdt

 SSDT는 System Service Descriptor Table로 커널 모드 함수에 대한 포인터를 포함한다. 그러므로 악성코드는 이러한 SSDT 후킹이 의심되므로 확인을 해주어야 하며 위 결과와 같이 0x805aa8b4는 사실 ntoskrnl.exe에 소유되지만 주소의 명령은 0x806d56c0(hal.dll)으로 나타내는 것을 확인할 수 있다.

그림 6. Volatility - callbacks

 SSDT에 이어 Callback을 확인해보면 이전에 보았던 hal.dll이 존재하는 것을 확인할 수가 있다. 해당 dll은 버그 체크를 할 때 Callback되는 것을 확인할 수가 있다.

그림 7.Rekall - modscan

 해당 모듈을 찾기 위하여 modscan을 사용하였다. 결과는 위의 그림과 같으며 해당 주소에 MZ시그니처를 확인 후 덤프로 추출해낼 것이다.

그림 8. Volatility – volshell    

 Volshell의 db를 통해 해당 주소의 MZ 시그니처가 있는지 확인을 해본 결과 위의 그림과 같이 올바른 위치에 MZ 가 위치해 있는 것을 확인할 수가 있다. 따라서 아래와 같이 해당 모듈을 추출해 보자.

그림 9. Volatility – moddump

 추출한 hal.dll의 악성코드 여부를 판단하기 위하여 Virustotal을 이용하였다. 결과는 아래와 같으며 55개의 엔진에서 악성코드라 판단되는 것이 0이라는 것을 알 수가 있다. 따라서 추출한 hal.dll을 악성코드라 보기가 힘들다.

그림 10. VirusTotal – Extracted hal.dll

 이에 추가로 확인하기 위하여 같은 운영체제(Windows XP x86)에서의 정상적인 hal.dll과 문자열을 통해 비교해보았다. BinText를 통해 각 문자열을 추출하였으며 추출한 문자열들을 WinMerge를 통하여 비교하였다. 결과는 아래의 그림과 같다.

그림 11. WinMerge – Compare String

 위에 나타난 부분만이 메모리에서 추출한 hal.dll에 추가로 있는 부분이다. 그 외에 원본에는 있지만 추출한 dll에는 존재하지 않는 부분은 메모리에서 추출했다는 점을 감안하여 나타내지 않았다. 추출한 파일에 추가로 붙는 정보가 적으므로 악성코드라 판단하기 힘들다는 것을 알 수 있었다.

그림 12. Volatility – malfind

 해당 플러그인은 Code Injection을 검출해주는 기능을 한다. 위의 그림과 같이 의심되는 IEXPLORE.EXE에서도 해당 되는 지점이 나타났지만 값이 0으로 채워져 있는 것을 확인할 수가 있다. 이는 해당 지점을 읽을 수 없으므로 읽을 수 있는 지점이 나올 때까지 이동하며 보아야 한다.

그림 13. Volatility – volshell

 해당 주소 0x7ff80000에서부터 100씩 읽으며 읽혀지는 곳이 나올 때까지 확인해보았다. 그 결과 0x7ff81000에서 데이터를 읽을 수 있다는 것을 확인하였다. 이제 이 지점을 디스어셈블하여 출력해보자.

그림 14. Volatility – volshell

 해당 지점을 확인해보니 쉘코드가 존재하는 것을 확인할 수가 있다. 페이지의 권한이 실행, 읽기, 쓰기라는 점과 함께 malfind플러그인을 통해 확인할 수가 있다. 이번엔 api후킹의 여부를 확인해보자.

그림 15. Volatility – apihooks

 Apihooks 플러그인을 통해 확인을 해본 결과 IEXPLORE.EXE에 여러 개가 검출 되었다. 후킹된 대부분의 함수들 모두 0x7ff81960을 호출하는 부분으로 이어지는 것을 확인할 수가 있었다. 그림 4에서의 주소(0x7ff81b40)와 유사함을 알 수가 있고, 이에 대하여 volshell을 통해 확인해보자.

그림 16. Volatility – volshell

 디스어셈블을 통해 확인한 결과는 위의 그림과 같다. 이러한 dll을 덤프로 추출하고자 할 때 dlldump는 메모리에서의 변화를 포함하고 있으며 dumpfiles는 디스크 상에서의 코드와 일치한다. 그러므로 두 방법을 통해 추출하고 바이너리를 비교해보자.

그림 17. Volatility – dlldump

 Dlldump를 통해 추출하는 방법은 위의 그림과 같다. 추출에 성공하였고 해당 이름이 module.2044.485d1a8.771b0000인 것을 확인할 수가 있다.

그림 18. Volatility – dumpfiles

 Dumpfiles를 통해 추출한 결과는 위의 그림과 같다. 추출한 파일 이름은 file.2044.0x80f04f30으로 나타난다. 이제 이 두 개의 파일을 비교하여보자.

그림 19. Compare Bytes

 위의 두 그림에서와 같이 좌측은 Dlldump, 우측은 Dumpfiles를 통해 추출한 파일이다. 즉 좌측은 메모리에서의 코드 변경이 반영되었고, 우측은 반영되지 않았다는 것이며 그림에서와 같이 디스크 상에서의 파일에는 존재하지 않는 코드가 존재한다. 이외에도 몇 가지 더 있지만 생략하겠다.

그림 20. Volatility – envars

 환경변수를 확인해보면 부모 프로세스가 자식 프로세스에게 해당 환경 변수를 상속하는 것이 일반적이다. 붉게 표시한 부분을 보면 부모에게는 없지만 자식(iexplore.exe)에는 존재하는 것을 확인할 수가 있다. 정상적인 프로세스에는 없다는 것을 생각했을 때 해당 환경변수 또한 악성코드에 의해 남은 흔적임을 의심해볼 수 있다.

  3.정리

 2장의 분석 과정을 통하여 CoreFlood가 실행된 메모리를 분석해보았다. 대체로 더 상세한 분석을 하기에는 필자의 실력이 아직 미흡하기에 버겁다. 지금까지 분석한 내용을 정리하면 아래와 같다.

• Flashload.exe가 2010-08-15 18:11:13를 실행
• IEXPLORE.EXE가 키보드와 마우스의 전역 후킹을 함
• API후킹과 Code Injection으로 보이는 흔적 발견
• 전체적으로 악의적인 코드는 0x7FF81000 이후에 분포
• 환경변수에 흔적이 남는 것으로 예상

참고자료

The Art of Memory Forensics (Detecting Malware and Threats in Windows, Linux, and MAC Memory)

Ligh, Michael Hale, Case, Andrew, Levy, Jamie 외 1명 저  JohnWiley&SonsInc  2014.07.14.

https://en.wikipedia.org/wiki/Coreflood

https://code.google.com/p/volatility/

http://www.rekall-forensic.com/

1. 분석 결과 요약

1.1 의뢰 내용 요약

의뢰 내용은 의뢰자(피해자)가 사건 현장에서 잠시 자리를 비우고, 복귀 후 해당 PC에 이상 프로세스(Economices)가 동작 중임을 의뢰자가 인지하였으며 이에 따라 해당 프로세스가 어디서 유입이 되었는지, 어떠한 기능을 하며, 추가적인 2차 피해가 발생할 수 있을 경우 대응 방안에 대하여 조사를 의뢰하였습니다. 자세한 내용은 아래와 같이 2개로 나뉩니다.

- 실행된 프로세스(Economices.exe)의 악성코드 여부

- 2차 피해 발생 가능성 여부와 대응 방안

1.2 해당 PC 악성코드 감염 사항

의뢰자의 PC에 대하여 해당 악성코드와 관련하여 분석 결과를 시간 순으로 나타내면 아래와 같습니다.

그림 1. 악성코드 행위 타임라인

• 피의자는 피해자가 자리를 비운 사이 2015-11-12 19:39:30에 피해자의 PC에 자신의 USB로 연결을 하였습니다.

• 연결 후 'eco'라는 폴더를 생성하였으며, 해당 디렉터리에 Economices.exe를 저장하고 실행하였으며, 이는 피해자의 키 이벤트 내용을 피의자의 PC로 전송하는 개인정보 침해를 유발하는 프로그램입니다..

• 실행 후 피의자는 피해자의 PC 레지스트리에 등록을 하여 지속적으로 피해자의 정보를 얻으려 하였다는 것을 알 수 있습니다.

• 이후 피의자는 2015-11-12 19:41:57에 USB 연결을 해제하였습니다.

  2.증거 수집 및 분석 도구

증거 수집과 분석에 사용된 도구들의 이름과 버전, 그리고 각각 사용된 용도에 따라 정리를 한 페이지입니다.

2.1증거 수집 도구

증거 수집에 사용된 도구들에 대하여 정리하였으며 이러한 도구에 대한 내용은 아래의 [표–1]와 같습니다.

표 1. 증거 수집 도구

2.2 분석 도구

분석 단계에서 사용한 도구는 아래 [표-2]와 같습니다. 

표 2. 증거 분석 도구

 분석 단계에 있어서 Volatility와 Rekall을 통하여 수집한 메모리를 분석하려 했으나, 수집 단계나 이송에 문제가 있었는지 해당 YURI-PC-20151112-110112.raw 정상적으로 인식되지 않아 수집한 메모리를 통한 분석은 하지 못하였습니다.

  3. 증거 수집

본 증거물은 의뢰자 PC로부터 2015-11-12 19:44:12부터 조사자의 USB를 연결하여 수집을 시작하였으며, 해당 의뢰자의 동참 하에 진행되었습니다. 그리고 각 분석의 진행을 시간 순으로 정렬한 내용은 아래와 같습니다.

그림 2. 증거 수집과 이송 절차 

 증거물 수집 과정에 있어 고려해야 할 사항은 다음과 같습니다.

• 의뢰자의 인터뷰
  • 전체적인 이미징은 거부함에 따라 선별적인 증거 수집
  • 압수 수색이 아니기에 의뢰자가 동의한 사항에서만 증거 수집
• 증거 수집에 있어 의뢰자가 동참하였으며 해당 의뢰자의 요청으로 인하여 지정된 수준까지만 수집이 가능

• 의뢰자는 증거 수집이 끝난 후 본인의 작업(LoL)을 해야 함에 따른 시간 상의 제약이 존재

* 증거 수집에 있어 해당 PC의 메모리 수집이 올바르게 되지 않았기에 해당 프로그램에 대하여 추가적인 분석을 위하여 의뢰자에게 해당 PC의 Economices.exe를 전송해줄 것을 요청하였고 15-11-13 03:41:50 해당 파일을 수신하였습니다.

3.1 증거물 대상과 수집 PC 환경

 수집 대상에 대하여 충분한 설명을 의뢰자에게 하였으며 이에 따른 동의가 있고 증거 수집을 하였기에 선별적인 증거 수집이 이루어졌으며, 의뢰자가 수집에 동의한 사항은 아래의 표와 같습니다.

표 3. 증거 수집 대상

 분석 대상 컴퓨터 환경에 대한 기본 정보는 아래의 표와 같습니다. 

표 4. 증거 수집 대상 PC 환경

3.2 증거 메모리 수집 : 2015-11-12 19:45:27

메모리 수집에 있어 DumpIt을 통하여 디스크의 변질을 최소화 하기 위하여 조사자의 외부 USB로 메모리 수집을 진행하였으며 YURI-PC-20151112-110112.raw로 저장이 되었습니다. 

3.3 증거 레지스트리 수집 : 2015-11-12 20:12:03

 REGA를 통한 레지스트리 수집을 하였으며 수집된 레지스트리 파일은 아래의 [표-5]와 같으며, 이렇게 수집된 레지스트리에 대한 해시와 시간은 [별첨-1]을 통하여 확인할 수 있습니다. 

표 5. 수집된 레지스트리 관련 자료

3.4 증거 PC의 $MFT 수집 : 2015-11-12 20:18:34

 FTK Imager와 WinHex를 통하여 $MFT와 $LogFile, $J 파일을 수집하였으며, 이 파일에 대한 해시 값은 아래와 같습니다. 

표 6. MFT파일 크기와 해시 값

3.5 의뢰자에게 별도로 받은 의심 파일 : 2015-11-13 03:41:50

 해당 의심 파일이 의뢰자에 PC에 남아있음을 인지하였으며 이에 대해 의뢰자에게 송신해줄 것을 요청하였으며, 이러한 요청에 의해 2015-11-13 03:41:50에 해당 파일을 송신하였습니다. 파일에 대한 내용은 아래의 표와 같습니다.

표 7. Economices.exe의 크기와 해시 값

 해시 값을 통하여 전송한 파일과 수신한 파일 간에 무결성이 유지되었음을 확인할 수가 있었습니다.

4. 상세 분석 내용

 상세 분석 내용을 제공하는 페이지 입니다. 의뢰자의 PC에서 수집한 증거를 분석실로 이송 후 조사자의 분석 환경에 해당 증거들을 옮긴 후 분석을 진행하였습니다.

4.1MFT 분석을 통한 시간대 확인

 의심되는 프로세스(Economices.exe)에 대한 타임스탬프를 확인할 것이며. 사건 현장은 상대적으로 의뢰자의 지인이 많이 찾아오는 장소로 동 시간대에 의뢰자가 잠시 자리를 부재한 사이(19:35:00-19:43:00)에 발생한 것임을 고려하여야 합니다.

 이를 토대로 근처 시간대를 확인할 것이며 해당 시간대에 의심되는 파일이 생성되거나 실행되었는지를 확인하기 위하여 MFT를 분석해 보았습니다.

그림 3. MFT 분석

 위의 그림과 같이 해당 프로그램은 "\Documents\카카오톡 받은 파일"에' eco폴더를 생성 후(19:40:12) 해당 경로에 저장(19:40:14)이 되었다는 것을 확인할 수가 있습니다. 이에 대한 csv파일은 [별첨-3]과 [별첨-4]에서 확인할 수 있습니다.

 이를 통해 의뢰자가 자리를 비우고 약 5분이 지난 후 제 3자에 의해 해당 파일이 생성되었음을 알 수가 있습니다.

4.2 해당 프로그램 침입 경로 확인

 위의 MFT 분석을 통해 시간대를 축소할 수가 있었으며, 이러한 시간에 이루어진 레지스트리 변경사항에 대하여 분석해보았습니다.

그림 4. USB 연결 흔적 확인

 그림-4과 같이 해당 시간(19:39:30)에 USB와 연결한 흔적들을 확인할 수가 있었으며 이를 통해 해당 프로그램이 USB를 통하여 복사되었음을 예상할 수가 있습니다. 하지만 여기서 최초 장비 연결 시 더 많은 레지스트리의 값이 변화하는데 몇 개의 값만이 변화되었기에 해당 USB는 이번이 최초 연결이 아님을 알 수가 있습니다.

 이는 그림-5를 보면 알 수 있듯이 해당 필드의 한 칸 상위인 VID_058F&PID_6366의 값은 마지막으로 쓰여진 값이 2015-10-04 03:11:47인 것을 통해 해당 일자에 최초로 PC에 연결이 되었으며 이번이 최초연결이 아님을 알 수가 있습니다.

그림 5. VID_058F&PID_6366 LastWriteTime

 이를 통해 해당 프로그램 Economices.exe를 설치한 피의자는 의뢰자의 지인임을 예상할 수가 있었으며, 여기에 사용된 USB의 정보는 아래의 표와 같습니다. 

표 8. 악성코드 유입에 사용된 USB의 정보

 해당 USB에 대한 사용 흔적은 수집한 대상 PC의 DriverFrameworks-UserMode 이벤트 로그에도 기록되었는데, 이에 대해 표-8을 보면 19:39:32에 연결하였다는 항목을 보아 위 그림-4과 그림-5에서의 내용에 신빙성을 더해주며, 해당 USB의 연결 해제가 19:41:57에 이루어졌다는 것 또한 확인을 할 수가 있습니다. 자세한 사항은 [별첨-5]를 통해 확인할 수 있습니다.

표 9. 증거 대상

4.3 기타 침해 입증 자료

 아래의 그림과 같이 해당 파일의 경로와 해당 Economices.exe가 레지스트리에 추가된 것(19:41:33)을 확인할 수가 있으며 이는 USB를 연결 해제(19:41:57)하기 전에 등록된 것임을 알 수가 있으며, 값이 추가되었다는 것은 컴퓨터를 종료 후 다시 실행할 때마다 해당 프로그램이 자동 실행되는 것을 의미하며 이는 악성코드가 지속성을 유지하고자 할 때 주로 쓰는 방법입니다.

그림 6. 지속성 유지를 위한 레지스트리 추가

 그림-7과 같이 해당 프로그램은 19:40:47에 실행이 된 것임을 확인할 수가 있습니다.

그림 7. Economices.exe 실행 시간

 대상 PC의 증거를 수집하며 네트워크 연결 상태도 확인을 해보았으며 이에 대한 사진은 [별첨-6]을 통해 볼 수 있고, 이를 토대로 중요한 사항인 3226(Economices.exe)은 현재 같은 IP 영역대인 192.168.0.5와 네트워킹을 하고 있었음을 알 수가 있습니다. 

표 10. Netstat을 통해 본 연결 상태

 이를 통하여 해당 프로그램은 같은 IP에 있는 의뢰자의 친구 김00씨의 PC가 연결된 주소로, 2대의 PC가 네트워킹을 하고 있음을 알 수가 있으며 이러한 악성코드의 기능은 아래에서 설명하겠습니다.

4.4 해당 프로세스의 악성코드 여부 확인

 Economices.exe에 대한 상세한 분석을 진행하는 페이지입니다. 해당 파일에 대한 PE구조를 분석하고 그에 맞게 분석을 진행하였습니다.

그림 8. PEiD의 출력 결과

 위의 그림과 같이 PEiD를 통하여 보았을 때는 별로 알 수 있는 유용한 내용이 없었으며 추가적으로 PE 구조를 더 살펴본 결과 .rsrc 섹션에 아래의 그림과 같이 PYTHON27.DLL이라는 문자열과 exe의 MZ 헤더와 PE 시그니처 등이 존재하는 것을 확인할 수가 있으며, 이러한 구조는 주로 Python으로 된 코드를 py2exe를 통하여 컴파일 했을 경우 주로 나타나는 구조임을 알 수가 있습니다.

그림 9. 해당 파일의 리소스 섹션

 이를 통하여 Py2exe된 파일을 다시 코드로 볼 수 있도록 제작하는 작업이 필요하며 사용된 도구는 [표-2]에 기재된 바와 같이 2개의 Python Code를 통하여 진행하였습니다. 해당 과정은 아래와 같습니다.

그림 10. Python Code 복구 과정

 이러한 과정을 통하여 복구된 파이썬 코드는 [별첨-7]와 같으며 이를 통해 파이썬의 기능에 대하여 알아보았습니다. 주요 기능은 아래와 같습니다.

• Pyhook을 통해 키로깅의 기능을 구현하였습니다.

• 의뢰인의 지인이였던 김00군 PC의 IP 주소인 192.168.0.5가 나타나있습니다.

 위 두가지 사실을 종합해보았을 때 해당 프로그램은 키로깅의 기능이 있으며 하나의 클라이언트로 동작하는 것을 확인할 수가 있었습니다. 이를 통해 의뢰인(192.168.0.3)은 김00군(192.168.0.5)에 키 이벤트를 전송하므로 개인 정보 유출의 위험이 많다는 것을 알 수가 있습니다.

그림 11. 메모리 분석을 통한 키로깅 확인

  5. 대응 방안

 위의 분석을 토대로 2차 피해 발생에 대응하기 위한 방안은 다음과 같습니다.

• 실행 중인 악성코드의 경우 해당 프로세스를 종료하여 추가적인 피해를 방지해야 합니다.

• 현재 피해자의 PC에 악성코드가 지속성을 유지하고 있기 때문에 해당 레지스트리의 값을 제거하여 2차적인 피해를 방지합니다.

• 피의자가 피해자의 관계 상 해당 프로세스를 다시 설치할 수가 있기에 피해자의 PC에 접근을 하지 못하게 하는 등 제약이 필요합니다.

- https://code.google.com/p/volatility/source/browse/branches/scudette/docs/blogg_posts/scudette/kdbg.txt?r=2805

- SANS Poster 2015-Memory-Forensic2.pdf

- http://www.rekall-forensic.com/posts/2014-02-21-do-we-need-kdbg.html

0. Before

 이 문서를 번역하는데 있어 해당 문서가 2006년임을 감안하여야 한다. 이 때에 비하여 현재 9년이나 흐른 시점이므로 당시보다 메모리 포렌식이 더 발전하였기에 너무 아래의 글을 읽는데 있어 이를 감안하여야 한다.

0. Abstract

 휘발성 메모리에 대한 조사는 상대적으로 새로운 분야이지만 그만큼 포렌신 분야에 있어서 중요한데 이는 이제 범죄자들 또한 포렌식에 대하여 인지를 많이 하는 추세이며 대상 컴퓨터의 하드 디스크에 대한 접근 없이 범죄를 저지를 수 있기 때문이다. 이는 전통적인 "Pulling the plug" 침해 대응 연습이 범죄의 유일한 증거를 파괴할 수 있다는 것이다. 

 메인 메모리의 콘텐츠를 수집하는 몇개의 방법들이 존재하는 반면에 의미 있는 방식으로 이러한 데이터를 해석할 수 있는 것은 몇 존재하지 않는다. 이러한 요인의 이유 중 하나는 바로 현대 운영체제의 가상 메모리 시스템의 복잡한 추상화이다. 이는 겉보기에는 하나의 프로세스에 속하는 데이터가 하드디스크나, 물리메모리의 전체 범위를 가로질러 임의의 방법으로 분산되어 질 수 있다는 것이다.

 이 문서에서는 필요한 데이터를 담고 있는 커널 구조와 어떻게 물리메모리와 가상메모리 공간이 메모리가 맵핑되고 변환되는지를 포함하는 가상 메모리 시스템, 그리고 메모리를 수집하거나 분석할 수 있는 툴들에 대하여 초점을 맞추고 있다. 

1. Introduction 

Motivation and Intent

 시디롬이나 하드디스크와 같은 비휘발성 저장장치의 데이터를 수집하거나 조사하는 방법에 대해서는 문서화가 잘 되어 있는 반면에 메인 메모리와 같은 휘발성 저장장치에 대한 가이드 라인은 여전히 부족하다. 몇 가이드 라인은 휘발성 메모리 수집을 완전히 무시하며 대신에 하드 디스크의 데이터 손실을 방지하기 위해 즉시 장치의 전원을 종료할 것을 제안하였다. 다른 몇 가지 가이드 라인의 경우에는 휘발성의 순서에 메모리에서부터 마지막엔 비휘발성 데이터 등을 따라서 데이터를 수집해야한다고 제안한다.

 하지만 이러한 가이드라인은 어떻게 이러한 수집이 진행되어야 하는지를 자세하게 보여주지는 못한다. 게다가, 메모리 이미지가 취득된 이후 현재 어떻게 이러한 이미지가 분석되어야 하는지에 대한 규범적인 가이드라인이 존재하지 않는다. 많은 조사자들은 텍스트 검색을 하거나 이미지와 같은 파일을 찾기 위해 카빙을 한다. 하지만 이러한 조사들이 텍스트에서 몇가지 흥미로운 것들을 생성할 수가 있지만, 이것들은 복구된 데이터가 저장된 컨텍스트를 보여주지는 않는다. 예를 들어 문자열 검색은 불법적인 인터넷 사이트에 대한 레퍼런스를 밝혀주지만 사용자의 브라우저 히스토리 전체를 나타내주지는 못한다. 

 비록 본격적인 메모리 분석 시스템이 사용되고는 있지만 현재 프로세스의 가상 주소 공간을 다양한 방법으로 매꿀 수 있는 도구들이 현재 나타나지 않았다. 그러므로 이 문서의 초점은 어떤 데이터가 저장되어 있는지, 어디에서 복구를 할 수 있는지에 대하여 조사하는 것이며 가상 메모리 시스템을 상세히 조사할 것이다.

Overview

 이번 장에서는 이 문서의 연구 단계에서 사용되었던 툴과 방법에 대하여 설명할 것이며 2 장에서는 윈도우 메모리의 몇가지 구조와 유용한 정보를 찾기 위해 어떻게 분석되어야 하는지를 설명할 것이며 3장에서는 윈도우 메모리 이미지로부터 정보를 어떻게 복구하는지를 보여주며 윈도우 가상 메모리 시스템에 대하여 설명할 것이다. 이는 가상주소와 물리주소, 페이징 시스템의 조사를 포함하며 어떻게 가상주소 공간을 조종하는지에 대해서도 설명한다. 4장에서는 메모리 수집을 위하여 사용되는 도구들의 측면에서 메모리 수집 프로세스에 대해 언급할 것이며 이미징 간에 발생할 수 있는 이슈와 문제에 대해, 그리고 가능한 솔루션과 대체 방법에 대하여 이야기 할 것이다. 5장에서는 현재 수집 간에 있어 생성되는 분석을 위한 방법을 설명할 것이다. 6장에서는 페이지 파일이나 메모리 이미지에서 주어지는 프로세스의 가상 주소 공간을 재구성하는 'vtop' 증거 개념 툴에 대하여 소개할 것이다. 여기에는 어떻게 툴이 동작하며 어떻게 더 나은 동작을 하는지에 대한 제안을 할 것이다. 마지막으로 7장에서는 이 문서의 연구결과에 대한 요약과 메모리 포렌식 분야의 더 나은 작업을 위한 추천을 할 것이다.

Methods And Tools

 이 프로젝트를 위해 요구되는 연구의 핵심은 RAM이나 메모리 이미지에 있는 구조에 대해 상세한 집합이다. 이는 [13]으로부터 얻어진 시스템의 아키텍처의 지식과 'Debugging Tools for Windows'[41]을 통해 크래시 덤프의 디버깅, [55]'WinHex'와 디버거를 통해 오프셋과 주소를 수동으로 찾는 방법들을 조합하여 이루어진다.

 아키텍처에 대한 충분한 지식을 갖고 있다면 메모리에서 구조에 대한 타입과 오프셋을 찾을 수가 있을 것이다. 이를 위해 메모리 이미지는 'dd'를 사용해 가졌으며 4장에서 소개할 방법인 'CrashOnCtrlScroll' 방법 사용한 크래시 덤프를 통한 테스트 시스템을 구성하여 사용할 것이다. 이러한 사항들은 'dd'에 의해 생성된 메모리 덤프가 불일치를 최소하기 위한 크래시 덤프와 유사함을 보장한다. 이 크래시 덤프 파일은 이를 분석할 수 있는 WinDBG[41]을 통해 열 수가 있다. 마이크로소프트로부터 심볼들을 다운받으므로 커널 구조는 'dt _eprocess'가 구조의 시작에 대한 데이터 필드의 주소를 포함하고 있는 _EPROCESS구조를 보여주는 것과 같이 'dt' 명령어를 사용하여 조사할 수가 있다. 이러한 하나의 구조의 시작 주소를 제공하므로 모든 연결된 다른 구조들은 그들의 오프셋의 주소를 읽으므로 찾을 수가 있고, 그들의 타입 또한 'dt' 명령어를 통해 찾을 수가 있다. 

 새로운 정보가 디버거로부터 얻어질 때마다 이러한 정보들은 WinHex를 통하여 메모리 덤프의 정보를 수동으로 복구하여 확인할 수가 있다. 구조에 있는 오프셋은 구조의 물리 주소를 이동시키고 오프셋을 더한 주소의 값을 읽으므로 확인할 수가 있다. 이 시점에서 이는 x86아키텍처는 데이터를 리틀 엔디언으로 저장하며 이러한 데이터의 값은 역순으로 읽어야 한다.

 'vtop' 증거개념의 발전을 위해 코드 부분을 실행하고 모듈 전체를 리로딩 없이 테스트 할 수 있는 IDLE 파이썬 개발 환경을 사용한다. 

 두 가지 프로세스 뷰어의 영향을 테스트할때 'Process Viewer'[24]와 Process Explorer[48]을 사용할 것이다. 프로세스 익스플로어는 좀 더 디테일한 정보를 주지만 빠른 업데이트와 함께 실행중인 프로세스에서만 가능하다.

2. Windows Structures

 윈도우즈 하에서 실행되는 각 프로그램들은 메모리에서 프로그램의 상태를 구체화 하는 프로세스로 할당이 된다. 프로세스가 실행되려면 프로그램이 실행된 이후 변경된 모든 데이터가 유지 되어야 하며 그것이 유지되는 프로세스의 구조안에 이러한 데이터가 있다. 현재 실행 중인 프로세스들의 목록은 Windows Task Manager를 통해 확인하거나 Sysinternals's의 Process Explorer와 같은 서드 파티 툴을 통해 확인을 할 수가 있다. 비록 이와 같은 도구들이 램의 내용을 변경할 수 있기 때문에 포렌식 환경에서는 프로세스를 확인하기에 좋은 방법이 아님에도 불구하고, 프로세스나 컴퓨터의 상태에 대해 RAM 으로부터 무엇이 밝혀 질수 있는지에 좋은 아이디어를 줄 수가 있다. 

 윈도우즈는 _EPROCESS 커널 구조에 각 프로세스에 대한 정보를 저장하며 이러한 대부분의 정보는 수집될 수가 있다. 모든 프로세스의 _EPROCESS 구조는 시스템 프로세스의 주소 공간에 저장되어 있으며 그렇기에 이러한 구조를 찾는 것은 메모리 분석에서의 첫 단계이다. 이는 이름, 타입, 각 구조의 오프셋등을 보여주기에, _EPROCESS 블럭의 베이스 주소는 알려져 있으며 이러한 값은 오프셋과 가산 값을 확인함으로써 판독할 수가 있다. 

 4GB 가상 주소 공간에서 첫번째 2GB의 가상 주소 공간은 프로세스가 쓰기 위하여 이용될 수 있으며 나머지 두번째 2GB(변경이 가능)는 시스템 메모리의 공유에 사용된다. 이는 0x00000000부터 0x80000000(0-2GB)까지 범위의 가상 주소를 찾는 것으로 쓰기 가능한 모든 메모리의 덤프를 구성할 수가 있다.

 불행하게도 시스템 _EPROCESS의 가상 주소를 찾는 것은 매번 윈도우즈가 이를 로드하는게 다르기 때문에 어려운 작업이라 할 수 있다. mem_parser와 KnTList 툴들은 EPROCESS 구조 패턴과 특정 문자열을 찾으므로 이를 성공적으로 이를 했었다. XP에서 프로세스의 PDB는 항상 0x39000에 이으며 DirectoryTableBase 필드는 이 값으로부터 +0x018에 위치하고 있다. 또한 'ImageFileName'필드는 16바이트로 +0x174~0x183에 '시스템' 값을 갖고 있다.  그러므로 EPROCESS는 00039000 인스턴스를 찾으므로 밝힐 수가 있으며, 'System '(53 79 73 74 65 6D 00)으로부터 0x15C만큼 떨어져 있다. 이는 하나 이상의 결과를 만드는 것이 매우 어렵다. 또한 볼 수 있는 EPROCESS들은 아래에서 설명할 ActiveProcessLinks 필드를 통하여 확인할 수가 있다.

Process List

 _EPROCESS에 대해 알아야할 첫번 쨰 사항은 시스템에서 실행 중인 다른 프로세스들 각각에 대응하는 _EPROCESS 블럭의 위치이다. 모든 프로세스들은 doubly-linked-list의 형태로 연결되어 있으며 그래서 'ActiveProcessLinks' 필드는 이전_EPROCESS(at +0x08C)와 다음 _EPROCESS(at +0x088)의 가상주소를 포함하고 있다. 'DirectoryTbleBase'를 제외한 모든 주소들은 변환이 필요한 가상 주소로써 주어진다(이에 대해서는 3장에서 다룰 것이다.). 실행 중인 프로세스를 찾는 이 방법을 사용할 경우 한 가지 단점은 악성코드가 자신을 다른 _EPROCESS들로부터  'Unlink'시킬 수 있다는 것이다. 이렇게 언링크된 프로세스는 분석가들이나 프로세스 뷰어에 보이지 않게 된다. 이를 위해, 악성 프로세스의 _EPROCESS 블록에서 앞뒤로 링크를 변경시키므로 가운데에 있던 자신은 잊혀지도록 한다. 이를 그림으로 보면 아래와 같다.

 이러한 기법은 Direct Kernel Object Manipulation(DKOM)의 한 형태이며 이는 데이터를 숨기는 1차적인 방법중에 하나 이다. 이러한 문제를 해결 하기 위한 두 가지 방법이 존재한다. 첫 째로 RAM 이미지에서 _EPROCESS 블럭의 특성을 찾는 것인데, 비록 나은 기법들이 사용되면 오탐을 줄일 수 있기는 하지만 이는 어림짐작에 의존하기도 하며 오탐지될 확률이 높다. 두 번째 방법은 스레드가 실행 중일 경우 이는 'Dispatcher Ready Queue'라 불리는 큐에 담기므로,모든 스레드의 리스트를 얻기 위해 Windows thread queuing system를 분석하는 것이다. 스레드는 자신의 더 많은 정보를 찾을 수 있는 곳에 대한 자신 프로세스의 PEB 포인터를 포함하는 '_ETHREAD' 커널 오브젝트에 의해 나타난다. 불행중 다행스럽게도, 리버스 엔지니어링 없이 할 수 있도록 스레드 스케줄러에 대한 미약한 내용이나마 문서가 공개되어 있다.

Basic Process Details

 실행 중인 모든 프로세스와 프로세스 블럭이 발견되면, 각 기본 정보들을 알아낼 수가 있다. 아래의 테이블은 유용한 엔트리를 몇 가지 보여준다. 여기서 세번째 항목까지는 _EPROCESS의 첫번째 필드인 PCB(_KPROCESS)의 항목과 같으므로 결국 EPROCESS에서도 바로 찾을 수가 있는 것이나 다름 없다.

Table 1: Usefil filelds in the _EPROCESS structure

* 페이지 디렉터리 베이스는 프로세스에 대해 가상 주소를 물리주소로 변환되어 사용되는 페이지 디렉터리의 물리 주소이며 이에 대해서는 3장에서 논한다.

( * 역 : 이러한 구조는 윈도우 버전에 따라 상이하기에 각 버전에 맞는 것을 찾아보아야 한다. )

Process Environment Block( PEB )

 PEB는 프로세스 주소 공간에 위치하고 있는 프로세스 디스크립터의 일부이다. Windows XP 32비트 운영체제부터, 각 프로세스는 자신들만 사용할 수 있는 주소 공간을 갖는 것을 의미하는 32비트 가상 주소를 갖는다. PEB는 프로세스 주소 공간에 있는 많은 구조들의 주소를 포함하기 때문에 이는 매우 효율적이라 할 수 있다. PEB에 접근하는 기 위해서는 _EPROCESS블럭의 PDB와 _EPROCESS에 저장 되어 있는 PEB의 주소를 사용하여 가상 주소를 물리 주소로 변환하는 과정이 꼭 필요하다. 이러한 가상 주소를 물리주소로 변환하는 것은 3장에서 언급이 된다.

 프로그램이 실행될 때, 실행파일의 사본이 메모리의 자신의 엔트리에 로드되며 이 주소는 PEB로부터 +0x008에 저장이 된다. 이 필드는 메모리 덤프로부터 카빙 될 수 있으며 실행 된 파일로 저장이 되고, 알려진 original과 함께 분석이나 비교할 수 있다.

 추가로 또한 PEB는 프로세스가 사용 중인 모듈(DLL files), 파일이 가지고 있는 오픈 핸들, 프로세스 힙의 가상 주소, 공유 메모리와 코드 영역을 포함한다. 이러한 PEB의 필드들과 오프셋은 아래와 같이 정리할 수가 있다.

Table 2: Useful fields in the _PEB structure

Interpretation

 명백하게도 데이터는 의미 있는 방식으로 해석될 때에만 유용하다. 프로세스 리스트를 시작으로, 프로그램은 메모리 이미지가 만들어진 시점에 실행이 되었는지를 보여줄 수 있는데 이는 메모리 이미지를 수집하는 방법에 따라 의존적임을 유념해야 한다.

 기본 속성 중 프로세스의 이름은 그 이름이 수상해보일 경우에는 더욱, 어떤 프로스세스를 나타내는지를 알려주기 때문에 유용하다. 하지만 이름이 신뢰할 수 있는 프로세스처럼 보일지 언정, 위에서 언급된 DKOM(Direct Kernel Object Manipulation)과 유사한 방법을 사용하여 진짜 존재를 변조할 수가 있다. 만약 프로세스가 신뢰할 수 있고 같은 이름(e.g cssrs.exe)으로 로드되거나 앞뒤의 'real' cssrs.exe의 링크가 숨겨지도록 수정되면, 'fake' cssrs.exe는 정교한 프로세스 리스팅을 사용하지 않는 한 유일한 엔트리로 나타날 것이다. 해당 프로세스가 시작되기 전에 침해 사건이 발생한 경우 'KernelTime'과 'UserTime'은 얼마나 오랫동안 프로세스가 시작되어있는지를 확인할 수가 있다.

 또 PID와 PPID는 의심 되는 프로세스를 볼 수 있게 도와주는데 예로 explorer.exe의 자식 프로세스는 유저에 의해 키보드나 시작시 실행될 때 지역적으로 실행된다. 반대로 프로세스의 네트워크 서비스 PPID는 원격적으로 실행 될 수 있다. '_EPROCESS' 의 ObjectTable' 필드는 파일 및 레지스트리 키와 같은 열린 핸들을 가진 프로세스의 오브젝트를 나타내는 구조를 포함하고 있지만 이에 대해 조사를 하기에는 문서가 충분하지 않다. 마찬가지로 '_PEB'안 'Ldr'필드는 프로그램을 지원하기 위해 로드된 DLL 필드의 자세한 '_PEB_LDR_DATA'구조 주소를 포함하고 있다. 일부 경우에 이러한 것들은 증거 적인 가치가 있지만 이를 추가로 분석할 만한 증거가 불충분하다. 아마 이번 장에서 가장 가치있는 값은 바로 'DirectoryTableBase'인데 이는 가상 주소를 물리 주소로 변환하는데에 사용 될 수 있으며 이에 대해서는 3장에서 이야기 할 것이다.

 PEB가 발견될 경우 이미지 파일이나 프로세스 힙과 같이 더 많은 분석을 할 수가 있다. 이미지 파일은 지정된 가상 주소의 콘텐츠를 읽으므로 메모리 덤프에서 카빙할 수가 있다. 이러한 파일의 길이는 아래의 테이블과 같이 EXE 헤더를 통해 추출해 낼 수가 있다.

Table 3: Offsets into the image file showing file size

 파일이 추출되면 이는 생성된 해시를 통해 나타난 잘 알려진 것들과 비교 될 수 있다. 만약 이러한 것이 나타나지 않는다면 이는 테스트를 위해 디스어셈블하거나 그렇지 않으면  그것의 기능을 밝히도록 분석될 수가 있다.

 PEB를 통한 이용 가능한 또 다른 증거는 프로세스 힙으로 이는 새로운 변수가 초기화 될때 프로세스에게 할당 되는 메모리 세그먼트로부터의 섹션이다. 그러므로 프로그램에 의해 저장된 어느 데이터도 이 공간에서 사용될 수가 있다. 하지만 각각의 응용프로그램은 그 데이터가 쓰여질 때 사용된 프로그래밍 언어나 코드를 컴파일할때 사용한 컴파일러, 컴파일에 쓰인 대상 플랫폼이나 디자인 된 프로그램에 따라 다르게 구성이 된다. 특정한 프로세스의 메모리를 분석하는 것은 이에 대한 자세한 지식이 필요하며 이를 할 수 있는 소프트웨어를 만드는 것은 종종 제한된 정보에 접근하거나 시간 둘 다 필요하다.

3. Windows Memory Management

현대의 모든 운영체제는 다른 프로세스에 속하는 데이터 접근의 위험이나 불필요성을 방지하고자 하면서 더 큰 주소 공간에 프로세스가 접근할 수 있도록 하는 가상 메모리 시스템의 형태를 갖고 있다. 윈도우 XP에 의해 사용되는 VM 시스템은 프로세스가 가상 주소 4GB 모두에 접근하는 것을 가능하게 하며, 페이징 시스템에 의한 실제 물리 주소에 대한 요청으로 가상 주소를 변환할 수 있다.

The Paging System

 RAM의 과도함을 요구하지 않고 메모리의 전체 4GB를 프로세스가 위치하도록 하기 위해서는 각 프로세스는 페이징 시스템을 사용하여야 한다. 이 페이징 시스템 실제 물리 메모리 위치에 맵핑할 자신만의 가상주소를 허용해주며 이러한 페이징 시스템은 다음과 같이 구성이 된다. "각 프로세스가 유지하고 있는 페이지 테이블을 참고하는 1024을 포함하는 페이지 디렉터리, 각 페이지 테이블이 포함하고 있는 각 4096 주소를 참조하는 1024 페이지". 이는 4MB 전체 페이징 구조를 저장하는데 반해, 1024*1024*4096 이나 4G 가용한 주소를 줄 수가 있다. 32비트 가상 주소는 아래와 같이 3가지 파트로 나누어 진다.(예로 주소가 0x81291830)

이는 Page Directory에 10비트 인덱스와 Page Table에 10비트 인덱스, 그리고 Page에 12비트 인덱스를 허용한다. Page Directory Index는 사실 프로세스의 EPROCESS block에 저장된 Page Directory Base에 주어진 물리주소에서의 오프셋이며 페이지 테이블의 주소를 포함하는 정보를 가진 Page Directory Entry를 가리킨다. Page Table Entry의 물리주소는 PDE에 있는 주소와 프로세스의 Page Directory Base를 조합하므로 찾을 수가 있다. 마찬가지로, Page는 Page Table의 주소와 PTE에 있는 주소를 조합하므로 찾을 수가 있다. 마지막으로 바이트 오프셋은 데이터를 찾기 위해 해당 주소에 추가된다. 이러한 프로세스의 세부사항과 예외사항은 이후에 뒷부분에서 설명할 것이다.

Page Table Entries

 Page Directory는 효과적으로 동일한 포맷을 가지는 PDE(Page Directory Entries)와 PTE(Page Table Entries)의 Page Table로 구성된다. 이들은 필요한 Page Table이나 Page 뿐만 아니라 각각 다른 유용한 정보로의 포인터까지 포함한다. 이에 대한 구조는 아래와 같다.

여기에는 세가지 비트가 있는데 [1-19]비트는 Page Table이나 Page에 대한 위치를 가리키는 포인터를 포함하며 bit [31]은 페이지가 물리 메모리에 액세스 할 수 있는지의 여부를 나타내는 'Validity Flag'이다. [20-30] 비트는 오직 페이지가 물리 메모리에 접근할 수 없을 때에만 유용하다(아래에서 이야기 할 것이다).

Page Faults and the Page-file

 일부 경우에 어느 한 프로세스가 많은 양을 필요로 하거나 많은 프로세스가 동시에 실행되고 있을 수 있기에 프로세스는 물리(실제) RAM에서 사용할 수 있는 것보다 더 많은 메모리가 필요로 한다. 이런 경우, 메모리에서 덜 사용되는 페이지가 하드 디스크로 'Swapped out'된다. 프로세스가 메모리의 페이지에 대한 요청을 하면, 페이지는 RAM으로 'Swapped in'되며 다른 페이지가 스왑 아웃된다. 프로세스가 스왑 아웃 페이지를 요청하면, 'Page fault'가 생성된다. 이는 VM시스템이 PDE나 PTE의 포맷을 다르게 해석하도록 야기하며 대신 요청된 페이지의 page-file을 보고하도록 한다. page-file은 일반적으로 'pagefile.sys'라 불리며 각 드라이브의 최상단에 위치하고 있다. 하지만 여러 페이지 파일이 있도록 설정되어 있는지와 어디에 있는지를 확인해야만 한다. 페이지파일의 포맷은 매우 단순하며, 정확하게 메모리와 동일하게 처리될 수 있다. 또한 이는 물리주소로 사용되는 같은 오프셋에 의해 참조될 수 있는 연속적인 단순한 데이터이다.

 페이지가 더이상 메모리에서 사용될 수 없을 때, 'invalid'가 되며 이에 따라 PTE나 PDE가 변경된다. 'invalid' PTE나 PDE는 항상 최하위 비트가 0으로 설정 되어야 하지만 약간 다른 PTE/PDE 포맷을 사용하는 각자들이 'invalid'가 되는 몇 가지 이유가 있다.

- Page File : 요청된 페이지나 페이지 테이블은 디스크로 스왑 아웃된다. 이는 아래와 같이 페이지파일 넘버[N]의 오프셋을 읽으므로 검색될 수가 있다.

- Demand Zero : 요청은 zero의 페이지를 필요로 함에 따라 그러한 요청은 0을 리턴함으로 만족될 수가 있다. 필드 [O], [T], [P], [N], [V]가 모두 제로이다.

- Transition : 요청된 페이지는 페이지 테이블이 마지막으로 업데이트 된 이후에 수정되었을 수가 있다. 이는 필드 [V]가 제로인 것을 제외한 유효한 PTE는 동일하다.

- Prototype : 요청된 페이지는 다른 프로세스와 공유될 수가 있다. 이 구조는 유효한 페이지로 동일하지만 이는 실제주소를 가리키지 않기에. 편의상 잘못된 주소로 간주될 수가 있다.

Address Translation

 언급한 바와 같이 주소 변환은 가상 주소와 프로세스의 Page Directory Base(PDB)를 가지고 시작한다. 이러한 두 값을 제공하므로, 페이지 파일이나 메모리 덤프에 대한 엑세스와 주소를 가상 주소에서 물리주소로 변환할 수 있으며, 제공된 주소의 메모리에서 콘텐츠를 발견될 수 있다. 이 순서는 아래와 같으며 최상위 비트는 0으로 번호가 매겨진다. 이하의 설명이 도움이 되도록, 예제는 이러한 변수들을 가질 것이다.

1. VA의 10비트(1000000100=0x204)를 갖고 각 PDE는 4바이트이기 때문에 0x4를 곱하여 0x810을 제공하므로 페이지 디렉터리 인덱스(PDI)를 복구할 수 있다.

2. 페이지 디렉터리의 물리주소를 제공하기 위해 PDI(0x810)을 PDB(0x39000)를 추가한다. = page directory(0x39810)

3. PDE(0x01222163)를 제공하기 위해 32비트(4바이트) 주소의 값을 읽는다.

4. Page Table의 물리주소는 PDE의 특정 비트의 상태에 의존한다. 만약 [31] 비트가 1일 경우 페이지는 유효하며, [0-19]비트는 0x1000(각 페이지는 4096바이트이다)과 곱해진 후 RAM의 물리주소로서 사용되고 읽혀질 수 있다. 만약 31비트가 0이면 페이지는 물리 RAM에 접근할 수가 없다. 이 경우는 다음과 같다.

- 만약 [0-20]과 [26-30]이 0일 경우 PTE는 'demand 0'이며 그렇기에 제로 페이지가 반환될 수 있다.

- [21]비트가 1인 경우 페이지는 공유되는 주소를 의미하며 이처럼 단순함은 'invalid'로 간주 될 수가 있다.

- 만약 [21-22]가 0이라면 Page Table은 디스크로 스왑 아웃되어있는 것이며 이는 [27-30]비트가 페이지 파일 번호로 주어지고 [0-19]비트가 페이지 파일의 오프셋으로써 주어지는 것을 의미하며, 이 오프셋을 위치를 읽는 것은 Page Table의 주소를 알게 한다.

5. VA의 [10-19]비트(1010010001=0x291)에 0x4를 곱하므로 가상 주소로부터 PTI (Page Table Index)를 복구할 수 있으며 이는 0xA44이다.

6. PTI를 4단계에서 읽은 Page Table의 값에 더한다. 계산을 하면 그 값은 0x1222A44가 된다.

7. PTE ( Page Table Entry : 0x011F2163)의 주소를 읽는다.

8. 4단계와 마찬가지로, 페이지의 위치는 PTE에 의존적이다. 유효한 페이지 비트[0-19]에 0x1000을 곱하고 이는 RAM 내 Page의 물리주소로 사용될 수 있다. 4단계와 같이 적용하지 않으면 페이지는 'invalid'가 된다. 예에서 PTE는 유효하며 이는 주소 0x11F2000을 가져온다.

9. 정확한 가상 주소의 물리주소를 얻기 위해서 가상주소의 마지막 12비트[20-31]에 의해 주어지는 바이트 오프셋을 더한다.

이러한 과정은 가상 주소에서 참조하는 물리주소를 제공하며, 물리 메모리 덤프나 페이지 파일의 데이터 조각을 나타내는 주소를 제공한다.

4. Memory Acquistion

 디지털증거의 가이드라인에 따라 적어도 가장 휘발 적인 것부터 수집을 해야한다. 이는 사고 대응 팀이 해야할 첫번 째 것들 중 하나로 현장에서 실행중인 컴퓨터 RAM의 사본을 확보하기 위해 시도해야한다는 것이다. 하지만 이러한 생각의 문제는 가이드 라인이 의심되는 장치에 대해 모든 단계를 다루는 것이 아니라는 점이다. 이러한 룰의 완화를 위해선 추론과 이미징 기법의 영향이 더욱 고려되어야 한다.

(역: * 현재에는 당시보다 더 나은 툴들이 많이 나왔기에 툴에 대한 설명들은 번역을 하면서 제외 시켰다.)

Software Solutions

 소프트웨어 메모리 이미저는 의심 되는 컴퓨터나 의심되는 컴퓨터 안에 이미 나타나는 소프트웨어(운영체제와 같은)를 실행한다. 첫째로, 몇 가지 소프트 웨어는 존재하고 있는 운영체제에 의하여 실행된다. 이는 운영체제가 잘못되거나 무책임한 결과를 제공하는 방식의 프로시저 호출을 야기할 수 있으며 그 결과로 얻어진 결과들은 결코 신뢰할 수가 없다. 두번째로, 어떤 데이터는  이미징 프로세스가 동작하는 동안에 항상 수정되는데 이는 심지어 가장 효율적인 메모리 이미저도 메모리에 로드되며 이는 기존에 존재하는 데이터를 대체할 수 있기 때문이다. 만약 오래된 데이터가 디스크로 스왑 아웃되면 아직 덮어지지 않았지만 더 이상 사용하지 않는 페이지는 삭제될 것이다. 이 문제는 매우 작은 메모리 이미저를 통해 완화될 수 있지만, 이 문제를 완전히 제거할 수는 없다. 메모리 이미징 프로그램은 메모리 이미지에 나타나며, 그러므로 조사시에 고려되어야만 한다.

 또 다른 문제는 대부분의 소프트웨어 솔루션은 유저모드에서 실행되며 다른 실행 중인 프로세스들과 프로세서의 시작을 공유한다는 것이다. 그러므로 이들은 다른 프로세스들이 프로세서로부터 실행 시간을 인수하기 전에는, 이미징 프로세스가 동작하는 동안에 데이터 변경을 초래할 수 있기에 RAM 전체의 내용을 이미징 할 수가 없다. 마지막 문제는 유저 권한으로 실행되는 메모리 이미저가 없다는 것인데 이는 유저 권한으로 물리 메모리 전체에는 접근을 할 수 없기 때문이다. 이러한 접근할 수 없는 부분도 조사에 있어서는 항상 고려되어야 하며 중요한 증거가 이로 인해 손실될 가능성이 존재함을 인지해야 한다. 

Hardware Solutions

 최근 들어(역:당시 2006년) 소프트웨어 기반 수집을 대체하는 몇 가지 방법들이 제안되었다. 이러한 기법들은 수정 없이 RAM의 전체 내용을 카피할 수 있도록하는 DMA를 통해 메모리에 직접 접근하는 이점을 갖는다. 이에 더해, 매우 빠르게 복사를 할수가 있으며, 이는 리스크를 줄이며 이미징 프로세스가 동작하는 동안 데이터를 변화를 감소시킨다.

Hibernation

 'Hibernation'은 휘발성 메모리를 디스크에 저장하는 것을 허용하므로 사용되는 시스템이며, 데이터의 영구적인 손실 없이 전원을 끄는 것을 가능하게 한다. 몇 가지 문서에서 볼 수 있듯이 유용한 정보들이 'hiberfil.sys'로, 시스템이 하이버네이션 상태가 될 때 해당 파일에 저장되어 있을 수가 있다. 

 또한 하이버네이션은 추가적으로 프로그램이 로드될 필요가 없기 때문에, 메모리의 내용을 수집하는데 유용하게 사용될 수가 있다. 하지만 불행하게도, 이에 관련된 몇 가지 문제가 있다. 첫째로, 시스템이 절전모드가 될 때 데이터는 'hiberfil.sys'에 쓰여진다. 만약 이 파일이 기존에 존재하면 덮어 씌워지기 때문에 기존의 파일은 제거된다. 둘째, 'Disabled'된 시스템에서 절전모드를 활성화 하기 위해선 추가적인 단계가 요구되는데 이는 데이터가 변화될 위험이 증가하도록 한다. 또 중요한 문제는 윈도우 XP의 하이버네이션 코드는 'ntldr'파일안에 포함되어 있는데 이는 공개되지 않은 소스로 철저한 테스트 없이는 하이버네이션의 결과가 무엇일지 확실하게 표시할 수가 없다는 것이다. 또한 이는 어떠한 데이터가 저장되어 있는지 명확하지 않지만, 마이크로소프트에 따르면 현재 사용 중인 페이지가 디스크에 기록되므로 절전모드에서 정상모드로 복귀하는 속도를 향상시킨다. 그리고 이들은 독점 압축 알고리즘을 사용하여 쓰여지기 전에 압축된다. 이는 압축 알고리즘과 파일 포맷이 하이버네이션 파일을 분석하고자 하면 이전에 밝혀져야만 한다는 것과. 잔여 데이터 메모리의 여유 공간을 분석하기 위한 기회가 없다는 것을 의미한다. 만약 이러한 문제들이 해결된다면 다음과 같은 사항들이 하이버네이션을 통하여 가능해진다.

hiberfil.sys 파일을 복사, 시스템을 절전모드로 전환, 디스크를 복사(클론), 절전모드일 때와 동일한 상태에서 시스템을 생성하거나 재개하는데 클론을 사용

하지만 이러한 단계를 실현가능하도록 하기 위해서는 하이버네이션 프로세스와 하이버네이션 파일의 포맷에 대한 더 많은 연구들이 필요하다.

5. Memory Analysis

의심되는 장치로부터 메모리 이미지를 획득했다면, 그로부터 추출될 수 있는 의미있는 정보들을 위해 분석을 해야만 한다. 최근까지(역: 2006년) 만약 메모리가 조사되지 않았다면 이를 종종 문자열이나 'foremost'와 같은 카빙 툴을 사용해 공통된 파일 타입을 찾고는 했었다. 앞서 언급한 바와 같이이러한 방법들은 몇 가지 유용한 정보의 조각들을 밝혀주지만 저장되어 있는 그 정보들의 내용은 손실되어있는 경우가 많다. 메모리 덤프 분석의 영역은 수집보다 새롭지만, 몇 가지 툴들이 개발되었다. 마이크로 소프트의 'Debugging Tools for Windows' 또한 특정 상황에서 메모리 분석에 사용할 수 있지만, 메모리 분석 툴 중 공개된 것으로는 'Memory Parser'와 'WMFT'이다.

 이 문서에서 지금 까지 발표된 정보는 적어도 다음과 같은 작업이 자동화 툴을 이용하여 가능하다는 것을 보여준다.

- 가능한 자세하게 어드밴스 프로세스 Lister를 통해 실행 중인 프로세스에 대한 데이터를 보여준다.

- 프로세스를 로드하는 실행파일의 이미지를 복구할 수가 있으며, 이를 디스크로부터 원본과 비교하거나 더 상세히 분서할 수가 있다.

- 힙으로 부터 각 프로세스에 할당된 메모리 공간을 보여주며, 프로그램에 대한 상세한 지식과 시스템에 의해 분석하거나. 문자열이나 이미지를 찾을 수가 있다.

- 가능한 경우 페이지 파일을 통합하고 읽혀지는 각 프로세스의 가상주소 공간의 전 범위를 허용한다.

(* 역 : 툴에 대해서는 현대에 더 좋은 툴이 많기에 WIinDBG만 간략하게 언급을 하고 이외의 것들은 언급하지 않습니다.)

Available Tools

WinDBG

WinDBG는 Debugging Tools for Windows의 GUI컴포넌트이며 사용자가 실행 중인 시스템이나 시스템 크래쉬에 의해 생성되는 메모리 덤프를 분석할 수 있게 해준다. 명령어는 크래시 됐을 때의 시스템 상태의 특정 측면을 나타내기 위해 입력될 수 있으며, 조사될 프로세스에 사용가능한 심볼 데이터베이스를 제공한다. 운영체제에 대한 심볼들은 전역적으로 정의가 가능하지만 private 심볼들은 유저공간 프로그램에 의해 정의 될 수 없다. 크래시 덤프가 열리거나 분석될 때 선택할 수 있는 많은 명령어들이 존재한다. 이러한 명령어 중 가장 유용한 몇 가지는 아래와 같다.

Table 4: Useful WinDBG commands

 이러한 명령어들은 커널 공간을 설명하는 핵심 값들을 제공하며, 이미지 파일이나 프로세스 힙과 모듈에 대한 주소와 같이 프로세스에 대한 몇 가지 정보를 제공한다. 하지만 WinDBG를 통해 덤프의 실행 이미지 파일을 복구할 수는 없다.

6. The 'vtop' Proof-of-Concept

( * 역 : 이번 장부터는 위의 개념들과는 별로 관련성이 떨어지기에 몇 부분만 번역하였다. 자세한 사항이 궁금하다면 원문을 보아야 한다. )

Intent

 이 툴은 프로세스의 가상 주소 공간이 페이지 파일과 물리 메모리 덤프를 조합하므로 재구성 할 수 있음을 증명하도록 개발 되었다

Tools and Design

 이는 단지 개념 증명을 목적으로 했기 때문에, 보통 모듈화, 규모화, 성능 및 요건이 개발 시간을 희생시켰다.프로그래밍 언어로는 파이썬을 선택되었는데, 이는 파일 핸들링과 같은 필요한 OS 함수들을 모두 지원하며, type이 함축되도록 허용한다. 또한 2진수와 10진수, 16진수를 변환하기에 편리하기 떄문이다. 'IDLE' 개발 환경을 사용하는 것은 실시간으로 코드가 쓰여지고 실행될 수 있음을 허락하며 새로운 함수들이 전체 시스템의 리로드 없이 테스트 될 수 있다.

Testing and Problems

이 프로그램은 오직 개념 증명이기에 철저하게 제품으로서 테스트 되지 않았다. 몇 가지 구조들은 예상되는 주소에서 출력되었고 심지어 이는 버그가 존재해도 기본적으로 작동하도록 나타났다.

 프로그램의 첫번째 문제중 하나는 큰 파일을 읽을 때 발생한다. 파이썬에 대한 제한된 경험때문에 vtop의 첫번째 버전은 메모리 덤프나 페이지 파일 전체의 내용을 읽으려 시도하며, 긴 시간이 걸리지 않았은 것 뿐만 아니라 테스트 시스템의 스왑 파일이 충분히 크지 않다면 I/O 예외를 생성한다. 이 문제는 추후에 파일의 작은 부분이 한번에 읽힐 수 있도록 하는 seek() 함수를 사용하므로 극복하였다.

 가장 큰 문제는 프로그램의 부분을 테스팅 하는 것이 어렵다는 것이다. 페이지 파일로부터 복구된 데이터가 어떤 결과가 나오는지 밝힐 수가 없기에 이것이 옳은 것인지를 확인할 방법이 없다. _EPROCESS 블러이나 이와 연결된 구조와 같이 확인 될 수 있는 모든 중요한 데이터 구조가 디스크에 페이징 되지 않고 오직 사용자 공간 프로세스들만 스왑 아웃된다. 이를 테스트하는 하나의 명백한 방법은 특정한 가상 주소에 특정한 데이터를 기록하는 프로그램을 제작하고, 프로세스가 디스크에 페이지 되도록 하며, 메모리나 페이지 파일을 수집한 후 지정된 데이터의 지정된 주소공간을 확인하는 것이다. 이 방법은 매우 어려우며, 시간 또한 많이 소요된다. 또한 이미 필자가 시도했지만 실패하였다.

Improvements

툴이 개념증명 상태 이후 개발된다면, 몇 가지 옵션들이 주어지면 더욱 유용할 것이다. 이러한 요소로는 특정 PDB를 지정하거나 I/O 파일이름과 명령어 라인의 주소 범위, 대화형 또는 구성파일 등이 있으며, 이들은 좀 더 사용자가 사용하기 쉽도록 할 것이다. 

Applications

이러한 제약에도 불구하고 이 툴은 특정한 상황에서 유용할 것이다. 만약 특정 프로세스가 의심되는 경우, 재구성된 주소는 그 프로세스와 관련될 수 밖에 없는 결과들에 대한 지식과 함께 찾을 수 있게 할 것이다. 

Reference

Nicholas Paul Maclean - “Acquisition and Analysis of Windows Memory” PDF