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

prefetch_parser.exe

1. 개요

1.1 동기

Prefetch 분석 도구를 제작하고자 현재 프리패치와 관련된 툴로 WinPrefetchView를 사용하고 있지만 불편한 점을 느꼈다. 실행 시 프리패치 파일에 대하여 상세히 분석을 해주지만 현재 실행시킨 시스템에서의 파일만 분석을 한다는 것이다.

Figure 1. WinPrefetchView

그렇기에 다른 PC의 프리패치 파일을 분석하기 위해선 그 해당 PC에서 실행을 하거나 해야한다. 하지만 모든 상황에서 실행이 가능한 것은 아니기 때문에 최대한 흔적을 적게 남기는 것을 목표로 하고자 한번 만들게 되었다.

1.2 구상

우선 어떻게 만들지 구상을 해보았다. 여러 가지 고려 해야 할 사항은 매우 많지만 가장 크게 뽑는 다면 다음과 같다.

• 제작에 사용할 프로그래밍 언어 - Python
• 윈도우 버전 – Win10의 경우 압축이 되어있음
• GUI vs CLI – 흔적을 최소화 하기 위하여 CLI

이와 같이 3가지 사항에 대하여 크게 고민을 하였다. 프로그래밍 언어의 경우 다룰 수 있는 것이 파이썬 밖에 없었기에 결정하는데 큰 고민이 없었지만 윈도우 버전의 경우 압축 해제 과정이 들어가야 하기에 어느 버전으로 할 것 인지 고민했다.

하지만 WinPrefetchView에서는 두 가지 모두 지원을 하고 있었다. 그러므로 하나로 통합은 힘들 테니 각 버전에 맞는 2개를 만들어보자 라는 생각을 하게 되었다.

GUI의 경우 사용에 있어 편의성을 향상 시키겠지만, 우선 내가 아직 GUI를 한번도 만들어보지 않았다는 점이 크게 작용하여 결국 CLI로 택하였다.

1.3 전체적인 흐름

어떻게 프로그래밍을 해야 할까 고민을 해보았다. 어떻게 동작을 해야 하나 고민을 하고 다음과 같이 생각하였다.

1. 우선 파일을 읽어야 한다. f=open('.pf','rb'). 그렇다면 이 파일은 어떻게 지정할 것인가?
2. sys라이브러리를 통해 인자로 받는 것이 별 힘이 안 들 것 같음
3. 읽은 파일이 압축 된 것일 경우 압축을 해제 – 압축 해제에는 다른 분의 소스를 사용
4. 해제된 데이터를 읽어 .pf파일의 포맷에 맞게 읽음
5. 이름, 사이즈, 마지막 실행시간, pf파일생성시간, pf파일 수정시간, 런카운트, 실행에 포함되는 파일의 이름들
6. 5의 사항들을 출력

이렇게 전체적인 흐름을 생각하였고 이에 맞추어 코드를 하나하나 타이핑 하였고, 하면서도 많은 부분 분노와 슬픔이 있었다.

2 코드 쓰기

2.1 경로 인자 받기 & 압축 해제

우선 파일의 경로를 인자로 받아야 한다. Sys 모듈을 사용하고 인자로 받은 pf파일이 있는 경로에서 .pf 확장자를 찾아 선별하여야 한다.

Figure 2. 인자받기 & PF확장자 찾기

위의 코드와 같이 첫 번째 줄에서 sys.argv[1]로 인자를 받는다. 그리고 그 해당 경로에서 .pf 확장자를 갖는 file을 찾는 코드이다.

이제 인자로 받은 파일이 XPRESS 압축이 되어 있는 경우 압축을 해제하여야 한다. 이는 francesco.picasso@gmail.com 분의 소스를 가져왔으며 원래는 인자로 2개를 받아 input file과 output file을 지정해주어야 하지만, 이를 수정하여 output을 파일이 아니라 bytearray의 형태로 압축 해제된 데이터를 반환하도록 하였다.

Figure 3. XPRESS 압축해제

2.2 Pf 파일 이름 읽기

