1.  요약

  중요한 파일이 유출되었을 경우 많은 상황들이 나타날 수가 있다. 이러한 많은 상황들 중 이번 문서에서는 USB를 통해 문서파일이 유출된 경우에 대하여 다루어보았다. 따라서 이외의 상황에 대해선 다루지 않는다.

  문서 유출과 관련되어 기술적인 측면만으론 정확하게 확인하기가 힘든 것은 사실이다. 그래도 그러한 가능성의 여부를 좀 더 확인하고자 하는 것은 충분히 가능하다. 특정 파일이 유출되었는가를 확인하기 위해선 이후에 설명할 바와 같이, 하나의 요소만으로는 확인할 수가 없다.

  남겨진 여러 가지의 흔적들의 연관성을 통해 당시 그 상황에 어떠한 일이 이루어졌는지를 확인하므로, 당사자가 하지 말아야 할 행동을 했거나 의심되는 행동을 했는지 확인하는 과정이 될 것이다.남아 있는 흔적의 수가 하나 하나 늘어날수록 더 유용할 수도 있지만, 오히려 분석을 하는데 있어 시간을 지체하게 만들기도 한다.

  PC에서 문서가 열람이 된 경우 남는 흔적들을 통해 본인이 자리를 비웠을 때 어떠한 문서들이 열람되었는지를 확인할 수가 있으며, USB를 통해 유출된 경우 USB 연결 흔적과 USB에서 문서를 열람했다면 좀 더 결정적인 흔적이 남는다.

  가장 많은 흔적이 남는 부분은 레지스트리이지만, RecentDocs의 항목만으로는 유출에 대하여 확정 짓기에는 많이 부족한 감이 있다. 따라서 레지스트리 외에도 프리패치, 링크파일 등을 통해서 종합적으로 추론할 수가 있다.

2. 개요

  일반적으로 특정 파일이 의도치 않게 유출 되는 경우가 발생할 수 있다. 가령 같은 직장의 다른 직원이 내 PC의 중요파일이나 기밀 문서 등을 가져가므로 유출되었을 수가 있다. 이러한 사항들로 인해 많은 사람들이 유출 여부를 확인하고자 하지만 막상 구체적인 방법에 대해 제시된 글은 많지 않다.

  실제로 특정파일이 유출되는 경우와 관련해서는 많은 사항들을 고려해야 한다. 하지만 이 모든 것을 다루기에는 어려우므로 한정적인 상황에 대해서나마 방법에 대하여 고려해보자. 기술적인 측면뿐 아니라 심리적인 측면 또한 들어가므로 유념하여야 한다.

2.1 실습 준비

  많은 사항들 중 USB를 통해 PC의 파일이 유출되는 경우에 한해 다룰 것이다. 따라서 특정 파일을 가지고 있는 PC와 USB가 있어야 한다. 그리고 실습을 위해 특정 파일을 3가지 준비하였다. 주로 문서와 관련한 사항이 중요하므로 이에 대하여 초점을 맞추었다.

그림 1. Target File List

  이외에 EXE파일이나, USB를 통한 유출이 아닌 부분은 여기서 다루지 않을 것이다. 문서에서 가장 자주 쓰이는 3가지 종류로 PDF, MSWord, HWP를 가지고 이제 어떠한 방향으로 접근해야 할 지 알아보자.

2.2 접근 방향

  특정 파일들을 준비하였으므로, 어떻게 접근할 것인가에 대해 먼저 논의할 것이다. 그리고 이러한 방향에 대하여 직접 실습을 통한 작업을 첨부하여 더 자세하게 알아볼 것이다.

  PC를 만든 것은 결국 인간이며, 범죄를 저지르는 사람도 결국 인간이다. 따라서 기술적인 측면뿐만 아니라 심리적인 요소 또한 고려를 해야 편협적이지 않게 접근할 수가 있다. 한번 직접 범법자가 되었다 생각하고 타인의 PC에서 파일을 가져오는 방법에 대해 생각해보자.

표 1. 고려사항

  이러한 고민을 한다는 것에 이의를 제기할 사람을 아마 없을 것이다. 대상 PC에 접근하는 방법은 같은 회사라면 대상이 자리를 비웠을 때 접근을 할 것이며, 파일을 가져오는 방법으론 FTP나 메일을 통해 보내는 것도 있지만, 가장 편하게 USB를 연결하여 바로 보내는 것이 빠르다. 또한 마지막으로 파일의 위치는 기존에 조사를 통해 위치를 알고 있거나 당장에 찾을 것이다.

  바로 이러한 과정 중에 중요한 요소가 한 가지 더 발생하게 된다. 바로 해당 파일이 올바른지, 또는 올바르게 옮겨졌는지 확인을 한다는 것이다. 어느 위치에 있는지 모를 경우 유사한 이름의 많은 파일들을 열어보게 될 것이며, 이름을 안다 해도 이것이 맞는지 확인할 것이다.

  후자의 경우 전자의 과정을 거치거나 거치지 않더라도, 올바르게 파일이 옮겨졌는지 바로 그 현장에서 USB에 담긴 파일을 실행하여 확인해 볼 수가 있다. 바로 이러한 요소가 이 문서가 초점을 맞춘 부분이다.

3. PC에서 열람

  용의자가 파일을 복사해 가기 이전에 PC에서 열람을 했다는 가정하에 어떠한 흔적들이 남는지 조사해볼 것이다. 준비된 3가지 문서에 따라 어떠한 흔적들이 남는지 확인해보자.  

3.1 ReadMe.PDF

그림 2. PDF – Opened Time

  PDF파일을 먼저 열어보았다. 시간은 위와 같이 01:17:11초 근처에 열었으며 종료는 이로부터 13초후에 종료하였다. 어떠한 변화가 있는지 레지스트리를 확인해보았다. 아래의 그림을 보자.

그림 3. PDF – Registry (1)

  위의 그림과 같이 PDF는 Adobe의 하위에 있는 Acrobat Reader\DC\AVGenerel의 하위 항목 값들이 변화한 것을 확인할 수가 있다. 해당 문서를 열람하고자 할 경우 PDF 리더기가 먼저 실행이 되므로 이와 관련된 부분들이 변화한 것이다.

  Acrobat Reader의 cRecentFile의 하위에 c1의 값들이 변화한 것을 확인할 수가 있다. C1이 나타내는 FileName이 ReadMe.pdf인 것과 경로를 확인할 수 있으며, 해당 키의 마지막 쓰기 시간이 PDF를 실행한 시점과 같다는 점에서 실행한 흔적임을 알 수 있다.

