개요

$LogFile?

  지금까지의 과정은 $MFT를 위주로 진행되어왔다. 이제 MFT Entry 2번($MFT가 0번)에 위치하는 $LogFile에 대하여 알아보자. 추후에 학습할 $UsnJrnl이 변경 로그라면 $LogFile은 트랜젝션 로그이다. 이 역시 각 볼륨마다 하나씩 존재하며 만약 NTFS가 정전이나 기타 오류로 인해 갑작스럽게 중단되면 운영체제는 $LogFile에 저장된 로그를 바탕으로 현재 진행되는 작업의 이전 상태로 파일 시스템을 복구한다.

  파일이나 디렉터리의 생성, 삭제, 데이터 작성, 파일명 변경 등 트랜잭션 작업 내용은 레코드 단위로 기록되며, $LogFile의 작업 레코드에 저장된다. 각 작업 레코드는 고유의 LSN($LogFile Sequence Number)를 가지며 이는 순차적으로 증가한다. 이러한 각 레코드는 복구를 위해 작업 데이터(Redo)와 작업 전 데이터(Undo)를 갖는다.

$LogFile Size

  일반적인 하드 디스크 볼륨에서는 64MB인것을 알 수가 있으며 볼륨 용량에 따라 크기가 달라질 수는 있지만 기본적으로는 최대 64 MB 이하이다. 만약 이러한 $LogFile의 크기를 변경하고자 할 때는 chkdsk 명령의 /L 옵션에 따라 크기 조절이 가능하며 '/L:파일크기(KB 단위)' 형식의 옵션을 주면 $LogFile의 크기를 변경할 수 있으며 크기를 지정하지 않는다면 위의 그림과 같이 현재 크기를 나타낸다.

구조

$LogFile의 전체적인 구조

  $LogFile은 아래의 그림과 같이 재시작영역(Restart Area)과 로깅 영역(Logging Area)으로 나뉘어진다. 각 영역의 구성 단위는 0x1000(4096)바이트 크기의 페이지이다. 재시작 영역은 파일의 가장 첫 두 페이지(0x0000~0x20000)에 해당하고 가장 마지막 작업에 대한 정보를 가지고 있다.

  로깅 영역은 재시작 영역 외의 영역(0x2000~)을 말하며 실제 작업 레코드들이 기록된다. 로깅 영역은 다시 버퍼 페이지 영역과 일반 페이지 영역으로 구성된다. 이에 대한 건 좀 더 뒤에서 이야기할 것이다.

$LogFile 재시작 영역 구조

  위에서 말한 바와 같이 재시작 영역은 가장 마지막 작업 레코드를 가리키며 이는 현재 작업 중인 내용으로 0x0000부터 두 페이지(0x2000)로 구성이 된다. 여기서 두 번째 페이지는 백업용으로 사용되며 각 페이지는 매직넘버(RSTR)로 시작한다. 운영체제는 이 영역에서 마지막 레코드에 대한 정보를 가져와서 파일 시스템을 복구하는 것이다. 위의 그림은 재시작 영역의 페이지 헤더 구조이며 Cuurent LSN 필드에 마지막 작업 레코드의 LSN 정보를 저장하고 있다.

  위 그림은 실제 $LogFile을 Hex Editor로 열어서 확인한 것으로 상단의 그림은 첫 번째 페이지 영역으로 매직넘버 RSTR로 시작하는 것을 확인할 수가 있다. 하단의 그림은 두 번째 페이지 영역(0x1000~0x2000)의 시작 부분으로 위와 같은 구조를 가지고 있으며 백업을 위한 공간임을 알 수가 있다.

* 재시작 영역은 운영체제가 어떠한 파일 시스템의 정리를 수행할 경우 어떠한 트랜잭션을 참고해야 하는지 판단하는데 도움을 주는 구조체이며, 성공적인 마지막 트랜잭션을 위한 어떤 로깅 영역을 가리키는 포인터를 포함한다.

