2023 실전 연습 - 분석해보기(EnCase)

석 연습에 필요한 저장매체 (가상디스크, E01 이미지) 파일의 경우 이전 포스팅에서 다운 받을 수 있습니다.

-> 2023 실전 연습 문제(종합유형)

1. 쓰기방지 및 사본 이미지 획득

• 1. EnCase의 FastBloc를 이용한 쓰기방지 설정 에서 진행한 것과 동일한 방식으로 진행

1-1) 쓰기방지

1. 가상디스크로 연습에는 큰 의미는 없으나 연습을 위해서 한번 옵션을 사용해보도록 하겠습니다. EnCase의 Tools - FastBlock SE...을 선택 하여봅시다.

   
2. 먼저 Write Protected, 또는 Write Blocked 를 선택 한 뒤 게이지가 움직이고 있는 상태에서 USB를 연결하면 Write Protected, 또는 Write Blocked 에 표시가 되면서 쓰기방지가 설정됩니다.

   
3. 가상디스크가 정상적으로 연결 된 경우 아래와 같이 확인할 수 있습니다. 가상디스크 또는 USB를 연결한 경우 아래와 같이 포맷이 필요하다고 하는 것이 표시된다면 정상 인식 된 것입니다.

   
4. 이제 문제 저장매체(가상디스크)를 연결해보도록 하겠습니다. (실제 시험에서는 USB를 연결하는 것과 동일한 것 입니다.) 가상디스크로 연결 할 경우 디스크 관리(Win+X - 디스크 관리)에서 동작 - VHD 연결에서 읽기 전용을 체크 한 뒤 가상디스크 파일을 선택합니다.

   

1-2) 사본 이미지 획득

1. 이제부터 사본 이미지 획득을 진행 합니다.

   파티션1을 살펴보니 시작 섹터는 비어 있으나 마지막 섹터로 가보니 NTFS의 VBR 복사본이 위치합니다. 즉, 파일시스템이 훼손되어 있습니다. 따라서 RAW 로 이미지 획득을 진행합니다. 용량이 34GB로 크기 때문에 충분한 용량을 확보 후 진행하시기 바랍니다.

   
2. 문제에서 원본 저장매체의 사본이미지, 해시값 획득에 대해 질문이 없고 파일시스템도 훼손되지 않았기 때문에 raw로 추출하지 않도록 하겠습니다. 다만 분석 보고서 작성시 활용할 수 있으니 원본 저장매체의 해시값을 획득해보도록 하겠습니다.

   
3. 분석해야 할 USB 이미지와, 분석할 가상디스크의 디스크 이미지를 추출해보도록 하겠습니다. USB_image.aff 가상디스크 디스크 이미지(vmdk)를 추출 해보겠습니다.

   
4. USB_Image.aff인 aff 의 경우 Advanced Forensic Format 파일로 이미지 파일의 한 종류입니다. FTK Imager를 이용하여 aff 이미지 파일을 열게 되면 Raw이미지로 획득이 가능합니다. 즉, USB_image를 AFF로 획득한 것을 열어보도록 하겠습니다.

   

   이미지를 열어보면 0번 섹터는 훼손되어 있고, 마지막 섹터에는 NTFS VBR 복사본이 없습니다. 6번 섹터에도 FAT32 VBR의 복사본이 없습니다. 그러나 12번 섹터에서 exFAT VBR 복사본을 확인할 수 있습니다. 즉, exFAT 파일시스템 구조를 가진 USB의 파일시스템이며, 파일시스템 복구를 위해서는 Raw 이미지로 추출 한 뒤 복구 시도를 해봐야 합니다.

   
5. VMDK를 열어보도록 하겠습니다. 분할 저장되어 있는 파일 중에서 숫자가 없는 vmdk 이미지를 선택하여 열 수 있습니다.

   
6. VMDK 구조를 보면 GPT 파티션 구조가 있으며, 마지막 파티션의 경우 bitlocker 암호화 되어 있습니다. 파일시스템 복구가 필요한 것은 아니기 때문에 raw 이미지 추출을 하지 않아도 됩니다. (raw 이미지로 획득 후 진행하여도 무방. 다만 용량이 매우 크기 때문에 충분한 용량이 필요.) EnCase의 경우 bitlocker의 경우 raw 이미지로 추출하지 않아도 분석 가능하니 vmdk를 바로 추가하여 진행하도록 합니다.

   

2. 분석 준비

2-1) 파일시스템 복구