이제 윈도우 10의 경우에도 압축이 해제된 데이터를 가질 수가 있다. 그러므로 포맷에 맞게 간단히 데이터를 읽기만 하면 되는 줄 알았다. F.read()의 데이터를 buf라 했을 때 Pf 파일의 이름은 buf[16:49]이다. 그대로 읽기만 하면 되는데 문제가 생겼다. 아래의 그림을 보자.

Figure 4. NULL이 포함된 이름

파일의 이름이 Unicode의 형태처럼 2바이트씩 쓰여 있는 것을 알 수가 있다. 따라서 이를 그냥 출력하면 'M E L O N . E X E'와 같이 출력이 된다. 그냥 써도 별 문제는 없겠지만 나중에 해당 파일의 이름을 복붙하는 과정에 있어 저 공백 부분을 매번 지우기가 귀찮을 것 같아 공백 없이 출력되도록 하였다.

Figure 5. NULL 없애기

함수의 인자로 buf[16:49]와 같이 주면 buf[16]부터 buf[49]까지 하나 하나 읽으며 \x00을 buf배열에서 제거한다. 그리고 \x00이 제거된 부분만 반환을 하는 부분이다.

Figure 6. 출력된 파일 이름

이렇게 성공적으로 이름이 출력되는 것을 위의 그림과 같이 확인할 수가 있다. 이제 뭔가 쉽게 잘 풀리는 것 같아서 좋다.

2.3 파일 사이즈 출력

파일 사이즈도 출력을 해보자. 파일의 사이즈는 아래의 그림과 같이 12:15에 존재하고 있다. 이 부분을 10진수로 읽어 출력을 하면 된다.

Figure 7. 파일 사이즈

16진수를 10진수로 나타내기 위해서는 해당 부분을 읽은 다음에 10진수로 변환하여 출력을 해주어야 한다. 하지만 %d로 출력을 바로 하면 아래와 같은 결과를 볼 수가 있다.

Figure 8. 파일 사이즈 출력 오류

Bytearray형식으로 읽었기 때문에 %d의 형식으로 출력을 할 수가 없다는 것이다. 그렇다면 %s로 출력을 하면 어떨까?

Figure 9. 파일 사이즈 출력 오류

위의 그림과 같이 이상하게 출력되는 것을 확인할 수가 있다. 그렇다면 어떻게 해야 할까 고민을 하던 중 아는 분이 mft와 관련하여 분석하는 Python 코드를 보았는데 리틀엔디언을 십진수로 출력해주는 코드가 있기에 가져왔다.

Figure 10. LittleEndianToInt

이 함수를 통하여 리틀엔디언으로 나타난 부분을 바로 10진수로 출력해주는 것을 확인할 수가 있다. 참 편리한 부분이다.

Figure 11. 파일 사이즈 출력

원하는 바와 같이 204910이 제대로 출력되는 것을 확인할 수가 있다. 이렇게 파일의 이름과 사이즈의 출력에 성공하였다.

2.4 마지막 실행 시간 출력

포렌식 툴인 만큼 가장 중요한 부분은 바로 시간과 관련된 부분이다. 0x80~0x88까지의 부분이 프리패치 파일이 마지막으로 실행된 시간(Last Run Time)이다.

Figure 12. 마지막 실행시간 위치

시간과 관련하여 꽤 시간을 소모하였다. 시간을 출력하는데 datetime 모듈을 사용하였으며 필요한 코드는 아래의 그림과 같다.

Figure 13. 시간 변환 함수

우선 리틀엔디언을 빅엔디언 10진수로 변환해주고 그 다음 time_convert라 써있는 부분의 함수를 호출하여 알맞은 형태로 출력되게 하고자 하였다. 여기서 애를 먹은 부분은 3번째와 5번째라인이다. 우선 5번째 라인의 마지막 timedelta에 hours=9를 해주므로 한국 기준 시간인 UTC 9:00을 맞출 수 있었다. 만약 저 부분을 쓰지 않는다면 한국 시간과 9시간 차이가 나는 값을 얻게 된다.

Figure 14. 시간 출력 오류

