정보보안 엔지니어링

TCP와 UDP를 이용한 스캔은 시스템 자체의 활성화 여부가 아닌 포트 스캔을 한다. 물론 포트가 열려 있다면 해당 시스템은 활성화되어 있는 것이다.

1. TCP Open 스캔

TCP를 이용한 가장 기본적인 스캔으로는 Open 스캔이 있다. 먼저 동작하리라고 예상하는 포트에 세션을 생성하기 위한 SYN 패킷을 보낸다. 포트가 열린 경우 서버에서 SYN + ACK 패킷이 돌아오고, 공격자는 다시 ACK 패킷을 보낸다.

(a)에서 볼 수 있듯이 Open 스캔은 3-way-handshake 과정을 모두 거친다. 따라서 상대방 시스템에 로그가 남는다. 포트가 닫혀 있는 경우에는 (b)처럼 공격자가 SYN 패킷을 보내면 RST+ACK 패킷이 돌아오고, 공격자는 아무 패킷도 보내지 않는다.

Open 스캔 중에는 Reverse Ident라는 방법이 있다. 이 방법은 세션을 성립한 상태에서 원격지 서버에서 데몬을 실행하고 있는 프로세스의 소유권자를 확인하기 위한 것이다.

* 데몬 : 시스템의 사용자 인터페이스에는 나타나지 않지만, 서비스를 요청하면 이에 반응할 수 있도록 항상 실행되고 있는 프로그램을 말한다.

위 그림에서 확인할 수 있듯이 Reverse Ident 스캔은 세션을 성립한 후에 113번 포트를 연다. 113번 포트는 사용자 인증을 위해 사용되지만, 이 서비스는 보통 중지되어 있다.

2. 스텔스 스캔

스텔스 스캔은 세션을 완전히 성립하지 않고 공격 대상 시스템의 포트 활성화 여부를 알아내기 대문에 공격 대상 시스템에 로그가 남지 않는다. 따라서 공격 대상의 시스템 관리자는 어떤 IP를 가진 공격자가 자신의 시스템을 스캔했는지 확인할 수가 없다. 스텔스 스캔은 이처럼 단순히 로그를 남기지 않는 것만이 아니라, 공격 대상을 속이고 자신의 위치를 숨기는 스캔 모두를 통칭한다.

TCP Half Open 스캔이 대표적이다. 스캔의 시작은 Open 스캔과 같다. 먼저 SYN 패킷을 보낸다. 포트가 열린 경우 서버는 SYN+ACK 패킷을 보내고 공격자는 즉시 연결을 끊는 RST 패킷을 보낸다. 포트가 닫힌 경우는 Open 스캔과 같다.

스텔스 스캔의 다른 형토로 FIN 패킷을 보내는 방법이 있다. 포트가 열린 경우에는 응답이 없고, 포트가 닫힌 경우에만 RST 패킷이 되돌아 온다.

NULL과 XMAS 패킷을 보내는 때도 이와 같은 결과를 얻을 수 있다. NULL은 플래그 값을 설정하지 않고 보낸 패킷을 말하고, XMAS는 ACK, FIN, RST, SYN, URG 플래그 모두를 설정하여 보낸 패킷을 말한다. XMAS 패킷은 크리스마스 선물처럼 푸짐하게 모두 준다는 의미로 붙여진 이름이다.

또 다른 방법으로 ACK 패킷을 보내는 방법이 있다. 이때 포트 하나가 아니라 모든 포트에 ACK 패킷을 보낸다. ACK 패킷을 받은 시스템은 이에 대한 RST 패킷을 보내고 공격자는 RST 패킷의 TTL 값과 윈도우의 크기를 분석한다. 포트가 열린 경우 TTL 값이 64 이하인 RST 패킷이 돌아오고, 윈도우가 0이 아닌 임의의 값을 가진 RST 패킷이 돌아온다. 포트가 닫힌 경우에는 TTL 값이 운영체제에 따라 일정하게 큰 값이며, 윈도우의 크기가 0인 RST 패킷이 돌아온다.

TCP 패킷을 이용한 스캔 역시 ICMP 스캔처럼 모든 시스템에 동일하게 적용되는 것은 아니다. 이러한 스캔 방법은 최근 시스템에는 거의 적용되지 않는다고 생각해도 될 만큼 많이 알려졌다. 하지만 SYN 패킷을 이용한 스캔 방법은 세션을 성립하기 위한 정당한 패킷과 구별할 수 없기 때문에 아직도 유효하며 아주 효과적이다.

TCP를 이용한 또 다른 스텔스 스캔 방법으로는 TCP 단편화가 있다. 이 방법은 크기가 20바이트인 TCP 헤더를 패킷 두 개로 나누어 보내는 것이다. 첫 번째 패킷에 출발지 IP주소와 도착지 IP주소를, 두 번째 패킷에 스캔하고자 하는 포트 번호가 있는 부분을 보낸다. 첫 번째 패킷은 TCP 포트에 대한 정보가 없기 때문에 방화벽을 통과하고, 두 번째 패킷은 출발지 주소와 목적지 주소가 없어 방화벽을 지날 수 있다.

1. 스캔에 대한 이해

스캔은 서비스를 제공하는 서버의 작동 여부와 서버가 제공하는 서비스를 확인하기 위한 작업이다. TCP 기반의 프로토콜은 기본적으로 요청을 보내면 응답을 전달해 준다. 스캔은 ㄴ방화벽과 IDS( 침입 탐지 시스템 )을 우회하기 위해 발전한 스캔은 종류가 무척 다양하다.

2. Ping

서버의 동작 여부를 알아보는 가장 기본적인 스캔은 ping을 이용하는 것이다. 검사하고자 하는 네트워크에서 동작하는 서버를 찾아내는 일은 공격 대상 네트워크에서 공격 대상의 IP 주소를 결정하는 데 무척 중요하다.

ping은 네트워크와 시스템이 정상적으로 작동하는지 확인하기 위한 간단한 유틸리티로, ICMP를 사용하며, 기본적으로 TCP/IP 네트워크에서 사용된다.

넷웨어와 같이 다른 프로토콜 체제를 쓰는 네트워크에서는 ping 유틸리티도 다르며, 모든 네트워크에 ping이 있는 것은 아니다. 

* 넷웨어 : 가장 광범위하게 설치되었던 노벨의 네트워크 서버 운영체제다. 초기 넷웨어는 대기업이나 중소기업용 근거리 통신망에서 노벨의 제품 간 통신에 주로 사용했다. 그후 대규모 네트워크의 필요성이 커지자 새롭게 설계되었다.

* ICMP : 호스트 서버와 인터넷 게이트웨이 사이에서 메시지를 제어하고 오류를 알려주는 프로토콜이다.

3. ICMP 스캔

ICMP를 이용해 공격 대상 시스템의 활성화 여부를 알아보는 방법은 다음 네 가지다.

Ⅰ Echo Request( Type 8 )와 Echo Reply( Type 0 ) 이용하기

Ⅱ Timestamp Request( Type 13 )와 Time Reply( Type 14 ) 이용하기

Ⅲ Information Request( Type 15 )와 Information Reply( Type 16 ) 이용하기

Ⅳ ICMP Address Network Request( Type 17 )와 ICMP Address Network Reply( Type 18 ) 이용하기

가장 일반적인 방법은 Ⅰ을 이용하는 것이며, 일반적으로 옵션 없이 ping 유틸리티를 사용하면 된다.

① ICMP 패킷의 길이를 나타내는 것으로, 운영체제마다 보내는 바이트의 길이가 다르다. 유닉스와 리눅스와 같은 시스템은 위 그림처럼 대부분 56바이트 ICMP Echo Request 패킷을 생성하여 보낸다. 윈도우 시스템은 32바이트이다. 각 바이트의 내용은 의미없는 알파벳으로 채워진다.

② 공격 대상에서 보내온 ICMP Echo Reply 패킷의 크기이다.

③ TTL( Time To Live ) 값으로, 라우팅 정보가 잘못되어 패킷이 네트워크를 무한대로 돌아다니지 않도록 최초 라우터를 제외한 라우터를 지날 때마다 값이 1씩 줄어든다. TTL 값도 운영체제에 따라 조금씩 다르다.

줄어든 TTL 값으로 원격지 시스템이 라우터 몇 개를 거쳐서 도달했는지 알 수 있다. 세계 어느 곳에 있는 시스템일지라도 20여개 이상을 지나는 경우는 드물다. 보통 기본 TTL이 64라고 생각하는데, TTL 값이 55라면 자신의 경계라우터를 포함해 라우터 12개를 지나 목표 시스템에 도달한 것이다.

