디지털포렌식 2급 실기 (2018 모의 문제 풀이 - 2번 문제) [FTK Imager]

다시 돌아와서 2번 문제를 풀어봐야한다.

2-1번 문제

2-1번의 문제는 SHA1 값이 98debd6a350baccb3e25fc7c2cd5de5ea09a7488 인 파일을 찾고 파일명, 크기, 시간 정보를 구해야한다.

비트낭님께서는 Encase의 파일 확장자와 시그니처의 분석 기능을 이용해서 풀으셔서 FTK Imager로 문제를 풀어보려는 나한테는 한계가 있는 문제였다. (정확하게는 너무 힘든 노가다성을 띄는 문제다.)

비트낭님께 이런 경우에는 어떻게 풀으냐고 물어봤는데
Autopsy를 추가적으로 사용하여 풀이한 pdf 파일을 참고하라고하셔서 한 번 보았다.

autopsy로 새로 case를 만들었다.
이름은 2018로 지었다.

디스크 이미지를 분석할 것이니
맨 위에꺼로 정해주고

파일시스템을 복구해놓고 저장한 2018_VHD.001을 골라준다.

분석 내용은 위와 같이 설정해줘야한다고 하심...
Claude.ai한테 물어보니까


1. Recent Activity: 최근에 수정된 파일 목록을 보여줍니다.

2. Hash Lookup: 알려진 해시 값과 파일을 비교하여 알려진 파일인지 확인합니다. 

3. File Type Identification: 파일 헤더를 분석하여 파일 유형을 식별합니다.

4. Extension Mismatch Detector: 파일 확장자와 실제 파일 유형이 다른 경우를 감지합니다.

5. Embedded File Extractor: 다른 파일 내에 포함된 파일을 추출합니다.

6. Picture Analyzer: 이미지 파일에서 메타데이터를 추출하고 분석합니다.

7. Keyword Search: 지정한 키워드가 포함된 파일을 검색합니다.

8. Email Parser: 이메일 파일을 분석하고 메타데이터를 추출합니다.

9. Encryption Detection: 암호화된 파일을 감지합니다.

10. Interesting Files Identifier: 중요한 파일 유형을 식별합니다.

11. Central Repository: 이전 케이스에서 수집한 정보를 저장하고 활용합니다.

12. PhotoRec Carver: 삭제된 파일을 복구하려 시도합니다.

13. Virtual Machine Extractor: 가상 머신 디스크 이미지를 분석합니다.

14. Data Source Integrity: 데이터 소스의 무결성을 검증합니다.

15. Android Analyzer: 안드로이드 장치 데이터를 분석합니다.

16. Cyber Triage Malware Scanner: 악성코드를 검사합니다. 

17. DJI Drone Analyzer: DJI 드론 데이터를 분석합니다.

18. Plaso: 로그 파일 타임라인을 생성합니다.

19. YARA Analyzer: YARA 규칙을 사용하여 파일을 분석합니다.  

20. iOS Analyzer: iOS 장치 데이터를 분석합니다.

21. GPX Parser: GPS 데이터 파일을 분석합니다.

라고한다.

여기서 비트낭님께서는 
1. Recent Activity: 최근에 수정된 파일 목록을 보여줍니다.
2. Hash Lookup: 알려진 해시 값과 파일을 비교하여 알려진 파일인지 확인합니다. 
4. Extension Mismatch Detector: 파일 확장자와 실제 파일 유형이 다른 경우를 감지합니다.
8. Email Parser: 이메일 파일을 분석하고 메타데이터를 추출합니다.

이 외에도 Exif Parser 라고 있었는데, 이건 Picture Analyzer로 이름이 바뀐듯하다.

6. Picture Analyzer: 이미지 파일에서 메타데이터를 추출하고 분석합니다.

Extension Mismatch Detector는 설정을 이렇게 해줘야한다.
모든 속성 파일을 대상으로 확장자가 없는 파일은 분석에서 제외한다는 뜻이다.

이제 다음으로 넘어가주면...

이렇게 파일 시스템 구조가 나온다.

볼륨을 나눠놓고 바이트의 크기를 보아하니 vol1은 MBR을 나타내고 vol2는 NTFS을 나타내는듯하다.

자 이제 SHA1 값이 98debd6a350baccb3e25fc7c2cd5de5ea09a7488 인 파일을 찾아보자.

Tools -> File Search by Attributes를 들어가보면

이렇게 MD5와 SHA-256 해시값을 넣어주면 해당 파일이 있는지 확인을 해준다고한다.
근데 SHA1은 없으므로 다른 방법을 생각해야한다.