1. *USB_Image.aff의 경우 파일시스템 복구가 필요하여 Raw 이미지로 추출해보도록 하겠습니다.

   

   추출한 Raw 이미지를 12번 섹터를 복사 후 0번 섹터에 덮어써서 복구해보도록 하겠습니다.

   

2. 아래와 같이 USB 내부 폴더 구조가 확인이 되면 Autopsy, EnCase와 같은 도구에 추가하여 분석합니다.

   

• 이번 이미지 형태는 정상 vmdk와 훼손된 exFAT 파일시스템을 복구하여 분석해야 합니다.

2-2) 분석 이미지 추가하기

1. 용량이 적은 usb 이미지를 먼저 추가해보겠습니다. EnCase에서 케이스 생성 후 복구한 Raw 이미지를 추가합니다. Add Evidence - Raw Image를 선택 한 뒤 복구한 파일시스템을 선택합니다.

   
2. 추가로 VMDK 윈도우 이미지를 추가 해보겠습니다.

   

   Windows 내부 구조를 보기 위해 클릭할 경우 bitlocker 복호화 하는 메뉴를 제공합니다. 다만 아직은 암호를 모르기 때문에 취소를 누른뒤 확인해보겠습니다

   
3. 이 후 1차 프로세싱(Processor)을 진행합니다. 비교적 빨리 끝나며 기존에 주로 출제되는 문제 유형을 해결하는데 도움이 되는 프로세스 옵션을 선택 후 진행합니다. - File Signature analysis - Hash Anlysis - Find email - Find Internet Artifacts - System info Parser - Windows Event Log Parser - Windows Artifact Parser

   
4. View - Processor Manager, 우측 하단에 진행 상황을 확인할 수 있습니다. 2개의 대상이 동시에 진행됩니다.

   
5. 실제 시험에서는 이 동안 해결 가능한 문제를 해결하거나, 답안 작성 준비를 작업을 진행합니다. 프로세싱이 완료되면 Evidence 의 우클릭 또는 Refresh를 클릭하여 프로세싱 처리 내역을 적용합니다.

3. 분석 및 문제 해결

3-1) 기초 분석 문제

1. 파일시스템이 훼손된 USB 이미지를 복구하고 아래 질문에 답변하시오. 1-1. 파일시스템 종류 1-2. 클러스터 크기 / 클러스터 당 섹터 수 1-3. 전체 섹터 수 1-4. 파일시스템의 총 용량 / 가용 용량

1번 분석 과정 (직접 먼저 해보시고 참고 해보세요!)

1. 먼저 파일시스템 복구를 위에서 했습니다. exFAT 구조를 확인하고VBR의 복사본인 12번 섹터를 복사하여 0번 섹터에 덮어쓰기 하여 복구 하였습니다.

   
2. 문제에서 요구하는 부분은 EnCase, FTK Imager에서 내용 확인이 가능합니다. 다만 주의 사항으로 Total Cluster 값이 다릅니다.

   

   exFAT에서는 아래 부분이 Total Cluster 값을 저장하는 영역입니다. FTK Imager에서는 이 부분을 해석 해서 보여줍니다.

   

   반면 EnCase의 경우 Total Sector / Sector per Cluster = 8388608 / 64 = 131,072 클러스터로 계산하고 있습니다. 이렇게 총 클러스터 크기가 차이가 나면 가용용량도 차이가 날 것입니다. - FTK Imager의 가용용량 = 131008 X 32768(클러스터 크기) = 4,292,870,144 bytes > VBR 기반 - EnCase의 가용용량 = 131072 X 32768(클러스터 크기) = 4,294,967,296 bytes > 전체용량 기반 어떤 방식이 더 정확한가?

   • 파일 시스템 분석이 목적이라면: FTK Imager 방식 (VBR 기반)

     • VBR의 Total Clusters 값은 파일 시스템이 관리하는 클러스터 수를 정확히 나타냄.

     • EnCase가 전체 디스크를 기반으로 계산하는 방식은 파일 시스템 외부 영역을 포함할 가능성이 있어, 파일 시스템 자체를 분석하려는 목적과는 맞지 않을 수 있습니다.

   • 디스크 전체 공간 분석이 목적이라면: EnCase 방식

     • 디스크의 전체 용량을 기반으로 계산하므로, 파일 시스템 외부의 공간까지 포함한 계산이 가능합니다.

     • 하지만 파일 시스템 관리 영역 외부는 파일 시스템 분석에서 필요하지 않은 경우가 많습니다.

