F-INSIGHT에서 발표했던 발표자료입니다.



Deep in the artifacts #1.pdf


저작자 표시 비영리 변경 금지
신고
  1. 오정훈 2017.03.13 19:28 신고

    좋은 자료 감사합니다~^^

  2. nill 2017.04.05 17:20 신고

    좋은자료감사합니다
    uuid가 레지스트리에 존재하나요?
    아무리 찾아도 없네요;;

    • Favicon of http://maj3sty.tistory.com BlogIcon MaJ3stY 2017.04.07 17:58 신고

      UUID 형태의 값들은 많이 존재하지만, UUID라고 명확하게 명시되어 있는 단일 값은 존재하지 않습니다.

포렌식 아티팩트 중에는 점프 목록(Jump List)라는 것이 있다. 각 어플리케이션 또는 시스템에서 자주 사용 되거나 최근에 사용 되었던 것들에 대해서 지역성 있게 윈도우 운영체제 자체에서 사용이력을 관리하기 위한 기술이라고 생각하면 되는데, 이번 글에서는 점프 목록에 대한 다른 문서들에서 언급되지 않은 이야기를 해보고자 한다.


기본적인 점프 목록에 대해서는 Forensic-Proof에서 자세하게 설명하고 있으니 참고하기 바란다. 이번 글에서는 다른 문서나 블로그 포스트에서 다루지 않았던 이야기를 하기 때문에 기본적인 설명을 생략할까 한다.


점프 목록 포렌식 기본 : http://forensic-proof.com/archives/1904


위 글을 읽었다면 점프 목록에는 "AutomationDestination" 이라는 것과 "CustomDestination" 이라는 것이 있는 것을 파악 했을 것이다.

AutomationDestination은 최근 사용한 목록이나 사용자가 고정 시킨 것들에 대한 정보가 포함되어 있고, CustomDestination은 자주 사용되는 목록이나 작업(task) 목록 정보가 포함된다.


여기서 AutomationDestination 폴더에 저장되는 파일들은 모두 OLE 파일 구조를 가지고 있어, 실제 우리가 원하는 정보는 OLE 파일 구조 내부에 Stream에 들어 있다. Stream은 모두 하나의 링크(lnk)파일 구조를 가지고 있어 OLE 구조에서 Stream만 추출이 가능하다면 쉽게 세부 정보들을 출력 해 낼 수 있다. 또 OLE 구조 제일 마지막 부분에는 "DestList"라는 이름의 Stream이 존재하는데 해당 스트림은 윗단에 존재하는 각 Stream들의 간략한 정보를 가지고 있어, 이 부분도 분석에 있어 고려를 해야 하는 부분이지만, 점프목록 분석 도구들의 대부분이 DestList Stream에 대해 분석을 해주지 않는다.


그리고 CustomDestination의 경우 표준 파일 구조가 존재하지 않는다. 이런 이유로 대부분의 점프 목록 도구는 CustomDestination 파일을 분석 해주지 않지만, tzworks의 jmp 도구만이 해당 파일을 분석하여 출력 해 준다.


이번 글에서는 도구들이 분석에서 간과하는 "DestList Stream"과 "CustomDestination" 파일 구조에 대해 알아보고자 한다.


1. DestList Stream

DestList Stream은 간단한 정보만을 가지고 있어, 다른 파일구조에 비해 간단하다. 해당 Stream의 구조를 살펴보면 다음과 같다.


[그림 1 - DestList Stream 구조]


참고로 [그림 1]의 구조는 DestList Stream에서 32 오프셋을 건너 띈 이후에 연속으로 존재한다. 각 항목에 대한 설명은 다음과 같다.


 - Check Sum : 가리키고 있는 Stream의 Check Sum 값이 저장되어 있다.

 - New Volume : Birth Volume ID 값이 아닌 Volume에서 해당 파일이 수정되면 파일이 수정 될 때의 Volume GUID 값이 저장 된다.

 - Object ID 1: 어떤 ID 값이 저장되는지 밝혀지지 않았지만, 다음에 존재하는 Object ID 2와 동일한 값을 저장한다.

 - Birth Volume ID : 가리키고 있는 Stream이 생성 된 Volume GUID 값이 저장 된다.

 - Object ID 2 : 어떤 ID 값이 저장되는지 밝혀지지 않았지만, 이전에 존재하는 Object ID 1과 동일한 값을 저장한다.

 - Machine ID : 해당 Stream이 생성 된 시스템의 이름 값이 저장 된다.

 - Entry ID : 가리키고 있는 Stream의 이름이 저장 된다.

 - File Access Count : Stream의 접근 횟수를 부동소수점으로 표현한 값을 저장하고 있다.

 - Last Record Time : Stream의 마지막 수정 시간을 저장하고 있다.

 - pin : 메타데이터 구조의 끝을 알리는 값으로 항상 0xFFFFFFFF 값을 가지고 있다.

 - Unicode String Length : 뒷 부분에 위치하는 Unicode 문자열의 길이를 저장하고 있다. 실제 길이는 Unicode의 2byte 특성 때문에 해당 값에 2를 곱해야 한다.

 - Unicode String : Stream에서 가지고 있는 문자열을 Unicode 형태로 저장하고 있다.


