파일 삭제 흔적 찾기 (NTFS) #nagoona

 

 

 

• 이걸 왜 했냐면?

공격자가 파일을 지우는 방법이 몇가지 있는데 이와 관련하여 확인할 수 있는 아티팩트가 궁금했었다.

이를 윈도우에서 특히 많이 쓰이는 파일시스템인 NTFS에서 사용되는 아티팩트에서 확인해보려고한다. 삭제된 파일이 중요한 이유는 침해사고 분석이 일어난 시간을 근거로 타임라인 분석방법을 사용하기 때문이다. 공격자가 악성 행위를 위해 설치 및 악성 파일이나 접근 및 수정한 파일에 대한 시간정보는 상당히 중요하다. 이 외에도 시스템에 일어난 행위를 파악할때 존재하는 파일은 간단하게 MFT의 타임스탬프를 이용하면 되나 삭제된 파일은 남아있지 않을 수 도 있다는 생각이들어서 조사해보았다.

 

 

 

• 파일이 삭제되는 원인 및 추적방법

I. 공격자가 악성코드(혹은 스크립트)를 이용하여 자동적으로 파일을 삭제하는 경우(혹은 악성코드에 내재된 기능인 경우)

II. 공격자(혹은 사용자)가 악성 파일을 사용 후(혹은 발견후) 윈도우 Delete키를 이용하거나 휴지통을 이용하여 삭제하는 경우

 

III. 백신에 의하여 탐지되어 삭제되는 경우

 

위와 같이 삭제된 경우에서 대게 파일을 복구하면 복구된 파일의 메타데이터를 이용하여 타임라인을 완성할 수 있으나 모든 파일이 복구되지 않거나, 삭제된 파일의 존재를 알아채지 못하는 경우가 있다. 이러한 경우 삭제된 파일의 정보를 알기 위해서는 공격자가 침입한 이후 생성된 파일의 정보를 확인해 보는 방법도 있다.

 

이번 문서에서는 윈도우 시스템에서 주로 사용되는 파일 시스템인 NTFS (New Technology File System)의 특징을 이용하여 삭제된 파일을 추적하는 방법을 조사해보고자 한다. NTFS의 몇몇 파일은 메타데이터 정보를 담고 있는데, $MFT, $LogFile, $UsnJrnl, INDX파일이 이에 대한 정보를 가진다.

 

• 관련 아티팩트

 

1. MFT

기본적으로 $MFT는 타임라인 분석에서 많이 사용되고 있다. 기본적으로 $MFT를 수집하고 내부의 데이터를 파싱하게되면 다양한 정보를 확인할 수 있는데 여기서, 삭제와 관련된 정보는 확인이 가능하다.

 

현재 MFT 분석에 가장 많이 사용되는 AnalyzeMFT를 이용하여 MFT를 파싱하면 다음과 같이 Acive/Inactive를 나누어 표기해준다. 

 

AnalyzeMFT – Inactive

Acive는 실제로 사용 중인 MFT이고 Inactive 상태의 MFT는 실제로 사용을 하지 않는 것으로 알려져있다. 즉, Inactive 상태의 MFT는 비할당 상태이며 이는 삭제 명령이 내려져 있으나 다른 데이터로부터 덮여 쓰여지기 전 상태로 생각해도 될 것이다.

AnalyzeMFT는 각각의 MFT 칼럼 중에 offset : 0x16- Flags 값에서 가져온다.

$MFT 파일 포멧 – MFT Entry Header

Analyze MFT 코드 중 일부

하지만 inactive된 비할당 데이터 영역이 다른 데이터 영역으로 덮여 쓰인다면 이후에는 해당 파일의 삭제 기록을 $MFT에서 확인 할 수가 없다. OS가 설치된 드라이브나 자주 사용되는 디스크라면 시간이 지난 파일의 삭제 정보를 해당 아티팩트로 찾기가 어렵다.

 

2. INDX파일 ($I30)

FTK Imager를 통해 $I30으로 표기되는 이 파일은 INDX파일로 각 파일에 대한 레코드를 포함한 파일로 각각의 디렉터리에 위치하고 있다. 해당 파일이 지니고 있는 데이터 값은 MFT의 File_Name에서 참조하여 생성되는 값이다.

 

FTK Imager를 통해 확인되는 INDX파일 ($I30)

 

INDX파일은 현재 디렉터리에 존재하는 파일 뿐만 아니라 삭제된 파일의 정보까지 저장하며 저장 용량에 제한이 없기 때문에 용량 부족으로 이전 데이터가 덮여 쓰여지지 않는다. 분석가는 INDX파일을 분석함으로 해당 디렉터리에 존재하는 그리고 존재하였던 파일의 정보를 확인할 수 있다.

 

