개요

 메모리 포렌식에 있어서 볼라틸리티는 많이 유명하며 실제로도 많이 사용을 하고 있다. 이러한 볼라틸리티를 이용하여 메모리 포렌식에 대하여 알아보고 이후에는 이를 통하여 실습을 진행할 수 있도록 연습을 해볼 것이다. Volatility에 관한 글은 한번에 포스팅하기에는 많기에 전체적인 사용방법에 대하여 포스팅을 한 후 어떻게 활용을 하는지에 대하여 추가적인 포스팅을 진행할 것 같다.

Memory Acquisition

 메모리 분석을 하기 전에 해당 메모리를 수집하여야 한다. 이러한 메모리 수집에 있어서는 Win32dd와 같은 툴을 주로 사용하며 필자의 경우 DumpIt나 FTK Imager를 사용하기에 이에 대해서는 별도의 언급을 하지 않겠다. DumpIt의 경우 간단하게 더블 클릭으로 실행하면 해당 메모리가 수집되기에 편리한 장점이 있다.

Getting Started with Volatility™

 볼라틸리티를 사용함에 있어서 헷갈리거나 모르는 부분이 있을 경우에는 이러한 help를 이용하여 필요한 정보를 확인하거나 어떠한 인자가 필요한지 등을 확인하여야 한다. 그리고 Imageinfo는 기본적으로 가장 먼저 수행해야하는 작업이며 이를 통해 해당 이미지의 정보를 확인하여 이후 --profile=<profile>에 사용하여야 한다.

Getting Help

# vol.py –h (show options and supported plugins)

# vol.py plugin –h (show plugin usage)

# vol.py plugin --info (show available OS profiles)

Sample Command Line

# vol.py -f image --profile=profile plugin

Identify System Profile

imageinfo - Display memory image metadata

# vol.py –f mem.img imageinfo

Using Environment Variables

Set name of memory image (takes place of -f )

# export VOLATILITY_LOCATION=file:///images/mem.img

Set profile type (takes place of --profile= )

# export VOLATILITYPROFILE=WinXPSP3x86

Converting Hibernation Files and Crash Dumps

 시스템을 사용하는데 있어서 크래시가 발생하는 경우가 종종 존재한다. 이러한 크래시가 발생하였을 때 덤프 파일을 생성하는데 이러한 덤프파일을 볼라틸리티를 이용해 이미지 파일로 생성할 수가 있다. 

 또한 하이버네이션 파일의 경우 절전 모드 시 최소한의 전력만 사용하기 위해 물리메모리의 내용을 파일로 저장하게 하는 기능이다. 다시 시스템을 동작시키면 재부팅 과정에서 저장된 하이버네이션 파일의 내용을 메모리에 읽어와 절전 모드 이전 상태로 시스템을 복원시켜준다. 이러한 하이버네이션이 기본적으로 활성화 되어있는 노트북의 경우 메모리 상에서 존재했던 많은 내용을 확인할 수가 있다. 해당 경로는 다음과 같다. C:\hiberfil.sys 의 형태로 존재하고 있다.

 여기선 덤프된 이미지가 아니라 현재 사용자의 PC에서의 파일을 대상으로 -f 인자를 지정해야 한다.

Volatility imagecopy

-f Name of source file (crash dump, hibernation file)

-O Output file name

--profile Source OS From imageinfo

# vol.py imagecopy -f hiberfil.sys -O hiber.img --profile=<profile>

# vol.py imagecopy -f Memory.dmp -O memdmp.img --profile=<profile>

Memory Artifact Timelining

 볼라틸리티의 Timeliner 플러그인은 메모리 이지미에서 발견할 수 있는 타임스탬프를 수집한다. 출력물은 아래와 같이 정리된다.

 Process creation time   Thread creation time   Driver compile time   DLL / EXE compile time   Network socket creation time

 Memory resident registry key last write time    Memory resident event log entry creation time

--output-file Optional file to write output

--output=body Mactime bodyfile format (also text | xslx)

--registry Include timestamps from registry hives

-y <file> Perform YARA search using signature file

#volatility -f MEMDUMP timeliner --output-file out.csv --profile=Win7SP1x64

Registry Analysis Volatility™ Plugins

 레지스트리와 관련하여 볼라틸리티의 플러그인은 아래와 같다.

hivelist - Find and list available registry hives

# vol.py hivelist -f filename

hivedump - Print all keys and subkeys in a hive

-o Offset of registry hive to dump (virtual offset)

# vol.py hivedump -f filename –o 0xe1a14b60

printkey - Output a registry key, subkeys, and values

-K “Registry key path”

# vol.py printkey -f filename –K “Software\Microsoft\Windows\CurrentVersion\Run”

userassist - Find and parse userassist key values

# vol.py userassist -f filename

hashdump - Dump user NTLM and Lanman hashes

-y Virtual offset of SYSTEM registry hive (from hivelist)

-s Virtual offset of SAM registry hive (from hivelist)

# vol.py hashdump -f filename –y 0x8781c008 –s 0x87f6b9c8

Identify Rogue Processes

 메모리에서 어떤 프로그램이 실행되었는지 확인을 하기 위해 볼라틸리티의 ps* 명령어들을 사용할 수가 있다. 기본적으로 pslist를 사용하면 어떤 프로세스가 메모리에 올라왔는지 그리고 메모리에 있었다가 종료된 프로세스의 경우 해당 종료 시간 또한 알 수가 있다.

 그 외에 psscan을 통해 종료된(비활성) 프로세스들과 루트킷에 의해 숨겨지거나 연결이 끊어진 프로세들을 찾을 수 있다. 또한 pstree를 통하여 프로세스 간의 부모 자식 관계를 알 수가 있으며 이를 통하여 분석자가 편하게 확인을 할 수가 있다.

pslist - High level view of running processes

# vol.py pslist        //여기서 -P 옵션을 주면 물리적 오프셋의 주소가 나타내어 진다.

psscan - Scan memory for EPROCESS blocks

# vol.py psscan

pstree - Display parent-process relationships

# vol.py pstree

pstotal - Graphical view of parent-process relationships

--output=dot Produces vector process DOT graph

# vol.py pstotal -output=dot

Look for Evidence of Code Injection

malfind명령어는 VAD 태그와 페이지 권한들 같은 문자들을 기반으로 사용자 모드(user mode) 메모리에 숨겨져 있거나 삽입(injected) 되어 있는 코드/DLLs 를 찾아내는데 도움을 준다.

malfind - Find injected code and dump sections

-p Show information only for specific PIDs

-o Provide physical offset of single process to scan

--dump-dir Directory to save memory sections

# vol.py malfind --dump-dir ./output_dir

ldrmodules - Detect unlinked DLLs

-p Show information only for specific PIDs

-v Verbose: show full paths from three DLL lists

# vol.py ldrmodules –p 868 -v

Check for Signs of a Rootkit

psxview - Find hidden processes using cross-view

# vol.py psxview

modscan - Scan memory for loaded, unloaded, and unlinked drivers

# vol.py modscan

apihooks - Find API/DLL function hooks

-p Operate only on specific PIDs

-Q Only scan critical processes and DLLS

# vol.py apihooks

ssdt - Hooks in System Service Descriptor Table

# vol.py ssdt | egrep –v ‘(ntoskrnl|win32k)’

driverirp - Identify I/O Request Packet (IRP) hooks

-r Analyze drivers matching REGEX name pattern

# vol.py driverirp –r tcpip

idt - Display Interrupt Descriptor Table

# vol.py idt

Analyze Process DLLs and Handles

 dlllist와 handles의 경우 어떠한 dll과 핸들이 사용되었는지 확인 할 수가 있으며, filescan의 경우 pool 태그 스캐닝을 사용하여 물리적 메모리에서 FILE_OBJECT들을 찾아내려면 filescan 명령어를 사용해야 한다. 이것은 루트킷이 디스크에서 파일을 숨겼을지라도 열려있는 파일들을 찾아낼 것이고 루트킷이 활성 시스템에서 열린 핸들을 숨기도록 몇몇 API 함수들을 연결시켜도 찾아낼 것이다.

dlllist - List of loaded dlls by process

-p Show information only for specific process identifiers (PIDs)

# vol.py dlllist –p 4,868

getsids - Print process security identifiers

-p Show information only for specific PIDs

# vol.py getsids –p 868

handles - List of open handles for each process

-p Show information only for specific PIDs

-t Display only handles of a certain type {Process, Thread, Key, Event, File, Mutant, Token, Port}

# vol.py handles –p 868 –t Process,Mutant

filescan - Scan memory for FILE_OBJECT handles

# vol.py filescan

svcscan - Scan for Windows Service information

-v Show service DLL

# vol.py svcscan

Review Network Artifacts

네트워크와 관련된 명령어들의 경우 netscan을 제외하고는 XP 환경에서 밖에 실행이 되지 않아서 구체적으로 확인을 하지 못하였다.

connections - [XP] List of open TCP connections

# vol.py connections

connscan - [XP] ID TCP connections, including closed

# vol.py connscan

sockets - [XP] Print listening sockets (any protocol)

# vol.py sockets

sockscan - [XP] ID sockets, including closed/unlinked

# vol.py sockscan

netscan - [Win7] Scan for connections and sockets

# vol.py netscan

Dump Suspicious Processes and Drivers

 의심되는 프로세스나 드라이버가 있을 경우에 아래의 명령어들을 통하여 덤프를 뜰 수가 있다. 하지만 덤프를 함에 있어서 메모리에서 페이징되는 등의 경우는 덤프에 실패 할 수가 있다. 

dlldump - Extract DLLs from specific processes

-p Dump DLLs only for specific PIDs

-b Dump DLLs from process at base offset

-r Dump DLLs matching REGEX name

--dump-dir Directory to save extracted files

# vol.py dlldump --dump-dir=./output –r metsrv

moddump - Extract kernel drivers

-b Dump driver using base address (from modscan)

-r Dump drivers matching REGEX name

--dump-dir Directory to save extracted files

# vol.py moddump --dump-dir=./output –r gaopdx

procdump - Dump process to executable sample

