시스템 복원지점 포렌식 분석 (System Restore Point Forensics)

시스템 복원지점(SRP, System Restore Point)은 포렌식 분야에서 이미 오래된 주제이다. 윈도우 ME 버전에서 처음 소개된 이후에 XP까지 사용되었다. 서버 버전인 2000과 Server 2003은 복원지점을 지원하지 않는다. 윈도우 비스타 이후로 넘어오면서 현재는 복원지점 대신 볼륨 섀도우 복사본(VSS, Volume Shadow Copy)을 사용하고 있다.(비스타에서는 복원지점과 볼륨 섀도우 복사본을 함께 사용) 하지만, 아직까지도 윈도우 XP 시스템을 사용하고 있는 사용자들이 많이 존재하고, 실제 침해 분석에도 많은 도움이 되기 때문에 정리를 해볼까 한다.

시스템 복원지점에 대해 모두 알고 있더라도 다시 한번 읽어보기 바란다. 혹시나 빠트리거나 잘못 알고 있었던 정보는 없었던가? 만약, 이 글에 잘못된 정보가 포함되어 있다면 망설이지 말고 댓글로 알려주기 바란다.

1. 시스템 복원지점 소개

시스템 복원지점은 운영체제 재설치 없이 시스템을 백업한 과거의 특정 시점으로 복원하는 기능으로 운영체제 설치 시 기본으로 활성화되어 있다. 시스템 복원지점은 “시스템 등록 정보 => 시스템 복원 탭”에서 설정 가능하다.

시스템 복원지점에 할당된 공간은 볼륨 크기가 4GB 이상인 경우에는 최대 볼륨 크기의 12%를 사용할 수 있고, 4GB보다 작은 경우에는 400MB로 제한되어 있다. 이 크기는 사용자 설정을 통해 최대 200MB까지 줄일 수 있다. 커스트마이징된 버전의 XP를 사용한다면 복원지점이 꺼져있을 수 있다. 그리고 인터넷에 많이 떠돌아 다니는 시스템을 빠르게 하는 방법을 보면 복원지점을 끄라고 충고하기도 한다. 이 모든 것은 예전 펜티엄시대의 산물로 현재의 컴퓨터 성능에서는 복원지점을 사용하던 안하던 사용자가 체감하는 성능 제한은 거의 없다.

시스템 복원지점은 특정 시점 이후에 컴퓨터가 갑자기 느려졌거나 자기도 모르게 이상 동작을 하는 경우 사용할 것이다. 누구나 한번 쯤은 안전 모드로 부팅한 후에 복원지점을 이용해 복원해 본 경험을 갖고 있을 것이다. 생성한 복원지점을 이용해 복원을 하고 싶다면, “시작 => 보조프로그램 => 시스템도구 => 시스템 복원” 메뉴를 활용하면 된다. 메뉴를 클릭하면 아래 그림과 같은 화면이 나온다. 복원하고 싶다면 “이전 시점으로 내 컴퓨터 복원”을 체크하고 다음을 누르면 되고, 현재 시점의 복원지점을 생성하고 싶다면 “복원 지점 만들기”를 누르면 된다.

“이전 시점으로 내 컴퓨터 복원”을 누르면 다음과 같이 이전에 생성한 복원 지점들을 볼 수 있다. 원하는 날짜의 백업된 복원지점을 선택하고 다음을 누르면 해당 시점의 상태로 복원이 된다.

2. 복원지점 생성 시점

그럼 복원지점 생성 시점은 언제일까? 앞서 살펴본 대로, 사용자가 직접 원하는 시점에 복원지점을 생성할 수 있다. 하지만, 사용자 정의가 아니더라도 기본적으로 활성화되어 있는 기능에 의해 생성된다.

다음은 시스템 복원지점이 생성되는 경우를 나열한 것이다.