3. 최상위에서 이미지를 선택 후 [Report]에서 문제에서 요구하는 내용을 확인할 수 있습니다. 1-1. 파일시스템 종류 : exFAT 1-2. 클러스터 크기 : Sectors per cluster X Bytes per sector = 64 X 512 = 32,768 bytes 클러스터 당 섹터 수 : 64 섹터 1-3. 전체 섹터 수 : 8,388,608 섹터 1-4. 파일시스템의 총 용량 / 가용 용량 총 용량 : 전체 섹터 수 X 512 = 4,294,967,296 bytes 가용 용량 : 4,292,870,144 Bytes (4 GB) = Total Clusters X 클러스터 크기 = 131008(Cluster count - FTK Imager) X 32,768 bytes = 4,292,870,144 bytes

1. 윈도우가 설치된 파일시스템을 복구하고 아래 질문에 답변하시오. 2-1. 설치된 운영체제 종류와 머신네임은 무엇이고 설치일, 최종 종료시간은 언제인가? 2-2. 실제 사용자 계정명은 무엇인가? 2-3. 해당 운영체제의 IP 할당은 어떤 방식이고 IP는 무엇인가?

2. 파일시스템 복구한 USB가 가상머신의 운영체제에 연결된 흔적이 있다고 한다. 3-1. 해당 USB의 벤더사, 제품명, 시리얼 넘버는 무엇인가? 3-2. 어떤 것을 통해 USB 가 해당 운영체제에 연결되었는지 증명할 수 있는지 작성하시오. 3-3. 해당 USB가 최초 연결 시간을 확인하라.

3. 썸네일 Cache Entry Hash 값이 "a319ff50ce83c0e2"인 썸네일을 이미지를 캡쳐하고, 이 썸네일이 의미하는 것이 무엇인지 간단히 설명하시오.

2~4번 분석 과정 (직접 먼저 해보시고 참고 해보세요!)

[2번 문제]

1. EnCase의 프로세싱이 종료되면 문제에서 요구하는 부분을 살펴보겠습니다. View - Artifacts 에서 시험에서 요구하는 부분을 살펴보겠습니다. 운영체제 종류, 설치일, 종료시간을 확인 할 수 있습니다.

   

2. 윈도우의 머신 네임(장치 이름)은 레지스트리 분석에서 확인이 가능합니다. Windows\system32\config\SYSTEM 파일 우클릭 - View File Structure를 통해 분석 가능

   

   SYSTEM\ControlSet001\Control\ComputerName\ComputerName 경로에 머신네임 이름을 확인할 수 있습니다.

   

   또는 아티팩트에서 Link Parser 에서 C드라이브로 지정된 링크를 분석하면 머신이름을 확인할 수 있습니다.

   
3. System Info Parser의 Account에서 Last Login Date값이 있는 사용자 계정을 확인해보면 실제 사용자 정보로 볼 수 있습니다.

   
4. System Info Parser 후 네트워 아티팩트에서 확인하면 해당 정보를 확인할 수 있습니다.

   
5. 정리 해보겠습니다.

   1. 설치된 운영체제 종류 : Windows 10 Pro

   2. 머신네임 : DESKTOP-MJ5P95F

   3. 설치일 : 2024-06-23 14:22:03 (+9시 대한민국 표준시)

   4. 최종 종료시간 : 2024-06-23 21:34:15 (UTC +9시 대한민국 표준시)

   5. 실제 사용자 계정명 : web-bit

   6. 운영체제의 IP 할당은 어떤 방식이고 IP : 192.168.126.133 (DHCP 방식)

[3번 문제]

1. System info Parser에서 USB관련 정보를 확인할 수 있는 아티팩트를 통해 문제에서 요구하는 부분을 찾을 수 있습니다. 어떤 드라이브였는지도 확인이 가능하네요!

   
2. Windows Artifacts parser에서 찾을 수 있는 Link 분석 부분을 살펴보면, USB 드라이브에 연결되었던 것으로 보이는 링크파일이 발견되며, 볼륨 시리얼 넘버를 확인할 수 있습니다.

   
3. USB 이미지의 파일시스템 볼륨시리얼 넘버와 비교를 해봤을 때 동일한 것을 알 수 있습니다.

   
4. usb의 최초 연결 시간의 경우 setupapi.dev.log를 살펴봐야 합니다. ”USBSTOR”을 검색 한 뒤 Ven, Prod 를 살펴보고 해당하는 USB에 시작 시간을 확인할 수 있습니다. (표준한국시가 적용되어 있는 시간값 입니다.)

   
5. 정리 해보겠습니다.

   1. 해당 USB의 벤더사 : Sandisk (_USB)

   2. 제품명 : SanDisk_3.2Gen1

   3. 시리얼 넘버 > 01010636ebc1f45454b6f164e49485f622e742e779d56ecbf80c86c9df0f896

   4. USB (F).lnk의 원본 파일의 볼륨시리얼 넘버가 USB의 볼륨시리얼 넘버와 동일

   5. USB 최초 연결 시간 : 2024-06-23 21:33:07(+9, 표준한국시)

