Notice
Recent Posts
Recent Comments
Link
«   2024/05   »
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31
Tags more
Archives
Today
Total
관리 메뉴

Piki's Play

NTFS 분석 - 응용프로그램 범주, 큰 그림, 다른 주제 본문

포렌식/파일시스템 (파일시스템 포렌식분석)

NTFS 분석 - 응용프로그램 범주, 큰 그림, 다른 주제

Pikigod 2020. 3. 10. 14:55

12.5 응용프로그램 범주

- NTFS는 많은 응용프로그램 수준의 기능을 지원하는 유일한 파일시스템이다. 이 기능들은 파일시스템에서 꼭 필요하지는 않지만 응용프로그램이나 운영체제들이 효율적으로 운영되기 위해서 필요하다. 이 절에서는 디스크 할당, 로깅, 변경 저널링에 대해 기술하겠다. 그 데이터 구조체들은 13장에서 설명한다. 이 절에서는 기능의 응용프로그램 수준의 필수 데이터만을 언급하도록 하겠다.

 

 

▶ 디스크 할당

- NTFS는 디스크 공간 할당을 지원한다. 관리자는 각 사용자별로 사용할 수 있는 공간을 제한하는 할당을 설정할 수 있다. 할당 정보 일부는 파일시스템 데이터로 저장되고 다른 데이터는 레지스트리 같은 응용프로그램 수준의 파일들에 저장된다. NTFS 3.0 이전 버전에서는 MFT엔트리 9에 \$Quota 라는 파일 시스템 메타데이터 파일이 있었지만 NTFS 3.0+ 버전에서는 이 파일이 \$Extend 디렉토리에 존재하고 그것은 어떠한 MFT 엔트리에도 있을 수 있다. \$Quota 파일은 할당정보를 관리하기 위해 2개의 인덱스를 사용한다. 한 인덱스는 $O라는 이름을 가지고, SID와 소유자 ID를 연관시킨다. 다음 인덱스는 $Q라는 이름을 가지고 소유자ID와 얼마나 많은 바이트들이 사용자에게 할당 되었는지를 또 얼마나 많은 용량들을 허용하는지의 세부내용을 연관시킨다. 

 

분석 고려사항

- 운영체제가 파일시스템을 사용할 때 할당상태를 반드시 이용하는 것은 아니다. 그래서 할당상태는 부가적인 사항으로 봐야한다. 예를들어 다른 운영체제에서 NTFS 파일시스템을 마운트하면, 사용자가 파일을 생성할 때 할당상태를 업데이트 하지 못한다. 할당은 포렌식 조사동안 어떤 사용자들이 큰 데이터를 가지고 있었는지 판단할때도 유용하다. 모든 시스템에서 할당 시스템이 활성되어 있는 것은 아니기 때문에 이러한 데이터가 없을수도 있다. 

 

 

로깅 - 파일시스템 저널링

- 파일시스템의 신뢰성을 높이기 위해 마이크로소프트는 NTFS에 저널링을 추가하였다. 마이크로소프트는 '로깅'이라 부르지만, 다른 파일시스템에서는 '저널링'으로 부른다. 운영체제는 파일시스템 저널을 이용해서 파일시스템을 더욱 빠르게 원래상태로 되돌린다. 데이터를 파일시스템에 쓰는 동안 시스템에서 충돌이 나면 파일시스템은 대부분 손상된다. 저널은 충동이 일어나기 전에 메타데이터 업데이트에 대한 정보를 기록하고, 언제 업데이트들이 일어났는지도 기록한다. 이러한 업데이트에 대해 기록하기 전에 충돌이 일어나면 운영체제는 빠르게 이전 상태로 시스템을 되돌린다. 

- NTFS 로그 저널 파일은 MFT엔트리 2에 $LogFile이라는 이름으로 저장이된다. 로그데이터는 $DATA에 저장된다. 로그파일은 파일시스템 전체 크기에서 1~2%를 차지한다. 

 

NTFS 저널을 포함하는 $LogFile $DATA 속성의 레이아웃

- 로그파일에는 2개의 주요구역, 재시작영역 로깅영역이 있다. 그림에서 보면 알 수 있듯이 재시작 영역에는 데이터 구조체의 두 복사본이 있다. 재시작 영역은 운영체제가 정리가 필요할 때 어떤 트랜잭션을 조사해야 하는 지 판단하는데 도움을 준다. 또 성공적인 마지막 트랜잭션을 위해 로깅 영역이 가리키는 포인터를 포함한다. 

