self study

Startup 디스크 포렌식 실습

악성코드 감염 PC 복구

사용 툴: FTK Imager, HxD, Python

※ 실제 PeTya 랜섬웨어 감염으로 인한 환경과 유사하다고 함

- 해당 실습은 생각하면 어렵고, 복구 방법에 초점이 되어있기 때문에 실습 그대로 진행해야함

- 해당 구조를 어떻게 만든건지 파악하고자 하면 PeTya 랜섬웨어 디버깅이 필요함...(복구 초점으로 Go)

- 위 그림은 실습파일의 전체 구조가 아닌 VMware 관련 헤더?를 제거한 후 FTK Imager에서 확인할 수 있는 구조

- VMware를 이용하여 부팅 시 위와 같은 화면이 나타남

- 감염 후 MBR 구조를 복구하기 위한 방법

1) XOR 암호화된 MBR을 XOR 복호화하여 MBR 획득

· 0x7000 위치에서 512byte 복사 후 0x37로 XOR 연산 후 정상 MBR 복원

· 정상 MBR을 0x7000으로 덮어씀

2) 악성 데이터가 덮어 쓰인 영역을 모두 0으로 채움

· 0x7200 옵셋에서 ~까지 모두 0으로 채움

1) XOR 암호화된 MBR을 XOR 복호화하여 MBR 획득

FTK Imager로 XOR된 기존 MBR

- FTK Imager에서 0x7000위치에서 512바이트 hex값을 복사하여 HxD를 열어 붙여넣음

악성 MBR

- 실습 과정에서 XOR 연산을 일괄적으로 할 수 있도록 변환 파일을 제공하고 이를 이용하여 정상 MBR 획득

복구된 MBR

- 정상 MBR 획득 후 HxD로 vmdk 파일을 열어 실제 위치로 덮어써야 하는데 여기서 중요한 건 어디다 붙여넣어야 하는지 찾아야 함

- 위치를 찾는 방법은 FTK Imager에서 악성 MBR 위치(0x0) 데이터 일부를 복사하여 HxD로 검색하여 찾음

FTK Imager에서 악성 MBR 일부 문자열 복사

HxD에서 복사된 일부 문자열 검색

검색 후 위치

- 위치(0x790000)에 획득한 정상 MBR 데이터를 붙여넣으면 1단계 끝

- 단순 실습이라 hex값과 친해지기 위해 파이썬 코드를 만들어봄

- 16진수 2자리를 받아서 0x37 값으로 XOR 연산을 일괄적으로 할 수 있도록 짬

  (방법: 악성 MBR 512바이트를 hex값으로 복사 후 txt 파일로 저장 후 파이썬 코드 실행하면 result.txt 떨어짐)

2) 악성 데이터가 덮어 쓰인 영역을 모두 0으로 채움

- 모두 0으로 덮어쓰는 이유는 MBR 시작위치에 첫 번째 파티션(BR영역)이 시작되기 전까지의 모든 영역은 예약영역으로 모두 0으로 고정되어 있기 때문

- MBR의 위치는 15488 섹터이고 15489의 시작 옵셋(0x790200) - 15,545 섹터 옵셋(0x797201)까지 모두 0으로 변환

- 마지막 설명이 좀 부족하긴 하지만 단순히 넣는 방법을 실습해보았음

정리

1) 툴 사용에 조금 더 익숙해지고, 여러 사례를 보는 입장이기 때문에 단순 실습이라 해도 도움이 됨

2) 의문점: 복구된 MBR과 BR의 떨어진 섹터는 0x800인데 이를 계산하면 0x890000 = 0x790000 + 0x100000 이어야 함(문제를 만드는 과정에서 발생된 건지... 책에서도 갑자기 단순하게 0으로 넣기만 하라고 나와서 당황)

Startup 디스크 포렌식 실습

악성코드 감염 PC 복구

사용 툴: FTK Imager, HxD

※ 실제 3.20 사이버테러 때 사용된 악성코드로 감염시킨 환경은 아님

- 해당 실습은 메타데이터 부분을 맡고 있는 MBR, VBR이고 이를 복구 시키기 위한 실습

- 실습 파일은 파티션 2개로 아래와 같은 구조로 되어있고, MBR, VBR01, VBR02(붉은박스) 모두 "HASTATI." 문자열로 덮어쓰여짐

제공된 파일이 VMware 파일이므로 HxD로 읽을 경우 섹터 계산이 좀 복잡하여 FTK Imager를 이용하여 계산

가. MBR 복구

