윈도우에는 프리/슈퍼패치라는 파일이 존재한다.
이 파일들은 윈도우 속도향상을 위해 존재하며, 포렌식적으로 의미가 많은 파일이기 때문에 상세히 알아보도록 하겠다.

[프리패치 파일]
프리패치 파일은 윈도우 속도향상을 위해 윈도우는 특정 어플리케이션이 사용하는 시스템 자원을 파일에 저장해놓고 윈도우 부팅시 프리패치 파일을 모두 메모리에 로드한다. 사용자가 메모리에 로드한 패치파일의 시스템 자원을 사용하는 어플리케이션을 실행 할 경우 미리 로드되어 있는 패치파일을 이용하여 어플리케이션을 실행하기 때문에 속도향상의 결과를 얻을 수 있는 것이다. 해당 파일의 관리는 프리패처(Prefetcher)가 하며, 프리패치 파일의 저장 경로는 아래와 같다.

경로 : %SystemRoot%\Prefetch

프리패치는 윈도우 부팅 시, 어플리케이션 실행 시 이 두 경우에 사용이 되는데 각각 어떻게 사용이 되는지 알아보자.

[부트 프리패칭]
윈도우 부팅 시 일어나는 과정의 명칭으로 윈도우는 부팅 시 여러 파일에서 실행코드와 데이터를 읽어오는데 읽어오는 파일들이 저장장치의 여러부분에 나뉘어져 있어 하드디스크의 헤드가 이리저리 빠르게 움직여야 해 하드디스크에 부담을 주게 된다. 이러한 이유로 데이터 읽기 시간은 지연되기 때문에 이러한 현상을 방지 하기 위하여 프리패처는 여러군데 나뉘어져 있는 파일들을 한군데 모아준다. 이러한 과정을 모니터링하고 그 결과를 저장하는 과정이 '부트 프리패칭' 이며 이때 만들어지는 파일이 있는데 이름이 'NTOSBOOT-BOODFAAD.PF' 이다. 

 

[어플리케이션 프리패칭]
어플리케이션 실행 시 일어나는 과정의 명칭으로 프리패처는 프리패치 파일이 없는 어플리케이션의 동작을 10초 동안 모니터링 하고 이 어플리케이션이 메모리에 올린 실행코드의 일부 또는 전부를 프리패치 파일로 만들어 저장한다. 그 후 해당 어플리케이션이 실행하면 윈도우 부팅 시 미리 메모리에 올려져 있는 해당 어플리케이션의 프리패치 파일을 사용하여 어플리케이션을 실행시킨다. 이렇게 함으로써 어플리케이션의 실행 속도는 향상된 결과를 얻게 된다.
이와 같은 과정을 '어플리케이션 프리패칭'이라고 한다.
어플리케이션 프리패칭 과정에서 생성되는 어플리케이션 프리패치 파일의 이름은 다음과 같은 규칙이 적용되어 생성된다.

[그림 1 - 어플리케이션 프리패치 파일 이름 생성 규칙]

* 참고 : 파일위치 hex값은 파일의 전체 경로(명령 옵션 포함)를 MD5로 해쉬한 값이다. 


프리패칭 기능들은 버전마다 기본적으로 사용되는 OS가 다르다.
 - 부트 프리패칭 : Win XP, 2003, Vista, 2008, 7
 - 어플리케이션 프리패칭 : Win XP, Vista, 7


위와 같이 다른 이유는 서버 OS의 경우 어플리케이션 사용 개수가 극히 소수이므로 굳이 어플리케이션 프리패칭 기능을 사용 할 필요가 없는 것이다.

프리패칭 기능은 레지스트리를 통해서 제어 할 수도 있고 서비스 관리를 통해 제어 할 수도 있다.

레지스트리의 경우 아래 키에서 프리패칭 기능을 제어 할 수 있다.

키 : HKLM\System\CurrentControlSet\Control\Session Manager\Memory Management\PrefetchParameters
 

[그림 2 - PrefetchParameters 키]

위 키에서 EnablePrefetcher Value를 통해 제어 할 수 있으며, 설정 되는 값마다 의미하는 바가 다르기 때문에 아래에 해당 값들을 나열해 두었다.
 - 0 : 프리패칭을 사용하지 않음
 - 1 : 어플리케이션 프리패칭만 사용
 - 2 : 부트 프리패칭만 사용
 - 3 : 모두 사용(Defalut)


다음은 서비스 관리를 통한 프리패칭 제어 방법이다.

[그림 3 - Task 스케쥴러 서비스]

위 서비스가 중지되면 프리패칭 기능도 중지 된다.


* 참고 : 윈도우 XP의 프리패치 파일의 개수는 최대 128개이며 초과시 오래된 프리패치 파일은 삭제된다. 이와 같은 이유로 라이브 리스폰스 과정에서 실행된 어플리케이션의 프리패치 파일이 시스템의 오래되고 중요할지도 모르는 프리패치 파일을 지울 수 있어 이 점을 꼭 기억해 두고 있어야 한다.

