c0msherl0ck.github.io

[출처 및 참고]

https://github.com/proneer/Slides/tree/master/Filesystem "(FP) FAT12,16,32 Filesystem.pdf"  (FP) FAT12,16,32 Filesystem.pdf

http://holywaterkim.tistory.com/20?category=810422 "VBR (FAT12/16/32, NTFS) 분석"

http://holywaterkim.tistory.com/3?category=810422 "MBR 분석"


charsyam 과제 "FAT32 에서 폴더 및 파일 탐색하기"


1. MBR 에서 볼륨 시작 주소 찾기

2. 볼륨의 맨 첫번째, VBR 에서 FAT(File Allocation Table) 크기 구하기

3. Data Area 시작 주소 구하기

4. 루트 디렉토리 분석하기

5. 서브 디렉토리 이동하기



1. MBR 에서 뷸륨 시작 주소 찾기



MBR 에서 파티션 테이블 엔트리의 내용은 다음과 같다.


partition type : 0x0B, (FAT32 의미)

LBA Starting Addresss : 0x3F, 63 번째 섹터(볼륨시작주소), Data area 영역을 구하는데 필요

Size in Sector : 0x3C3FC0, 3948480


해당 볼륨의 시작 주소 63 번째 섹터로 이동하면 VBR 의 Boot Sector 를 볼 수 있다.


2. 볼륨의 맨 첫번째, VBR 에서 FAT(File Allocation Table) 크기 구하기



VBR 크기 : 0x1F0, 496 번째 섹터, Data area 영역을 구하는데 필요

FAT32 크기 : 0xF08, 3848 번째 섹터 , Data area 영역을 구하는데 필요



3. Data Area 시작 주소 구하기




Data area 의 시작주소는 : 볼륨시작주소 + VBR 크기 + FAT 크기 * 2


즉, Data area 의 시작주소는 0x3F + 0x1F0 + 0xF08 * 2 = 0x203F , 8255 번째 섹터이다.


루트디렉토리가 클러스터 2번이기 때문에 Data area 의 첫 번재가 루트 디렉토리이다. 만약, 루트 데릭토리가 cluster 2 번이 아니라면 Data area 의 첫번째 영역이 root directory 가 아니다. 


참고 1. 여기서 클러스터 2번이라고 해서 볼륨의 시작주소 + 클러스터크기*2 를 하게 되면 전혀 엉뚱한 주소로 가게된다. 클러스터 2번이라는 의미는 FAT entry 표현에서 Data area 첫번재 주소부터 클러스터2번째로 표현한다는 것이지, 전체 볼륨에서 클러스터 두번째라는 얘기가 아니다.

즉, Data area 의 시작주소부터 cluster 2 번째로 카운트 한다고 생각하면 된다.


참고 2. 루트디렉토리는 Data area 영역의 어느 곳에나 올 수 있으나, 일반적으로 가장 첫번째에 온다.



4. root directory 분석



32 bytes 크기의 directory entry 로 나누어져 있으며, 파일의 이름의 길이가 긴 경우 Long File Name entry 를 통해 표현하고 있다.



위의 엔트리 구조에 따라 루트 디렉토리를 분석하면 다음과 같다.



첫번재 파일 : ① 엔트리

Attr : 0x08(Volume Label), 해당 파일의 이름이 곧 볼륨이름이며, "EVIDENCE" 이다.




두번째 파일 : ②, ③, ④ 엔트리

Attr : 0x16 = 0x10(Directory) + 0x04(System file) + 0x02(Hidden file), 시스템 숨김 폴더이며,  "System Volume Information" 이다.




세번째 파일 : ⑤, ⑥ 엔트리

Attr : 0x10(Directory), 이며 한글폴더로 한글 한 문자당 2 bytes 가 사용된다.(Little Endian 이다.) "리더십"



Name 1(Unicode) : AC B9 54 B3 ED C2 00 00 FF FF

Name 2(Unicode) : FF FF FF FF FF FF FF FF FF FF FF FF

Name 3(Unicode) : FF FF FF FF


0xB9 AC : 리

0xB3 54 : 더

0xC2 ED : 십

0x00 00 : Null (문자열의 마지막에 온다.)

0xFF : 문자가 할당되지 않을 경우 채우는 용