그림 4. PDF – Registry (2)

  레지스트리에서 가장 보편적으로 확인해야 할 항목 중 하나인 RecentDocs에도 해당 PDF 파일의 항목이 추가된 것을 확인할 수가 있다. 레지스트리 외의 항목들은 무엇이 있을까? 아래의 그림을 보자.

그림 5. PDF – Prefetch File

  우선 PDF Viewer인 Acrobat Reader가 실행되었으므로, 이에 해당하는 프리패치 파일이 생성된 것을 확인할 수가 있다. 여기서 해당 프로세스가 로드한 항목들 중 ReadMe.pdf가 존재하는 것 또한 확인할 수가 있다.

그림 6. PDF – Link File

  다른 항목으로는 바로 링크파일이다. 프리패치의 항목에서도 링크파일이 로드 된 것을 확인할 수가 있으며, 실제로 링크파일 분석 도구를 통해 확인하면 해당 시간에 맞는 흔적이 존재하는 것을 확인할 수가 있다. 만약 기존에 열어보았던 문서라면 LnkCreation Time과 AccessTime 등이 다르다. 

3.2 ReadMe.hwp

그림 7. HWP – Opened Time

  HWP의 경우 특이하게 대한민국에서만 사용률이 높은 문서양식이다. Hwp와 MS 워드 중 hwp를 쓰는 기업도 있기 때문에, 이에 중요한 내용이 담겨 있을 경우를 고려하여 어떠한 흔적이 남는지 확인해보았다.

그림 8. HWP – Registry (1)

  위의 그림은 문서를 연 시간대 이후 변화한 레지스트리 항목들을 나타내고 있다. 전체적으로 PDF와 유사한 변화들을 보이고 있다. 우선 RecentDocs에 대해선 PDF에서도 다루었기에 다루지 않을 것이다. 그림 8의 마지막 항목을 보자.

그림 9. HWP – Registry (2)

   PDF Viewer와 같이, HWP는 한컴오피스에 관련되어 레지스트리 항목이 저장되는 것을 확인할 수가 있다. 해당 값에는 문서의 경로까지 나타나고 있다.

그림 10 HWP – Prefetch File

  프리패치 파일 또한 생성되는 것을 확인할 수가 있다. 로드된 항목엔 이전과 같이 링크파일의 존재를 확인할 수가 있으므로 Lnk파일 또한 확인해보자.

그림 11. HWP – Link File

  HWP를 연 시간에 AccessTime이 나타나고 있다. 여기서 Creation Time과 Access Time이 다른데, 이는 이전에 설명한 바와 같이 이전에 한번이라도 열어본 파일인 것이다. 이전에 열었을 때 링크 파일이 생성되었으며, 마지막 접근 시간은 22일 이므로 서로 다르다. 이를 통해서도 언제 마지막으로 접근했는지 확인할 수가 있다.

3.3 ReadMe.Docx

그림 12. Docx – Opened Time

  MS 워드 또한 Hwp와 마찬가지로 많이 사용되는 문서 양식이다. 위 그림과 같이 해당 문서를 연 시간은 01:10:19초 가량이며 이전과 마찬가지로 해당 시간대 이후의 레지스트리 변화를 살펴보자.

그림 13. Docx – Registry (1)

  RecentDocs에 값이 추가된 것을 확인할 수가 있다. 이외에 특이한 점으로 Microsoft의 하위에 Office\14.0\Word 밑에 있는 값들에 변화가 있다는 것을 확인할 수가 있다. 여기서 중요한 부분은 File MRU이다.

그림 14. Docx – Registry (2)

  Fil MRU를 보면 Item으로 값이 존재한다. 여기서 Item에 순서가 주어져 있는데 가장 최근에 열어본 문서의 경로와 이름이 1번이 된다. 이후 새로운 문서를 확인했을 경우 해당 번호가 뒤로 밀리므로 유의하여야 한다.

  마지막으로 앞의 두 경우와 마찬가지로 프리패치 파일과 링크 파일을 통해 해당 문서를 열었는지 확인할 수가 있다.

그림 15 Docx – Link File

4. USB에서 열람

  이전 장의 내용들을 통해 어떠한 문서가 열람되었는지 많은 흔적들을 살펴볼 수가 있었다. 하지만 이러한 하나의 흔적들만으로는 파일 유출에 대해 확신할 수가 없다. 그러므로 이번 장에선 USB 내에서 열람된 경우를 살펴보자.

  USB에서 열람되었다는 것은, 이전의 흔적들보다 좀 더 큰 유출 가능성을 나타낸다. 만약 연결되지 않아야 할 USB가 연결되었을 수도 있으며, USB로 옮겨져선 안될 문서가 존재할 수도 있다. 또한 USB의 경우 언제 연결되었는지 시간을 확인할 수가 있으므로 더 많은 흔적들을 남긴다고 볼 수 있다.

4.1 USB 최초 연결 흔적

  USB에 관한 흔적의 경우 크게 2가지로 볼 수가 있다. 바로 최초 연결된 시점과 마지막으로 연결된 시점이다. 최초 연결 시 많은 흔적들을 남기지만, 마지막 연결된 시점의 경우 이에 비해 흔적이 많이 적다. 이에 대해 하나 하나 알아보자.

그림 16. USB – Setupapi.dev.log

  %SystemRoot%\INF\Setupapi.dev.log는 대표적으로 최초 연결 흔적이 남는 항목이다. 어떠한 USB가 최초로 연결될 경우 위의 그림과 같은 항목들이 형성된다. 하지만 log 파일에 많은 내용이 저장되면 이전의 내용들이 지워진다는 것을 잊으면 안된다.

그림 17. USB – Registry [Portable Devices]

  최초 연결과 관련된 많은 항목들 중 하나만 이야기 더 한다면 위 항목과 같다. 기존의 레지스트리엔 KALI LIVE란 항목이 없지만 USB를 연결한 이후 해당 라벨명이 기록되는 것을 확인할 수가 있다.

  이외에도 최초 연결과 관련되어 많은 흔적들이 존재한다. 만약 본인의 PC에 본인이 사용하지 않는 USB 연결 흔적이 있을 경우 유출에 대하여 더 의심해볼 수 있는 상황이 될 것이다. 하지만 최초 연결은 최초 연결된 시점만 다루기에 마지막 연결 시점이 필요하다.