[4번 문제]

1. EnCase에서 윈도우가 설치된 파일시스템의 전체 플레이트 선택 후 Name을 정렬한 뒤 "thumb" 또는 "thumbcache"를 입력하여 빠르게 검색하여 ThumbCache_~ 가 위치하는 폴더를 찾습니다. 또는 Users{사용자}\AppData\Local\Microsoft\Windows\Explorer 폴더로 이동합니다. - 썸네일 캐시 분석 방법 > 4. 썸네일 캐시 분석
2. 해당 폴더에서 용량이 최소 1000이상인 것들을 선택 한 뒤 파일을 추출해보도록 하겠습니다.

3. 추출한 파일을 Thumbcache Viewer에 드래그하여 열어보도록 하겠습니다.

   
4. Cache Entry Hash 를 클릭하여 정렬 후 문제에서 요구하는 값을 찾아보도록 하겠습니다. 2개가 발견되는데 하나는 96x96, 다른 하나는 256x256 사이즈로 확인이 됩니다.

   

• 이렇게 썸네일 캐시 이미지가 발견된 것은 파일이 완전 삭제되어 복구가 불가능하다고 하더라도 이 윈도우 운영체제에서 해당 이미지가 존재 하였다는 것을 의미합니다. (이후 비트락커 문제를 해결하면 원본 파일을 찾을 수 있으나, 비트락커 해제가 되지 않은 경우 썸네일 캐시에서 몇 가지 생성형 이미지들을 찾을 수 있습니다.)

3-2) 시나리오 관련 분석 문제

1. 발견한 USB 의 소유가 용의자의 것으로 볼 수 있는 가능성이 큰 이유는 무엇인가?

2. 용의자와 다른 사람이 공모한 흔적을 찾고 찾은 과정을 간략히 작성하시오.

3. 개인 거래내역을 다운 받아서 저장하였다고 한다. 해당 파일을 찾고 아래 내용을 작성하시오. 6-1. 파일명을 변경하였다, 다운받을 때 파일명과 변경한 파일명은 무엇인가? 6-2. 해당 파일을 다운로드 받은 경로

5~7번 분석 과정 (직접 먼저 해보시고 참고 해보세요!)

• 시나리오 관련 파일은 순서대로 찾아지는 것이 아니라 파일들을 찾다 보면 순서 상관없이 의심스런 파일들이 찾아질 수 있습니다. 따라서 우선은 전체적으로 살펴보고, 찾은 파일이 몇 번 문제에 해당하는지 맞춰보는 방식으로 가야 합니다.

• 우선 접근할 때 순서를 정해보도록 합시다.

  1. 일반적으로 사용자가 접근하는 폴더 살펴보기

  2. 시그니처가 이상한 파일

  3. 메일, 시나리오 관련 정상 파일 살펴보기(폴더 별로 일일이 살펴봐야 합니다.)