Name : B8 AE B4 F5 BD CA 20 20  -> 의미 없는 한글 깨진 문자.



네번째 파일 : ⑦, ⑧ 엔트리

Attr : 0x10(Directory), 이며 한글폴더로 한글 한 문자당 2 bytes 가 사용된다.(Little Endian 이다.) "성행동 심리학"


Name 1(Unicode) : 31 C1 89 D5 D9 B3 20 00 EC C2

Name 2(Unicode) : AC B9 59 D5 00 00 FF FF FF FF FF FF

Name 3(Unicode) : FF FF FF FF


0xC1 31 : 성

0xD5 89 : 행

0xB3 D9 : 동

0x00 20 : space bar

0xC2 EC : 심

0xB9 AC : 리

0xD5 59 : 학

0x00 00 : Null (문자열의 마지막에 온다.)

0xFF : 문자가 할당되지 않을 경우 채우는 용


Name : BC BA C7 E0 B5 BF 7E 31 -> 의미 없는 한글 깨진 문자



다섯번째, 여섯번째, 일곱번째 폴더 또한 같은 방법으로 분석한다.



5. Sub directory 로 이동하기


디렉토리 엔트리에서 Starting Cluster Hi, Low 를 통해 파일이 위치한 시작 클러스터 주소를 알 수 있다.



세번째 파일 "리더십" 폴더의 시작 주소를 알아보면 다음과 같다.(Little Endian 으로 표현되어 있음에 주의.)


Starting Cluster Hi : 0x00 00

Starting Cluster Low : 0x00 05


Starting Cluster : 0x00 00 00 05


※ 서브 디렉토리의 시작 주소 찾기 (이 개념을 몰라 삽질을 몇번했다.)

Root directory 의 시작클러스터가 2번이므로. 5번 클러스터는 2번클러스터의 시작주소로부터 클러스터 3개만큼의 크기를 더해주면 구할 수 있다.

2번 클러스터의 시작 주소는 루트 디렉토리, Data area 의 시작주소 8255 섹터이다.


sub directory 시작 주소 = root directory 시작주소 + 클러스터 시작 주소 차이 * 클러스터당 섹터 수

8255 + (5-2) * 8 = 8279 번째 섹터이며, 해당 위치로 이동하면 다음과 같다.


현재 폴더를 의미하는 "." 폴더

상위 폴더를 의미하는 ".." 폴더

Long File Name 을 가지는 파일 2개








https://www.cfreds.nist.gov/data_leakage_case/data-leakage-case.html

http://forensic-proof.com/archives/5375 "광학 레코딩 흔적 찾기 (Optical Recording Artifacts)"


#32. What a method (or software) was used for burning CD-R?


어떠한 Third Party App 의 흔적도 발견할 수 없다.

1. [USB 플래시 드라이브에서처럼 사용] 흔적 : 레지스트리 분석

2. [CD/DVD 플레이어에서 사용] 흔적 : 시스템 이벤트 로그(ID : 133), 임시파일(DAT#####.tmp, FILXXXXX.tmp, POSTxxxxx.tmp) 흔적 분석


1. [USB 플래시 드라이브에서처럼 사용] 흔적


HKU\Software\Microsoft\Windows\CurrentVersion\Explorer\CD Burning\Drives\Volume{Volume_GUID}\*

HKU\Software\Microsoft\Windows\CurrentVersion\Explorer\CD Burning\StagingInfo\Volume{Volume_GUID}\*

HKU\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2\{Volume_GUID}\*


위의 레지스트리 경로를 따라 레코딩 흔적을 파악한 결과, 다음과 같이 아무런 흔적도 발견할 수 없었다.


2. [CD/DVD 플레이어에서 사용] 흔적


가. %UserProfile%\AppData\Local\Microsoft\Windows\Burn\Burn(#) 에서의 임시파일을 조사한다.


다음과 같이 흔적을 찾을 수 없다.


나. Log Parser Studio 를 통해, 시스템 이벤트 로그(ID : 133)를 분석한다.


1) 프로그램 실행 후, 다음의 버튼을 클릭한다.


2) Add Files 를 통해 모든 이벤트 로그를 불러온다.


3) Log Type : EVTLOG 를 설정한다.


4) 다음과 같은 쿼리를 질의하여 해당결과를 얻는다. 질의 실행 아이콘은 ! 이다.