④ Echo Request 패킷을 보낸 후 Reply 패킷을 받기까지의 시간이다.

⑤ Request 패킷의 개수, Reply 패킷의 개수, 손실된 패킷의 개수를 보여준다.

⑥ Request 패킷을 보낸 후 Reply 패킷이 오기까지의 시간 정보를 알려준다.

라우터나 방화벽 등에서 ICMP Echo Request 패킷을 막는 경우가 있는데, 이때 이용할 수 있는 방법으로 세 가지를 생각할 수 있다.

첫 번째 방법은 Ⅱ를 이용하는 것이다. Timestamp Request 패킷은 원격지 시스템의 현재 시각을 알아보기 위한 것이다. 송신자가 패킷을 보낸 시각과 수신자가 패킷을 받은 시각, 송신자가 수신자에게 전송하는 동안 걸린 시간으로 공격 대상의 현재 시스템 시각을 알 수 있다. 하지만 Timestamp Request 패킷에 Reply 패킷을 돌려보내는 시스템이 시간만 알려준다고 생각할 수는 없다. 상대 시스템의 Reply 패킷이 돌아온다는 것은 상대 시스템이 활성화 되어 있음을 말하는 것이다.

두 번째 방법은 Ⅲ을 이용하는 것이다. 원래 Information Request와 Reply는 메인 프레임의 단말기처럼 부팅할 때 자신의 디스크가 없는 시스템이 스스로 IP를 설정할 수 있도록 하는 패킷으로, 자신이 네트워크를 찾기 위해 개발되었다. 기본 목적은 RARP, DHCP와 같은 프로토콜과 같지만 다른 프로토콜을 이용한 방법에 비해 원시적이라고 할 수 있다.

마지막으로 Ⅳ를 이용하는 것이다. 이 패킷 역시 Information Request 패킷처럼 단말기가 부팅될 때 자신이 속한 네트워크의 서브넷 마스크를 알기 위해 보낸다.

ICMP 패킷을 이용한 앞의 세 가지 방법이 모든 운영체제에서 작동하지는 않는다. 운영체제에 따라 일부만 지원하므로 지원 여부를 살펴보면 다음과 같다.

ICMP를 이용한 여러 가지 ping은 시스템 하나를 조사하기에는 적절하지만 큰 네트워크에서 활성화 시스템을 찾는 데는 그다지 효과적이지 않다. 네트워크 전체에서 활성화 시스템을 찾는 일을 스위핑( Sweeping )이라고 한다. 스위핑은 검색하고자 하는 네트워크에 브로드캐스트 ping을 보내거나 자동화 도구를 이용해 특정 범위의 네트워크에 ping을 보낸다.

1. FAT( File Allocation Table )

FAT은 디지털 카메라 등에 장착되는 대부분의 메모리 카드와 수많은 컴퓨터 시스템에 널리 쓰이는 컴퓨터 파일 시스템 구조이다. FAT 파일 시스템은 상대적으로 간단하기 때문에 플로피 디스크, 플래시 메모리 카드, 디지털 카메라 및 다른 수많은 휴대용 기기에서 흔하게 볼 수 있다. FAT의 성능은 다른 대부분의 파일 시스템에 견주어 좋지 않은 평을 받는다. 그 까닭은 운영 시간을 낭비하게 만드는 너무나도 단순한 자료 구조를 이용하고 조그마한 파일이 많이 있으면 디스크 공간을 잘 활용하지 못하기 때문이다.

2. FAT32

2기가바이트 이상의 하드디스크를 지원하며, 윈도우 95 OSR2부터 이 파일 시스템을 사용할 수 있다.

FAT32에서는 하나의 파일은 최대 4기가바이트 - 1바이트의 용량을 가질 수 있다. 하나의 파티션이 최대 8테라바이트의 용량을 가질 수 있고, 최대 268,435,437개의 파일을 담을 수 있다. 윈도우 98, 윈도우 Me와 같은 구형 운영체제나, 리눅스, OS X와 같은 운영 체제에서 윈도우와 호환성이 필요할 때, 또는 디지털카메라, 게임기 등에서도 이용된다.

3. FAT32 파티션 구조

FAT32의 파티션 구조는 아래 그림과 같으며 여기서는 Boot Sector의 구조에 대해 알아보고 실제 데이터가 있는 위치까지 추적하는 방법에 대해 알아보자.

Boot Sector는 MBR 구조와 같이 특정 오프셋 별로 가리키는 의미가 다르다.

① Boot Code : 0 ~ 2 byte

② BIOS Parameter Block : 3 ~ 8 byte

③ Boot Code와 Error Message : 90 ~ 509 byte

④ 시그니처 2byte : 510 ~ 511 byte

이제 FAT32의 BR 영역에 대해 알아보자.( 사용하지 않는 영역에 대해서는 따로 언급하지 않겠다. )

FAT 32의 BR 구조는 위와 같이 나타낼 수 있다. 각 영역의 의미는 다음 표와 같다.

Reserved 영역은 예약된 파일시스템에 대한 정보를 구조체로 저장하고 있으며, BR에 대한 백업 본을 저장하고 있다. FAT 영역의 경우 클러스터의 상태 값을 가지고 있는 영역으로써, 각각의 클러스터 정보는 4byte로 나타나게 된다.

- FAT 영역

① 4byte는 미디어 타입을 나타내며, F8 FF FF 0F는 하드디스크를 나타낸다.

② 4byte는 파티션의 상태를 나타낸다. 파티션의 상태는 보통 FF FF FF FF로 나타나게 된다.

③ 4byte는 루트 디렉터리의 클러스터 정보를 나타낸다.

④ 실제 데이터의 연속된 클러스터 공간할당 영역을 나타낸다.

4. 루트 디렉터리 추적

FAT32.vhd.zip

위 실습 파일을 다운로드 하여 압축을 푼다. 그리고 HxD의 '기타설정 > 디스크 이미지 열기' 메뉴로 열고 첫 번째 파티션의 시작 위치로 이동하면 다음과 같은 화면을 볼 수 있다.

실제 데이터 정보를 담고 있는 루트 디렉터리의 위치를 알아내기 위한 정보만 짚고 넘어가자.

FAT32의 BR 영역에서 필요한 정보만 분석해보면 아래 표와 같다.

루트 디렉터리로 가기 위해서는 FAT Area의 위치를 알아야 한다. FAT Area의 주소는 다음과 같이 구할 수 있다.

128 ( BR 주소 ) + 6,646( Reserved Sector( 0x19F6 ) ) = 6,774 섹터

6,774번 섹터로 이동하게 되면 FAT의 구조를 볼 수 있다. 아래 그림에서 00으로 채워진 공간은 사용하지 않는 FAT Area 영역이다.

루트 디렉터리로 가기 위해서는 FAT 주소에 FAT 크기의 2를 곱한 값을 더해주면 된다. 2를 곱해주는 이유는 FAT의 개수가 기본적으로 2개이기 때문이다.

6,774 + ( 773( 0x0305 ) * 2 ) = 8,320 섹터

8,320 섹터로 이동하게 되면 우리가 원하던 데이터에 대한 정보를 저장하고 있는 루트 디렉터리를 볼 수 있다. 이제 루트 디렉터리의 구조에 대해 알아보자.

- Name : 파일에 대한 이름을 나타낸다. 첫 번째 byte가 0xE5로 시작되면 삭제된 파일을 나타낸다. 삭제된 파일을 나타내는 0xE5를 다른 문자열로 바꾸면 해당 파일은 복구할 수 있다. 0x00이면 사용하지 않는 영역이다.

- Extension : 파일 확장자

- Attr : 파일에 대한 속성이다.

- Reserved : 예약된 영역

- Create Time Tenth : 생성 시간을 1/100초 단위까지 측정. 0~199의 값을 사용

- Create time : 파일이 생성된 시간을 나타낸다. 시간 변환은 A6 93이라는 정보가 저장되어 있다고 하면, 93 A6( 리틀엔디안 방식 )을 2진수로 변환하여 각각의 2진수를 우측에서 좌측으로 5자리, 6자리, 5자리씩 끊어주면 된다. 초단위의 경우 5비트를 사용한다. 즉, 0 ~ 31까지 표현할 수 있기 때문에 60초를 표현하기 위해 2를 곱해주어야 한다. 