• 초기 시스템 검사 시 : 운영체제를 설치하고 처음 시작할 때, 시스템 검사와 함께 생성한다.
• 주기적인 생성 : 시스템이 켜져 있는 경우 24시간 마다 생성하며, 24시간 이상 꺼져 있는 경우에는 다음 부팅 시 생성한다.
• 프로그램 설치 및 제거 시 : 윈도우 설치 관리자(Windows Installer)에 의해 시스템을 설치하거나 제거할 때 생성한다.
• 자동 업데이트 시 : 자동 업데이트를 통해 다운받은 업데이트 파일이 설치되기 전 자동으로 생성한다.
• 시스템 복원 전 : 시스템 복원 작업은 시스템을 변경시키므로 복원 작업 전에  생성한다.
• 서명되지 않은 장치드라이 설치 시 : WHQL(Windows Hardware Quality Labs)에 의해 인증되지 않은 드라이버 설치 시 생성한다.
• 사용자가 수동으로 생성 : 시스템 복원 마법사를 통해 사용자가 수동으로 생성한다.

복원지점을 생성하면 기본적으로 다음의 경로에 관련 파일들이 저장된다.

• %HOMEDRIVE%\System Volume Information\_restore{GUID}\RP#(#은 복원지점 생성 번호)

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

 
3. 복원지점에 백업되는 정보

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

시스템 복원 시 복원 가능한 정보는 다음과 같다.

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

복원 불가능한 정보는 다음과 같다.

• DRM 설정
• SAM 하이브의 패스워드
• WPA 설정(윈도우 인증 정보는 복원 불가능)
• 사용자 프로파일에 저장되는 사용자가 생성한 데이터
• HKLM\SYSTEM\ControlSet001\Control\BackupRestore\AsrKeysNotToRestore에 설정된 항목
• HKLM\SYSTEM\ControlSet001\Control\BackupRestore\FilesNotToBackup 에 설정된 항목
• HKLM\SYSTEM\ControlSet001\Control\BackupRestore\KeysNotToRestore에 설정된 항목
• filelist.xml에 <Include>가 설정되지 않은 항목

복원가능한 정보 중 가장 중요한 레지스트리와 filelist.xml 에 대해 살펴보자. 우선 레지스트리는 복원지점이 생성되는 순간, 스냅샷(snapshot) 형태로 백업된다. 최초 복원지점 생성 시에는 레지스트리 전체가 백업된 다음, 복원지점이 추가될 때마다 변경된 부분이 백업된다. 이렇게 백업된 스냅샷은 레지스트리 분석 도구로 분석이 가능하다.

filelist.xml은 모니터링할 목록을 설정하는 파일로 위치는 다음과 같다.

• %SYSTEMROOT%\system32\Restore\filelist.xml

다음은 filelist.xml 파일의 내용 일부이다.