3번째 라인의 경우 쓰지 않을 경우 위와 같이 에러가 출력이 되는데, 3번째 라인을 써주므로 문자열의 형태로 만든 다음 원하는 결과를 제대로 나타낼 수 있게 해주므로 나의 코드에서는 반드시 써주어야 했다.

Figure 15. 시간 출력 성공

위의 과정들을 통하여 코드를 완성하였다. 그리고 위와 같이 올바른 값을 출력하도록 할 수 있었다.

2.5 pf파일 생성시간 & 수정시간 출력

생성시간과 수정시간의 경우 실행한 원래의 파일에 대한 것이 아니라 프리패치 파일이 생성된 시간과 수정된 시간에 관하여 출력을 나타낸다.

Figure 16. 생성시간 & 수정시간

이 둘은 datetime 모듈과 os.path의 getctime과 getmtime을 통하여 쉽게 얻을 수가 있었다. 이에 대한 출력 결과는 아래와 같다.

Figure 17. 생성시간 & 수정시간 출력 성공

2.6 실행 횟수 출력

프리패치 파일에는 해당 파일을 몇 번 실행했는지 또한 나타나있다. 이는 pf 파일의 0xD0에서 0xD3까지에 위치해 있다.

Figure 18. Run Count 위치

이 경우도 2.3에서 파일의 사이즈 출력과 비슷한 작업을 거쳐 출력을 해주면 된다. 우선 리틀 엔디언의 형태로 되어있으므로 빅엔디언으로 변환하고 10진수로 출력을 해주면 된다. 여기선 위와 같이 LittleEndianToInt 함수를 사용하였다.

Figure 19. Run Count 출력 성공

2.7 포함되는 파일 목록

프리패치 파일에는 해당 프로그램이 실행 될 때 로드하는 파일에 대하여 목록을 가지고 있다. 이러한 파일의 목록은 분석을 하는 입장에서도 중요한데, 만약 잘못된 위치에서 의심스러운 파일이 로드 되는 등의 행위는 분석에 있어 시간을 단축할 수 있게 해주는 중요한 단서가 된다.

Figure 20. 파일 목록 & 크기

0x64~0x68까지는 로드되는 파일의 이름이 있는 위치를 나타내며 0x68~0x6C는 파일 목록이 저장된 위치의 크기를 나타내어 준다. 따라서 offset은 0x64~0x68이며 size는 0x68~0x6C이므로 로드된 파일의 목록이 나타나는 마지막 위치는 offset+size이 된다.

Figure 21. 로드된 파일 목록 함수

우선 file list의 offset을 0x64에서 확인을 해주고 size는 0x68에서 확인을 해준다. 그리고 이를 통해 마지막 위치를 알 수가 있으니 해당 부분을 읽으면 된다. 하지만 여기서 아래의 그림을 확인하자.

Figure 22. 유니코드와 NULL 구분

표시한 부분이 바로 로드된 파일의 나누는 기준이 된다. 전체적으로 유니코드로 나타나기에 \x00\x00을 통해 파일을 나누어야 한다. 그렇기에 위의 코드에서 Unicode_split를 추가한 것이다.

이렇게 \x00\x00을 통해 각 파일들을 나눌 수가 있다. 하지만 유니코드의 형태를 그대로 읽었기에 출력을 할 경우 "V O L U M E . . ."처럼 2.2에서 파일의 이름에 공백이 추가되어있듯이 나타난다. 하지만 이번에는 bytearray의 형태가 아니라 문자열의 형태로 파일의 목록을 읽었기 때문에 다른 방식으로 접근해야 했다.

Figure 23. 로드된 파일 목록 공백 제거

"V.O.L.U.M.E …"와 같이 파일 경로를 하나 하나 인자로 remove_uni_null 함수에 주게 되면 임시로 만든 tmp배열에 \x00이 아닌 경우에만 추가된다. 그러므로 \x00은 자연히 떨어져 나가게 되며 이렇게 만들어진 새로운 tmp 배열은 join(tmp)를 통해 일반적인 문자열과 같이 출력되는 결과를 확인할 수가 있다.

Figure 24. 출력 결과

이렇게 전체적인 내용을 모두 완성하였으며 출력 결과 또한 만족스럽다.