프리패치 파일을 분석해주는 도구(Windows File Analyzer, Prefatch Paser)가 있지만 구조 공부를 하고 도구를 사용하는 것이 더욱 정보를 쉽고 정확하게 분석 할 수 있는 것이기 때문에 프리패치 파일의 구조를 알아보겠다.
다음 이미지는 프리패치 파일 구조 오프셋을 표시한 이미지이다.
* 참고 : Win XP와 Win 7의 경우 프리패치 파일의 구조가 달라 오프셋 표시 이미지가 두개이다.

 

[그림 4 - Win 7의 프리패치 파일 구조 offset]

[그림 5 - Win XP의 프리패치 파일 구조 offset]

[포렌식 관점에서의 프리패치 파일]
프리패치 파일은 실행파일의 여러가지 정보를 담고 있어 포렌식적 의미가 높으며 그 중에서도 포렌식적으로 활용 될 수 있는 정보는 아래와 같다.
1. 실행파일의 이름
2. 실행파일의 실행 회수
3. 실행파일의 마지막 실행 시간
4. 프리패치 파일의 타임라인(생성, 수정 접근)

 
이제 슈퍼패치에 대해서 알아 볼 차례이다.

[슈퍼패치 파일]
슈퍼패치 파일은 프리패치 파일의 추가적인 정보를 저장하는 파일이면서 프리패치 파일의 문제점을 해결하기 위해 만들어진 파일이기도 하다.
프리패칭의 과정 중 메모리에 프리패치 파일을 로드하는 과정이 있는데 이 과정에서 메모리 용량의 한계로 프리패치 파일이 페이지 파일로 Swap되면 추후에 어플리케이션 실행 시 다시 페이지 파일에서 메모리로 로드해야 한다는 점에서 속도 저하를 발생시킨다. 이러한 단점을 해결하기 위해 슈퍼패치 파일이란 것을 추가하였으며, 슈퍼패치 파일에는 사용자의 프로그램 실행 패턴을 기록한다.
슈퍼패치 파일은 프리패치 파일과 동일한 경로에 저장되며, 파일명은 Ag로 시작하고 확장자는 '.db' 이다.
슈퍼패칭 기능의 제어는 프리패치와 동일하게 레지스트리와 서비스 관리에서 할 수 있다.
레지스트리의 키 경우 프리패칭과 동일하며, Value만 다르다.

[그림 6 - 슈퍼패칭 Value]
 
프리패칭 기능을 제어하는 Value와 마찬가지로 여러 값을 가질 수 있으며 해당 값들은 아래와 같다.
 - 0 : 사용하지 않음
 - 1 : 어플리케이션 프리패칭 시 사용
 - 2 : 부트 프리패칭 시 사용
 - 3 : 모두 사용 



[그림 7 - 슈퍼패치 서비스]

슈퍼패치 파일은 여러가지가 있는데 이 파일들은 압축 파일과 비압축 파일로 나뉘며 아래와 같이 정리 할 수 있다.
1. 압축
    - AgAppLaunch.db
    - AgRobust.db
    - AgCx_SC[number].db
2. 비압축
    - AgGlFaultHistory.db
    - AgGlFgAppHistory.db 
    - AgGlGlobalHistory.db 
    - AgGlUAD_P_<SID>.db
    - AgGlUAD_<SID>.db

 

파일 구조는 간단하게 알아보도록 하겠다.(데이터 압축 크기가 가변적이어서 앞부분만 살펴보도록 하겠다)

[그림 8 - 슈퍼패치 파일 구조 offset]

슈퍼패치는 ntdll.dll 파일의 임포트 함수목록 중 RtlCompressBuffer(), RtlDeCompressBuffer() 함수에 의해 압축, 압축해제가 되며 함수에 들어가는 인자(COMPRESSION_FORMAT_LZNT1, COMPRESSION_FORMAT_XPRESS or COMPRESSION_FORMAT_XPRESS_HUFF)에 따라 압축 방식이 달라진다.


이 외에도 레디부스트라는 Vista 이후 버전에 추가된 기능이 있는데 이 기능은 다음에 다루도록 하겠다.

'[+] Forensic' 카테고리의 다른 글

Web Browser  (0) 2012.01.13
썸네일(Thumbnail) 파일 분석  (2) 2012.01.12
프리/슈퍼패치 파일  (0) 2012.01.12
바로가기(LNK) 파일  (0) 2012.01.11
이벤트 로그  (1) 2012.01.11
윈도우에는 다른 OS와 차별화된 '바로가기' 라는 기능의 파일이 존재한다.

다른 OS에는 비슷한 기능으로 심볼릭 링크가 존재한다.

대부분의 사람들이 이 두 기능을 같은 기능으로 보고 있지만, 분명히 다른 기능이다.

윈도우의 바로가기 기능은 OS 차원의 기능이고, 심볼릭 링크는 파일시스템 차원의 기능이어서 그 기능의 동작방식부터가 다르다.