-p Dump only specific PIDs

-o Specify process by physical memory offset

-n Use REGEX to specify process

--dump-dir Directory to save extracted files

# vol.py procdump --dump-dir=./output –p 868

memdump - Dump every memory section into a single file

-p Dump memory sections from these PIDs

-n Use REGEX to specify process

--dump-dir Directory to save extracted files

# vol.py memdump –dump-dir=./output –p 868

dumpfiles - Dump File_Objects from file cache

-Q Extract using physical offset

-r Extract using REGEX (-i for case insensitive)

--dump-dir Directory to save extracted files

# vol.py dumpfiles –dump-dir=./output –r \\.exe

Reference

http://www.codeengn.com/archive/Forensic/Volatility%20Plugin%20%EC%9D%84%20%EC%9D%B4%EC%9A%A9%ED%95%9C%20Windows%20Memory%20Dump%20%EB%B6%84%EC%84%9D%20%5BDeok9%5D.pdf

https://digital-forensics.sans.org/media/volatility-memory-forensics-cheat-sheet.pdf

https://digital-forensics.sans.org/media/Poster-2015-Memory-Forensics2.pdf

http://forensic-proof.com/archives/1834   , 하이버네이션 파일 관련 참고

개요

 포렌식 분석에 있어서 타임스탬프는 중요한 의미를 갖는다. 해당 타임스탬프에 따라 사건의 경위를 유추하고 조사의 방향을 정할 수 있기 때문이다. 이러한 타임 스탬프와 파일 사이에 연관성은 중요하며, 만약 어떠한 악성코드를 실행시켰는데 표면적으로는 아무런 일도 일어나지 않은 것처럼 보일 때 분석가들은 레지스트리를 비교하거나 서비스, 네트워킹, 프로세스 등을 비교한다.

 여기서 파일의 생성과 삭제와도 밀접한 연관이 있는데, 드롭퍼나 다운로더의 경우 다른 파일들을 새로 생성하거나 다운 받은 다음에 이를 실행하도록 하기에 만약 다양한 안티리버싱 기법으로 인하여 어떠한 파일이 생성되는지나 삭제, 이동하는지 확인이 어려울 때 바로 $UsnJrnl을 확인하면 손쉽게 확인이 가능하다.

 우선 전체적인 타임스탬프는 위와 같다. 처음에 echo 명령어를 통하여 현재 시간을 출력하였으며, 이는 악성코드라 가정했을 경우 악성코드의 실행시간을 기록하기 위함과 같다. 그리고 2022 디렉터리를 생성후 2022 .txt .xls .rar 파일을 각 각 해당 폴더 안에 생성한다. 그리고 마지막에 다시 타임스탬프를 통해 경과된 시간을 확인해 보았다.

수집

 여기서 해당 파일을 수집할 때는 FTK Imager를 사용하였다. $UsnJrnl은 $Extend 디렉터리 안에 존재하는데 해당 파일을 클릭하면 다시 $J와 $J.FileSlack, $Max가 있는 것을 확인할 수가 있다. 여기서 우리가 추출해야할 파일은 바로 $J이다. $J는 실제 변경 로그 레코드가 저장되어 있는 파일이며 $MAX의 경우 변경 로그의 기본 메타 데이터를 저장하고 있다. 

 아래와 같이 성공적으로 출력했다는 것을 확인할 수가 있다. 이와 같이 $LogFile과 $MFT도 추가로 추출해보았다. 

 필자가 사용한 툴은 NTFS Log Tracker v1.4로 이를 통해 보기 좋게 내용이 정리되는 것을 확인할 수가 있다. 각자 해당 파일의 경로를 설정해주고 Parsing 버튼을 누르면  진행률이 나타나는 것을 확인할 수가 있다.그리고 여기서 CSV Export를 통하여 엑셀의 형태로 열어서 확인해보았다.

NTFS Log Tracker : https://code.google.com/p/ntfs-log-tracker/

 타임스탬프를 보면 위의 20:22와 같은 시간이며 '2022' 디렉터리의 생성과 각 파일들이 생성되었다는 것이 로그에 남아있는 것을 확인할 수가 있다. 이를 통해 추가적인 파일의 생성이나 특정한 파일의 삭제가 있었는지 확인할 수가 있다.

이동

 파일이 이동하였을 때의 명령어는 아래와 같다. 2054 디렉터리를 새로 생성한 후 2022 디렉터리 안으로 이동을 시키는 것이다. 이에 대하여 분석을 해보자.

 아래의 그림과 같이 처음에 '2054' 디렉터리가 생성이 된 것을 확인할 수가 있다. 그리고 파일을 이동시켰는데 여기서는 File_Renamed_Old와 _New에서 같은 이름인 2054를 유지하고 있다. 이러한 경우를 추후에 발견하면 해당 파일이 다른 곳으로 이동이 되었다는 것으로 확인할 수가 있다.

*추가 : 추가적으로 필자의 PC에서 해당 파일의 기록은 10/07~10/09 (현재 10/09)까지의 기록 밖에 남아있지가 않다. 따라서 PC를 많이 사용하는 경우에는 이전의 기록이 더욱 빠르게 없어져있을 수가 있음에 유의하자.

결론

 이와 같이 매우 간단하게 살펴보았는데 $MFT, $LogFile, $UsnJrnl의 개념에 대한 내용은 많이 나와있는데 실제로 실습에 관한 내용을 찾기가 어려워 필자는 직접 해보고 포스팅을 하였다. 확실히 이러한 방법을 통하여 특정한 시간대(악성코드의 실행시간)에 어떠한 파일의 생성, 삭제, 이동의 여부를 쉽고 명확하게 확인을 할 수가 있으므로 이는 참 편리한 방법 같다.

 리버싱을 통해서도 이에 해당하는 결과와 비슷하게 얻을 수가 있지만, 패킹이나 난독화가 되어있는 경우에는 분석에 많은 시간이 소요되며 자칫 안중요하다고 Step OUt과 같은 방식으로 진행하다가 중요한 파일의 생성 여부를 놓칠 수가 있기에 조심하여야 한다. 아무래도 가장 좋은 방법은 파일의 생성과 삭제에 있어서 리버싱과 포렌식 두 방식 모두 활용하는 것이 좋은 경우인 것 같다.

 마지막으로 포렌식의 관점에서 특정 파일의 삭제 여부를 확인한다는 것은 매우 중요하다. 이는 조사가로부터의 분석을 방해하기 위하여 파일을 삭제시키는 경우가 많을텐데 이러한 상황에서 이 방법을 통하여 해당 파일이 언제 삭제가 되었는지를 확인할 수가 있으므로 중요하다.

개요

 요즘 시대에 토렌트는 많이 대중화 되어 있다. 컴퓨터를 하면서 어떠한 파일을 구하고자 할때 이제는 토렌트 파일을 먼저 검색하게 되며 가격도 무료에다가 구하고자 하는 파일들을 쉽게 구할 수 있기에 많은 용이함을 제공한다. 그렇기에 이러한 토렌트의 사용은 많아졌고 이는 포렌식에 있어서 충분히 분석할 가치가 있음에 충분하다고 생각한다. 

 가령 토렌트를 통하여 그 사람의 경향을 유추할 수가 있으며, 만약 불법적인 자료를 다운받았다면 이 또한 흔적으로 남으므로 조사에 있어서 충분히 도움이 된다. 따라서 이러한 토렌트가 남기는 아티팩트에 대하여 학습을 해보고자 한다.

사용 흔적

우선 크게 토렌트 파일은 두 곳에 아티팩트를 남긴다고 할 수가 있다. 하나는 레지스트리이며 다른 하나는 바로 지정된 디렉터리이다. 레지스트리를 먼저 살펴보자. 레지스트리의 경우 컴퓨터에서 사용자가 사용하거나 접근할 떄 마지막 접근 시간이 변하거나 새로운 키나 값이 추가되는 등의 변화가 존재한다. 그렇다면 토렌트로 인하여 나타나는 레지스트리 아티팩트는 무엇인지 살펴보고 그 후에는 디렉터리에 대하여 알아보자.

레지스트리

HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\RecentDocs\.torrent

  위의 경로는 많은 곳에서 언급이 되는 RecentDocs 키이다. 여기서 토렌트 파일의 경우 .torrent의 형태로 실행이 되기때문에 이 곳에 기록이 남는다. 하지만 여기서 이상한 점이 존재한다. 필자의 컴퓨터에서는 실제로 토렌트를 많이 사용하는 편인데 여기에서는 하나의 목록만이 나와있다는 것이다.

 이는 필자가 Chrome을 사용하는데 크롬의 경우 웹페이지에서 파일을 다운받으면 크롬의 하단 부분에 다운로드 리스트가 나오며 그 리스트에서 해당 항목을 클릭하면 다운과 함께 바로 실행이 된다. 바로 이러한 실행 방식으로 인하여 레지스트리에서는 기록이 남지 않는 것이다. 즉, 만약 범죄자로 의심되는 사람이 이러한 방식으로 토렌트 파일을 실행한다면 이는 RecentDocs에 흔적이 남지 않으므로 유념하여야 한다.

*추가 :해당 키는 Explorer의 하위 키이기 떄문에 explorer에서 실행할 때만 남으며 크롬이나 IE에서 관련된 히스토리(로컬 파일 열람 흔적)을 볼때 토렌트 파일 존재

디렉터리

 디렉터리의 경우에는 아래에 나타난 경로와 같다. 여기서 Roaming 안에 uTorrent가 존재하며 여기에는 다운받을 때 사용되었던(사용 후 바로 삭제해서 제거된) 토렌트 파일들이 존재하는 것을 확인할 수가 있었다. 이는 파일을 다운받을 때 사용된 원래의 토렌트 파일과 같은 파일을 해당 디렉터리에 생성하는 것임을 알 수가 있으며 생성 시간이나 수정시간, 접근시간들을 통하여 언제 실행이 되었는지 등을 유추할 수가 있다.

%AppData%\Roaming\uTorrent