3. 후기

일단 원하는 내용의 프로그램은 만들었기에 매우 뿌듯하다. 하지만 다 만들면서 또는 만든 후에 느끼는 점이 매우 많은데 이에 대해 정리하면 다음과 같다.

첫째, 확실히 프로그래밍은 많이 해보아야 하는 것 같다. 전체적인 구성을 하는 것보다는 유니코드에 포함된 NULL을 제거하거나 리틀엔디언을 10진수로 출력하거나 시간을 변환하고자 하는데 해당 형식은 안된다는 등의 오류를 해결하는데 오히려 훨씬 더 많은 시간을 지체하였다. 결국 오랜 시간 끝에 하나하나 해결을 하였기에 이와 유사한 프로그램을 만들 때에는 내가 만든 소스를 보므로 시간을 훨씬 단축할 수 있을 것 같다.

둘째, 원하는 내용을 만들었지만 아쉬운 점이 많이 느껴진다. 예를 들어 CLI의 형태이므로 어떠한 컬럼을 기준으로 정렬을 할 수 없다는 점이 가장 크다. 내가 만든 프로그램의 경우 지정된 폴더에 이름 순서에 따라 나타나는 정도이기에 다소 불편함이 있기는 하다.

셋째, 전체적으로 코드에 대한 이해가 부족한 느낌이 크다. 왜 굳이 bytearray를 사용했는지, 왜 bytearray는 변환이 되고 str은 안되는지 등에 대하여 자세한 이유를 모른다는 점에서 부족함을 많이 느꼈다.

넷째, 부족한 프로그램이지만 내가 만든 프로그램은 내가 애정을 가져야 하는 것 같다. 다른 사람이 더 잘 만들 수 있지만, 만들면서 많은 고민을 했다는 것 자체만으로도 큰 도움이 되는 것 같다.

참고

http://www.forensicswiki.org/wiki/Windows_Prefetch_File_Format   프리패치 파일 포맷

http://devanix.tistory.com/306  datetime 모듈

http://tt-share.blogspot.kr/2015/05/python_35.html    파일 mac 시간 구하기

https://gist.github.com/dfirfpi/113ff71274a97b489dfd#file-w10pfdecomp-py   XPRESS 압축 해제

https://gist.github.com/craSH/393155/19cb41b9f536593cb16a978af8ebeb00ffae500f 프리패치 해시 값

http://www.forensicfocus.com/Forums/viewtopic/p=6542386/#6542386

4. 첨부

완성된 코드

압축해제에 참고한 코드

Prefetch File

프리패치는 부팅할 때나 응용프로그램을 실행할 때 속도를 높이기 위해 사용한다. 윈도우에서 메모리를 효율적으로 관리하기 위한 한 방법이기도 하다. 실행파일이 사용하는 시스템 자원을 프리패치 파일에 저장해두고 부팅, 응용프로그램 실행시 미리 저장된 정보를 메모리에서 실행하여 속도를 향상시킨다. 부팅시에는 120동안 모니터링하고, 응용프로그램 시작시에는 10초를 모니터링 한 후, 모니터링한 정보로 프리패치 파일을 생성한다. 경로는 %Systemroot%Prefetch 에 저장이 된다.

응용프로그램의 경우 프리패치 파일이 남기 위해서는 10초간 메모리에 올라가있어야한다는 말이며, 개수에 있어서도 제한이 있는데 128개의 프리패치를 갖으며, 이 개수를 초과할 경우 오래된 프리패치 파일부터 삭제가 되어 새로운 pf 파일이 형성이 된다.

Windows 10 

프리패치 파일에 공부를 하기 위하여 자료를 찾던 중 Prefetch Format을 내 PC에서 확인하기 위하여 파일을 HxD로 확인하였을 때 많이 당황하게 되었다. SCCA 시그니쳐가 보여야하는데 보이지 않고 이상한 MAM 시그니쳐만 확인이 되었다.

이에 대하여 알아보니 이전에는 바로 내용들이 보였지만 최근의 운영체제에선 압축을 하여 바로 원하는 문자열들을 확인할 수가 없다. 하지만 간단한 툴들이나 코드를 이용해 바로 확인이 가능하도록 할 수가 있다.