윈도우의 바로가기 기능의 경우 바로가기 파일을 통해 실현 가능한데, 이 파일은 일반 파일과 동일하게 메타데이터와 MFT 엔트리를 가지고 있고 심볼릭 링크의 경우 원본 파일을 가리키고 있는 것은 파일이 아닌 것으로 파일시스템이 인식하기 때문에 이 두기능이 다르다고 할 수 있다.

그럼 윈도우에서 바로가기가 어떤 경우에 생성되는지 알아보자.

[바로가기 생성]
1. 윈도우 설치 시
    - 윈도우에서 기본적으로 지원하는 '내 컴퓨터', '작업 표시줄 아이콘' 등도 모두 바로가기 파일이다.
2. 윈도우 설치 후
    - 대표적으로 '내 최근 문서' 폴더의 문서 목록들이 있다.
3. 어플리케이션 설치 시
    - 어플리케이션 설치 중 '바탕화면에 바로가기 아이콘을 생성 하시겠습니까?' 라는 메시지를 보았을 것이다.
4. 사용자 임의 생성
    - 파일을 마우스 오른쪽 클릭 후 생성 하는 것들 


바로가기는 일반 사용자가 보기에는 일반적인 파일로 보일지 모르지만 조사관의 입장에서는 시스템 조사 시 유용한 정보들을 많이 지니고 있는 파일로 취급 될 수 있다.

대부분 포렌식 통합 분석 도구에는 바로가기 분석 도구도 내장되어 있어 간편하게 바로가기 파일을 분석 할 수 있지만, 어느정도 구조를 알고 분석한다면 시간과 획득하는 정보의 양질적 면이 높아지니 구조를 한번 살펴보자.

바로가기 정보는 일부는 속성창에서 얻을 수 있다. 

[그림 1 - 바로가기 속성 창]

하지만 이 정보는 바로가기 정보들 중 아주 극히 일부분에 지나지 않는다.

이러한 정보를 알기 위해서 구조를 분석하는 것이 아니니 조금 더 깊숙히 보도록 하겠다.

바로가기는 아래와 같은 영역들이 있다.

[바로가기 영역 구분]
1. SHELL_LINK_HEADER
    - 식별정보, 타임스탬프, 선택 가능한 영역의 유무 표시 플래그 정보를 저장하고 있다.
2. LINKTARGET_DILIST
    - 원본 정보를 포함하고 있다.
3. LINKINFO
    - 원본의 위치를 찾을 때 필요한 정보를 저장하고 있다.
4. STRING_DATA
    - 사용자 인터페이스나 경로 식별 정보를 저장하고 있다. 
5. EXTRA_DATA
    - 기타 정보를 저장하고 있다. 

 

각 영역이 저장하는 정보를 간략하게 알아 봤으니 이제 각 영역을 세분화 하여 알아볼 차례이다.

[SHELL_LINK_HEADER]
식별정보, 타임스탬프, 선택 가능한 영역의 유무 표시 플래그 정보를 저장하고 있는 영역이다.
오프셋 별로 저장하고 있는 정보가 다른데 아래 이미지에 각 오프셋에 대해서 표시 해 두었다.

[그림 2 - SHELL_LINK_HEADER offset]

Link Flag의 경우 많은 양의 여러가지 값이 있어 일일이 설명하지는 못하니 MS-SHLLINK.pdf(p12)를 참조하기 바란다.


[LINKTARGET_IDLIST]
다른 파일에서는 선택 항목이지만 바로가기에서만큼은 필수항목인 영역이다. 
다음은 이 영역의 오프셋을 표시한 이미지이다.

 

[그림 3 - LINKTARGET_IDLIST]

위에 IDList가 표시되지 않았는데 그 이유는 ItemIDList와 시작 오프셋이 같기 때문에 체크 박스가 겹쳐 표시하지 않았다.

IDList 마지막에는 TerminalID라고 하는 예양영역이 있는데 이 영역은 모두 0으로 설정되어 있다. 


[LINKINFO]
바로가기 파일에서 필수적인 요소이며 원본 파일이 정해진 위치에 없는 경우 원본 파일을 찾기 위한 필수 정보들을 가지고 있다.
오프셋을 표시하려고 했으나 오프셋 위치가 정확하게 찾아지지 않아 MS 문서를 참고하여 아래와 같은 목록을 작성하였다.

[그림 4 - LINKINFO offset]

LINKINFO Flag의 경우 특이하게도 전체 32비트 중 좌측 2비트만 사용한다.
 - 10000000~ 일 경우: VolumeID와 LocalBasePath 필드에 오프셋 값이 들어감 
 - 01000000~ 일 경우 : Network Volume Info 필드에 오프셋 값이 들어감 


VolumeID 필드는 바로가기가 생성될 당시 원본이 있던 Volume 데이터를 저장하고 있다.
VolumeID 필드의 오프셋은 다음과 같다.

[그림 5 - VolumeID 필드 Offset]

VolumeID 필드의 DriveType은 아래와 같은 값들을 가질 수 있다.

[그림 6 - DriveType]

LINKINFO offset 중 Network Volume Info 필드가 속해 있는데 이 필드의 오프셋은 다음과 같다.

 

