[ccibomb@CRG]# _bykim

10.    Shortcut Analysis

10-1.    Link Files 분석 개요

-      바탕화면, 최근문서, 시작메뉴, Send to 폴더 등에는 shortcut 형태의 증거들이 있다. Shortcut 파일들은 타겟 파일(어플리케이션, 디렉토리, 데이터 파일, 프린터 등)에 대한 정보를 가지고 있다. 이를 분석하여 필요한 정보를 추출해낼 수 있다.

10-2.    Link File 생성 시기

-      사용자가 의도적으로 생성시

-      프로그램 설치시

-      쉘(explorer)이나 OS가 파일 실행시

10-3.    Link File 골라내기 (Condition 기능 이용)

Conditions - Extention - Match – lnk

Conditions - FileType - equal to - LINK 로 등록하여 확인

10-4.    Link File 활용 (Link File의 MAC Time 정보)

① Link파일 안에는 Link file 생성 당시의 타겟 파일의 MAC Time 정보(CAM 정보)가 기록되어 있다.

a.     Windows : Created, accessed, modify

b.    Linux : Modify, accessed, changed

② Windows에서 개개의 날짜/시간 정보는 8bytes로, Link File에서 MAC Time 정보는 Offset 28번에서부터 24bytes에 표현된다.

File Created Time (타겟 파일 생성 시각)과 Last Written (마지막 수정 시각)이 몇 초 차이나는 경우에는 해당 파일의 '다운로드' 가능성을 의심해볼 수 있으며, 이 두 시각이 동일할 경우 '복사' 가능성이 있다.

③ USB를 PC에 꽂아 어떤 파일을 설치 또는 사용하였는지 여부를 확인하여 인지사실에 대한 증거로 사용하려는 경우, Link File의 시간정보를 가지는 Volume Serial Number (타겟 파일의 위치를 나타내는 값 앞 10을 찾고 그 전 4바이트)와 USB 파일시스템 내부의 Volume Serial Number를 비교하여 찾을 수 있다. 해당 Target 파일이 들어있는 파일시스템의 Volume Serial Number가 Link File에 부여되기 때문이다.

                        // Hex ‘10’을 찾은 후, 그 앞 4 bytes가 Volume Serial Number (Unicode)

// Encase의 Report 탭으로 확인한 Link File의 Volume Serial Number

이를 USB 파일시스템 내부의 Volume Serial Number와 동일한지 비교하여 추출한다.

11.    참고문헌

-      File System Forensic Analysis, Carrier  저,|Addison-Wesley, 2005.01.01

-      Encase Computer Forensics--the Official Ence (Paperback / 2nd Ed.)   (Encase Certified Examiner Study Guide), Bunting, Steve  저, John Wiley & Sons Inc, 2007.09.12

-      Encase Forensic Academic Program Students Guide, Guidance

12.    도움주신 분들

-      이지스원 시큐리티 보안팀장 김 태 일

-      이지스원 시큐리티 연구원   이명수, 주한익

-      경찰수사연수원 사이버 교수 유    현

-      국립 경찰 대학 사이버 교수 장 윤 식

-      육군 사관 학교 사이버 교관 유 정 호

9.   Hash Analysis

9-1.       Hash 함수

-      임의의 메시지를 입력 받아 고정된 사이즈의 결과값을 출력한다. 고정된 사이즈는 어떤 알고리즘을 사용하느냐에 따라 달라짐 MD5는 128비트이다.

-      h=H(M)    :   Hash value 또는 Message Digest(메시지 요약)를 사용하는

이유는 대체로 메시지 사이즈보다 Hash 사이즈가 작고, 동일한 메시지에 대해 항상 같은 결과가 나오기 때문이다.

-      h가 주어졌을 때 메시지 M의 내용이나 M과 관련된 어떠한 정보도 계산해 내거나 추출할 수 없는 단방향성을 지니고 있다. 즉, 역함수가 없다.

-      Collision-resistance(메시지는 다른데 결과값이 같은 경우)는 거의 없다.

eg.  MD5) 1 / 340,282,366,920,938,463,463,374,607,431,768,211,456