다. NTFS_log_tracker 를 이용한 DAT#####.tmp, FILXXXXX.tmp, POSTxxxxx.tmp 흔적 분석


임시 폴더(Burn)에 파일이 복사되고 광학 미디어에 하드 링크가 추가된 상태에서 [디스크 굽기]를 실행하면 다음의 흔적이 남는다.
- 임시 폴더(Burn)의 파일을 “%UserProfile@\AppData\Loca\Temp\DATXXXXX.tmp” 복사
- Temp 폴더에 관련 정보 파일 “FILXXXXX.tmp”, “POSTxxxxx.tmp” 생성
- 시스템 이벤트에 로그 기록
- 작업 완료 후 임시 폴더(Burn) 하위 파일 삭제

1) NTFS_LOG_TRACKER 를 통해 분석된 결과 db 파일을 SQLite 를 통해 분석한다.

다음과 같이 Temp 폴더에 DAT######.tmp, FIL######.tmp, POST######.tmp 이 있던 흔적을 발견할 수 있다.


2) 실제로 WinHex 에서 추출하여 tmp 파일의 확장자를 확인 후 복구하려 하였으나, 해당 임시파일들은 이미 삭제되어 남아있지 않았다.


https://www.cfreds.nist.gov/data_leakage_case/data-leakage-case.html

http://forensic-proof.com/archives/5065 "구글 드라이브 아티팩트 (Google Drive Artifacts)"

http://jeongchul.tistory.com/346 "클라우드 스토리지 포렌식"


#31. Identify account information for synchronizing Google Drive.