[그림 7 - Network Volume Info]

해당 필드의 Flag도 VolumeID의 플래그와 같은 방식이며 의미는 다음과 같다.
 - 1000000~ : DeviceName 필드가 존재함
 - 0100000~ : NetProviderType 필드가 존재함 

 
* 참고 : NetName은 원본이 있는 공유된 네트워크의 이름을 뜻 함 


[STRING_DATA]
사용자 인터페이스와 경로 식별자를알려주는 일련의 문자열로 구성되어 있는 영역이다.
이 영역에 올수 있는 문자열의 종류는 LinkFlags에 따라 결정되며 가능한 문자열은 아래와 같다.
 

[그림 8 - STRING_DATA 문자열 종류]


[포렌식관점에서의 바로가기]
각 영역에서의 포렌식적 의미를 가지는 부분들을 나열해 보면 다음과 같다.
1. SHELL_LINK_HEADER
   - 원본파일의 속성 정보
   - 원본 파일의 생성, 접근, 수정 시간
2. LINKINFO
   - 원본파일의 크기
   - 원본파일이 위치한 VolumeID
   - 원본파일이 위치한 VolumeID의 시리얼 번호
   - 원본파일의 경로
3. EXTRA_DATA
   - NetBios 이름
   - MAC 주소 


EXTRA_DATA는 원본에 대한 추가 정보를 가지고 있지만 대부분의 정보가 포렌식 관점에서는 필요하지 않은 정보이기 때문에 생략하도록 하겠다.

EXTRA_DATA 영역이 궁금하다면 MS-SHLLINK.pdf(p26)을 참조하기 바란다.



'[+] Forensic' 카테고리의 다른 글

썸네일(Thumbnail) 파일 분석  (2) 2012.01.12
프리/슈퍼패치 파일  (0) 2012.01.12
바로가기(LNK) 파일  (0) 2012.01.11
이벤트 로그  (1) 2012.01.11
휴지통 분석  (0) 2012.01.10

[MRU(Most Recently Used)]
윈도우는 사용자가 특정 행위를 하였을 때 마지막 행위를 레지스트리에 기록해 두는데 이 목록이 MRU List이다.
이제부터 소개하는 것들이 MRU List에 포함 되는 것들이다.

[검색 목록]
윈도우의 검색 목록은 레지스트리에 XP의 경우 검색 종류에 따라 각각 기록되는 서브키가 다르며, Win 7의 경우 통합적으로 기록이 된다.

키(XP) : HKCU\Software\Microsoft\Search Assistant\ACMru\5603  --> 모든 파일과 폴더 검색 기록
키(XP) : HKCU\Software\Microsoft\Search Assistant\ACMru\5001  --> 로컬 인터넷 검색
키(XP) : HKCU\Software\Microsoft\Search Assistant\ACMru\5647  --> 컴퓨터와 사람들 검색
키(XP) : HKCU\Software\Microsoft\Search Assistant\ACMru\5604  --> 음악, 그림, 동영상 검색


[그림 1 - ACMru 키의 서브키]


키(Win 7) : HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\WordWheelQuery

[그림 2 - Win 7의 WordWheelQuery 키]

위 이미지에 나와 있는 것처럼 검색 순서는 MRUListEx data에서 알 수 있다. 

* 참고 : Vista는 검색 기록을 레지스트리에 남기지 않는다. 

 

[최근 문서]
윈도우 버튼을 누르면 각 윈도우마다 내 최근 문서라고 하여 최근에 열었던 파일들을 나열해주는 기능이 있다.
이 기능또한 레지스트리를 참조하는 기능으로서 레지스트리를 통해 확인이 가능하다.

키 : HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\RecentDocs
 

[그림 3 - RecentDocs 키]

각 Value의 data를 확인 해 보면 파일을 확인 할 수 있으며 순서는 MRUListEx를 참고하면 된다. 


[최근 실행명령어]
윈도우 버튼을 누르면 실행이란 부분을 볼 수 있다. 일반 사용자들은 이 부분을 잘 사용하지 않지만 관리자나 컴퓨터에 대해서 조금만 알고 있는 사람들은 이 실행창을 자주 이용한다. 이 실행창에서의 명령어 리스트를 아래 키에서 볼 수 있다.

키 : HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU

[그림 4 - RunMRU 키]

이 키의 MRUList Value는 위의 MRUListEX Value와 다르게 순서가 알파벳으로 저장된다. 물론 실행된 기록들 또한 알파벳으로 저장된다.


[원격 데스크탑 연결 목록]
이 기능도 의외로 많이 사용하는 기능중 하나이다. 이 기능을 사용하여 원격 PC에 접속하고 나중에 다시 접속하려고 보면 예전에 접속했던 IP가 목록화 되어 남아 있는 것을 볼 수 있는데 이 정보 또한 레지스트리에 기록되는 정보이다.

키 : HKCU\Software\Microsoft\Terminal Server Client\Default

MRUx 형태로 Value가 되어 있는데 x는 0부터 시작한다. 숫자가 작을수록 최근에 접속한 IP이다. 


