Kali-KM_Security Study

볼륨 섀도우 카피 ( 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