sync_log.log 분석 (이전의 글 data leakage case #30 cloud storage forensic for google drive 참고.)


sync_log.log 분석


이메일 주소에는 "@" 가 들어가므로, 로그 파일 내에서 해당 문자를 검색해본다.

다음과 같이 계정주소를 알 수 있다.

https://www.cfreds.nist.gov/data_leakage_case/data-leakage-case.html

http://forensic-proof.com/archives/5065 "구글 드라이브 아티팩트 (Google Drive Artifacts)"

http://jeongchul.tistory.com/346 "클라우드 스토리지 포렌식"


#30. What files were deleted from Google Drive?

Find the filename and modified timestamp of the file.

[Hint: Find a transaction log file of Google Drive.]


1. snapshot.db, sync_config.db 분석

2. sync_log.log 분석


1. Snapshot.db, sync_config.db 분석


snapshot.db : 클라우드/로컬 파일 정보, 파일 간의 연관 관계

sync_config.db : 이메일 주소, 설치 경로, 소프트웨어 버전


가. %UserProfile%\AppData\Local\Google\Drive 에서 파일을 확인한다.

Winhex 상에서 "?" 는 복구 가능성이 존재하는 파일이며, "x" 는 삭제 이후 파일이 덮어 씌워져서 복구가 불가능한 것이다.

snapshot.db, sync_config.db는 용의자가 안티포렌식 행위를 하며 삭제한 것으로 보인다.


나. SQLite 를 통해 보았을 때, 데이터가 존재하지 않는 것을 확인할 수 있다.


2. Sync_log.log 분석


sync_log.log : 동기화 로그


가. sync_log.log 를 sublime text 3 를 통해 열 경우 다음과 같다.


나. 이 로그들 중, 대소문자 구분없이 "delete" 가 있는 라인을 delete.txt 로 따로 추출한다.


delete.txt


다. delete.txt 를 분석하면 다음의 로그가 눈에 띄는데, 해당 로그를 통해 어떠한 파일들이 삭제되었는지 알 수 있다.

common.aggregator:114 --------> Received event RawEvent(DELETE, path=u'\\\\?\\C:\\Users\\informant\\Google Drive\\{파일명}

How to get started with Drive, do_u_wanna_build_a_snow_man.mp3, happy_holiday.jpg 3가지의 파일이 삭제되었다.


https://www.cfreds.nist.gov/data_leakage_case/data-leakage-case.html

http://forensic-proof.com/archives/3584 "클라우드 서비스 흔적 – Cloud Spy"

https://www.researchgate.net/publication/257687927_Digital_Forensic_Investigation_of_Cloud_Storage_Services


#29. Find traces related to cloud services on PC.

(Service name, log files...)


1. 프로그램 설치 경로 확인

2. 링크파일 분석

3. 클라우스 서비스 별 파일 경로를 통해 확인


1. 프로그램 설치 경로 확인


다음과 같이 Google Drive와 관련된 흔적을 찾을 수 있다.



2. 링크파일(.lnk) 분석


Google Drive와 iCloud관련 흔적을 발견할 수 있다.



3. 클라우드 서비스 별 파일 경로를 통해 확인


다음은 클라우드 서비스 디지털 포렌식 수사 관련 파일이다.


DigitalForensicInvestigationofCloudStorageServices.pdf


google drive 에 관한 내용 대신 google docs 에 관한 내용만이 존재하므로 문제를 푸는데 있어서 큰 도움은 되지 않으나, Dropbox, Evernote 의 경우 흔적을 찾는데 도움이 될 것으로 보인다..



https://www.cfreds.nist.gov/data_leakage_case/data-leakage-case.html

http://forensic-proof.com/archives/607 "LNK 파일 포렌식 분석"

https://www.raymond.cc/blog/parse-and-analyze-windows-lnk-shortcut-files/ "6 Free Tools To Analyze Windows LNK Shortcut Files"


#27. List all directories that were traversed in the company’s network drive.

#28. List all files that were opened in the company’s network drive.


1. ShellBagsExplorer 를 통한 폴더 열람 기록 분석 (이전 글 data leakage case #23 참고.)

2. 링크파일(.lnk) 분석

3. 점프목록(jumpList) 분석



1. ShellBagsExplorer 를 이용한 분석


다음과 같이 네트워크 드라이브의 '폴더' 열람 기록을 확인할 수 있다.




2. 링크파일(.lnk) 분석


네트워크 드라이브 상에서 최근에 실행된, 4개의 '문서' 파일을 확인할 수 있다.




3. 점프목록(jumpList) 파일 분석


네트워크 드라이브의 Volume Letter는 'V:'이며 관련 흔적은 다음과 같다.

V:\Secret Project Data\final

V:\Secret Project Data\final\[secret_project]_final_meeting.pptx


이 중 마지막 수정시각(Modified Time) 보다 생성시각(Created Time) 이 이전인 경우를 다음과 같이 선택하였다.

상식적으로 생각한다면 파일의 마지막 수정시각이 생성시각보다 이전이라는 것은 말이 되지 않을 것 같으나,

"파일을 복사할 경우", 수정시각이 변경되지 않고, 생성시각과 접근시각만이 복사한 시간에 맞춰 복사파일이 생성된다.


이를 통해 혐의자가 해당 파일들을 복사하였다는 것을 알 수 있다.


https://www.cfreds.nist.gov/data_leakage_case/data-leakage-case.html

https://www.raymond.cc/blog/parse-and-analyze-windows-lnk-shortcut-files/ "6 Free Tools To Analyze Windows LNK Shortcut Files"

http://forensic-proof.com/archives/1904 "윈도우 7 점프 목록 (Windows 7 Jump Lists)"


#25. List all directories that were traversed in ‘RM#2’.

#26. List all files that were traversed in ‘RM#2’.


1. ShellBagsExplorer 를 통한 분석

2. 링크파일(.lnk)을 이용한 분석

3. 점프목록(jumpList) 분석


#22. USB 흔적 분석에서 RM#1 과 #RM#2가 'E:' 드라이브로 마운트 되었던 기록을 확인할 수 있으며, 해당 드라이브와 관련된 폴더 및 파일 열람 흔적을 분석한다.


1. ShellBagsExplorer를 통한 분석


다음과 같이 E 드라이브에 마운트 되었던 장치의 폴더 및 파일 열람 정보를 알 수 있다.

(이전 글 #23 참고.)


E: 드라이브 하위 폴더 중, RM#1의 하위 폴더를 제외한 Secret Project Data의 하위 폴더가 RM#2에서 탐색된 폴더이다.



2. 링크파일(.lnk) 분석


다음과 같이 E 드라이브에서 최근에 실행되었던 '문서' 파일 2개를 확인할 수 있다.

그러나, 해당 파일은 RM#2가 아닌 RM#1의 흔적이다.




3. 점프목록(JumpList) 분석


점프목록이란?

"작업 표시줄에 나타나는 응용프로그램에 마우스를 위치시킨 후 마우스를 우클릭하면 해당 응용프로그램으로 최근에 열거나 사용했던 파일들이 표시된다. 이를 점프 목록이라 부른다." (출처 - http://forensic-proof.com/archives/1904 "윈도우 7 점프 목록 (Windows 7 Jump Lists)")


가. 다음 경로의 폴더를 Recover/Copy 한다.


C:\Users\[UserProfile]\AppData\Roaming\Microsoft\Windows\Recent\AutomaticDestinations

C:\Users\[UserProfile]\AppData\Roaming\Microsoft\Windows\Recent\CustomDestinations


AutomaticDestinations(이하 AutoDes) : 최근 사용한 목록(Recent)이나 사용자가 고정(Pinned)시킨 목록

CustomDestinations(이하 CustomDes) : 자주 사용되는 목록(Frequent)이나 작업(Tasks) 목록



나. nirsoft 의 JumpListView 를 통해 분석한다.


다음 그림은 readme.txt 의 일부이다.

(윈7, 8, 10, 32bit 64bit 를 다 지원한다.)



다. 최초 실행시 Host-PC 의 JumpList 를 분석하나, [Options] - [Advanced Options] 기능을 통해 분석하고자 하는 PC 의 점프목록 파일을 로드할 수 있다.




라. (가) 에서 복구한 2개의 폴더가 있는 폴더를 지정한다.

(필자는 #jumpList 폴더에 AutomaticDestinations, CustomDestinations 를 복구하였다.)



마. 다음과 같이 최근에 열람한 파일 및 폴더들을 확인 할 수 있다.


E:\Secret Project Data\design\winter_whether_advisory.zip 이 RM#2에서 탐색된 압축파일이다.


이외에도 생성시각(Created Time)보다 수정시각(Modified Time)이 빠른 경우를 다음과 같이 선택하였다.

상식적으로 생각한다면 파일의 마지막 수정시각이 생성시각보다 이전이라는 것은 말이 되지 않을 것 같으나,

"파일을 복사할 경우", 수정시각이 변경되지 않고, 생성시각과 접근시각만이 복사한 시간에 맞춰 복사파일이 생성된다.


이를 통해 혐의자가 해당 파일들을 복사하였다는 것을 알 수 있다.


Full Path 에서 Volume letter

-E: USB 의미

-v: network drive 의미


https://www.cfreds.nist.gov/data_leakage_case/data-leakage-case.html

http://holywaterkim.tistory.com/46?category=811084


#24. What is the IP address of company’s shared network drive?


ShellBagsExplorer 를 통한 분석(이전 글 data leakage case #23 참고.)


https://www.cfreds.nist.gov/data_leakage_case/data-leakage-case.html

http://holywaterkim.tistory.com/19?category=811084

http://forensicinsight.org/wp-content/uploads/2013/07/F-INSIGHT-Advanced-UsnJrnl-Forensics-Korean.pdf

http://jxo21.tistory.com/14 "Registry Shellbag"

http://forensic-proof.com/archives/2109 "윈도우 검색 포렌식"


#23. Identify all traces related to ‘renaming’ of files in Windows Desktop.

(It should be considered only during a date range between 2015-03-23 and 2015-03-24.)

[Hint: the parent directories of renamed files were deleted and their MFT entries were also overwritten. Therefore, you may not be able to find their full paths.]


1. 파일시스템 로그 분석(NTFS Log Tracker) : Renaming에 대한 직접적인 흔적

2. ShellBags 분석(ShellBagsExplorer) : 사용자의 폴더 열람 기록

3. Windows Search database 분석(WinSearchDBAnalyzer) : 윈도우 내 존재했던 폴더, 파일 기록


1. 파일시스템 로그 분석


가. NTFS Log Tracker에 다음의 파일을 입력하여 파일시스템 로그 정보를 추출한다.

$UsnJrnl : C:\$Extend\$Usnjrnl:$J

$MFT : C:\$MFT

$LogFile : C:\$LogFile


나. SQLite Expert Personal 를 이용해 해당 db 를 분석한다.

쿼리는 다음과 같으며 각 라인에 대한 설명을 첨부하였다.


1) select * from UsnJrnl where event like '%file_renamed%' 

2) and timestamp > '2015-03-23 00:00:00' and timestamp < '2015-03-25 00:00:00' 

3) and (fullpath like '%informant_desktop%' or fullpath is '') 

4) and fileattr is 'Archive'


1) renaming 된 파일을 찾기 위한 event 명

2) 2015-03-23 ~ 2015-03-24 기록

3) fullpath is '%informant_desktop%' 는 informant 계정의 바탕화면 경로이다.

   fullpath is '' 는 문제의 힌트에 설명되어있듯이, 해당 파일이 있던 부모 디렉토리가 삭제되었을 경우 fullpath 를 알 수 없기 때문이다.