구조

 토렌트 파일도 하나의 증거가 될 수 있기에 삭제가 되었더라도 이러한 파일을 복구할 수 있도록 카빙을 위한 시그니처나 패턴을 찾아보려고 했다. 일반적인 토렌트 파일의 경우 아래와 같은 바이너리의 값을 가진다. 특히 드래그로 파랗게 표시한 부분이 바로 토렌트 파일에서 모두 공통적으로 존재하고 있는 하나의 파일 시그니처와 같이 존재하고 있다. 

 따라서 만약 토렌트 파일을 카빙하고자 할 때에는 위와 같이 헤더에 'd8:announce'를 찾으면 된다. 그리고 토렌트 파일의 바이너리를 살펴본 결과 NULL(\x00)의 값이 거의 존재하지 않았다. NULL이 존재하기는 하지만 거의 대부분 연속적으로 존재하지 않으며 일반적은 PE구조의 파일과는 많이 다른 양상을 보였다. 이는 다시 말해 토렌트 파일을 카빙할 때 헤더를 기준으로 삼고 이러한 특성(슬랙과 같은)을 이용하면 될 것 같다고 생각이 된다.

 사실 해당 토렌트 파일을 디스크에서 발견했다고 하더라도 꼭 카빙을 해야하는 것은 아니다. 대부분의 경우 토렌트 파일은 이름에서 많은 내용들을 유추할 수가 있으며 이를 통해 불필요한 카빙을 예방하므로 시간을 절약할 수가 있다(자동화된 툴을 가지고 할 경우는 예외). 해당 토렌트 파일의 이름은 바이너리에서도 확인이 가능하며 이를 확인하면 아래와 같다.

 name**;라는 문자열 뒤에 해당 토렌트 파일의 이름이 나와 있는 것을 확인할 수가 있었으며 이는 삭제된 파일을 카빙하고자 할 때 이름을 참고할 수 있는 하나의 좋은 단서가 된다. 이외에 더 참고할 수 있는 정보들은 아래에 표와 같이 정리되어 있다. 이러한 정보들을 통하여 PC에 남아있는 토렌트 파일에 대한 아티팩트를 이해하기에 도움이 된다.

Reference

http://maj3sty.tistory.com/1050

http://maj3sty.tistory.com/1070

https://www.sans.org/reading-room/whitepapers/detection/detecting-torrents-snort-33144

For-MD-Torrent-Forensics.pdf

Abstract

 해당 글은 사용자의 PC에서 사용할 수 있는 다양한 디지털 포렌식 증거에 대하여 설명하며, 이러한 증거를 찾는 방법에 대하여 논의할 것이다. 또한 이러한 방법 뿐만 아니라 기법이나 어떤 이슈에 초점을 맞춰야 하는지에 대하여 알아볼 것이다.

Introdution

최근의 버클리 과학자 연구에 의하면 모든 정보의 93% 이상이 디지털 도메인을 남기지 않는다. 이는 정보의 과반수 이상이 디지털의 형태로 생성되며, 수정되고, 소비된다는 것을 의미한다. 거의 모든 데이터베이스와 스프레드 시트는 종이로 작성되지 않으며, 대부분의 디지털 스냅샷은 인쇄되지 않는다. 또한 이러한 디지털의 형태로 채팅이나 Social networking이 존재하며 이는 가상 영역의 외부라 상상할 수도 없다.

 대부분의 이러한 활동은 명확한 흔적들을 남기며 이는 단서를 수집하는 것을 허용하며, 범죄를 해결할 수 있도록 도와주며 예방하게끔 하기도 한다. 이번 기사에서는 일반적인 사용자의 컴퓨터에서 생성될 수 있는 여러 타입의 디지털 증거들에 대하여 언급할 것이며, 조사에 사용될 수 있는 증거들을 PC에서 추출하는 방법과 기법에 대하여 설명할 것이다.

Digital Forensic

디지털 증거는 결코 과소 평가할 수가 없다. 디스크에 저장된 디지털 파일들의 형태로 저장되어 사용할 수 있는 증거들은 많으며, 이러한 정보에 접근하는 것은 오늘날에 필수적으로 여겨지고 있다.

Instant Messenger

 인스턴트 매니저는 커뮤니케이션에서 중요한 요소가 되었다. 많은 사람들이 그들의 나이, 국적, 성별에 상관 없이 컴퓨터로 보내는 시간들이 많아졌으며, 이는 채팅 기록으로부터 점점 더 많은 단서들을 수집할 수 있음을 의미한다. 

Social Networking

 소셜 네트워크는 몇 년 사이에 빠르게 대중적인 요소가 되었고, 점점더 커뮤니케이션은 기존의 채팅 방이나 개인메신저로부터 이주되고 있다. 이러한 소셜 네트워크로부터 추출된 커뮤니케이션은 확실히 포렌식 조사에 있어서 가치가 있다.

Web Browsers

 웹 브라우징은 보편화된 활동이기에 이러한 웹 브라우저의 히스토리나 북마크, 웹 페이지의 캐시들을 분석하는 것은 중요한 작업이 되었다. 웹 브라우저의 캐시에는 불법적인 내용을 담은 이미지나 악성코드로 의심되는 스크립트 등을 포함하고 있을 수가 있다. 구글을 검색하는 것과 같은 인터넷 활동은 분석될 수가 있으며, 종종 명백하지 않은 범죄의 해결을 도와준다.

Email

 메신저와 소셜 네트워크가 증가함에도 불구하고 이메일은 아직도 중요한 정보들을 가지고 있으며 이는 기업에 있어서 더욱이 그렇다는 것을 알 수가 있다. 많은 온라인이나 오프라인 이메일 클라이언트는 중요한 정보를 제대로 접근하지 않고 간과하기가 쉽다. 

P2P and File Exchange Software

 토렌트와 같은 P2P와 파일 교환 클라이언트는 불법적인 이미지나 비디오, 저작권이나 지적 재작권이 침해된 자료들을 포함한 단서들을 포함하고 있다. 다운로드나 업로드, 공유된 파일에 대한 정보는 실질적으로 증거 수집에 도움이 된다. 

Multimedia Content

 아직도 이미지나 비디오 파일들은 그들의 컨테츠를 위해 분석된다. 그리고 몇개의 툴들은 이러한 불법동영상이나 얼굴 비교, 스캔된 그림파일로 저장된 텍스트 문서들의 탐지를 자동적으로 도와준다.

Type of Digital Evidence

이번 기사에서는 PC, 메모리, 디스크에서 사용 가능한 증거에 대하여 엄밀히 말할 것이다. 디지털 증거의 유형은 다음의 리스트를 모두 포함한다. 리스트는 아래와 같다.

Retrieving Log and History files

로그 파일과 히스토리 파일은 가치있는 본질적인 증거를 포함하고 있다. 채팅 커뮤니케이션은 종종 타임스탬프와 상대방의 닉네임, 누가 응답자였는지에 대하여 포함하고 있다. 이러한 파일의 정확한 위치와 이름을 결정하는 것은 추가적인 분석을 수행하는데 필요한 필수적인 첫 단계이다. 

 최근 버전의 윈도우는 user-created, application-generated 데이터를 AppData Program files, 그리고 Documents와 Settings Folders에 포함하고 있다. 윈도우 비스타와 윈도우 7에서 AppData폴더는 고정된 위치를 가지고 있지 않다. 추가적으로 이러한 시스템은 관리 권한보다 낮은 권한으로 실행된 응용 프로그램을 위한 가상화된 저장공간을 유지하고 잇다. 이러한 공간은 조사에 있어서 가끔 간과되며 심지어 well-know Documents와 Settings 윈도우의 기본 지역에 따라 다른 이름으로 저장되는 것이 무시되기도 한다. 예로 이는 “Мои документы” or “Dokumente und Einstellungen” 라는 이름으로 설정되어 있을 수도 있다. 유저들은 이러한 이름의 변경으로 분석을 복잡하게 할 수가 있다.

 조사자는 분석에 있어서 흥미로운 윈도우 레지스트리 파일이나, 응용 프로그램 구성 파일과 같은 파일을 찾은 후엔 그것들로부터 데이터를 추출하기를 원한다. 그렇기에 소스파일들 각각의 정확한 형식에 대하여 알아야 한다. 많은 종류의 format이 존재하며 이는 특정 형식에 대하여 기술적인 지식을 요구한다. 운이 좋게도 현대의 응용프로그램들은 대부분 밝혀진 format으로 대부분 이루어졌기에 분석을 하기에 쉽다. 예로 SQLite DB는 Skyped에서 사용이 되며, 이는 SQLite 분석 프로그램에 의하여 자동적으로 분석이 가능하다.

Common Obstacles

 컴퓨터 유저들은 조사를 어렵게 하거나 느리게 하는 방식을 쉽게 갖는다. 아래에는 분석의 속도를 늦추며 범죄자들에 의하여 사용되는 몇개의 방식에 대하여 정리한 것이다. 한번 확인해 보자.

- History 파일의 기본 위치를 변경하는 방식

- 히스토리 파일의 이름이나 해당 폴더의 이름을 변경하거나 위치를 옮기는 방식

- 시스템의 권한이나 속성을 이용하여 히스토리 파일을 감추거나 보호하는 방식

- 히스토리 파일을 제거하는 방식

- 하드 디스크를 포맷하거나 파괴하는 방식

- 볼륨 전체를 암호화 하는 방식

- 히스토리를 유지하지 않거나 모든 로깅을 사용하지 않는 방식

 컴퓨터 사용자들의 대부분은 IT 보안의 전문가가 아니며 그렇기에 이러한 대부분의 장애물은 약간의 노력만으로 극복할 수 있는 불만 이상의 것은 아니다. 심지어 일반 사용자에 의해 전체 드라이브의 암호화가 구성되었을 때도 처리가 될 수 있다. 아래의 챕터에서는 이러한 기법에 대하여 자세히 논의할 것이며 각각의 장애물을 극복할 수 있는 사용가능한 방안에 대하여 추천할 것이다.

Obscuring and Information and Why it works