- 로깅 영역은 연속적인 레코드들이다. 각 레코드는 64비트 값인 LSN(Logical Sequence Number)를 갖고, 오름차순으로 할당된다. 로깅영역은 크기가 한정되어 있고, 레코드를 위해 더이상 공간이 없을 때 파일 시작에서 다시 시작한다. 더 이상 필요하지 않은 레코드들은 로그가 순환했을 때 덮어써진다. 

- 여러가지 레코드 유형이 있지만 마이크로소프트에서는 두 가지 유형을 설명한다. 가장 많이 볼 수 있는 유형은 업데이트 유형이고, 이것은 발생하기 전에 파일시스템 트랜잭션을 설명하기 위해 사용된다. 또한 파일시스템 트랜잭션이 수행될 때 사용된다. 많은 트랜잭션들이 좀 더 작은 연산들로 이루어지기 대문에 한 개 이상의 레코드가 필요하고 각 연산은 업데이트 레코드를 갖는다. 

예제 파일시스템 트랜잭션은 아래의 내용을 포함한다. 

 

º 새로운 파일이나 디렉토리 생성

º 파일이나 디렉토리의 내용변경

º 파일이나 디렉토리의 이름변경

º 파일이나 디렉토리의 MFT엔트리에 저장된 데이터의 변경(ID, 보안설정 등)

 

- 각 업데이트 레코드는 LSN 값 외에 두 개의 주요 필드를 갖는다. 하나는 어떤 동작이었는지에 대한 정보를 포함하고 "redo"필드라 한다. 다른 필드는 정 반대의 정보를 포함하고 이 동작을 어떻게 원래대로 되돌리는지 설명한다.(Undo 필드) 이 레코드들은 파일시스템 트랜잭션이 수행되기 전에 생성된다. 그 파일시스템 트랜잭션이 수행된 후 다른 업데이트 레코드를 생성하고, 그 트랜잭션이 생성되었다는 것을 보여준다. 이것을 '적용'레코드라고 한다.

- 레코드의 두 번째 유형은 검사지점 레코드이다. 이 검사지점레코드는 운영체제가 파일시스템을 검증할 때 운영체제가 로그파일 어디서부터 시작해야 하는 지 구별할 수 있도록 도와준다. 윈도우는 이러한 레코드들 중 한개를 5초마다 생성하고, LSN 값은 로그파일의 재시작 영역에 저장된다. 

- 파일시스템 검증을 위해 운영체제는 마지막 검사지점 레코드 위치를 확인하고 시작되는 트랜잭션을 확인한다. 만약 트랜잭션이 완료되었고 적용레코드가 존재한다면 운영체제는 그 데이터가 디스크에서 업데이트 되었는지, 캐시에서 손상되지 않았는지 redo필드 내용을 확인한다. 트랜잭션이 완료되지 않고 적용레코드를 찾지 못했다면 운영체제는 트랜잭션 시작전 상태로 데이터가 되돌려졌는지 보증하기 위해 Undo필드를 사용한다.

 

마지막 검사지점 레코드 다음 두 트랜잭션을 갖는 예제 $LogFile

- 위 그림을 보자. 재시작 영역에서 마지막 검사지점 레코드를 포인터를 이용해 가리킨다. 그 범위에는 두개의 트랜잭션이 있다. 트랜잭션 1은 적용레코드가 있기 때문에 디스크가 정확하다는 것을 보장하는 'redo'를 사용한다. 트랜잭션2는 적용레코드가 없기 때문에 요청된 변경들이 없다는 것을 보장하기 위해 'Undo'를 사용한다.

- 로그는 비거주로 클러스터에 저장되는 사용자 데이터는 포함하지 않기 때문에 파일 복구에 사용될 수 없다. 로그는 거주속성들의 내용을 저장할 수 있고 최근 변경에 대한 복구를 하는데 사용할 수 있다. 파일에서 ASCII나 파일에 유니코드 스트링을 보는 것으로 일부 데이터를 확인할 수 있고 이는 13장에서 다루자. 

- 각 MFT엔트리 헤더에는 마지막 LSN이 있다. 이것은 두 파일의 변경순서를 결정하는 데 사용될 수 있다.

 

분석 고려사항

- 저넉은 파일시스템에서 최근에 변경된 정보를 제공하지만 그것들이 덮어써지기 전에 어떤 엔트리들이 있었는지 확인할 수 없고, 그 저널 파일이 어떤 식으로 구성되있는지 알 수 없다는 특징이 있다. 그래서 증거를 찾더라도 설명하기 어려울 수 있다. 파일 MFT엔트리 헤더에서 주어주는 LSN값은 어떤 파일들이 수정되었는지를 순차적으로 재구성하는데 사용된다. 큰 숫자일수록 더 최근에 수정된 것이다. 

 

 