- Create Date : 파일이 생성된 날짜를 나타낸다. 날짜 변환은 82 48이라는 정보가 저장되어 있다고 하면, 48 82( 리틀엔디안 방식 )를 2진수로 변환하여 각각의 2진수를 우측에서 좌측으로 7자리, 4자리, 5자리로 끊어주면 된다. 년단위의 경우 기준이 1980년이기 때문에 계산한 값에 1980을 더해주면 된다.

- Last Accessed Date : 파일에 마지막 접근된 날짜

- Starting Cluster Hi : 파일에 대한 클러스터 상위 값

- Last Written Time : 파일에 대한 마지막 수정시간

- Last Written Date : 파일에 대한 마지막 수정 날짜

- Starting Cluster Low : 파일에 대한 클러스터 하위 값

- File Size : 파일에 대한 크기

8,320 섹터에 있는 실제 데이터를 루트 디렉터리 클러스터 오프셋 별로 분석해보면 NCS.txt 파일과 DISK.jpg 파일이 존재한다는 것을 알 수 있다. NCS.txt 파일을 살펴보면 파일의 크기는 0x0D로 13 바이트이고, 파일의 생성 시간은 0x7490으로 14시 36분 16초다. 그리고 생성 날짜는 각각 0x4A9C로 2017년 4월 28일 임을 알 수 있다.

마지막으로 실제 데이터가 있는 위치를 찾아가기 위해서는 다음과 같이 계산하면 된다.

Cluster Hi + Cluster Low = 00 00 + 00 08 = 8

( 8 - 2 ) * 4 ( SP ) = 24

8,320 + 24 = 8,344

Hello world!! 라고 데이터가 저장되어 있음을 확인할 수 있다.

1. 윈도우 포렌식 분석 개요

윈도우 컴퓨터의 하드디스크에는 악성코드, 레지스트리, 로그 파일 같은 악성 코드의 흔적뿐만 아니라, Prefetch와 같은 실행 또는 조작여부를 알 수 있는 다양한 정보가 존재한다.

2. 윈도우 시스템에서 악성코드 식별 및 추출

- 알려진 악성코드 검색

* HashMyFiles( Link )

> 보통 공격자들은 공개된 RootKit이나 Sniffer와 같은 공개된 프로그램을 사용한다.

> 안티 바이러스 프로그램 또는 Hash 식별을 이용하여 알려진 악성코드를 식별한다.

- 설치된 프로그램 조사

> 감염된 컴퓨터에 설치된 프로그램에 대해 설치 날짜와 이름을 조사함으로써, 의심스러운 프로그램뿐만 아니라 원격 접속, 데이터 유출 등에 악용된 관련 프로그램 탐지

> 'Program Files' 폴더 하부 및 레지스트리에서 설치된 프로그램의 목록 확인

- 실행파일 점검

> 공격자들은 보통 악성코드를 발견 및 탐지하기 어렵게 하기 위해 노력한다.

> 확장자 변경 : 확장자를 변경해도 실제 데이터는 변경되지 않는다.

> 패킹 : 탐지 및 포렌식 분석을 무력화하기 위해 인코딩을 한다.

> ADS : 다른 파일이나 폴더의 대체 데이터 스트림에 존재하는 실행파일을 찾는다.

- 서비스, 드라이버, 자동 실행 위치, 예약된 작업 점검

> 악성코드는 재부팅 후에도 동작할 수 있도록 서비스, 드라이버, 예약된 작업과 같은 다양한 시작 루틴에 악성코드를 적용한다.

> 예약된 작업 : %SystemRoot%\Tasks 폴더 내에 예약된 작업을 조사

> 서비스 : 악성코드는 보통 새로운 서비스로 자신을 등록하거나, 기존 서비스에 자신을 추가한다.

> 자동실행

- 로그 조사

> 로그 파일을 바탕으로 악성코드 사고와 관련된 기록을 확인할 수 있다.

> 윈도우 이벤트 로그 : 보안 이벤트 로그 기록을 통해 외부 침입자가 내부 접근 권한을 획득한 정보를 확인할 수 있다.

> 웹 브라우저 히스토리 : 악성 웹사이트 접근 여부나 악성코드가 다운로드 된 사실을 확인할 수 있다.

> Desktop 방화벽 로그 : 감염된 시스템으로의 접근 시도 및 다양한 행동이 기록된다.

- 사용자 계정과 로그인 활동 검토

> 감염된 시스템에 새로운 비인가 계정이 생성됐는지, 패스워드가 없는 계정이 존재하는지, 관리자 그룹에 추가된 계정이 어느 것인지 등을 확인한다.

> 비인가 계정 생성 : 알려진 비인가 이벤트 발생 전후 생성된 사용자명이나 계정 확인

> 관리자 그룹 : 로컬 또는 도메인 레벨의 관리자 그룹에 있어서는 안되는 사용자 계정 확인

> 취약한 패스워드 : 패스워드가 없거나 쉽게 예측 가능한 패스워드가 설정되어 있는 계정 확인

3. 윈도우 레지스트리 조사

- 레지스트리

> 운영체제 내에서 작동하는 모든 하드웨어, 소프트웨어, 사용자 정보 및 시스템 구성 요소 등을 담고 있는 데이터 베이스

> 구성

> HKEY_CLASSES_ROOT를 비록하여 5개의 가장 상위키( =루트키 )를 갖는다.

> 각 루트키 아래의 서브키부터 아래의 모든 세부 서브키를 포함하는 트리구조를 레지스트리 하이브라고 한다.

> 각각의 하이브는 저마다 고유한 저장장소( 파일 )와 로그 파일을 갖고 있다.

- HKEY_CLASSES_ROOT

> 파일 확장자에 대한 정보, 각 파일과 프로그램간의 연결에 대한 정보, 마우스 오른쪽 단추의 등록 정보 등

> 모든 형식의 파일 확장자가 서브키 형태로 구성된다.

> HKLM\SOFTWARE\Classes 키에 동일하게 저장되어 두 곳이 연동된다.

- HKEY_CURRENT_USER

> 현재 로그인중인 사용자들에 대한 등록 정보

( 사용자 배경화면, 디스플레이 설정이나 단축 아이콘 정보 등 )

> 응용 프로그램의 우선 순위, 보안 접근 허용 여부

- HKEY_LOCAL_MACHINE

> 하드웨어 구성 초기화 파일, 제어판과 밀접하다.

> 사용중인 하드웨어 및 소프트웨어에 대한 정보

> 로그온 한 사용자와 관계없이 컴퓨터에 등록된 모든 사용자에게 동일

- HKEY_USERS

> 이전 사용자 초기화 파일을 보관

> 두 키 사이가 겹치면 HKEY_CURRENT_USER가 우선

- HKEY_CURRENT_CONFIG

> 현재 사용중인 윈도우의 디스플레이( 화면 글꼴이나 해상도 )정보와 프린터 관련 정보

> HKLM\Config 키의 내용과 같다.

- 하이브 파일

> %SystemRoot%\System32\config\

> C:\Users\{사용자명}\

- UserAssist( Link )

> 사용자 계정에 의해 실행된 프로그램 목록이 저장된다.

> UserAssist 키에는 가장 최근에 실행된 프로그램의 날짜/시간 스탬프와 같은 악성 행위에 대한 세부 정보를 제공한다.

- 이 키에 존재하는 값들은 "ROT13" 암호화 알고리즘으로 암호화 되어 있다.

- 사용자 계정 확인

> 사용자 별로 다른 계정이 존재한다.

> HKLM\SOFTWARE\Microsoft\CurrentVersion\ProfileList 이하에 각 사용자에 대한 Profile 정보가 포함되어 있다.

> 특정인에 의한 해킹이 시도된 경우로 새로운 사용자를 생성

- 특정 작업을 수행 후 사용자를 삭제한 경우 계정 정보 확인이 가능하다.

- 사용자 계정 확인 - 세부정보 확인

* AccessData Registry Viewer( Link )

> HKLM\SAM\Domains\Users\

- User Name, 로그온 횟수, 패스워드 변경시간 등을 확인 할 수 있다.

- 최근 열어본 문서

> HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\RecentDocs

- Windows Explorer를 통해서 최근에 Open된  파일의 목록을 기록하고 있다.

- 파일 확장자로 구분되어 있으며, "Folder"는 최근에 Open한 파일의 폴더 목록을 유지한다.

- 자동 실행 프로그램

> HKU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run

>%SystemRoot%\System32\Tasks\

- 컴퓨터가 부팅 후 자동으로 실행되는 프로그램 리스트

- 설치된 프로그램

> HKU\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\

> HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\

> HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CureentVersion\Uninstall\

- 컴퓨터에 설치되어 있는 프로그램 리스트

- 최근 실행 명령어

> HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU

