Kali-KM_Security Study

Pulling the Plug

Forensic/Theory2017. 3. 22. 22:56

서론

이번 포스팅에서 다루고자 하는 주제는 바로 "Pulling the Plug" 이다. 단어 그대로 연결되어 있는 플러그를 뽑는다는 것으로 주로 장치의 강제 종료를 의미한다. PC 나 핸드폰 등 강제로 전원이나 배터리를 분리하여 종료시킨적이 한번 쯤은 있을 것이다. 필자의 경우 핸드폰에 대해서는 잘 모르니 PC 에 한해서만 이야기 해보고자 한다. 그렇다면 이 강제 종료에 대해 무슨 생각을 할 수 있기에 포스팅까지 할까? 


사실 별거 없다. 당연히 PC 에 무리가 간다는 것쯤이야 모두가 알고있다. 하지만 약간의 악성코드와 포렌식 측면의 고려 사항을 추가하면 고민해볼 가치는 있다고 생각한다. 필자도 포렌식에 대해서는 얕은 지식만 가지고 있어 깊이 다루기는 어렵지만 알고 있는 지식에 한해 이 주제에 대해 이야기해보고자 한다. 개인적인 의견이 다분하며 전문적인 내용은 거의 없으므로 시간이 많이 남는 사람들에 한해 가볍게 읽기를 권한다.





본론

정상적인 PC 종료 과정

PC 의 정상적인 종료 과정에는 무엇이 있는지 먼저 알아보자. Windows PC 의 종료 과정은 부팅과정 비하여 훨씬 간소화 된 절차를 거친다. 종료는 주로 CSRSS (Client/Server Runtime Subsystem) 및 WinLogon, 이 두 가지 구성 요소로 처리 된다. 대략적인 순서에 대해 알아보자.


Windows 에서 시스템 종료 명령을 내리면 ExitWindowsEx 함수를 호출한다. 이 함수는 RPC(원격 프로시저 호출) 을 사용하여 CSRSS 에게 시스템 종료 메시지를 보낸다. CSRSS가 이 메시지를 받은 후, WinLogon 에도 다른 메시지를 보낸다. 메시지를 받은 WinLogon 은 ExitWindowsEx 함수를 호출한 것이 자기 자신이 아님을 확인한다. 확인 후 자신이 호출한 것이 아니라면 사용자를 대신해 WinLogon 이 한번 더 ExitWindowsEx 함수를 호출한다.


두 번째 호출로 인해 CSRSS 에는 또 다시 RPC 를 통해 종료 메시지가 전달된다. 하지만 이번엔 위와 다르게 WinLogon 에서 ExitWindowsEx 함수가 호출된 것임을 확인하고 종료를 승인한다. 종료가 승인되면 CSRSS 는 각 사용자의 Interactive 세션에서 실행되는 모든 프로세스를 종료하는 작업을 수행한다. CSRSS 가 Interactive 사용자 세션에서 실행되고 있는 모든 프로세스를 종료할 때가 되면, 실행 중인 프로세스들의 셧다운 레벨 역순으로 종료 순서를 지정한다.


CSRSS 가 유저 세션 프로세스를 모두 종료한 뒤, shutdown 이 발생하고 있음을 세션 0에서 실행 중인 시스템 프로세스에 알린다. 이제 WinLogon 이 NtShutdownSystem 함수를 호출하며 제어를 반환한다. 그 다음 PoSetSystemPowerState 를 호출하며 아래의 작업을 진행한다.


 * I/O 관리자는 shutdown IRP 를 등록 된 모든 장치 드라이버에 보낸다. 이를 통해 각 장치 드라이버는 종료하기 전에 필수적으로 해야 할 작업을 수행한다. 

 * 메모리 관리자는 수정 된 메모리 페이지를 파일 데이터와 함께 디스크에 다시 기록한다.

 * 구성 관리자는 레지스트리 변경 사항을 각각의 하이브 파일에 기록하도록 한다.

 * I/O 관리자는 모든 파일 시스템 드라이버에 종료를 알려 변경 된 데이터 저장 등의 동작을 수행하도록 한다.

 * 마지막으로, 전원 관리자는 시스템 전원을 끄므로 shutdown 과정을 완료한다.


위와 같은 과정을 통해 정상적인 PC 의 종료를 확인할 수 있다.



비정상적인 PC 종료 과정

그렇다면 정상적인 종료가 아닌 '비정상적인' PC 종료에 대하여 간략히 알아보자. 우선 비정상적인 종료의 경우 위와 같이 특정 신호(API 호출이나 IRP 등)를 전달할 수 없게 된다. 특히 제목과 같이 전원 플러그를 바로 뽑아버린다면 정상적인 과정에서 볼 수 있던 Flush 작업이 모두 진행되지 않는다. 이로 인해 손실되는 데이터는 당연히 존재하게 된다.


PC 의 전원이 갑자기 차단되면 기존에 동작하고 있던 하드 디스크 표면에 물리적인 손상 또한 생길 수가 있다. 반복적인 손상은 하드디스크에 배드섹터를 유발 할 수 있으며, 이는 기능적인 측면 뿐만 아니라 여러 측면에서 불편함을 가지고 올 수 있다. 또한 위에서 언급했던 바와 같이 각 드라이버와 장치들이 수행하던 작업 데이터의 기록이 이루어지지 않는다. 변경 사항이 저장되지 않는다면 드라이버 동작 간에 문제를 유발할 수 있다. 그리고 개인적인 생각에서 문제가 될 수 있는 것은 사후 분석을 위한 데이터 수집 중 휘발성 데이터가 문제가 된다는 것이다. 우선 아래 RFC 3227 에서 언급하는 휘발성 데이터 순서를 보자.


 1. registers, cache
 2. routing table, arp cache,process table, kernel staistics, memory
 3. temporary file sysem
 4. disk
 5. remote logging and monitoring data that is relevant to the system in question
 6. physical configuration, network topology
 7. archival media 


휘발성 데이터의 경우 비휘발성 데이터보다 데이터 수집이 빠르게 이루어져야 한다. 그렇지 않다면 휘발성 데이터는 모두 손실될 수 있기 때문이다. 중요한 데이터는 디스크에 저장되어 있으니깐 상관없지 않느냐라고 할 수 있지만 메모리, 레지스터 등등 휘발성 데이터에도 중요한 데이터는 존재하고 있다. 


가령, Fileless 형태의 악성코드가 네트워크 연결을 통해 악성 실행 데이터를 받아와 메모리에서만 동작한다고 가정해보자. 동작 중인 악성코드에 의해 이상 징후를 느낀 사용자가 갑작스레 PC 를 종료하면 메모리에 있던 악성코드에 대한 정보는 모두 손실된다. 결국 사용자는 추후에도 어떤 악성코드에 의해 감염된 것인지 알기 어려울 것이다. 


이처럼 PC 를 강제 종료하는 것을 추천하는 경우는 결코 많지 않을 것이다.



결론

본론을 통해 PC 의 정상적인 종료 과정과, 그렇지 않은 경우에 나타날 수 있는 상황에 대하여 알아보았다. 사실 본론은 매우 편파적으로 'PC 를 강제 종료하면 안된다.' 라는 입장으로 쓰였다. 이렇게 서술한 이유는 모두가 알다시피 일반적인 상황에서는 PC 를 강제종료하지 않아야 한다는 것을 알고 있기 때문이다.


하지만 PC 를 강제 종료 해야할까? 라는 고민이 들 순간들에 대하여 몇 가지 언급해보자.

* 랜섬웨어에 의해 사용자 파일이 암호화 되고 있다.

* 어떠한 악성코드에 의해 PC 에 이상 증상(팝업 창 출력 등)이 연속적으로 나타나고 있다.


이러한 상황을 맞이한다면 어떻게 해야할까? 우선 필자가 위 상황에 놓인 경우 두 가지 행동으로 상황을 마무리 할 것이다. 첫째, 실행 중인 프로세스 목록을 확인하여 의심되는 프로세스를 종료한다. 하지만 의심되는 프로세스가 보이지 않고 종료했다하더라도 다시 실행되어 동작하는 경우를 가정하자. 그렇다면 둘째로 바로 PC 를 강제종료 시킬 것이다. 이렇게 하므로 악성코드의 동작을 저지할 수 있다.


대부분의 사용자는 이와 유사한 행동을 취할 것이라 생각한다. 하지만 개인이 아닌 기업의 입장에서 생각해보면 이는 큰 위험이 될 수 있다. 우선 운영 중인 서버에 악성코드가 나타났다고 생각해보자(참고로 서버를 잠시 종료해도 상관없다고 가정하자). 서버의 경우 하나의 개인이 아닌 기업이 가진 자산이다. 첫 번째 상황의 경우 랜섬웨어가 확실하다면 서버를 강제 종료해도 괜찮을 것이다. 하지만 두 번째 상황에 놓인 경우 역시 강제 종료하려 한다면 큰 리스크를 갖게 된다.

어떠한 악성코드인지 모르는 상황에서 섣불리 강제 종료해버린다면 그 증거들을 놓칠 수 있기 때문이다. 하지만 강제 종료하지 않는다면 서버 장치에서 어떠한 동작이 추가적으로 일어날지 모른다. 혹여나 악성코드에 대한 증거를 놓치면 그에 따른 치료 방향 또한 잡기 어려워지며, 이는 서버 장치 운영에 무리가 될 수 있다. 과연 어떠한 선택을 해야 할까.


사실 정답은 없다. 단지 어떠한 면을 우선으로 하느냐에 따라 강제종료 할 수도 있고, 하지 않을 수도 있다. 선택하는 사람의 몫인 것이다. 하지만 이러한 상황을 맞이하게 된다면 어떻게 행동해야 할지 한번 쯤 생각해보는 것도 나쁘지 않을까 생각한다.




참고자료

* OverClock, "Windows: The startup and shutdown process", http://www.overclock.net/t/1453560/windows-the-startup-and-shutdown-process

* faqs, "RFC 3227 - Guidelines for Evidence Collection and Archiving", http://www.faqs.org/rfcs/rfc3227.html#b

'Forensic > Theory' 카테고리의 다른 글

Pulling the Plug  (0) 2017.03.22
Unicode 확장자 변조(RLO)  (3) 2016.05.15
Windows Event Log (2) – 주요 이벤트 로그  (0) 2016.02.01
Windows Event Log (1) – 이벤트 로그의 개념  (2) 2016.02.01
Volume Shadow Copy 분석  (1) 2016.01.18
NTFS FIle System (9) $UsnJrnl  (0) 2016.01.16

Comment +0

지난 2005년 경부터 일부 피싱에 사용된 Unicode RLO 방식을 이용하여 악성코드의 확장자를 다른 형태로 보이도록 하는 형태의 악성코드가 지속적으로 나타나고 있다. 유니코드란 아스키 코드보다 더 크게 모든 문자를 표현하는 문자셋이라 할 수 있다. 각 나라마다 고유의 문자들이 있는데 이를 ASCII 문자로만으로는 표현할 수가 없다.


일반적으로 문자는 왼쪽에서 오른쪽으로 읽지만, 일부 국가에서는 오른쪽에서부터 문자를 읽기도 한다. 이를 컴퓨터에 표현하기 위한 Unicoode는 바로 0x202E로 "Right to Left Override"라는 문자이다. 해당 문자에 대한 정보는 아래와 같다.

이전부터 악성 파일과 관련되어 모르는 exe 파일은 열어보아서는 안된다라는 내용의 이야기는 많이 들을 수 있었다. 그렇기에 일반적인 사용자들도 더 이상 모르는 실행 파일을 함부로 실행시키지는 않는다. 그렇기에 공격자들은 이러한 확장자를 감추려 하거나 변조하는 등으로 사용자를 속이려 한다. 유니코드 확장자 변조에는 위에서 언급한 0x202E가 사용된다. 아래 파일을 보자.

위 그림에서 볼 수 있듯이 파일의 이름은 "testrcs.mp4"이다. 일반적으로 보았을 때 그냥 정상적인 MP4 파일과 같이 볼 수 있다. 하지만 우측의 파일 유형을 보면 '화면보호기(scr)'로 나타나는 것을 확인할 수 있다. 어떻게 된 것일까? CMD를 통해 해당 디렉터리에서 파일의 이름을 다시 확인해보자.

CMD를 통해 확인한 결과에서는 "test 4pm.scr"로 나타나는 것을 확인할 수 있다. 바로 test라는 문자열과 4pm 이라는 문자열 사이에 0x202E가 들어가 있는 것이다. 그렇기에 0x202E 이후의 내용 "4pm.scr"은 반전되어 "rcs.mp4"로 나타내는 것이다. 이를 통해 scr파일을 mp4파일로 착각하도록 할 수 있다.


그렇다면 직접 실습을 진행해보자. 우선 RLO 유니코드 문자를 가지고 와야하는데 이는 0x202E로 바로 나타내도 되지만 편리하게 문자열 셋에서 구할 수가 있다. Windows+R을 입력한 뒤 나타나는 창에 charmap을 입력해보자. 그렇다면 아래와 같은 문자표가 나타난다.

그 다음 '고급 보기'를 체크하여 나타나는 항목에서 유니코드로 이동에 "0x202E"를 입력해준다. 그렇다면 아래의 그림과 같이 나타나는데 해당 문자를 복사해주면 준비가 끝난다.

두 개의 파일 1234abcd.mal과 2234abcd.mal을 준비한다. 그리고 두 번째 파일에서 원하는 부분에 해당 문자를 복사해보자. 아래와 같이 "2234ablam.dc"로 출력되는 것을 확인할 수가 있다. 

이와 같이 확장자를 변조할 수가 있으며, 이에 추가적으로 해당 실행파일이 아이콘 또한 변조된 이름과 같이 보이게 하면 자연스럽게 실행을 유도할 수가 있다. 따라서 어떠한 파일이든 다운을 받았다면 실행을 시키지 말고, 파일의 이름을 한번 의심해보고 반드시 파일의 유형까지 확인해보아야 한다.



Reference


http://egloos.zum.com/voidns/v/2409436

http://cleverdj.tistory.com/48

http://viruslab.tistory.com/1986

http://www.fileformat.info/info/unicode/char/202e/index.htm

http://jvinci.tistory.com/228


'Forensic > Theory' 카테고리의 다른 글

Pulling the Plug  (0) 2017.03.22
Unicode 확장자 변조(RLO)  (3) 2016.05.15
Windows Event Log (2) – 주요 이벤트 로그  (0) 2016.02.01
Windows Event Log (1) – 이벤트 로그의 개념  (2) 2016.02.01
Volume Shadow Copy 분석  (1) 2016.01.18
NTFS FIle System (9) $UsnJrnl  (0) 2016.01.16

Comment +3

1. 개요


  이벤트 로그에 대하여 학습을 하기 위해 이벤트 ID에 대하여 알아보았다. 너무 많은 이벤트들이 존재하기에 어떤 이벤트가 중요한 것인지 불필요한지 직접 확인 하기에는 번거로움이 크다. 따라서 이번 문서에서는 많은 이벤트들 중에서 유심히 보아야 할 로그에 대하여 학습하고자 한다.

  이에 대하여 NSA에서는 Spotting the Adversary with Windows Event Log Monitoring에 대하여 글을 작성하였으며 이를 토대로 해당 문서를 작성하고자 한다. 위에서 언급한 해당 문서에서는 크게 16개의 카테고리에 대하여 설명을 한다. 이러한 로그에 대하여 학습해보자.

표 1. NSA – 16가지 이벤트 카테고리

  아래의 테이블은 각 카테고리와 이를 나타내는 이벤트 ID에 대하여 정리된 것이다. 이러한 표에서 몇 가지에 대하여 상세하게 알아보자.


2. 이벤트 카테고리


