4. MFT

NTFS File System (1) ~ (3)을 통해 MBR(혹은 EBR)을 지나 해당 파티션의 VBR을 찾을 수가 있었다. 이러한 VBR에서 BPB를 참고하여 $MFT의 위치까지 찾아보았다. 이제 이러한 MFT에 대하여 설명을 하고자 한다.

 MFT는 Mater File Table의 약자로 NTFS에선 파일이나 디렉터리, 메타 정보를 모두 파일의 형태로 관리하고 있다. 이러한 각 파일의 위치나 속성, 이름, 크기 등의 메타정보는 MFT Entry라는 특별한 구조로 저장된다. MFT는 NTFS 상에 존재하는 모든 파일의 MFT Entry의 모음으로 아래의 그림과 같이 나타낼 수 있다.

 위의 표와 같이 각 엔트리의 번호와 기능에 대하여 설명할 수가 있다. 이러한 각 각의 엔트리는 MFT Entry Header, Fixup Array, Attributes, End Marker, Unused Space로 구분되는 구조를 갖는다. End Marker 이후의 값은 MFT Entry에서 사용되지 않는다. 이를 그림으로 나타내며 아래와 같다.

MFT Entry Header

이러한 각 항목 중 먼저 MFT Entry Header에 대하여 설명해보자. MFT Entry Header는 모든 MFT Entry의 앞 부분에 위치하는 48Byte의 정보로 그림과 표를 통해 좀 더 자세히 설명하겠다. 아래의 그림과 같이 첫 부분에 MFT 시그니처인 'FILE'로 시작하여 Fixup Array 전 까지의 구조를 갖는다.

이를 토대로 현재 PC의 $MFT의 MFT Entry Header를 확인해보자.

Fixup

출처 및 참고

(FP) NTFS.pdf

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

3 .NTFS - VBR

 이전 포스팅에선 MBR의 파티션 테이블(혹은 EBR)을 참고하여 해당 파티션의 위치를 찾을 수가 있었다. 여기서 필자는 NTFS를 학습하기 위함으로 FAT16, FAT32 외 다른 것들은 일단 제외하겠다. 우선 NTFS의 구조는 아래의 그림과 같다.

VBR(Volume Boot Record)와 MFT가 있으며 그리고 Data 영역이 존재하고 있는 것을 확인할 수가 있다. 우선 VBR에 대하여 먼저 이야기를 해보자. VBR은 그 크기가 고정된 것이 아니라 클러스터의 크기에 의존한다. 아래의 표와 같다.

 하지만 이전에 말했듯이 대부분의 NTFS는 클러스터의 크기가 4KB이므로 VBR의 크기는 8 Secotr(== 1cluset)가 된다.

 VBR의 구조에 대해선 아래의 그림과 같다. 

- Jump instruction : EB 52 는 어셈블리어로 JMP 0x52이며 두의 90은 NOP로 52+2 바이트 뒤인 0x54에서 Boot Code가 시작됨을 알려준다.

- OEM ID : NTFS를 나타내고 있다.

- BIOS Parameter Block (BPB) : 클러스터의 크기, 루트 디렉터리 위치, 총 섹터 등 파일 시스템 정보가 기록되어 있다.

- Boot Code : 해당 볼륨의 운영체제를 로드하기 위한 명령어가 있다.

- Signature : 0xAA55가 위치해 있다.

파일 시스템의 정보를 나타내는 BPB에 대하여 좀 더 자세히 보면 아래의 그림과 같다.

위와 같이 정리할 수가 있으며 $MFT에 접근하기 위해선 0x30의 Start Cluster for $MFT의 값을 참고한다. 한번 직접 해보자. 아래의 그림은 이전에 MBR을 통해 찾은 VBR을 나타내고 있다. 0x30의 부분은 $MFT가 있는 클러스터의 위치를 나타내는 것으로 C0000의 클러스터(현재 VBR을 기준으로) 가 있는 곳에 위치해있다고 해석할 수가 있다.

C0000은 클러스터의 값이므로 이를 이동하기 편하게 Offset으로 나타내기 위해선 [해당 클러스터값 * 클러스터당 섹터 수* 섹터크기]와 같이 계산을 하면 된다. 이를 직접 해보면 C0000 * 8 * 0x200 = C0000000 이다. 이제 이를 현재 VBR이 있는 오프셋 F38200000에 더하면 FF8200000이다. 해당 위치는 아래의 그림과 같이 나오며 MFT 파일의 시그니처인 'FILE'가 있는 것을 확인할 수가 있다.

