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

전통적인 컴퓨터 포렌식 방법론에서는 컴퓨터를 조사하기 전에 우선 전원 플러그를 뽑고 하드 드라이브의 이미지를 복사하는 것이 가장 기본적이었다. 하지만 최근에는 컴퓨팅 환경의 변화로 인해 저장 매체의 이미지 복사에 앞서 휘발성 정보를 먼저 수집하고 분석하는 쪽으로 방법론이 빠르게 이동하고 있다.

휘발성 정보에는 시스템 시간, 네트워크 연결 정보, 로그온 사용자 정보, 실행되고 있는 프로세스 정보 등이 있는데, 이런 정보는 컴퓨터가 꺼지고 나면 증발하듯 사라지기에 우선적으로 수집하여야 한다. 다시 말해 살아있는 시스템에서 수집 가능한 모든 정보의 수집과 분석, 그리고 이를 바탕으로 한 사고 처리까지가 담당범위이다.

1.1    라이브 리스폰스의 중요성

-       휘발성 저장장치에서만 찾을 수 있는 정보가 있다. 프로세스 목록, 열려있는 파일목록, 클립보드, 사용자 정보, 임시파일, 비밀번호 등을 포함하고 있으며 비휘발성 장치를 거치지 않고 바로 메모리에 로드되는 악성프로그램들이 존재하기에 이는 중요하다.

-       수집한 휘발성 정보를 우선적으로 평가함으로써 시스템의 대략적인 상태 파악 가능, 이를 통하여 조사의 세부 방향을 잡는데 기초적인 밑그림을 제공한다.

-       종료를 하기에 곤란한 상태에 있는 서버 컴퓨터와 같은 컴퓨터를 조사할 때 어쩔수 없이 라이브러리 상태에서 모든 증거를 수집하고 문제를 해결해야 한다.

1.2    시기

-       시간이 촉박하지만 않다면 항상 라이브 리스폰스를 수행하는 것이 좋은 판단이다.

-       비휘발성 저장장치에서 증거가 수정되거나 삭제되고 있는 상황에서 수행하는 것은 옳지않다. 예로 Secure Deletion & Secure Erase, Wiping과 같은 방법이 있다. 이런 의심이 들 경우 전원 플러그를 뽑는 것이 좋다. 이는 해커가 삭제하려는 파일보다 휘발성 증거들이 덜 중요할 수 있기 때문이다. 제한적인 휘발성 정보만 수집하고 싶다면 네트워크 연결정보와 메모리 덤프를 우선적으로 수집할 것을 권장한다.

-       사용하려는 도구들이 조사하고자 하는 윈도우 버전에서 충분한 검토가 이루어지지 않은 때에는 라이브 리스폰스를 수행하지 않는 것이 좋다. 이는 시스템에 미치는 영향을 전혀 예측할 수 없기 때문이다. (단, 이는 상황에 따라 조사관의 판단에 의해 용인 가능하다.)

1.3    원칙

-       휘발성 증거를 수집할 때 최우선으로 적용되는 원칙은 “원본에 대한 영향을 최소화 한다”는 것이다. 이는 동작중인 컴퓨터를 대상으로 하기 때문에 조사자의 휘발성 정보 수집행위가 시스템에 미치는 영향을 완전히 배제할 수 없다.

.

1.4    영향

-       메모리 : 도구를 실행하면 프로세스가 생성되고 실행 코드와 오브젝트드링 메모리에 적재된다. 이때 두 영역에서 수정 및 삭제가 발생한다. 첫째로, 프로세스는 메모리의 일정 영역을 점유하고 그 영역에 있던 이전 데이터를 덮어쓴다. 그 부분은 종료된 다른 프로세스가 사용하던 영역이거나, 임시데이터가 저장되어 있던 영역일 수 있다. 둘째로, 커널 오브젝트를 과리하는 시스템 테이블이 갱신된다. 테이블이 가득차 있다면 가장 오래된 항목이 자동 삭제된다.

