2025 실전 연습 - 분석해보기(EnCase)
1. 쓰기방지 및 사본 이미지 획득
1. EnCase의 FastBloc를 이용한 쓰기방지 설정 에서 진행한 것과 동일한 방식으로 진행
1-1) 쓰기방지
가상디스크로 연습에는 큰 의미는 없으나 연습을 위해서 한번 옵션을 사용해보도록 하겠습니다. EnCase의 Tools - FastBlock SE...을 선택 하여봅시다.
먼저 Write Protected, 또는 Write Blocked 를 선택 한 뒤 게이지가 움직이고 있는 상태에서 USB를 연결하면 Write Protected, 또는 Write Blocked 에 표시가 되면서 쓰기방지가 설정됩니다.
이제 문제 저장매체(가상디스크)를 연결해보도록 하겠습니다. (실제 시험에서는 USB를 연결하는 것과 동일한 것 입니다.) 가상디스크로 연결 할 경우 디스크 관리(Win+X - 디스크 관리)에서 동작 - VHD 연결에서 읽기 전용을 체크 한 뒤 가상디스크 파일을 선택합니다.
가상디스크가 정상적으로 연결 된 경우 아래와 같이 확인할 수 있습니다. 가상디스크 또는 USB를 연결한 경우 아래와 같이 포맷이 필요하다고 하는 것이 표시된다면 정상 인식 된 것입니다.
1-2) 사본 이미지 획득
이제부터 사본 이미지 획득을 진행 합니다.
먼저 해당 가상 디스크를 FTK Imager에서 Physical Drive로 선택하여 불러옵니다.
가볍게 살펴보니 파티션 3(Basic data partition)의 경우 VBR이 훼손된 것을 알 수 있습니다. 파티션3의 시작 섹터가 239,616 섹터에 위치하고 바로 다음 섹터에 BOOTMGR이 슬쩍 보입니다.
그리고 해당 파티션 마지막 섹터에 NTFS VBR 복사본이 위치합니다. 40,764,344 섹터가 VBR의 복사본이며 NTFS 파일 시스템임을 알 수 있습니다. 40,764,344 -> 239,616 섹터로 복사하여 덮어쓰기를 진행하여 복구 할 수 있습니다.
파티션 복구 및 파일시스템 사본 이미지 생성을 해보도록 하겠습니다. 물리 드라이브 최상위 우클릭 - Export Disk Image (꼭 최상위를 선택해야 저장매체의 전체 사본을 획득할 수 있습니다. 파티션만 고를 경우 파티션만 획득 됩니다.)
또는 File - Create Disk Image - Physical Drive 를 선택합니다. (완전히 동일한 기능으로 원하는 걸로 하시면 됩니다.)
Add 를 이용하여 획득한 이미지 파일 종류, 저장할 경로, 분할 사이즈를 선택합니다.
분할 사이즈(Image Fragment Size)는 0으로 설정합니다. -> raw 이미지 파일이 1개로 나오며 0번부터 마지막 섹터까지 연결되어 복구가 용이합니다.
raw 이미지 획득이 완료되면 아래와 같이 .001 파일이 생성되며, .txt로 로그 파일이 생성됩니다. 이 로그 파일에서 실제 시험에서 답안 작성 또는 분석 보고서에 활용 합니다. 원본 저장매체의 해시값, 드라이브 시리얼 넘버 등이 나옵니다. 아쉽게도 가상디스크의 경우 시리얼 넘버가 없습니다.
USB 또한 E01 파일인 이미징 파일 입니다. > Bitlocker 제외 버전의 경우 이 부분은 참고만 합시다. FTK imager로 확인 해보겠습니다.
아래와 같이 내부 구조를 확인할 수 없습니다. ex - FVE-FS 이런 식으로 보일 경우 암호화된 bitlocker 파일시스템으로 볼 수 있고 시나리오-사전정보에서도 bitlocker에 대해서 언급이 되어 있습니다.
Autopsy 4.22.1 버전 이상에서는 raw로 변경하지 않아도 인식이 가능 하지만 실제 시험에서는 이전 버전을 제공 할 수 있으니 Raw로 추출한 뒤 분석하도록 하겠습니다.
2. 분석 준비
2-1) 파일시스템 복구
파일시스템 복구에 필요한 것은 위에서 이미 확인 하였으나 다시 한번 살펴보겠습니다. 먼저 파티션 3번 위치로 이동하였는데 섹터의 앞 부분이 훼손되어 있습니다. 시작 섹터번호가 239,616 섹터입니다.
NTFS의 경우 해당 파티션에 가장 마지막에 NTFS 복사본이 위치합니다. 가장 끝에 위치로 이동해 보겠습니다. 그리고 해당 파티션 마지막 섹터에 NTFS VBR 복사본이 위치합니다. 40,764,344 섹터가 VBR의 복사본이며 NTFS 파일 시스템임을 알 수 있습니다. 40,764,344 -> 239,616 섹터로 복사하여 덮어쓰기를 진행하여 복구 할 수 있습니다.
파일시스템 복구는 HxD를 이용하여 Raw 이미지를 복구합니다. 도구 - 디스크 이미지 열기로 Raw 이미지를 열고 VBR 복사본이 위치한 섹터(2,054)로 이동 후 한 섹터를 복사합니다. (FTK Imager로 raw 이미지를 열면 수정이 안되니 복구할 때에는 FTK Imager를 모두 종료합니다.) 40764344섹터로 이동 한 뒤 해당 섹터를 복사합니다.
239,616번 섹터가 파티션1 시작 위치며 정상 VBR이 위치해야 합니다. 이 섹터에 가장 앞 부분에서 우클릭 -[붙여넣기 쓰기] 하여 덮어쓰고 저장 합니다. * 삽입을 하게 되면 1섹터가 전체적으로 밀려나기 때문에 삽입하면 안됩니다.
FTK Imager를 이용하여 복원한 이미지를 불러오면 정상적으로 파일 구조가 확인되면 복구는 정상적으로 진행한 것입니다. [root] 디렉토리에서 데이터가 정상적으로 보이면 정상 복구 된 것입니다.
2-2) 분석 이미지 추가하기
EnCase에서 케이스 생성 후 복구한 Raw 이미지를 추가합니다. Add Evidence - Raw Image를 선택 한 뒤 복구한 파일시스템을 선택합니다.
이 후 1차 프로세싱(Processor)을 진행합니다. 비교적 빨리 끝나며 기존에 주로 출제되는 문제 유형을 해결하는데 도움이 되는 프로세스 옵션을 선택 후 진행합니다. - File Signature analysis - Hash Anlysis - Find email - Find Internet Artifacts - System info Parser - Windows Event Log Parser - Windows Artifact Parser - Thumbnail creation(선택적으로 선택 가능, 다만 그렇게 효율적이진 않은 느낌..)
View - Processor Manager, 우측 하단에 진행 상황을 확인할 수 있습니다.
실제 시험에서는 이 동안 해결 가능한 문제를 해결하거나, 답안 작성 준비를 작업을 진행합니다. 프로세싱이 완료되면 Evidence 의 우클릭 또는 Refresh를 클릭하여 프로세싱 처리 내역을 적용합니다.
3. 분석 및 문제 해결
3-1) 기초 분석 문제
증거물 사본을 생성하고 각 문제 항목의 답안을 작성하시오.
기초 분석 문제 1-1) 운영체제가 설치된 파일시스템의 파일시스템 종류
1-2) 운영체제가 설치된 파일시스템의 볼륨시리얼 넘버
1-3) 운영체제가 설치된 파일시스템의 클러스터 크기
1-4) 운영체제에 할당된 IP 주소
분석 과정 (직접 먼저 해보시고 참고 해보세요!)
운영체제가 설치된 파일시스템의 파일시스템 종류 > NTFS
운영체제가 설치된 파일시스템의 볼륨시리얼 넘버 > 시리얼넘버 : 1259-943F / 풀시리얼넘버 : 62 12 59 BA 12 59 94 3F
운영체제가 설치된 파일시스템의 클러스터 크기 > 4,096 bytes
운영체제에 할당된 IP 주소 > 172.30.1.22
프로세싱이 종료된 후 View-Artifacts 에서 System Info Parser -> Network - Interfaces에서 네트워크 관련 정보를 확인할 수 있습니다.
할당된 IP 정보를 확인할 수 있습니다.
3-2) 시나리오 관련 분석
시나리오와 관련 있는 분석 문제를 해결해 봅시다!
bitlocker로 암호화된 usb를 복구할 수 있는 키를 찾고 복구 후 아래 문제를 해결하시오. (bitlocker 제외 버전은 바로 복구 없이 아래 문제 해결) 2-1) USB 파일시스템의 볼륨시리얼 넘버 2-2) 내부 자료 유출을 의뢰한 내용을 확인하고 보낸 사람, 메일 주소를 확인하라.
분석 과정 (직접 먼저 해보시고 참고 해보세요!)
먼저 bitlocker 복구키를 찾아야 합니다. 먼저 주요 폴더들을 찾아보면 쉽게 복구키를 찾을 수 있습니다. 휴지통에서 쉽게 찾아지고 추가로 키워드 검색이나 condition에서 파일명 검색에서도 어렵지 않게 찾을 수 있습니다. > 실제 시험에서 찾기 어려울 경우 프로세스의 키워드 검색에서 bitlocker를 검색해서 찾을 수 있을 것 입니다.
Usb 이미지를 EnCase에 로드 해보도록 하겠습니다. Add - Evidence 에서 Add - Evidence File 에서 usb 이미지 E01을 선택합니다. 추가하면 프로세싱 할 것인지 묻는데 Cancel 선택합니다. (Bitlocker 제외 버전의 경우 여기서 bitlocker 제외 버전 E01을 선택합니다.)
이 후 usb 이미지를 Name 부분을 로딩하면 bitlocker 암호를 입력하라는 창이 나옵니다. Recovery Password 에서 식별자를 선택한 뒤 복구 키를 입력 합니다. *참고로 잘못 입력하거나 할 경우 Recan을 누르면 다시 이 창을 열 수 있습니다.
내부 구조를 확인할 수 있으며. 시나리오와 관련 있어 보이는 파일도 발견됩니다.
2-1) USB 파일시스템의 볼륨시리얼 넘버 > 시리얼 넘버 : 52 E7 66 FE / 풀시리얼넘버 : 80 52 E7 6E 52 E7 66 FE
파일시스템이 위치한 파티션을 선택하면 Report에서 볼륨시리얼 넘버 확인이 가능합니다.
참고로 NTFS의 경우 $Boot 메타데이터에 VBR 섹터 데이터를 가지고 있습니다. 여기서도 볼륨 시리얼 넘버를 확인할 수 있습니다.
2-2) 내부 자료 유출을 의뢰한 내용을 확인하고 보낸 사람, 메일 주소를 확인하라.
우선 USB 자체에는 특정 파일들 외에는 발견 되는 것이 없기 때문에 바로 빠르게 시그니처분석, 해시값 등을 확인할 수 있는 기능도 활용해보도록 하겠습니다. 전체 파일을 체크 한 뒤 우클릭 Entires - Hash\Sig Selected.. 선택한 뒤 해시와 Verify file Signature를 체크한 뒤 OK 합니다. 또는Processing을 진행하여도 좋습니다.
이후 Refresh 하면 해시값, Signature Anlysis 결과 등을 확인할 수 있습니다.
이제 USB의 전체적인 파일을 찾아보면서 이상해 보이는 파일을 찾아야 합니다. 유일하게 Zone.Identifier가 없는, 그리고 docx 이지만 다른 docx랑 다르게 아무 내용이 보이지 않습니다.
hex 값을 비교해보면 구조도 다른 것을 알 수 있습니다. ( 부분만 봐도 확장자가 정상이 아닌 것을 의심해볼 수 있을 것 입니다.)
해당 파일은 압축 파일로 보이며 우클릭 - Entries - View File Structure를 통해 내부 구조를 확인할 수 있습니다. 실제로 확인해보면 다른 문서 파일들을 압축 파일인데 docx로 변경한 것으로 예상해볼 수 있습니다.
이 파일들도 한번 Signature 분석을 위해 전체 체크 후 Entries - Hash\Sig Selected를 선택 하여 시그니처 분석을 진행 합니다. OK 후 refresh 버튼을 눌러 반영하도록 합니다.
이후 Refresh 에서 결과를 확인할 수 있으며, 같은 docx인데 하나가 Match가 아닌 Alias인 파일이 하나 발견되며, 내용을 다른 파일과 달리 확인할 수 없습니다. (참고로 hwp의 경우 Alias가 정상입니다.)
동일한 docx랑 비교했을때 시그니처는 동일하지만 뒷부분이 약간 달라보입니다.
차리리 doc 파일의 구조와 비슷해 보입니다.
해당 파일을 추출 한뒤 직접 시그니처를 doc의 시그니처로 수정해보도록 하겠습니다.
정상 doc 파일을 참고해서 시그니처를 수정합니다.
이후 확장자를 doc로 변경 후 파일을 열어보면 내용을 확인 할 수 있습니다. (doc가 아니라면 xls, ppt, hwp 등 다 시도 해봐야 합니다.)
정리하면 먼저 압축파일의 확장자를 docx로 변경하였고 구버전 doc를 docx로 변경하여 숨겨논 상황입니다. > 보낸 사람 : 이진우 / 메일 : jinu.biz@protonmail.com
분석 과정 (직접 먼저 해보시고 참고 해보세요!) - bitlocker 제외 버전
Usb 이미지를 EnCase에 로드 해보도록 하겠습니다. Add - Evidence 에서 Add - Evidence File 에서 usb 이미지 E01을 선택합니다. 추가하면 프로세싱 할 것인지 묻는데 Cancel 선택합니다.
내부 구조를 확인할 수 있으며. 시나리오와 관련 있어 보이는 파일도 발견됩니다.
2-1) USB 파일시스템의 볼륨시리얼 넘버 > 시리얼 넘버 : 52 E7 66 FE / 풀시리얼넘버 : 80 52 E7 6E 52 E7 66 FE
최상위에서 파일시스템 부분 선택 후 Report에서 파일시스템의 볼륨시리얼 정보를 확인할 수 있습니다.
참고로 NTFS의 경우 $Boot 메타데이터에 VBR 섹터 데이터를 가지고 있습니다. 여기서도 볼륨 시리얼 넘버를 확인할 수 있습니다.
2-2) 내부 자료 유출을 의뢰한 내용을 확인하고 보낸 사람, 메일 주소를 확인하라.
우선 USB 자체에는 특정 파일들 외에는 발견 되는 것이 없기 때문에 바로 빠르게 시그니처분석, 해시값 등을 확인할 수 있는 기능도 활용해보도록 하겠습니다. 전체 파일을 체크 한 뒤 우클릭 Entires - Hash\Sig Selected.. 선택한 뒤 해시와 Verify file Signature를 체크한 뒤 OK 합니다. 또는Processing을 진행하여도 좋습니다.
이후 Refresh 하면 해시값, Signature Anlysis 결과 등을 확인할 수 있습니다.
이제 USB의 전체적인 파일을 찾아보면서 이상해 보이는 파일을 찾아야 합니다. 유일하게 Zone.Identifier가 없는, 그리고 docx 이지만 다른 docx랑 다르게 아무 내용이 보이지 않습니다.
hex 값을 비교해보면 구조도 다른 것을 알 수 있습니다. ( 부분만 봐도 확장자가 정상이 아닌 것을 의심해볼 수 있을 것 입니다.)
해당 파일은 압축 파일로 보이며 우클릭 - Entries - View File Structure를 통해 내부 구조를 확인할 수 있습니다. 실제로 확인해보면 다른 문서 파일들을 압축 파일인데 docx로 변경한 것으로 예상해볼 수 있습니다.
이 파일들도 한번 Signature 분석을 위해 전체 체크 후 Entries - Hash\Sig Selected를 선택 하여 시그니처 분석을 진행 합니다. OK 후 refresh 버튼을 눌러 반영하도록 합니다.
이후 Refresh 에서 결과를 확인할 수 있으며, 같은 docx인데 하나가 Match가 아닌 Alias인 파일이 하나 발견되며, 내용을 다른 파일과 달리 확인할 수 없습니다. (참고로 hwp의 경우 Alias가 정상입니다.)
동일한 docx랑 비교했을때 시그니처는 동일하지만 뒷부분이 약간 달라보입니다.
차리리 doc 파일의 구조와 비슷해 보입니다.
해당 파일을 추출 한뒤 직접 시그니처를 doc의 시그니처로 수정해보도록 하겠습니다.
정상 doc 파일을 참고해서 시그니처를 수정합니다.
이후 확장자를 doc로 변경 후 파일을 열어보면 내용을 확인 할 수 있습니다. (doc가 아니라면 xls, ppt, hwp 등 다 시도 해봐야 합니다.)
정리하면 먼저 압축파일의 확장자를 docx로 변경하였고 구버전 doc를 docx로 변경하여 숨겨논 상황입니다. > 보낸 사람 : 이진우 / 메일 : jinu.biz@protonmail.com
이미지 파일 유출 관련(시나리오 분석 문제-1 )
-유출한 이미지 파일 자체는 해당 공용 PC에 저장된 적이 없습니다. 이 상태에서 아래 문제를 해결하세요. 3-1) 내부 자료를 유출한 이미지는 무엇이고 원래 어떤 경로에서 해당 USB 의 어떤 경로로 저장되었는지 확인하세요.
3-2) USB가 해당 PC에 연결되고 유출에 사용 되었다는 것을 증명할 수 있는 추가적인 내용을 작성하세요.
3-3) 유출한 이미지 파일명이 원래 무엇에서 무엇으로 변경되었는지 확인하시오.
3-4) 공용 PC에서 유출한 이미지 내용은 확인할 수 있는 추가적인 방법을 제시하시오.
분석 과정 (직접 먼저 해보시고 참고 해보세요!)
유출한 이미지 파일 자체는 해당 공용 PC에 저장된 적이 없습니다. 이러한 상태에서 아래 문제를 해결하세요.
내부 자료를 유출한 이미지는 무엇이고 원래 어떤 경로에서 해당 USB 의 어떤 경로로 저장되었는지 확인하세요.
USB가 해당 PC에 연결되고 유출에 사용 되었다는 것을 증명할 수 있는 추가적인 내용을 작성하세요.
유출한 이미지 파일명이 원래 무엇에서 무엇으로 변경되었는지 확인하시오.
만약 USB가 없었다는 전재로 이 공용 PC에서 해당 이미지를 확인할 수 있는 방법을 제시하시오.
우선 문제부터 이해가 어렵습니다. 이미지 파일이 해당 PC에 저장된 적이 없는데 USB로 저장되었다고 합니다. 먼저 인터넷에서 다운 받았다면 당연히 PC에 저장될 것이고 PC에 저장된 적이 없는데 파일을 넣었다는 상황은 상상하기가 쉽지 않습니다. 우선 전체적으로 파일을 살펴보고, 의심스러운 부분들을 모두 살펴본 뒤 다시 정리해보도록 하겠습니다.
우선 바탕화면에 여러가지 자동차 사진 그리고 문서 폴더에 있던 복구키 관련 말고는 의심스런 파일 찾기가 매우 어렵습니다. 사실 재부팅 되면 초기화되는 공용PC라면 더 더욱 자료가 잘 없을 것 같습니다.
Artifacts 에서 Windows Artifacts Parser 에서 Recycle Bin 에서 휴지통에 있던 파일의 원래 경로를 확인할 수 있습니다. 내 문서 폴더에 있었네요.
그렇다면 가장 최근에 실행했던 목록들을 살펴보겠습니다. Artifacts 에서 System Info Parser에서 MRU Artifacts 에서 Explorer Recent Documents에서 최근 실행했던 파일의 링크 파일 목록을 확인할 수 있습니다.
Users폴더의 플래이트(초록 버튼)을 눌러서 해당 링크파일을 찾아봅시다. 위에서 찾은 파일명과 동일한 파일명을 클릭할 경우 최근에 실행한 파일의 링크파일이 모여있는 폴더를 찾을 수 있습니다.
Report에서 Link 관련 정보를 확인할 수 있으며, 해당 원본 파일의 크기, 저장된 경로 등을 확인할 수 있습니다. 자 여기서 SerialNumber를 보면 USB의 시리얼 넘버와 동일한 것을 확인할 수 있으며, 실제 USB에 해당 경로와 파일이 있는 것을 알 수 있습니다.
System info parser 에서 USB 연결 정보도 확인할 수 있고 E드라이브에 연결되었던 것도 확인이 됩니다.
여기서 다른 링크파일을 살펴보다보면 상당히 의심스런 경로의 파일이 실행되었음을 확인할 수 있습니다.
우선 해당 링크 파일들을 모두 추출한 뒤 링크 분석 전용 도구로 살펴보겠습니다. lnk를 체크한 뒤 Entries - Copy files를 하여 체크한 파일만 추출합니다. 체크할때 다른 파일들은 체크 안되게 유의하면서 추출합니다.
20170327_LinkParser_DFRC.exe 도구(시험장 제공 도구)를 이용하여 해당 폴더를 열어 보겠습니다. 참고 > 2. Link 링크파일 관련 실제로 아직 출제된 적도, 공부한적도 없지만 상당히 이상한 경로에 파일들이 있고, E드라이브 관련도 보이고 합니다.
*참고로 이 프로그램에는 버그가 있어서 폴더로 열 경우 약간 잘못된 정보도 보여주고 있으니 정말 정확한 분석이 필요할 경우 하나씩 파일로 열어서 start 눌러서 확인해야 합니다. 동일한게 2번 나오면서 2번째에 DriveSerialNumber가 붙고 있습니다. 시간정보도 모두 동일
자 이제 Filesize로 정렬을 한번 해보겠습니다. 아래와 같이 우선은 동일한 사이즈의 파일이 아직 잘은 모르지만 \\172.30.1.43\2025 new project이랑 E드라이브에 있는 것처럼 보입니다
이 두 파일만 다시 따로 하나씩 열어보겠습니다.
그리고 드라이브 시리얼 너버를 보게 되면 이전 문제에서 해결했던 USB의 시리얼 넘버와 동일하게 보입니다. > 시리얼 넘버 : 52 E7 66 FE 즉, 172.30.1.43 폴더에서 USB로 복사된걸까? 의심해볼 수 있습니다. *\\172.30.1.43 의 의미는 공유폴더로 해당 공용PC에서 같은 네트워크에 공유폴더로 접근했을 때 폴더를 공유하고 있는 상대방 PC의 IP에 해당합니다.
그렇다면 USB에서 파일명이 변경되었는지 한번 확인해볼 필요가 있습니다. 우선 해당 폴더로 가보면 누가 봐도 의심스러운 파일이 있습니다. 다만 이 파일명이 이전에 뭐였는지 체크해볼 필요가 있습니다. NTFS Log Tracker를 이용하여 파일명 변경 이력을 살펴보겠습니다. 참고> 6. 파일명 변경 내역(NTFS Log) $LogFile, $MFT 파일을 추출합니다.
NTFS Log Tracker에 $LogFile, $MFT 파일을 선택 후 Parse를 선택하여 추출합니다.
사실 가장 처음 부분에 파일명 변경 내역이 확인이 가능합니다. 필요시 검색을 통해 파일명 변경 이력을 찾을 수 있습니다.
즉, 충분히 공유폴더에서 해당 USB로 파일을 복사한 뒤 파일명을 변경한 것으로 보이는 것을 확인할 수 있습니다.
자 그러나 이것은 USB가 있을 경우 USB 분석을 통해서 가능합니다. 그렇다면 USB가 없을 경우에 해당 PC에 이미지를 확인할 수 있는 부분이 어디가 있을까? 혹시 모르니 Win이 설치된 파일시스템에서 동일한 파일 용량의 이미지 파일이 어딘가에 있을 수 있으니 검색해보겠습니다.
그전에 이미지 파일 하나의 용량을 체크해보겠습니다. 1,743,301 bytes 파일과 동일한 용량의 파일이 있는지 Windows가 설치된 파일시스템에서 찾아보겠습니다. 파일시스템 전체를 플래이드 걸고 사이즈로 정렬한뒤 해당 용량을 찾아봐도 찾을 수 없습니다.
그러나 우리는 썸네일을 알고 있습니다. 완벽하진 않지만 만약 미리보기 등으로 확인을 했었다면 이 PC에서 해당 파일을 확인 했었다는 것을 알 수 있습니다. (참고)> 4. 썸네일 캐시 분석 우선 thumb를 검색한 뒤 thumbcache 파일을 찾아봅시다. 해당 드라이브 플레이트를 열고 name을 더블클릭하여 정렬한 뒤 thumb를 입력하여 검색하여 봅시다.
thumbcache 파일이 있는 경로를 찾을 수 있습니다.
용량으로 정렬 한 뒤 해당 어느정도 용량이 있는 파일들을 선택하여 추출합니다. (사실 모든 thumbcache 파일을 출력해도 무방합니다. )
썸네일 캐시를 하나하나 열다보면 실제로 동일한 파일을 열어서 썸네일이 생성된 것을 확인할 수 있습니다.(thumbcache_1280.db / 가능하면 뒤에 숫자가 큰 것부터 열어보는 것 추천)
사실 공용 폴더의 경우 더 많은 아티팩트 분석도 가능합니다. System info Parser 에서 Network Shares 에서 공유 폴더 IP 정보등도 확인이 가능합니다.
더 상세히 공부해보고 싶은 분들은 찾아보시면 더 많은 아티팩트에서 확인이 가능하니 직접 찾아 보시길 권고 드리고 추후에 저도 공유폴더 관련 자료도 더 보강하도록 하겠습니다.
답안 작성은 직접 해보시길 바랍니다. -> 추후 정리 예정
동영상 파일 유출 관련(시나리오 분석 문제-2) - 유출된 동영상이 존재한다. 어떻게 유출되었는지 조사하라! 4-1) 유출된 동영상의 파일 사이즈, MD5 해시값을 확인하라. 4-2) 동영상들은 어떤 방법으로 유출되었는지 확인 후 추가로 유출된 파일의 MD5 해시값을 구하라.
분석 과정 (직접 먼저 해보시고 참고 해보세요!)
우선 유출 되었다고 하면 여러가지 시나리오가 있겠지만 메일이나 메신저, 기타 파일 전송 관련 프로그램, 서비스 등을 사용했을 가능성이 높으므로 순서대로 찾아보는 것을 추천합니다.
eml 파일, 메신저 등은 발견되지 않으나 의심스러운 프로그램들이 다운로드 및 설치된 것은 확인할 수 있습니다. FileZilla, 알드라이브의 경우 FTP 프로토콜로 파일 전송 관련 프로그램에 해당합니다. 그리고 구글 드라이브 역시 파일 업로드를 할 수 있는 프로그램에 해당합니다. 다만 특이한 것은 구글 드라이브는 웹으로 접근이 가능하지만 PC 버전으로 설치도 가능하다는 것입니다. 특히나 휴지통에 해당 파일들의 설치 파일들이 발견됩니다.
우선 해당 프로그램들이 설치된 것으로 보이는 경로를 가서 로그 같은 흔적을 찾아봅니다. 그러나 열심히 봐도 딱히 보이진 않습니다.
User\{사용자}\AppData에서 살펴보면 구글 드라이브 관련 폴더가 발견되고 구석 구석 살펴보겠습니다. content_cache 폴더 내부를 살펴보다 보면 갑자기 bitlocker 가 보이고 CodePage를 Unicode로 하면 아까 찾았던 비트락커 복호화 키가 보입니다.
content_cache 하위 폴더들을 좀 더 살펴보면 동일한 구조를 가진 파일들이 더 발견 됩니다. 시험에서 자주 출제되지는 않은 것으로 알고 있는 동영상 파일의 시그니처를 가지고 있습니다.
우선 해당 하위 폴더 내 파일을 더블클릭 해보겠습니다. PC에 설정된 것에 따라 다르겠지만 바로 동영상이 재생됩니다.
만약 재생되지 않더라도 동영상이라고 생각하고 해당 파일들 추출 한 뒤 확장자를 mp4로 변경해보도록 하겠습니다. 동영상이 재생됩니다.
우선 이 파일들의 크기와 아까 링크 파일을 분석해서 공유폴더에 있던 파일들의 크기를 비교해보겠습니다. 동일한 것을 확인할 수 있습니다.
그렇다면 구글 드라이브를 통해 유출했을 것으로 매우 크게 의심이 됩니다. 관련 정보를 더 파악하기 위해 구글드라이브 관련한 추가 정보를 찾아보도록 하겠습니다. 특히나 이런 앱, 프로그램의 경우 sqlite 파일이 있을 경우 분석해볼 필요가 있습니다. 시간이 허락하는한 많은 파일을 살펴 봐야하지만 우선 제일 의심스러워 보이는 DB 파일들을 추출 합니다. (추출 시 다른 파일 추출하지 않도록 체크)
DB Browser를 이용하여 열어보도록 하겠습니다. 테이블을 바꾸다 보면 Items 바꾸다 보면 파일 사이즈와 파일명 정보를 확인할 수 있습니다. 참고 > 5-1) Sqlite 열어보기
해당 정보등을 토대로 해시값 등도 같이 정리해볼 수 있습니다.
사실 Content_cache에 폴더 경로 관련 정보까지 있으면 베스트지만 없거나 찾기 어려울 수 있습니다. 프로그램 개발사에서 정하는 모든 구조를 알려주는건 아니기도 하고 모든 걸 분석가가 바로 알기도 어렵고 언제 또 새로운 형태로 바뀔지도 모릅니다.
위의 찾은 것들을 모아서 파일명, 크기 정보를 토대로 정리해보면...
파일명: 304 -> 내부영상1.mp4 파일크기: 3,081,865 bytes MD5: 55053f5f59c4356a92fd7c436445e13b
파일명: 306 -> 내부영상2.mp4 파일크기: 3,863,968 bytes MD5: 4ec4ea6832065a234957b7cc64fce0bd
파일명: 308 -> 내부영상3.mp4 파일크기: 3,907,574 bytes MD5: 48121d255e754e4c54adb8ef9165350d
파일명: 302 -> 내부영상1.mp4 파일크기: 3,256,235 bytes MD5: 1e9dfffe5af77c1386392dab1aff6ccb
정리해보면 공유폴더에 있는 영상과 USB의 비트라커 키를 구글 드라이브에 업로드 한 것으로 볼 수 있게 되는 것입니다. 사실 링크파일에서도 최근 G드라이브 - Google Drive에 연결되었던 링크 파일도 확인이 가능합니다.
310 파일이 추가로 발견되며 해당 파일 내용을 보면 bitlocker의 복구키 또한 업로드 한 것으로볼 수 있습니다. - 파일명 : 310 -> BitLocker 복구 키 C9DF434A-095A-4B88-AC14-4A3E38849555.TXT - 파일크기 : 836 Bytes - MD5 : 3d7e74e36f6f16dd42036e8643e541a6
이번에는 구글 드라이브를 기준으로 하였으나 실제 시험에서는 어떤 앱이나 프로그램이 추가로 나올지 알 수 없으나 최근 대부분의 앱이나 프로그램은 AppData에서 설치되며, Sqlite구조로 되어 있는 경우가 많습니다. 이렇게 구글 드라이브 뿐만 아니라 다른 여러가지 프로그램을 문제에 사용될 수 있고 이러한 것들을 분석할 수 있는 역량을 확인하는 듯 합니다. 그러나 모든 프로그램 마다 무엇을 봐야 하는지 일일이 다 외워야 한다는 식으로 어렵게 생각할 필요는 없고 Appdata에서 각폴더에 들어가서 Sqlite db 파일을 발견하면 해당 파일을 추출한 뒤 DB browser for Sqlite를 이용하여 테이블 등을 살펴보면서 분석을 시도해 볼 수 있을 것입니다.
4. 답안 작성
문제지에서 요구하는 형식에 맞춰서 답안 작성 문서 파일, 주요 증거 파일을 저장합니다.
참고로 시험 합격여부에 거의 영향은 없을 것이지만 증거제출용 USB에 먼저 문서파일, 폴더를 저장한 뒤에 맨 마지막에 FTK Imager에서 주요 증거파일을 USB 파일 저장 폴더에 바로 추출합니다. EnCase에서 우클릭 - Entries - Copy로 추출한 뒤 저장할 때 USB에 주요 증거파일 폴더에 추출하여도 동일합니다.
Last updated