[대화상자를 통한 접근 기록]
대부분 프로그램에서 사용자에게 파일을 열도록 유도할 때 대화상자를 이용하는데 대부분의 프로그램이 윈도우 기본 대화상자를 사용한다. 이 대화상자를 통해 접근한 최근 폴더나 파일의 기록 또한 레지스트리에 남는다.

키(Vista/7) : HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32\LastVisitedPidMRU --> 최근 접근한 폴더
키(Vista/7) : HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32\OpenSavePidlMRU --> 최근 저장하거나 읽은 파일


이 키의 Value 또한 알파벳으로 표현되며, 두 키의 내용은 거의 비슷하나 OpenSavePidlMRU의 경우 확장자 별로 확인 할 수 있다. 

* 참고 : XP의 경우 키 이름에서 Pid만 제거하면 XP의 키 이름이 된다. 


[네트워크 드라이브 맵핑 정보]
윈도우는 원격에 있는 다른 컴퓨터의 하드디스크나 폴더를 로컬 컴퓨터의 드라이브로 맵핑 하여 사용한 정보를 레지스트레 기록한다. 

키 : HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Map Network Drive MRU

이 키또한 Value가 알파벳으로 표현된다. 



[마지막으로 접근한 레지스트리 키 정보]
아래 키에서 확인 할 수 있다.

키 : HKCU\Software\Microsoft\Windows\CurrentVersion\Applet\Regedit

LastKey Value의 data로 알 수 있다. 


[파일 접근 시간 업데이트 여부]
이 기록은 Win Vista/7에서만 사용하는 것으로 아래 키에서 확인 할 수 있다.

키 : HKLM\System\CurrentControlSet\Control\FileSystem

[그림 5 - FileSystem 키]

NtfsDisableLastAccessUpdate Value의 값에 따라 업데이트 여부가 결정 된다.
 - 0 : 업데이트
 - 1 : 업데이트 하지 않음(Default) 


디렉토리 리스닝의 속도를 빠르게 하기 위해 기본적으로 사용하지 않음. 


[휴지통 우회]
휴지통을 통해 삭제가 되는가, 휴지통을 거치지 않고 삭제가 되는가를 결정해주는 키가 있다.

키(XP) : HKLM\Software\Microsoft\Windows\CurrentVersion\Explorer\BitBucket
키(Vista/7) : HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\BitBucket\Volume\<GUID>


[그림 6 - Volume 키]

 - 0 : 삭제시 휴지통으로 이동(Default)
 - 1 : 삭제시 휴지통을 거치지 않고 바로 삭제 


XP의 경우 레지스트리 한번의 설정으로 모든 사용자가 동일하게 적용 받지만, Vista/7은 Volume과 사용자 별로 설정 할 수 있다.


[삭제된 프로그램 정보]
원래 이 키의 목적은 프로그램의 이름을 다국적 언어로 지원하기 위해 한번 실행된 프로그램의 이름을 이 키에 저장해 두었다가 후에 해당 프로그램이 실행되면 이 키를 읽어 프로그램의 이름을 다국적 언어로 표현하기 위한 것이다.
하지만 이 키에 등록된 Value는 한번만 등록되더라도 지워지지 않는 특성이 있어 포렌식적으로 중요한 의미를 지닌다.

키 : HKCU\Software\Classes\Local Setting\Software\Microsoft\Windows\Shell\MuiCache

[그림 7 - MuiCache 키]

실행 전체경로와 실행 파일명까지 나와 있는 것을 볼 수 있다. 


지금까지 알아 본 레지스트리들만이 포렌식적으로 의미를 갖는 것은 아니다.

여기서 다루지 않은 레지스트리 키들도 다른 정보와 결합하거나 의미를 갖지만 아직 알려지지 않았을 뿐이다. 

'[+] Forensic' 카테고리의 다른 글

휴지통 분석  (0) 2012.01.10
윈도우 계정  (0) 2012.01.10
Registry (11)  (0) 2012.01.07
Registry (10)  (0) 2012.01.07
Registry (9)  (0) 2012.01.06

[이동형 저장장치 정보]
이동형 저장장치는 USB 썸 드라이브(Thumb Drive)나 외장 하드 드라이브처럼 한곳에 고정되어 있지 않고 편하게 휴대하여 다닐 수 있는 저장장치들을 말한다. 요즘은 이러한 저장장치들의 크기가 커지면서 활용도가 엄청 높아져서 이로인한 보안사고도 빈번하게 일어난다. 회사들의 경우 이동형 저장장치의 반입을 물리적으로 차단하기도 하고 컴퓨터의 USB 포트를 봉인해두기도 한다. 이동형 저장장치가 컴퓨터에 연결되면 Plug & Plug Play Manager가 이벤트 알림신호를 받고 연결된 이동형 저장장치에 장치 정보들을 요청한다. 이 정보를 바탕으로 PnP Manager는 Device Class ID를 부여하고 적절한 드라이버를 찾은 후 해당 드라이버가 현재 로드되어 있지 않으면 해당 드라이버를 로드하여 준다. 이러한 과정이 끝나면 PnP Manager는 아래 키에 Device Class Identifier 키와 서브키들을 생성한다.