<PCHealthProtect>
    <VERSION>1.0</VERSION>
    <DEFTYPE>E</DEFTYPE>
    <FILES>
        <Exclude>
            <REC>%windir%\system.ini</REC>
            <REC>%windir%\tasks\desktop.ini</REC>
            <REC>%windir%\win.ini</REC>
            <REC>*:\AUTOEXEC.BAT</REC>
            <REC>*:\CONFIG.MSI</REC>
            <REC>*:\CONFIG.SYS</REC>
            <REC>*:\DUMPFILE.SYS</REC>
        </Exclude>
        <Include>
            <REC>c:\placeholder\ph.dll</REC>
        </Include>
    </FILES>
    <DIRECTORIES>
        <Exclude>
            <REC>%cookies%</REC>
            <REC>%favorites%</REC>
            <REC>%History%</REC>
            <REC>%internetcache%</REC>
            <REC>%nethood%</REC>
            ... ...
	        <REC>%SystemDrive%\Documents And Settings\All Users\Favorites</REC>
	        <REC>%SystemDrive%\Documents And Settings\All Users\Documents</REC>
	        <REC>%SystemDrive%\Documents And Settings\Default User\My Documents</REC>
	        <REC>%SystemDrive%\Documents And Settings\Default User\NetHood</REC>
    	    <REC>%SystemDrive%\Documents And Settings\Default User\Favorites</REC>
    	    <REC>%SystemDrive%\Documents And Settings\Default User\Cookies</REC>
    	    <REC>%SystemDrive%\Documents And Settings\Default User\Cache</REC>
    	    <REC>%SystemDrive%\Documents And Settings\Default User\Local Settings\History</REC>
    	    <REC>%SystemDrive%\Documents And Settings\Default User\Local Settings\Temp</REC>
    	    <REC>%SystemDrive%\Documents And Settings\Default User\Local Settings\Temporary Internet Files</REC>
        </Exclude>
        <Include>
            <REC>*:\Documents And Settings\*\Application Data\Microsoft\Internet Explorer\Quick Launch</REC>
        </Include>
    </DIRECTORIES>
    <EXTENSIONS>
        <Include>
            <REC>~~C</REC>
            <REC>~~D</REC>
            <REC>12A</REC>
            <REC>1PA</REC>
            <REC>1ST</REC>
			... ...
            <REC>WTB</REC>
            <REC>WTR</REC>
            <REC>XLL</REC>
            <REC>XMX</REC>
            <REC>XRS</REC>
            <REC>XTU</REC>
            <REC>ZFSENDTOTARGET</REC>
            <REC>ZH</REC>
            <REC>ZH_TW</REC>
            <REC>ZRW</REC>
        </Include>
    </EXTENSIONS>
</PCHealthProtect>

내용은 크게 3가지로 구분되어 있다.

• <FILES> : 모니터링할 파일 설정
• <DIRECTORIES> : 모니터링할 디렉터리 설정
• <EXTENSIONS> : 모니터링할 확장자 설정

각 노드는 다시 <Exclude>와 <Include>로 나눠진다. <Exclude>는 제외할 목록이고, <Include>는 포함할 목록이다. 즉, 복원지점에 백업하기 위해 모니터링할 파일, 디렉터리, 확장자에 대한 포함/제외 여부를 설정할 수 있다. 하지만, 상식적으로 <Include>에 대한 설정만 하면되지 <Exclude>는 왜 필요하단 말인가?

그 이유는 우선순위에 있다. 위에서부터 <FILES>가 우선순위가 가장 높고, <EXTENSIONS>가 우선순위가 가장 낮다. 따라서, 만약 <EXTENSIONS> 항목에 EXE 확장자가 <Include>되어 있더라도, <FILES>나 <DIRECTORIES>의 <Exclude> 항목에 포함된 EXE 파일은 모니터링에서 제외된다.

이와 같이 filelist.xml에 설정된 파일들은 생성, 변경, 삭제 이벤트가 발생할 때마다 이벤트 내역, 경로, 파일의 복사본 등이 백업된다. 자세한 이벤트 내역은 SRRestorePtAPI.h에 정의된 RESTOREPOINTINFO 구조체에서 확인할 수 있다. 파일을 삭제할 때 휴지통을 거친다면 당연히 파일의 복사본도 백업되지만, SHIFT+DEL을 이용해 휴지통을 거치지 않고 삭제하게 되면 파일 복사본은 백업되지 않고 삭제한 기록만 남는다. 파일/폴더에 대한 모니터링은 커널의 파일시스템 드라이버 상단에 위치하는 시스템 복원 필터 드라이버(%SYSTEMROOT%\system32\drivers\sr.sys)에 의해 추적 감시된다. 해당 드라이버는 시스템 복원기능에 의해 설정된 파일들이 변경이 일어날 때마다, 변경에 대한 로그를 기록하고 복사본을 생성한다.

 
4. 복원지점과 관련된 파일
복원지점과 관련된 파일들은 다음의 두 경로에서 찾아볼 수 있다.

• %SYSTEMROOT%\system32\Restore\
• %HOMEDRIVE%\System Volume Information\_restore{GUID}\

먼저 %SYSTEMROOT%\system32\Restore\ 경로에는 존재하는 파일을 살펴보자.