4) fileattr 은 폴더인지 파일인지 구분하는 필드이며, 파일만 보기 위해 Archive 라는 옵션을 주었다.


[참고] $UsnJrnl의 각 필드별 의미


TimeStamp 가 동일하고, Event 가 File_Renamed_Old, File_Renamed_New, File_Renamed_New/Closed 3개가 연속으로 나타나는 것이 파일의 이름을 바꾼 행위에 대한 기록이다.




2. ShellBags 분석


ShellBag 이란?

쉘백은 최초로 폴더를 열람 시 생성된다. 이외에도 폴더를 생성, 복사, 압축 프로그램에 의해 실행되었을 경우에도 생성된다.




가. Eric Zimmerman's tools 중, ShellBagsExplorer을 처음 실행시키면 다음과 같이 초기 설정을 할 수 있으며, 이후에 옵션탭을 통해 변경할 수 있다.

time zone 을 분석 PC에 맞게 설정한다. (UTC-4) 


나. [File] - [Load offline hive] 에서 분석할 계정의 NTUSER.DAT 과 UsrClass.dat 을 선택한다.

(동시에 여러개 선택이 안되서 각각 선택 후 분석해야 한다.)


다. 다음과 같이 실행결과에 대한 창이 뜬다.


라. [Tools] - [Expand tree nodes] 를 클릭하면 tree 구조가 전부 펼쳐진다.