4.2 USB 마지막 연결 흔적

  본인의 PC에 직장 동료나 친구가 이미 USB를 연결했던 적이 있다면 위의 흔적들은 최초 연결된 시점만을 가리키기에 아무런 소용이 없다. 따라서 이러한 상황에 필요한 것이 바로 마지막 연결 시점이다.

그림 18. USB – Registry

  위 그림은 이전에 연결한 적이 있던 USB를 다시 연결한 것이다. 항목에서 나타내는 것과 같이 항목에는 USB의 VID나 PID등이 기록되어 있다 .따라서 다시 연결한 경우 해당 항목의 마지막 쓰기 시간이 갱신되어 있는 것을 확인할 수가 있다.

  하지만 이러한 방법으로 확인하는 것을 어려움이 따른다. 따라서 간단하게 확인할 수 있는 방법에 대하여 알아보자.

그림 19. USB – Event Log

 이벤트 로그에는 많은 내용들이 기록이 된다. 여기서 우리가 살펴보아야 할 이벤트 항목은 응용프로그램 로그의 Microsoft\Windows\DriverFrameworks-UserMode이다. 해당 로그엔 USB를 연결한 시간과 해제한 시간이 기록되어 간편하게 확인할 수가 있다.

  하지만 해당 로그는 윈도우 7까지만 기본적으로 활성화되며, 윈도우 8부턴 비활성화되어 있기 때문에 활성화 해놓는다면 이후 분석에 있어서도 많은 편의를 가질 수가 있을 것이다.

4.3 USB에서 문서 열람

그림 20. USB – Time

  위 그림은 이후에 분석할 내용을 나타낸 시간이다. 03:13:45 가량에 USB를 연결한 이후부터 연결을 해제한 03:15:16 근처까지의 시간을 나타내는 것이며 이와 관련하여 분석해보자.

그림 21. USB – Connected Time

  USB가 최초 연결이 아니기 때문에 많은 흔적이 남지는 않는다. 하지만 기존의 형성되어 있는 항목들의 몇 가지 값들이 갱신되어 마지막 쓰기 시간이 변화된 것들을 확인할 수가 있다. 이외에도 USB 연결과 관련된 항목은 생략하겠다.

그림 22. Registry - Docx

  이전에 PC에서 문서를 열람했을 때와 마찬가지로 유사하다. 하지만 한 가지 필요 없어진 점이 있다면, 바로 RecentDocs이다. 해당 항목에선 열람된 파일의 경로가 나타나지 않기 때문에 외부에서 실행한 것임을 알 수 없다.

  그에 반해 MS Word의 File MRU 항목에서는 해당 경로까지 나오므로 새로 마운트된 볼륨 F: 에서 문서가 열람된 것임을 확인할 수가 있다.

그림 23. Registry - PDF

  PDF의 경우도 위와 유사하다. RecentDocx에서는 파일의 경로를 알 수가 없지만 Acrobat Reader의 하위 항목인 RecentFile에선 가장 최근에 열람된 항목이 되는 c1에서 파일의 경로까지 확인할 수가 있다.

그림 24. Registy - HWP

  한글파일의 경우도 마찬가지다. HwpFrame 밑에 있는 RecentFile의 값을 통해 가장 최근에 열람된 'file0'의 데이터가 F:\OpenMe.hwp를 가리키고 있는 것을 확인할 수가 있다.

그림 25. Prefetch File

  위는 프리패치 파일의 정보를 나타내는 것으로 각 뷰어들이 실행된 시간을 확인할 수가 있고, 문서의 위치는 로드된 파일 정보에서 'Device Path'를 통해 외부에서 로드가 된 것인지 확인할 수가 있다. 아래의 그림을 보자.

그림 26. Prefetch File (2)

  그림에서 볼 수 있듯이, 기존의 C: 에서 로드된 항목들은 경로가 올바르게 나타나지만 외부에서 로드된 항목은 경로가 제대로 나타나지 않는다. 하지만 Device Path를 통해 볼륨ID가 다른 것을 확인할 수가 있으며, 이를 통해 외부 장치임을 알 수가 있다.

그림 27. Link File

  링크 파일의 경우 바로 해당 파일이 열람된 위치인 F: 가 나타나는 것을 볼 수가 있으며, 이를 통해 쉽게 외부에서 문서가 열람된 것임을 알 수가 있다.

5. 참고

* 블로그, USB를 통한 자료 유출의 흔적

• http://egloos.zum.com/ykei/v/4761463

* 블로그, 개인정보 보호를 위한 USB 장치 사용내역 확인할 수 있는 프로그램

• http://wezard4u.tistory.com/2692

* 블로그, 어떤 사용자가 어떤 파일을 cp 했는지 기록이 남는가

• https://kldp.org/node/48984

* 블로그, USB 연결 흔적 관련 아티팩트

• http://kali-km.tistory.com/entry/Practice-USB-Artifacts

  포렌식을 공부하면서 점차 데이터 복구나 수집한 증거를 분석하는 방법에 대하여 점차 관심이 많아지기 시작하였다. 이를 위해선 공통적으로 파일 시스템에 대한 이해가 필요하다고 생각하였고, 그렇기에 현재 사용하고 있는 NTFS에 대하여 먼저 학습해보자 생각하였다.

  파일 시스템이나 NTFS에 대하여 이론적으로 더 잘 정리된 많은 문서들이 있으므로, 나는 Python을 통해 접근을 하기 위함을 목적으로 학습을 진행하였다. 이렇게 접근을 한 다음 최종적으로는 $MFT 수집 도구를 만드는 것이 목적이다. 학습을 위한 준비사항은 아래와 같다.

표 1. 사용한 도구

  학습은 윈도우 10을 통해 진행하였으며 전체적으로 학습을 하면서 Windows7이나 XP와의 별 차이를 느끼지 못하였다. Prefetch나 Web Artifact에 있어선 좀 상이한 부분이 있지만, 이번 문서에서 다루는 내용에 한해서는 큰 차이가 없었다.

그림 1. 부팅 과정

  컴퓨터의 전원을 누른 순간부터 사용자 모드로의 부팅 과정은 위의 그림과 같다. 여기서 BIOS는 ROM에 적재가 되어 있으므로 우리는 MBR부터의 과정을 구체적으로 확인할 수가 있다. 이를 토대로 학습을 진행해보자.

2. 디스크 접근

2.1 HxD 디스크 열기

  전체적인 진행을 하기 전에 직접 자신의 디스크를 확인해보자. HxD를 관리자 권한으로 실행을 한 다음, 아래의 버튼과 같이 디스크 열기를 누르면 대개 '논리 디스크'와 '물리 디스크'라 나뉘어 있는 것을 확인할 수가 있다.