9-2.       Digital Forensic 에서 Hash 함수의 용도

-      증거의 무결성을 검증하기 위해 사용한다.

디지털 증거는 조금이라도 조작되었을 경우 크게 다른 결과를 가져올 수 있으므로 무결성을 검증하는 것이 매우 중요하다.

9-3.       Hash 분석의 방식

①  Negative Hash analysis

1. 의의
• Known-good hash set을 이용하는 hash 분석 방법

2. 조사방법

• 증거이미지에 포함된 파일의 hash값을 모두 발생

• Known-good hash set과 비교하여 매칭되는 파일을 조사 목록에서 제거

②  Positive Hash analysis

1. 의의
• Known-bad hash set을 이용하는 hash 분석 방법

2. 조사방법

• 증거이미지에 포함된 파일의 hash값을 모두 발생

• Known-bad hash set과 비교하여 매칭되는 파일을 모두 조사

9-4.       Hash set

① 의의  : 선택한 파일의 해쉬값을 모아놓은 DB

② 종류

1. Known-good Hash set

·         정상적인 파일의 hash 값 집합

·         조사할 필요가 없는 파일의 hash값의 Data Base

·         OS의 버전이 다양하기 때문에 만들기 힘들다.

·         c.f) NSRL(National Software Reference Library) : 미국의 NIST 산하에서 프로젝트로 만든 known-good hash set으로서, 우리나라 환경에는 잘 맞지 않지만 매우 유용하게 사용될 수 있다. 우리나라도 환경에 맞는 known-good hash set이 필요하다. (참조 : http://www.nsrl.nist.gov/)

                                     ii.        Known-bad Hash set

·         해킹에 사용된 툴, 악성코드 등 조사할 필요가 있는 파일의 hash값의 Data Base

9-5.       Empty파일(size가 0인 파일) 제거

-      컴퓨터 상에는 size가 0인 파일이 많은데, 이는 특정 파일이 특정 프로그램의 존재여부와 관련된 경우와 같이 조사가 필요한 특별한 경우가 아니면 조사할 필요가 없다.

-      Encase는 기본적으로 비어있는 파일에 대한 Hash값을 가지고 있다.

-      Hash 분석을 하면 기본적으로 Hash set에서 Empty file으로 분류한다. Category는 known으로 분류되어 있다.

-      c.f) Size가 0인 파일 만들기 : (Windows) Fsutil file createnew [파일명] [size]

(Linux) touch [파일명]

 9-6.       Hash set 생성 실습 (Hash set은 생성 후 Rebuild 필요)

① View - hash set 에서 hash sets 탭을 만든다.

② Cases entry에서 해시 값 만들 파일들을 선택한 후 Search 기능 이용하여 hash값 만들어낸다.

// Selected items only  : 선택된 파일만

Compute hash value  : hash값 생성

③ Hash set 탭에서 New 기능을 통해 Hash set 추가

   (도출된 Hash값을 Known으로 등록)

1. New hash set에서 Category는 Notable, Known 두 가지만 사용하는 것이 좋다. 이는 Guidance 社의 권고사항으로, Enscript가 이 두 가지 Hash set을 가정하고 작성된 것이 많기 때문에 이를 활용하기 위함이다.

                                     ii.        Known  : Known-good Hash set

Notable : Known-bad Hash set

             // Hash Set이 만들어졌다.

Encase가 설치된 폴더의 Hash Sets 폴더에 저장되며, 복사 가능하다.

 ④ Rebuild 필요

Hash set 생성 후 당장은 사용이 안 된다. 해당 Hash set을 체크한 후 Rebuild 하거나(우클릭- Rebuild Library) 다시 껐다 켜야 한다.

9-7.       Hash set을 이용한 조사 실습 (Conditions 활용)

① 필요한 Hash set 선택 후, Search- Compute hash value 체크 -> Search!

② 우측 하단의 필터 pane을 이용하여 조사 파일의 양을 줄일 수 있다.

예를 들어, Hash category가 known인 것은 제거할 수 있다.