-       네트워크 : 도구가 네트워크 기능을 이용한다면 시스템은 지정된 소켓을 열고 외부와 네트워크 연결을 맺는다. 방화벽 기능 활성화시 관련 로그가 기록되고 로그 파일이 쌓이면서 이전에 사용치 않던 HDD 영역을 사용하게 된다.

-       프리 패치 파일 : 윈도우는 새로운 프로그램이 실행될 때마다 Prefetch 파일을 만든다. 여기서 윈도우 XP에선 프리패치파일의 개수에 제한(120개)가 있기 떄문에 초과시 오래된 파일을 삭제한다.

-       레지스트리 : 라이브 리스폰스 도구들은 레지스트리에 접근하여 그 값을 사용한다. 윈도우 설치 정보를 찾아보거나, EULA(End User License Agreement)가 사용자에 의해 승인되었다는 것을 기록하기도 한다. 레지스트리에 대한 쓰기 작업은 레지스트리 키의 마지막 쓰기 시간 변경을 의미한다. 도구들은 이곳에 다양한 기록들을 남기게 된다.

-       DLL : 포렌식 도구가 DLL 파일을 필요로 한다면 해당 파일을 찾아서 읽을 것이며 파일의 접근 시간을 갱신할 것이다. 하지만 DLL 파일의 접근 시간 갱신은 크게 신경 쓸 필요가 없어 보인다. 하지만 사용하는 시스템 DLL이 이미 변조되거나 교체되었다면 문제는 달라진다.

-       로그 파일 : 도구가 에러를 발생시켰다면 기본적으로 그 정보는 이벤트 로그에 기록된다. 에러가 아니더라도 도구 자체가 이벤트 로그에 스스로 로그 기록을 남길 수 있다. 앞에서도 말했지만 이러한 로그들이 생성 될 때 하드 드라이브의 미할당 영역을 사용할 것이고, 이는 오래된 로그를 삭제할 수도 있다.

명심해야 할 것은 어떤 식으로 노력하든 라이브 리스폰스 도중에 실행하는 여러 도구와 조사관의 행위가 시스템에 전혀 영향을 미치지 않을 수는 없다. Write-Protection Device에 연결해서 하드를 카피하는 것과는 달리, 라이브 리스폰스는 중간에 어떤 보호 장치도 없으며 동작 중인 시스템을 대상으로 한다. 이 과정만으로도 시스템의 메모리, 레지스트리, 파일 시스템에 영향을 미친다. 따라서 영향의 배제가 아닌 최소화를 목적으로 해야 한다.

포렌식에서 여러 사전 준비 단계가 있고 하드웨어 준비, 소프트웨어 준비, 절차에 대한 준비로 나눌 수 있다. 하드웨어에는 분석용 컴퓨터나 장비들도 속하지만 증거물을 만질 때 사용할 장갑이나 사진기, 시계 등도 포함되며 소프트웨어엔 분석용 도구들과 라이브 리스폰스에서 사용할 도구가 포함된다. 절차는 증거의 수집과 분석, 그리고 최종 보고서 작성에 이르기까지의 일련의 합의된 과정을 의미한다.

2.1    도구 선택 단계

라이브 리스폰스에서 사용하는 도구는 적법한 절차를 통해 구해야 하고, 임의로 수정되거나 바이러스에 감염되지 않은 파일임을 증명할 수 있어야 한다. 컴퓨터 포렌식은 언제나 소송 같은 법적인 절차를 대비해야 하기 때문에 사용하는 도구들도 항상 법의 테두리 안에 있는 것들만 사용해야 한다.

2.2    도구 테스트 단계

도구를 선택했다면 다음은 그 도구들이 과연 예상했던 것처럼 잘 동작하는지 테스트하고, 시스템에 어떤 영향을 미치는지를 모니터링 할 차례이다. 한 버전에서 잘 동작하는 도구가 다른 버전 혹은 다른 서비스 팩에서도 잘 동작하리라는 보장은 없다. 따라서 라이브 리스폰스에 사용할 도구들은 다양한 버전과 서비스 팩에서 반복적으로 실행해 보고 확인해볼 필요가 있다.