변경 저널

- 변경 저널은 파일과 디렉토리들이 변경될 때 기록하는 파일이다. NTFS 3.0 이상부터 사용하고 응용프로그램들은 파일들이 어떤 시간 범위에서 변경되었는지 판단하기 위해 이 저널을 이용한다. 변경로그 저널은 변경되었던 파일들을 목록화하기 때문에 어떤 파일들이 변경되었는지 판단과정을 더욱 쉽게 만든다.

- 윈도우에서 변경저널 기능은 기본적으로 비활성화되어 있지만, 활성화 시킬 수 있다. 저널에는 64비트 숫자가 있고 저널이 활성화되거나 비활성화 되었던 시간을 기록한다. 응용프로그램들은 저널이 비활성화 될 수 있으므로 이 숫자를 일부 변경들이 손실되지 않았는지를 결정하는데 사용할 수 있다. 해당 저널이 비활성화 되었을 때 윈도우는 그 파일을 정리하고 지운다.

- 변경저널은 \$Extend\$UsrJrnl 파일에 저장되어있다. 이 파일은 대체로 예약된 MFT엔트리들 중 한개에 할당되고 2개의 $DATA속성을 갖는다. 하나는 $Max이고 저널에 대한 기본 정보를 포함한다. 다른 하나는 $J이고, 다양한 크기 레코드 목록으로 실제 저널을 포함한다. 각 레코드는 파일이름 변경시간, 변경타입을 포함한다. 레코드 길이는 파일이름의 길이에 기반을 둔다. 각 레코드는 64비트 크기인 USN(Update Sequence Number)를 갖는다. USN은 저널에 레코드를 나타내기 위해 사용되고, 수정된 파일의 $STANDARD_INFORMATION 속성에 저장된다. USN은 저널 내 바이트 오프셋에 해당하며 그것의 USN에 해당하는 레코드를 찾는 것은 쉽다. (각 레코드는 다른 크기를 갖기 때문) 그 레코드는 변경된 데이터는 포함하지 않고 단지 발생한 변경의 타입만을 포함한다.

- 윈도우에는 저널에 할당할 수 있는 최대 크기가 있다. 만약 저널이 그 크기를 모두 사용하면 윈도우는 그 파일을 Sparse파일로 변경하고 계속해서 파일의 마지막에 데이터를 추가한다. -> 이때 첫 클러스터는 제거한다.

그래서 항상 같은 할당된 클러스터 개수를 갖는다. USN은 계속 증가하는데 파일의 시작에서의 오프셋이기 때문이다.

 

▷ 분석 고려사항

- 이 저널기능이 활성화 되었다고 보장할 수 없기 때문에 그 파일로부터 얼마나 많은 정보를 모을 수 있는지 정확하지 않다. 비활성화되면 위도우는 내용을 모두 지워버린다.(응용프로그램이 저널을 비활성화 시킬 수 있다.)

만약 내용들을 신뢰할 수 있다면, 최근에 발생된 사건들을 재구성 하는데 유용할 수 있다.

 

 


12.6 큰 그림

-> 다른 데이터 구조체들과 복잡한 상호관계들을 가지고 있는 이번 장을 이해하기 위해서 파일이 할당되고 지워졌을 때의 단계를 순서대로 확인해보자.

 

파일 할당 예제 

- 파일 \dir1\file1.dat을 생성하고, dir1 디렉토리는 루트 디렉토리에 이미 존재한다고 가정하자. 파일의 크기는 4000바이트이고, 각 클러스터는 2048 바이트이다.

 

1. 파일시스템의 첫 번째 섹터를 읽고, 부트섹터는 클러스터 크기, MFT시작 주소, 각 MFT 엔트리 크기를 결정한다.

 

2. $MFT 파일인 MFT의 첫 번재 엔트리를 읽어 $DATA 속성에 있는 MFT 나머지 레이아웃을 결정한다. 

 

3. 먼저 새로운 파일을 위해 한 개의 MFT엔트리를 할당해야 한다. 비할당 엔트리를 찾기 위해 $MFT파일의 $BITMAP 속성을 해석한다. 첫 번째 free 엔트리, 엔트리 304는 새로운 파일에 할당되고, 비트맵 해당 비트는 1로 설정된다. 

 

4. MFT내의 위치를 구하고, 내용을 지워 MFT엔트리 304를 초기화한다. $STANDARD_INFORMATION과 $FILE_NAME 속성이 생성되고, 시간 값들은 현재 시간으로 설정된다. '사용 중' 플래그가 MFT 엔트리 헤더에서 설정된다.

 