Condition : 해당 조건에 맞는 데이터만 보는 것이 가능하다.

(Enscript로 이루어짐. C++ 문법과 유사함)

 ③ Known Files 는 제외하고 필터링한 결과

④ Query 버튼을 누르면 조건이 적용된다.

선택적 적용은 Display 탭에서 체크한다.

⑤ 참고 : Hash 카테고리 Known 인 파일을 제외시키는 Condition 만들기

                                      i.        New Condition (Name : Remove Known Files)

                                     ii.        함수 추가 New

(Properties : Hash Category, Operator : equal to, Value : Known)

                                   iii.        Not 적용

                                    iv.        직접 입력하여 생성된 Condition

                                     v.        이를 Run 해보면, Known Files는 제외되는 것을 볼 수 있다.

           // 적용 전

 

                     // 적용 후  : Known Files 가 보이지 않음

8.   Signature Analysis

8-1.       개요

Signature Analysis는 확장자가 변경된 파일 식별이 주 목적이다.

대부분의 프로그램에서 확장자를 보고 파일 타입을 결정하는 것이 문제의 소지가 될 수 있으므로, 기록된 확장자와 파일의 실제 Signature 를 분석하여 일치하는 지를 확인하는 작업이다.

8-2.       Signature

어떠한 파일타입인지를 나타내는 코드

보통 파일의 앞 부분

JPG 의 경우 FF D8 , MP3 의경우 ID 3 로 시작함.

Encase 의 View 메뉴에 가면 File Signatures 메뉴가 있다.

8-3.       Encase에서 Search (Verify file signatures 체크) 후 결과 표시

8-4.       Signature Search 시 필터링

Signature contains [*]    :  *포함한 것

or Signature contains [!]  : 복합조건 (조건을 더 만든다.)

c.f) 복합조건 생성시 논리연산자가 자동으로 or 로 됨.

and 로 바꾸려면 ‘change logic’을 하면 된다. (우클릭 – logic)

8-5.       새로운 File Signature 등록 (Multimedia - new) : Rebuild 불필요함

                      예시 : Mp3 파일 등록

Search expression - '\x49\x44\x33'

GREP - 16진수, 정규식 사용시

Case Sensitive - 대소문자 구별, Signature : ID3

 Extentions : mp3

 Name : mp3 Audio file

 

c.f) File Type 은 DB가 별도로 있어 별도 등록 필요함. Viewer는 개별설정 가능함

 8-6.       File Signature 분석하는 방법

파일 표준이 있을 경우 분석자료를 참고한다.

파일 샘플을 여러 개 가져다 놓고 비교 분석한다.

파일 signature를 분석해놓은 사이트를 참조한다.

