1. Shellbag 이란?
Windows에서 폴더/Desktop에 대한view preference를 저장하기 위한 것으로, 폴더의 속성, 하위 아이템의 타입(폴더/파일), 접근 순서, MAC timestamp, 아이콘의 위치, 정렬 방법, 분류 기준, 윈도우 사이즈" 등등 사용자에게 보여지는 모든 것들을 저장하기 위한 구조체이다.
한편 Windows Registry 값 중 일부 특수 구조를 의미하기도 한다. Windows 10 기준, 아래 위치에 저장된 값들을 Shellbag이라고 부른다. 그 중에서도 NTUSER.DAT 하위에 저장되는 값들은 거의 고정이기 때문에, USRCLASS.DAT 하위에 있는 값들 위주로 분석을 진행할 예정이다.
#USRCLASS.DAT가 담고 있는 정보
HKCU\Software\Classes\Local Settings\Software\Microsoft\Windows\Shell\Bags
HKCU\Software\Classes\Local Settings\Software\Microsoft\Windows\Shell\BagMRU
#NTUSER.DAT가 담고 있는 정보
HKCU\Software\Microsoft\Windows\Shell\Bags
HKCU\Software\Microsoft\Windows\Shell\BagMRUShellbag은 BagMRU와 Bags로 구성된다. BagMRU는 폴더의 이름, 접근 순서, MAC timestamp 등을 기록하고, Bags는 사용자의 View preference를 기록한다. 포렌식적으로 의미있다고 생각되는 아티팩트는 BagMRU이고, BagMRU를 중심으로 분석을 진행할 예정이다.
추가적으로, 이 포스팅은 Shellbag의 hex 데이터를 완전히 이해하고자 하는 사람들에게 추천하며, Shellbag의 간단한 동작원리를 알고 싶다거나(-> 도구 사용 or 다른 포스팅), MAC를 추적하고 싶다거나(-> 사용자 행위 별로 MAC 분석해놓은 논문들) 하면 다른 게시글을 보시기를 권장합니다.
2. Shellbag 구조 분석 - Basic
Shellbag BagMRU은 레지스트리에서 계층적인 구조를 띈다. BagMRU는 최상단 키임과 동시에 Desktop을 의미한다. BagMRU\0, BagMRU\1은 그 순서대로 첫 번째, 두 번째 폴더를 각각 나타낸다(예시에서는 Test-0, Test-1).
My computer, Control Panel과 같은 윈도우 특수 폴더는 BagMRU 바로 아래에 존재한다.
BagMRU 내부에는 위와 같이 여러 값들을 가진다.
MRUListEX는 접근 순서를 나타내는 필드로, 4바이트 단위로 끊어서 앞에서부터 해석한다. 위의 사진에서는 "0 3 2 1 0"의 순서로 접근했음을 알 수 있다.
NodeSlot은 Shellbag의 Bags 구조와 연결되는 필드로, Bags\8을 보면 BagMRU의 View Preference를 알 수 있음을 나타낸다.
0, 1, 2, 3과 같은 필드가 오늘의 중점적인 분석 대상이다. 위의 사진을 보면 Test-2와 같은 폴더의 이름이 존재하는 것을 확인할 수 있으며, 이외에도 폴더의 타입, MAC 타입 등 많은 정보가 존재한다.
Shellbag의 기본적인 Block, Extension 구조를 공부하기 위해서는 아래 블로그를 추천한다.
https://blog.forensicresearch.kr/20
3. Shellbag 구조 분석 - Shell Item
Shellbag(BagMRU 중 0,1,2 등 키)의 구조는 Windows Shell에서 사용되는 Shell item이라는 포맷을 사용한다. 해당 포맷은 윈도우 버전에 따라 구조가 상이하고, 조사된 자료도 많이 없으나 아래 링크가 그나마 자세한 정보를 제공한다.
github.com/libyal/libfwsi/blob/master/documentation/Windows%20Shell%20Item%20format.asciidoc
Shellbag의 구조는 매우 복잡하다. 그럼에도 불구하고 공통점을 뽑아보자면, 2Byte의 Block Size와 1Byte의 Type indicator가 있다는 것이다. Type indicator를 기준으로 나누어 살펴보자.
3.1. Root Folder Shell item(0x1f)
윈도우에서 기본적으로 제공하는 My computer와 같은 특수 폴더를 나타낸다. 아래와 같은 단순한 구조를 띈다.
GUID는 특수 폴더를 식별하기 위한 식별자로 Known_GUID 목록을 기준으로 판별한다. 예를 들면 "My Computer"의 경우에는 {20d04fe0-3aea-1069-a2d8-08002b30309d}의 값을 갖는다.
Index는 폴더마다 정해진 지정 값이 있다. 링크를 참고하자.
Size가 20을 넘으면 "Extension Block 0xbeef0017"가 존재하기도 한다. 이 내용은 뒤에서 더 설명할 예정이다.
3.2. Volume Shell item(0x20 ~ 0x2f)
C,D 드라이브 및 A, J와 같은 이동식 드라이브 등을 나타낸다. 구조체도 2Byte의 Size와, 1Byte의 Type 이외에는 알려진 부분이 없다.
Type은 0x20 | Flag를 하여 정해지는데, 그 기준에 대해서도 알려진 바가 많이 없다고 한다.
그러나 실제로 Registry를 확인해보면, C: D: 의 type이 0x1f 혹은 0x2f를 갖는 경우가 있어 다소 정확하지 않은 부분이 있는 듯하다.
3.3. File Entry Shell item(0x30 ~ 0x3f)
가장 일반적으로 볼 수 있는 파일 형식으로, 폴더와 파일과 같은 파일 형식을 나타낸다.
1Byte의 Type은 0x30 | Flag를 하여 정해지는데, Flag의 기준은 아래와 같다.
따라서 폴더 = 0x31, 파일 = 0x32, 한글 폴더 = 0x35, 한글 파일 0x36의 값을 갖는다. 좀 더 자세히 연구해본 바에 따르면 Short Name 필드에 한글이 포함될 때에 0x04 플래그가 활성화되는 것으로 보인다.
구조는 2. 에서 분석했던 Block, Extension 구조와 동일하다. 따라서 Type이 0x30~0x3f 값을 가질 때에(File Entry Shell item) 폴더/파일의 이름, MAC 타임 등 포렌식적으로 의미있는 정보들을 획득하기에 용이하다.
4. Shellbag 구조 분석 - Extension Block
Extension Block은 Shell item 구조 뒤에 따라오는 Block으로, 잘 분석된다면 많은 정보를 획득할 수 있는 부분이다.
일반적으로 Signature Base로 Block을 구별하며, 0xbeef00XX의 형식을 띈다.
가장 일반적으로 발견할 수 있는 것은 Extension Block 0xbeef0004이며, File Entry Shell item에도 존재한다.
Extension Block은 아래의 형태를 띄며, Signature에 따라 다양한 형태를 가진다.
0xbeef0004를 제외하고도, 0xbeef0008, 0xbeef0003, 0xbeef0025등도 유의미한 정보를 획득할 수 있다고 한다.
5. Shellbag 구조 - Windows Property Store
Windows Property Store은 사용자의 property들을 저장하기 위해 공통적으로 사용되는 포맷으로, Windows Shortcut File(LNK)나 Shellbag에서 사용된다.
Property Store -> Serialized Property Storage -> name/numeric Property Value -> Typed Property Value로 이어지는 계층적 구조를 가지고 있으며, 자세한 내용은 링크1, 링크2를 참고하자.
해당 포맷을 구분하는 기준은 Serialized Property Storage가 가지고 있는 "1SPS"라는 Signature이다. Signature를 확인한 이후에는 위 링크에 정리된 포맷을 따라 차근차근 분석하면 된다.
그러나 이 역시도 예외적인 값들이 많이 존재하고 손으로 하나하나 분석하기에는 쉽지 않거나 그 의미가 불분명한 부분들이 다소 존재했다.
6. 결론 및 한계
Shellbag을 분석하기 위해 Shell item의 구조 분석, Extension Block 구조 분석, Windows Property Store 구조 분석을 진행하였으나 그럼에도 불구하고 Shellbag 레지스트리에 존재하는 모든 데이터를 분석할 수는 없었다. 예외가 많고, 아직 연구&정리되지 않은 부분이 상당히 많아 아쉬움을 느낀다.
AXIOM, FTK, Encase 등 종합 분석 도구들에서도 레지스트리 분석을 지원하고, 오픈 소스 중에서도 ShellbagsView나 ShellBags Explorer 등이 존재한다. 대부분 File Entry Shell Item(0x30~0x3f)와 Extension Block 0xbeef0004의 분석(MAC time 등)은 잘 지원하지만 이 포스팅에서 언급한 Serialized Property Storage나 Extension Block에 대해서는 많이 분석되지 않는 것 같다.
그나마 Shellbags Explorer를 사용하면, 아래와 같이 분석된 결과를 확인할 수 있다.
7. 마치며
일반적으로 사용자의 행위를 추적하고 싶을 때에, Shellbag을 분석하게 될 것이다. 그런 의미에서 사용자가 직접 생성하는 파일/폴더인 File Entry Shell Item(0x30~0x3f)가 가장 중요하다. 따라서 어쩌면 Shellbag 분석에 있어 선행되어야 할 연구는 Windows 10 환경에서 사용자의 구체적인 행위에 따른 Shellbag 각 필드의 생성 및 변화일 수도 있다. (Windows 이전 버전은 이미 문서가 존재한다 - 링크)
그럼에도 불구하고 Windows 버전 업데이트 등을 추적할 수 있는 Root Folder Shell item(0x1f), 디스크에 대한 정보를 추적할 수 있는 Volume Shell item(0x20~0x2f), 네트워크 관련 정보들을 추적할 수 있는 Network location Shell item (0x40~0x4f) 등은 분석한다면 유용하게 사용할 수 있을 것이라고 생각한다.