그림 2. HxD 디스크 열기

  이 중 어떠한 것을 열어야 할 지 모른다면 직접 둘 다 열어서 확인해보자. 어떠한 차이가 있는지는 아래의 그림과 같다. '물리 디스크'를 먼저 확인해보면 알 수 있는 것이 아무것도 없다. 반면에 '논리 디스크'로 연다면 시작과 함께 NTFS라는 문자열이 있다.

그림 3. HxD 디스크 확인

  이는 기본적인 디스크를 어떻게 구분하느냐에 따른 것이다. 물리 디스크는 하나의 장치 그 자체를 말하는 것이며 논리 디스크는 하나의 파티션이나 볼륨과 같은 논리적인 부분을 말하는 것이다.

2.2 Python 디스크 열기

  Python을 통해 이러한 물리 디스크나 논리 디스크에 접근하는 방법에 대하여 알아보자. Python에는 기본적으로 open(filename, type) 함수가 존재하고 있다. 그렇다면 어떻게 이러한 시스템적인 부분에 접근하는가? 아래의 그림을 보자.

그림 4. Python – open()

* 여기서 CMD를 열 때Administrator 권한으로 열어야 권한 거부가 생기지 않는다.

  이렇게 Python에서 Drive에 접근하고자 할 땐 '\\\\.\\Drive'와 같이 나타내어야 한다. 이는 원래 \\.\Drive 인 것을 나타내기 위해 \를 두 번씩 표기하여 주는 것이다. 만약 두 번씩 하지 않으면 하나는 생략된 결과로 Python은 인식하게 된다. 접근 모드는 'rb'로 바이너리를 읽기 모드로 여는 것이다.

그림 5. Python – read()

  제대로 물리 드라이브를 읽는 것을 확인할 수가 있다. 그렇다면 물리드라이브엔 어떻게 접근을 해야 할까? 의문을 가질 수가 있다. 결국 최종적인 목표는 $MFT를 수집하는 것임을 잊지 말자. NTFS에서 부팅 가능한 영역을 MBR에서 찾아서 가는 것이 어찌 보면 부팅 과정처럼 정도의 길이라 할 수가 있다.

그림 6. Python – 논리 디스크 열기

  하지만 바로 논리 디스크로 접근하는 방법이 있다면 굳이 MBR에서부터 부팅 가능한 영역을 찾는 번거로움을 감수하고 싶지는 않을 것이다. 위의 그림과 같이 \\\\.\\ 뒷 부분에 열고자 하는 논리 디스크 'C:'와 같이 입력을 해주면 된다. 읽은 부분에서 NTFS 라는 그림 3에서 확인했던 문자열이 올바르게 출력되는 것을 확인할 수가 있다.

2.3 MBR 구조

  물리 디스크 영역은 앞 부분에 MBR(Mater Boot Record)가 있다. 코드 영역엔 부팅을 하기 위한 코드들이 포함되어 있으며, 붉게 표시한 부분은 바로 파티션 테이블로 64 Byte를 차지하고 있는 것을 확인할 수가 있다. 전체적인 구조는 아래와 같이 나타난다.

그림 7. MBR

  코드 영역은 별도의 구조가 없이 코드들로 이루어져 있지만 파티션 테이블의 경우에는 구조가 있기 때문에 그 구조에 맞게 해석을 할 수가 있어야 한다. 파티션 테이블은 부팅 가능한 디스크를 나타내기 위한 부분으로 아래의 구조와 같다.

그림 8. Partition Table

  여기서 중요한 것은 바로 앞 부분의 1바이트이다. Boot Flag로 부팅이 가능한 파티션인지를 나타내는 값으로 0x80은 부팅이 가능하다는 것을 뜻하며 0x00은 부팅이 불가능함을 뜻한다. 파티션 타입의 경우 어떤 타입(FAT, Unix, NTFS 등)을 나타낸다.

  그렇다면 부팅 가능한(Boot Flag = 0x80) 파티션이 있다면 그 위치는 어떻게 알 수 있을까? 예전엔 CHS Address를 사용했지만 점차 용량이 커지므로 표현의 한계가 있기에 현재는 LBA를 통해 해당 운영체제의 시작 지점을 알 수가 있다. 여기서 LBA란 Local Black Area의 약자로 흔히 섹터라 표현할 수가 있다. 위 그림 8의 Starting LBA Address란 결국 몇 번째 섹터에 운영체제가 시작하는 지 포함되어 있음을 의미한다. 이를 직접 확인해보자.

그림 9. HxD Partition Table

  위의 그림은 실제 내 PC의 파티션 테이블이다. 각 색에 맞게 4개의 파티션이 나타나 있는 것을 확인할 수가 있다. 세 번째 파란색 부분을 보면 부팅 플래그가 0x80으로 부팅이 가능함을 나타내며 7912000 LBA에 운영체제가 시작함을 나타낸다.

* 참고 : 섹터의 크기는 512 Bytes이므로 해당 LBA에 512를 곱해 Offset을 알 수 있다.

  단, 윈도우 7부턴 윈도우를 설치할 때 시스템 예약 파티션이 나뉘어 지는데, 해당 파티션은 BitLocker 암호화를 위한 예약된 공간이다. 특이한 점은 이전 XP와는 다르게 부팅 플래그가 바로 이 시스템 예약 파티션에서 설정이 되어 있다는 점이다. 다시 말해 위 그림 9의 부팅 플래그 0x80으로 되어 있는 부분이 시스템 예약 파티션이란 것이다. 정확한 이유는 알 수가 없지만, BitLocker 암호화는 지정된 보호 기능을 위해 동작하는 것으로, 해당 부분을 보호하기 위하여 먼저 이 곳으로 부팅이 되는 것이 어찌 보면 당연한 것이다. 컴퓨터의 전원을 켰을 때 장치에 이상이 없는 것을 POST에서 확인하는 것과 유사하다고 생각하자.

  그렇다면 그림9에서 NTFS는 어디에 있는 것일까? 바로 네 번째 부분에 존재하고 있다. 파티션 타입번호(0x07)을 통해 확인하거나 해당 LBA로 직접 가서 확인하는 방법이 있다. 물론 시스템 예약 파티션을 없애면 바로 NTFS로 부팅 플래그가 설정 될 것이다. 만약 파티션이 5개 이상이라면 MBR에 더해 EBR로 관리를 하는데 이는 파티션 테이블 부분에 EBR로 가는 16 Bytes 구조가 생기며 해당 LBA로 이동하면 다음 EBR과 자신이 가리키는 파티션의 LBA를 가지고 있다.

 3. NTFS

  2장의 과정을 통해 MBR을 통해 부팅 가능한 파티션과 해당 파티션의 위치를 찾아가는 방법에 대하여 알아보았다. HxD로 '물리 디스크'로 디스크를 열었지만 이 방법을 통해 NTFS가 있는 '논리 디스크' C:와 같은 부분을 찾을 수가 있다.