(eg. http://www.garykessler.net/library/file_sigs.html/)

8-7.       File Signature 확인 실습

① Search – Verify file signatures

② Searching

③ Finish

④ Result

8-8.       Signature 위치에 따른 파일 인식 여부

① Signature가 File의 시작이 아닌 중간에 위치한 경우 인식 여부 확인

  정상적인 JPG 파일 (VMware.jpg)

 

Signature를 중간으로 옮긴 경우 (VMware2.jpg)

 



② File 내 여러 개의 Signature가 있는 경우 인식 여부 확인

정상적인 JPG 파일의 중간에 png 파일의 Signature 삽입 (VMware3.jpg)

③ Encase에서 인식 결과

-      Signature 를 중간으로 옮긴 (VMware2.jpg)의 경우 “! Bad signature”

즉, Signature는 각 파일의 맨 앞에 위치하여야 함

-      Signature 가 중복된 (VMware3.jpg)의 경우 정상적인 JPG 파일로 인식함

즉, Signature는 각 파일의 맨 앞에 위치한 하나만 인식함

8-9.       MS Office File Signature

① 2003 ver. 이하 문서 (xls, doc, ppt)

-      Password 유무 상관 없이 동일한 Signature 지님 : 구분 불가능!

Signature : D0 CF 11 E0 A1 B1 1A E1

-      Encase에서는 세 개 파일 모두 동일한 File Signature에 등록되어 있음

Encase 에서는 xls, doc, ppt 모두 Compound Document File에 등록됨

따라서 이 세 개의 확장자 중에서 서로 바꾸는 경우에도 Match 로 인식됨

② 2007 ver. 문서 (xlsx, docx, pptx)

-      암호 유무에 따라 서로 다른 Signature 지님

암호가 없는 경우 공통 Signature : 50 4B 03 04

암호가 걸린 경우 공통 Signature : D0 CF 11 E0 A1 B1 1A E1 (2003과 동일)

 



-      Encase 의 File Signature Table 에서 확인

암호가 없는 경우 공통 Signature : 50 4B 03 04 는 ZIP Compressed에 ‘zip, docx, pptx, xlsx’ 확장자와 함께 등록되어 있음. 따라서 상호간 확장자를 바꾸어도 Encase는 Match로 인식함

암호가 걸린 경우 D0 CF 11 E0 A1 B1 1A E1 는 2003의 경우와 동일하게 Compound Document File에 File Signature로는 등록되어 있으나, 확장자(xlsx, docx, pptx)는 등록되어 있지 않으므로 Encase는 * (Alias) 로 인식함

③ 결론

Office 2003 문서(암호 유무 상관 X)의 Signature

= Office 2007 문서(암호 O)의 Signature

= ZIP 파일(암호 유무 상관 X)의 Signature

7.   Web History Analysis

Web History 라는 것은 피의자가 어떤 웹사이트에 언제 접속했는가를 찾기 위한 중요한 단서가 된다. (웹히스토리는 사용자가 브라우저를 통해 웹을 방문할 때, 그 방문 접속 기록을 가지고 있는 파일들이다.) 그리고 실제 수사에서도 가장 많이 사용되는 기록 중에 하나이다.

예를 들어 특정 사용자의 웹 히스토리 중 위와 같은 폴더를 확인했을 때, 이 데이터로부터 조사관은 사용자가 gmail과 hotmail 이메일 주소를 가지고 있고, tdbanknorth라는 온라인 뱅킹을 이용하며, 디지털 포렌식 웹사이트에 관심이 있고, 아마도 Champlain에 있는 대학을 다니고, 그 지역 아파트에 대해 알아보고 있다는 추측이 가능하다.[i]

또한 다운로드 받은 파일을 마지막으로 저장한 폴더를 보여주는 경우, 조사관은 사용자가 파일들을 어디에 저장하는지 알 수 있으며, 이 밖에도 로그로 활용하기 위한 정보가 담겨있기도 하며, 이에는 웹 브라우져의 자동 로그온 아이디와 비밀번호, 검색어 등이 날짜, 시각 정보와 함께 저장되어 있다. 자동 완성 비밀번호 웹 페이지가 인코딩되어 저장되기도 한다.

Encase 에서 웹 히스토리를 분석하는 것은 간단하다.

   툴바의 Search 를 선택한다.

이 때 오른쪽 아래에 Search for internet history 를 체크해주면, 현재 추가된 증거들에서 자동으로 웹 히스토리 파일들을 찾아서 분류해준다.

결과는 Entries 탭이 아닌 Record 탭(View->Cases->Records)에서 볼 수 있다.

Encase에서는 다음과 같은 웹히스토리 파일이 분석 가능하다.

-       Internet Explorer - Windows, Mac

-      Mozilla( Netscape, Firefox ) - Windows, Mac

-       Opera - Windows, Mac and Linux

-       Safari - Mac

  참고사항 : Index.dat

 Internet Explorer의 경우 Index.dat 파일을 이용하여 브라우져의 사용에 관한 정보를 유지하는데, Index.dat 파일은 Cookies, History, Temporary Internet Files 폴더 등의 정보가 위치한다. 다양한 Index.dat 파일은 그 구조는 유사하지만, 서로 다른 타입의 데이터를 저장한다.

   Cookies – 웹사이트에 의해 컴퓨터 시스템에 저장된 데이터.

.TXT 파일들이 실제 쿠키들을 나타내며,

Index.dat 파일은 각 쿠키 기록을 따른다.

Temporary Internet Files Index.dat – Internet Explorer를 통해 접근한 웹페이지에

나타난 파일들을 포함한다. 캐쉬 파일들은 컴퓨터에 저장될 때, 이름이 변경되는데 Index.dat는 이러한 변경 정보를 기록한다.

  Main History Index.dat – 전반적인 현재 히스토리

  Daily History Index.dat – 날짜 범위를 포함하는 폴더 저장.

예를 들어, ‘MSHist012010050420100505’는 2010년 5월 4일 하루의 히스토리를 의미한다.

   Weekly History Index.dat – 날짜 범위를 포함하는 폴더 저장.

예를 들어, ‘MSHist012010050220100508’의 경우 2010년 5월 2일~8일 주를 의미한다.

   위의 Main, Weekly, Daily History Index.dat는 Internet Explorer 외에도 Windows Explorer를 통해 접근한 Local 파일에 대한 히스토리도 기록한다.

Case ④ 각각의 Partition의 VBR이 모두 손상된 경우

-      복원 전 MBR : Partition Table Layout

-      하드 전체 Layout

-      하드디스크 정보 (229,824 Sectors, 112.2MB)

-      인식 오류 발생 원인

Encase로 불러왔을 때, 아무런 파티션도 인식하지 못한 상태이다.

해당 디스크의 MBR을 확인해 보았다. MBR에는 2개의 파티션 정보가 나타나 있다. 해당 정보에 따르면, 첫 번째 파티션 시작 위치는 63섹터, 두 번째 파티션 시작 위치는 128520 섹터이다. 그러나 해당 섹터(VBR)는 모두 손상되었다.

즉, MBR은 손상되지 않았지만, 각각 파티션들의 VBR이 손상되었다.

a.       MBR의 Partition table을 보고, 각 Partition의 시작 위치 확인

b.       첫 번째 파티션의 시작 위치인 63 sector에서 VBR 손상 확인

c.       두 번째 파티션의 시작 위치인 128520 sector에서 VBR 손상 확인

-      복원 과정

VBR이 손상되었을 때에는, VBR 백업본을 이용하여 복원할 수 있는 가능성이 존재한다. NTFS의 경우 파티션의 가장 마지막 섹터에 백업 되며, FAT32의 경우 보통 VBR에서 6번째 섹터에 기록되어 있다. 각각 파티션의 백업 VBR의 존재를 확인 후 손상된 VBR의 위치에 덮어쓰는 방법으로 복원할 수 있다.

a.     첫 번째 파티션의 VBR (63 sector) 바로 다음 섹터 확인

// NTLDR 관련 정보가 있는 것으로 보아 NTFS인 것으로 추측.

NTFS의 경우 VBR의 백업본이 맨 마지막 sector에 저장되어 있음

b.    첫 번째 파티션의 맨 마지막 섹터 (128519 sector) 확인

// NTFS 파일시스템 파티션 VBR 이 백업되어 있음

c.     두 번째 파티션의 시작위치(128520 sector)로부터 6 sector 뒤 확인

// FAT32 파일시스템 파티션 VBR이 백업되어 있음

d.    WinHex로 dd 이미지를 읽음

(Encase Forensic Training버전에서는 Disk Emulate 기능 없으므로 직접 수정이 불가하므로 WinHex를 이용하여 VBR 백업본을 직접 손상된 VBR에 덮어써서 복원 후 마운트해야 함)

e.     Encase를 통해 이미 확인한 VBR 백업본을 원래의 VBR 위치에 덮어씌움

   // NTFS의 VBR 백업본

                  // FAT32의 VBR 백업본 

-      복원 완료

a.       Encase로 확인

Winhex에서 저장 후 Encase에서 Raw Image로 불러들여 읽음

 // 정상적으로 C, D 드라이브가 인식된 것을 확인

b.       Linux의 Loop Device로 Mount하여 정상 인식되는지 확인

b-1.  dd 파일의 정보 확인 (Encase로 확인한 바와 동일함)

           c.f) MMLS filesystemrecovery.dd 를 이용하여도 Partition 정보 확인 가능