하드 디스크에서 정보를 숨기는 가장 명확한 방식은 모호한 이름으로 저장을 하거나 잘 사용하지 않는 위치에 해당 정보를 저장하는 방식이다. 이러한 트릭은 명확하고 합리적인 보안정책을 아직까진 통과할 수 없기에 약간의 보호 기능만을 제공한다. 하지만 왜 범죄자들에 의하여 이러한 방식이 여전히 사용되며 작동하는가?

 이에 대한 답은 간단하다. 조사자들은 모바일 포렌식이나, 컴퓨터나 노트북을 조사할 때 시간제약을 갖기 때문이다. 그들은 종종 가능한 모든 증거를 추출하기 위하여 20분에서 부터 몇시간까지 소요되기 떄문이다. 이러한 상황이 복잡하기 때문에 조사자들은 엄격한 규칙을 준수하고 있다. 이러한 규칙 중 하나를 해하므로 연구자들이 추출한 모든 증거들이 무효가 될 수 있기 때문이다. 

Retrieving Obscured Files : When File Location is Changed

 조사자들은 사용자의 모든 정보들이 기본 폴더에 위치해 있다고 기대해서는 안되며, 무엇이든지 기본 위치를 벗어나 존재할 수가 있다. 암호화 된지 않은 로그파일과 히스토리 파일을 찾기 위해 하드 디스크 전체를 검색하는 작업은 필요하다. 이러한 방식은 몇개의 오탐이 있으며 그렇기에 추가적으로 검사가 종종 필요하다. 

 현실적으로 어떠한 파일의 하나를 위치시키는 것은 명백한 작업이며 메신저나 Email 클라이언트 같은 응용프로그램은 자신들의 작업 파일에 대한 권한을 갖고 있어야 하며, 그들은 윈도우 레지스트리나 자신의 구성 파일 등 어딘가에 해당 내용들을 저장한다. 확실한 것은 분석될 각 응용 프로그램(P2P, Email, 메신저, 브라우저)에 대하여 많은 것을 알아야 하며 시간이 제한된 바쁜 환경 조건에서는 자동화된 방식이 유일한 해결방안이다. 

Hidden and Inaccessible Files and Folders

 컴퓨터 유저들은 종종 파일의 속성이나 권한을 이용하여 정보를 보호하며 이를 통해 무단 액세스를 방지할 수가 있다. 숨겨진 시스템파일이나 폴더는 일반적인 위치에 있는데 이들은 종종 포렌식 도구에 따라 강조되어 표시되기도 한다. 대부분의 포렌식 도구들은 NTFS 액세스 제어 권한 같은 파일 시스템에 의해 설정된 보안 속성 및 권한 제어 관리를 우회할 수가 있다. 특별히 주의해야 할 것은 접근할 수 없는 파일이나 폴더이다. 그렇지 않으면 액세스 제한을 갖는 폴더에 있는 증거들을 놓칠 수가 있기 때문이다.

Destroyed Evidence

오늘날에는 사용자의 행동으로 인한 손상이나 시간에 대한 손상 뿐만 아니라 저장 장치의 형태로서의 손상과 같이  디지털 증거를 손상시키려는 시도는 매우 일반적인 것이다. 이번 챕터에서는 손상된 증거를 복구하는 일반적인 사례와 방법에 대하여 논의할 것이다.

Deleted Files

 중요한 증거들은 종종 Recycle.biin에서 끝을 보게 되며 이는 Windows PC에 있어서 더욱이 그렇다 할 수 있다. 말 그대로, 삭제된 파일은 종종 휴지통이나 해당 파일들이 지워지기 전에 위치하였던 임시폴더 같은 곳의 내용을 분석하여 성공적으로 찾을 수가 있다. 

 만약 지워진 파일들이 더이상 휴지통에서 보이지 않는다면 상용 데이터 복구 도구를 이용해서 그 파일들을 복구할 수 있는 좋은 기회를 만들 수가 있다. 이러한 파일 복구의 원리는 파일이 지워져도 해당 파일의 내용을 삭제하지 않는 윈도우즈의 원리에 있다. 데이터를 지우지 않는 대신에 파일 시스템은 해당 파일의 위치에 삭제되었다는 플래그를 남기는 것이다. 그리고 이는 0으로 채워지거나 다른 데이터로 채워지기 전까지는 이전 데이터가 그대로 채워져 있다(SSD의 경우에는 좀 다르다.). 

 파일의 특성이나 시그니처를 하드 드라이브에서 찾거나 파일 시스템을 분석하는 것은 유저에 의해 지워진 파일 뿐만 아니라 많은 응용프로그램에 의해 생성된 임시파일이나 문서 작성 중에 임시저장된 파일과 같은 파일까지 복구가 가능하게 한다. 이를 다시 말해 'Carving'이라 한다.

Formatted Hard Drives

 사용자에 의해 하드 드라이브가 포맷된 후의 정보들은 아마 상용 데이터 복구 툴의 데이터 카빙을 통해 복구가 가능하다. 하지만 여기서 '아마'라는 단어에서와 같이 포맷된 하드 드라이브는 불확실하며 매개 변수의 다양한 설정에 따라 달라진다.

- Full Format

 윈도우에서는 Full과 Quick이라는 두가지 형태의 사용가능한 포멧이 존재한다. 빠른 포멧은 단순히 파티션을 포멧하는 새로운 (빈) 파일 시스템을 생성하여 디스크를 초기화하는 반면에 Full 포멧은 디스크의 배드 섹션까지 확인을 한다. 

 이름에서와 같이 전체 포멧은 항상 파괴적이며 윈도우 비스타 이전의 버전에서는 0으로 채우지 않지만 윈도우 7부터는 디스크의 내용을 지우고 0으로 기록한다. 그리고 신뢰성을 보장하기 위하여 섹터를 다시 읽는다. // SSD의 경우에는 따로 설명하겠다.

- Quick Format

 SSD를 제외하고 빠른 포멧은 퍄괴적이지 않다. 빠른 포멧으로 디스크에서 클리어 된 정보는 카빙을 지원하는 도구를 이용하여 복구가 가능하다. 

The Issue of SSD Drivers

 위의 내용들은 대부분 HDD나 USB와 같은 부분에 한정된다. SSD의 경우에는 다른 이슈들을 보아야 한다. SSD는 새로운 저장 기술을 대표하며 기존의 HDD에 비하여 빠르게 동작하며 쉽게 정보를 파괴하고 복구하기 어렵게 전혀 다른 방식으로 정보를 저장한다.

 이러한 방식의 핵심은 바로 TRIM 명령이다. 운영체제에 의해 삭제되었다고 표시가 되면 TRIM 명령은 해당 공간을 0으로 채운다. 쓰기 방지가 된 장비의 경우 TRIM 명령을 예방하는 것을 도울 수가 없다. 어떠한 실험에 따르면 SSD의 TRIM 명령은 3분 안에 모든 데이터를 완전히 지울 수 있다고 한다. 

 기존의 포렌식 방법들은 SSD 드라이버에서 삭제된 정보나 빠른 포멧이나 전체 포멧에 의한 어떠한 것들이든 복구하는데 실패하였다. 하지만 여기에는 예외가 존재한다. 위에서는 파일이 삭제되면 TRIM 명령에 의해 데이터를 복구할 수 없다고 말하였다. 이는 다시 말해, TRIM 명령이 일어나기 전에는 복구가 가능하다는 것이다. 또한 많은 구성 요소 중 적어도 하나는 TRIM을 지원하지 않는 경우에 발생할 수 있다. 이 구성 요소의 예로는 윈도우 비스타와 7은 TRIM을 지원하지만 XP의 경우에는 TRIM을 지원하지 않으며 파일 시스템의 구성 또한 마찬가지다. 파일 시스템의 경우 NTFS에서는 TRIM을 지원하지만 리눅스와 같은 FAT에서는 해당 기능을 지원하지 않는다. 

Data Carving

 카빙은 하드 드라이브 전체의 내용을 연속적으로 검사하며 정확한 비트를 찾는다고 할 수 있다. 카빙은 이를 통하지 않으면 사용될 수 없는 많은 아티팩트들을 찾는데 도움을 준다. 카빙은 파일복구의 개념과는 다르며 조사자들은 이를 통하여 디스크에서 부분적으로 덮어 씌워진 파일이나 조각나거나 흩어진 파일에 의존적이지 않아도 된다. 대신에 특정한 시그니처를 찾거나 몇가지 흥미로운 데이터가 디스크 상의 특정 지점에 저장 될 수 있는 단서를 제공할 수 있는 패턴을 찾는다. 

 카빙은 손상된 데이터를 찾는데 없어서는 안되며, 전통적인 HDD의 경우에는 데이터가 지워진 후 오랜 기간이 지나도 해당 데이터를 보존하기에 더욱 필요하다. 때때로 디스크를 포멧해도 해당 데이터가 원래의 형태를 유지하고 있는 경우도 존재하고 있다.

Carving Text Data

 일부 바이너리와 대부분의 텍스트 전용 형식은 여전히 Carving될 수 있으며 텍스트 정보는 아마 복구하기에 쉬울 것이다. 문자 데이터를 포함한 블럭은 문자나 숫자, 심볼과 같은 명확한 값으로 채워져 있다. 텍스트 데이터를 카빙하려할 때 조사자는 다양한 언어와 계정에 따른 인코딩을 고려해야 한다. 이는 한국, 중국, 터키, 미국, 일본에 따라 모두 상이하기 떄문이다.

 각각의 다른 인코딩은 그들이 지원하는 언어에 대하여 고려해야하는데 디스크에서 언어나 인코딩에 따른 정보를 읽을 때 일반적으로 텍스트 정보를 발견할 수가 있다. 이와 대조적으로 바이너리 데이터는 매우 랜덤한 형태로 나타난다. 따라서 텍스트 정보는 주어진 언어나 인코딩 조합에 속하지 않는 값을 확인하여 텍스트 블록의 시작과 끝을 확인하기에 비교적 용이하다.

Limitations of Data Carving

 카빙은 시그니처나 특유의 패턴에 의존하기에 모든 데이터가 카빙되는 것은 아니다. 바로 데이터 영역이 손상되었을 경우에는 카빙을 통하여 해당 시그니처나 데이터를 찾으려해도 실패하게 된다. 이뿐만 아니라 데이터가 흩어져 있는 경우에도 카빙을 통하여 복구하기에 제한된다.