1. 먼저 USB를 살펴보겠습니다. USB를 하나하나 살펴보면 NPKI(공인인증서)가 폴더가 포함되어 있습니다. 해당 폴더를 살펴보니 이름도 있고, der 확장자를 더블클릭해서 열어보면 인증서 정보도 확인이 가능합니다. 사실상 공인인증서의 경우 남의 인증서를 가지는 경우는 사실상 없기 때문에 1번 문제의 답으로 볼 가능성이 크다고 볼 수 있습니다.

   
2. 시나리오, 문제를 읽어 본 뒤 파일을 살펴보면 파일명이 상당히 의심스러운 파일이 하나 발견됩니다.

   

   우선 의심스러우면 확장자가 정상인지?, 시그니처가 정상인지? 확인해보고 정상이라면, 스테가노로 숨겨진 것이 있을지 한번 확인해봅니다. 해당 파일은 확장자, 시그니처가 큰 문제가 없어 보이기에 정상적으로 파일이 잘 끝나는지 확인해보겠습니다. FF D9 뒤에 추가 그림파일로 보이는 FF D8~로 시작되기 때문에 EnCase의 Decode를 이용해서 한번 살펴보면 추가 이미지가 발견됩니다.

   

   계속 해서 Find Next로 검색해서 숨겨진 이미지가 더 없는지 찾아봅니다. 그런데 맨 마지막 부분에 FF D9 뒤에 추가된 데이터가 확인됩니다. 가장 끝에 "=" 또는 "=="이 있을 경우 Base64 데이터 일 수 있으니 Decode의 Text - Base64 Encoded 로 해석해서 살펴보면 이미지와 동일한 내용을 확인할 수 있습니다. 음.. 그런데 아직 이 비밀번호가 언제 쓰여질지 모르니 추후에 찾아지는 파일들에 대해서 시도해보겠습니다.

   

   다만 사실 이 파일을 한번에 발견하기 어려울 것 입니다. 추가 분석하다가 나중에 이 파일을 발견할 수 있을 수도 있습니다. 혹은, vmdk만 분석하다보면 USB 이미지로 다시 돌아와서 검색해야 할 필요성이 있는데 시험에서는 생각나지 않을 수도 있을 것입니다.

3. usb는 더 이상 특별한게 없어 보이니 이제 vmdk windows 이미지 파일을 분석해보는 쪽으로 가보겠습니다. 파일을 살펴보던 중 Downloads에서 pdf 파일인데 시그니처가 PDF로 시작하지 않은 Bad signature 파일이 발견됩니다. 잘 읽어보면 시나리오와 관련된 파일로 보입니다. [Doc]탭에서 보면 메일을 주고 받은 것을 알 수 있습니다.

   

   [Hex]로 보면 pdf 시그니처가 아닙니다. 즉, 메일 파일 확장자를 변경한 것입니다.

   내용을 보면, 무엇인가를 몇 장 보내주고, 입금을 해준다고 하네요.

   
4. 추가적으로 의심스런 파일들을 찾다보면, 확장자는 jpg인데, 문서파일의 시그니처를 가진 파일을 발견할 수 있습니다.

   

   [doc]를 보면 뭔가 암호화되어 있다고 합니다.

   
5. 우선 우리는 해당 문서 시그니처의 경우 한글, 오피스 파일(구버전)이기 때문에 hwp, docx, xlsx, pptx 등으로 변경하면서 정상적으로 열리도록 확장자를 계속 변경하면서 확인 합니다. docx로 수정 후 문서 파일 확장자로 바꾼 뒤 열어보면 암호를 입력하라고 합니다. 아쉽게 docx로는 안열리네요!

   

   xlsx로 변경 후 USB에서 찾을 비밀번호를 입력하여 열어 보면 내용을 확인할 수 있네요! (메일을 참고하여 "루이스딘"과 거래한 내역이 있는지 살펴보세요!!)

   

   
6. 문제를 보면 파일명을 변경하였다고 합니다. 파일명 변경 내용을 확인하기 위해서는 NTFS Log Tracker를 활용해서 확인하는 것을 추천합니다. 루트디렉토리에서 $LogFile, $MFT, $UsnJrnl$J 파일을 추출 한 뒤 NTFS Log Tracker에 넣고, 찾을 파일을 검색하여 봅시다. ($LogFile 에서 검색, $UsnJrnl 에서 모두 검색 해봅니다.) - NTFS Log Tracker 사용법 > 6. 파일명 변경 내역(NTFS Log) - NTFS Log Tracker 연습하기 > 3. NTFS 로그 분석 연습

   

   결과를 보면 나오는데$UsnJrnl 의 FileReferenceNumber를 값을 이용하여 파일명이 변경되기 전에 이력을 살펴 볼 수 있습니다. (아쉽게도 $LogFile 에는 발견되지 않는듯 하네요.)

   

   Search 에서 $UsnrJrnl 의 FileReferenceNumber 값을 검색하여 결과를 보면 파일명 바꾸기 전의 파일명을 알 수 있습니다. (BB은행.xlsx)

   
7. 또한 해당 파일의 Zone.Identifier를 살펴보면, 구글 드라이브에서 다운로드한 것을 확인할 수 있습니다.

   

   인터넷 아티팩트 분석 결과에서 크롬 다운로드 이력에서 해당시간에 해당파일을 다운받은 것을 알 수 있습니다.

   