그림 10. 논리디스크 찾기

  이제 본격적으로 NTFS에 대하여 알아보자. Python을 통해선 2장의 과정이 없이 바로 C:와 같은 논리 디스크를 열 수 있음을 다시 한번 기억하자. 이제부터 다룰 내용은 NTFS의 구조에 대한 것으로 필수적으로 알아야 할 내용들을 주로 다룰 것이다.

그림 11. NTFS 구조

  위 그림은 NTFS에 대한 전체적인 구조를 나타낸 것이다. VBR을 시작으로 MFT가 존재하고 있으며 그 후 각 파일에 대한 Data가 존재하고 있는 Data Area가 있다. 이들에 대하여 알아보기 전에 클러스터(Cluster)에 대하여 간략히 설명하고자 한다.

   디스크는 기록을 할 때 Sector 단위로 한다. 하지만 NTFS 운영체제는 Cluster 단위로 기록을 하는 것으로 이 두 사이에 차이가 난다. 이러한 Cluster Size는 볼륨의 크기에 따라 주로 결정되며 기본적으로 2GB이상이라면 Cluster Size는 4 KB이다.

3.1 VBR

  VBR은 Volume Boot Record의 약자로 해당 볼륨의 부팅을 위한 영역이다. 여기서 우리가 주로 보아야 할 부분은 바로 보라색으로 나타나있는 BPB 부분이다. 해당 부분엔 많은 시스템에 대한 많은 정보들이 포함되어 있다. VBR의 구조는 아래의 그림과 같다.

그림 12. VBR 구조

  BPB엔 섹터의 크기나 클러스터의 크기를 포함하고 있으며 이 문서에서 가장 중요하게 다루는 MFT의 시작 위치가 있다. 그렇기에 이 부분의 몇 가지 항목만 올바르게 해석할 수 있다면 된다.

그림 13. BPB 구조

  우선 Bytes Per Sector와 sec per Clus라 되어 있는 부분은 각 각 섹터의 크기와 클러스터의 크기를 나타낸다. 만약 사용자가 그 값을 윈도우를 설치할 때 지정해주었다며 다를 수 있으므로 반드시 저 부분의 값도 확인을 해야 한다.

 그 다음 확인해야 할 중요한 사항은 바로 0x30에 위치한 Start Cluster for $MFT로 MFT의 첫 번째 Entry가 시작되는 클러스터의 번호를 담고 있다. 아래 예에선 MFT의 시작 위치가 C0000 Cluster임을 확인할 수가 있다. 따라서 해당 오프셋은 클러스터의 크기인 8 섹터와 섹터의 크기 512Bytes를 곱해주면 된다. 따라서 0xC0000000이 해당 오프셋이라는 것을 알 수가 있다.

그림 14. Start Cluster for $MFT

  해당 오프셋으로 이동하면 MFT의 Signature인 'FILE' 문자열을 확인할 수가 있다. 따라서 올바르게 값을 해석했다는 것을 알 수가 있다.

그림 15. $MFT Signature

3.2 VBR – Python

  그렇다면 Python을 통해서 VBR을 접근해보자. 그 뒤 필요한 항목을 어떻게 설정해야 하는지 확인해보자. 우선 '논리 디스크' C:를 위 그림 6에서의 방법과 동일하게 열어보자.

그림 16. Python – open C:

  여기서부턴 해당 디스크를 Bytearray를 통해서 읽을 것이다. 아까와 같이 올바르게 NTFS 문자열이 출력되는 것을 확인할 수가 있다. 이에 더해 한 가지 함수를 먼저 만들어보자. 만들고자 하는 함수는 Little Endian으로 되어있는 16진수 값을 10진수로 읽어 값을 반환해주는 함수로 이후에 계속 사용될 것이다.

그림 17. Python – LtoI()

  VBR에서 우리가 알아야 할 값은 총 3개이다. 섹터의 크기, 클러스터의 크기, 그리고 마지막으로 MFT Entry의 시작위치이다. 이 3개를 알아야 이후에 MFT에 대하여 Python을 통해 분석을 올바르게 할 수가 있다.

  섹터의 크기는 VBR에서 0x0B~0x0C에 위치해 있으며, 클러스터의 크기는 0x0D에 있는 것을 BPB구조에서 확인할 수가 있었고 MFT는 0x30에 해당 클러스터의 값이 있다. 이제 이를 Python으로 입력해보자.

그림 18. Python – Sector

  위의 그림과 같이 섹터의 크기는 512 Bytes(0x200)이며 클러스터의 크기는 8 섹터(4KB)임을 알 수가 있다. 이제 이 값을 가지고 MFT의 위치를 알맞게 해석할 수 있다. 아래의 그림을 보자.

그림 19. Python – MFT Offset

  MFT의 첫 번째 Entry의 Offset이 0xC0000000임을 Python을 통해 해석할 수가 있었다. 이제 VBR에서 우리가 더 확인해야 할 항목은 없으므로 이제 MFT에 대하여 학습해보자.

4. MFT

  VBR을 통해 MFT의 위치를 찾을 수가 있었다. MFR는 Master File Table의 약자로 NTFS에선 파일이나 디렉터리, 메타 정보들을 모두 파일의 형태로 관리하고 있다. 이러한 각 파일들의 위치나 속성, 이름, 크기 등의 메타 정보가 MFT Entry에 저장된다.

  따라서 이러한 많은 정보들이 저장된 MFT를 통해 Forensic 조사에 있어서도 많은 유용한 정보들을 제공한다. 그렇기에 MFT에 대하여 이해 한다는 것은 많은 이점을 갖게 되는 것과 같다. MFT가 갖는 각 Entry에 대한 설명은 아래와 같다.

그림 20. MFT Entry 정보

  많은 유용한 Entry들이 존재하지만, 모두 다루기엔 많은 분량이 나오므로 이 문서는 $MFT에 한정하여 설명할 것이며 추가적으로 필요한 내용에 한해서만 다룰 것이다. MFT Entry의 구조는 아래의 그림과 같다.