간혹 DestList Stream 내부에 [그림 1] 구조가 깨져 있을 수 있다. 데이터를 쓰는 도중에 시스템에 오류가 생겨 쓰기 동작 예기치 못하게 중지 되는 경우인데, 이때 해당 구조가 깨져있는지를 확인하려면 pin 데이터를 확인하면 된다. pin 데이터는 항상 0xFFFFFFFF이기 때문에 해당 값이 아니라면 구조에 문제가 있는 것으로 판단 할 수 있다. 또 Entry ID의 값이 AutomaticDestination 내부에 존재하는 Stream의 이름이 아니라면 이 또한 해당 구조에 문제가 있다고 판단 할 수 있다.


아래는 구현한 도구의 결과 샘플이다.


 [DestList]

 JumpList File Name : AutomaticDestinations\1b4dd67f29cb1962.automaticDestinations-ms

 Stream Name : 3

 Check Sum : 446aed6629321199

 New Volume ID : 0648918d3e59f140b41967735b7fdb49

 Object ID_1 : 1fca1e3db7bbe311beeb000c29501e46

 Object ID_2 : 1fca1e3db7bbe311beeb000c29501e46

 Birth Volume ID : 0648918d3e59f140b41967735b7fdb49

 Machine ID : msdn-special

 File Access Count : 4.17815044784e-08

 Last Record Time : 2014/04/04 14:09:21 Fri

 String Data : ::{031E4825-7B94-4DC3-B131-E946B44C8DD5}\Music.library-ms


file_display_auto_result.txt



2. CustomDestination

CustomDestination의 구조는 표준으로 정해져있지 않다. 불규칙적으로 lnk 구조가 여러개 존재한다. 크게 구조를 본다면 다음과 같다.

[그림 2 - CustomDestination 파일 구조]


[그림 2]와 같은 구조에서 lnk 구조를 파악하려면 lnk 구조를 카빙해야 한다. lnk 구조는 헤더의 크기가 76byte로 이를 나타내는 필드의 값이 0x4C000000 값으로 고정이 되어 있으며, 파일의 GUID 값이 항상 00021401-0000-0000-C000-000000000046으로 고정이기 때문에 해당 값들을 이용 해 카빙을 수행하면 대략적인 lnk 구조를 파악 할 수 있다.


하지만 CustomDestination 파일 구조에서는 깨진 lnk 구조가 존재 할 수 있다. 깨진 lnk 구조는 ExtraData의 블록 시그니처 값으로 확인하면 쉽게 확인 할 수 있다. tzworks의 lp 도구도 slack 옵션을 이용하면 해당 방법을 이용 해 lnk 구조를 카빙하여 그 결과 값을 보여준다.


ExtraData 구조체는 성질이 optional이기 하지만, 실제로는 필수 구조체이다. 해당 구조체에 Machine ID 등에 값이 저장되기 때문이다. ExtraData 구조체 내부에는 또 여러개의 구조체 블록이 존재하는데, 이때 각 구조체 블록들은 블록 시그니처를 가지게 된다. 해당 시그니처는 몇 개 되지 않기 때문에 해당 시그니처들로 lnk 구조가 정상적이지 않은지 판별 할 수 있다.


아래는 구현한 도구의 결과 샘플이다.


 [-] Lnk Structure Carving ...

 JumpList File Name : CustomDestinations\5d696d521de238c3.customDestinations-ms

 Offset(10) : 7042

 Lnk Attributes : ARCHIVE

 Lnk Created Time(Local) : 2014/03/04 13:23:43 Tue

 Lnk Modified Time(Local) : 2014/04/30 10:46:34 Wed

 Lnk Accessed Time(Local) : 2014/04/24 09:26:06 Thu

 Drive Type : DRIVE_FIXED

 Lnk Size : 841032

 Volume Serial Number : 2718108183

 Local Base Path : C:\Program Files (x86)\Google\Chrome\Application\chrome.exe

 Relative Path :

 Working Directory :

 Target File Description :

 Command Arguments : http://for-md.org/

 Icon Location : C:\Users\Administrator\AppData\Local\Google\Chrome\User Data\Default\JumpListIcons\670E.tmp

 NetBIOS Name : maj3sty

 MAC Address : e9-1f-74-82-03-a1

 ItemIDList : P???i↖+00?/C:\?얛PPROGRA~2|絶??얛P*RProgram Files (x86)@shell32.dll-21817P1dD?Google:絶dD?dD?*?GoogleP1얛?Chrome:絶dD?얛?*BChrome\1얛?APPLIC~1D絶dD?얛?*~?Application\2H?쁃( chrome.exeB絶dD?얛?뺄@chrome.exe

 ExtraData : 1SPS?XF퍵8C샜?쁬?



점프 목록을 통해 우리가 지금까지 얻었던 데이터들 이외에 많은 데이터들이 있었다는 것을 알 수 있었다. 해당 데이터들의 해석은 분석가들이 해야 할 몫이기에 여기서는 따로 언급하지 않았다.


지금까지 소개한 데이터들로 인해 분석가들이 조금 더 많은 흔적들을 찾고 어떠한 행동에 대해 밝혀냈는데 도움이 되었으면 좋겠다.


 * 참고 : 현재 글에서 소개한 도구는 내부적인 검토가 끝난 후 무료로 배포 될 예정입니다.


저작자 표시 비영리 변경 금지
신고

+ Recent posts