키 : HKLM\System\CurrentControlSet\Enum\USBSTOR\<Device Class Identifier>\<Unique Instance ID>

[그림 1 - USBSTOR 키]

위 이미지에서 Disk로 시작하는 서브키가 Device Class Identifier이며, 위 이미지에는 없지만 Device Class Identifier 하위키로 Unique Instance ID가 존재한다.

Device Class Identifier 서브키의 이름에는 규칙이 있는데 그 규칙은 아래 이미지와 같다.

[그림 2 - Device Class Identifier 이름 생성 규칙]

 

 이번에는 Unique Instance ID를 알아볼 차례이다. 이 서브키의 이름도 규칙이 있는데 그 규칙은 아래와 같다.
1. 저장장치의 Device ID나 Serial Number로 Unique Instance ID를 부여하는데 만약에 없다면 PnP Manager가 임의로 부여한다.
 - Device ID나 Serial Number가 있을 경우 형식 : XXXXXXXXXX&X
 - PnP Manager가 임의로 생성할 경우 형식 : X&XXXXXXXXXX&X


레지스트리에는 위와 같은 이름들을 한번에 볼 수 있는 키도 존재한다.

키 : HKLM\System\CurrentControlSet\Control\DeviceClasses\{53f56307~, 53f5630d~}

[그림 3 - DID와 UID를 한번에 볼 수 있는 키]

53f56307-b6bf-11d0-94f2-00a0c91efb86 키의 서브키들의 이름은 디스크의 GUID를 의미하며 53f5630d-b6bf-11d0-94f2-00a0c91efb86는 볼륨 디바이스 인터페이스의 GUID를 의미한다.
이 두 키의 하위키의 data에서 시스템에 연결된 장치들의 DID와 UID를 확인 할 수 있다.

 

[그림 4 - 확인 할 수 있는 data에서의 DID와 UID]

만약 이러한 정보들만으로 증거로 수집된 수많은 이동형 저장장치 어느것이 쓰였는지 판단하려면 정보가 부족한 감이 없지 않다. 이럴때 제조사의 ID와 제품의 ID 정보를 수집하여 조회 한다면 찾고자 하는 이동형 저장장치의 범위가 좁혀질 것이다.

키 : HKLM\System\CurrentControlSet\Enum\USB

위 키의 서브키 이름은 아래와 같은 규칙을 갖는다.

[그림 5 - USB 키의 하위키들 이름 생성 규칙]

USBSTOR에서의 정보와 위 생성 규칙으로 생성되는 서브키들의 연관성은 UID로 이루어 진다.

[그림 6 - USB키의 하위키들과 USBSOTR키의 하위키들의 연관성]


이동형 저장장치의 특정 사용시간을 알아내려면 최초 연결 시간과 마지막 연결 시간을 알아보면 된다.
최초 연결 시간은 아래 키 서브키의 마지막 수정 시간(Last Writteen Time) 을 보면 된다.
 

키 : HKLM\Software\Microsoft\Windows Potable Devices\Devices

마지막 연결 시간은 아래 키 서브키의 마지막 수정 시간을 보면 된다.

키 : HKU\<user>\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoint2
      HKLM\System\ControlSetXXX\Enum\USB\VID_XXXX&PID_#### 


위 키의 하위키들 중 Volume GUID나 Serial Number를 찾아 마지막 수정 시간을 보면 된다.
하지만 정확한 사용시간은 알아내지 못하며, 시간 범위를 유추하기 위하여 정보를 수집하는 것이다.

[연결된 저장장치 정보]
연결된 모든 저장장치(로컬, 이동형)의 연결 정보는 아래 키에서 확인 할 수 있다. 

키 : HKLM\System\MountedDevices
 

[그림 7 - MountedDevices 키]

이 키의 Value와 data를 보면 어떠한 이동형 저장장치나 로컬 저장장치가 어떠한 드라이브 문자와 맵핑되었는지 알 수 있다.
 

 

[그림 8 - 연결된 저장장치와 드라이브 문자와의 맵핑 정보]

유니코드로 기록된 문자열을 읽어보면 USBSTOR#Disk&Ven_SAMSUNG&Prod_YP_PB2&Rev_1.00~ 이란 문자열이 나온다. 


[계정 정보]
계정 정보의 경우 SAM 키의 하위키에 존재하는데 SAM 키의 접근 권한은 시스템 계정뿐이 없다. 하지만 활성시스템에서 권한 상승을 하기란 여러모로 문제가 있어 대부분의 계정 정보는 포렌식 이미징에서 획득하는 것이 좋다.
포렌식 이미지에서 SAM 파일의 복사본을 파싱 할 수 있는 레지스트리 파싱 도구들이 몇가지 있다.
따로 툴들에 대해서는 다루지 않겠다. 또 구조에 대해서도 따로 다루지는 않겠다. 