2.1 Application Whitelisting

  응용프로그램 화이트 리스트 이벤트는 차단된 응용 프로그램을 찾기 위해 수집되어야 한다. 차단된 응용프로그램들은 악의적일 수가 있으며, 승인되지 않은 소프트웨어의 실행을 시도하고자 한다. 응용프로그램 화이트 리스트 이벤트는 SRP(소프트웨어 제한 정책)이나 AppLocker가 네트워크 상에서 사용될 때 수집 될 수 있다.

그림 1. Whitelisting Events

2.2 Application Crashes

  응용 프로그램 충돌에 관한 이벤트들은 충돌이 발생했을 때, 이것이 악의적인 것에 의한 것인지 아닌지 판단하는데 도움을 준다. BSOD, Windows Error Reporting(WER), 응용 프로그램 충돌들은 이벤트를 발생시킨다. 만약 EMET(Microsoft Enhanced Mitigation Experience Toolkit)을 사용하고 있다면, EMET 로그들도 수집될 것이다.

그림 2. Application Events

2.3 System or Service Failures

  시스템과 서비스 실패는 조사하는데 있어 흥미로운 이벤트들이다. 서비스 동작은 보통 실패하지 않는다. 만약 서비스가 실패했을 경우, 관리자로서 이를 검토하여야 한다. 만약 윈도우 서비스가 지속적으로 실패할 경우, 이는 공격자가 해당 서비스를 대상으로 하고 있음을 나타내는 것이다.

그림 3. System Events

2.4 Windows Update Errors

  컴퓨터는 알려진 취약점을 대비하기 위하여 최신 상태를 유지해야 한다. 그럴 가능성은 거의 없지만, 이러한 패치가 때로는 적용하는데 실패하기도 한다. 업데이트를 실패하는 것은 운영체제나 응용프로그램의 취약점을 피하기 위하여 해결해야만 한다.

그림 4. Windows Update Failed Event

2.5 Windows Firewall

  만약 클라이언트 환경이 호스트 기반의 윈도우 방화벽의 사용하고 있다면, 방화벽의 상태를 나타내는 이벤트들이 수집된다. 예를 들어, 만약 방화벽이 활성화에서 비활성화로 전환된다면 이에 대한 로그가 남는 것이다. 일반적인 사용자는 방화벽의 상태나 규칙을 변경하지 않는다.

그림 5. Firewall Events

2.6 Clearing Event Logs

  정상적인 동작을 하는 동안 이벤트 로그 데이터가 지워질 가능성은 거의 없으며, 악의적인 공격자들이 그들의 행동을 감추기 위해 이벤트 로그를 지웠을 가능성은 높다. 이벤트 로그가 지워져을 때 이는 분명히 의심할 만한 사항이다. 이벤트 로그를 수집하는 것은 공격자가 자신의 행동을 감추기 더 어렵게 하는 이점이 있다.

  하지만 공격자가 이벤트를 지웠을 경우 이것이 새로운 이벤트로 기록이 된다. 따라서 로그를 지웠다는 새로운 이벤트가 발견된다면, 이에 맞게 추가적인 행동을 취해야 한다. 가령 VSS를 확인한다거나 삭제된 로그를 복구하는 조치를 취하면 좋을 것이다.

그림 6. Log Activity Events

2.7 Software and Service Installation

  일반적인 네트워크 동작의 일부로써, 새로운 소프트웨어나 서비스가 설치되며 이러한 활동에 대해서 이벤트가 생성 된다. 관리자들은 새롭게 설치된 소프트웨어나 시스템 서비스에 대한 로그를 통해 확인할 수가 있으며, 네트워크에 위험하지 않은지 추가적인 확인할 수가 있다.

그림 7. Software and Service Events

  여기서 이벤트 ID 800에 대하여 알아야 더 언급하자면, 윈도우 7에서 해당 이벤트는 매일 오전 12:30에 응용프로그램 활동에 대하여 요약을 제공하기 위하여 생성된다. 이 이벤트는 설치되거나 제거된 응용 프로그램의 수를 찾는 관리자들에게 편의를 제공할 것이다.

2.8 Account Usage

  사용자 계정 정보는 수집과 감사 될 수가 있다. 로컬 계정 사용을 추적하는 것은 Pass the Hash 활동과 인가되지 않은 다른 계정의 사용을 탐지할 수 있게 도와준다. 원격 데스크톱 로그인 이나 권한 그룹에 사용자를 추가하거나, 계정 잠금과 같은 추가적인 정보들은 추적될 수가 있다.

  권한 그룹에 추가된 사용자 계정은 실제로 권한 그룹에 속한 사용자임을 보증하기 위하여 더 면밀히 감시되어야 한다. 권한 그룹의 인가되지 않은 멤버는 악의적인 활동이 발생할 수 있음을 나타낸다.

그림 8. Account Activity Events

  도메인 계정 잠금 이벤트는 로컬 계정 잠금 이벤트가 로컬 컴퓨터에 생성되는 것에 반하여 도메인 컨트롤러에 생성된다. 또 위에서 성공적으로 사용자 계정에 로그인한 이벤트 (ID: 4624)에서는 로그온 유형에 대하여 반드시 확인해주어야 한다. 이에 대한 설명은 2.15의 로그온 유형 표를 참고하자.

2.9 Kernel Driver Signing

  윈도우 비스타 64비트에서 커널 드라이브 서명은 커널에 악의적인 드라이버들이나 행동이 삽입되는 것에 대해 막도록 하는 효과가 있다. 변경되어 보호되고 있는 드라이버의 표시는 악의적인 활동을 나타낼 수가 있거나 디스크 에러와 조사를 보장한다.

그림 9. Kernel Driver Signing Events

2.10 Group Policy Errors

  도메인 컴퓨터의 관리는 관리자가 보안과 그룹 정책의 규제를 높이는 것을 허가한다. 그룹 정책 에러로 인해 정책을 적용하지 못하는 것은 보안의 안전함을 감소시킨다. 따라서 관리자는 즉시 이러한 이벤트들에 대해 조사하여야 한다.

그림 10. Group Policy Errors Events

2.11 Windows Defender Activities

  Spyware나 Malware는 심각한 문제들을 남기기에 마이크로소프트는 Windows Defender라는 Anti-Spyware와 Anti-Virus를 개발하였다. 이러한 악의적인 프로그램을 감지, 제거, 예방한다는 알림은 조사되어야 한다. Windows Defender가 도작하는데 실패했다는 알림은, 관리자가 추가적인 감염이나 이러한 가능성을 방지하기 위해 즉시 올바르게 만들어야 한다. 만약 서드파티 안티바이러스나 안티스파이웨어 제품이 올바르게 사용되고 있다면, 이러한 로그는 필요하지 않다.

그림 11. Windows Defender Activities Event

2.12 Mobile Device Activities

  무선 장치들은 많은 곳에 존재하며 기업의 무선 장치 활동을 기록하는 것은 중요하다. 프로토콜에 관계 없이 통신을 위해 사용되는 무선장치들은 다른 네트워크를 오가며 손상될 수가 있다. 그러므로 어떤 휴대용 네트워크 장치를 추적하는 것은 손상이 일어나는 것을 방지하는데 유용하다. 아래의 이벤트들의 생성은 얼마나 자주 장치를 연결해제 하거나, 재연결 하는 가에 따라 빈번히 생성된다.

그림 12. Mobility related Events

2.13 External Media Detection

  USB 장치를 감지하는 것은 많은 환경에서 중요하다. 아래의 나타나는 이벤트와 이벤트 로그들은 오직 윈도우 8 이상에서만 사용이 가능하다.

그림 13. External Media Detection Events

  만약 윈도우 7이하의 경우에는 Microsoft-Windows-Driverframeworks-Usermode를 확인하면 된다. 해당 부분에서 이벤트 ID 1003, 2000, 2001, 1004를 통하여 USB가 연결되었다는 것을 확인할 수가 있으며 반대로 해당 USB가 해제된 것은 1006, 1008, 2900, 2901 등을 통해 확인할 수가 있다.

2.14 Printing Services

  문서를 인쇄하는 것은 많은 환경에서 일상적인 작업을 위해 필수적이다. 매우 많은 양의 인쇄는 어떤 문서가 인쇄되었는지, 누구의 것인지에 대하여 추적하거나 확인하는데 있어 어렵게 한다. 처리를 위해 프린터로 전달되는 문서들은 다양한 방식으로 로깅하기 위해 기록될 수 있다.

  각 인쇄 작업은 프린터 서버나 프린터 그 자체 또는 요청된 기계에 기록될 수가 있다. 이러한 동작들에 대한 로그를 기록하는 것은 인쇄된 특정 문서들을 발견할 수가 있다. 아래의 이벤트들은 문서를 인쇄하기 위해 요청되는 클라이언트 장비에서 생성된 것이다.

그림 14. Printing Services Events

2.15 Pass the Hash Detection

  사용자 계정에 Pass the Hash(PTH)를 검출하는 것은 XML로 고급 필터링 옵션을 구성하는 커스텀 뷰를 생성하는 것이 요구된다. 이벤트 쿼리 언어는 XPath에 기반한다. 아래의 추천된 쿼리 리스트는 PTH 공격을 감지하는데 제한된다. 이러한 쿼리들은 도메인의 일부가 아닌 로컬 계정을 사용하는 공격자의 행동을 밝히는데 초점이 맞추어져 있다.

  아래의 쿼리 리스트는 도메인의 일부가 아닌 다른 장치로 원격 연결을 시도하는 로컬 계정이 보여주는 이벤트들을 포착한다. 아래의 XPath 쿼리들은 이벤트 뷰어의 Custom Views를 통해 사용된다.

  성공적인 PTH은 Securiy Log의 이벤트 ID 4624를 야기한다. 도메인 로그온이 아닌 익명의 NTLM 인증은 로그온 유형이 3으로 나타난다. 아래에는 해당 이벤트에 대한 설명이 나와있으며 아래의 표에서 로그온 유형에 따른 설명들을 확인할 수가 있다.

그림 15. Logon Success – PTH Event

표 2. Logon Type

  로그온 유형에 따라 해당 로그인의 의미가 많이 중요해질 수가 있으므로 위의 표를 상기하여야 한다. 아래에 있는 쿼리 리스트에서 <DOMAIN NAME>에 실제 도메인 이름을 넣어주면 해당 쿼리가 올바르게 동작한다.

<QueryList>

<Query Id="0" Path="ForwardedEvents">

<Select Path="ForwardedEvents">

*[System[(Level=4 or Level=0) and (EventID=4624)]]

and

*[EventData[Data[@Name='LogonType'] and (Data='3')]]

and

*[EventData[Data[@Name='AuthenticationPackageName'] = 'NTLM']]

and

*[EventData[Data[@Name='TargetUserName'] != 'ANONYMOUS LOGON']]

and

*[EventData[Data[@Name='TargetDomainName'] != '<DOMAIN NAME>']]

</Select>

</Query>

</QueryList> 

  PTH를 통한 로그온 시도에 실패했을 경우 이는 이벤트 ID 4625를 야기한다. 이 역시 로그온 타입이 3으로 도메인 로그온이 아닌 익명의 로그온 계정이 NTLM 인증을 하고자 할 때 생성된다.

그림 16. Logon Fail – PTH Events

<QueryList>

<Query Id="0" Path="ForwardedEvents">

<Select Path="ForwardedEvents">

*[System[(Level=4 or Level=0) and (EventID=4625)]]

and

*[EventData[Data[@Name='LogonType'] and (Data='3')]]

and

*[EventData[Data[@Name='AuthenticationPackageName'] = 'NTLM']]

and

*[EventData[Data[@Name='TargetUserName'] != 'ANONYMOUS LOGON']]

and

*[EventData[Data[@Name='TargetDomainName'] != '<DOMAIN NAME>']]

</Select>

</Query>

</QueryList>

2.16 Remote Desktop Logon Detection

  원격 데스크탑 계정 활동 이벤트는 GUI 이벤트 뷰어를 통해 확인하기 쉽지 않다. 계정이 원격으로 클라이언트에 연결될 때, 일반적인 로그온 성공 이벤트가 생성된다. 커스텀 쿼리 필터는 행해진 로그온 유형을 분류하는데 도움을 줄 수 있다. 아래의 쿼리는 원격 데스크톱을 사용한 로그인을 보여준다. 원격 데스크톱 활동은 특정 관리자가 이를 사용하며 이는 제한된 설정에서 진행되어야 한다. 또한 이러한 활동은 모니터링 되어야만 한다. 만약 예상치 못한 로그인 활동이 있을 경우 이에 대해선 반드시 조사하여야 한다.

  아래의 XPath 쿼리는 이벤트 뷰어의 커스텀 뷰를 통해 사용된다. 이벤트 ID 4624와 4634는 각 각 언제 사용자가 로그온 했는지, 로그오프 했는지를 나타낸다. 로그온 타입 10은 이러한 원격 로그인에 대해 나타낸다.

그림 17. Remote Desktop Login Events

<QueryList>

<Query Id="0" Path="ForwardedEvents">

<Select Path="ForwardedEvents">

<!-- Collects Logon and Logoffs of RDP -->

<!-- Remote Desktop Protocol Connections -->

*[System[(Level=4 or Level=0) and (EventID=4624 or EventID=4634)]]

and

*[EventData[Data[@Name='LogonType']='10')]]

and

(*[EventData[Data[5]='10')]]

or

*[EventData[Data[@Name='AuthenticationPackageName'] = 'Negotiate']])

</Select>

</Query>

</QueryList>

 

3. 결론


2장의 내용을 통하여 어떠한 로그들이 어떠한 용도로 활용되어야 하는지에 대하여 알아보았다. 위의 내용이 옳다는 것만은 아니다. 당연히 이외에도 유심히 보아야 할 이벤트로그는 많이 존재할 것이다. 그러한 추가적인 내용을 공부하기 전에 이번 문서를 통해 어떠한 식으로 접근하여야 하는가에 대하여 알아보았다고 할 수 있다.

이벤트 로그를 공부하면서 많은 이벤트를 접하게 될 때 www.eventid.net/을 통해 찾아볼 수 있으며, 대부분의 경우 구글에 검색하면 많은 정보들을 볼 수가 있다.

  

출처


* 블로그, Spotting the Adversary with Windows Event Log Monitoring

http://www.redblue.team/2015/09/spotting-adversary-with-windows-event.html

* 블로그, 윈도우 이벤트 로그 분석 #기초

http://elven.kr/archives/361

* 문서, Spotting the Adversary with Windows Event Log Monitoring.pdf

    https://www.nsa.gov/ia/_files/app/spotting_the_adversary_with_windows_event_log_monitoring.pdf

'Forensic > Theory' 카테고리의 다른 글

Pulling the Plug  (0) 2017.03.22
Unicode 확장자 변조(RLO)  (3) 2016.05.15
Windows Event Log (2) – 주요 이벤트 로그  (0) 2016.02.01
Windows Event Log (1) – 이벤트 로그의 개념  (2) 2016.02.01
Volume Shadow Copy 분석  (1) 2016.01.18
NTFS FIle System (9) $UsnJrnl  (0) 2016.01.16

Comment +0

1. 이벤트 로그


  로그란 감사 설정된 시스템의 모든 기록을 담고 있는 데이터라 할 수 있다. 이러한 데이터에는 성능, 오류, 경고 및 운영 정보 등의 중요 정보가 기록되며, 특별한 형태의 기준에 따라 숫자와 기호 등으로 이루어져 있다. 이러한 로그는 운영체제가 업그레이드 됨에 따라 버전 별로 형태와 경로가 조금 상이하다. 각 운영체제 별 이벤트 로그의 특징은 아래의 그림과 같다.


그림 1. 운영체제 별 로그 특징


  이러한 로그를 분석하여 필요로 하는 유용한 정보를 만들어 낼 수가 있으며 로그 데이터 분석을 통해 얻을 수 있는 정보는 다음과 같이 다양하게 활용될 수가 있다.


