$UsnJrnl

  응용 프로그램이 특정 파일의 변경 여부를 파악하기 위해 사용한다. 기본적으로 Windows 7부터 활성화가 되어 있으며 비활성화 되어 있을 경우, Fsutil로 활성화 시 킬 수 있다. UsnJrnl은 $Max 속성과 $J 속성으로 구성되는데 $MAX는 변경 로그의 기본 메타 데이터를 저장하며 $J속성은 실제 변경 로그 레코드를 저장하고 있다.

  여기서 $J의 각 레코드들은 USN(Updata Sequence Number)정보를 가지며, 이러한 USN 정보를 통해 각 레코드들의 순서를 구분한다. 실제 USN 값은 $J 속성 내에서의 레코드의 Offset 값을 가지고 있으며, USN 값은 MFT 엔트리의 $STANDARD_INFORMATION 속성에도 저장되어 있다. UsnJrnl은 MFT 엔트리의 10번째인 $Extend 디렉터리 안에 존재하고 있다. /$Extend/$UsnJrnl 와 같은 경로를 가지고 있다.

 기록 되는 로그 데이터의 양은 일반적으로 컴퓨터를 계속 사용할 경우 1~2일 정도의 로그가 남으며, 규칙적(하루 8시간)으로 사용할 경우 4~5일 정도의 로그가 남는다.

$UsnJrnl 구조

$Max 속성의 구조

  $Max 속성은 32 Byte의 고정된 크기를 가지며 해당 속성에 저장되는 정보는 아래와 같이 로그 데이터의 최대 크기, 그리고 $UsnJrnl 파일의 생성시간, 마지막으로 현재 저장된 레코드 중 가장 작은 USN 값을 갖으며, 해당 값을 통해 $J 속성 내 첫 번째 레코드로 바로 이동이 가능하다.

$J 속성의 구조

  $J 속성은 가변적은 크기를 가지며, 로그 레코드들이 연속적으로 나열된다. 또한 속성의 앞 부분은 0으로 채워진 "Sparse Area"를 가지고 있다. 아래의 그림은 내 PC의 $UsnJrnl:$J를 나타낸 것으로 0부터 0x57800000 전 까지는 모두 0으로 채워져 있는 것을 확인할 수가 있다. 이러한 구조를 가지는 이유는 운영체제가 $J 속성에 저장되는 로그 데이터의 크기를 일정하게 유지하려고 하기 때문이다.

  $J 속성은 새로운 로그 레코드들이 할당 될 때마다 속성 끝에 추가되며, 추가된 레코드들의 총 크기가 "Allocation Size"를 넘으면 추가 레코드들을 포함하여 전체 로그 데이터의 크기가 "Maximum Size"를 넘는지 확인한다. 만약 전체 로그 데이터의 크기가 "Maximum Size"를 넘는다면 로그 데이터의 앞 부분을 "Allocation Size" 만큼 0으로 채워 "Sparse Area"로 만든다.

  따라서 $J 속성의 논리적인 크기는 계속 커지지만 실제 데이터가 할당된 영역은 일정하게 유지되며, 일반적으로 0x2000000~0x23FFFFF의 로그 데이터를 저장한다.

  MFT Reference Numbr 대신 Parent MFT Reference Number를 사용하는 이유는 전자를 사용할 경우, 해당 파일이 삭제되었을 때 전체 경로를 못 얻을 수도 있기 떄문이다. 

<Reason Flag>

<Source Information>

<File Attribute>

출처 및 참고

F-INSIGHT-NTFS-Log-TrackerKorean.pdf

개요

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

 여기서 파일의 생성과 삭제와도 밀접한 연관이 있는데, 드롭퍼나 다운로더의 경우 다른 파일들을 새로 생성하거나 다운 받은 다음에 이를 실행하도록 하기에 만약 다양한 안티리버싱 기법으로 인하여 어떠한 파일이 생성되는지나 삭제, 이동하는지 확인이 어려울 때 바로 $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과 같은 방식으로 진행하다가 중요한 파일의 생성 여부를 놓칠 수가 있기에 조심하여야 한다. 아무래도 가장 좋은 방법은 파일의 생성과 삭제에 있어서 리버싱과 포렌식 두 방식 모두 활용하는 것이 좋은 경우인 것 같다.

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