- [시작] -> [실행]에서 수행하여 기억하고 있는 명령어 목록

- 사용자가 실행한 명령어 목록을 확인 가능

- 컴퓨터 정보

> HKLM\SOFTWARE\Microsoft\WindowsNT\CureentVersion

- CSDVersion : Service Pack

- RegisteredOwner : 등록된 사용자

- SystemRoot : 시스템 기본 경로

- ProductName : OS 기본 정보

- InstallDate : 설치 일자

4. 기타 포렌식 분석

- 자동실행 프로그램 조사

* AutoRuns( Link )

> 컴퓨터가 시작할 때 자동으로 프로그램을 실행시키기 위해 참조하는 윈도우 시스템의 다양한 위치에서 상세 정보를 추출한다.

> 서명되지 않은 실행파일 목록 확인 가능

> 디스크에 존재하지 않는 실행 파일과 관련된 자동 실행 항목 확인 가능

- Prefetch 분석

> 윈도우의 부팅 커널까지 포함하여 응용 프로그램 실행 정보를 저장한 파일을 메모리에 올려두어 실행속도를 빠르게 하기 위한 기능이다.

> 침해사고 발생 시 사용자가 실행한 응용프로그램을 확인할 수 있다.

> 프로그램을 한번이라도 실행할 경우 '%SystemRoot%\Prefetch' 폴더에 .pf 확장자로 저장된다.

* WinPrefetchView( Link )

> 실행한 응용프로그램의 이름, 실행 횟수, 마지막 실행 시간, 참조 목록( dll / ini ) 확인

- 외장형 저장장치 분석

* USBDeviceForensics( Link )

> 사용자가 연결한 외장형 저장장치의 정보를 확인할 수 있다.

> HKLM\SYSTEM\ControlSet00x\Enum\USBTOR

- USB장치 정보 저장

- Device Class ID : Disk&Ven_XXX&Prod_YYY&Rev_ZZZ

- XXX( Vender ), YYY( Product ), ZZZ( Version )

> HKLM\SYSTEM\MountedDevices를 참조하여 어떤 USB 장치가 어떤 드라이브에 연결되었는지 확인 가능하다.

- 외장형 저장자치 분석 - 연결 기록

> %SystemRoot%\System32\winevt\Logs\ 폴더에 존재하는 Microsoft-Windows-DriverFrameworks-UserMode%40perational.evtx

- 이벤트 로그 분석을 통하여 외장형 저장장치의 연결/해제 관련 로그 확인 가능

- Security Identifier ( SID )

① 해당 시스템이 윈도우 시스템임을 말한다.

② 시스템이 도메인 컨트롤러이거나 단독 시스템임을 표시한다.

③ 시스템의 고유한 숫자. 이 고유한 숫자는 시스템을 설치할 때 시스템의 특성을 수집하여 생성한다.

④ 각 사용자 별 숫자로 표현되는 고유한 ID. 관리자는 500번, Guest는 501번, 일반 사용자는 100번 이상의 숫자를 갖는다.

> 시스템 고유 숫자를 이용하여 장치의 연결이력을 확인할 수 있다.

> 외장형 저장장치 및 HDD가 다른 윈도우 시스템에 연결될 경우 해당 시스템의 SID 값으로 휴지통 폴더가 생성된다.

> 휴지통 폴더 정보를 통해 장치의 연결 기록을 확인할 수 있다.

1. 메모리 포렌식 개요

메모리 덤프에는 악성 실행파일, 시스템 연관 데이터 구조, 관련된 사용자 활동 정보와 악성 이벤트 등 다양한 데이터가 내포되어 있다.

메모리 포렌식의 주된 목적은 악성코드와 직접적으로 관련이 있는 데이터를 추출하고 어떠한 이벤트가 발생했는지, 어떻게 악성코드가 설치됐는지와 같은 맥락 정보를 식별하는데 있다.

2. 윈도우 메모리 포렌식 도구

메모리 포렌식 도구의 내부 작동 원리를 이해하는 것은 특정 작업에 맞는 도구를 선택하고 결과의 정확도와 완성도를 평가하는데 도움이 된다.

주요 메모리 포렌식 도구가 공통적으로 제공하는 정보의 목록은 아래와 같다.

> Process와 Thread

> 모듈과 라이브러리

> 열린 파일과 소켓

> 다양한 데이터 구조체

- Process와 Thread 

* Volatility ( Link )

> 숨겨져 있거나 종료된 Process를 포함한 Process와 Thread 정보를 수집하고, 상세 분석을 바탕으로 어떤 Process가 악성코드와 연관되어 있는지 판단하는데 도움을 준다.

> 관련 Volatility 플러그인 정보

- psscan : 전체 Process 구조체를 카빙

- pslist : 동작중인 Process 목록 확인

- psdiff : psscan과 plist 목록을 비교

- dlllist : 해당 Process에 로드된 DLL목록 확인

- csrpslist : Process의 세부 정보를 추출해 숨겨진 Process 확인

> pslist 옵션 결과와 psscan 출력 결과를 비교해 악성코드에 의해 불일치 되는 부분을 찾아내거나 악성코드 행위와 관련된 비정상 상태 탐지 가능하다. ( psxview )

* Responder ( Link ) -> 유료이기 때문에 30일 동안만 무료로 사용할 수 있다.

> Process와 열린 Handle 목록 뿐만 아니라 메모리 덤프에서 URL, 사용자 명, 패스워드, 키, 그 외 기타 정보 등을 추출해 준다.

- 모듈과 라이브러리

> 악성코드는 자신을 은폐하거나 키로깅 하는 등의 주요 기능을 수행하기 위해 드라이버를 생성하거나 라이브러리를 로드한다.

> 관련 Volatility 플러그인 정보

- modules : 시스템에서 동작 중인 모듈 목록 제공

- driverscan : 특정 드라이버 객체를 메모리에서 검색

- moddump : 특정 모듈에 대해 실행 파일 포맷 형태로 파일을 추출

- dlldump : 메모리 덤프에서 특정 DLL 추출

> Responder를 이용하여 로드된 라이브러리와 드라이버 목록을 확인하고, 특정 개체에 대한 더욱 더 자세한 정보를 조사 가능하다.

1. 휘발성 데이터 수집

- 휘발성 데이터

전원이 끊어지면 손실되는 데이터 -> 초기 분석 수행해야 한다.

동작중인 시스템의 메모리에 존재한다.

Process, Password, IP address, event log 등 악성 코드와 관련된 내용 포함이 가능하다.

휘발성 데이터들의 수명은 그 특성으로 인해 모두 다르기 때문에 우선 순위를 고려해야 한다.

- 휘발성 순위

> Register, Cache

> Routing Table, ARP cache, Process Table, Kernel Statistics, Memory

> Temporary file system

> Disk

> Remote logging and monitoring data

> Physical configuration, network topology

> Archival media

휘발성 순위는 RFC3227 문서에 잘 정리되어 있다.

https://www.ietf.org/rfc/rfc3227.txt

- 디지털 증거의 무결성

라이브 시스템에서 데이터를 수집하는 행위는 해당 시스템( 디지털 증거 )에 영향을 줄 수 있다.

> 수집을 위한 외장형 저장장치 연결, 프로그램 설치 및 실행 등

수집 과정에서 일부 변경이 일어날 수 있으나, 보존과 처리 과정에서 변경이 발생하지 않음을 객관적 방법으로 진술 성립의 진정함이 증명되는 때에 증거로 할 수 있다.

- 휘발성 데이터 수집

시스템의 날짜 / 시간을 확인 후, 대상 시스템의 물리 메모리를 획득해야 한다.

> Windows 각 버전마다 메모리 구조가 다르기 때문에 도구에 따라 제대로 해석하지 못하는 경우가 발생한다.

> 따라서 물리 메모리 획득 및 라이브 시스템의 정보를 저장해 두어야 한다.

로컬에서 물리 메모리 획득

> 명령프롬프트나 GUI 유틸리티를 사용해 물리 메모리 덤프를 생성한다.

* 무료 물리 메모리 획득 툴

> MDD

> DumpIt

> FTK Imager

- 시스템 정보 수집

시스템 정보는 라이브 대응과 사후 포렌식 과정에서 타임 라인 생성, 로그와 기타 포렌식 아티팩트와 함께 대상 시스템을 식별하는데 활용된다.

* 주요 수집 대상 시스템 정보

> 시스템 날짜와 시간

라이브 대응 조사를 수행하는 과정에서 처음과 마지막에 수집하는 항목이다.

시스템 분석 시 타임라인 생성과 모든 문서의 기초이다.