5. 다음은 MFT 엔트리 6인 $BITMAP 파일의 $DATA 속성을 이용해서 파일의 두 클러스터를 할당하는 것이다. 이 파일에는 2개의 클러스터가 필요하며, 두 개의 연속적인 클러스터 692, 693을 '자동 맞춤' 알고리즘을 이용해 찾는다. $BITMAP의 그 클러스터들에 해당 비트들은 1로 설정된다. 파일 내용은 클러스터에 써지며, 해당 $DATA속성은 그 클러스터 주소들로 업데이트된다. 그 MFT엔트리는 수정되고 파일 수정 시간들은 업데이트된다. 

 

6. 다음 단계는 추가할 파일을 위해 파일 이름 엔트리를 더하는 것이다. MFT엔트리 5에 있는 루트 디렉토리는 dir1에 위치한다. $INDEX_ROOT와 $INDEX_ALLOCATION 속성들을 읽고, 정렬된 트리를 탐색한다. 그 dir1 인덱스 엔트리를 찾고, 그것의 MFT엔트리 주소는 200이다. 디렉토리의 마지막 접근 시간은 업데이트된다. 

 

7. MFT엔트리 200을 구하고, file1.dat가 어디에 위치하는지 찾기 위해 $INDEX_ROOT 속성을 처리한다. 새로운 인덱스 엔트리가 그것을 위해 생성되고, 그 트리는 재정렬 된다. 이것은 그 노드 주위 인덱스 엔트리들에 결과이다. 새오룬 인덱스 엔트리는 파일 참조 주소에 MFT엔트리 304를 갖고, 시간들과 플래그들은 적절하게 설정된다. 그 디렉토리의 마지막 생성, 수정, 접근 시간들은 업데이트 된다.

 

8. 이전 각 단계들에서 $LogFile 파일시스템 저널, 그리고 \$Extend\$UsrJrnl 변경 저널에 엔트리들을 만들어 왔다. 할당이 활성화되어 있었다면 새로운 파일의 크기가 \$Extend\$Quota 사용자 할당에 더해졌을 것이다.

 

아래그림에서 각 요소들 관계와 마지막 상태를 확인할 수 있다.

 

파일 추가 후 마지막 상태

 

 

▶ 파일 삭제 예제

지금부터는 \dir1\file1.dat 파일이 지워질 때 어떤 과정이 발생하는지 보여주도록 한다.

 

1. 파일시스템의 첫 번째 섹터를 읽고, 부트섹터는 클러스터 크기, MFT시작 주소, 각 MFT 엔트리 크기를 결정한다.

 

2. $MFT 파일인 MFT의 첫 번재 엔트리를 읽어 $DATA 속성에 있는 MFT 나머지 레이아웃을 결정한다. 

 

3. dir1 디렉토리를 찾기 위해 루트 디렉토리, MFT 엔트리 5를 해석하고, $INDEX_ROOT와 $INDEX_ALLOCATION속성들에 인덱스를 탐색한다. dir1 엔트리를 찾고, MFT 엔트리 주소는 200이다. 디렉토리의 마지막 접근 시간은 업데이트된다.

 

4. MFT엔트리 200의 $INDEX_ROOT 속성을 처리하고, file1.dat 엔트리를 검색한다. 그 파일에 MFT 엔트리 주소가 엔트리 304라는 것을 확인할 수 있다.

 

5. 인덱스에서 그 엔트리를 제거하고, 그 노드에 엔트리들은 이동되고, 원래 엔트리로 덮어 써진다. 디렉토리에 마지막 생성, 수정, 접근 시간들이 업데이트 된다. 

 

6. 사용중 플래그를 정리하는 것으로 MFT엔트리 304를 비할당한다. 또한 $BITMAP 파일의 $DATA속성을 처리하고, 이 엔트리에 해당하는 비트를 0으로 설정한다. 

 

7. MFT 엔트리 304의 비거주 속성을 처리하고 \$BITMAP 파일에서 그 해당 클러스터들에 해당하는 비트를 비할당 상태로 설정한다. 클러스터 692, 693의 비트가 비할당된다.

 

8. 이전 각 단계들에서 $LogFile 파일시스템 저널, 그리고 \$Extend\$UsrJrnl 변경 저널에 엔트리들을 만들어 왔다. 할당이 활성화 되어 있었다면 \$Extend\$Quota 사용자 할당에서 파일 크기를 뺀다.

 