출처 및 참고

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

http://home.sogang.ac.kr/sites/gsinfotech/study/study1702/Lists/b10/Attachments/17/20131212_%EC%B9%A8%ED%95%B4%EC%8B%9C%EC%8A%A4%ED%85%9C%EB%B6%84%EC%84%9D.pdf

http://ntfs.com/ntfs-partition-boot-sector.htm

(FP) NTFS.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과 같은 방식으로 진행하다가 중요한 파일의 생성 여부를 놓칠 수가 있기에 조심하여야 한다. 아무래도 가장 좋은 방법은 파일의 생성과 삭제에 있어서 리버싱과 포렌식 두 방식 모두 활용하는 것이 좋은 경우인 것 같다.

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

ADS

ADS란 Alternate Data Stream의 약자로 NTFS 구조에서는 다중의 데이터 스트림을 지원하는데, 이러한 데이터 스트림이 여러개라는 것은 파일이 하나 이상의 데이터를 담을수 있다는 것이다. 이를 이용하여 원하는 데이터를 다른 파일 안에 숨길 수가 있다.

아래의 그림을 보면 FAT 에서는 하나의 Data Stream만이 존재하지만 NTFS의 구조에는 Main Stream이 존재한다. 하지만 Main Stream 외에도 여러개의 Data Stream이 존재하는 것을 확인할 수가 있는데, 바로 이것이 Alternate Data Stream인 것이다.

이러한 ADS를 사용하여 데이터를 은닉할 수가 있으며 은닉된 데이터느 일반 사용자가 알아차리기가 힘들기 때문에 악성코드를 넣는 등 악의적인 용도로 사용이 가능하기에 Windows XP 이후에는 이러한 ADS에서 실행파일을 실행되지 않도록 했기에 더이상은 실행파일이 실행되지 않는다. 그렇다하여 ADS에 대해 모르는 것보다는 알고 있는 것이 좋다. 

Practice

이제 ADS를 직접 이용해보자. 가장 편하게 만들 수 있는 방법은 CMD와 echo 명령어를 이용하는 것이다. 아래에 그림과 같이 echo "This is ADS" > file.txt:ads.txt이라고 입력을 해준다. 여기서 중요한 것은 바로 " : " 표시이다. 저 기호를 통해 우리는 ADS로 접근을 할 수 있게 되는 것이다. 

파일이 생성된 이후 해당 파일의 내용을 확인해보면 아무것도 나타나지 않는다. 하지만 " : "을 이용해서 ADS에 접근하면 우리가 첫 줄에서 은닉하고자 했던 데이터 문자열이 출력되는 것을 확인할 수가 있다. 그리고 그 후에 디렉터리를 확인해보면 file.txt에는 아무 내용도 없는 것처럼 0바이트의 크기를 차지하고 있다는 것을 확인할 수가 있다. 즉, 우리는 ADS를 탐지하지 못하고 있다.

하지만 dir 명령어에 /r 이라는 옵션을 넣어주면 우리는 숨겨져있던 ADS의 목록을 볼 수가 있다. dir /r 을 입력해준 결과 아래와 같이 출력 되는 것을 확인할 수가 있다. file.txt 는 분명히 0 바이트를 차지하지만 그 바로 밑에 있는 file.txt:ads.txt는 16바이트의 크기를 차지하고 있다.

또한 아래와 같이 디렉터리 자체에도 ADS를 형성할 수가 있다.

Conclusion

이렇게 간략한 방법으로 ADS를 형성할 수 있다는 것을 확인하였다. 만약 아직도 ADS에 있는 실행파일을 실행할 수 있게 된다면 이는 악성코드로 부터 많이 사용될 확률이 높다. 현재는 이러한 기능이 차단되어 XP까지만 가능하지만, Power Shell을 이용하는 방법 등 아예 실행하지 못하는 것은 아닌 것 같다. 이에 대해서는 추후에 지식을 더 쌓게 되어 다루게 된다면 다시 포스팅 하겠다.

Reference

http://www.codeblack.net/2015/03/ntfs-file-system-adsalternate-data.html

http://blog.naver.com/PostView.nhn?blogId=ifkiller&logNo=70156536987&redirect=Dlog&widgetTypeCall=true

2018-06-19

ADS 또한 실행 할 수 있는 방법이 존재한다. 아래의 방법은 Windows 7 x64 에서 Test 했을 때 성공적으로 실행되었다. 다른 환경은 아직 테스트 해보지 않았다.

참조 링크 : http://asec.ahnlab.com/1090?category=342979