대상 시스템의 날짜와 시간을 확인 후 정확한 검증을 위해 신뢰할 수 있는 시간 출처와 비교가 필요하다.

> 시스템 식별자

set user : 로그인한 사용자의 도메인, 이름, 프로필

net user [계정명] : 로컬 컴퓨터의 사용자 정보 수집

> 네트워크 구성

ipconfig : 로컬 컴퓨터에 설정된 IP 정보 및 MAC 주소 확인

netstat -ano : 프로토콜 연결, 연결 상태, 트래픽, 통계 등을 확인

> 서비스 정보

net start : 현재 윈도우 시스템에서 실행되고 있는 서비스 정보 수집

- 제공되지 않는 서비스 또는 유사한 서비스 명으로 등록된 것은 악성코드일 수 있다.

> 시스템 환경

systeminfo : 시스템 uptime, 종류, 프로세서, 메모리, 핫픽스, 네트워크 카드 정보 등 확인

> 공유폴더 정보

net share [공유 이름] : 로컬 컴퓨터의 모든 네트워크 공유 자원에 대한 정보

- 알지 못하는 공유 자원이 있는지 점검해야 한다.( NETBIOS 취약점 )

> 예약된 작업 확인

schtasks : 예약된 작업에 대한 자세한 정보를 제공

- 일부 악성코드 변종은 특정 날짜나 이벤트가 발생할 때까지 휴면상태로 남아있는 '이벤트 기반' 방식을 사용한다.

- 예약된 목록을 확인하여 휴면상태의 악성코드 등을 확인한다.

> 배치파일 제작

대상 시스템상에서 직접 명령어를 이용해 살펴볼 수 있으나, 실수와 누락을 피하기 위해 자동화 도구 등을 이용하는 것이 효율적이다.

2. 비 휘발성 데이터 수집

가용성이 중요한 서버 및 종료할 수 없는 시스템을 다룰 때에는 컴퓨터가 동작하는 동안 전체 시스템의 포렌식 사본을 생성해야 한다.

아래와 같이 주요 비활성 데이터에 대한 수집 및 분석을 수행한다.

> 보안 구성 평가

> 호스트 파일 획득

> Prefetch 파일 조사

> 자동시작 리스트 조사

> 이벤트 로그 조사

> 사용자 계정 조사

> 파일 시스템 조사

> 레지스트리 조사

- 보안구성 평가

* WinUpdateList( Link )

> 시스템이 안전하게 구성됐는지 점검하는 일은 호스트에서 발생할 수 있는 오용, 취약점, 가능한 공격 벡터의 위험 수준을 평가하는데 도움을 준다.

- 호스트 파일 획득

> %SystemRoot%\system32\drivers\etc\

> 해당 위치에 있는 파일들에는 신뢰된 호스트와 네트워크 정보가 존재한다.

> hosts : IP와 호스트 이름 사이의 관계

> networs : IP 주소 범위와 네트워크 이름 사이의 관계

> lmhosts : IP 주소와 NetBIOS 이름 사이의 관계

- Prefetch 파일 조사

> %SystemRoot%\Prefetch

> 윈도우 운영체제는 프로그램 실행 성능을 개선할 목적으로 'Prefetch' 파일을 생성한다.

> 비 정상적인 실행파일명을 포함하는 Prefetch 파일은 대상 시스템의 감염을 증명할 수 있는 잠재적 흔적이다.

- 자동 시작 리스트 조사

* AutoRuns( Link )

> 윈도우의 자동 시작 위치는 시스템을 재부팅해도 악성코드가 지속적으로 존재할 수 있도록 도와준다.

> 자동 시작 위치는 특정 폴더, 레지스트리, 시스템 파일을 비롯해 운영체제의 다양한 곳에 존재한다.

- 파일 시스템 조사

* HFind( Link )

> 일반 사용자는 보지 못하도록 숨겨진 파일이나 ADS의 위치 탐지 및 관련된 목록 출력해준다.

- 레지스트리 덤프

* regdump(  Link )

> 운영체제 내에서 작동하는 모든 하드웨어, 소프트웨어, 사용자 정보 및 시스템 구성 요소 등이 레지스트리에 저장된다.

3.20 전산대란에 대한 내용은 아래 링크를 참고하길 바란다.

https://ko.wikipedia.org/wiki/3·20_전산_대란

3.20 전산대란에 발생했던 것과 비슷한 상황의 vmdk를 이용해 실습을 진행한다.

* vmdk는 VMware용 가상 운영체제의 디스크 파일이다.

우선 HxD 에디터로 실습 파일을 실행해보면 다음과 같다.

이전에 봤던 다른 실습파일들과 구조가 다른것을 볼 수 있다. 예전 실습 파일들의 구조는 0번 섹터에 바로 MBR이 존재했지만 이번 실습파일은 0번 섹터에 MBR이 존재하지 않는다. 이는 vmdk 파일이기 때문에 vmdk 파일의 헤더가 가장 먼저 등장하기 때문이다. 이 헤더의 구조는 나중에 살펴보기로 하고 일단 MBR을 찾아 보자.

MBR을 찾기 위해서는 offset 40에서 00 ~ 07 위치에 있는 데이터가 실제 저장된 데이터의 시작 주소다. 따라서 '80 28 00 00 00 00 00 00'은 10,368이기 때문에 이 섹터로 이동하면 다음과 같다.

가장 먼저 등장하는 곳이 MBR인데 데이터가 모두 HASTATI.로 바뀌어 있음을 확인할 수 있다.

* MBR의 위치는 10,368

실습파일을 FTK 프로그램으로 열면 다음과 같다.

FTK는 헤더 정보는 모두 걸러내고 실제 MBR부터 표시를 해준다. 이 부분이 MBR 부분이라는 것을 쉽게 유추할 수 있다. 그리고 데이터가 모두 HASTATI.로 변경된 것을 이용해 다음 VBR의 위치를 찾아보면 다음과 같다.

아래 부분을 보면 'phy sec = 2048' 부분이 보이는데 실제 VBR의 위치가 2048 섹터임을 알 수 있다. 즉, 첫 번째 파티션의 위치가 2048 섹터임을 알 수 있다. 이는 예약 크기가 2048 섹터임을 알 수 있고 이를 통해 Windows vista 이상 버전임을 알 수 있다. Windows XP의 경우 예약 크기가 63 섹터이다.

HxD 에디터로 'HASTATI'를 검색하면 다음과 같이 다음 섹터를 알 수 있다.

위 캡쳐화면을 보면 10496 섹터에 첫 VBR이 나오는데, 이 위치는 실제 위치라고 보기 힘들다. 따라서 FTK를 이용해서 위치를 찾는 것이 포인트이다.

* 첫번째 파티션의 시작 위치는 10496

첫 번째 파티션의 타입이 무엇인지 모르기 때문에 해당 섹터에서부터 6 섹터 밑으로 갔을 때 VBR 백업본이 있으면 FAT32, 그렇지 않으면 NTFS임을 유추할 수 있다.

우선 10502 섹터에 가보면 다음과 같다.

해당 섹터에 가보니 알 수 없는 데이터만 있는 것을 확인할 수 있다. 따라서 FAT32 타입이 아니라 NTFS 타입임을 알 수 있다. NTFS의 경우 VBR 백업본이 해당 파티션 끝에 존재하기 때문에 찾기가 힘들다. 하지만 BR이 'HASTATI.' 라는 문자열로 모두 바뀐 것을 이용해 FTK 프로그램으로 찾아보면 다음과 같다.

206848 섹터에서 'HASTATI' 문자열이 등장하였고 그 위 섹터에 NTFS 백업본이 있는 것을 확인할 수 있다. 이 VBR 데이터를 따로 저장해 놓자. 이름은 'partition1'로 하도록 하자.

현재 위치에 있는 VBR의 타입을 모르기 때문에 마찬가지로 6섹터 밑으로 가보면 다음과 같다.

역시 마찬가지로 VBR이 아닌 알 수 없는 데이터만 존재하는 것을 볼 수 있다. 따라서 두번째 파티션 또한 NTFS 임을 확인할 수 있다.

파티션이 더 있는지 확인하기 위해 'HASTATI' 문자열을 이용해 검색을 해보면 다음과 같이 찾지 못했다는 메시지가 뜨는 것을 확인할 수 있다.

즉, 두번째 파티션이 마지막 파티션이라는 것을 유추할 수 있다. 하지만 백업본의 위치는 찾지 못했다. 백업본의 위치를 찾기 위해 시그니처를 이용한다. NTFS의 시그니처는 "EB 52 90 4E 54 46 53 20"이다. 이 시그니처를 이용해서 하나 하나 찾아가다보면 VBR 형식의 데이터가 여럿 존재하는 것을 확인할 수 있다. 