Analysis Results -> Extension Mismatch Detected 목록을 봐보면 확장자와 시그니처가 일치하지 않는 파일들을 볼 수 있다.

Phantom.pdf 의 시그니처는 PK로 압축파일이다.

근데 명량.pdf도 마찬가지이다.

Extract File(s)를 이용하여 파일을 뽑아내보자.

이 2개의 파일을 이제 확장자를 .zip으로 바꾸고 풀어보자.

그리고 혹시 모르니까 2개의 파일을 sha1 해시값을 뽑아내보자

일치하지 않는다

 

Phantom.zip부터 풀어보자.

암호가 걸려있어서 확인할 수가 없다.
그럼 마지막으로 명량.zip을 압축해제해보자

해제가 된다.

이 사진들의 해시값들을 알아보면...

20190614_1.png의 해시값이 일치함을 알 수 있었다.

실제로 해당 파일의 내용을 보면 유령(Phantom)의 시나리오 내용임을 알 수 있다.

2-2번 문제

파일시스템이 생성된 날짜와 운영체제가 설치된 날짜를 구하라.

파일시스템을 공부한 사람들은 대강 알 것이다.
NTFS 파일시스템의 메타데이터를 담고 있는 파일은 $MFT이다.
$MFT의 값들을 통해서 수정 날짜, 생성 날짜, 접근 날짜를 모두 알아낼 수 있다.

NTFS에 해당하는 볼륨에 들어가서 $MFT 파일을 찾아서 해당 파일의 메타데이터를 찾아보면 나온다.

2019-06-15 11:03:16 KST 이다.
조금 추가적인 설명으로는 UTC 혹은 GMT 시간에 9시간을 더해준게 KST 시간이다.

이제 구해야할건 운영체제가 설치된 날짜이다.
이전 필기 시험에 나왔었던 내용일 것이다.
운영체제 설치 날짜는 SOFTWARE 파일에 있다.
SOFTWARE 파일의 경로는 /img_2018_VHD.001/vol_vol2/Windows/System32/config/SOFTWARE 이다.

해당 파일을 Extract File 해주어서 Rega라는 고려대학교에서 만든 도구를 이용해서 분석해보자
Rega는 레지스트리 파일을 분석해주는 도구이다. 디지털포렌식 2급에서 인정해주는 도구이므로 사용법을 익혀두는게 좋다.

https://dfrc.korea.ac.kr/infra_dfrc_tools/?q=YToxOntzOjEyOiJrZXl3b3JkX3R5cGUiO3M6MzoiYWxsIjt9&bmode=view&idx=14616120&t=board

REGA : DFRC - Digital Forensic Research Center

서울로 골라준다.

추출한 SOFTWARE 레지스트리 파일을 열어준다.

비할당영역 복구를 안하는게 더 빠르다.

윈도우 설치 정보를 눌러서 확인해주면 Install Date가 나온다.
2019-05-29 19:52:02 이다. 이는 KST 기준이다.(UTC +09:00 이니까)

2-3번 문제

USB Drive Name

Vender
Serial Number
를 구해야한다.

시나리오대로라면 해당 USB에 담긴 파일시스템에 연결된 다른 USB가 존재하는지,
더 나아가서 그 USB를 언제 연결하였는지에 대해서 알아내는 것 같다.

다시 autopsy로 돌아와서 USB Device Attached를 통해서 USB Device 중에 어느 것들이 기록되었는지 확인해보면
가장 눈에 먼저 띄는건 SanDisk 에서 만든 USB이다.
해당 SYSTEM 파일을 Extract File해주고 마찬가지로 Rega로 분석해보자.

저장 장치를 통해서 SanDisk 가 만든 USB가 접속되었음을 알 수 있다.
1. USB Drive Name은 SanDisk Ultra USB 3.0 USB Device
2. Vendor는 제조업체를 뜻하는데 SanDisk이다. Rega에는 표기하지 않는듯하다.
3. Serial Number는 4C530001020712119595&0 이다.

2-4번 문제

클러스터 번호가 125,791인 파일을 찾고, 해당 파일의 시그니처 정보를 확인하고 그 값을 구하라

 

정말 오래 고민하기도 했고, 현재 한국포렌식학회에서 인정해주는 도구 중에서는 클러스터 번호에 할당된 파일을 명시해주는 도구가 없었다.

그러므로 직접 MFT 엔트리를 분석하여 찾아내는 방법이 있는데, 이것 또한 쉽지 않다... 구조도 겹겹히 있고, 구분하고 계산하다보면 값이 제대로 안 나오기 때문이다...
그래서 비트낭님께 메일을 넣어봤다.