MMLS는 Sleuthkit Tool 중 하나로, 분석할 디스크 레이아웃과 전체 파티션 스키마 취득, 물리적 디스크만 분석 가능 (스냅샵으로 획득한 이미지 파일에서는 사용 못함)

img_stat도 스냅샷 작성한 파일과 원본 디스크 또는 파티션 정보 확인 가능

b-2. 첫 번째 파티션의 offset(시작위치sector를 byte로 환산)을 지정하여 Mount 시킴

c.f) 파일 시스템을 마운트하는 것이므로, offset을 지정하지 않는 경우 해당 이미지는 하나의 파일 내에 두 개의 파일시스템이 존재하게 되어 마운트 자체가 불가능함

“dd if=filesystemrecovery.dd of=recovery.dd bs=512 start=63 size=128457”와 같이 offset을 지정하지 않고, 첫 번째 파티션만 따로 dump하여 mount 가능

                            b-3. 마운트된 첫 번째 파티션 확인 (정상 인식)

b-4. 두 번째 파티션 Mount 후 확인 (정상 인식)

Case ③ MBR의 Partition Entry가 전혀 없는 경우

-      복원 전 MBR : Partition Table Layout

-      하드 전체 Layout

-      하드디스크 정보 (229,824 Sectors, 112.2MB) 