[실행정보]
윈도우 키를 누르면 아래와 같이 자주 실행되는 프로그램이 나타나는데 이 기준은 실행 횟수이다.

[그림 9 - 자주 실행되는 애플리케이션]

이렇듯 윈도우는 자주 실행된 애플리케이션들을 기억하며 애플리케이션들의 정보도 레지스트리에 기록해 둔다.
아래는 이 정보들을 저장하는 키의 위치이다.

키 : HKCU\Software\Microsoft\Windows\CurrentVersion\Explorers\UserAssist\<GUID>\Count

위 키의 Value를 보면 XP의 경우 아래와 같은 Value를 볼 수 있으며 각 오프셋이 뜻하는 의미는 이미지에 설명 해 두었다.

[그림 10 - XP offset]

Vista/7의 경우는 조금 다르다.

[그림 11 - Vista/7 offset]

 
Vista/7의 경우 실행 횟수의 초기값이 어플리케이션마다 다르기 때문에 정확하게 파악하기는 힘들다. 





'[+] Forensic' 카테고리의 다른 글

윈도우 계정  (0) 2012.01.10
Registry (11)  (0) 2012.01.07
Registry (10)  (0) 2012.01.07
Registry (9)  (0) 2012.01.06
Registry (8)  (2) 2012.01.06
계속해서 포렌식적으로 의미있는 레지스트리들을 살펴보겠다.

[서비스 및 드라이버 목록]
이 정보는 라이브 리스폰스 단계에서 수집되는 정보이며, 레지스트리에서도 수집 할 수 있는 정보이다.
아래 키로 가면 서비스와 드라이버 목록들이 서브키로 나열되어 있다.
드라이버 목록과 서비스를 구별하는 방법은 각 서브키의 Value 중 type이란 Value의 값을 보면 판단 할 수 있다.

키 : HKLM\System\CurrentControlSet\Service

 [그림 1 - 레지스트리에서의 서비스 및 드라이버 목록]

Start Value 값에 따라 자동 시작되는 서비스가 될 수도 있고 안될 수도 있다.

* 타입별 자세한 설명은 http://support.microsoft.com/kb/103000 참조하기 바란다. 


[로그온 자동 시작점]
윈도우는 사용자가 로그온을 하면 HKCU 레지스트리 해당 사용자의 하이브 파일을 읽고 그 안에 있는 자동시작 항목등을 차례대로 실행한다. 사용자별 자동시작 프로그램 목록은 서로 다르며, 그 이유는 아래처럼 여러가지의 키가 존재하기 때문이다.

키 : HKLM\Software\Microsoft\Windows\CurrentVersion\Run
키 : HKLM\Software\Microsoft\Windows\CurrentVersion\Runonce

이 두 키의 경우 로그온한 사용자 상관없이 프로그램이 실행되게끔 하는 키이다.

키 : HKCU\Software\Microsoft\Windows\CurrentVersion\Run
키 : HKCU\Software\Microsoft\Windows\CurrentVersion\Runonce

이 두 키의 경우 해당 사용자가 로그온 했을 때만 실행되게끔 하는 키이다.

그리고 Run, Runonce 서브키로 나뉘는 것을 볼 수 있는데 Run 키의 경우 시스템이 부팅될 때마다 실행시키는 키 이고,
Runonce는 한번만 실행되게끔 하는 키이다.

그리고 RunonceEx 라는 키가 HKLM과 HKCU에 또 존재한다. 이 키는 Runonce와 같은 성격의 키 이지만, 프로그램을 처리하는 방식이 다르다. Runonce의 경우 프로그램의 연관성을 무시하고 실행시키지만, RunonceEx의 경우 연관성 있는 프로그램끼리 그룹으로 묶어 처리하고, 처리 과정을 GUI 방식으로 사용자에게 보여 줄 수 있다.


[감사 정책]
다른 OS와 마찬가지로 윈도우도 시스템 내부에서 일어나는 여러 이벤트에 대한 보안 로그를 남긴다. 
보안 로그 기록의 기준이 감사 정책인데 관리자 도구를 이용해서도 알 수 있지만, 레지스트리에서도 알 수 있다.

키 : HKLM\Security\Policy\PolAdtEv
Value : (기본값)


Windows 버전마다 레지스트리에서의 감사정책별 offset이 다르다. 아래는 XP의 감사정책 별 오프셋 목록표 이다.

[그림 2 - 감사 정책별 offset(출처 : Forensic-Proof(FP-15-레지스트리-포렌식-분석.pdf))]

아래는 Win Vista/7의 감사 정책 별 offset이다.