결론만 말하자면, 자격증 시험을 위해서라면 굳이 크게 신경쓰지 않아도 되는 문제라는 것이다.
시험에 나온 경우는 2번이고, 크게 비중이 높지 않을 것이라고 생각이 드며, 이 문제에 시간을 쏟는 것보다 다른 도구 사용을 통해 문제풀이하는 시간을 단축하는 것이 더 효율적이라고 보신 것이다.

그래서 약간의 야메 방식으로 풀어야할듯하다...
완전히 잘못 풀었다.
SFN과 LFN 구조와 유사하여서 SFN,LFN에 있는 클러스터 번호를 검색하여 파일명도 함께 찾아내는 것인 줄 알았는데, 그게 아니였다.

비트낭님께서 SFN과 LFN은 FAT32에서만 사용하는 구조라고 하심...
그러면 다시 예전처럼 클러스터 런 리스트에서 찾아봐야한다.
알려주신대로해보자.

1. $MFT 파일의 시작 섹터를 찾는다.

일단 지금은 파티션의 값을 통해서 들여다봤지만, 클러스터 단위로 이동하기 위해서는 전체 디스크에서 이동해야한다.

전체 디스크의 첫번째에는 MBR이 있고, 그와 동시에 파티션에 대한 구조 정보가 있다.
첫번째 파티션이므로 하이라이트된 부분이 될 것이다.
파티션은 1 3 1 3 4 4 으로
부트 플래그, CHS 시작주소, 파일시스템 종류, CHS 끝주소, LBA 시작주소, 파티션의 섹터 수 이다.
CHS 주소체계는 현재 거의 쓰이지 않는다고한다. 드라이브 제작시에 보통 사용을 안한다는 이야기.
그래도 일단 둘 다 계산해봐야겠다.

CHS 시작주소 = 02 03 00 -> 00 03 02 -> 3*2*512 = 3072 바이트 -> 0xc00 바이트
LBA 시작주소 = 0x80 00 00 00 -> 0x00 00 00 80 -> 0x80 = 128 이므로 128*512 = 65536 바이트 -> 0x10000 바이트

둘 다 가보면,

CHS 방식은 아니다.

LBA 방식이 맞다.

여기서부터가 VBR(BR)의 시작이면서 파티션 시작 위치이다.
주소값은 0x10000
그리고 BR에서 명시한 구조를 보면,

일단 VBR에서부터 명시된 $MFT의 LBA 주소를 통해 알아낸다.
클러스터 단위이므로 0xAA 09 01 00 00 00 00 00 -> 0x00 00 00 00 00 01 09 AA -> 68010
클러스터 당 섹터 수는 귀찮으니까 도구 기능을 이용해서

8이라는 것을 알아냈다.
$MFT 파일 시작 섹터 = 파티션 시작 위치 + (Start of MFT 번호 * 클러스터 당 바이트 수)
= 65536 + 68010 * 8 * 512 = 278634496

뭔가 의미가 있는듯한 곳으로 왔다.

MFT 엔트리는 2개의 섹터씩 공간을 할당받는 것으로 예전부터 알고 있었다.
그래서 0x109ba400 주소가 5번째 MFT 엔트리인 .(Root_Dir) MFT 엔트리이다.
이 엔트리에서 $INDEX_ALLOCATION 속성을 찾아야한다.
속성 식별값은 0xA0 이다. 검색해보면

2개가 나온다. 하지만 다행이게도 속성식별값은 4바이트를 사용하므로
아래의 0x109bb680 주소값의 0xA0 00 00 00 이 $INDEX_ALLOCATION 속성임을 알 수 있다.
더 확신을 주는 단서는 $INDEX_ALLOCATION 보다 앞서서 나오는 $INDEX_ROOT 속성의 식별값인 0x90 00 00 00이 근처 앞부분에서 나타났다는 것이다.

구글링을 해보았는데 $INDEX_ALLOCATION 속성의 구조와 크기를 모르겠어서 일단 하이라이트해놓은 부분으로 추측을 했다.
이유는 $INDEX_ALLOCATION 이후에 나타나야하는 속성인 $Bitmap 속성의 식별값인 0xB0 00 00 00 이 바로 나타났다는 것이다.
그리고 비트낭님께서 포스팅한 글에서 보면 $INDEX_ALLOCATION 속성은 항상 Non-Resident 속성이다.
그러므로
http://forensic-proof.com/archives/596

이러한 구조를 갖게 될 것이다.
이를 직접 손으로 구분지어서 분석해보았다.