표 1. 로그 데이터 분석의 활용


  이러한 로그 데이터는 시스템에서 발생하는 모든 문제에 대한 유일한 단서가 될 수 있으며, 시스템에서 발생한 오류 및 보안 결함에 대하여 검색이 가능하다. 또한 잠재적인 시스템 문제를 예측하는데 사용할 수가 있다.

  장애 발생시 복구에 필요한 정보로 활용하거나, 침해 사고가 발생된 경우 로그에 남아 있는 근거들을 자료로 활용할 수가 있다. 이렇게 살펴본 바와 같이 로그 데이터는 중요한 의미를 가지고 있으며, 그렇기에 올바른 분석이 더욱 요구 된다.



2. 로그 관리 및 분석


  로그 분석에 필요한 정보로는 로그 설정 방법, 파일의 저장 위치, 로그에서 나타내는 정보를 말할 수가 있다. 그리고 로그를 관리하기 위해서는 로그의 실시간 저장 및 무결성을 확보해야 하는데, 이를 위해선 시스템의 로컬에 로그를 저장하기 보다는 원격 로그서버를 구축하거나 DB서버와 연동하는 방식도 사용된다. 기초적인 Windows의 로그에 대하여 알아보자.


2.1 이벤트 로그의 이해

  Windows 시스템에서는 시스템의 로그가 이벤트 로그형식으로 관리되며, 이벤트 로그를 확인하기 위해서는 Windows의 Event Viewer를 이용하여야 한다. Event Viewer를 실행시키면 아래의 그림과 같은 모습을 나타내는 것을 확인할 수가 있다.


그림 2. 윈도우 이벤트 뷰어


  Windows 시스템은 응용 프로그램 로그, 보안 로그, 시스템 로그와 같이 세 가지 로그를 이벤트에 기록하며, OS 구성에 따라 디렉터리 서비스 로그, 파일 복제 서비스 로그, DNS 서버 로그가 추가될 수가 있다. 주요 이벤트 별 특징은 다음과 같다.


표 2. Windows 시스템 이벤트 로그 종류


이러한 로그들은 이벤트 뷰어를 통해 쉽게 확인할 수가 있다. 그렇다면 이벤트 뷰어를 통해 어떻게 나타나는지 아래의 그림을 통해 확인해보자.


그림 3. 이벤트 헤더와 설명


  각 이벤트를 확인하면 위와 같은 정보들이 나타난다. 위의 상자와 같은 부분에서 어떠한 경로에 있는지 등에 대한 정보가 있으며, 아래에는 해당 이벤트에 대한 정보들이 나타나 있다. 상단의 탭에서 Details를 누르면 좀 더 많은 정보들을 확인할 수가 있다.

  위 그림에서 하단의 Level이라 되어 있는 곳을 보자. Level에는 Information이라 되어 있다. 이처럼 이벤트 뷰어에서는 이벤트의 형태를 다섯 가지의 유형으로 구분한다. 이러한 다섯 가지 유형에 대해 아래의 그림을 통해 확인하자.


표 3. 이벤트 유형


2.2 이벤트 로그 설정 확인

  이벤트 로그에 대하여 개략적으로 알아보았다. 그렇다면 이러한 이벤트 로그의 설정을 확인하는 방법에 대하여 알아보자. 이벤트 로그를 설정하기 위해선 크게 두 가지 방법이 있으며 바로 레지스트리를 이용하는 방법과 이벤트 뷰어를 이용하는 방법이다. 이에 대해 알아보자.


레지스트리를 통한 확인

  레지스트리를 통해 확인하는 방법에 대하여 먼저 알아보자. 우선 Win+R을 통해 실행 창이 나타나면 regedit를 입력하여 레지스트리 편집기를 띄우자. 그리고 아래의 경로로 이동하면 이벤트 로그에 관한 설정이 나타나는 것을 확인할 수가 있다.


그림 4. 레지스트리를 통한 이벤트 로그 설정

위와 같이 나타나는 것을 확인할 수가 있다. 좌측의 키에는 응용프로그램, 보안, 시스템 등이 존재하는 것을 확인할 수가 있다. 우측은 각 항목들을 통해 로그에 대한 설정이 기록되어 있는 것을 확인할 수가 있다. 몇 가지 항목이 의미하는 것에 대하여 알아보자.

표 4. 레지스트리 - 항목 설명


이벤트 뷰어를 통한 확인

이벤트 뷰어에서도 각 이벤트 로그에 대한 속성을 변경할 수가 있다. 해당 속성을 변경하고자 한다면, 해당 이벤트의 속성에 들어가야 한다. 아래의 그림을 보자.


그림 5. 이벤트 뷰어 - Disabled


  현재 위의 그림에서 붉게 표시한 바와 같이, Driverframeworks-UserMode는 모니터링 설정이 되어 있지 않은 것을 확인할 수가 없다. 만약 모니터링 되고 있지 않은 항목에 대하여 모니터링이 필요하다고 생각되면 우측을 클릭하면 된다.


그림 6. 이벤트 뷰어 – 설정


우클릭을 하여 나타나는 목록 중에서 Properties에 들어가서 설정을 할 수가 있으며, Properties 밑에 있는 Enable Log를 통해서도 모니터링 하도록 설정할 수가 있다. 이렇게 설정을 바꾼 뒤, 해당 이벤트가 발생하게 되면 로그가 남는 것을 확인할 수가 있다.


그림 7. 이벤트 뷰어 - Enable

 

  

3. 이벤트 로그 감사 정책


  감사정책이란 개체 액세스, 로그온/로그오프, 감사 정책 설정 변경 등의 보안 관련 로그를 기록하며, 지정한 이벤트 범주의 사용자나 시스템 동작을 기록하도록 정책 설정이 가능하다. 감사 정책의 자세한 설명 및 로그 관리를 위한 권장 값은 다음과 같다.


표 5. 감사 정책 권장 값


3.1 로컬 보안 정책 설정

  이러한 감사 정책을 확인하기 위해 로컬 보안 정책을 확인해보자. 제어판에서 관리도구 중 로컬 보안 정책을 선택하거나 Local Security Policy를 찾아서 실행한 다음 Local Policies의 하위에 있는 Audit Policy를 확인하면 된다. 아래의 그림을 보자.


그림 8. Local Security Policy


  위와 같이 설정되어 있는 것을 확인할 수가 있다. 현재 감사하지 않음으로 되어 있는 것을 확인할 수가 있다. 이를 감사로 변경하면 감사가 시작된다. 이러한 감사정책을 구성하기 전에 유의해야 할 사항들에 대하여 알아보자.

  첫 째, 지나친 감사 범위 설정은 중요 로그 검색에 어려움을 동반한다. 불필요한 로그까지 저장되기 때문에, 검색의 어려움뿐만 아니라 시스템의 성능 저하 및 로그 관리의 어려움을 발생 시킬 수 있으므로 시스템 감사 구성에 필요한 항목을 사전에 선정하여야 한다.

  둘 째, 잘못된 이벤트 로그 크기 설정은 용량 한계로 시스템이 중지될 수가 있다. 시스템 장애가 발생한다는 것은 서비스를 위해 서버를 운영하는 기업에서는 많은 손실을 야기할 수 있다. Windows는 이러한 문제를 방지하기 위해 기본 설정으로 오래된 항목을 덮어씌우는 옵션이 설정되어 있다.


3.2 보안 템플릿을 통한 감사 정책 구성

  보안 템플릿이란 보안 구성을 표시하는 파일로 로컬 컴퓨터 및 그룹 정책 개체를 적용하거나 보안 분석에 사용된다. 이러한 보안 템플릿을 이용하면 손쉽게 감사 정책 구성을 공유할 수가 있고, 반대로 공유된 감사 정책을 구성할 수가 있다.


그림 9. 보안 템플릿 구성


  템플릿을 구성하는 방법은 위의 그림과 같다. 좌측의 키에서 Security Settings에 놓고 상단 탭의 Action을 선택하면 위와 같이 나타나는 것을 확인할 수가 있다. Import Policy를 선택하면 다른 템플릿을 통해 감사 정책을 구성할 수가 있다.

  반대로 현재의 감사 정책 구성을 다른 PC에 공유하거나 백업해놓고자 할 경우 Export Policy를 선택하여야 한다. 선택 후 저장 경로를 설정해주면 *.inf와 같은 형식으로 저장이 되는 것을 확인할 수가 있을 것이다.



4. 보안 감사 이벤트 설명