아래는 Python으로 Decompree 한 상태이다. 이제서야 본격적인 공부를 시작할 수가 있다. 이를 해제하기 위한 Python 코드는 블로그에 올렸으니 확인을 한 후 어떤 코드가 사용되었는지 한번 보는 것이 좋다. 참고로 GrtHub에서 퍼온 것이다.             http://kali-km.tistory.com/entry/XPRESS-Decompress-by-Python

*winprefetchview를 통하여 확인할 경우 위와 같은 디컴프레스 과정이 필요없이 바로 내용을 확인이 가능하다. 

Registry

프리패치에 대한 설정은 레지스트리를 통하여 변경할 수가 있다. 아래에 보면 EnablePrefetcher라는 키가 있는데 값이 0x3으로 설정되어있다. 이 값에 따라 사용하지 않거나 어플리케이션이나 부트 프리칭만을 사용하거나 둘다 사용하도록 설정 할 수가 있다.

기본값으로 0x3이 설정 되어있기 떄문에 별도의 수정을 하지 않는 이상 프리패치 파일들이 형성되며 이를 통하여 추가적인 분석이 가능하다.

외장 저장장치 사용흔적 확인

프리패치 파일에는 실행한 프로그램의 경로 또한 나타내어진다. 이를 통하여 해당 프로그램의 위치를 알 수가 있는데, 만약 프로그램이 USB에 담겨있던 프로그램이라면 이 또한 확인이 가능하다. 아래 사진에서와 같이 다른 프로그램들은 C:\로 시작하지만 이 경우에 있어선 독특하게 \VOLUME으로 시작하는것을 확인할 수가 있다. 이를 통해 우리는 외부저장장치에 있던 프로그램이 실행되었단 흔적을 찾을 수가 있다.

Format

운영체제에 따라 해당 오프셋의 위치가 다르긴 하지만 항목은 같다는 것을 알 수가 있다. 우선 첫 4바이트는 운영체제에 따른 Prefetch 버전을 나타내며 윈도우 XP의 경우 0x11이며 윈도우7의 경우 0x17등 버전은 아래의 표와 같다.

그 후SSCA 시그니처와 pf파일의 크기와 이름이 나오며 0x4C에 있는 4바이트의 값은 파일의 경로에 대한 MD5 해시값이다. 그리고 0x58의 위치에는 파일을 실행하기 위해서 메모리에 올라가야할 파일의 수를 나타내며 이 파일들의 목록은 0x64에서 가리키는 값의 오프셋에서 확인할 수가 있다. 그리고 0x6C에는 봄륨에 대한 정보 블록을 가리키는 오프셋이 나와 있다.

프리패치 파일을 통하여 확인할 수 있는 것들은 아래와 같이 정리해볼 수가 있다. 외장저장장치 사용흔적은 위에서 언급을 하였으니 확인을 할 수가 있다. 또한 SCCA 시그니처를 통해 파일 카빙을 할 수가 있으며, 삭제된 pf 파일이더라도 카빙이 가능하다. 악성코드의 흔적은 이름과 응용프로그램 실행 과정 등 종합적으로 고려하여 여부를 파악할 수가 있다.

추가

http://kali-km.tistory.com/entry/Windows-10-Prefetch-Parser  ; 윈도우 10 프리패치 분석 도구

참고

https://github.com/libyal/libscca/blob/master/documentation/Windows%20Prefetch%20File%20%28PF%29%20format.asciidoc

http://www.forensicswiki.org/wiki/Windows_Prefetch_File_Format

http://maj3sty.tistory.com/857

http://forensicswiki.org/wiki/Prefetch

http://blog.digital-forensics.it/2015/06/a-first-look-at-windows-10-prefetch.html

http://forensic-proof.com/wp-content/uploads/2013/07/FP-%ED%94%84%EB%A6%AC%EC%8A%88%ED%8D%BC-%ED%8C%A8%EC%B9%98-%ED%8F%AC%EB%A0%8C%EC%8B%9D-Pre-Superfetch-Forensics.pdf

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