· MBR 복구: 제공해준 파일(446 부트코드 제공) 나머지 파티션 정보를 입력

· 파괴된 MBR(Sector 0)

· 제공된 MBR과 붉은 박스를 채워넣어야 하고 해당 데이터를 입력하기 위해 부팅여부, 파티션타입, VBR 시작위치, 파티션의 섹터 수를 구해야 함

· 추가로 CHS 타입을 쓰지 않기 때문에 0으로 표기

나. VBR01 복구

· VBR 복구: 파티션 타입을 알아낸 후 VBR 위치 찾기

· 파괴된 VBR01(Sector 2048)

· 첫 번째 VBR의 백업본을 찾기 위해서 3번째 "HASTATI." 문자열이 시작되는 섹터의 전 섹터임(가장 상 위에 있는 그림의 첫 번째 화살표)

· 백업 VBR01(Sector 206848)

다. VBR02 복구

· VBR 복구: 파티션 타입을 알아낸 후 VBR 위치 찾기

· 파괴된 VBR02(Sector 206848)

· 두 번째 VBR은 NTFS 시그니쳐(EB 52 90 4E 54 46 53 20)를 이용하여 찾음(여러 방법이 있을 수 있음)

· 해당 실습 파일엔 정말 많은 해당 시그니쳐가 존재하고 필자는 가장 마지막에 있고, 시그니쳐가 섹터의 첫 번째 위치하는 곳으로 정함

· 백업 VBR02(Sector 125827072)

· 아래 그림은 시그니쳐를 찾으면서 발견된 섹터들...(다수 존재)

첫 번째 그림은 그럴듯 하나 주위에 데이터 존재하여 일단 패스, 두 번째 그림은 시그니쳐 위치가 달라서 패스

라. MBR에 입력할 데이터 계산

★ 모두 VBR에서 6섹터 떨어진 곳에서 백업본이 존재하는지 확인한 결과 데이터가 존재하지 않아 FAT가 아닌 것으로 확인(둘 다)

가) 첫 번째 VBR 필요 데이터

   - 부팅 가능: 0x80

   - 파티션 타입: NTFS(0x07)

   - VBR 시작 섹터 0x800(2048)

   - 첫 번째 파티션 섹터 수: VBR 백업본 마지막 offset(0x6500000) - VBR offset(0x100000) / 1섹터 크기(0x200) = 0x32000

나) 두 번째 VBR 필요 데이터

   - 부팅 가능: 0x80

   - 파티션 타입: NTFS(0x07)

   - VBR 시작 섹터 : VBR offset(0x6500000) / 1섹터 크기(0x200) = 0x32800

   - 두 번째 파티션 섹터 수: VBR 백업본 마지막 offset(0xefff00000) - VBR offset(0x6500000) / 1섹터 크기(0x200) = 0x77CD000

이를 MBR에 아래와 같은 위치에 입력

정리

1) MBR의 중요 필드 데이터 입력(부팅가능, 파티션 타입,  VBR 시작 위치, 파티션 섹터 수)

2) 파티션의 Filesystem이 무엇인지 추측

3) 섹터 계산

Startup 디스크 포렌식 실습

FAT32와 마찬가지로 Volume Boot Record의 Overwrite 된 데이터를 백업 데이터를 이용하여 복구

- NTFS MBR

☞  07: NTFS를 나타내는 Signature

☞  00 00 00 3F(Little Endian): MBR로부터 떨어진 BR의 위치(시작지점)

☞  00 3C 3F C0(Little Endian): 파티션의 섹터 수(파티션의 끝 위치가 아님)

- NTFS Boot Record

☞ BR의 시작위치로 FAT32 실습했던과 마찬가지로 다른 문자열에 의해 Overwirte 됨

☞ NTFS의 BR 백업은 해당 파티션 섹터의 마지막에 위치

☞ MBR 그림의 3번 째 붉은 박스에 해당 파티션의 섹터 수를 이용하여 BR 백업 데이터를 찾음

☞ 파티션의 섹터 수는 003C3FC0(3,948,480(10진수))고, 파티션의 섹터 수이기 때문에 첫 BR부터 해당 섹터수를 더해야 파티션의 끝을 알 수 있음

☞ 00 00 00 3f + 003c3fc0 = 003C3FFF (3,948,543)

☞ 해당 섹터 수에서 -1을 함(이유는 섹터는 0부터 시작)

- NTFS Backup Boot Record

☞ 해당 섹터를 복사하여 붙여넣기 후 저장

Startup 디스크 포렌식 실습 #1 (FAT32)

- FAT32 파일시스템 파일 카빙(BR 복구)