When Data Carving is Not Available

 컴퓨터 유저가 데이터 카빙을 불가능하게 하는 몇가지 방법이 존재한다. 많은 수의 응용프로그램들은 하드 드라이브에 있는 정보를 안전하게 제거할 수 있으며 디스크에서 이전에 채워져 있는 민감한 정보나 데이터를 랜덤한 데이터로 채우는 특별한 알고리즘이 개발되었다. 이러한 파라노이드 상태에서 민감한 정보들은 추출이 불가능할 만큼 몇번 덮어씌우기를 진행한다. 만약 어떠한 응용 프로그램이 이러한 방법을 사용하면 카빙으론느 절대 복구가 불가능할 것이다. 하지만 디스크의 통계적 분석을 통하여 그러한 도구를 디스크에 사용했는지를 검출할 수가 있다. 덮어쓴 위치에 포함된 화이트 노이즈는 일반적으로 하드 드라이브에 저장되어 있지 않다. 그리고 이러한 사실이 정확한지 감지할 수 있는 도구들이 존재한다. 이러한 증거는 거의 없는 것으로 간주될 수 있지만, 실제로는 비정상적인 상황 경고를 줄 수 있다.

 또 카빙을 사용하지 못하게 하는 간단한 방법으로는 증거를 하드 드라이브에 저장하지 않는 것이다. 이 방법은 일상생활에서는 불편할 지라도 이는 브라우징이나 커뮤니케이션의 기록을 숨기는 일반적인 방법이다. 이러한 경우 라이브 RAM 분석이 최근의 활동을 복구 시킬 수 있는 유일한 방법이다.  

Encrypted Volumes

디스크를 암호화 하는 도구들은 강력하며 신뢰할 수 있고 완벽한 암호화 작업을 이행한다. 보통 조사자들은 보호를 위해 암호화된 볼륨의 평문 패스워드 문자를 알고자 한다. 하지만 많은 유저들이 점점 더 길고 복잡한 암호를 사용하고자 하기에 브루트 포스를 통한 방법을 사용하는 것이 대부분이다. 

 하지만 이러한 길고 복잡한 암호를 사용하는 것은 암호화 컨테이너에 침입할 수 있는 방법을 제시한다는 것은 사실이다. 그것은 쉬운 일을 하고자 하는 인간의 본성이며 사용자가 어떠한 것에 접근을 할 때마다 길고 복잡한 암호를 입력해야하는 것은 결코 쉽지 않다. 대부분의 유저들은 PC를 로드한 후에 한번만 패스워드를 입력한다. 암호화된 컨테이너는 전체 세션동안 'open'과 손쉽게 연결할 수 있게 해준다. 아주 명백히 이러한 암호화된 볼륨은 Cain&Abel이나 hashcat과 같은 도구들을 이용하게 크랙할 수가 있다.

Disabled Local and Remote Logging

 대부분의 응용프로그램들이 로컬 히스토리 파일을 생성하는 반면에, 몇 몇 응용프로그램은 클라우드에 해당 로그 파일을 저장하기 위하여 사용한다. 모든 로깅을 비활성화 하는 것은 범죄에 있어서 포렌식 조사를 통해 얻을 수 있는 디지털 증거의 수집을 방지하는데 효과적인 방법이다. 로깅이 비활성화 될 때, 로그 파일과 히스토리 파일은 클라우드 저장소에 디스크에 기록되지 않는다. 하지만 몇개의 로그들은 컴퓨터 메모리에 여전히 남아 있는다. 

 그러므로 Live RAM 분석은 몇개 혹은 최근의 모든 증거를 밝힐 수가 있다. 만약 컴퓨터가 켜져 있다면, 그 해당 램의 메모리 캡처 파일은 Live RAM 분석에 사용이 될 수 있을 것이며 컴퓨터가 꺼져있을 때 조사자들은 페이지 파일이나 하이버네이션 파일을 통하여 분석을 진행해야 한다.

Live RAM Analysis

 추가적인 디지털 증거들은 RAM을 분석하므로 추출될 수가 있으며 휘발성이라는 특성에 의해 이러한 RAM 분석을 위해서는 PC의 전원이 켜져있어야만 한다. 그렇기에 조사자들은 의심되는 분석 대상 PC를 종료하지 말라고 지시하는 이유이다. 이러한 메모리 캡처에는 많은 포렌식 도구(FTK Imager 외)들이 존재한다.

Locked Computers

 만약 분석하고자 하는 컴퓨터가 잠겨있다면, 조사자는 PC를 리부팅하려는 시도를 해서는 안된다. FireWire를 사용하는 윈도우 PC의 경우 유저에 의하여 비활성화를 하지 않는 한 Firewire 공격에 취약하다. 심지어 Firewire 포트를 사용할 수 없는 경우에도 hot-pluggable Firewire 어댑터를 사용할 수가 있다. Firewire 공격 방식은 잘 알려진 Firewire의 영향에 대한 보안 이슈에 의존한다. 조사자는 Firewire 케이블을 대상 PC에 연결하므로 해당 컴퓨터의 메모리를 직접적으로 컨트롤 할 수가 있으며, 조사자의 PC에서 작은 응용 프로그램을 시작할 수가 있다. 그런 후에 전체 메모리 스냅 샷을 캡처하는데 걸리는 시간은 얼마 걸리지 않는다. 명시적으로 이러한 장치 관리자에서 파이어와이어 드라이버를 사용하지 않도록 설정하는 것이 유일하게 이러한 공격으로부터 벗어나는 방법이다. 

Performing Live RAM Analysis

 데이터 카빙은 메모리 분석에서도 충분히 사용되며 이러한 카빙은 최근의 메신저 대화나, 주고받은 문자 메세지, 그리고 응용프로그램에 의해 사용된 임시정보와 같은 것들을 추출하는데 도움을 준다. 물론, 휘발성 메모리인만큼 최근의 정보들에 대해서만 접근이 가능하다. 이러한 방식으로 얻은 정보가 손상되었거나 부분적으로 덮어씌워졌다해도 없는 것보다는 있는 것이 훨씬 낫다.

Page Files and Hibernation File Analysis

PC가 종료되어도 남아있는 라이브 메모리의 내용이 존재하는데 윈도우는 이를 두가지 타입(페이지 파일과 하이버네이션 파일)으로 컴퓨터 메모리의 스냅샷을 유지한다. 이 두개의 파일은 운영체제 작업 루틴의 하나로써 디스크에 기록된 메모리 아티팩트들을 포함하고 있다.

 하이버네이션 파일은 보통 노트북의 절전모드를 통하여 많이 사용이 되며, 이는 배터리의 소모를 줄이기 위하여 상대적으로 덜 중요한 프로세스들을 메모리에서 내린 후 디스크에 기록을 해놓은 파일이다. 페이지 파일은 대부분의 컴퓨터에서 사용이 되며, 메모리에서 스왑 아웃된 프로세스에 대한 내용들이 기록되어 있다. 이 두 파일은 같은 카빙 기법을 통하여 분석이 될 수 있으며, 윈도우 하이버네이션 파일의 경우 사전에 압축해제 되어야만 한다.

Real Time Analysis and Other Considerations

 때때로 post-factum은 충분하지 않기에 많은 IT 보안 및 정보 전문가들은 많은 상용 키로거들을 사용해보거나 네트워크 트래픽을 차단해보며 범죄로 의심되는 것을 확인하였다. 이러한 기술을 여전히 가치가 있다고 할 수 있으며, 컴퓨터 감시의 범위는 이 문서를 벗어난다.

Worst Case Scenario

마지막으로 사용자가 할 수 있는 모든 방법 중에 어떠한 방법이 그들의 정보를 보호하는 방법인가? 만약 그들이 모든 것을 암호화된 볼륨 안에 저장하거나 그 외에도 그들의 정보를 보호하기 위한 기법을 중첩하여 사용한다면 조사자는 더이상 많은 것을 추출할 수가 없게 된다. 조사자는 여전히 대상 PC를 조사하며 그리고 증거를 수집한다. 

 하지만 대부분의 범죄들은 평범한 사람들이자 컴퓨터를 다루는 능력도 평범하하다. 심지어 그들은 정보 보안에 있어서 너무하다 싶을 정도로 무딘 경향을 보인다. 그렇기에 이들은 하나 또는 그 이상의 것들을 놓칠 수가 있으며, 이는 조사자들이 해당 컴퓨터에서 많은 정보를 쉽게 수집할 수 있는 환경을 제공한다. 

Reference

Retrieving Digital Evidence, http://articles.forensicfocus.com/2012/07/11/retrieving-digital-evidence-methods-techniques-and-issues/

개요

 File System Forensic을 공부하다보면 메타 데이터 영역이나 MFT라는 단어를 한번 쯤은 들어보았을 것이다. 여기서 MFT란 Mast File Table의 약자로 MFT 엔트리는 1024Bytes의 크기로 각 파일 및 디렉터리의 위치, 시간 정보, 파일 이름, 크기 등의 속성 정보를 가지고 있다.

 이러한 중요한 포렌식적인 요소를 가지고 있기에 중요하므로 이에 대한 문서를 다양하게 접할 수가 있다. 하지만 여기서 필자는 Forensic의 'F'자도 모르는 비전공자의 입장에서 포렌식 공부를 시작하였기에 MFT의 구조나 개념이 아닌 직접 어떠한 내용이 담겨 있는지 확인해 보고 싶었다. 그렇기에 직접 해당 파일을 찾아서 분석해보고 싶었지만 컴맹의 입장에서는 찾기 힘들었고 번거로웠기에 이번 포스팅을 진행한다.

FTK Imager

 보통 FTK Imager를 통하여 추출한다고 한다. 하지만 필자의 PC의 경우에는 추출이 가능하였지만 analyzeMFT와 작용이 제대로 이루어지지 않았기에 다른 방법을 찾게 되었다. 우선 FTK Imager를 통하여 추출한 파일을 MFT00라 저장하였고 아래와 같이 analyzeMFT를 이용하여 .csv 파일로 추출하려고 할 때 저 상태로 작동이 멈추어 버리는 것을 확인하게 되었다.