이러한 파일을 파싱해주는 도구를 William Ballenthin이 만들었는데 해당 도구를 이용하면  INDX 파일에서 “파일 이름”, “물리적 크기”, “논리적 크기”, “수정 시간”, “접근 시간”, “변경 시간”, “생성 시간”을 파싱해준다.

 

INDX파일 파싱

해당 아티팩트를 이용하면 과거에 생성된 파일 및 디렉터리에 대한 존재여부를 확인할 수 있다. 현재 존재하는 파일과 디렉터리와 비교해 보면 파일의 삭제 여부에 대하여 확인이 가능하다. 하지만 다른 아티팩트와 달리 전체 디렉터리에 퍼져있기 때문에 수집 및 분석이 번거롭다는 단점이 있다.

 

3. $UsnJrnl

$UsnJrnl은 NTFS 파일 시스템에 쓰여지는 모든 파일 및 디렉터리의 변경사항을 기록하는 로그이다. $UsnJrnl은 다음과 같은 위치에 저장되며 $J는 데이터를 담고 있으며 $Max는 Usnjrnl의 기본 메타데이터를 가지고 있다.

$UsnJrnl 위치

$UsnJrnl은 파일의 변경 여부를 파악하기 위해 사용 되기 때문에 삭제된 파일에 대하여 확인이 가능하다.

$UsnJrnl – NTFS LogTracker

해당 아티팩트의 저장 기간이 자주 사용하는 디스크라면 평균 2일 정도로 짧은 기간의 로그 기록만 저장을 하고 있다. 하지만 그에 비하여 저장되는 용량이 큰데 그 이유는 $J 속성의 레코드 할당 정책 때문이다.

$J에 데이터는 레코드 형태로 연속적으로 저장되는데 할당된 크기를 넘으면 추가적으로 저장되는 레코드 값을 그 공간 만큼 0으로 채우고 밀어내고 새로운 값을 저장한다. 이렇게 때문에 UsnJrnl 데이터는 크기에 비해 실제 사용할 수 있는 데이터는 작다.

 

하지만 공간에서 밀려난 저널 데이터가 위치한 주소 값은 비할당이 상태가 된다. 즉, 재할당되기 전까지는 데이터를 읽을 수 있는 것이다. NTFS LogTracker 1.4버전 이상에서는 이와 관련하여 비할당영역에 존재하는 저널 데이터 파싱을 지원한다. 비할당 영역의 저널 데이터를 이용하면 수개월 전의 파일 삭제 정보 또한 확인이 가능하다. 

$UsnJrnl – 비할당영역 레코드 파싱

4. $LogFile

$UsnJrnl이 많은 양의 데이터를 제공하였다면 $LogFile은 적지만 자세한 데이터를 제공한다. 파일 삭제, 생성, 수정, 이름 변경 등 다양한 Event를 저장하고 $MFT와 $UsnJrnl 정보와 흔히 함께 쓰인다. $LogFile을 일반적으로 64byte의 크기를 가지지만 더 크게 할당하여 보다 많은 데이터를 로깅할 수 있도록 설정할 수 있다. $LogFile도 동일하게 NTFS Log Tracker를 이용하여 쉽게 분석이 가능하다.

$LogFile – NTFS Log Tracker

 

 

끝으로 분석에 사용한 많은 툴과 아티팩트 분석 노하우를 공유해주시는 분들께 무한한 감사를 드립니다.

Finally, I would like to express my gratitude and respect to those who share the wonderful tools and artifact analysis know-how used in the analysis.

 

 

 

• 참고 

 

[1] https://www.sans.org/summit-archives/file/summit-archive-1492113892.pdf

이 글의 기본 토대가 되었음.

 

[2] https://www.writeblocked.org/resources/ntfs_cheat_sheets.pdf

MFT 분석 부분을 참고하였음.

 

[3] http://forensic-proof.com/wp-content/uploads/2010/10/FP_NTFS_Forensic_Analysis.pdf

나열한 모든 아티팩트에 대한 설명이 포함되어 있음.

 

 

[4] https://github.com/dkovar/analyzeMFT/tree/master

AnalyzeMFT

 

[5] http://forensicinsight.org/wp-content/uploads/2013/07/F-INSIGHT-Advanced-UsnJrnl-Forensics-Korean.pdf

NTFS-Logtracker 및 Usnjrnl분석을 참고하였음.

 

출처 :  파일 삭제 흔적 찾기 (NTFS) #nagoona (tistory.com)

파일 삭제 흔적 찾기 (NTFS) #nagoona