마. informant 사용자가 열람했던 폴더 구조를 살펴볼 수 있다.


3. Windows Search Database 분석


Windows.edb 란?

Windows.edb 파일에는 윈도우 검색에 사용하기 위한 색인 정보가 저장되어 있다. 윈도우 검색 색인 정보는 사용자가 정의하지 않더라도 사용자의 기본 폴더, 이메일, 인터넷 히스토리 등의 정보가 저장되므로 포렌식 분석에 큰 도움이 될 수 있다.

Windows Vista/7 : %ProgramData%\Microsoft\Search\Data\Applications\Windows


가.  Windows.edb 파일을 Recover/Copy 한다.


나.  WinSearchDBAnalyzer를 이용해 해당 파일을 분석한다.


https://www.cfreds.nist.gov/data_leakage_case/data-leakage-case.html

http://forensic-proof.com/archives/3632 "윈도우에서 USB 흔적 추적하기 (USB Device Tracking on Windows)"

http://forensic-proof.com/archives/276 "마운트된 장치 GUID 분석하기 (Mounted Devices GUID Analysis)"

http://forensic-proof.com/archives/5945 "윈도우 7 장치 연결/해제 이벤트 로그 (Windows 7 Device Tracking Event Log)"

https://docs.microsoft.com/ko-kr/windows-hardware/drivers/install/hklm-system-currentcontrolset-control-registry-tree

https://www.blackbagtech.com/blog/2017/02/14/analyzing-usb-entries-in-windows-7/

https://www.forensicswiki.org/wiki/USB_History_Viewing

http://orionforensics.com/w_en_page/USB_forensic_tracker.php "USB Forensic Tracker"


#22. List external storage devices attached to PC.


1. SetupAPI 로그 분석(setupapi.dev.log) 을 통한 최초 장치 연결 시각

2. 레지스트리 분석

3. 이벤트 로그 분석을 통한 연결 해제 시각

4. USB Forensic Tracker를 통한 분석


1. SetupAPI 로그 분석(setupapi.dev.log)


Windows 2000/XP : %SystemRoot%\Setupapi.log

Windows Vista/7/8 : %SystemRoot%\inf\Setupapi.dev.log


가. 위 경로의 파일을 recover/copy 한다.