해당 상태에서 시간이 지나도 완료되지가 않아 작업을 취소하고 CSV 파일을 확인해보았더니 아무런 내용이 저장되어 있지 않은 결과를 확인할 수가 있었다. 다른 PC에서는 어떠할지 모르겠지만 필자의 PC(WIndows10 x64)에서는 제대로 동작하지 않으므로 FTK Imager가 아닌 다른 방법을 모색하여야 했다.

Winhex

 우선 Winhex를 통해 추출한 결과를 말하자면 성공적이였다. 하지만 그 과정에서 자꾸 다른 곳으로 바보같이 헤매었기에 이렇게 포스팅을 통해 정리하고자 한다. 우선 Winhex는 Free버전을 검색을 통하여 쉽게 다운받을 수가 있었다. 다운을 받은 후 해당 폴더에서 setup.exe를 통해 설치를 해도 되지만 설치를 하지 않고 바로 실행할 수 있는 Winhex.exe를 통하여 실행해보았다. (참고로 관리자 권한으로 실행하여야 한다.)

 실행시킨 후 우측 상단에 보면 붉은 상자로 표시한 부분이 존재하는 것을 확인할 수가 있다. 해당 부분을 눌러 현재 디스크의 정보를 수집하는 과정을 진행한다. 해당 과정이 완료되면 아래와 같이 파일들의 목록이 리스트로 정렬되며 여기서 $MFT라는 파일을 발견할 수가 있었다.

 그리고 해당 파일을 오른쪽 클릭하여 확인해보니 Recover/Copy...라는 부분이 존재하는 것을 확인할 수가 있었고 이를 통하여 해당 파일을 다른 곳으로 복사하거나 추출할 수 있을 줄 알았다. 하지만 이러한 방법은 틀린 방법이였다.

 해당 버튼을 클릭하면 0 file(s) and 0 directory/ies were copied.(0 B)라고 뜨며 Messages 박스를 확인해볼 경우 'With this evalution version you cannot save files that are larger than 200 KB.'라는 문구를 확인할 수가 있었다. 즉, 해당 프리버전에서는 200 KB가 초과할 경우 사용할 수 없다는 것이다. 그래서 다른 버전을 구해보기도 하며 전전긍긍하며 해결방안을 찾기 위해 노력해보았다.

 노력한 결과 알아낸 방법은 정말이지 간단해서 당황스러웠다. 이전과 같이 오른쪽 클릭을 통하여 목록을 확인해보면 Viewr Programs 라는 탭을 확인할 수가 있다. 여기서 필자는 Associated Program를 선택하여 HxD를 선택하였다.

 그 결과 제대로된 $MFT의 데이터가 HxD에 나타나는 것을 확인할 수가 있었다. 이제 파일 탭을 클릭하여 다른 이름으로 해당 파일을 저장하면 MFT 추출이 완료되는 것이다. 필자는 MFT0이라는 이름으로 파일을 바탕화면에 저장하였다.

 추출한 'MFT0'이라는 파일을 이제 analyzeMFT 툴을 이용하여 필요한 정보들을 읽기 편하게 뽑아낼 것이다. 여기서 .csv로 한 이유는 .csv로 선택하여 output된 파일은 아래와 같이 엑셀의 형태로 열리게 되며 이는 메모장을 통해 파일을 여는 것보다 훨씬 가독성이 좋게 나타나기 때문이다.

 위와 같이 'okidoki'라는 문자열이 출력되면 성공적을 작업이 완료되었다는 것이다. 따라서 이제 해당 .csv 파일을 열어서 확인해보면 아래와 같이 깔끔하게 내용이 정리된 것을 확인할 수가 있다. 만약 .csv 로 하지 않고 그냥 일반 텍스트 파일로 할 경우에는 정말 심할 정도로 가독성이 떨어지므로 불편한 분석을 하게 될 것이다. 아래와 같이 되어 있으므로 필요 없는 부분은 한번에 삭제가 가능하며 이는 우리가 필요한 정보를 선출하는데 도움을 주며, 정렬 기능을 이용하여 어떠한 부분을 기준으로 분석을 진행할 것인지에 편리함을 더해 준다.

개요

 USB와 관련된 아티팩트를 공부하며 직접 실습을 해보면서 어느 부분이 제대로 동작하는지, 이번 실습을 통하여 추후에 다시 학습을 할 수 있도록 하기 위하여 포스팅을 진행한다. 많은 USB 관련 Registry가 존재하지만 여기서는 몇개만 선출하여서 어떻게 동작하는지를 확인할 것이다.

  전체적인 타임라인은 아래와 같다. 크게 세 부분으로 나누었으며 USB를 최초 연결한 시간과 최초 연결로부터 분리한 시간, 그리고 마지막으로 USB의 마지막 접근 시간을 파악하기 위하여 재연결 시간 또한 확인을 하였다. 해당 포스팅은 아래의 타임라인을 중심으로 진행이 되며 이러한 타임스탬프가 변조되지 않았다는 전제하에 분석을 계속 진행할 것이다.

최초 연결 시간

 USB를 최초 연결하여 기존의 레지스트리에 변화가 있는지를 확인해보자. 여기선 최초 연결이라는 사항이 중요하기에 기존의 PC가 아닌 다른 PC 환경을 제공받아서 진행을 하였다. 진행된 PC의 환경은 WIndows 7 x86으로 본인의 PC인 Windows 10 x64와는 차이가 다소 있지만 아티팩트에 대한 접근 방법은 같기에 아무 이상은 없을 것이라 생각한다.

Setupapi.dev.log

 USB를 연결할 경우 흔히 언급되는 아티팩트로는 바로 %SystemRoot%\INF\Setupapi.dev.log를 말할 수가 있다. 해당 로그는 USB가 최초에 연결될 때에만 해당 로그를 남기며 이를 통하여 대상 PC에 USB가 연결이 되었는지, 만약 연결되었다면 어떠한 USB인지 대략적인 정보를 얻을 수가 있다.

  위의 그림을 보면 분석 이전의 log 파일에서는 존재하지 않았던 부분이 생긴 것이다. 이전의 로그기록은 9.14MB의 크기를 가지고 있지만 최초 연결 이후 로그파일의 크기는 9.20MB로 해당 로그에 내용이 추가되었음을 알 수가 있었고, 해당 로그의 내용은 위와 같이 [Device Install (Hardware Initated) - USB\{VID}&{PID}\{Serial Number}]의 형태로 나타난다. 

 로그에 기록된 Section Start를 확인해보면 2015/10/01 16:32:23으로 나타나있는 것을 확인할 수가 있다. 위 타임라인에서 보았던 연결시간과의 약간의 차이는 USB를 꽂는 수동적인 작업으로 인하여 몇초 정도 오차가 나타난 것이므로 같다고 생각하자. 그러므로 타임라인과 USB 연결시간이 같은 것을 확인할 수가 있다. 이를 통해 결국 USB를 최초 연결할 경우 setupapi.dev.log에 기록이 남는 것을 확인할 수가 있다.

Portable Devices - Registry

 USB연결과 관련하여 수많은 아티팩트들이 존재한다. 하지만 이러한 많은 아티팩트 중에서 하나만 살펴볼 것인데 바로 Portable Devices키이다. 해당 키의 서브 키들과 값을 출력해보면 왼쪽의 reg_4.16과 같다. USB를 연결한 이후의 값은 오른쪽과 같다.

 이를 통해 맨 위에 KALI LIVE라는 값이 추가된 것을 확인할 수가 있다. 이처럼 다른 레지스트리 키를 확인해도 비슷한 결과를 얻을 수가 있기에 최초연결에 관한 설명은 아래의 레지스트리로만 실습을 진행하였다. 그 외에 값들은 변화가 없이 유지되어 있는 것을 확인할 수가 있다.

마지막 연결 시간

 USB와 관련된 아티팩트에 있어서 최초 연결시간을 알면 도움이 되지만, 이것만으로는 어떠한 PC에서 두번째로 연결된 시간을 확인할 수가 없다. 최초 연결 시간만으로도 포렌식 분석에 있어서 도움이 되지만 이 뿐만으로는 더 구체적인 타임라인을 형성하기에 부족하다. 그렇기에 추가적인 아티팩트가 필요하다.

 이러한 추가적인 아티팩트로는 바로 마지막 연결시간을 말할 수가 있는데, 이에 대하여 진행해보자. 우선 여기서도 위의 타임라인을 참고하여 타임스탬프를 확인하면 된다. 이제 아래를 통해 확인해보자.

Registry

 위 그림은 REGA를 통하여 해당 레지스트리를 수집한 다음 분석을 한 것이다. REGA를 통하여 특정 시간대로 정렬을 한 다음 그 중에서 연결된 것만을 확인한 것이다. 우선 총 3개의 레지스트리는 모두 마지막으로 쓰인 시간이 16:32:22로 USB를 꽂았을 때 생성된 시간이랑 같다. 그리고 여기서 더 자세히 보아야 할 것은 LogConf를 보아야 한다. 

 해당 키의 마지막 쓰인 시간은 16:45:15로 최근에 USB를 연결한 시간과 동일하다는 것을 알 수가 있다. 이를 통해 우리는 마지막 연결시간이 언제인지를 확인할 수가 있다. 이외에도 다른 방법을 통하여 확인할 수 있겠지만, 필자는 저 방법을 선택하였다. 그리고 이를 통하여 필자는 USB의 마지막 연결 시간을 확인할 수가 있었다.