그림 21. MFT Entry 구조

    MFT Entry 헤더가 오고 그 다음 Fixup Array가 나온다. 그 다음 가장 중요한 속성이 나오고 End Marker와 함께 뒤 부분은 사용되지 않는다. 이에 대하여 알아보자.

4.1 MFT Entry Header

  MFT Entry 헤더는 Signature('FILE')로 시작하여 많은 정보들을 담고 있다. 이 문서는 MFT 수집 툴을 만드는 것이 목적이므로 많은 내용은 다루지 않을 것이다. 전체적인 구조는 아래의 그림과 같다.

그림 22. MFT Entry Header 구조

  여기서 우리가 알아야 할 항목은 0x14에 위치한 'Offset to File Attribute' 항목이다. 이 항목은 속성이 시작하는 위치를 나타내주는 값으로 MFT 수집 툴을 만들기 위해선 이러한 속성 중 $DATA에 접근하여야 한다. 이에 대해선 좀 더 뒤에서 다룰 것이다.

그림 23. HxD - MFT Entry Header

  위의 그림과 같이 0x14에 있는 값이 현재 0x38로 나타나는 것을 확인할 수 있다. 이는 0x38의 위치부터 속성이 시작된다는 것으로 그림에선 0x10이 존재하고 있다. 이는 $STANDARD_INFORMATION(이후 $SIA라 하자.)의 속성 ID 값으로 4.6에서 알아보자.

4.2 MFT Entry – Python

  MFT Entry 헤더의 구조에 대하여 알아보았다. 이제 이를 Python을 통해 접근하는 방법에 대하여 살펴보자. 우선 우리는 그림 19에서와 같이 VBR을 통해 MFT의 첫 번째 Entry 주소를 알 수가 있었다. 이제 이를 통해 포인터를 이동시켜보자.

그림 24. Seek(MFT_Offset)

  Seek()함수를 통해 파일을 읽을 위치를 이동 시킬 수가 있다. 우리는 현재 MFT Entry 정보를 읽을 것이므로 이전에 선언했던 mft_off 또는 그 위치 값인 0xc0000000으로 이동을 한 후 해당 부분을 512 Bytes 읽은 것이다.

그림 25. Attribute Offset

  512 Byte를 읽은 다음 속성이 위치한 곳의 주소를 얻기 위하여 mft_attribute_off를 선언해주고 0x14-0x15의 값을 읽는다. 또 MFT Entry의 크기를 확인하므로 속성의 시작과 끝을 알 수가 있고, 이러한 속성의 데이터를 attr_off로 지정해놓은 것이다.

  이제 속성의 시작 위치를 알 수가 있으므로 우리는 $DATA를 찾아야 한다. 이를 찾기 위해선 각 속성의 식별 값을 확인을 할 것이며 만약 $DATA의 식별 값인 0x80이 아니라면 해당 속성의 크기를 통해 다음 속성으로 넘어 갈 수가 있다.

그림 26. Find $DATA

  여기서 3번째 라인을 보면 속성 값이 아닌0x0000(NULL)이나 0xFFFF(EndMarker)가 읽히면 해당 루프를 빠져 나오는 것을 확인할 수가 있다. 속성 식별 값이 0x80이 아니라면 해당 속성의 size를 구해 그 만큼을 건너 띄는 것을 아래의 2줄을 통해 확인할 수가 있다. 만약 0x80($DATA)이라면 아직 지정하지 않은 Data_parse()라는 함수를 호출해 $DATA 속성을 분석할 것이다. 이에 대해선 속성에 대하여 알아본 뒤에 다시 해보자.

4.3 Attributes

  하나의 MFT Entry는 여러 개의 속성을 포함하고 있다. 이러한 속성엔 각 항목에 따라 유용한 정보들을 가지고 있으므로 이를 해석할 수 있어야 한다. 이러한 속성에 대한 설명은 아래의 그림과 같다.

그림 27. 속성 정보

  많은 속성 항목들이 있지만 모두가 중요한 것은 아니다. 크게 가장 많이 사용되는 항목은 $SIA와 $FILE_NAME(이후 $FN), 그리고 $DATA 항목이다. 우선 이러한 속성의 공통적인 구조 먼저 알아보자.

그림 28. 공통 속성 헤더

  속성의 구조는 거주 속성과 비거주 속성으로 나뉘어 지는데, 이에 대해 알기 전에 공통적을 포함되는 공통 속성 헤더에 대하여 알아보자. 구조는 위의 그림 25와 같이 되어 있다. 공통 속성헤더를 통해 어떠한 속성타입인지, 해당 속성의 길이가 얼마나 되는지, 만약 속성이 이름을 갖는다면 그 이름이 무엇인지 등이 있다. 여기서 속성 이름이란 $SIA나 파일 이름이 아닌, 속성 자체에 부여되는 이름을 뜻하는 것이다. 이러한 공통 속성 헤더 다음엔 거주 속성, 비거주 속성인지에 따라 다른 구조를 갖는다.

4.4 거주 속성 (Resident Attribute)

  거주 속성은 해당 속성의 내용이 크지 않기에 MFT Entry 구조에 모두 담을 수 있을 때의 갖는 상태이다. 속성 내용을 모두 담을 수 있기에 다른 곳을 보지 않아도 되며, 그 내용은 거주 속성 헤더 뒤에 나타난다. 이러한 거주 속성의 구조는 아래의 그림과 같다.

그림 29. 거주 속성 헤더

  속성 내용의 크기와 속성 내용의 위치, 인덱스 플래그, 마지막으로 속성의 이름이 있다면 그 속성의 이름이 나오며 없을 경우 바로 속성 내용이 나온다. 아래의 그림은 $MFT의 속성 부분을 나타낸 것이다.

그림 30. HxD - 거주 속성

  공통 속성 헤더를 제외하고 0x48부터 거주 속성 헤더가 존재하는 것을 확인할 수가 있으며 해당 속성은 이름이 존재하지 않기 때문에 바로 뒤에 속성내용이 따라오는 것을 확인할 수가 있다. 이렇게 거주 속성의 구조에 대하여 확인할 수가 있으며, 이러한 거주 속성은 대부분의 $SIA와 $FN에서 나타난다.

4.5 비거주 속성 (Non-Resident Attribute)

  속성 내용이 너무 커진다면 그것을 한곳에 모두 담을 수가 없다. 이러한 상태가 바로 비거주 상태라 하게 되며 이 경우 별도의 클러스터를 할당하여 그 곳에 내용을 담아 놓는다. 아래의 그림을 통해 구조를 확인해보자.