2.3    문서화 단계

문서화는 포렌식 전반에 걸쳐 항상 적용되어야 하는 필수 사항이다. 선택한 도구들의 목록을 만들고 그것의 출처와 해시 값을 기록하라. 도구들을 테스트하고 테스트한 시스템의 환경과 그 결과, 그리고 그것이 시스템에 미치는 영향을 꼼꼼히 기록하자.

특히 도구가 시스템에 미치는 영향에 대한 문서화는 필수적이다. 이것을 게을리하면 실제 분석 과정에서 악성 프로그램이 시스템에 미친 영향과 사용한 도구가 미친 영향을 구별하지 못해서 큰 혼란을 겪게 된다.

2.4    모니터링과 문서화

라이브 리스폰스 도구들이 시스템에 어떤 영향을 미치는가를 문서화할 때 가장 중점을 두어야 하는 부분에는 세가지가 있다. 하나는 실행될 때 로드되는 DLL 파일 목록, 다음은 레지스트리 접근 정보, 마지막은 프로그램이 수정 및 생성하는 파일 목록이다. 이는 프로세스 모니터로 확인이 가능하다.

2.5   시스템 DLL 파일 사용하지 않기

앞에서 말한 바와 같이 라이브 리스폰스가 시스템에 미치는 영향을 완전히 없애는 것은 불가능하며, 최소화하는 방안에도 많은 걸림돌이 있다. 대상 시스템에 미치는 영향 중에서 가장 최소화하기 쉬운 것이 DLL파일이다.

이러한 DLL을 최소화 하기 위하여 상대적으로 적은 DLL을 로드하는 CLI 프로그램들로 도구들을 구성하는게 좋다. GUI의 경우 CLI에 비하여 많은 DLL을 로드하기 떄문이다. 이에 더해 시스템 DLL 파일을 사용하지 않는 방법에는 크게 3가지가 있다.

-    DLL 파일들을 실행 파일이 있는 폴더로 모두 복사

-      Dynamic-Link Library Redirection 기능을 이용

-      실행 파일의 코드를 수정

세가지 방법 중에서 로드되는 DLL 파일들을 실행 파일과 같은 폴더로 복사해 넣는 방법이 가장 간단하다. 그러나 별 효과가 없기에 실무에선 적합하지 않다. 프로세스가 필요한 DLL 파일을 찾기 위해 검색하는 폴더의 순서는 다음과 같다.

가장 높은 순위에 있는 SxS는 프로그램을 만들 때 컴파일러에서 별도의 옵션을 지정해야만 만들 수 있으며, 3번의 경우 코딩 시에 SetDllDirectory 함수를 넣어주어야만 한다. 따라서 이미 컴파일이 끝난 도구는 이를 응용할 수 없다. 그러므로 가장 간단하고 편리한 것이 2번의 방법이다.

2.6    파일 이름 변경

사용할 도구들이 확정되었다면 파일 이름을 원래의 것과 구별되는 것으로 변경하는 것이 좋다. 그렇지 않으면 기존 프로그램과 별도의 도구가 혼동될 경우가 있기 때문이다.

휘발성 정보에도 여러 종류가 존재하기에 어디에 우선순위를 두고 먼저 수집을 해야 할지 결정을 해야 한다. 이는 어떻게 기준을 잡느냐에 따라 다르므로 주관적이라 할 수 있다. 이제 이에 대하여 알아보자.

물리적 메모리는 수집하는데 시간이 가장 오래 걸림에도 불구하고 다른 정보들보다 먼저 수집하려는 이유는 대부분의 휘발성 정보들이 모두 메모리에 들어있기 때문에 물리적 메모리를 수집함으로써 그것들을 한번에 수집할 수 있고, 물리적 메모리 이외의 휘발성 정보들은 변조나 은폐가 가능하기 때문에 그 신뢰성이 물리적 메모리에 비해 떨어지기 때문이다.

표 출처 : 서강대 박종석 선임 - 활성 시스템 분석.pdf   2013.11.14