-      인식 오류 발생 원인

MBR에 Partition Entry가 전혀 기록되어 있지 않다. 즉, Encase에서는 아무런 파티션도 인식하지 못하였다.

-      복원 과정

a.       MBR의 Partition Entry를 고의적으로 삭제하였을 경우, 실제 파티션의 시작 지점에 위치하는 VBR은 남아있는지를 우선적으로 확인한다. 이때, 첫 Primary Partition은 63번 섹터에서 시작하게 되므로 63번 섹터를 확인. 

           // OEM String 으로 보았을 때, NTFS 파일 시스템을 갖는 파티션이 존재함 확인

b.       첫번째 파티션(Primary, NTFS) 추가

c.       하지만, 이때 파티션이 여러 개 존재하는지 여부 및 파티션의 크기와 시작 위치 등은 MBR이 삭제 되었으므로 더 이상 알 수 없다.

따라서 다른 파티션을 찾아보기 위하여 Keyword로 Search 한다.

                        c-1. 먼저 OEM String 을 키워드로 등록한다.

c-2. Unused Disk Area와, OEM String 키워드를 체크하고 Search

d.       검색 결과 확인

// 총 4개가 검색되었다. 이때, VBR의 백업본도 함께 검색되므로, 선별 작업이 필요하다. 보통 NTFS의 경우 VBR 백업본은 가장 마지막 섹터이고, FAT32의 경우 VBR로부터 6번째 섹터에 기록되므로 이 하드 디스크의 총 파티션 수는 2개이며, NTFS와, FAT32 파일 시스템을 사용하고, 각각 파티션 시작 위치(VBR)은 63 과 128520 임을 알 수 있다.

e.    두 번째 파티션(FAT32) 인식

e-1.  시작 지점인 128520섹터로 가 본다.

(첫 번째 파티션의 마지막 섹터 바로 다음이다.)

// 바로 VBR이 위치하는 것을 알 수 있다. 첫 번째 파티션이 128519 에서 끝났으므로 두 번째 파티션 또한Primary Partition인 것을 알 수 있다. (BR이 없으므로, MBR에 등록되어있는 Primary임을 의미함)

 e-2. Add Partition

-      파티션 복원 완료

새로 추가된 E 드라이브의 Messages.txt 파일 내용 확인

-      추가 연구가 필요한 사항

추가하려는 E 드라이브 외에 D 드라이브(C와 E전부를 가리킴)가 생성되는 이유와 이를 포렌식적으로 제거하는 방법에 대한 연구가 필요하다.

c.f) 최종 복구 후 모습

Case ② MBR의 Partition Table 일부 및 확장 파티션의 BR이 손상된 경우

-      복원 전 MBR : Partition Table Layout