그림 31. 비거주 속성 구조

  공통 속성 헤더가 나온 뒤 VCN이나 런리스트, 속성 내용의 크기, 속성 이름과 속성내용 등 관련된 내용들이 기록되어 있다. 이 항목들 중 자세히 알아볼 내용은 런리스트에 관한 내용이다.

  비거주 속성은 속성 내용이 크기 때문에 외부 클러스터에 해당 내용들을 담고 있다. 하지만 이러한 클러스터들이 모두 연속적으로 존재할 수는 없기에 이러한 클러스터들에 대한 정보를 담고 있는 런리스트가 필요하다. 즉, 런리스트는 속성 내용을 담은 클러스터가 어디에 위치하였는지를 알려주기 위한 것이라 할 수 있다.

그림 32. Run List

  런리스트를 해석하는 방법의 위의 그림과 같다. 첫 바이트를 읽어 일의 자리 수와 십의 자리수로 나눈다. 그 다음 일의 자리 수만큼 뒤의 바이트를 읽고 이것이 해당 클러스터의 길이가 된다. 십의 자리 수만큼 바이트를 이어 읽으면 해당 클러스터의 위치 값을 알 수가 있다. 이해하기 쉽게 직접 해석해보자.

그림 33. Run List

  위의 그림은 내 PC의 MFT Entry 중 비거주 속성의 런리스트를 나타낸 부분이다. 검은색 동그라미가 첫 바이트이며, 붉은 색은 런의 길이, 파란 색은 런의 위치를 나타내기 위해 표시해놓은 것이다.

  첫 번째 런의 첫 바이트는 '33'이다. 이를 십의 자리와 일의 자리로 나누면 십의 자리는 각 각 '3'이 된다. 따라서 둘 다 3바이트씩 읽은 것이다. 이를 해석하면 C00000 클러스터에서부터 C820개의 클러스터가 할당되어 있음을 나타내는 것이다.

  두 번째 런은 앞과 유사하므로 생략하고 세 번째 런을 보자. 십의 자리가 '4' 일의 자리가 '2'임을 알 수가 있다. 따라서 런 길이는 2바이트를 읽어 0x308이며 런 위치는 4바이트를 읽어 124727B 클러스터이다. 이렇게 런리스트를 해석하면 비연속적으로 저장된 데이터를 올바르게 찾아갈 수가 있다.

  이를 찾아갈 때 고려해야 할 것은 2번째 런부턴 앞의 이전의 런위치를 더해야 한다는 것이다. 2번째 런을 예로 들면 런 위치가 57E23D 번째 클러스터에 있음을 알 수가 있는데, 정작 57E23D 클러스터를 확인해보면 올바르지 않게 되어 있다. 올바르게 찾아가기 위해선 57E23D에 C0000을 더해야 한다. 따라서 63E23D 클러스터에 올바른 속성 내용이 위치하고 있다는 것이다.

  이러한 비거주 속성은 보통 파일의 크기가700Bytes 보다 더 클 경우에 속하게 되며 이보다 작을 경우엔 거주 속성이 된다. 주로 $DATA의 경우 비거주 속성을 띄는 경우가 많으며 우리가 목적으로 하는 $MFT 또한 이러한 비거주 상태에 속하므로 클러스터 런을 올바르게 해석할 수 있어야 한다

4.6 Attribute - $SIA, $FN, $DATA

$STANDARD_INFORMATION

  $SIA는 $FN과 같이 모든 MFT Entry에 기본적으로 포함되는 속성으로 파일의 시간 정보와 파일에 대한 정보 등이 기록되어 있다. 전체적인 구조는 아래와 같다.

그림 34. $SIA 구조

$FILE_NAME

  $FN은 해당 MFT Entry가 가리키고 있는 파일에 대한 이름을 포함하여 $SIA에도 있었던 시간 정보들이 존재한다. 하지만 $SIA의 시간정보에 비해 상대적을 변경 되는 경우가 적다. 이에 대해선 나중에 더 자세히 학습하자. $FN의 구조는 아래와 같다.

그림 35. $FN 구조

$DATA

  마지막으로 알아볼 $DATA 속성에 대해선 조금 더 자세히 알아보자. 위의 두 가지 항목은 파일에 대한 정보를 나타내는 것이었다면 $DATA는 해당 파일의 실제 내용으로 앞의 두 개와 마찬가지로 중요한 속성이다. 우선 구조를 먼저 살펴보자.

그림 36. $DATA 구조

  구조가 상대적으로 매우 단조로워 보인다. 만약 $DATA 속성의 크기가 작다면 속성 헤더(공통헤더와 거주속성헤더) 뒤에 바로 속성 내용이 나오게 된다. 하지만 만약 속성의 크기가 커지면 비거주 상태가 되어 위에서 살펴본 바와 같이 클러스터 런을 통해 속성 내용을 관리한다.

 만약 $DATA 속성이 2개라면 어떻게 될까? 이것이 바로 ADS다. 기존의 메인 스트림 외에 대체 스트림이 하나 더 주어지는 것으로 이 경우 반드시 속성 이름이 주어진다. 이를 통해 추후에 $UsnJrnl:$J를 분석할 때 참고할 수가 있을 것이다.

  이번 문서의 목적은 Python을 통해 $MFT를 수집하는 것이므로 일반적으로 크기가 큰 $MFT가 많기 때문에 대부분 비거주 상태에 있다. 따라서 이러한 $DATA의 클러스터 런을 잘 해석할 수가 있어야 할 것이다.

4.7 $DATA - Python

  올바르게 속성 식별 값 0x80($DATA)를 찾았다면 이제 해당 부분을 분석하여 정보를 추출을 위한 정보를 알아내야 한다. 우선 Runlist의 위치와 해당 버퍼를 담아보자. 아래의 그림에서와 같이 $DATA의 구조를 읽어 런리스트의 위치와 런리스트부터의 버퍼를 담고 있는 것을 확인할 수가 있다.

그림 37. $DATA 분석 – Python

  $MFT의 $DATA 속성의 경우 비거주 속성을 가질 수 밖에 없다. $MFT가 700바이트 이하의 크기를 갖기는 많이 어렵기 때문이다. 런리스트를 반복문을 통해 분석하기 전에 필요한 변수들을 먼저 선언해주자.

그림 38. 변수 선언

  Count와 tmp, calc, add_offset 등은 반복문에서 대부분 첫 번째 런을 위하여 존재하는 것이며 clu_size와 clu_off, tmp_size와 tmp_offset은 런을 해석한 결과를 담기 위해 미리 리스트(배열)을 선언해놓은 것이다. 이제 반복문을 통해 분석을 진행해보자.