다음 캡쳐파일을 보자.

위의 캡쳐파일을 보면 NTFS의 VBR 형식이 맞는 것 같다. 하지만 데이터를 조금만 분석해보면 백업본 VBR이 아님을 알 수 있다.  캡쳐파일이 잘 안보이기 때문에 HxD로 옮겨서 보도록 하자.

일단 offset 0의 0D( 13 )번째 바이트를 보면 '01'로 되어 있는데 이는 클러스터의 크기가 1섹터라는 의미이다. 하지만 기본적으로 클러스터의 크기는 8 섹터이다. 이것만 봐도 VBR이 아님을 알 수 있지만 이 값이 '08'인 경우도 있다. 그럴 경우 offset 10의 0C~0F( 12 ~ 15 )번째 바이트를 보면 "02 00 00 00" 으로 되어 있다. 이는 Hidden Sector 부분으로 현재 섹터 앞에 있는 모든 섹터의 수가 2 섹터임을 의미하는데, 위의 FTK 파일 캡쳐화면을 보면 나오는 섹터 수와 다름을 알 수 있다. 이렇듯 데이터를 분석했을 때 납득이 되지 않는 부분이 존재한다면 백업 VBR이 아니라는 것을 알 수 있다. 

실제 백업 VBR을 보면 다음과 같다.

위 부분이 바로 두번째 파티션의 백업 VBR이다. 이를 'partition2'라는 이름으로 따로 저장해 놓자.

HxD 에디터를 이용해서 VBR을 복구해보자.

HxD에서 'HASTATI' 문자열을 검색했을 때 두번째 나오는 섹터가 첫 번째 파티션의 VBR 부분이고, 세번째 나오는 섹터가 두번째 파티션의 VBR이라는 것을 앞서 확인했다. 따라서 첫 번째 파티션의 VBR 부분에 'partition1'으로 저장한 데이터를 붙여 넣으면 다음과 같다.

똑같은 방법으로 두번째 파티션의 VBR을 복구해보면 다음과 같다.

여기까지 두개의 파티션에 대한 VBR을 복구했다. 하지만 MBR이 복구가 되지 않았으므로 여전히 부팅이 되지 않는다. 그렇기 때문에 이제 MBR을 복구해보도록 하자.

우선 위와 같이 디스크 관리에 들어가 VHD 만들기 메뉴를 선택하면 다음과 같이 나타난다.

위치는 VHD를 저장할 위치를 지정하고 디스크 크기는 적당하게 잡아준다. 여기서는 3GB로 잡았다. 디스크 포맷으 VHD, 디스크 유형은 고정 크기로 설정하고 확인을 선택한다.

그러면 위와 같이 디스크가 추가가 되며 해당 디스크를 우클릭해 디스크를 초기화 한다.

디스크를 초기화할 때 파티션 형식을 MBR로 선택하고 확인을 누른다.

위 화면과 같이 디스크 1은 온라인으로 바뀌고 디스크를 우클릭해서 새단순 볼륨을 선택해 디폴트로 설정된 값으로 진행을 한다.

포맷이 완료가 되면 디스크1의 연결을 해제하고 HxD 에디터로 방금 생성한 VHD을 열어보면 다음과 같다.

블록박스 처리된 부분( 0 ~ 439 바이트 )까지의 값을 복사하여 복구할 MBR에 붙여넣어 준다. 

위와 같이 변경을 하고나서 FTK로 복구한 파일을 열면 다음과 같이 나타난다.

파티션은 복구가 된 것을 확인할 수 있다. 하지만 여전히 부팅이 되지는 않는다. 이유는 data signature를 수정해주지 않았기 때문이다. data signature는 기기마다 다르다고 보면 되기 때문에 이 값이 다르면 당연히 부팅이 되지 않는다. 이 값은 레지스트리에 존재하며 복구된 파티션에서 'NONAME > [root] > Windows > System32 > config > SYSTEM' 파일을 우클릭으로 추출한다.

추출한 SYSTEM 파일을 레지스트리 편집기를 이용해 하이브 로드하여 data signature를 확인한다.

하이브 로드를 선택하여 SYSTEM 파일을 선택하고 사용할 키 값을 입력한다. 여기서 키 값은 '320'으로 했다.

그러면 위와 같이 '320 > MountedDevices'에 가보면 C 드라이브의 데이터를 앞에서 4바이트 만 기억하고 이 값을 MBR의 440 ~ 443 번째 바이트에 넣어주면 된다.

위와 같이 값을 넣어주면 복구가 모두 완료가 됐다. 여기까지 완료가 됐다면 해당 이미지 파일을 가지고 VMware에서 부팅이 가능해야 한다. 하지만 부팅이 되지 않는다. $BOOTMSG 파일이 존재하지 않기 때문에 부팅 코드가 메모리에 로드되지 않는다. 따라서 부팅시키기 위해서는 윈도우 cd를 이용해 복구 모드로 들어가야 한다. 

앞선 포스팅에서는 MBR, VBR을 분석하는 정도로 실습을 했다. 하지만 이번 포스팅에서는 MBR이 날아간 경우와 VBR이 날아간 경우 그리고 MBR와 VBR이 함께 날아간 경우에 대해 분석하고 복구하는 실습을 한다.

실습에 앞서 먼저 파일시스템의 BR에 대해 간단하게 설명하고자 한다.

- FAT32 구조

FAT32는 위와 같은 구조를 갖는다. FAT32의 BR은 Boot Sector에 존재한다.

- FAT32의 BR

FAT32의 BR은 위와 같은 구조를 갖으며, 각 영역의 의미는 다음 표와 같다.

- NTFS 구조

NTFS는 위와 같은 구조를 갖는다.

- NTFS의 BR

NTFS의 BR 구조는 위와 같으며 각 영역의 의미는 다음 표와 같다.

FAT32와 NTFS의 구조 중 BR에 대한 부분만을 살펴봤다. 이를 참고하여 다음 예제를 실습해보자.

- MBR Test #3

예제 파일을 HxD 에디터로 열어보면 위와 같다. Partition Table이 위치한 446 ~ 509 바이트를 보면 00으로 비어있는 것을 알 수 있다. 즉 MBR이 손상된 경우이다. 

예제 파일을 FTK 프로그램으로 실행시켜보면 다음과 같다.

Evidence Tree에 보면 파티션이 나눠지지 않는 것을 확인할 수 있으며 해당 디스크가 손상되어 있음을 확인할 수 있다.

이를 복구하기 위해선 다음과 같은 절차를 거친다.

1. VBR의 위치를 찾는다.

2. 해당 파티션의 총 크기를 구한다.

3. MBR의 Partition Table에 구한 값을 수정한다.

4. 제대로 복구가 됐는지 확인하기 위해 FTK 프로그램으로 해당 디스크 구조를 열어 확인한다.

그럼 이제 실습파일을 이용해 분석을 해보도록 하자. 우선 실습파일을 HxD 에디터를 이용해 로드한다. 

첫번째 VBR은 윈도우 XP의 경우 VBR의 위치는 63섹터, Vista 이상의 버전에서는 2048 섹터에 위치한다. 이를 이용해 해당 섹터에 이동해보면 VBR이 존재하지 않는 것을 볼 수 있다. 이는 vhd를 분석할 때 종종 나타나며 보통 128 섹터에 첫번째 VBR이 위치한다.

FAT32 BR 구조를 참고하여 위 VBR을 분석해보면 Hidden Sector는 '80 00 00 00'으로 128, 즉 0번 섹터부터 127 섹터까지를 의미한다. 그리고 Total Sector는 '00 98 07 00'으로 497,664이다. 두번째 VBR의 위치는 497,664 + 128인 497,792 섹터로 이동해 보면 다음과 같다.

NTFS BR 구조를 참고하여 위 VBR을 분석해보면 Hidden Sector는 '80 98 07 00'으로 497,792, 즉 0번 섹터부터 497,791 섹터까지를 의미한다. 그리고 Total Sector는 'FF 9F 05 00'으로 368,639이다. 세번째 VBR의 위치는 497,792 + 368,639 + 1인 866,432 섹터로 이동해 보면 다음과 같다.

* 여기서 1을 더한 이유는 NTFS의 Backup VBR의 위치는 해당 파티션 끝에 위치하여 Backup VBR 바로 이전의 섹터까지만 Total Sector에 포함되기 때문에 더해준다.