• 지금까지의 분석을 토대로 답안작성에서 요구하는 부분을 정리합니다.

1. 비트락커로 암호화되어 있는 파일시스템이 존재합니다. 비트락커를 복구 후 아래의 답변하시오. 8-1. 비트락커의 식별자와 복구키는 무엇인가? 8-2. 비트락커 복구키가 원래 존재 하였던 경로는 무엇인가?

8번 분석 과정 (직접 먼저 해보시고 참고 해보세요!)

1. 여러 파일을 살펴보고 휴지통도 한번 살펴보겠습니다. 휴지통에 복구키가 있는 것을 확인할 수 있습니다. 비트락커의 식별자, 복구키를 확인 할 수 있습니다.

   

   만약 시험에서 전체 파일 대상으로 Name 정렬 한 뒤 bitlocker를 검색하거나, 휴지통 등에서도 발견되지 않을 경우 키워드 검색을 해야 할 것입니다. 키워드의 경우 단순 bitlocker 할 경우 불필요한 것도 발견될 수 있으니 "BitLocker 드라이브" 를 유니코드 한국어를 포함한 검색하게 되면 발견될 수 있을 것 입니다. (다만 시간이 상당히 소요될 수 있겠죠!)

2. 휴지통에서 해당 파일이 있던 원래 파일의 경우 $I~~로 시작하는 파일에서 확인이 가능합니다. $I~ 로시작하는 파일을 보면 EnCase에서 유니코드 변경하여 경로를 확인할 수 있으며, 파일 추출 후 시그니처를 "FF FE"로 변경 후 메모장으로 열면 한글 경로도 확인이 가능합니다.

   
3. 복호화 키를 찾았기 때문에 비트락커 해제를 해봅시다. EnCase의 Evidence로 돌아 간 뒤 Rescan을 선택 시 비트락커 암호화 해제를 할 수 있는 창이 나오고 Recovery Password 에서 식별자 선택 후 복구 키를 입력하여 암호해제를 해봅시다.

   
4. 비트락커가 해제된 파일시스템 구조를 살펴볼 수 있습니다.

   

   다만 이 파일시스템의 경우 프로세싱이 되어 있지 않을 수 있습니다. 구조를 보면 윈도우가 없는 단순 파일만 있는 형태이기 때문에 해당 드라이브의 주요폴더를 체크한 뒤 우클릭 - Entries - Hash/sig Selected를 선택하여 빠르게 해시, 시그니처 분석등을 할 수 있습니다.

   
5. 정리하면 - 식별자 : 68E0564C-B535-48AF-920C-06FB97B42452 - 복구키 : 273273-202334-697807-597663-602459-103411-510455-490479 - 비트락커 복구키가 원래 존재 하였던 경로 > C:\Users\web-bit\Desktop\BitLocker 복구 키 68E0564C-B535-48AF-920C-06FB97B42452.TXT

1. 공모한 사람의 의뢰를 받고 특정 파일을 외부로 유출하였다고 한다. 외부로 유출한 파일은 무엇으로 의심되며, 어떤 IP로 유출하였는가?

9번 분석 과정 (직접 먼저 해보시고 참고 해보세요!)

1. 먼저 외부 유출에 사용한 프로그램을 의심해봐야 하는데 알드라이브라는 것을 다운 받았고, 실제 설치까지 되어 있습니다.

   
2. 최근에는 AppData에 관련 데이터가 저장되는 경우가 많습니다. 해당 부분을 살펴보면 ALDrive가 설치되어 있고, 접근해서 파일 5개를 전송한 것을 확인할 수 있습니다. 유출한 IP는 “172.30.1.43” 으로 확인되네요!

   
3. 유출했을 것으로 보이는 파일들이나 파일 하나(vol4)는 덮어 써져있고, 5개도 아닌 것을 알 수 있습니다.

   

   egg 파일의 경우 압축파일이며, 분할압축한 것으로 보인다. 즉, 1~5번 파일이 있어야 하는데 3번이 보이지 않습니다.

4. exe 실행 파일 중에 시그니처가 정상이 아닌 것을 볼 수 있으며, 해당 시그니처를 보면 EGG로 압축파일의 시그니처로 볼 수 있습니다.

   
5. 우선 압축파일로 보이는 것들을 살펴봅시다. 분할압축을 하였다면, 동일한 용량이어야 하나, 2배인 것을 알 수 있습니다.

   

   해당 파일을 추출한 뒤 HxD로 한번 살펴보겠습니다. 시그니처를 동일하게 검색하면, 중간에 다시 EGG로 시작하고 있습니다.

   