Event Log

 마지막으로 살펴볼 것은 바로 이벤트로그를 통하여 확인을 하는 방법이다. 운영체제는 특정한 행동을 하거나 오류 및 등의 이벤트가 발생하면 로그로 기록을 한다. 그리고 이러한 로그는 포렌식에서도 중요한 역할을 한다. 물론 USB와 관련된 이벤트 로그도 생성이 되는데 이는 Applications and services logs 항목 아래에 Microsoft\Windows\DriverFrameworks-UserMode에 기록이 된다.

 해당 로그를 확인해보면 아래와 같이 시간과 어떠한 이벤트인지 나타난다. 우선 타임라인과 함께 비교를 하면 4:32:31을 기준으로 '특정 장치에 대한 pnp 또는 전원..' 이라는 텍스트를 발견할 수가 있을 것이다. 더 자세한 문구는 직접확인해보면 되지만 대략적으로 USB의 연결과 연결해제에 관한 내용이 나타나 있다.

연결을 했을 뿐인데도 여러개의 이벤트가 생성이 되었으며 마찬가지로 연결을 해제 했을 경우에도 여러개의 이벤트 로그가 기록되어 있는 것을 확인할 수가 있다. 이를 통하여 결론적으로 USB연결과 관련된 아티팩트를 발견할 수가 있었다. 하지만 이벤트 로그를 이용한 방법은 윈도우 7에서까지만 유효하다고 할 수 있는데 그 이유는 해당 이벤트 로깅이 윈도우8부터는 기본설정으로 되어 있지 않아, 따로 수동으로 값을 수정해주어야 하기떄문이다.

 따라서 윈도우7까지는 이 방법을 사용하는 것이 확인하기도 쉬우며 장치 연결시간 뿐만 아니라 해제 시간까지 로깅되기에 더욱 자세하게 타임라인을 이어나갈 수가 있다. 하지만 윈도우 8부터는 대부분의 PC에 설정이 되어있지 않을 확률이 높기때문에 이를 염두하여야 한다.

결론

이번 포스팅을 통하여 직접 USB 아티팩트를 찾아보았다. 사실 최초 연결시간에 관해서는 너무나 많은 아티팩트가 존재하기에 이를 선별하기 위하여 이번 실습을 진행했던 이유가 크다. 그래서 몇개만 선별하여 진행을 해보았는데 대략적인 분석 방법은 유사하다고 말할 수가 있다.

 USB 아티팩트는 크게 3가지 방법으로 찾을 수 있으며 레지스트리 분석, 이벤트 로그 분석, setupapi.dev.log를 이용한 분석과 같다. 결국 3가지 방법을 위에서 모두 다 다루었으며 로그를 이용한 분석들은 상대적으로 쉽게 확인을 할 수가 있었지만 레지스트리는 마지막 쓰여진 시간을 확인하기도 해야하며 직접 어떻게 타임라인이 진행되었는지를 알아야 하기에 다소 복잡하게 느껴질 수도 있다. 하지만 반복적으로 다른 키들을 분석하더라도 방법은 유사하기에 직접 분석을 진행해보면 더욱 좋을 것 같다.

Reference

http://mr-zero.tistory.com/103

http://forensic-proof.com/archives/5945

Practice Last Connection Time - Last Written time in registry key

 마지막 연결 시간을 확인하기 위하여 직접 USB를 새로 연결해보았다. 그리고 근처 시간의 레지스트리 타임스탬프를 검색해본 결과 위와 같이 USB와 관련된 항목 3가지를 발견할 수가 있었다. 그리고 왼쪽 탭에서와 같이 마지막으로 쓰여진 시간이 일치한 것을 확인할 수가 있다.

 따라서 조사할 PC의 해당 경로에서 해당 타임스탬프를 확인하면 마지막으로 USB를 연결한 시간이 언제인지를 확인할 수가 있을 것이다.

장치 연결 흔적 확인 - 이벤트 로그

USB와 같은 장치를 연결하면 윈도우는 장치로부터 드라이버를 받아 설치하거나 이미 있다면 기존 드라이버를 로드시키고, 연결 해제 시 드라이버를 언로드 시킨다. 이와 같은 드라이버 이벤트는 다음 로그 파일에 기록된다.

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

Reference

해당 이벤트로그와 관련해서 더 자세하게 설명된 곳 : http://forensic-proof.com/archives/5945

http://mr-zero.tistory.com/103

1. Introduction

 Project Spartan이란 IE의 뒤를 이어 새로 나온 MS의 Edge의 코드네임이다. 이번 문서를 통해서는 이러한 Edge가 남기는 Artifacts에 대하여 알아볼 것이며 ,무엇이 이러한 흔적으로 남는지, 어느 위치에 해당 흔적이 남는 지, 어떻게 수집되는 지를 분석할 것이다. 또한 이 문서는 결국 이전의 IE와 차이가 크지 않다는 결론으로 이끌게 될 것이며 이는 동작하는 방식과 데이터를 저장하는 방식이 이전과 유사함을 의미한다. 그리고 이러한 흔적을 자동적으로 수집할 수 있게 도와주는 도구에 대하여 알아볼 것이다.

 웹 브라우징 활동은 포렌식 분석에 있어서 중요한 요소이기에 많은 도구들이 이를 위하여 존재하고 있기도 하다. 이러한 도구들은 웹 브라우저의 구조에 많이 의존하며 그렇기에 각 버전이나 새로운 브라우저에 따라 다른 경로 파악이나 코드를 사용하여야 한다.

 마이크로소프트는 Windows 10으로 오면서 기존의 IE를 벗어나 Edge를 적용하였으며 그렇기에 필자의 목적은 Edge의 아티팩트를 수집하고 분석하는 것에 초점을 두고 있다. 해당 참고 포스터가 2015.07.27인 점을 보아 현재의 Edge와 다른 부분이 꽤 존재하고 있기에 이러한 부분은 필자가 직접 확인하고 올바르게 나타내도록 하겠다.

1.1 Scope, Motivation and research question

 Edge는 웹 브라우저 중 가장 최근에 개발된 것으로 아티팩트 분석에 있어서 많은 흥미를 유발시키며 점차 많은 사람들이 윈도우10을 사용하게 될 경우 이는 더욱 중요한 사하잉 된다. 그러므로 이러한 정보들은 디지털 포렌식의 가치가 있으며 지속적인 조사가 필요하다. 해당 포스팅은 아래의 문구에 주로 초점을 두고 작성되었으며 이를 상기하며 분석을 진행할 것이다.

What and where are the artifacts Project Spartan leaves behind on workstations, and how can these artifacts be gathered for further analysis to serve as forensic evidence? 

 이러한 연구 주제는 아래와 같은 Sub research Question으로 나누어 볼 수가 있다.

- 프로젝트 스파르탄이 기존과 얼마나 다른지, 기존의 툴킷들이 Edge에서도 사용 가능한가?

- 자동화 방식으로 웹 브라우저의 아티팩트를 수집하기 위한 툴이 개발 될 수 있는가?

2. Related work

 Windows 10과 Microsoft Edge는 최근에 공개되었기에 상대적으로 관련된 공개 문서나 자료가 적은 것은 사실이다. 따라서 여기서는 프로젝트 스파르탄의 구조를 분석할 것이고 Microsoft IE의 최근 버전의 정보 저장에 대하여 분석할 것이다. 그러므로 우리는 두 개(IE & Edge)를 서로 비교하는 경우(아티팩트와 관련하여)가 존재할 것임을 알아야 한다.

2.1 Browser Forensic

 브라우저와 관련된 포렌식은 흔히 디스크에서 아티팩트가 저장되는 장소와 연관이 크며 이는 브라우저마다 상이하다. 그렇기에 새로운 브라우저가 출시되면 해당 장소에 대한 정보와 아티팩트 수집에 관한 방법이 요구된다. 포렌식 조사자는 웹 브라우저 아티팩트에 관한 자세하고 신뢰성 있는 정보들이 필요하며 이러한 정보는 조사에 있어서 매우 중요한 가치가 있을 수 있다. 따라서 이러한 사용자 활동의 증거 분석을 게을리 할 수가 없다.

 Private browsing은 브라우징을 하는 동안 개인정보호를 위하여 점차 증가되는 추세이다. 이러한 Private browsing은 크롬이나 파폭, IE 등에서 지원을 하지만, 개인 정보 보호의 입장에서는 IE 보다는 크롬이나 파폭이 인기가 더 있는 추세이다. Private browsing은 사용자 활동의 증거를 거의 남기지 않아 포렌식의 입장에서 꾸준한 개발을 지속하고 있다. 

2.2 Structure of Internet Explorer

 이번 조사의 가장 큰 목적은 IE 10이나 그 이후의 버전과 관련이 되었으며 이는 많은 구조에서 Project Spartan과 유사함을 알 수가 있었다. IE 10v+와 Project Spartan은 정보 저장에 있어서 Extensible Storage Engine(ESE) DataBase와 Joint Engine Technology(JET)에 의존하는 것을 확인할 수가 있었다. IE 10은 WebCacheV1.dat이라는 하나의 데이터 베이스에 아티팩트를 저장하며 이 위치는 아래와 같다.

ESE Database 관련 참고 자료 : http://forensicmethods.com/ese-recovery

 해당 데이터베이스에 나타난 아티팩트는 다른 유형(Cache, hHstory, Cookies)들과는 차이가 있으며 이러한 유형들은 다른 컨테이너 테이블('Container XX')에 안에 나누어져 있다. 각 컨테이너는 같은 필드를 공유하며 이는 포렌식 조사에 있어서 가치가 있다고 할 수 있다. 메모리에서 로그 캐시에 있는 트랜젝션과 관련된 정보가 ESE 첫 부분에 저장될 때, 그 후 메모리에서 데이터베이스 페이지를 저장한다. 시스템이 로그 파일을 기록할 준비가 되자마자 가능하다면 데이터베이스가 Clean State에서 새 트렌젹센와 함께 업데트 되고 만약 가능하지 않다면 Dirty State로 진행이 된다. 만약 데이트베이스가 Dirty일 경우 .chk파일과 log 파일을 사용하여 복구가 진행될 것이다. 또한 esentutl Windows Tool을 사용하여 Clean State로 복구가 될 수 있다.  대부분의 아티팩트들이 여기에 저장될 뿐만 아니라 디스크에서 파일로서도 발견이 된다. 이러한 IE의 파일들은 아래의 경로에 위치한다. 

 해당 경로에는 캐시파일과 쿠키 등을 볼 수가 있다. 이러한 정보는 레지스트리에서도 확인이 가능하다. 