$LogFile 로깅 영역 구조

  로깅 영역에는 실제 작업 레코드들이 기록되며 버퍼 페이지 영역과 일반 페이지 영역으로 나뉘어진다. 여기서 버퍼 페이지 영역은 첫 두 페이지(0x2000~0x4000)가 존재하고 두 번째 페이지는 위와 같이 백업용이며 순차적으로 레코드가 기록된다. 여기서 만약 버퍼 페이지가 레코드로 가득 차게 되면 페이지 내용을 일반 페이지 영역으로 기록을 넘기는 형식으로 작업이 진행된다. 따라서 가장 최근의 작업 레코드들은 버퍼 페이지 영역에 남게 된다.

  일반페이지 영역은 버퍼 페이지를 제외한 나머지 영역(0x4000~)을 말하며 버퍼 페이지가 모두 채워지면 기록된 내용을 받는 역할을 한다. 만약 작업 레코드들이 파일 끝까지 가득 차게 되면 위의 그림과 같이 일반 페이지 영역 시작부분부터 다시 덮어쓰는 방식으로 진행된다.

* Redo 필드는 어떤 동작이었는지에 대한 정보를 저장하며, Undo 필드는 어떤 동작을 어떻게 원래대로 되돌리는지 설명하는 정보를 저장한다.

Page 구조

  페이지는 $LogFile의 기본 구성 단위이며 크기는 0x1000(4096 Bytes)로 고정되어 있다. 페이지는 하나의 헤더와 다수의 작업 레코드들로 구성되어 있으며 마지막 레코드가 페이지를 넘어가면 다음 페이지에 이어서 기록이 된다. 위의 그림은 이 구조를 나타낸 것으로, 페이지 헤더에 매직 넘버('RCRD')가 나오는 것을 확인할 수가 있으며 Last LSN 필드의 정보를 통해 페이지 내에서 가장 나중에 기록된 작업 레코드의 LSN 정보를 획득할 수 있다. Next Record Offset 필드의 정보를 통해 페이지 내에서 가장 나중에 기록된 작업 레코드의 위치를 알 수가 있다.

  결국 운영체제는 재시작 영역의 Currsnt LSN 필드에서 가장 마지막에 기록된 LSN 정보를 가져와서 해당 LSN 정보를 Last LSN 값으로 가진 페이지를 찾고, 그 페이지의 Next Record Offset을 가져와 실제 마지막 기록된 레코드의 위치를 찾는다.

작업 레코드 구조

  작업 레코드에는 실제 트랜젝션 작업의 내용이 기록되며 위의 그림과 같이 여러 작업 레코드가 순차적으로 모여서 하나의 트랜젝션 작업을 이룬다. 가장 첫 레코드를 Checkpoint 레코드라 하며 마지막 레코드를 Commit 레코드라 한다. 그 외 중간에 있는 레코드들은 Update 레코드라 한다.

  Checkpoint 레코드 외의 레코드들은 자신의 이전 작업 레코드의 LSN 값을 가지고 있다. 따라서 파일 시스템 복구 시, 운영체제는 트랜젝션 작업을 구성하는 레코드들을 역추적하면서 각 레코드들의 Undo 데이터를 사용하여 복구할 수가 있다.

[이미지 출처 - zrungee Blog]

  작업 레코드는 레코드 헤더와 데이터 영역으로 구성된다. 레코드 헤더는 고정된 0x58 크기를 가지며 데이터 영역은 Redo와 Undo 데이터가 들어가기 때문에 크기가 가변적이다. 따라서 작업 레코드의 크기도 가변적이며 큰 레코드는 여러 개의 페이지를 사용하기도 한다. 그리고 하나의 작업 레코드가 끝나면 바로 이어서 다음 작업 레코드가 이어진다. 상세한 작업 레코드 헤더 구조는 위의 그림과 같으며 각 필드에 대한 설명은 아래의 표와 같다.

  Redo Op 필드와 Undo Op 필드는 실제 레코드가 어떠한 작업을 수행하였는지에 대한 정보를 가진다. 각 Op가 가지는 연산 코드의 의미는 아래와 같다.

출처 및 참고

http://www.ahnlab.com/kr/site/securityinfo/secunews/secuNewsView.do?curPage=1&menu_dist=2&seq=19518

http://zrungee.tistory.com/206

개요

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

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

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