6. 혹시 3번, 4번을 하나의 파일로 만든거 아닐까요? 중간부터 마지막까지 분리해서 파일을 만들고, 파일명을 다른 것과 동일하게 한 뒤 번호만 3, 4번으로 지정해 보겠습니다.

   

   압축을 풀어보려고 하는데 에러가 발생합니다.

   
7. 파일이 이상할 때에는 무조건 HxD로 열어보겠습니다. vol1 번을 HxD로 살펴보겠습니다. 시그니처가 훼손 되어 있네요.

   
8. 다른 egg 파일을 참고하여 정상 시그니처로 수정 후 압축을 해제하여 봅시다. 정상적으로 압축이 해제 됩니다.

   

   
9. 만약, 3,4번을 반대로 이름을 설정하여 압축해제 시 일부만 보여지게 될 것입니다.

   
10. 정리하면 작업용.vol1.egg~작업용.vol5.egg를 알드라이브로 전송하고, 3,4번을 합쳐서 파일명을 변경한 것으로 보입니다. 비트락커 드라이브에서 $LOG_FILE, $MFT 를 추출한 뒤 NTFS Log Tracker로 살펴봅시다. 아쉽게도 $UsnJrnl:$J는 비활성화 되어 있는지 보이지 않기 때문에 $LOG_FILE, $MFT만 가지고 분석해봅시다. Search 에서 파일명에 확장자 egg로 검색하여 봅시다. 여기서 3,4번도 vol1,2와같은 VCN을 가지게 됩니다. 동일한 Target VCN 값을 가진다는 것은, 해당 파일들이 논리적으로 동일한 위치를 공유하거나 동일한 클러스터 그룹 내에서 작업이 수행되었음을 나타냅니다. vol5만 다른 Target VCN 값을 가지는 것은 분할 압축 파일 생성 과정에서 마지막 파일로 클러스터 단편화등이 일어나서 다음 Target VCN값을 가진 것으로 보입니다. (시험에서 이러한 내용을 아는 것은 중요한 것은 아닙니다.)

    
11. Target VCN을 검색 해보면, 작업용.vol3.egg가 파일명이 변경된 것을 알 수 있게 됩니다.

    
12. 알드라이브를 이용하여 172.30.1.43으로 작업용.vol1.egg ~ .vol5.egg이 유출된 것으로 보입니다.

1. 해당 가상머신에서 프린트를 시도한 파일이 있었다고 한다. 10-1. 프린트한 파일명은 무엇인가? 10-2. (심화) 프린트한 내용은 무엇인가?(그림 파일 형태)

10번 분석 과정 (직접 먼저 해보시고 참고 해보세요!)

1. 먼저 프린터의 경우 Windows\System32\spool\PRINTERS\ 폴더에 프린터 시 필요한 임시 파일이 생성됩니다.

   
2. SPL 파일을 hex, text에서 유니코드로 살펴보면 출력 시도한 파일명을 확인할 수 있습니다.

   
3. (심화) 프린터마다 설정이 다르기 때문에 모든 경우에 해당하는 것은 아니나, SHD 파일에서 EMF 구조의 경우 출력 내용을 확인할 수 있습니다. EMF 앞으로 41글자 앞의 01 부분이 헤더가 되면 Decode에서 그림파일 형태로 출력물을 확인할 수 있습니다.

   

   EMF 파일의 시그니처가 사실상 01 00 00 00 으로 시작하고 41바이트 뒤에 EMF(시그니처) 가 있는 구조로 보시면 됩니다. 파일 추출 후 01 앞으로 내용을 지우고 그림판에서 내용 확인이 가능합니다.

   

   

• 프린터 구조에 따라 EnCase에서 바로 보일 수도 있고 아닐 수도 있습니다. EnCase에서 EMF의 시작부분 01 00 00 00 부분을 정확히 지정하여 Decode - Picture로 확인하면 미리보기가 가능하고, 파일을 추출 한 뒤 EMF 앞에 부분을 날리고 시작부분을 정확히 저장하면 그림판에서도 확인이 가능합니다. 다만 이러한 것은 사실상 EMF 구조를 외우고 있어야 하는 것으로 굳이 외우지는 않으셔도 무방합니다.(시험에 나올 가능성 매우 적음)