3. Approach

연구의 첫 번째 파트는 프로젝트 스파르탄의 구조를 이해하고 사용자에 대한 정보를 저장하는 방법에 대한 이해를 이야기 할 것이고. 두번째 파트는 어떻게, 어디에서 아티팩트가 발견되는지를 조사할 것이다. 그 후 웹브라우저 도구들을 이용하여 테스트를 진행할 것이다. 마지막 스텝에서는 툴을 이용하여 가치있는 무엇을 찾을 수 있는지 확인할 것이다. 해당 연구에서는 아래의 도구들이 사용되었다.

- ESEDatabaseView v1.30

- ESECarve v1.20

- Notepad++ v6.7.8

4. Artifacts Analysis

여기서는 프로젝트 스파르탄(현재의 Edge)가 어디에 아티팩트를 저장하는지를 설명할 것이며, 어떠한 특징이 있는지 어떠한 아티팩트를 남기는지에 대하여 설명할 것이다. 본문에서는 Spartan이라는 디렉터리나 레지스트리 키가 자주 보이지만 이 포스터에서는 본인의 PC (Windows 10)에서 Edge에 해당하는 부분으로 직접 찾아서 설명할 것이다.

4.1 Database

 Microsoft의 Edge는 IE의 최선버전들과 같은 DB 구조(ESE)를 가지고 있다. 메인 WebCache DB 파일은 사용자에 따라 %LocalAppData% 환경변수 항목에 위치하고 있으며 이 경로는 아래와 같다.         // 해당 부분의 DB를 Edge에서는 찾지 못해 스파르탄의 형태로 나타내었습니다.

DB 파일을 읽기 위해 존재하는 많은 종류의 도구들이 존재하지만 여기서는 위에서 말했던 도구들을 사용할 것이다. 해당 DB 파일에는 저장된 정보들이 정렬되어 있지만 많은 실질적인 내용이 많이 존재하지는 않는다. 대신에 이는 실질적인 아티팩트가 저장되어 있는 주소에 대한 인덱스와 같다.

 이 파일을 HxD로 열려고 할 때, 기존에 사용되던 버전과 같은 구조를 같음을 확인할 수가 있었다. DB 파일의 헤더 부분을 해석하면 아래의 그림과 같다. 각 바이트는 리틀 엔디언으로 기록되어 있으며 해당 값을 읽을 때는 역순으로 읽어야한다. 

AppData\Local\Microsoft\Windows\WebCache\WebCacheV01.dat

해당 Database에는 시스템에서 지역적으로 저장되어 있는 모든 다른 아티팩트의 주소를 포함하고 있다. 해당 컨테이너에서는 다른 컨테이너의 ID 항목들을 볼 수가 있으며 컨테이너에 어떤 내용이 있는지 또한 확인을 할 수 있다.

4.2 Cache

 Edge의 경우 분산된 형태로 캐시를 저장하며 해당하는 경로는 아래와 같다. 아래에서 #!xxx라고 표시한 부분에는 #!001, #!002, #!121이라는 3개의 디렉터리가 존재하며 각 폴더 모두에 해당 데이터 들이 저장되어 있다.

 IE와 유사하게 각 캐시폴더에는 많은 내용의 캐시 내용들이 저장되어 있으며 웹 브라우징 중에 생긴 HTML 페이지나 사진 등 많은 내용들이 저장되어 있는 것을 확인할 수가 있다. 

추가 : \AppData\Local\Packages\Microsoft.MicrosoftEdge_8wekyb3d8bbwe\AC\MicrosoftEdge\Cache

4.3 Cookies

 Edge의 쿠키 내용들이 저장되는 경로는 아래와 같으며 이 역시 !#xxx의 형태로 나뉘어 저장된다. 해당 폴더를 확인하면 .txt의 형태로 여러개의 랜덤한 이름의 파일이 존재하는 것을 확인할 수가 있다. 해당 파일의 내용에 바로 쿠기 내용이 저장되어 있다. 해당 쿠키들이 어느 도메인에 속한지 WebCacheV01.dat를 봐도 알 수가 있다.

추가 ; \AppData\Local\Packages\Microsoft.MicrosoftEdge_8wekyb3d8bbwe\AC\MicrosoftEdge\Cookies

4.4 Bookmark

 Edge의 북마크 목록 또한 아티팩트로 존재하는데 이는 아래의 경로에 존재한다. 해당 경로로 가면 .url의 형태로 존재하는데 내용을 확인해보면 해당 사이트의 URL을 출력해주는 것을 확인할 수가 있다.

4.5 Visited URLs (History)

 사용자가 방문했던 URL의 정보는 실질적인 내용을 보여주지 않지만, 포렌식 조사에 있어서 충분히 가치가 있는 정보들이다. 이러한 URL 정보들은 위의 4.1에서 다루었던 DB 파일에 저장이 되어있으며 이는 중요한 아티팩트가 될 수가 있다. 

4.6 Download list

 다운로드 리스트는 4.5와 같이 4.1의 DB에서 발견할 수가 있다. 해당 컨테이너의 이름은 iedownload이며 해당 지점에 그 이름으로 여러개의 컨테이너가 존재하지만 시스템에서 컨테이너 ID 17이 바로 해당 컨테이너이다. 해당 컨테이너에는 hex 코드로 되어 있으므로 ASCII로 변환하여 읽어야 한다.

4.7 Web Notes

 Edge에서부터는 웹노트라는 기능이 추가되어 브라우저에서 웹페이지를 캡처하여 바로 메모를 할 수게 해주는 기능이다. 이러한 웹노트는 두 경로를 알아야하는데, 하나는 임시로 저장되는 경로와 다른 하나는 완성된 파일이 기록으로 남는 장소이다.

4.8 Cortana

 Cortana란 인공지능 인식 서비스로 원래는 윈도우 폰에 적용되던 서비스지만 윈도우 10부턴 PC에 적용이 되어 사용자의 편의를 돕는다. 하지만 이런 기능은 일부 국가 언어에서만 지원하기에 한국에서는 아직 사용할 수가 없다. 이에 대한 정보는 4.1에서 'Dependency Entry 5'라는 컨테이너에 존재하므로 해당 컨테이너를 확인하여야 한다.

4.9 Reading List

 Reading List는 읽기 목록으로 즐겨 찾기에 추가된 것이 아니라 읽기 목록이라는 카테고리가 따로 존재한다. 읽기 목록에 새로운 페이지를 추가할 경우 아래의 파일에 해당 주소가 추가되어 아티팩트가 남는다.

4.10 Tiles

 윈도우 8부터 타일은 사용이 가능했으며 수정이 가능했다. 이 타일 기능은 당연히 Edge에도 포함이 되었으며, 타일은 글꼴, 색상, 인터페이스 요소로 구성되어 있다. 이 타일은 ESE DB에 저장이 되지 않지만 디스크에서는 발견이 가능하다. 해당 경로는 아래와 같다.

 Private Browsing을 분석함에 있어, 우리는 PC 환경을 최신버전으로 업그레이드 시킬 필요가 있으며 Edge는 개인정보보호 브라우징을 제공한다. 사용자가 방문했던 페이지를 검색하기 위해서 우리는 ESECarve를 사용할 것이다. 해당 툴은 윈도우 10에서 inpriveate 브라우징 아티팩트를 검색하기 위하여 사용되며 윈도우10에서 호환성을 위하여 해당 디렉터리에 DB 파일(.chk & WebCache01.vat)을 포함해야 한다. 이를 통하여 찾게 된 로그들은 라이프 사이클에 대하여 설명할 수 있는 하나의 단서가 되며, inprivate 히스토리는 ESEDatavaseview를 통하여 복구할 수 있다. 

5. Result

 이번 장에서는 위에서 조사한 결과를 토대로 정리할 것이다. 그리고 IE와 Edge를 비교하여 유사한 점과 차이점에 대하여 정리할 것이다. 

5.1 Project Spartan vs Internet Explorer (Similarities and differences)

 이번 절에서는 두 브라우저가 남기는 아티팩트를 비교하여 정리할 것이다. 전체적으로 두 브라우저가 남기는 아티팩트는 유사한 점이 많았다. 프로젝트 스파르탄의 모든 기능을 언급하기에는 힘들기에 모든 차이점과 유사점에 대해 언급하는 것은 어렵다.

 가장 먼저, 둘의 유사점에 대하여 정리하면 그들은 사용자 활동에 대한 정보를 저장하기 위해, 크러시가 발생했을 때 복구를 하기 위하여 ESE database라는 같은 엔진을 사용한다. 두 브라우저가  Microsoft Exchange server, Active Directory와 Desktop search에 사용되는 ESE라는 database 엔진을 사용하는 것을 알 수가 있다. 그 결과 Project Spartan과 IE가 매우 유사한 구조를 가질 수 밖에 없음을 알 수 있다. 이는 ESE database에서 아티팩트를 찾도록 만들어진 소프트웨어가 Project Spartan에서도 사용이 가능하다는 것을 알 수가 있다. 하지만 약간의 문제들로 인하여 윈도우 10에 최적화될 필요가 있다.

 바로 프로젝트 스파으탄에서부터 도입된 새로운 기능들이 존재한다. 이러한새로운 기능은 포렌식에서 중요하다고 여겨질 수 있는 새로운 아티팩트를 남긴다. 새로운 기능이란 4장에서 다룬 것 중에서와 같이 Cortana가 있다. 코타나를 통하여 어떠한 조사 가치가 있는 정보들이 저장이 된다. 또한 코타나 외에도 Reading List나 웹 노트의 경우에도 새로운 아티팩트들을 남겨주는 것을 확인할 수가 있었다. 결론적으로, 스파르탄의 구조는 IE의 최신버전과 유사함을 알 수가 있다. 새로운 아티팩트들은 IE에 없던 기능들에서부터 생겨나는 것으로 위에서 몇 가지 요소에 대하여 다루었다.

6. Reference

Project Spartan, http://articles.forensicfocus.com/2015/07/27/project-spartan-forensics/