파일이 삭제된 마지막 상태를 아래 그림에서 볼 수 있다.

파일을 삭제한 후 마지막 상태

 

- 파일이 NTFS에서 지워질 때 윈도우는 어떠한 포인터들도 삭제하지 않는다. 그래서 파일이름과 MFT엔트리 사이 연결은 인덱스 엔트리가 재정렬 때문에 손실되지만 않는다면 여전히 존재할 것이다.

 


12.7 다른 주제

- 이 절은 특정 데이터 점주에 적용할 수 없는 지워진 파일 복구와 파일시스템 일관성 검사에 대해 언급한다.

 

▶ 파일 복구

- NTFS는 지워진 파일을 복구하는 것이 다른 파일시스템들보다 쉽다. 파일이 지워지면 그 이름은 부모 디렉토리 인덱스에서 제거되고, 그 클러스터들은 비할당된다. 마이크로소프트는 어떠한 포인터들도 삭제하지 않지만 향후에는 삭제할 수도 있다.

- NTFS의 단점은 파일 이름을 부모 인덱스에서 제거할 때 그 인덱스가 재정렬되고 이름정보를 잃어버릴 수 있다는 것이다. 즉, 지워진 파일의 이름을 확인하지 못할 수도 있다. 하지만 MFT 엔트리들은 한 테이블에서 찾을 수 있고, 비할당 엔트리를 찾을 수 있다. 각 엔트리는 부모 디렉토리의 파일 참조 주소를 갖는 $FILE_NAME 속성을 갖는다. 그래서 부모 디렉토리들이 새로운 파일이나 디렉토리에 재할당되지 않았다면 전체 경로를 결정할 수 있다.

- 파일 속성이 거주라면 그 데이터는 MFT엔트리가 재할당 될 때까지는 덮어써지지 않는다. 만약 파일을 위해 MFT엔트리가 1개이상 존재하면 다른 MFT엔트리도 복구해야 한다. 윈도우는 MFT엔트리를 '첫번째 적용'으로 할당한다. MFT엔트리 중 낮은 번호들은 높은 번호 엔트리들보다 더 빈번하게 할당된다.

 

 

▶ 일관성 검사

- 일관성 검사는 이미지가 손상되었거나, 변경여부를 탐지하는데 사용할 수 있다. 이 절은 NTFS 파일시스템 이미지에서 수행할 수 잇는 몇가지 검사를 다룬다. NTFS 부트섹터에 적은 양의 데이터가 있지만 마이크로소프트는 사용하지 않는 일부 값들을 0으로 만든다. $Boot 파일 내 부트코드 다음에 사용하지 않는 클러스터들이 많다는 것을 확인했다. 또한 다른 파일시스템처럼 $BadClus 파일에서 불량으로 표시한 클러스터들을 조사해야 한다. 그 이유는 파일시스템이 그것들을 재구성하기 전에 하드디스크에서 불량클러스터들을 수정하기 때문이다. 

- 16개의 MFT엔트리들은 예약되어 있고, 도 몇개는 사용하지 않고 있다. 예약되어 있고 사용하지 않는 메타데이터 구조체들은 다른 파일 시스템들처럼 데이터를 숨기기 위해 사용될 수 있다. 

- 할당된 각 클러스터들은 파일에서 반드시 클러스터 run의 일부분이어야 한다. 할당된 모든 클러스터들은 파일이나 디렉토리의 일부분이고, 일관성 검사는 그것을 검증해야한다. 할당된 각 MFT엔트리는 '사용 중' 플래그를 가져야하고, $BITMAP 속성에 해당 비트가 설정되어 있어야 한다. 할당된 MFT 엔트리는 또한 각 파일 이름들을 위해 디렉토리 인덱스 엔트리를 가져야만 한다. 모든 파일시스템의 메타데이터 파일들에는 루트디렉트리에 이름이 있다. 

- NTFS 파일시스템은 너무 유연하고, 많은 옵션들을 지원한다. 그래서 분석이 더 어렵다.

 

 

▶ 요약 

- NTFS는 현재 많은 요구사항을 충족시키기 위해 설계되어서 복잡하다. 또한 가체적으로 응용프로그램 수준의 기능을 혼합해서 복잡성이 더해졌다.

- 이 파일시스템은 지워진 파일들을 복구하기 더 쉽고, 만약 저널들이 활성화 되어있으면 이벤트 이력이 존재하기 때문에 수사관들이 분석하기가 더 쉽다.

반면에 시스템이 복자해서 확인된 증거를 설명하고 이해하는 것은 어려움을 겪을 수 있다.

 

 

 


p.s 많....아