그림 39. 반복문 – 분석

  2번째와 3번째 라인은 이전에 선언해놓은 tmp='00'을 십의 자리와 일의 자리로 나누어 계산을 진행하는 것으로 이후에 tmp가 런의 첫 바이트를 읽어 다시금 자리 수를 나누기 위함이다.

  6번째 라인이 런의 첫 바이트틑 읽는 것으로 이후에 clu_size와 clu_off를 위해 몇 바이트씩 읽어야 하는지 나타내기 위해 존재한다. 그 후 tmp_들로 인하여 해당 바이트의 값을 읽고 있는 것이다. 그리고 add_offset을 통해 4.5에서 살펴본 것과 같이 클러스터 런의 오프셋을 더하기 위한 부분이다. 이렇게 반복문이 0x00을 만나 빠져나오면 tmp_에 담겨있는 값을 다시 정리하여야 한다. 이를 위한 코드는 아래와 같다.

그림 40. Tmp 정리

  이전에 tmp에 담겨있는 것을 정리하기 위해 각각 size와 offset을 선언해준다. 그 후 반복문을 통해 클러스터 단위가 아닌 바이트 단위로 나타내기 위하여 tmp의 값에 초반에 구했던 sec과 clu를 곱해준다.

  이렇게 얻어진 값을 통해 기록하고자 하는 파일을 연다. Seek() 함수를 통해 해당 클러스터의 오프셋으로 이동해 사이즈만큼 읽고 이를 기록한다. 이렇게 런의 수만큼 반복이 된다. 최종적으로 완성된 코드를 실행하면 결과는 아래의 그림과 같다.

그림 41. 실행 결과

5. 정리

간단하게 $MFT 수집 도구를 만들고 싶었지만, $MFT를 수집하기 위해선 결코 간단한 지식을 가지고는 수집할 수 없겠다는 것을 여러 번 느끼는 계기가 되었다. 이해했다고 생각했던 것들이 코드를 통해 직접 해보려 하니 낯설기도 하고 더 어렵게 느껴지기도 하였다.

그래도 직접 NTFS를 공부하면서 만들어보고자 했고, 결국 만들었음에 매우 흡족하다. 이후엔 $LogFile과 $Usnjrnl:$J까지 한번에 수집해주는 도구를 제작해보고자 한다. 이를 위해선 더 많은 것을 공부해야겠지만 분명 재미있는 공부가 될 것이라 생각한다.

참고 자료

해킹대회문제로 배우는 파일시스템.pdf

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

cappleblog.co.kr/40; MBR 구조

cappleblog.co.kr/590; MBR 해석

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

forensic-proof.com/archives/357

forensic-proof.com/archives/431

http://home.sogang.ac.kr/sites/gsinfotech/study/study1702/Lists/b10/Attachments/17/20131212_%EC%B9%A8%ED%95%B4%EC%8B%9C%EC%8A%A4%ED%85%9C%EB%B6%84%EC%84%9D.pdf

http://ntfs.com/ntfs-partition-boot-sector.htm

(FP) NTFS.pdf

forensic-proof.com/archives/584

개요

컴퓨터를 살 때 많이 고민하는 사항 중 하나가 데스크탑을 살지, 노트북을 살지에 대하여 많은 고민들을 하기도 한다. 이번 포스팅은 필자도 노트북을 쓰는 입장이므로 이에 대해 지식을 함양시키고자 직접 해보았다. 상황은 아래와 같다.

- 기존에 쓰던 노트북이 어떠한 이유에서인지 부팅이 되지 않는다.

- 고치러 가기엔 디스크에서 특정 파일을 빨리 사용해야 한다.

이러한 상황에 있을 때 혹은 유사한 사항에 있을 때 할 수 있는 방법에 대하여 알아보자. 준비물이 몇 가지 필요하다.

준비물 : 대상 노트북, 외장하드, 복구 또는 추출을 하기 위한 정상적인 PC

실습

 필자는 아래와 같이 준비하였다. 노트북은 LG의 XNOTE를 준비하였으며 우측의 외장하드는 엠지텍의 MG25-TERRAN2+COUP을 준비하였다. 외장하드가 필요한 이유는 노트북의 하드 디스크와 크기가 같기에 이를 통해서 연결할 수기 때문이다. 준비된 장치들을 이제 분해하여 보자.

 위와 같이 우선 분석 또는 복구를 하고자 하는 노트북의 하드를 먼저 분리 한다. 그리고 아래의 좌측 그림과 같이 외장하드도 분리를 해준다. 여기서 두 하드의 크기가 얼추 맞는지 확인을 간단하게 해준다. 만약 크기가 다를 경우 해당 단자에 꽂히나 한번 해보고 안된다면 해당 포스팅에선 능력 밖이므로 다른 문서를 찾아보자.

 아래 좌측의 그림은 엠지텍의 하드를 빼낸 후 남은 본체의 모습이다. 이제 이 곳에 노트북의 하드(TOSHIBA)를 꽂자. 꽂을 때 너무 과하게 힘은 주지 말자 괜히 멀쩡하던 곳도 손상될 수가 있으므로 조심하자. 연결 한 후의 모습은 원래 외장하드를 열었을 때의 모습과 다를 바가 없다.

 이렇게 조립한 외장하드를 이제 외장하드의 USB 단자를 통해 분석 또는 복구를 하고자 하는 PC에 연결해보자. 필자는 노트북이 2대이므로 정상적인 노트북 LG그램에 연결을 진행하였다.

 우선 연결이 잘 되었는지 해당 디스크 F:가 생성되는 것을 아래의 그림과 같이 확인할 수가 있었다. 또한 우측의 그림을 통해서 기존의 Disk 0 이 아닌 새로운 Disk 1이 생성된 것을 확인할 수가 있다. 만약 정상적으로 장치 인식이 되지 않는다면 연결 단자나 하드를 조립할 때 제대로 하였는지 다시 한번 확인해보자.

연결된 하드를 HxD나 WinHex, FTK Imager 등을 통해 다양한 작업을 할 수도 있으며 실제 외장하드와 같이 디렉터리 안으로 들어가 파일을 가져올 수도 있다. 이러한 방법이 언젠가는 쓸모가 있을 것 같기에 이렇게 포스팅을 해보았다.

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에 접근을 하지 못하게 하는 등 제약이 필요합니다.