마지막의 $I30과 남은 8바이트가 마음에 걸린다.
일단 $I30은 현재 보고 있는 $INDEX_ALLOCATION 속성에 정해진 이름이다.
확실하게 구분해야할 것은

· 속성의 종류에 따른 식별값
· 속성에게 주어진 이름값

이 둘은 다르다.
그리고 $DATA 속성에 대해 내가 정리해놓은 부분이 있다.
https://wintersnowaaa.tistory.com/15
이때도 런리스트 구조를 직접 계산하여 오프셋으로 이동해보았지만, 원하던 곳으로 이동하지 않아서
포기했었는데 다시 마주치게 되었다.
어쨋든 $DATA 속성에 대해서 정리해놓은 글을 보면
$DATA 는 Non-resident 속성이며, 
$INDEX_ALLOCATION 또한 Non-resident 속성이며,
내가 이전에 분석한 구조와 이번에 분석하는 2018년 모의문제의 디스크상에서의 속성 헤더 구조와 0x48의 크기가
거의 일치한다. 그러므로 내가 올린 포스팅과 비교하여서 속성 헤더를 분석하면 조금 더 편할 것이다.

이제 Attr Content인 런리스트 구조에 대해서 분석해보자.
https://blog.naver.com/sjhmc9695/221408336363

이러한 구조를 나타낸다.

첫 번째는 0x2C 값으로 이는 0x2C 번째 클러스터를 나타낸다.
문제는 이것이 파티션의 시작지점(BR) 부터 인지,
디스크의 시작지점부터 인지가 헷갈리긴한데
아마도 파티션의 시작지점(BR)이라고 예상된다.
왜냐하면 파일시스템을 처음 만들 때 클러스터의 크기를 결정하며, 클러스터는 운영체제와 파일시스템이 파일을 저장할 때 사용하는 단위이기 때문이다.

NTFS 파일시스템 부분을 들어가서
클러스터 검색을 통해 0x2c번째 클러스터로 이동해보았다.
INDX라는 인덱스 헤더 값이 보인다.
맞게 잘 온듯하다.
https://blog.naver.com/ginger2009/222039942046
해당 글을 보면,

인덱스 노드의 구조가 나온다.
해당 부분이 내가 보고 있는 인덱스 부분이다.

Index Record Header

Index Node Header

Index Entry

저 3가지 구조 중에 이번 문제를 풀기 위한 단서는 사실 없다...
해당 Index Entry가 알려주는 정보는 파일의 MFT 주소(번호를 유추할 수 있다) 와 $FILE_NAME 밖에 없다.
여기서 MFT Entry에 있는 $DATA 속성에 클러스터 번호가 있지만, 저 많은 속성들을 모두 일일이 찾아보며 
클러스터 번호를 찾아낸다는 것은 불가능에 가깝다고 생각한다.
그러므로 단순한 방법으로 그냥 이진 데이터 검색 기능을 이용해보련다.
비트낭님께서도 직접 풀어보신 방법은 이러하였다.
클러스터 번호가 125791인 파일을 찾아내는 것인데,
125791 -> 0x01 eb 5f (빅엔디안) -> 0x5f eb 01 (리틀엔디안) 으로 변환하여

여러번 찾아가보면 어떠한 MFT 엔트리로 도착하게 된다.
그리고 happening,jpg라는 파일명이 적혀있는데 이에 대한 확신을 줄 수 있는 정보를 찾아보았다.

이건 MFT Entry 헤더이다.

이건 Fixup Array이고

이건 $STANDARD_INFORMATION

$FILE_NAME이다.

드디어 단서를 찾아냈다.
$FILE_NAME 속성 구조를 보면, 이전에 포스팅한 글을 참고해보면 https://wintersnowaaa.tistory.com/13

MBR - NTFS($FILE_NAME)

Length of Name 값은 0이다. Name이 없다는 것이므로 바로 Attr Content 가 나오게 된다.
Attr Content가 무엇이길래 바로 happening.jpg라는 문자열이 나오는 것이지? 라고 생각했다.
proof님의 $FILE_NAME 포스팅을 보면

이렇게 구조가 이루어져있다.

이렇게 나눌 수 있는데,이름의 길이가 0x0D (13) 이다.
happening.jpg 으로 총 13바이트의 길이가 맞다.
Attr Content 중 Name의 자리로 happening.jpg 값이 들어간 것이다.

그리고 그 다음으로 0x80 00 00 00 의 값은 $DATA 속성의 식별자 값이고, 
$DATA 속성은 Non-Resident 속성이므로, 공통속성헤더 (0x10) 크기와 Non-Resident 헤더 (0x38)의 크기로