위와 마찬가지로 NTFS 파일시스템임을 알 수 있다. VBR을 분석해보면 Hidden Sector는 '80 38 0D 00'으로 866,432, 즉 0번 섹터부터 866,431 섹터까지를 의미한다. 그리고 Total Sector는 'FF DF 06 00'으로 450,559이다. 네번째 VBR의 위치는 866,432 + 450,559 + 1인 1,316,992 섹터로 이동해보면 다음과 같다.

Partition Table의 정보를 보면 Partition Type이 '0B'로 FAT32임을 알 수 있고 시작 위치가 '80 00 00 00'으로 128이다. MBR의 특성상 4번째 파티션부터는 Extended Boot Record( EBR )로 상대적인 위치를 나타낸다. 따라서 해당 파티션의 실제 위치는 1,316,992 + 128인 1,317,120 섹터이다. EBR의 특성에 따라 파티션 테이블은 최대 2개가 존재한다. 2번째 테이블을 분석해보면 Partition Type은 '05'로 Ext이고 해당 파티션의 시작 위치는 '80 40 06 00'으로 409,728이다. 이 파티션 역시 실제 위치는 1,316,992 + 409,728인 1,726,720 섹터로 이동해보면 각각 다음과 같다.

* EBR은 MBR과 비슷한 구조를 갖지만 MBR과 달리 파티션 테이블을 제외한 곳은 모두 0으로 채워져 있다.

EBR 부분을 이전에 만든 python 코드로 돌려보면 위와 같이 분석이 되는 것을 알 수 있다.

FAT32 파일시스템임을 알 수 있다. 해당 파티션의 총 크기는 '00 40 06 00'으로 409,600 * 512 / 1024 / 1024 = 200MB 임을 계산할 수 있다.

Partition Table 정보를 보면 하나의 정보만 존재하는 것을 확인할 수 있다. 이는 더 이상의 파티션이 존재하지 않음을 의미한다. Partition Type이 '0B'로 FAT32임을 알 수 있고 시작 위치가 '80 00 00 00'으로 128이다. 이 파티션 또한 실제 위치는 1,726,720 + 128인 1,726,848 섹터로 이동해보면 다음과 같다.

앞서 분석한 내용을 정리하면 다음과 같다.

> 첫번째 파티션

① 시작 섹터 : 128

② 파티션 타입 : FAT32

③ 파티션 총 섹터 수 : 497,664

> 두번째 파티션

① 시작 섹터 : 497,792

② 파티션 타입 : NTFS

③ 파티션 총 섹터 수 : 368,639

> 세번째 파티션

① 시작 섹터 : 866,432

② 파티션 타입 : NTFS

③ 파티션 총 섹터 수 : 450,559

> 네번째 파티션( EBR )

① 시작 섹터 : 1,316,992

② Current 파티션 타입 : FAT32

③ 시작 섹터 : 1,316,992 + 128 = 1,317,120

④ 파티션 총 섹터 수 : 409,600

⑤ Next 파티션 타입 : Extended

⑥ 시작 섹터 : 1,726,720

⑦ 파티션 총 섹터 수 : 362,624

> 다섯번째 파티션( EBR )

① 시작 섹터 : 1,726,720

② Current 파티션 타입 : FAT32

③ 시작 섹터 : 1,726,720 + 128 = 1,726,848

④ 파티션 총 섹터 수 : 362,496

앞서 분석한 것을 바탕으로 본격적으로 Partition table이 손상된 MBR을 수정한다.

위와 같이 수정한 후 FTK Imager 프로그램으로 실습 파일을 로드하면 다음과 같이 복구가 된 것을 확인할 수 있다.

파티션 복구 실습을 하기 전에 계산 방법에 대해 알아보자.

우선, 샘플 예제를 HxD 에디터로 열어보면 다음과 같다.

파티션과 관련된 파티션 테이블 부분은 446byte부터 509byte까지 총 64byte이며, 16바이트씩 총 4개의 파티션 정보가 담긴다. 

Boot flag( 1 byte ), Starting CHS( 3 byte ), Partition type( 1 byte ), Ending CHS( 3byte ), Starting LBA( 4 byte ),  Total Sector(4byte)로 구성된다.

•Boot flag: 부팅 가능여부를 나타내며, 0x00은 부팅 불가능, 0x80은 부팅 가능

•Starting CHS: CHS 주소지정방식의 시작 위치이며 더이상 사용하지 않는다.

•Partition type: 해당 파티션의 파일시스템 타입을 알 수 있다.

•Ending CHS: CHS 주소지정방식의 끝나는 위치 정보이며 더이상 사용하지 않는다.

•Starting LBA: LBA 주소지정방식에 의한 파티션 시작주소이다.

•Total Sector: 해당 파티션의 총 섹터 개수에 대한 정보를 담고 있다.

* 파티션 타입에 대한 정보는 아래 링크에서 확인할 수 있다.

https://en.wikipedia.org/wiki/Partition_type

* 데이터는 리틀 엔디언 방식으로 저장되어 있다.

위 샘플예제를 엑셀로 열면 다음과 같다.

우선 446 번째 바이트를 보면 0x00으로 부팅가능한 파티션이 아님을 알 수 있다. 그리고 CHS 방식은 더이상 사용하지 않기 때문에 447 ~ 449 바이트와 451 ~ 453 바이트는 보지 않아도 된다. 

450 번째 바이트를 보면 0B로 파티션 타입이 FAT32임을 알 수 있다. 

454 ~ 457 바이트를 보면 80 00 00 00 이지만 리틀 엔디안 방식으로 저장되어 있기 때문에 실제로는 00 00 00 80으로 LBA 시작 위치는 128 섹터임을 알 수 있다. 

458 ~ 461 바이트를 보면 00 08 03 00 이지만 이 또한 리틀 엔디안 방식으로 저장되어 있기 때문에 00 03 08 00 으로 총 섹터의 개수는 198,656개 임을 알 수 있다.

그리고 파티션의 총 용량은 총 섹터의 개수 x 512( 섹터 크기 )를 곱한 값으로 101,711,872 바이트 임을 알 수 있고 이를 MB 단위로 표시하기 위해서는 1024로 두번 나누어 주면( 2^20 ) 되며 그 값은 97 MB임을 알 수 있다.

분석 및 계산 방법은 위와 같이 하지만 일일이 계산하는 것이 불편하고 시간이 오래 걸리기 때문에 python을 이용하여 프로그램을 하나 만들었다. 

simple_MBR.py

* 위 파일은 python 2.7 버전으로 작성되어 있으며 windows 용으로 만들었다. 이를 실행하기 위해서는 python 2.7 버전이 설치되어 있어야 한다.

* 간단한 프로그램으로 파티션 타입을 확인할 수 있는 것이 제한적이다. FAT32, NTFS, Ext만 확인할 수 있다.

MBR.py

* 위 파일은 simple_MBR.py 프로그램의 MAC용이다. 저자가 맥북을 사용하기 때문에 따로 만들었다. 거창하지만 실제로는 파일을 찾는 경로에 차이가 있을 뿐이다.

* simple_MBR.py 사용법

1. HxD 에디터로 데이터를 연다.

2. 데이터를 전체 선택 후 복사한다.

3. 메모장을 열어 데이터를 붙여넣고 저장한다.

4. simple_MBR.py 프로그램을 실행시켜 저장한 txt 파일을 불러온다.

5. 결과를 확인한다.

위에서 살펴본 샘플 예제를 분석한 것과 결과가 같은 것을 확인할 수 있다.

앞서 살펴본 샘플 예제는 파티션이 1개인 경우를 살펴보았다. 이제 확장 파티션이 있는 샘플 파일을 분석해 보자.

위 파일을 분석하기 위해 simple_MBR 프로그램을 사용하면 다음과 같다.

파티션 1은 FAT32 방식이고 시작 섹터가 128 섹터, 총 섹터는 512,000, 총용량은 250MB

파티션 2는 FAT32 방식이고 시작 섹터가 512,128 섹터, 총 섹터는 512,000, 총용량은 250MB

파티션 3은 FAT32 방식이고 시작 섹터가 1,024,128 섹터, 총 섹터는 512,000, 총용량은 250MB

파티션 4는 Ext 방식이고 시작 섹터가 1,536,128 섹터, 총 섹터는 557,056, 총용량은 272MB

위와 같이 확인할 수 있다.

다양한 예제를 분석해보자.

- MBR test #1

위 파일을 simple_MBR 프로그램으로 돌려보자.