FTK Imager를 이용하여 이미지를 연 후 Boot Record 데이터가 "DISK Fail YAM!" 문자열로 overwrite되어 문제 발생

※ HXD 툴 활용 팁으로 이미지 파일은 단순 open이 아닌 해당 경로를 이용

  - 파일을 open 할 때 섹터 크기를 지정할 수 있고 512byte 선택

MBR: 붉은 박스가 첫 파티션의 시작위치(섹터)

63번째 섹터 위치로 이동

- 해당 Boot Record의 데이터가 없고 "DISK Fail YAM!" 문자열로 덮어씌여진 것을 확인 할 수 있음

- 해당 데이터를 복구하기 위해선 백업된 BR(BR 시작위치 + 6)을 복사하여 해당 위치로 덮어씀

Hxd 툴을 이용하여 백업된 BR(BR 시작위치 + 6)의 위치로 이동

백업된 BR을 복사하여 MBR에 정의된 첫 번째 파티션 BR 위치에 데이터를 붙여넣기

- 저장 후 FTK Imager 실행

- 파일카빙 완료

- 공부내용

1) MBR에 정의된 BR 위치 등

2) BR과 백업된 BR의 위치 등

 ㄴ http://wrkk.tistory.com/24 (BR 백업 위치 간략)

3) 툴 활용

- 침해사고 카테고리

1) 대규모(동시에 다수의 서버 공격)

2) 분산화(다수의 서버에서 목표시스템을 공격)

3) 대중화(해킹관련 정보의 손쉬운 획득)

4) 범죄적 성향(금전적 이익, 산업정보 침탈, 정치적 목적 등)

- 침해사고 대응 절차 요약

(https://www.linux.co.kr/home2/board/subbs/board.php?bo_table=lecture&wr_id=1691&page=&sca=7)

1) 사고 전 준비 과정 : 사고가 발생하기 전 대응팀 및 조직적인 대응 준비

2) 사고 탐지 : 침해사고 식별

3) 초기 대응 : 타임라인 기반 사고 정황 기록, 침해사고 관련 부서 통지

4) 대응 전략 체계화 : 대응 전략 결정 및 승인, 초기 조사 결과 토대로 소송이 필요한지 유무 결정과 수사기관 공조 여부 판단

5) 사고 조사 : 데이터 수집 및 분석 수행. 언제, 누가, 어떻게 사고가 일어났고 피해확산 및 사고 재발을 어떻게 예방할지 결정

6) 보고서 작성 : 의사 결정자가 쉽게 이해할 수 있도록 정확한 보고서 작성

7) 해결 : 차기 유사공격 식별 및 예방 보안정책 수립, 절차 변경, 사건 기록, 장기 보안 정책 수립, 기술 수정 계획수립 등 결정

- 침해사고 대응절차 상세

■ 사고 탐지

 ▷ 사고 탐지시 확인해야 할 세부항목

  1) 현재 시간과 날짜

  2) 사건보고 내용과 출처

  3) 사건 특성

  4) 사건이 일어난 일시

  5) 관련된 하드웨어, 소프트웨어 목록(EX FW, IDS, IPS... 등)

  6) 사고 탐지 및 사고 발생 관련자의 네트워크 연결 지점

■ 초기 대응

 ▷ 초기 대응 중요임무

  : 현재 발생한 사건이 업무 및 서비스에 영향을 미치는지 검증 후 사고를 어떻게 처리할 지 결정(대응전략 수립)

   1) 정오탐 구분

   2) 침해된 시스템에 적당한 대응책이 있는지

   3) 사건의 유형이 무엇인지

   4) 사고로 인한 잠재적인 업무 영향

■ 대응전략 수립

 ▷ 환경의 전체적인 고려

  1) 침해당하거나 도난당한 정보가 얼마나 민감

  2) 시스템과 사용자의 업무중단 시간은 어느정도

  3) 어느 정도의 경제적 피해

  .....등

 ▷ 적절한 대응 고려

(http://blog.pages.kr/1274)

■ 사고 조사

 ▷ 수집된 데이터 처리

(http://blog.pages.kr/1274)

   1) 네트워크 기반 증거 : 사고발생 관련 네트워크 장비들에 대한 로그 수집

   2) 호스트 기반 증거 : 휘발성 데이터 먼저 수집 후 위와 같은 필요 데이터 수집

                               (http://wrkk.tistory.com/entry/%EB%93%A4%EC%96%B4%EA%B0%80%EB%A9%B02 참고)

   ※ 데이터 수집시 시스템 날짜와 시간 고려