나. log 파일을 확인하면 다음과 같이, device 가 연결되었을 때의 "드라이버 설치과정"이 기록되어 있다. "최초 연결 시각"을 알 수 있다.

It should be noted that the dates and times listed in this log are in local time

(using the offset applied to the computer at the time of entry).  

즉, 기록되는 시간값이 분석대상 PC의 timezone이 적용된 local time 으로 기록된다.



setupapi.dev.log


2. 레지스트리 분석


HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USBSTOR

HKLM\SYSTEM\MountedDevices

HKU\{USER}\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\EMDMgmt\{Device Entry}

HKLM\SOFTWARE\Microsoft\Windows Portable Devices\Devices\{Device Entry}

HKLM\SYSTEM\ControlSet00#\Control\DeviceClasses\{숫자}\{Sub Keys}


가. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USBSTOR

This registry entry tracks USB storage devices that have been connected to the computer.  This is where Windows will record the manufacturer information along with the serial number as read from the device.


USB의 serial numberFirst connection time 을 알 수 있다.


나. HKLM\SYSTEM\MountedDevices


"MBR이 존재하는 디스크의 경우 사용자가 특별하게 해당 레지스트리 값을 지우지 않는다면 MountedDevice에 GUID 값이 저장된다. 각 값의 데이터에는 12바이트의 값이나 12바이트 이상의 값들이 존재한다. 12바이트의 문자는 MBR의 정보(디스크 시그니처 + 볼륨시작위치)를 이용해 생성하지만 그보다 긴 값들을 운영체제가 임의로(미리 정의된 형식) 생성한다. Data 값이 동일하고 Value Name 부분만 다른 케이스들을 확인 할 수 있는데, Volume GUID, 드라이브 문자 2가지로 표현한 것이며 동일한 장치를 의미한다."


위의 그림에서는 Data 값이 같은 것끼리 묶었을 때 총 6개가 확인가능하며 Data 크기에 따라 다음과 같이 해석한다.


1) Data 크기가 12 bytes 인 경우의 해석 (USB Drive Enclosure, 내장/외장 하드 디스크)

12 bytes = Disk signature (4 bytes) + volume start address (8 bytes)


1.1) \??\Volume{c9a1c040-d2d7-11e4-9dae-806e6f6e6963} / \DosDevices\C: / \??\Volume{c9a1c041-d2d7-11e4-9dae-806e6f6e6963}

위 그림의 위에서부터 3가지 항목의 Disk signature 가 20-57-26-F0 동일하므로 같은 로컬 고정 디스크이며,

시작위치정보는 각각 Little Endian 으로, 00-00-10-00-00-00-00-00, 00-00-50-06-00-00-00-00 이다.


MBR partition table 에서 확인해보면 다음과 같이 일치하는 것을 알 수 있다.

- Disk signature : 20 57 26 F0

- partition 1 시작위치 : 0x800 * 0x200(512bytes) = 0x100000

- partition 2 시작위치 : 0x32800 * 0x200(512bytes) = 0x6500000



1.2) \DosDevices\E: / \??\Volume{a2f2048e-d228-11e4-b630-000c29ff2429}

Disk Signature : 4C 03 21 E2

1.3) \??\Volume{662626a6-d181-11e4-9591-000c29ff2429}

Disk Signature : D8 03 21 E2


2) Data 크기가 12 bytes 이상인 경우의 해석 (USB Thumbdrive, CD, DVD)

Data 를 Unicode로 디코딩한다.

2.1) \DosDevices\A: / \??\Volume{c9a1c045-d2d7-11e4-9dae-806e6f6e6963}
interpreted data : \??\FDC#GENERIC_FLOPPY_DRIVE#6&3b4c39bd&0&0#{53f5630d-b6bf-11d0-94f2-00a0c91efb8b}
# 을 구분자로 한다.
- Device Class Identifier : GENERIC_FLOPPY_DRIVE
- Serial Number : 6&3b4c39bd&0&0
- Volume Label : 추가적인 정보가 없다.
- Volume Serial Number : 추가적인 정보가 없다.