• 실제시험에서는 이 경로에 EMF 구조가 아닌단순 그림 파일 형태일 수도 있습니다.

3-3) 주관식 및 분석 보고서 작성

1. 분석 보고서를 작성하고, 증거 관련 파일을 파일 형태 그리고 논리이미징 형태로 제출하시오.

   • 답안 작성 참고

   • 논리이미징 만들어보기 참고

3-4) 추가 심화 문제

• webui라는 오픈소스 아티팩트 분석 관련 연습문제로 시험 유형에는 해당하지 않는 문제 입니다.

1. 생성형 이미지를 사용한 프롬프트와 모델명을 확인할 수 있는 파일은 무엇인가?

2. 사용한 모델을 다운로드한 출처는 어디인가?

3. Webui 의 경우 이미지 생성 후 특정 폴더에 생성된 이미지를 자동 저장한다. 해당 폴더명은 무엇인가?

12~14번 분석 과정 (직접 먼저 해보시고 참고 해보세요!)

[12번 문제] > log.csv

1. stable-diffusion-webui를 살펴보면 log 폴더가 있고, 해당 폴더에 log.csv를 보면 prompt, model_name 등이 포함되어 있는 것을 볼 수 있습니다.

   
2. 실제로 파일을 추출하여 열어보면 프롬프트와, 모델명을 확인할 수 있습니다.

   

[13번 문제] > https://civitai.com

1. models 폴더를 살펴보면 Stable-diffusion 폴더를 찾을 수 있고, 모델명을 확인할 수 있습니다. 모델명에 해당하는 파일의 Zone.Identifier를 살펴보면 다운로드 했던 사이트도 확인이 가능 합니다.

   

[14번 문제] > outputs 폴더

1. outputs 폴더를 살펴보면 날짜별로 생성한 이미지들을 확인할 수 있습니다.

   

4. [작성 중] 답안 작성

답안 저장

• 문제지에서 요구하는 형식에 맞춰서 답안 작성 문서 파일, 주요 증거 파일을 저장합니다.

  
• 참고로 시험 합격여부에 거의 영향은 없을 것이지만 증거제출용 USB에 먼저 문서파일, 폴더를 저장한 뒤에 맨 마지막에 FTK Imager에서 주요 증거파일을 USB 파일 저장 폴더에 바로 추출합니다. EnCase에서 우클릭 - Entries - Copy로 추출한 뒤 저장할 때 USB에 주요 증거파일 폴더에 추출하여도 동일합니다.

답안 작성(참고로만 활용)

• 정답은 아니라 이런 식으로 답안 작성을 하면 된다는 정도로만 활용하시고 내용을 쉽게 작성 합니다. 다만 가장 중요한건 문제에서 요구하는 파일이나 내용, 키워드가 포함되어야 합니다.

• 1번 문제.rtf

• 2번 문제.rtf

• 3번 문제.rtf

• 4번 문제.rtf

• 5번 문제.rtf

• 6번 문제.rtf

• 7번 문제.rtf

• 8번 문제.rtf

• 9번 문제.rtf

• 10번 문제.rtf

[작성중]논리이미징 만들어보기

아직 시험에 출제된 적은 없으나 선별수집 시 파일들 만을 대상으로 논리이미징 하는 방식입니다.

다만, 시험에서 요구하지 않는 경우 불필요하게 포함할 필요는 없을 수 있기 때문에 참고로 알아 둡시다.

1. EnCase에서 증거로 제출할 파일들을 선택 후 우클릭 - Bookmark - Selected Items를 선택 한 뒤 북마크 폴더에 추가합니다.

   폴더를 새로 생성하여 저장하도록 합니다.

   

   파일을 체크 후 우클릭 Review Package - Export를 선택 한 뒤 Lx01 파일로 추출할 수 있습니다.

   불필요한 tag 관련은 모두 체크를 해제합니다.

   논리이미지를 Evidence에 추가하면 내용 확인이 가능합니다.

2. FTK Imager에서 주요 증거 파일을 선택 후 우클릭 - Add to Custom Content Imager(AD1)을 통해 추가 후 Create Image 를 선택합니다.

   Add를 통해 저장할 경로를 지정 후 Start하여 이미지 생성 합니다.

   

   FTK Imager 에서 해당 이미지를 추가하면 추가한 파일을 확인할 수 있습니다.