위와 같이 분석이 되었다. 분석이 제대로 되었는지 확인하는 방법은 HxD 에디터로 파티션의 시작 섹터 부분으로 이동했을 때 VBR이 나타나는지 보면 된다. 이는 다음과 같다.

에디터 상단에 '섹터' 부분에 128을 입력하고 엔터를 치면 다음과 같이 섹터 128로 이동하게 되며 VBR이 나타남을 볼 수 있다. 이와 같이 409,728 섹터와 716,928 섹터로 이동해보면 다음과 같다.

- MBR test #2

이를 simple_MBR 파일로 열면 다음과 같다.

4번째 파티션을 보면 Ext방식이고 시작 주소가 1,316,992 임을 알 수 있다.

이 주소로 가면 다음과 같다.

boot code 부분이 비어있는 것을 확인 할 수 있으며 이는 Extended Boot Record( EBR )의 특성이다. 이를 다시 simple_MBR 파일로 돌려보자.

파티션 정보가 2개만 있는 것을 확인할 수 있다. 이 또한 EBR의 특성이며 파티션 1은 현재 파티션의 정보를 나타내며 파티션 2는 다음 파티션의 위치를 나타낸다. EBR의 경우 상대적 위치를 나타내기 때문에 앞서 봤던 Ext의 시작 주소를 각 파티션의 시작 주소에 더해주어야 실제 파티션의 시작 주소를 알 수 있다.

위와 같은 방식으로 분석을 하면 된다.

다음 포스팅은 실제 파티션을 복구하는 방법에 대해서 알아보자.

파티션 복구 실습을 위해 자주 사용하는 도구에 대한 사용법을 간단히 살펴보자.

1. HxD 에디터

일반 텍스트 타입의 파일은 텍스트 편집기를 이용해서 쉽게 확인할 수 있지만, 대부분 파일 내부에는 텍스트가 아닌 데이터로 존재한다.

HxD는 이진 파일을 읽을 수 있는 무료 에디터 프로그램으로 사용법이 쉽고 간단하여 널리 사용되고 있다. 주로 사용되는 기능으로는 파일이나 이미지의 특정 섹터를 확인하거나 수정할 때 사용된다.

* HxD 에디터 다운로드

https://mh-nexus.de/en/downloads.php?product=HxD

- HxD 인터페이스

•파일: 파일의 열기, 저장, 인쇄가 가능한 메뉴이다.

•편집: 파일의 복사, 붙여넣기, 등이 있는 메뉴이다.

•찾기: 찾기, 찾아 바꾸기, 특정 오프셋으로 이동 등 설정이 가능하다.

•보기: 화면에 표시되는 데이터 표현( 아스키, 16진수 등 ) 설정이 가능하다.

•분석: 파일의 해시값 분석 및 두 개의 파일을 비교할 수 있다.

•기타설정: 물리적인 장치와 이미지 분석할 때 사용되는 메뉴이다.

1) 분석 대상 열기

HxD 에디터는 파일, 물리 디스크, 이미징된 파일을 읽을 수 있다. 먼저, 파일을 분석하려면 '파일 > 열기' 메뉴로 열 수 있지만, 포렌식 분석을 위해서는 '기타설정' 메뉴를 사용한다.

•램: 기타설정 > RAM 열기

•물리디스크: 기타설정 > 디스크 열기

•디스크 이미지: 기타설정 > 디스크 이미지 열기

처음 파일을 열면 1섹터 당 몇 byte인지 묻는데 보통 512byte이기 때문에 512를 선택하고 '수락'을 선택하면 섹터 단위로 이동하기 편리하다. size는 원하는 byte 단위로 바꿔도 된다.

2) Sector 이동과 수정

Sector 이동은 Sector 입력 폼에서 이동하고 싶은 Sector의 숫자를 직접 입력하여 이동할 수 있고, 원하는 위치의 Hex 값으로 수정할 수 있다.

또한, 원하는 섹터를 블록 지정하여 복사한 뒤 '붙여넣기 쓰기'를 통해 덮어쓰기도 가능하고 '붙여넣기 삽입'으로 삽입도 가능하다.

3) 특정 영역 일괄 블록지정

일괄 블록지정은 '편집 > 블록선택'에서 '오프셋 시작'과 '오프셋 종료'로 지정한다. 이 기능은 파일이나 디스크 복구 등 많은 섹터 영역을 지정해야 할 때 유용하게 사용된다.

4) 특정 영역 일괄 바꾸기

일괄 바꾸기는 바꾸고자 하는 영역을 드래그한 후 '편집 > 선택 채우기' 로 지정된 블록 영역을 원하는 값으로 모두 바꿀 수 있다.

2. FTK Imager

포렌식의 가장 기본이 되는 FTK Imager는 디스크 이미징 작업에 많이 쓰인다. 이 밖에도 이미징 작업에 많이 쓰이는 소프트웨어로는 EnCase와 dd라는 도구가 있으며, 물리적인 하드디스크 이미징 전용 장비로는 Road Master, Rapid Image 등이 있다.

논리적인 이미징 방식은 다른 하드디스크에 이미지 파일( .011, .dd 등 )로 저장이 되며, 실제 하드디스크와 같은 용량을 차지한다. 물리적인 이미징 방식은 하드디스크를 다른 하드디스크에 그대로 복제하는 것을 말하며, 복사될 하드디스크는 원본 디스크보다 용량이 같거나 커야 한다. 또한, 소프트웨어 방식과 물리적 방식 모두 복사될 하드디스크는 충분한 와이핑 후 복사를 해야 무결성을 지킬 수 있다.

FTK Imager는 제작사 다운로드 페이지에서 이름과 이메일 주소를 등록하면 다운로드 링크를 등록한 이메일로 보내준다.

* FTK Imager 다운로드

http://accessdata.com/product-download/digital-forensics/ftk-imager-version-3.4.3

- FTK Imager 인터페이스

FTK Imager의 인터페이스는 Evidence Tree, File List, Property, Hex Value Interpreter, Custom Content Sources으로 나뉘어있다.

•Evidence Tree: 계층적 트리구조로 추가한 증거 항목을 보여준다.

•File List: Evidence Tree에서 선택된 항목에 있는 파일과 폴더를 보여준다.

•Viewer: Preview Mode 옵션인 Natural, Text, Hex 선택에 따라 선택된 파일의 내용을 보여준다.

•Custom Content Sources: 이미지에 포함된 내용을 보여준다.

•Properties/Hex Value interpreter: Evidence Tree이나 File List에서 선택된 객체의 다양한 정보를 보여주고, 뷰어에 선택된 16진수 값을 10진수와 가능한 날짜, 시간 값으로 변환한다.

1) 이미징 생성

상단의 'File > Add Evidence Item' 메뉴를 클릭하거나 화면에 보이는 File 메뉴바로 아래에 있는 플러스가 하나인 아이콘을 클릭하면 다음과 같은 화면을 보게 된다.

•Physical Drive: 실제 물리적으로 연결된 하드 드라이브의 목록을 보여준다.

•Logical Drive: 논리 드라이브를 볼 수 있다.

•Image File: 이미징이 된 파일들을 불러올 수 있는 메뉴이다.

•Contents of a Folder: 폴더를 선택할 때 사용된다.

여기에서는 Physical Drive를 눌러 원하는 물리적인 하드 드라이브를 FTK Imager에 마운팅 시켜보면 다음과 같은 화면이 나타난다.

Evidence Tree에 원하는 파티션 또는 물리적인 드라이브를 선택하고 우클릭을 하면 5가지의 메뉴가 나타난다.

•Remove Evidence Item: 추가한 아이템을 제거한다.

•Verify Drive/Image: 검증을 위한 작업이 실행되고 Export

•Disk Image: 이미징 작업을 위한 메뉴이다.

•Image Mounting: 실제 마운팅을 실행시켜주는 작업메뉴이다.

•Export Directory Listing: 해당 드라이브의 모든 파일과 폴더 구조를 추출해주는 메뉴이다.

Export Disk Image 메뉴를 선택하면 다음과 같은 화면이 나타난다.

'Add' 메뉴를 누르기 전 Add 아래에 있는 'Verify images after they are created' 메뉴를 선택하여 이미지 검증을 진행하는 것이 좋다. 디지털 포렌식에서 무결성은 매우 중요하기 때문이다.

Add 메뉴를 누르게 되면 저장할 이미지 타입과 간단한 분석관 이름, 사건번호를 적는 화면이 나타나게 된다. 이후 저장할 이미지 이름과 크기를 입력하는 창이 뜨게 된다. 이때 주의할 점은 크기에 따라 파일이 나뉘게 된다는 것이다.