2.2) \DosDevices\D: / \??\Volume{c9a1c044-d2d7-11e4-9dae-806e6f6e6963}
interpreted data : \??\IDE#CdRomNECVMWar_VMware_SATA_CD01_______________1.00____#6&373888b8&0&1.0.0#{53f5630d-b6bf-11d0-94f2-00a0c91efb8b}
# 을 구분자로 한다.
- Device Class Identifier : CdRomNECVMWar_VMware_SATA_CD01_______________1.00____
- Serial Number : 6&373888b8&0&1.0.0
- Volume Label : 추가적인 정보가 없다.
- Volume Serial Number : 추가적인 정보가 없다.

다. HKU\{USER}\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2

계정별 마운트된 저장장치의 GUID 값을 확인할 수 있다.

즉, 해당계정의 사용자가 해당 장치를 마운트 한 것이다.


The Last Write Time listed is the last time this device was connected (by that user).

해당 키의 수정 시각이 "마지막 연결 시각", Last connection time


1) informant

##10.11.11.128#secured_drive

\??\Volume{662626a6-d181-11e4-9591-000c29ff2429}  Disk Signature : D8 03 21 E2

\DosDevices\E: / \??\Volume{a2f2048e-d228-11e4-b630-000c29ff2429}  Disk Signature : 4C 03 21 E2

\DosDevices\C: / \??\Volume{c9a1c041-d2d7-11e4-9dae-806e6f6e6963}

\DosDevices\D: / \??\Volume{c9a1c044-d2d7-11e4-9dae-806e6f6e6963} CD-ROM


2) admin11

\DosDevices\C: / \??\Volume{c9a1c041-d2d7-11e4-9dae-806e6f6e6963}

\DosDevices\D: / \??\Volume{c9a1c044-d2d7-11e4-9dae-806e6f6e6963} CD-ROM


3) temporary

\DosDevices\C: / \??\Volume{c9a1c041-d2d7-11e4-9dae-806e6f6e6963}

\DosDevices\D: / \??\Volume{c9a1c044-d2d7-11e4-9dae-806e6f6e6963} CD-ROM


위의 결과로 볼때, informant 계정의 사용자가 C: D: 기본 드라이브 이외에, 2개의 저장장치를 추가적으로 연결하였음을 알 수 있다.


라. HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\EMDMgmt\{Device Entry}

Volume label 을 확인할 수 있다.



마. HKLM\SOFTWARE\Microsoft\Windows Portable Devices\Devices\{Device Entry}

아래와 같이 정보가 없다.



바. HKLM\SYSTEM\ControlSet001\Control\DeviceClasses\{숫자}\{Sub Keys}

해당 키의 수정 시각이 "부팅 후 최초 연결 시각"이다. First Connection Time After Booting

아래의 그림은 하위키 중 USB, storage, CD-ROM 해당하는 부분을 확인한 것이다.





3. 이벤트 로그 분석


장치가 연결 해제되면 관련 정보를 이벤트 로그에 기록한다.

%SystemRoot%\System32\winevt\Logs\Microsoft-Windows-DriverFrameworks-UserMode%4Operational.evtx

해당 이벤트 로그를 분석하면, "마지막 연결 시각"을 알 수 있다. Last Connection Time


Security Log Audit Plug and Play Activity

6416: A new external device was recognized by the System.

6419: A request was made to disable a device.

6420: A device was disabled.

6421: A request was made to enable a device.

6422: A device was enabled.

6423: The installation of this device is forbidden by system policy.

6424: The installation of this device was allowed, after having previously been forbidden by policy.

Microsoft-Windows-Partition/Diagnostic

1006: May contain Manufacturer, Model, Serial, and raw Partition Table, MFT, and VBR data.


분석 대상 PC 에는 해당 이벤트 로그가 기록이 되어 있지 않다. 혐의자가 안티포렌식 행위를 한 것으로 보여진다.


일반적으로 다음과 같이 로그가 남겨진다.


4. USB Forensic Tracker v1.1.1 를 통한 분석


가. 프로그램 실행 후, Mount Forensic Image 를 클릭한다.



나. Mount E01 Image 를 클릭한다.



다. E01 image 를 클릭한다.



라. Write temporary 옵션을 선택한다.



마. 마운트된 드라이브 문자를 확인한다.



바. 해당 드라이브 문자를 선택 한 후, Run 한다.



사. 다음과 같이 1. 2. 3. 에서 했던 결과물들을 간편히 확인할 수 있다.