[그림 3 - 감사 정책별 offset(출처 :  Forensic-Proof(FP-15-레지스트리-포렌식-분석.pdf)]


모든 버전의 윈도우들은 위 오프셋중에서 0을 제외한 나머지 오프셋의 값들은 아래와 같은 의미를 지닌다.

 - 0x00 : 감사 정책 없음
 - 0x01 : 성공 이벤트 감사
 - 0x02 : 실패 이벤트 감사
 - 0x03 : 성공, 실패 이벤트 감사 

감사별 자세한 항목은 아래 문서를 참조하면 된다.
 


[무선 네트워크 정보]
만약 공격자의 컴퓨터를 조사한다고 하였을 때 대부분의 용의자는 공개 AP등을 이용하여 자신의 위치정보를 속여 공격을 하려고 할 것이다. 이러한 이유를 근거로 공격자는 범죄 행위를 부인 할 것이며, 조사관은 공격자가 어느 장소에서 접속했다는 증거를 공격자에게 제시하여 공격자의 주장을 무효화 시킬 수 있다.. 이러한 경우 공격자의 컴퓨터에서 용의자가 접속한 AP 정보를 찾아야 하며 윈도우의 경우 레지스트리에 그 정보가 있다.
해당 정보는 아래의 키에 있다.

키(XP) : HKLM\Software\Microsoft\WZCSVC\Parameters\Interface\{GUID}
Value : Static#000X

키(Vista/7) : HKLM\Software\Micrsoft\Windows NT\NetworkList\Nla<Wireless, Signature, Profile>


XP의 경우 해당 Value의 데이터만 보면 SSID 문자열을 찾을 수 있다.
하지만 Vista/7의 경우 Profile과 GUID(Globally Unique Identification Number)등이 나눠져 있어 한번에 SSID를 찾기가 쉽지 않다. 아래에는 Vista/7에서 네트워크 정보에 관한 서브키들의 연관성을 보여주는 이미지이다.

 

[그림 4 - 각 서브키의 연관성]

해당 순서는 서브키의 값을 따라 이동한 순서로 아래에 이미지를 참고하면 이해가 갈 것이다.

[그림 5 - 서브키의 연관성 1번]

Wireless 서브키의 하위키의 이름이 무선 네트워크 식별자이며 Unmanaged와의 연관성으로 여러 정보를 확인 할 수 있다.
Unmanaged 하위키에서 찾고자 하는 무선 네트워크 식별자를 찾은 뒤 Value와 data를 확인 해 보면 아래와 같다.

[그림 6 - Unmanaged 키의 하위키 내용]

ProfileGuid의 data 값을 Profile 서브키에서 찾아 data를 보면 접속한 AP에 대한 정보가 나온다.
이 순서가 2번 순서이다.

[그림 7 - 무선 AP의 정보]

 

Value를 보면 AP의 이름과 마지막 접속 시간등이 나와 있다.

마지막 접속시간의 경우 hex값을 우리가 알아 볼 수 있는 시간으로 바꾸려면 아래와 같은 과정을 거쳐야 한다.

1. 기존의 값을 2바이트씩 끊어 Little Endian 방식을 적용하여 변경한 뒤 10진수로 바꿔준다.

[그림 8 - 10진수로 변환하는 python 코드]


2. 변환한 값을 각 자리가 뜻하는 것으로 맞추면 된다.

[그림 9 - 각 자리가 뜻하는 의미]

어디에 접속했는지 알았다면 이제는 접속했을 때의 정보를 알아야 한다. IP가 대표적이다.

각 네트워크 카드를 확인하여 해당 네트워크 카드에 할당된 네트워크 정보를 보면 된다.

키 : HKLM\Software\Microsoft\Windows NT\CurrentVersion\NetworkCards

 

[그림 10 - 네트워크 카드 GUID]

위 빨간색 박스안에 있는 문자열이 네트워크 카드 GUID이다. 해당 GUID를 아래 키에서 찾으면 된다.

키 : HKLM\System\CurrentControlSet\Service\Tcpip\Parameters\Interface\<GUID>

[그림 11 - 네트워크 카드에 할당 된 네트워크 정보]

Value 중에 DhcpIPAddress가 있는데 이것이 해당 네트워크카드에 dhcp가 할당해준 IP 주소이다.
이 Value 말고 IPAddress가 있을수도 있는데 이 Value는 사용자가 직접 수동으로 설정해준 IP주소를 뜻한다.

하지만 여기서 끝이 아니다. 위 처럼 사설아이피라면 모든 공유기와 연결지어도 말이 되기 때문에 증거로서 효력이 없다.
정확하게 특정한 AP와 아이피를 연결시켜야한다. 이는 DhcpNetworkHint에 나와있다.
DhcpNetworkHint Value의 data를 2자리씩 끊어 리틀엔디안으로 변환하면 다음과 같다.

 

[그림 12 - DhcpNetworkHint Value Little Endian]

이렇게 변환한 값을 가지는 Wireless의 서브키를 찾으면 된다.

 [그림 13 - DhcpNetworkHint Value Little Endian 값을 갖는 Wireless 서브키]

이런 후에 위에 AP찾는 방법을 이용하여 찾으면 모든 네트워크 정보가 연결 된다.

'[+] Forensic' 카테고리의 다른 글

Registry (11)  (0) 2012.01.07
Registry (10)  (0) 2012.01.07
Registry (9)  (0) 2012.01.06
Registry (8)  (2) 2012.01.06
Registry (7)  (0) 2012.01.04

+ Recent posts