그렇다면 어떤 이벤트를 보아야 할까? 우선 이벤트 로그는 기존의 Evt에서 비스타 이후 부터 Evtx로 사용되고 있다. 실제 로그 파일의 헤더 및 구성의 변경이 있지만 대부분의 이벤트가 Evt ID 값에 4096 값을 더해주면Evtx 형태의 이벤트 ID 값이 된다. 각 감사에 따른 주요한 이벤트들의 목록의 아래의 표들과 같다. [표 출처 - http://elven.kr/archives/361 ]


개체 액세스 검사
파일, 폴더, 레지스트리 등 개체에 액세스 하는 사용자의 이벤트를 감시할지 여부를 결정합니다.
개체에 대한 접근 성공 여부를 감사하며, 개체 액세스 감사를 실행하면 보안 로그에 관련 로그가 기록됩니다.

 Type 1 – 이벤트 ID Type 2 – 이벤트 ID내용
 5604656개체에 대한 접근 허가
 5624658개체에 대한 핸들 닫힘 – 이벤트 종료
 5634659삭제할 목적으로 개체에 접근
 5644660보호된 개체의 삭제

계정 관리 감사
컴퓨터의 각 계정 관리 이벤트를 감사할지 여부를 결정합니다.
해당 이벤트의 예로는 사용자 계정 및 그룹 생성/수정/삭제, 암호 설정 및 변경 등이 해당됩니다.

 Type 1 – 이벤트 ID Type 2 – 이벤트 ID내용
6244720사용자 계정 생성
625 사용자 계정 유형 변경
6264722사용할 수 있는 사용자 계정
6274723암호 변경 시도
6284724사용자 계정 암호 설정
6294725사용하지 않는 사용자 계정
6304726삭제된 사용자 계정
6364732보안 사용 로컬 그룹 구성원 추가
6374733보안 사용 로컬 그룹 구성원 제거
6424738변경된 사용자 계정
643 변경된 도메인 정책
6444740사용자 계정 잠김

계정 로그온 이벤트 감사
계정 유효성을 검사하는 컴퓨터가 아닌 다른 컴퓨터에서의 로그온/로그오프 감사 여부를 결정합니다.
해당 감사 항목은 침입 감지에 유용하게 사용할 수 있습니다.

 Type 1 – 이벤트 ID Type 2 – 이벤트 ID내용
6804776로그인 성공 정보
6814777로그인 실패 정보

로그인 이벤트 감사
감사 이벤트를 기록하는 컴퓨터에 대해 사용자 로그온/로그오프 또는 네트워크 연결의 각 인스턴스 감사 여부를 결정합니다.
성공 감사는 로그온 시도가 성공할 때 생성되며, 이 항목은 침입 감지에 유용하게 사용할 수 있습니다.
해당 감사는 계정 로그온 이벤트 감사 보다 상제 정보를 로깅합니다.

 Type 1 – 이벤트 ID Type 2 – 이벤트 ID내용
5284624성공적인 로그인
5294625알 수 없는 계정이나 잘못된 암호를 이용한 로그인 시도
530 로그인 시 허용 시간 이내에 로그인 실패
531 사용지 금지된 계정을 통한 로그인 시도
532 사용 기간이 만료된 계정을 통한 로그인 시도
533 로그인이 허용되지 않은 계정을 통한 로그인 시도
534 허용되지 않은 로그인 유형을 통한 로그인 시도
535 암호 사용 기간 만료
537 위의 사항에 해당되지 않으나 로그인에 실패한 경우
5384634로그오프
539 로그인하려는 계정이 잠겨 있음
540 로그인 성공

프로세스 추적 감사
프로세스 활성화/종료 및 간접적 개체 액세스 등의 이벤트에 대한 자세한 추적 정보를 감사할지 여부를 결정합니다.
윈도우 XP SP2 및 서버 2003 SP1 이상에서 프로세스 추적 감사를 사용하면 윈도우 방화벽 구성 요소의 작동 모드 및 상태에 대한 정보도 기록합니다.

 Type 1 – 이벤트 ID Type 2 – 이벤트 ID내용
5924688새 프로세스 생성
5934689프로세스 종료
5944690개체에 대한 힌트의 중복
5954691개체에 대한 간접적인 접근

시스템 이벤트 감사
컴퓨터를 다시 시작하거나 종료할 경우 또는 컴퓨터 보안이나 보안 로그에 영향을 주는 이벤트가 발생할 경우 이를 감사할지 여부를 결정합니다. 이러한 이벤트는 매우 중요하기 때문에 조직의 모든 컴퓨터에 대하여 이 정책 설정을 [사용] 설정할 필요가 있습니다.

 Type 1 – 이벤트 ID Type 2 – 이벤트 ID내용
5124608윈도우 시동
5134609윈도우 종료
5144610LSA (Local Security Authority) 인증 패키지 로드
5154611신뢰할 수 있는 로그인 프로세스가 LSA로 등록
5164612저장 공간의 부족으로 인해 보안 이벤트 메세지 손실
517 보안 로그 삭제

로그온 유형에 따라 아래와 같이 분류할 수 있습니다.
이 중에서 “로그온 유형 10” 의 경우 원격 접속 이벤트로 사고 분석 시 가장 빈번히 활용됩니다.

로그온 유형 2대화식콘솔에서 키보드로 로그인 (KVM 포함)
로그온 유형 3네트워크네트워크를 통한 원격 로그인 (파일 공유, IIS 접속 등)
로그온 유형 4스케쥴스케쥴에 등록된 배치 작업 실행 시 미리 설정된 계정 정보로 로그인
로그온 유형 5서비스서비스가 실행될 때 미리 설정된 계정 정보로 로그인
로그온 유형 7잠금해제화면보호기 잠금 해제시
로그온 유형 8네트워크유형 3과 비슷하나 계정 정보를 평문으로 전송할 때 발생
로그온 유형 9새자격실행(RunAS)에서 프로그램 실행 시 /netonly 옵션을 줄 때
로그온 유형 10원격 대화식터미널 서비스, 원격 접속, 원격지원으로 로그인
로그온 유형 11캐시된 캐화식PC에 캐시로 저장된 암호로 자동 입력 로그인

  위의 표는 보안 감사 정책에 따라 구분된 것으로 실제 이벤트 뷰어를 통해서 확인할 때는 해당 항목을 찾는데 번거로움이 있을 수 있다. 따라서 아래의 그림과 같이 주요한 몇 개의 이벤트만 따로 정리할 수가 있다.



출처


* 블로그, 윈도우 이벤트 로그 분석 #기초

* 안랩, 전문가 칼럼, 윈도우 로그 관리 및 분석 방법

* MSDN, 보안 템플릿 정의


Comment +2

  • 감사합니다 2019.11.10 04:29

    좋은 정보 감사합니다~
    그럼 혹시 usb를 컴퓨터에 연결하면 “이벤트 뷰어-windows 로그-보안” 이곳에 작업범주 logon(이벤트 id 4624)랑 special logon(이벤트 id 4672)로 저장이 되어 보여지나요?

  • 감사합니다 2019.11.10 05:06

    안녕하세요 너무 좋은 정보 감사드립니다!’급한 마음에 이렇게 긴 질문을 드리게 됐는데 질문 드려도 괜찮을까요?ㅠㅠ
    너무너무 감사합니다ㅜㅜ
    1. usb가 접속되는 것을 로그로 모니터링 하도록 컴퓨터에 지정하지 않았을 경우에도, windows로그/보안에서 usb 꽂은 시간에 logon 됐다고 뜨면 usb 꽂은 걸로 알 수 있을까요?
    2. 제가 특정 시간에 usb가 연결 됐는지 알고 싶은데
    그 시간 동안(10분 넘게) windows로그/보안에 아무 이벤트도 저장된게 없으면 그 시간에 usb를 연결하지 않았다고 생각해도 될까요?

  1.  요약


  중요한 파일이 유출되었을 경우 많은 상황들이 나타날 수가 있다. 이러한 많은 상황들 중 이번 문서에서는 USB를 통해 문서파일이 유출된 경우에 대하여 다루어보았다. 따라서 이외의 상황에 대해선 다루지 않는다.

  문서 유출과 관련되어 기술적인 측면만으론 정확하게 확인하기가 힘든 것은 사실이다. 그래도 그러한 가능성의 여부를 좀 더 확인하고자 하는 것은 충분히 가능하다. 특정 파일이 유출되었는가를 확인하기 위해선 이후에 설명할 바와 같이, 하나의 요소만으로는 확인할 수가 없다.

  남겨진 여러 가지의 흔적들의 연관성을 통해 당시 그 상황에 어떠한 일이 이루어졌는지를 확인하므로, 당사자가 하지 말아야 할 행동을 했거나 의심되는 행동을 했는지 확인하는 과정이 될 것이다.남아 있는 흔적의 수가 하나 하나 늘어날수록 더 유용할 수도 있지만, 오히려 분석을 하는데 있어 시간을 지체하게 만들기도 한다.

  PC에서 문서가 열람이 된 경우 남는 흔적들을 통해 본인이 자리를 비웠을 때 어떠한 문서들이 열람되었는지를 확인할 수가 있으며, USB를 통해 유출된 경우 USB 연결 흔적과 USB에서 문서를 열람했다면 좀 더 결정적인 흔적이 남는다.

  가장 많은 흔적이 남는 부분은 레지스트리이지만, RecentDocs의 항목만으로는 유출에 대하여 확정 짓기에는 많이 부족한 감이 있다. 따라서 레지스트리 외에도 프리패치, 링크파일 등을 통해서 종합적으로 추론할 수가 있다.


2. 개요


  일반적으로 특정 파일이 의도치 않게 유출 되는 경우가 발생할 수 있다. 가령 같은 직장의 다른 직원이 내 PC의 중요파일이나 기밀 문서 등을 가져가므로 유출되었을 수가 있다. 이러한 사항들로 인해 많은 사람들이 유출 여부를 확인하고자 하지만 막상 구체적인 방법에 대해 제시된 글은 많지 않다.

  실제로 특정파일이 유출되는 경우와 관련해서는 많은 사항들을 고려해야 한다. 하지만 이 모든 것을 다루기에는 어려우므로 한정적인 상황에 대해서나마 방법에 대하여 고려해보자. 기술적인 측면뿐 아니라 심리적인 측면 또한 들어가므로 유념하여야 한다.

2.1 실습 준비

  많은 사항들 중 USB를 통해 PC의 파일이 유출되는 경우에 한해 다룰 것이다. 따라서 특정 파일을 가지고 있는 PC와 USB가 있어야 한다. 그리고 실습을 위해 특정 파일을 3가지 준비하였다. 주로 문서와 관련한 사항이 중요하므로 이에 대하여 초점을 맞추었다.

그림 1. Target File List

  이외에 EXE파일이나, USB를 통한 유출이 아닌 부분은 여기서 다루지 않을 것이다. 문서에서 가장 자주 쓰이는 3가지 종류로 PDF, MSWord, HWP를 가지고 이제 어떠한 방향으로 접근해야 할 지 알아보자.

2.2 접근 방향

  특정 파일들을 준비하였으므로, 어떻게 접근할 것인가에 대해 먼저 논의할 것이다. 그리고 이러한 방향에 대하여 직접 실습을 통한 작업을 첨부하여 더 자세하게 알아볼 것이다.

  PC를 만든 것은 결국 인간이며, 범죄를 저지르는 사람도 결국 인간이다. 따라서 기술적인 측면뿐만 아니라 심리적인 요소 또한 고려를 해야 편협적이지 않게 접근할 수가 있다. 한번 직접 범법자가 되었다 생각하고 타인의 PC에서 파일을 가져오는 방법에 대해 생각해보자.

표 1. 고려사항

  이러한 고민을 한다는 것에 이의를 제기할 사람을 아마 없을 것이다. 대상 PC에 접근하는 방법은 같은 회사라면 대상이 자리를 비웠을 때 접근을 할 것이며, 파일을 가져오는 방법으론 FTP나 메일을 통해 보내는 것도 있지만, 가장 편하게 USB를 연결하여 바로 보내는 것이 빠르다. 또한 마지막으로 파일의 위치는 기존에 조사를 통해 위치를 알고 있거나 당장에 찾을 것이다.

  바로 이러한 과정 중에 중요한 요소가 한 가지 더 발생하게 된다. 바로 해당 파일이 올바른지, 또는 올바르게 옮겨졌는지 확인을 한다는 것이다. 어느 위치에 있는지 모를 경우 유사한 이름의 많은 파일들을 열어보게 될 것이며, 이름을 안다 해도 이것이 맞는지 확인할 것이다.

  후자의 경우 전자의 과정을 거치거나 거치지 않더라도, 올바르게 파일이 옮겨졌는지 바로 그 현장에서 USB에 담긴 파일을 실행하여 확인해 볼 수가 있다. 바로 이러한 요소가 이 문서가 초점을 맞춘 부분이다.

 

3. PC에서 열람


  용의자가 파일을 복사해 가기 이전에 PC에서 열람을 했다는 가정하에 어떠한 흔적들이 남는지 조사해볼 것이다. 준비된 3가지 문서에 따라 어떠한 흔적들이 남는지 확인해보자.  

3.1 ReadMe.PDF

그림 2. PDF – Opened Time

  PDF파일을 먼저 열어보았다. 시간은 위와 같이 01:17:11초 근처에 열었으며 종료는 이로부터 13초후에 종료하였다. 어떠한 변화가 있는지 레지스트리를 확인해보았다. 아래의 그림을 보자.

그림 3. PDF – Registry (1)

  위의 그림과 같이 PDF는 Adobe의 하위에 있는 Acrobat Reader\DC\AVGenerel의 하위 항목 값들이 변화한 것을 확인할 수가 있다. 해당 문서를 열람하고자 할 경우 PDF 리더기가 먼저 실행이 되므로 이와 관련된 부분들이 변화한 것이다.

  Acrobat Reader의 cRecentFile의 하위에 c1의 값들이 변화한 것을 확인할 수가 있다. C1이 나타내는 FileName이 ReadMe.pdf인 것과 경로를 확인할 수 있으며, 해당 키의 마지막 쓰기 시간이 PDF를 실행한 시점과 같다는 점에서 실행한 흔적임을 알 수 있다.

그림 4. PDF – Registry (2)

  레지스트리에서 가장 보편적으로 확인해야 할 항목 중 하나인 RecentDocs에도 해당 PDF 파일의 항목이 추가된 것을 확인할 수가 있다. 레지스트리 외의 항목들은 무엇이 있을까? 아래의 그림을 보자.

그림 5. PDF – Prefetch File

  우선 PDF Viewer인 Acrobat Reader가 실행되었으므로, 이에 해당하는 프리패치 파일이 생성된 것을 확인할 수가 있다. 여기서 해당 프로세스가 로드한 항목들 중 ReadMe.pdf가 존재하는 것 또한 확인할 수가 있다.

그림 6. PDF – Link File

  다른 항목으로는 바로 링크파일이다. 프리패치의 항목에서도 링크파일이 로드 된 것을 확인할 수가 있으며, 실제로 링크파일 분석 도구를 통해 확인하면 해당 시간에 맞는 흔적이 존재하는 것을 확인할 수가 있다. 만약 기존에 열어보았던 문서라면 LnkCreation Time과 AccessTime 등이 다르다. 

3.2 ReadMe.hwp

그림 7. HWP – Opened Time

  HWP의 경우 특이하게 대한민국에서만 사용률이 높은 문서양식이다. Hwp와 MS 워드 중 hwp를 쓰는 기업도 있기 때문에, 이에 중요한 내용이 담겨 있을 경우를 고려하여 어떠한 흔적이 남는지 확인해보았다.

그림 8. HWP – Registry (1)

  위의 그림은 문서를 연 시간대 이후 변화한 레지스트리 항목들을 나타내고 있다. 전체적으로 PDF와 유사한 변화들을 보이고 있다. 우선 RecentDocs에 대해선 PDF에서도 다루었기에 다루지 않을 것이다. 그림 8의 마지막 항목을 보자.

그림 9. HWP – Registry (2)

   PDF Viewer와 같이, HWP는 한컴오피스에 관련되어 레지스트리 항목이 저장되는 것을 확인할 수가 있다. 해당 값에는 문서의 경로까지 나타나고 있다.

그림 10 HWP – Prefetch File

  프리패치 파일 또한 생성되는 것을 확인할 수가 있다. 로드된 항목엔 이전과 같이 링크파일의 존재를 확인할 수가 있으므로 Lnk파일 또한 확인해보자.

그림 11. HWP – Link File

  HWP를 연 시간에 AccessTime이 나타나고 있다. 여기서 Creation Time과 Access Time이 다른데, 이는 이전에 설명한 바와 같이 이전에 한번이라도 열어본 파일인 것이다. 이전에 열었을 때 링크 파일이 생성되었으며, 마지막 접근 시간은 22일 이므로 서로 다르다. 이를 통해서도 언제 마지막으로 접근했는지 확인할 수가 있다.

3.3 ReadMe.Docx

그림 12. Docx – Opened Time

  MS 워드 또한 Hwp와 마찬가지로 많이 사용되는 문서 양식이다. 위 그림과 같이 해당 문서를 연 시간은 01:10:19초 가량이며 이전과 마찬가지로 해당 시간대 이후의 레지스트리 변화를 살펴보자.

그림 13. Docx – Registry (1)

  RecentDocs에 값이 추가된 것을 확인할 수가 있다. 이외에 특이한 점으로 Microsoft의 하위에 Office\14.0\Word 밑에 있는 값들에 변화가 있다는 것을 확인할 수가 있다. 여기서 중요한 부분은 File MRU이다.

 

그림 14. Docx – Registry (2)

  Fil MRU를 보면 Item으로 값이 존재한다. 여기서 Item에 순서가 주어져 있는데 가장 최근에 열어본 문서의 경로와 이름이 1번이 된다. 이후 새로운 문서를 확인했을 경우 해당 번호가 뒤로 밀리므로 유의하여야 한다.

  마지막으로 앞의 두 경우와 마찬가지로 프리패치 파일과 링크 파일을 통해 해당 문서를 열었는지 확인할 수가 있다.

그림 15 Docx – Link File

 

4. USB에서 열람


  이전 장의 내용들을 통해 어떠한 문서가 열람되었는지 많은 흔적들을 살펴볼 수가 있었다. 하지만 이러한 하나의 흔적들만으로는 파일 유출에 대해 확신할 수가 없다. 그러므로 이번 장에선 USB 내에서 열람된 경우를 살펴보자.

  USB에서 열람되었다는 것은, 이전의 흔적들보다 좀 더 큰 유출 가능성을 나타낸다. 만약 연결되지 않아야 할 USB가 연결되었을 수도 있으며, USB로 옮겨져선 안될 문서가 존재할 수도 있다. 또한 USB의 경우 언제 연결되었는지 시간을 확인할 수가 있으므로 더 많은 흔적들을 남긴다고 볼 수 있다.

4.1 USB 최초 연결 흔적

  USB에 관한 흔적의 경우 크게 2가지로 볼 수가 있다. 바로 최초 연결된 시점과 마지막으로 연결된 시점이다. 최초 연결 시 많은 흔적들을 남기지만, 마지막 연결된 시점의 경우 이에 비해 흔적이 많이 적다. 이에 대해 하나 하나 알아보자.

그림 16. USB – Setupapi.dev.log

  %SystemRoot%\INF\Setupapi.dev.log는 대표적으로 최초 연결 흔적이 남는 항목이다. 어떠한 USB가 최초로 연결될 경우 위의 그림과 같은 항목들이 형성된다. 하지만 log 파일에 많은 내용이 저장되면 이전의 내용들이 지워진다는 것을 잊으면 안된다.

그림 17. USB – Registry [Portable Devices]

  최초 연결과 관련된 많은 항목들 중 하나만 이야기 더 한다면 위 항목과 같다. 기존의 레지스트리엔 KALI LIVE란 항목이 없지만 USB를 연결한 이후 해당 라벨명이 기록되는 것을 확인할 수가 있다.

  이외에도 최초 연결과 관련되어 많은 흔적들이 존재한다. 만약 본인의 PC에 본인이 사용하지 않는 USB 연결 흔적이 있을 경우 유출에 대하여 더 의심해볼 수 있는 상황이 될 것이다. 하지만 최초 연결은 최초 연결된 시점만 다루기에 마지막 연결 시점이 필요하다.

4.2 USB 마지막 연결 흔적

  본인의 PC에 직장 동료나 친구가 이미 USB를 연결했던 적이 있다면 위의 흔적들은 최초 연결된 시점만을 가리키기에 아무런 소용이 없다. 따라서 이러한 상황에 필요한 것이 바로 마지막 연결 시점이다.

그림 18. USB – Registry

  위 그림은 이전에 연결한 적이 있던 USB를 다시 연결한 것이다. 항목에서 나타내는 것과 같이 항목에는 USB의 VID나 PID등이 기록되어 있다 .따라서 다시 연결한 경우 해당 항목의 마지막 쓰기 시간이 갱신되어 있는 것을 확인할 수가 있다.

  하지만 이러한 방법으로 확인하는 것을 어려움이 따른다. 따라서 간단하게 확인할 수 있는 방법에 대하여 알아보자.

 

그림 19. USB – Event Log

 이벤트 로그에는 많은 내용들이 기록이 된다. 여기서 우리가 살펴보아야 할 이벤트 항목은 응용프로그램 로그의 Microsoft\Windows\DriverFrameworks-UserMode이다. 해당 로그엔 USB를 연결한 시간과 해제한 시간이 기록되어 간편하게 확인할 수가 있다.

  하지만 해당 로그는 윈도우 7까지만 기본적으로 활성화되며, 윈도우 8부턴 비활성화되어 있기 때문에 활성화 해놓는다면 이후 분석에 있어서도 많은 편의를 가질 수가 있을 것이다.

4.3 USB에서 문서 열람

그림 20. USB – Time

  위 그림은 이후에 분석할 내용을 나타낸 시간이다. 03:13:45 가량에 USB를 연결한 이후부터 연결을 해제한 03:15:16 근처까지의 시간을 나타내는 것이며 이와 관련하여 분석해보자.

 

그림 21. USB – Connected Time

  USB가 최초 연결이 아니기 때문에 많은 흔적이 남지는 않는다. 하지만 기존의 형성되어 있는 항목들의 몇 가지 값들이 갱신되어 마지막 쓰기 시간이 변화된 것들을 확인할 수가 있다. 이외에도 USB 연결과 관련된 항목은 생략하겠다.

 

그림 22. Registry - Docx

  이전에 PC에서 문서를 열람했을 때와 마찬가지로 유사하다. 하지만 한 가지 필요 없어진 점이 있다면, 바로 RecentDocs이다. 해당 항목에선 열람된 파일의 경로가 나타나지 않기 때문에 외부에서 실행한 것임을 알 수 없다.

  그에 반해 MS Word의 File MRU 항목에서는 해당 경로까지 나오므로 새로 마운트된 볼륨 F: 에서 문서가 열람된 것임을 확인할 수가 있다.

그림 23. Registry - PDF

  PDF의 경우도 위와 유사하다. RecentDocx에서는 파일의 경로를 알 수가 없지만 Acrobat Reader의 하위 항목인 RecentFile에선 가장 최근에 열람된 항목이 되는 c1에서 파일의 경로까지 확인할 수가 있다.

그림 24. Registy - HWP

  한글파일의 경우도 마찬가지다. HwpFrame 밑에 있는 RecentFile의 값을 통해 가장 최근에 열람된 'file0'의 데이터가 F:\OpenMe.hwp를 가리키고 있는 것을 확인할 수가 있다.

 

그림 25. Prefetch File

  위는 프리패치 파일의 정보를 나타내는 것으로 각 뷰어들이 실행된 시간을 확인할 수가 있고, 문서의 위치는 로드된 파일 정보에서 'Device Path'를 통해 외부에서 로드가 된 것인지 확인할 수가 있다. 아래의 그림을 보자.

그림 26. Prefetch File (2)

  그림에서 볼 수 있듯이, 기존의 C: 에서 로드된 항목들은 경로가 올바르게 나타나지만 외부에서 로드된 항목은 경로가 제대로 나타나지 않는다. 하지만 Device Path를 통해 볼륨ID가 다른 것을 확인할 수가 있으며, 이를 통해 외부 장치임을 알 수가 있다.

 

그림 27. Link File

  링크 파일의 경우 바로 해당 파일이 열람된 위치인 F: 가 나타나는 것을 볼 수가 있으며, 이를 통해 쉽게 외부에서 문서가 열람된 것임을 알 수가 있다.

 

5. 참고


* 블로그, USB를 통한 자료 유출의 흔적

* 블로그, 개인정보 보호를 위한 USB 장치 사용내역 확인할 수 있는 프로그램

* 블로그, 어떤 사용자가 어떤 파일을 cp 했는지 기록이 남는가

* 블로그, USB 연결 흔적 관련 아티팩트


'Forensic > Analysis' 카테고리의 다른 글

문서파일 복사,복사 여부 확인  (3) 2016.01.23
NTFS & Python - $MFT Acquisition  (0) 2016.01.07
노트북 하드 컴퓨터 연결  (2) 2016.01.03
Tigger Memory Analysis  (0) 2015.12.26
Black Energy 메모리 분석  (0) 2015.12.17
Memory Analysis - CoreFlood  (0) 2015.12.05

Comment +3

  • UNKNOWN3389 2017.03.13 18:37

    질문있습니다.
    Windows에서 제공하는 regedit.exe로 HWP 레지스트리 기록값 확인해봤더니 바이너리로 되어있어 무슨 값인지 모르겠습니다.
    작성글에서 RecentDocs라는게 프로그램을 의미하는것 같아서 찾아봤더니, 프로그램은 아닌 것 같습니다.
    레지시트리 기록값에 나와있는 바이너리값은 어떻게 읽을 수 있나요?

    • 윈도우 기본 레지스트리 관리 도구인 regedit.exe 로는 해당 키의 변경 시간을 알 수 없습니다.

      이를 확인하기 위해서 제가 사용한 툴은 REGA 입니다.

      REGA의 경우 레지스트리 키의 마지막 변경 시간을 출력해주어 분석 시 사용하고 있습니다.

  • 감사합니다! 2019.11.10 16:53

    안녕하세요 너무나 유용한 글 감사히 잘 읽었습니다!!
    제가 너무 급한 나머지 이렇게 질문을 드리려고 하는데 답변 부탁드려도 괜찮을까요~?

    제가 지금 특정시간에 누가 제 노트북에 제 usb를 연결해서 사용했었는지 꼭 확인해야하는데 저는 deiverframeworks-usermode에 로깅 사용 설정을 안해놔서 로그가 저장이 안되서 이벤트수가 0이드라고요ㅠㅠ
    대신 제가 usb 연결했는지 알고 싶은 기간(10분정도)에 “이벤트뷰어-windows로그-보안”에 기록된 로그가 하나도 없어서 그 기간에 이벤트수가 0이던데
    그럼 그 시간에 usb가 연결이 안됐던걸로 생각해도 괜찮을까요?

    긴글 읽어주셔서 감사드리고 너무나 유용한 정보들도 정말 감사합니다!!^_^

볼륨 섀도우 카피 ( Volume Shadow Copy )


  시스템 복원 지점은 윈도우 비스타 이후로 넘어오면서 '복원지점' 대신 '볼륨 섀도우 카피(Volume Shadow Copy)를 사용하고 있다. 시스템 복원 지점은 운영체제 재설치 없이 시스템을 백업한 과거의 특정 시점으로 복원하는 기능으로 운영체제 설치 시 기본으로 활성화되어 있다. 시스템 복원 지점은 아래와 같은 방법으로 설정할 수가 있다.

  위의 그림과 같이 System에서 좌측의 Advanced system settings를 클릭하여 들어가면 아래와 같은 창을 볼 수가 있다. 여기서 "System Protection"이라는 탭에 해당 항목들이 존재한다. Create...를 통하여 새로운 복원 지점을 형성할 수가 있으며, 사안의 "System Restore..."를 통해 이전에 설정된 복원지점으로 복원할 수가 있다.


접근 방법


  VSC에 접근하는 방법에 대하여 알아보자. 접근하기 위해선 해당 경로를 아는 것이 우선이므로 관리자권한으로 CMD를 열고 vssadmin list shadows 를 입력해주자. 그러면 현재 가지고 있는 VSC 만큼 그 결과가 출력될 것이다. 아래의 그림을 보자.

  2개의 VSC가 출력되고 있는 것을 확인할 수가 있다. 출력 결과를 통해 해당 섀도우 카피가 생성된 시점을 확인할 수가 있으며 해당 폴더에 접근하고자 할때 중요한 "Shadow Copy Volume"을 확인할 수가 있다. 위에 드래그 한 부분과 같이 해당 경로를 복사해놓자. 그 후 아래의 그림과 같이 mklink 명령어를 통해 링크폴더를 생성한다.

  그러면 해당 폴더에 접근 할 수 있는 것을 확인할 수가 있고, 필자는 C:\vsc에 링크를 걸었다. 링크를 설정한 후 해당 디렉터리로 이동하면 카피되어 있는 이전의 C:\의 모습이 보이는 것을 확인할 수가 있다.

 

복원 지점 생성 시점

  위에선 복원 지점을 직접 생성하는 방법에 대하여 알아보았다. 하지만 매번 직접 생성해야한다면 불편함이 있다. 따라서 기본적으로 시스템 복원지점이 생성되는 경우는 아래와 같이 나열할 수가 있다.

- 초기 시스템 검사 시 : 운영체제를 설치하고 처음 시작할 때, 시스템 검사와 함께 생성한다.

- 주기적인 생성 : 시스템이 켜져 있는 경우 24시간 마다 생성하며, 24시간 이상 꺼져 있는 경우에는 다음 부팅 시 생성한다.

- 프로그램 설치 및 제거 시 : 윈도우 설치 관리자(Windows Installer)에 의해 시스템을 설치하거나 제가할 때 생성한다.

- 자동 업데이트 시 : 자동 업데이트를 통해 다운 받은 업데이트 파일이 설치되기 전 자동으로 생성한다.

- 시스템 복원 전 : 시스템 복원 작업은 시스템을 변경시키므로 복원 작업 전에 생성한다.

- 사용자가 수동으로 생성 : 시스템 복원 마법사를 통해 사용자가 수동으로 생성한다.

  복원 지점은 한번 생성되면 다음 복원지점이 생성될 때까지 시스템을 모니터링하며 관련된 내용을 계속 추가한다. 다음은 3개의 복원 지점이 생성된 경우이다. 첫 번째 복원 지점(RP1)이 생성된 이후, 각 이벤트가 발생할때마다 관련된 백업 내용이 RP1 폴더에 계속 추가된다. 추가는 두번째 복원지점(RP2)이 생성될 때까지 계속된다. 현재는 3번 째 복원 지점이 생성된 이후에 관련 이벤트가 발생하는 중이다. 이때, 두번째 복원 지점(RP2)로 시스템을 복원했다면 "EVENT #1-3"이 적용된 이후의 상태로 복원 된다.


복원 지점에 백업되는 정보

  각 복원 지점 폴더에 추가되는 이벤트 관련 내용이라는 것은 이벤트가 발생할 때마다 관련된 내용이 폴더에 백업된다. 복원 지점 간의 발생하는 시스템의 모든 행위를 백업하기는 어렵다. 그러기 위해선 백업용 저장매체를 추가적으로 장착해야할 뿐 아니라 시스템 행위를 RAID 1과 같이 미러링 하는 것이므로 성능 하락의 원인이 될 것이다. 따라서, 윈도우는 기본적으로 복원에 가장 필요한 정보만 백업한다.

복원가능 : - 레지스트리    - 사용자 프로파일    - COM+DB    -WFP.dll캐시    - WMI DB    - IIS Metabase    - filelist.xml:<Include>설정항목

복원불가 : - DRM 설정    - SAM Hive의 password    - WPA 설정    - 사용자 프로파일에 저장되는 사용자가 생성한 데이터

HKLM\SYSTEM\ControlSet001\Control\BackupRestore\FileNotToSnapshot에 설정된 항목

HKLM\SYSTEM\ControlSet001\Control\BackupRestore\FilesNotToBackup 에 설정된 항목

- HKLM\SYSTEM\ControlSet001\Control\BackupRestore\KeysNotToRestore에 설정된 항목

filelist.xml에 <Include>가 설정되지 않은 항목


* 레지스트리에 설정된 복원 제외 항목

  복원 가능한 정보 중 가장 중요한 레지스트리와 filelist.xml에 대해 살펴보자. 우선 레지스트리는 복원 지점이 생성된 순간, 스냅샷 형태로 백업된다. 최초 복원지점 생성 시에는 레지스트리 전체가 백업된 다음, 복원지점이 추가될 때마다 변경된 부분이 백업된다. 이렇게 백업된 스냅샷은 레지스트리 분석 도구로 분석이 가능하다. filelist.xml은 모니터링할 목록을 설정하는 파일로 위치는 다음과 같다.

- %SystemRoot%\System32\Restore\filelist.xml

  Filelist.xml에서 확인할 수 있는 내용은 크게 3가지로 구분되어 있다. <FILES>는 모니터링할 파일이 설정되어 있으며, <DIRECTORIES>는 모니터링할 디렉터리가 설정되어 있고, 마지막으로 <EXTENSIONS>는 모니터링할 확장자가 설정되어 있다.

  이러한 각 노드는 다시 <Exclude>와 <Include>로 나뉘어 지는데 각 각 제외할 목록과 포함할 목록을 가지고 있다. 즉, 복원 지점에 백업하기 위해 모니터링할 파일, 디렉터리, 확장자에 대한 포함/제외 여부를 설정할 수 있다. 이렇게 세분화되는 이유는 백업에 따른 우선순위 때문이다. <FILE>가 우선 순위가 가장 높고 <EXTENSIONS>가 가장 낮기 때문에, 두 부분에서 각 각 포함/제외가 다르다면 우선순위에 따라 결정이 되는 것이다.

  이와 같이 filelist.xml에 설정된 파일들은 생성, 변경, 삭제 이벤트가 발생할 때마다 이벤트 내역, 경로, 파일의 복사본 등이 백업된다. 하지만 파일을 삭제할 때 Shift+Del과 같이 휴지통을 거치지 않고 삭제하게 되면 파일의 복사본은 백업되지 않고 삭제한 기록만 남게된다. 파일/ 폴더에 대한 모니터링은 시스템 복원 필터 드라이버(%SystemRoot%\System32\drivers\sr.sys)에 의해 추적 감시 된다. 해당 드라이버는 시스템 복원 기능에 의해 설정된 파일들이 변경이 일어날 때마다, 변경에 대한 로그를 기록하고 복사본을 생성한다.


복원 과정

  한번 직접 복원을 해보자. 해당 설정에 들어가 복원을 클릭하면 아래와 같이 나타난다. 여기서 영향을 받는 프로그램 검색을 클릭하면 복구를 하므로 사라지는 프로그램과 복구되는 프로그램의 목록을 볼 수가 있다. 이를 확인한 뒤 다음을 클릭하여 계속 진행하자.


  아래와 같이 마지막 화면 창이 나타난다. 이에 대해 경고문을 읽고 조심하여야한다. 복구를 통해 오히려 손실되는 프로그램이 있을 수도 있으므로 테스트는 VM환경에서 진행하는 것이 좋다.


  마침을 누르면 복원이 진행되는 것을 확인할 수가 있다. 여기서부턴 되돌릴 수 없으므로 유념하여야 한다. 복구가 완료되면 부팅 되는 것을 확인할 수가 있으며 설정에 따라 지정된 디렉터리 및 파일들이 남게 된다. 이렇게 쉽게 복원을 진행할 수가 있다.


활용 방안


삭제된 피알 복구

  filelist.xml에 <Include>되어 있는 파일들은 삭제될 경우 복사본인 백업 파일이 생성된다. 휴지통을 거치지 않고 Shift+Del 키를 이용한 경우 복사본이 남지 않지만, 삭제한 흔적은 확인할 수 있다. 따라서, 용의자 혹은 공격자가 악의적인 파일을 생성/실해한 후 흔적을 지우기 위해 파일을 삭제했다면 복원지점에서 관련된 흔적을 찾을 수 있다. 실제로 최근의 악성코드와 관련된 침해 사고는 자신의 흔적을 은폐하기 위해 관련 파일을 모두 삭제한다. 이 경우, 사건을 인지하고 초기 대응이 빠르다면 삭제된 흔적을 쉽게 발견할 수 있지만, 늦은 대응이라면 발견할 수 없는 삭제 흔적을 복원지점을 통해 발견할 수 있다.


설치/제거된 프로그램

  삭제된 파일과 마찬가지로 윈도우 설치관리자에 의해 설치/삭제된 프로그램 목록도 확인가능하다. 따라서, 윈도우 설치가 필요한 프로그램을 분석 시스템에 설치한 후 삭제하였더라고 복원지점을 확인하면 해당 흔적을 확인할 수 있다.


악의적인 드라이버 설치 흔적

  WHQL에 의해 인증되지 않은 드라이버를 설치 할 때도 복원지점이 생성된다. 따라서 커널 루트킷을 만들기 위해 설치하는 악의적인 드라이버의 흔적도 발견할 수가 있다.


악성코드 삭제 흔적

  PE 파일은 기본적으로 filelist.xml에 <Include> 되어 있다. 따라서, <Exclude>된 디렉터리가 아닌 곳에서 실행하고 삭제했다면 악성코드 복사본이 복원지점에 저장되어 있다. 따라서, 악성코드를 삭제하여 해당 파일을 찾을 수 없는 경우에도 타임라인 분석을 이용하다보면 복원지점에서 복사본이 발견되는 경우가 자주 있다.



참고

http://www.forensicswiki.org/wiki/Windows_Shadow_Volumes

http://forensic-proof.com/archives/2854

https://technet.microsoft.com/en-us/library/ee923636(v=ws.10).aspx

http://blogs.msdn.com/b/adioltean/archive/2008/02/28/a-simple-way-to-access-shadow-copies-in-vista.aspx

'Forensic > Theory' 카테고리의 다른 글

Windows Event Log (2) – 주요 이벤트 로그  (0) 2016.02.01
Windows Event Log (1) – 이벤트 로그의 개념  (2) 2016.02.01
Volume Shadow Copy 분석  (1) 2016.01.18
NTFS FIle System (9) $UsnJrnl  (0) 2016.01.16
NTFS File System (8) $LogFile  (0) 2016.01.13
NTFS File System (7) INDEX  (0) 2016.01.02

Comment +1

$UsnJrnl


  응용 프로그램이 특정 파일의 변경 여부를 파악하기 위해 사용한다. 기본적으로 Windows 7부터 활성화가 되어 있으며 비활성화 되어 있을 경우, Fsutil로 활성화 시 킬 수 있다. UsnJrnl은 $Max 속성과 $J 속성으로 구성되는데 $MAX는 변경 로그의 기본 메타 데이터를 저장하며 $J속성은 실제 변경 로그 레코드를 저장하고 있다.

  여기서 $J의 각 레코드들은 USN(Updata Sequence Number)정보를 가지며, 이러한 USN 정보를 통해 각 레코드들의 순서를 구분한다. 실제 USN 값은 $J 속성 내에서의 레코드의 Offset 값을 가지고 있으며, USN 값은 MFT 엔트리의 $STANDARD_INFORMATION 속성에도 저장되어 있다. UsnJrnl은 MFT 엔트리의 10번째인 $Extend 디렉터리 안에 존재하고 있다. /$Extend/$UsnJrnl 와 같은 경로를 가지고 있다.

 기록 되는 로그 데이터의 양은 일반적으로 컴퓨터를 계속 사용할 경우 1~2일 정도의 로그가 남으며, 규칙적(하루 8시간)으로 사용할 경우 4~5일 정도의 로그가 남는다.


$UsnJrnl 구조


$Max 속성의 구조

  $Max 속성은 32 Byte의 고정된 크기를 가지며 해당 속성에 저장되는 정보는 아래와 같이 로그 데이터의 최대 크기, 그리고 $UsnJrnl 파일의 생성시간, 마지막으로 현재 저장된 레코드 중 가장 작은 USN 값을 갖으며, 해당 값을 통해 $J 속성 내 첫 번째 레코드로 바로 이동이 가능하다.


$J 속성의 구조

  $J 속성은 가변적은 크기를 가지며, 로그 레코드들이 연속적으로 나열된다. 또한 속성의 앞 부분은 0으로 채워진 "Sparse Area"를 가지고 있다. 아래의 그림은 내 PC의 $UsnJrnl:$J를 나타낸 것으로 0부터 0x57800000 전 까지는 모두 0으로 채워져 있는 것을 확인할 수가 있다. 이러한 구조를 가지는 이유는 운영체제가 $J 속성에 저장되는 로그 데이터의 크기를 일정하게 유지하려고 하기 때문이다.

  $J 속성은 새로운 로그 레코드들이 할당 될 때마다 속성 끝에 추가되며, 추가된 레코드들의 총 크기가 "Allocation Size"를 넘으면 추가 레코드들을 포함하여 전체 로그 데이터의 크기가 "Maximum Size"를 넘는지 확인한다. 만약 전체 로그 데이터의 크기가 "Maximum Size"를 넘는다면 로그 데이터의 앞 부분을 "Allocation Size" 만큼 0으로 채워 "Sparse Area"로 만든다.

  따라서 $J 속성의 논리적인 크기는 계속 커지지만 실제 데이터가 할당된 영역은 일정하게 유지되며, 일반적으로 0x2000000~0x23FFFFF의 로그 데이터를 저장한다.

  MFT Reference Numbr 대신 Parent MFT Reference Number를 사용하는 이유는 전자를 사용할 경우, 해당 파일이 삭제되었을 때 전체 경로를 못 얻을 수도 있기 떄문이다. 

<Reason Flag>

<Source Information>

<File Attribute>



출처 및 참고

F-INSIGHT-NTFS-Log-TrackerKorean.pdf

Comment +0

개요


$LogFile?

  지금까지의 과정은 $MFT를 위주로 진행되어왔다. 이제 MFT Entry 2번($MFT가 0번)에 위치하는 $LogFile에 대하여 알아보자. 추후에 학습할 $UsnJrnl이 변경 로그라면 $LogFile은 트랜젝션 로그이다. 이 역시 각 볼륨마다 하나씩 존재하며 만약 NTFS가 정전이나 기타 오류로 인해 갑작스럽게 중단되면 운영체제는 $LogFile에 저장된 로그를 바탕으로 현재 진행되는 작업의 이전 상태로 파일 시스템을 복구한다.


  파일이나 디렉터리의 생성, 삭제, 데이터 작성, 파일명 변경 등 트랜잭션 작업 내용은 레코드 단위로 기록되며, $LogFile의 작업 레코드에 저장된다. 각 작업 레코드는 고유의 LSN($LogFile Sequence Number)를 가지며 이는 순차적으로 증가한다. 이러한 각 레코드는 복구를 위해 작업 데이터(Redo)와 작업 전 데이터(Undo)를 갖는다.


$LogFile Size



  일반적인 하드 디스크 볼륨에서는 64MB인것을 알 수가 있으며 볼륨 용량에 따라 크기가 달라질 수는 있지만 기본적으로는 최대 64 MB 이하이다. 만약 이러한 $LogFile의 크기를 변경하고자 할 때는 chkdsk 명령의 /L 옵션에 따라 크기 조절이 가능하며 '/L:파일크기(KB 단위)' 형식의 옵션을 주면 $LogFile의 크기를 변경할 수 있으며 크기를 지정하지 않는다면 위의 그림과 같이 현재 크기를 나타낸다.




구조


$LogFile의 전체적인 구조

  $LogFile은 아래의 그림과 같이 재시작영역(Restart Area)과 로깅 영역(Logging Area)으로 나뉘어진다. 각 영역의 구성 단위는 0x1000(4096)바이트 크기의 페이지이다. 재시작 영역은 파일의 가장 첫 두 페이지(0x0000~0x20000)에 해당하고 가장 마지막 작업에 대한 정보를 가지고 있다.


  로깅 영역은 재시작 영역 외의 영역(0x2000~)을 말하며 실제 작업 레코드들이 기록된다. 로깅 영역은 다시 버퍼 페이지 영역과 일반 페이지 영역으로 구성된다. 이에 대한 건 좀 더 뒤에서 이야기할 것이다.



$LogFile 재시작 영역 구조



  위에서 말한 바와 같이 재시작 영역은 가장 마지막 작업 레코드를 가리키며 이는 현재 작업 중인 내용으로 0x0000부터 두 페이지(0x2000)로 구성이 된다. 여기서 두 번째 페이지는 백업용으로 사용되며 각 페이지는 매직넘버(RSTR)로 시작한다. 운영체제는 이 영역에서 마지막 레코드에 대한 정보를 가져와서 파일 시스템을 복구하는 것이다. 위의 그림은 재시작 영역의 페이지 헤더 구조이며 Cuurent LSN 필드에 마지막 작업 레코드의 LSN 정보를 저장하고 있다.



  위 그림은 실제 $LogFile을 Hex Editor로 열어서 확인한 것으로 상단의 그림은 첫 번째 페이지 영역으로 매직넘버 RSTR로 시작하는 것을 확인할 수가 있다. 하단의 그림은 두 번째 페이지 영역(0x1000~0x2000)의 시작 부분으로 위와 같은 구조를 가지고 있으며 백업을 위한 공간임을 알 수가 있다.


* 재시작 영역은 운영체제가 어떠한 파일 시스템의 정리를 수행할 경우 어떠한 트랜잭션을 참고해야 하는지 판단하는데 도움을 주는 구조체이며, 성공적인 마지막 트랜잭션을 위한 어떤 로깅 영역을 가리키는 포인터를 포함한다.



$LogFile 로깅 영역 구조


  로깅 영역에는 실제 작업 레코드들이 기록되며 버퍼 페이지 영역과 일반 페이지 영역으로 나뉘어진다. 여기서 버퍼 페이지 영역은 첫 두 페이지(0x2000~0x4000)가 존재하고 두 번째 페이지는 위와 같이 백업용이며 순차적으로 레코드가 기록된다. 여기서 만약 버퍼 페이지가 레코드로 가득 차게 되면 페이지 내용을 일반 페이지 영역으로 기록을 넘기는 형식으로 작업이 진행된다. 따라서 가장 최근의 작업 레코드들은 버퍼 페이지 영역에 남게 된다.


  일반페이지 영역은 버퍼 페이지를 제외한 나머지 영역(0x4000~)을 말하며 버퍼 페이지가 모두 채워지면 기록된 내용을 받는 역할을 한다. 만약 작업 레코드들이 파일 끝까지 가득 차게 되면 위의 그림과 같이 일반 페이지 영역 시작부분부터 다시 덮어쓰는 방식으로 진행된다.


* Redo 필드는 어떤 동작이었는지에 대한 정보를 저장하며, Undo 필드는 어떤 동작을 어떻게 원래대로 되돌리는지 설명하는 정보를 저장한다.



Page 구조



  페이지는 $LogFile의 기본 구성 단위이며 크기는 0x1000(4096 Bytes)로 고정되어 있다. 페이지는 하나의 헤더와 다수의 작업 레코드들로 구성되어 있으며 마지막 레코드가 페이지를 넘어가면 다음 페이지에 이어서 기록이 된다. 위의 그림은 이 구조를 나타낸 것으로, 페이지 헤더에 매직 넘버('RCRD')가 나오는 것을 확인할 수가 있으며 Last LSN 필드의 정보를 통해 페이지 내에서 가장 나중에 기록된 작업 레코드의 LSN 정보를 획득할 수 있다. Next Record Offset 필드의 정보를 통해 페이지 내에서 가장 나중에 기록된 작업 레코드의 위치를 알 수가 있다.


 Magic Number

 "RCRD" 

 Last LSN 

 페이지를 넘어가는 레코드를 포함해서 가장 큰 LSN 

 Next Record Offset  

 Last LSN에 해당 하는 레코드의 페이지 내 Offset 

 Last End LSN 

 페이지를 넘어가지 않는 레코드들 중에 가장 큰 LSN 


  결국 운영체제는 재시작 영역의 Currsnt LSN 필드에서 가장 마지막에 기록된 LSN 정보를 가져와서 해당 LSN 정보를 Last LSN 값으로 가진 페이지를 찾고, 그 페이지의 Next Record Offset을 가져와 실제 마지막 기록된 레코드의 위치를 찾는다.



작업 레코드 구조



  작업 레코드에는 실제 트랜젝션 작업의 내용이 기록되며 위의 그림과 같이 여러 작업 레코드가 순차적으로 모여서 하나의 트랜젝션 작업을 이룬다. 가장 첫 레코드를 Checkpoint 레코드라 하며 마지막 레코드를 Commit 레코드라 한다. 그 외 중간에 있는 레코드들은 Update 레코드라 한다.


  Checkpoint 레코드 외의 레코드들은 자신의 이전 작업 레코드의 LSN 값을 가지고 있다. 따라서 파일 시스템 복구 시, 운영체제는 트랜젝션 작업을 구성하는 레코드들을 역추적하면서 각 레코드들의 Undo 데이터를 사용하여 복구할 수가 있다.


[이미지 출처 - zrungee Blog]


  작업 레코드는 레코드 헤더와 데이터 영역으로 구성된다. 레코드 헤더는 고정된 0x58 크기를 가지며 데이터 영역은 Redo와 Undo 데이터가 들어가기 때문에 크기가 가변적이다. 따라서 작업 레코드의 크기도 가변적이며 큰 레코드는 여러 개의 페이지를 사용하기도 한다. 그리고 하나의 작업 레코드가 끝나면 바로 이어서 다음 작업 레코드가 이어진다. 상세한 작업 레코드 헤더 구조는 위의 그림과 같으며 각 필드에 대한 설명은 아래의 표와 같다.



  Redo Op 필드와 Undo Op 필드는 실제 레코드가 어떠한 작업을 수행하였는지에 대한 정보를 가진다. 각 Op가 가지는 연산 코드의 의미는 아래와 같다.




출처 및 참고

http://www.ahnlab.com/kr/site/securityinfo/secunews/secuNewsView.do?curPage=1&menu_dist=2&seq=19518

http://zrungee.tistory.com/206

'Forensic > Theory' 카테고리의 다른 글

Volume Shadow Copy 분석  (1) 2016.01.18
NTFS FIle System (9) $UsnJrnl  (0) 2016.01.16
NTFS File System (8) $LogFile  (0) 2016.01.13
NTFS File System (7) INDEX  (0) 2016.01.02
Cluster Run 직접 확인해보기 - MFT엔트리찾기  (0) 2015.12.31
NTFS File System (6) MFT $SIA & $FN $DATA  (0) 2015.12.31

Comment +0


  포렌식을 공부하면서 점차 데이터 복구나 수집한 증거를 분석하는 방법에 대하여 점차 관심이 많아지기 시작하였다. 이를 위해선 공통적으로 파일 시스템에 대한 이해가 필요하다고 생각하였고, 그렇기에 현재 사용하고 있는 NTFS에 대하여 먼저 학습해보자 생각하였다.

  파일 시스템이나 NTFS에 대하여 이론적으로 더 잘 정리된 많은 문서들이 있으므로, 나는 Python을 통해 접근을 하기 위함을 목적으로 학습을 진행하였다. 이렇게 접근을 한 다음 최종적으로는 $MFT 수집 도구를 만드는 것이 목적이다. 학습을 위한 준비사항은 아래와 같다.

도구 이름

도구 버전

다운로드

Python

2.7

https://www.python.org/

HxD

.

http://mh-nexus.de/en/hxd/

Py2exe

.

http://www.py2exe.org/

표 1. 사용한 도구

  학습은 윈도우 10을 통해 진행하였으며 전체적으로 학습을 하면서 Windows7이나 XP와의 별 차이를 느끼지 못하였다. Prefetch나 Web Artifact에 있어선 좀 상이한 부분이 있지만, 이번 문서에서 다루는 내용에 한해서는 큰 차이가 없었다.


그림 1. 부팅 과정

  컴퓨터의 전원을 누른 순간부터 사용자 모드로의 부팅 과정은 위의 그림과 같다. 여기서 BIOS는 ROM에 적재가 되어 있으므로 우리는 MBR부터의 과정을 구체적으로 확인할 수가 있다. 이를 토대로 학습을 진행해보자.



2. 디스크 접근


2.1 HxD 디스크 열기

  전체적인 진행을 하기 전에 직접 자신의 디스크를 확인해보자. HxD를 관리자 권한으로 실행을 한 다음, 아래의 버튼과 같이 디스크 열기를 누르면 대개 '논리 디스크'와 '물리 디스크'라 나뉘어 있는 것을 확인할 수가 있다.

그림 2. HxD 디스크 열기

  이 중 어떠한 것을 열어야 할 지 모른다면 직접 둘 다 열어서 확인해보자. 어떠한 차이가 있는지는 아래의 그림과 같다. '물리 디스크'를 먼저 확인해보면 알 수 있는 것이 아무것도 없다. 반면에 '논리 디스크'로 연다면 시작과 함께 NTFS라는 문자열이 있다.

그림 3. HxD 디스크 확인

  이는 기본적인 디스크를 어떻게 구분하느냐에 따른 것이다. 물리 디스크는 하나의 장치 그 자체를 말하는 것이며 논리 디스크는 하나의 파티션이나 볼륨과 같은 논리적인 부분을 말하는 것이다.


2.2 Python 디스크 열기

  Python을 통해 이러한 물리 디스크나 논리 디스크에 접근하는 방법에 대하여 알아보자. Python에는 기본적으로 open(filename, type) 함수가 존재하고 있다. 그렇다면 어떻게 이러한 시스템적인 부분에 접근하는가? 아래의 그림을 보자.

그림 4. Python – open()

* 여기서 CMD를 열 때Administrator 권한으로 열어야 권한 거부가 생기지 않는다.

 

  이렇게 Python에서 Drive에 접근하고자 할 땐 '\\\\.\\Drive'와 같이 나타내어야 한다. 이는 원래 \\.\Drive 인 것을 나타내기 위해 \를 두 번씩 표기하여 주는 것이다. 만약 두 번씩 하지 않으면 하나는 생략된 결과로 Python은 인식하게 된다. 접근 모드는 'rb'로 바이너리를 읽기 모드로 여는 것이다.

그림 5. Python – read()

  제대로 물리 드라이브를 읽는 것을 확인할 수가 있다. 그렇다면 물리드라이브엔 어떻게 접근을 해야 할까? 의문을 가질 수가 있다. 결국 최종적인 목표는 $MFT를 수집하는 것임을 잊지 말자. NTFS에서 부팅 가능한 영역을 MBR에서 찾아서 가는 것이 어찌 보면 부팅 과정처럼 정도의 길이라 할 수가 있다.

 

그림 6. Python – 논리 디스크 열기

  하지만 바로 논리 디스크로 접근하는 방법이 있다면 굳이 MBR에서부터 부팅 가능한 영역을 찾는 번거로움을 감수하고 싶지는 않을 것이다. 위의 그림과 같이 \\\\.\\ 뒷 부분에 열고자 하는 논리 디스크 'C:'와 같이 입력을 해주면 된다. 읽은 부분에서 NTFS 라는 그림 3에서 확인했던 문자열이 올바르게 출력되는 것을 확인할 수가 있다.


2.3 MBR 구조

  물리 디스크 영역은 앞 부분에 MBR(Mater Boot Record)가 있다. 코드 영역엔 부팅을 하기 위한 코드들이 포함되어 있으며, 붉게 표시한 부분은 바로 파티션 테이블로 64 Byte를 차지하고 있는 것을 확인할 수가 있다. 전체적인 구조는 아래와 같이 나타난다.

 

그림 7. MBR

  코드 영역은 별도의 구조가 없이 코드들로 이루어져 있지만 파티션 테이블의 경우에는 구조가 있기 때문에 그 구조에 맞게 해석을 할 수가 있어야 한다. 파티션 테이블은 부팅 가능한 디스크를 나타내기 위한 부분으로 아래의 구조와 같다.

그림 8. Partition Table

  여기서 중요한 것은 바로 앞 부분의 1바이트이다. Boot Flag로 부팅이 가능한 파티션인지를 나타내는 값으로 0x80은 부팅이 가능하다는 것을 뜻하며 0x00은 부팅이 불가능함을 뜻한다. 파티션 타입의 경우 어떤 타입(FAT, Unix, NTFS 등)을 나타낸다.

  그렇다면 부팅 가능한(Boot Flag = 0x80) 파티션이 있다면 그 위치는 어떻게 알 수 있을까? 예전엔 CHS Address를 사용했지만 점차 용량이 커지므로 표현의 한계가 있기에 현재는 LBA를 통해 해당 운영체제의 시작 지점을 알 수가 있다. 여기서 LBA란 Local Black Area의 약자로 흔히 섹터라 표현할 수가 있다. 위 그림 8의 Starting LBA Address란 결국 몇 번째 섹터에 운영체제가 시작하는 지 포함되어 있음을 의미한다. 이를 직접 확인해보자.

 

그림 9. HxD Partition Table

  위의 그림은 실제 내 PC의 파티션 테이블이다. 각 색에 맞게 4개의 파티션이 나타나 있는 것을 확인할 수가 있다. 세 번째 파란색 부분을 보면 부팅 플래그가 0x80으로 부팅이 가능함을 나타내며 7912000 LBA에 운영체제가 시작함을 나타낸다.

* 참고 : 섹터의 크기는 512 Bytes이므로 해당 LBA에 512를 곱해 Offset을 알 수 있다.

  단, 윈도우 7부턴 윈도우를 설치할 때 시스템 예약 파티션이 나뉘어 지는데, 해당 파티션은 BitLocker 암호화를 위한 예약된 공간이다. 특이한 점은 이전 XP와는 다르게 부팅 플래그가 바로 이 시스템 예약 파티션에서 설정이 되어 있다는 점이다. 다시 말해 위 그림 9의 부팅 플래그 0x80으로 되어 있는 부분이 시스템 예약 파티션이란 것이다. 정확한 이유는 알 수가 없지만, BitLocker 암호화는 지정된 보호 기능을 위해 동작하는 것으로, 해당 부분을 보호하기 위하여 먼저 이 곳으로 부팅이 되는 것이 어찌 보면 당연한 것이다. 컴퓨터의 전원을 켰을 때 장치에 이상이 없는 것을 POST에서 확인하는 것과 유사하다고 생각하자.

  그렇다면 그림9에서 NTFS는 어디에 있는 것일까? 바로 네 번째 부분에 존재하고 있다. 파티션 타입번호(0x07)을 통해 확인하거나 해당 LBA로 직접 가서 확인하는 방법이 있다. 물론 시스템 예약 파티션을 없애면 바로 NTFS로 부팅 플래그가 설정 될 것이다. 만약 파티션이 5개 이상이라면 MBR에 더해 EBR로 관리를 하는데 이는 파티션 테이블 부분에 EBR로 가는 16 Bytes 구조가 생기며 해당 LBA로 이동하면 다음 EBR과 자신이 가리키는 파티션의 LBA를 가지고 있다.

 

 

 3. NTFS


  2장의 과정을 통해 MBR을 통해 부팅 가능한 파티션과 해당 파티션의 위치를 찾아가는 방법에 대하여 알아보았다. HxD로 '물리 디스크'로 디스크를 열었지만 이 방법을 통해 NTFS가 있는 '논리 디스크' C:와 같은 부분을 찾을 수가 있다.

그림 10. 논리디스크 찾기

  이제 본격적으로 NTFS에 대하여 알아보자. Python을 통해선 2장의 과정이 없이 바로 C:와 같은 논리 디스크를 열 수 있음을 다시 한번 기억하자. 이제부터 다룰 내용은 NTFS의 구조에 대한 것으로 필수적으로 알아야 할 내용들을 주로 다룰 것이다.

 

그림 11. NTFS 구조

  위 그림은 NTFS에 대한 전체적인 구조를 나타낸 것이다. VBR을 시작으로 MFT가 존재하고 있으며 그 후 각 파일에 대한 Data가 존재하고 있는 Data Area가 있다. 이들에 대하여 알아보기 전에 클러스터(Cluster)에 대하여 간략히 설명하고자 한다.

   디스크는 기록을 할 때 Sector 단위로 한다. 하지만 NTFS 운영체제는 Cluster 단위로 기록을 하는 것으로 이 두 사이에 차이가 난다. 이러한 Cluster Size는 볼륨의 크기에 따라 주로 결정되며 기본적으로 2GB이상이라면 Cluster Size는 4 KB이다.

  

3.1 VBR

  VBR은 Volume Boot Record의 약자로 해당 볼륨의 부팅을 위한 영역이다. 여기서 우리가 주로 보아야 할 부분은 바로 보라색으로 나타나있는 BPB 부분이다. 해당 부분엔 많은 시스템에 대한 많은 정보들이 포함되어 있다. VBR의 구조는 아래의 그림과 같다.

그림 12. VBR 구조

 

  BPB엔 섹터의 크기나 클러스터의 크기를 포함하고 있으며 이 문서에서 가장 중요하게 다루는 MFT의 시작 위치가 있다. 그렇기에 이 부분의 몇 가지 항목만 올바르게 해석할 수 있다면 된다.

그림 13. BPB 구조

 

  우선 Bytes Per Sector와 sec per Clus라 되어 있는 부분은 각 각 섹터의 크기와 클러스터의 크기를 나타낸다. 만약 사용자가 그 값을 윈도우를 설치할 때 지정해주었다며 다를 수 있으므로 반드시 저 부분의 값도 확인을 해야 한다.

 그 다음 확인해야 할 중요한 사항은 바로 0x30에 위치한 Start Cluster for $MFT로 MFT의 첫 번째 Entry가 시작되는 클러스터의 번호를 담고 있다. 아래 예에선 MFT의 시작 위치가 C0000 Cluster임을 확인할 수가 있다. 따라서 해당 오프셋은 클러스터의 크기인 8 섹터와 섹터의 크기 512Bytes를 곱해주면 된다. 따라서 0xC0000000이 해당 오프셋이라는 것을 알 수가 있다.

그림 14. Start Cluster for $MFT

  해당 오프셋으로 이동하면 MFT의 Signature인 'FILE' 문자열을 확인할 수가 있다. 따라서 올바르게 값을 해석했다는 것을 알 수가 있다.

그림 15. $MFT Signature


3.2 VBR – Python

  그렇다면 Python을 통해서 VBR을 접근해보자. 그 뒤 필요한 항목을 어떻게 설정해야 하는지 확인해보자. 우선 '논리 디스크' C:를 위 그림 6에서의 방법과 동일하게 열어보자.

그림 16. Python – open C:

  여기서부턴 해당 디스크를 Bytearray를 통해서 읽을 것이다. 아까와 같이 올바르게 NTFS 문자열이 출력되는 것을 확인할 수가 있다. 이에 더해 한 가지 함수를 먼저 만들어보자. 만들고자 하는 함수는 Little Endian으로 되어있는 16진수 값을 10진수로 읽어 값을 반환해주는 함수로 이후에 계속 사용될 것이다.

그림 17. Python – LtoI()

 

  VBR에서 우리가 알아야 할 값은 총 3개이다. 섹터의 크기, 클러스터의 크기, 그리고 마지막으로 MFT Entry의 시작위치이다. 이 3개를 알아야 이후에 MFT에 대하여 Python을 통해 분석을 올바르게 할 수가 있다.

  섹터의 크기는 VBR에서 0x0B~0x0C에 위치해 있으며, 클러스터의 크기는 0x0D에 있는 것을 BPB구조에서 확인할 수가 있었고 MFT는 0x30에 해당 클러스터의 값이 있다. 이제 이를 Python으로 입력해보자.

그림 18. Python – Sector

  위의 그림과 같이 섹터의 크기는 512 Bytes(0x200)이며 클러스터의 크기는 8 섹터(4KB)임을 알 수가 있다. 이제 이 값을 가지고 MFT의 위치를 알맞게 해석할 수 있다. 아래의 그림을 보자.

그림 19. Python – MFT Offset

  MFT의 첫 번째 Entry의 Offset이 0xC0000000임을 Python을 통해 해석할 수가 있었다. 이제 VBR에서 우리가 더 확인해야 할 항목은 없으므로 이제 MFT에 대하여 학습해보자.



4. MFT


  VBR을 통해 MFT의 위치를 찾을 수가 있었다. MFR는 Master File Table의 약자로 NTFS에선 파일이나 디렉터리, 메타 정보들을 모두 파일의 형태로 관리하고 있다. 이러한 각 파일들의 위치나 속성, 이름, 크기 등의 메타 정보가 MFT Entry에 저장된다.

  따라서 이러한 많은 정보들이 저장된 MFT를 통해 Forensic 조사에 있어서도 많은 유용한 정보들을 제공한다. 그렇기에 MFT에 대하여 이해 한다는 것은 많은 이점을 갖게 되는 것과 같다. MFT가 갖는 각 Entry에 대한 설명은 아래와 같다.

그림 20. MFT Entry 정보

  많은 유용한 Entry들이 존재하지만, 모두 다루기엔 많은 분량이 나오므로 이 문서는 $MFT에 한정하여 설명할 것이며 추가적으로 필요한 내용에 한해서만 다룰 것이다. MFT Entry의 구조는 아래의 그림과 같다.

그림 21. MFT Entry 구조

    MFT Entry 헤더가 오고 그 다음 Fixup Array가 나온다. 그 다음 가장 중요한 속성이 나오고 End Marker와 함께 뒤 부분은 사용되지 않는다. 이에 대하여 알아보자.

  

4.1 MFT Entry Header

  MFT Entry 헤더는 Signature('FILE')로 시작하여 많은 정보들을 담고 있다. 이 문서는 MFT 수집 툴을 만드는 것이 목적이므로 많은 내용은 다루지 않을 것이다. 전체적인 구조는 아래의 그림과 같다.

그림 22. MFT Entry Header 구조

  여기서 우리가 알아야 할 항목은 0x14에 위치한 'Offset to File Attribute' 항목이다. 이 항목은 속성이 시작하는 위치를 나타내주는 값으로 MFT 수집 툴을 만들기 위해선 이러한 속성 중 $DATA에 접근하여야 한다. 이에 대해선 좀 더 뒤에서 다룰 것이다.

그림 23. HxD - MFT Entry Header

  위의 그림과 같이 0x14에 있는 값이 현재 0x38로 나타나는 것을 확인할 수 있다. 이는 0x38의 위치부터 속성이 시작된다는 것으로 그림에선 0x10이 존재하고 있다. 이는 $STANDARD_INFORMATION(이후 $SIA라 하자.)의 속성 ID 값으로 4.6에서 알아보자.

  

4.2 MFT Entry – Python

  MFT Entry 헤더의 구조에 대하여 알아보았다. 이제 이를 Python을 통해 접근하는 방법에 대하여 살펴보자. 우선 우리는 그림 19에서와 같이 VBR을 통해 MFT의 첫 번째 Entry 주소를 알 수가 있었다. 이제 이를 통해 포인터를 이동시켜보자.

그림 24. Seek(MFT_Offset)

  Seek()함수를 통해 파일을 읽을 위치를 이동 시킬 수가 있다. 우리는 현재 MFT Entry 정보를 읽을 것이므로 이전에 선언했던 mft_off 또는 그 위치 값인 0xc0000000으로 이동을 한 후 해당 부분을 512 Bytes 읽은 것이다.

 

그림 25. Attribute Offset

  512 Byte를 읽은 다음 속성이 위치한 곳의 주소를 얻기 위하여 mft_attribute_off를 선언해주고 0x14-0x15의 값을 읽는다. 또 MFT Entry의 크기를 확인하므로 속성의 시작과 끝을 알 수가 있고, 이러한 속성의 데이터를 attr_off로 지정해놓은 것이다.

  이제 속성의 시작 위치를 알 수가 있으므로 우리는 $DATA를 찾아야 한다. 이를 찾기 위해선 각 속성의 식별 값을 확인을 할 것이며 만약 $DATA의 식별 값인 0x80이 아니라면 해당 속성의 크기를 통해 다음 속성으로 넘어 갈 수가 있다.

그림 26. Find $DATA

  여기서 3번째 라인을 보면 속성 값이 아닌0x0000(NULL)이나 0xFFFF(EndMarker)가 읽히면 해당 루프를 빠져 나오는 것을 확인할 수가 있다. 속성 식별 값이 0x80이 아니라면 해당 속성의 size를 구해 그 만큼을 건너 띄는 것을 아래의 2줄을 통해 확인할 수가 있다. 만약 0x80($DATA)이라면 아직 지정하지 않은 Data_parse()라는 함수를 호출해 $DATA 속성을 분석할 것이다. 이에 대해선 속성에 대하여 알아본 뒤에 다시 해보자.

  

4.3 Attributes

  하나의 MFT Entry는 여러 개의 속성을 포함하고 있다. 이러한 속성엔 각 항목에 따라 유용한 정보들을 가지고 있으므로 이를 해석할 수 있어야 한다. 이러한 속성에 대한 설명은 아래의 그림과 같다.

그림 27. 속성 정보

  많은 속성 항목들이 있지만 모두가 중요한 것은 아니다. 크게 가장 많이 사용되는 항목은 $SIA와 $FILE_NAME(이후 $FN), 그리고 $DATA 항목이다. 우선 이러한 속성의 공통적인 구조 먼저 알아보자.

그림 28. 공통 속성 헤더

  속성의 구조는 거주 속성과 비거주 속성으로 나뉘어 지는데, 이에 대해 알기 전에 공통적을 포함되는 공통 속성 헤더에 대하여 알아보자. 구조는 위의 그림 25와 같이 되어 있다. 공통 속성헤더를 통해 어떠한 속성타입인지, 해당 속성의 길이가 얼마나 되는지, 만약 속성이 이름을 갖는다면 그 이름이 무엇인지 등이 있다. 여기서 속성 이름이란 $SIA나 파일 이름이 아닌, 속성 자체에 부여되는 이름을 뜻하는 것이다. 이러한 공통 속성 헤더 다음엔 거주 속성, 비거주 속성인지에 따라 다른 구조를 갖는다.

  

4.4 거주 속성 (Resident Attribute)

  거주 속성은 해당 속성의 내용이 크지 않기에 MFT Entry 구조에 모두 담을 수 있을 때의 갖는 상태이다. 속성 내용을 모두 담을 수 있기에 다른 곳을 보지 않아도 되며, 그 내용은 거주 속성 헤더 뒤에 나타난다. 이러한 거주 속성의 구조는 아래의 그림과 같다.

그림 29. 거주 속성 헤더

  속성 내용의 크기와 속성 내용의 위치, 인덱스 플래그, 마지막으로 속성의 이름이 있다면 그 속성의 이름이 나오며 없을 경우 바로 속성 내용이 나온다. 아래의 그림은 $MFT의 속성 부분을 나타낸 것이다.

그림 30. HxD - 거주 속성

  공통 속성 헤더를 제외하고 0x48부터 거주 속성 헤더가 존재하는 것을 확인할 수가 있으며 해당 속성은 이름이 존재하지 않기 때문에 바로 뒤에 속성내용이 따라오는 것을 확인할 수가 있다. 이렇게 거주 속성의 구조에 대하여 확인할 수가 있으며, 이러한 거주 속성은 대부분의 $SIA와 $FN에서 나타난다.

  

4.5 비거주 속성 (Non-Resident Attribute)

  속성 내용이 너무 커진다면 그것을 한곳에 모두 담을 수가 없다. 이러한 상태가 바로 비거주 상태라 하게 되며 이 경우 별도의 클러스터를 할당하여 그 곳에 내용을 담아 놓는다. 아래의 그림을 통해 구조를 확인해보자.

그림 31. 비거주 속성 구조

  공통 속성 헤더가 나온 뒤 VCN이나 런리스트, 속성 내용의 크기, 속성 이름과 속성내용 등 관련된 내용들이 기록되어 있다. 이 항목들 중 자세히 알아볼 내용은 런리스트에 관한 내용이다.

  비거주 속성은 속성 내용이 크기 때문에 외부 클러스터에 해당 내용들을 담고 있다. 하지만 이러한 클러스터들이 모두 연속적으로 존재할 수는 없기에 이러한 클러스터들에 대한 정보를 담고 있는 런리스트가 필요하다. 즉, 런리스트는 속성 내용을 담은 클러스터가 어디에 위치하였는지를 알려주기 위한 것이라 할 수 있다.

 

그림 32. Run List

  런리스트를 해석하는 방법의 위의 그림과 같다. 첫 바이트를 읽어 일의 자리 수와 십의 자리수로 나눈다. 그 다음 일의 자리 수만큼 뒤의 바이트를 읽고 이것이 해당 클러스터의 길이가 된다. 십의 자리 수만큼 바이트를 이어 읽으면 해당 클러스터의 위치 값을 알 수가 있다. 이해하기 쉽게 직접 해석해보자.

그림 33. Run List

  위의 그림은 내 PC의 MFT Entry 중 비거주 속성의 런리스트를 나타낸 부분이다. 검은색 동그라미가 첫 바이트이며, 붉은 색은 런의 길이, 파란 색은 런의 위치를 나타내기 위해 표시해놓은 것이다.

  첫 번째 런의 첫 바이트는 '33'이다. 이를 십의 자리와 일의 자리로 나누면 십의 자리는 각 각 '3'이 된다. 따라서 둘 다 3바이트씩 읽은 것이다. 이를 해석하면 C00000 클러스터에서부터 C820개의 클러스터가 할당되어 있음을 나타내는 것이다.

  두 번째 런은 앞과 유사하므로 생략하고 세 번째 런을 보자. 십의 자리가 '4' 일의 자리가 '2'임을 알 수가 있다. 따라서 런 길이는 2바이트를 읽어 0x308이며 런 위치는 4바이트를 읽어 124727B 클러스터이다. 이렇게 런리스트를 해석하면 비연속적으로 저장된 데이터를 올바르게 찾아갈 수가 있다.

  이를 찾아갈 때 고려해야 할 것은 2번째 런부턴 앞의 이전의 런위치를 더해야 한다는 것이다. 2번째 런을 예로 들면 런 위치가 57E23D 번째 클러스터에 있음을 알 수가 있는데, 정작 57E23D 클러스터를 확인해보면 올바르지 않게 되어 있다. 올바르게 찾아가기 위해선 57E23D에 C0000을 더해야 한다. 따라서 63E23D 클러스터에 올바른 속성 내용이 위치하고 있다는 것이다.

  이러한 비거주 속성은 보통 파일의 크기가700Bytes 보다 더 클 경우에 속하게 되며 이보다 작을 경우엔 거주 속성이 된다. 주로 $DATA의 경우 비거주 속성을 띄는 경우가 많으며 우리가 목적으로 하는 $MFT 또한 이러한 비거주 상태에 속하므로 클러스터 런을 올바르게 해석할 수 있어야 한다

  

4.6 Attribute - $SIA, $FN, $DATA

 

$STANDARD_INFORMATION

  $SIA는 $FN과 같이 모든 MFT Entry에 기본적으로 포함되는 속성으로 파일의 시간 정보와 파일에 대한 정보 등이 기록되어 있다. 전체적인 구조는 아래와 같다.

그림 34. $SIA 구조

 

$FILE_NAME

  $FN은 해당 MFT Entry가 가리키고 있는 파일에 대한 이름을 포함하여 $SIA에도 있었던 시간 정보들이 존재한다. 하지만 $SIA의 시간정보에 비해 상대적을 변경 되는 경우가 적다. 이에 대해선 나중에 더 자세히 학습하자. $FN의 구조는 아래와 같다.

그림 35. $FN 구조

 

$DATA

  마지막으로 알아볼 $DATA 속성에 대해선 조금 더 자세히 알아보자. 위의 두 가지 항목은 파일에 대한 정보를 나타내는 것이었다면 $DATA는 해당 파일의 실제 내용으로 앞의 두 개와 마찬가지로 중요한 속성이다. 우선 구조를 먼저 살펴보자.

그림 36. $DATA 구조

  구조가 상대적으로 매우 단조로워 보인다. 만약 $DATA 속성의 크기가 작다면 속성 헤더(공통헤더와 거주속성헤더) 뒤에 바로 속성 내용이 나오게 된다. 하지만 만약 속성의 크기가 커지면 비거주 상태가 되어 위에서 살펴본 바와 같이 클러스터 런을 통해 속성 내용을 관리한다.

 만약 $DATA 속성이 2개라면 어떻게 될까? 이것이 바로 ADS다. 기존의 메인 스트림 외에 대체 스트림이 하나 더 주어지는 것으로 이 경우 반드시 속성 이름이 주어진다. 이를 통해 추후에 $UsnJrnl:$J를 분석할 때 참고할 수가 있을 것이다.

  이번 문서의 목적은 Python을 통해 $MFT를 수집하는 것이므로 일반적으로 크기가 큰 $MFT가 많기 때문에 대부분 비거주 상태에 있다. 따라서 이러한 $DATA의 클러스터 런을 잘 해석할 수가 있어야 할 것이다.

  

4.7 $DATA - Python

  올바르게 속성 식별 값 0x80($DATA)를 찾았다면 이제 해당 부분을 분석하여 정보를 추출을 위한 정보를 알아내야 한다. 우선 Runlist의 위치와 해당 버퍼를 담아보자. 아래의 그림에서와 같이 $DATA의 구조를 읽어 런리스트의 위치와 런리스트부터의 버퍼를 담고 있는 것을 확인할 수가 있다.

그림 37. $DATA 분석 – Python

  $MFT의 $DATA 속성의 경우 비거주 속성을 가질 수 밖에 없다. $MFT가 700바이트 이하의 크기를 갖기는 많이 어렵기 때문이다. 런리스트를 반복문을 통해 분석하기 전에 필요한 변수들을 먼저 선언해주자.

그림 38. 변수 선언

  Count와 tmp, calc, add_offset 등은 반복문에서 대부분 첫 번째 런을 위하여 존재하는 것이며 clu_size와 clu_off, tmp_size와 tmp_offset은 런을 해석한 결과를 담기 위해 미리 리스트(배열)을 선언해놓은 것이다. 이제 반복문을 통해 분석을 진행해보자.

그림 39. 반복문 – 분석

  2번째와 3번째 라인은 이전에 선언해놓은 tmp='00'을 십의 자리와 일의 자리로 나누어 계산을 진행하는 것으로 이후에 tmp가 런의 첫 바이트를 읽어 다시금 자리 수를 나누기 위함이다.

  6번째 라인이 런의 첫 바이트틑 읽는 것으로 이후에 clu_size와 clu_off를 위해 몇 바이트씩 읽어야 하는지 나타내기 위해 존재한다. 그 후 tmp_들로 인하여 해당 바이트의 값을 읽고 있는 것이다. 그리고 add_offset을 통해 4.5에서 살펴본 것과 같이 클러스터 런의 오프셋을 더하기 위한 부분이다. 이렇게 반복문이 0x00을 만나 빠져나오면 tmp_에 담겨있는 값을 다시 정리하여야 한다. 이를 위한 코드는 아래와 같다.

그림 40. Tmp 정리

  이전에 tmp에 담겨있는 것을 정리하기 위해 각각 size와 offset을 선언해준다. 그 후 반복문을 통해 클러스터 단위가 아닌 바이트 단위로 나타내기 위하여 tmp의 값에 초반에 구했던 sec과 clu를 곱해준다.

  이렇게 얻어진 값을 통해 기록하고자 하는 파일을 연다. Seek() 함수를 통해 해당 클러스터의 오프셋으로 이동해 사이즈만큼 읽고 이를 기록한다. 이렇게 런의 수만큼 반복이 된다. 최종적으로 완성된 코드를 실행하면 결과는 아래의 그림과 같다.

그림 41. 실행 결과

 

 

 

5. 정리


간단하게 $MFT 수집 도구를 만들고 싶었지만, $MFT를 수집하기 위해선 결코 간단한 지식을 가지고는 수집할 수 없겠다는 것을 여러 번 느끼는 계기가 되었다. 이해했다고 생각했던 것들이 코드를 통해 직접 해보려 하니 낯설기도 하고 더 어렵게 느껴지기도 하였다.

 

그래도 직접 NTFS를 공부하면서 만들어보고자 했고, 결국 만들었음에 매우 흡족하다. 이후엔 $LogFile과 $Usnjrnl:$J까지 한번에 수집해주는 도구를 제작해보고자 한다. 이를 위해선 더 많은 것을 공부해야겠지만 분명 재미있는 공부가 될 것이라 생각한다.

 

 

 

 

참고 자료


해킹대회문제로 배우는 파일시스템.pdf

humanistcpu.blogspot.kr/2013/10/hxd-mbrmaster-boot-record.html ; HxD MBR 구조 분석

cappleblog.co.kr/40; MBR 구조

cappleblog.co.kr/590; MBR 해석

forensic-proof.com/archives/2975 ; 시스템 예약 파티션 관련 내용

forensic-proof.com/archives/357

forensic-proof.com/archives/431

http://home.sogang.ac.kr/sites/gsinfotech/study/study1702/Lists/b10/Attachments/17/20131212_%EC%B9%A8%ED%95%B4%EC%8B%9C%EC%8A%A4%ED%85%9C%EB%B6%84%EC%84%9D.pdf

http://ntfs.com/ntfs-partition-boot-sector.htm

(FP) NTFS.pdf

forensic-proof.com/archives/584



'Forensic > Analysis' 카테고리의 다른 글

문서파일 복사,복사 여부 확인  (3) 2016.01.23
NTFS & Python - $MFT Acquisition  (0) 2016.01.07
노트북 하드 컴퓨터 연결  (2) 2016.01.03
Tigger Memory Analysis  (0) 2015.12.26
Black Energy 메모리 분석  (0) 2015.12.17
Memory Analysis - CoreFlood  (0) 2015.12.05

Comment +0

개요


컴퓨터를 살 때 많이 고민하는 사항 중 하나가 데스크탑을 살지, 노트북을 살지에 대하여 많은 고민들을 하기도 한다. 이번 포스팅은 필자도 노트북을 쓰는 입장이므로 이에 대해 지식을 함양시키고자 직접 해보았다. 상황은 아래와 같다.

- 기존에 쓰던 노트북이 어떠한 이유에서인지 부팅이 되지 않는다.

- 고치러 가기엔 디스크에서 특정 파일을 빨리 사용해야 한다.

이러한 상황에 있을 때 혹은 유사한 사항에 있을 때 할 수 있는 방법에 대하여 알아보자. 준비물이 몇 가지 필요하다.

준비물 : 대상 노트북, 외장하드, 복구 또는 추출을 하기 위한 정상적인 PC


실습


 필자는 아래와 같이 준비하였다. 노트북은 LG의 XNOTE를 준비하였으며 우측의 외장하드는 엠지텍의 MG25-TERRAN2+COUP을 준비하였다. 외장하드가 필요한 이유는 노트북의 하드 디스크와 크기가 같기에 이를 통해서 연결할 수기 때문이다. 준비된 장치들을 이제 분해하여 보자.

         

 위와 같이 우선 분석 또는 복구를 하고자 하는 노트북의 하드를 먼저 분리 한다. 그리고 아래의 좌측 그림과 같이 외장하드도 분리를 해준다. 여기서 두 하드의 크기가 얼추 맞는지 확인을 간단하게 해준다. 만약 크기가 다를 경우 해당 단자에 꽂히나 한번 해보고 안된다면 해당 포스팅에선 능력 밖이므로 다른 문서를 찾아보자.

         


 아래 좌측의 그림은 엠지텍의 하드를 빼낸 후 남은 본체의 모습이다. 이제 이 곳에 노트북의 하드(TOSHIBA)를 꽂자. 꽂을 때 너무 과하게 힘은 주지 말자 괜히 멀쩡하던 곳도 손상될 수가 있으므로 조심하자. 연결 한 후의 모습은 원래 외장하드를 열었을 때의 모습과 다를 바가 없다.

         


 이렇게 조립한 외장하드를 이제 외장하드의 USB 단자를 통해 분석 또는 복구를 하고자 하는 PC에 연결해보자. 필자는 노트북이 2대이므로 정상적인 노트북 LG그램에 연결을 진행하였다.


 우선 연결이 잘 되었는지 해당 디스크 F:가 생성되는 것을 아래의 그림과 같이 확인할 수가 있었다. 또한 우측의 그림을 통해서 기존의 Disk 0 이 아닌 새로운 Disk 1이 생성된 것을 확인할 수가 있다. 만약 정상적으로 장치 인식이 되지 않는다면 연결 단자나 하드를 조립할 때 제대로 하였는지 다시 한번 확인해보자.

          


연결된 하드를 HxD나 WinHex, FTK Imager 등을 통해 다양한 작업을 할 수도 있으며 실제 외장하드와 같이 디렉터리 안으로 들어가 파일을 가져올 수도 있다. 이러한 방법이 언젠가는 쓸모가 있을 것 같기에 이렇게 포스팅을 해보았다.





'Forensic > Analysis' 카테고리의 다른 글

문서파일 복사,복사 여부 확인  (3) 2016.01.23
NTFS & Python - $MFT Acquisition  (0) 2016.01.07
노트북 하드 컴퓨터 연결  (2) 2016.01.03
Tigger Memory Analysis  (0) 2015.12.26
Black Energy 메모리 분석  (0) 2015.12.17
Memory Analysis - CoreFlood  (0) 2015.12.05

Comment +2

  • 질문입니다ㅠㅠ 2016.05.11 14:40

    저도 노트북이 블루스크린이 떠서, 어떻게 데스크탑에 연결할수 없을까 고민중인데요,
    노트북안의 하드디스크는 내장하드라고 부르죠? 내장하드도 이런식으로 데스크탑에 연결 가능할까요?
    노트북바탕화면에 있는 파일을 구출해내야하는데 이런 방식으로 가능할까요?
    꼭 답변좀 부탁드립니다ㅠㅠㅠ

  • 노트북 하드를 분리하셔서 위 글에서처럼 연결할만한 잭이 있으셔야해요

    노트북 하드는 일반 하드보다 작아서 직접적으로 연결을 못해요. 그래서 글처럼 외장하드제품을 이용한다던지 아니면 아예 잭을 사서 하시면 가능합니다