• filelist.xml : 앞서 살펴본 대로 모니터링할 파일, 디렉터리, 확장자가 설정되어 있다.
• MachineGuid.txt : 시스템의 GUID로 “_restore{GUID}” 폴더 경로의 GUID 값과 일치한다.
• rstrui.exe : 시스템 복원 응용프로그램으로 앞서 살펴본 시스템 복원 시 나타나는 대화상자 프로그램이다.
• srdiag.exe : 시스템 복원지점과 관련된 텍스트 파일(cfg, txt, log, xml)을 CAB 형식으로 만들어주는 프로그램이다.
• srframe.mmf : 시스템 복원 응용프로그램과 관련된 설정 파일이다.

%HOMEDRIVE%\System Volume Information\_restore{GUID}\ 경로에는 다음과 같은 파일들이 존재한다.

• _driver.cfg : 드라이버와 관련된 설정 정보를 저장하고 있다.
• _filelst.cfg : filelist.xml의 설정 정보를 저장하고 있다.
• drivetable.txt : 각 볼륨의 마운트 포인트 위치, 볼륨 상태, 복원지점 공간 정보가 저장된다.
• RestorePointSize : 시스템 복원지점의 크기가 저장된다.
• snapshot (DIR) : 레지스트리 스냅샷이 저장된 폴더이다.
• A#######.(원본파일의 확장자) : 백업된 파일 복사본이다. (####### 번호는 백업 순서)
• change.log(change.log.#) : 백업된 파일의 전체 경로, 원본 파일명, 백업 파일명이 저장된다.
• rp.log : 복원지점 생성 시 발생한 이벤트 및 생성 시간이 저장된다.
• fifo.log : 복원지점에 할당된 용량의 90%가 넘으면, 자동 삭제하여 75%까지 용량을 줄이는데 이때 제거되는 파일들의 정보가 기록된다.

5. 파일 포맷

대부분의 파일은 설정 정보이므로 포렌식 분석을 위해 살펴보아야 하는 파일은 다음과 같다.

• fifo.log
• registry snapshot
• A#######.(extension)
• change.log
• rp.log

fifo.log는 텍스트 파일이기 때문에 쉽게 분석할 수 있고, 레지스트리 스냅샷은 기존 레지스트리 분석도구를 이용해 분석이 가능하다.  A#######.(extension) 파일은 백업된 파일인데 파일명이 변경되었으므로 파일 자체로서는 큰 의미가 없다. 어떤 파일이 어떤 상황에서 백업되었는지에 대한 정보가 필요하다. 그에 대한 정보가 change.log 파일에 저장되어 있다. rp.log는 복원지점이 생성된 시점과 원인을 알 수 있으므로 살펴볼 필요가 있다. rp.log과 change.log는 고유한 포맷을 가지고 있는데 간단히 살펴보자.

# rp.log 포맷

# change.log 포맷

change.log 파일의 가장 앞부분은 CHANGE_LOG_HEADER 구조가 위치하고 있고, 이어서 CHANGE_LOG_ENTRY 구조가 연속으로 온다. 우선 두 구조 모두에서 공통으로 사용하는 RECORD_HEADER에 대해 살펴보자.

RECORD_HEADER

CHANGE_LOG_HEADER

CHANGE_LOG_ENTRY

엔트리의 구조는 엔트리 유형에 따라 서로 다르다. 정확한 분석을 위해서라면 관련된 구조체를 참고하기 바란다.

rp.log 포맷을 살펴보면 복원지점이 생성된 원인(복원지점 유형), 복원지점의 이름, 복원지점 생성시간을 알 수 있다. change.log 포맷을 살펴보면 파일이 백업된 원인(엔트리 유형), 원본 파일 이름, 백업 파일 이름을 알 수 있다. 보통 엔트리 유형이 속성 변경(ATTRCHANGE)인 경우에는 파일을 백업하지 않고 변경된 내용만 기록한다. 반면, 파일 삭제와 같은 행위가 발생하면 해당 파일의 복사본이 저장된다. 따라서, 특정 파일이 현재는 삭제되어 존재하지는 않지만 filelist.xml에 설정되어 있는 파일/폴더에 위치하거나 확장자를 가졌다면 백업 파일로 완벽하게 복원할 수 있다.(복원지점 공간 부족으로 삭제되지 않았다면…)

rp.log, change.log 파일에 포함된 정보 이외에 중요한 정보가 하나 더 있다. 바로 백업 파일(복사본)의 생성 시간이다. 백업 파일의 생성시간은 이벤트가 발생하여 백업된 파일이므로 해당 이벤트가 발생한 시간을 알 수 있다.

 
6. 분석 도구

복원지점을 분석할 수 있는 도구는 그리 많지 않다. 대표적인 도구는 MANDIANT의 Restore Point Analyzer이다. 하지만 이 도구는 change.log 파일만 파싱해준다. 게다가 단지 원본과 복사본의 관계만 해석만 해준다. change.log에 엔트리가 추가될 때 발생한 이벤트 유형과 백업 파일의 생성 시간을 함께 보여주지 않는 것이(이를 위해서는 원본의 생성시간이 유지되어야 함)  아쉽기만 하다.

다음으로 분석 스크립트가 몇 가지 있다. 대표적인 것은  log2timeline을 만든 Kristinn의 스크립트와 Harlan Carvey가 만든 Regripper의 플러그인으로 동작하는 RipXP가 있다. RipXp는 레지스트리 값만 비교가 가능하고 사용하기도 까다로워 크게 유용하지 못하다. Kristinn의 스크립트 또한 rp.log만 파싱해주기 때문에 큰 의미가 없다.

결국, 복원지점이 언급된지 오래지만 쓸만한 도구가 별로 없다. 실제 분석에 큰 활용이 없다고 생각해서인지도 모르겠다. 3년전에 연구실에서 GUI로 개발한 rp.log, change.log 파싱 도구와 2년전에 개발한 레지스트리 별 스냅샷을 비교 도구가 있었는데 현재 어디로 간것인가…?

XP가 분석의 초점에서 점점 사라져서 그런지는 모르겠지만, 실제 분석 환경에서 복원지점을 활용하여 중요한 증거를 찾는 경우가 꽤 많다. 시간만 주어진다면 간단한 GUI로 만들고 싶지만, 이렇게 계획만 세우고 지나간 것들이 어디 한둘이랴…

 
7. 복원지점 활용방안

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

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

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

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

 
8. 결론

비스타 이후로 넘어가면서 복원지점이 대체되기는 했지만 아직까지 많은 시스템이 XP 기반을 사용하고 있다. 침해사고의 거의 대부분은 악성코드에 의해 발생한다. 최근 공격자들은 과거와 다르게 자신의 흔적을 감추기 위해 매우 노력한다. 포렌식 분석에 혼란을 주기 위해 일부러 흔적 데이터를 조작하는 경우도 많고, 목표로한 시스템을 제외하고는 경유한 모든 시스템의 흔적을 삭제한다. 이런 이유로 침해 사고 분석을 하는데 상당한 어려움을 겪는다.

물론, 빠른 대응이 되면 삭제된 파일을 복원하여 분석이 가능하겠지만 대부분의 경우 사고가 발생한지 상당한 시간이 흐른 후에야 인지한다. 또한, 자체적인 분석을 진행하면서 많은 사용흔적이 사라져버린다. 이런 상황에서 복원지점은 침해 사고의 원인을 규명하는데 많은 도움이 되고 있다.

비스타 이후에도 볼륨 섀도우 복사본이 복원지점의 역할을 하므로 이를 분석하면 많은 정보를 얻을 수 있다. 게다가 볼륨 섀도우 복사본은 정해진 파일만이 아닌 시스템의 모든 행위를 모니터링하기 때문에 더 큰 도움이 될 것이다. 다음 포스팅에서는 볼륨 섀도우 복사본에 대해서 살펴볼 예정이다.