하이라이트해놓은 0x48의 크기만큼의 속성이 차지하게된다.
$DATA 속성에 관한 정리를 다시 꺼내어보면, 
https://wintersnowaaa.tistory.com/15

MBR - NTFS($DATA, Non-Resident Header)

우리가 찾아낸 클러스터 번호 125791 -> 0x01 EB 5F (빅엔디안) -> 0x5F EB 01 (리틀엔디안) 값은 Attr Content이다.
이유는 공통속성헤더부분의 이름의 길이가 0으로 정해져있기 때문에 이름없이 바로 Attr Content 값이 나오기 때문.
그리고 $DATA의 Attr Content는 런리스트 구조이므로

3은 0x5F EB 01 (리틀엔디안) 으로 클러스터 번호를 나타내며,
1은 몇개의 클러스터를 사용하는지 VCN의 길이를 나타낸다.

정리하자면, 
1. 125791 번째 클러스터 번호에 있는 파일을 찾아내야하므로 0x5F EB 01 (리틀엔디안) 값을 검색
2. MFT Entry로 추정되는 곳의 속성을 파악하면 $FILE_NAME 속성에서 파일명이 happening.jpg 이며,
$DATA 의 Attr Content 의 런리스트 구조를 통해서 클러스터 번호가 0x5F EB 01에 위치한다는 것으로 확인받음.

문제는 FTK Imager는 파일명 검색 기능이 없다는 것이다. 

->

그래서 autopsy로 키워드 검색을하면 happening.jpg 파일이 있다는 것을 알 수 있다.
경로는...

바탕화면의 영화 포스터 모음쪽에 있구나.
해당 파일을 찾아가서 16진수로 데이터를 봐보자.

사실 시그니처 값을 모두 외우지 못해서 어디서부터 어디까지가 시그니처 값인지 모르겠다.
검색을 해보자.

그렇다고하는군....
그럼 happening.jpg 파일은 JFIF 파일 형식으로 저장된 비트맵 기반 이미지 파일이고,
시그니처 값은 FF D8 FF E0 이다.

2-5번 문제

[서식 5] 공동제작영화의 한국영화인정신청서.hwp 파일의 내부구조를 파악하고, 지은이(Author)를 파악해야한다.

 

이것 또한 비트낭님께서 직접 풀이한 방법대로 해보자.

키워드 검색을 통해 찾아내보면 있다.

Users/forensic/Desktop/영화 서식/ 에 위치한다.

FTK Imager로 들어가서 파일을 Export 해준다.

해당 파일을 hwp에서 zip으로 확장자명을 바꿔준다.
이후에 압축을 해제하면

해당 파일의 구조들을 모두 볼 수 있다.
이 중에 _HwpSummaryInformation 에 문서 정보들이 들어있다. 이를 autopsy로 Text 뷰를 통해 확인해보면,

meta:author: 법제처 국가법령정보센터 라고 메타데이터를 통해 알아낼 수 있다.

2-6번 문제

외부저장장치에 연결된 링크파일을 확인하고 링크파일과 대상파일의 시간정보, 대상 파일 위치, 볼륨 시리얼 넘버, 대상파일의 논리적 크기, 추가적으로 대상 파일이 있던 시스템의 MAC 주소로 보이는 것을 확인하라.

Autopsy에서 Recent Documents를 확인해보면 링크파일들이 있다.

딱 한가지 파일 Phantom.zip 파일이 E 드라이브와 연관된 파일이라고 명시되어있다.
Autopsy에는 링크 파일 분석 기능이 없다.
한국포렌식학회에서 LinkParser 도구를 사용해도 된다고 명시해놓았으니,
LinkParser를 설치해서 사용해보자.
https://www.softpedia.com/get/System/File-Management/LinkParser.shtml

autopsy에서 링크파일을 추출해내고 LinkParser를 실행시켜보자.
왜인지 모르겠지만 링크파일을 폴더에 담아내고 폴더의 파일들을 분석하게끔해줘야한다.

이런식으로 해줘야한다.
그러면 LinkParser가 분석해준 링크 파일의 내용을 보자.

1. 외부저장장치의 MAC주소 = 00:0C:29:07:83:7A

2. 외부저장장치의 볼륨 시리얼 넘버 = 5C3DA927

3. 외부저장장치의 링크 대상파일 크기 = 614480 bytes

클러스터번호를 통한 파일 찾기가 제일 어려웠다....
이거 때문에 2주 정도 이 포스팅만 붙잡았네....