Live Response

1      라이브 리스폰스란?

전통적인 컴퓨터 포렌식 방법론에서는 컴퓨터를 조사하기 전에 우선 전원 플러그를 뽑고 하드 드라이브의 이미지를 복사하는 것이 가장 기본적이었다. 하지만 최근에는 컴퓨팅 환경의 변화로 인해 저장 매체의 이미지 복사에 앞서 휘발성 정보를 먼저 수집하고 분석하는 쪽으로 방법론이 빠르게 이동하고 있다.

휘발성 정보에는 시스템 시간, 네트워크 연결 정보, 로그온 사용자 정보, 실행되고 있는 프로세스 정보 등이 있는데, 이런 정보는 컴퓨터가 꺼지고 나면 증발하듯 사라지기에 우선적으로 수집하여야 한다. 다시 말해 살아있는 시스템에서 수집 가능한 모든 정보의 수집과 분석, 그리고 이를 바탕으로 한 사고 처리까지가 담당범위이다.

 

1.1    라이브 리스폰스의 중요성

-       휘발성 저장장치에서만 찾을 수 있는 정보가 있다. 프로세스 목록, 열려있는 파일목록, 클립보드, 사용자 정보, 임시파일, 비밀번호 등을 포함하고 있으며 비휘발성 장치를 거치지 않고 바로 메모리에 로드되는 악성프로그램들이 존재하기에 이는 중요하다.

-       수집한 휘발성 정보를 우선적으로 평가함으로써 시스템의 대략적인 상태 파악 가능, 이를 통하여 조사의 세부 방향을 잡는데 기초적인 밑그림을 제공한다.

-       종료를 하기에 곤란한 상태에 있는 서버 컴퓨터와 같은 컴퓨터를 조사할 때 어쩔수 없이 라이브러리 상태에서 모든 증거를 수집하고 문제를 해결해야 한다.

1.2    시기

-       시간이 촉박하지만 않다면 항상 라이브 리스폰스를 수행하는 것이 좋은 판단이다.

-       비휘발성 저장장치에서 증거가 수정되거나 삭제되고 있는 상황에서 수행하는 것은 옳지않다. 예로 Secure Deletion & Secure Erase, Wiping과 같은 방법이 있다. 이런 의심이 들 경우 전원 플러그를 뽑는 것이 좋다. 이는 해커가 삭제하려는 파일보다 휘발성 증거들이 덜 중요할 수 있기 때문이다. 제한적인 휘발성 정보만 수집하고 싶다면 네트워크 연결정보와 메모리 덤프를 우선적으로 수집할 것을 권장한다.

-       사용하려는 도구들이 조사하고자 하는 윈도우 버전에서 충분한 검토가 이루어지지 않은 때에는 라이브 리스폰스를 수행하지 않는 것이 좋다. 이는 시스템에 미치는 영향을 전혀 예측할 수 없기 때문이다. (단, 이는 상황에 따라 조사관의 판단에 의해 용인 가능하다.)

1.3    원칙

-       휘발성 증거를 수집할 때 최우선으로 적용되는 원칙은 “원본에 대한 영향을 최소화 한다”는 것이다. 이는 동작중인 컴퓨터를 대상으로 하기 때문에 조사자의 휘발성 정보 수집행위가 시스템에 미치는 영향을 완전히 배제할 수 없다.

.

1.4    영향

-       메모리 : 도구를 실행하면 프로세스가 생성되고 실행 코드와 오브젝트드링 메모리에 적재된다. 이때 두 영역에서 수정 및 삭제가 발생한다. 첫째로, 프로세스는 메모리의 일정 영역을 점유하고 그 영역에 있던 이전 데이터를 덮어쓴다. 그 부분은 종료된 다른 프로세스가 사용하던 영역이거나, 임시데이터가 저장되어 있던 영역일 수 있다. 둘째로, 커널 오브젝트를 과리하는 시스템 테이블이 갱신된다. 테이블이 가득차 있다면 가장 오래된 항목이 자동 삭제된다.

-       네트워크 : 도구가 네트워크 기능을 이용한다면 시스템은 지정된 소켓을 열고 외부와 네트워크 연결을 맺는다. 방화벽 기능 활성화시 관련 로그가 기록되고 로그 파일이 쌓이면서 이전에 사용치 않던 HDD 영역을 사용하게 된다.

-       프리 패치 파일 : 윈도우는 새로운 프로그램이 실행될 때마다 Prefetch 파일을 만든다. 여기서 윈도우 XP에선 프리패치파일의 개수에 제한(120개)가 있기 떄문에 초과시 오래된 파일을 삭제한다.

-       레지스트리 : 라이브 리스폰스 도구들은 레지스트리에 접근하여 그 값을 사용한다. 윈도우 설치 정보를 찾아보거나, EULA(End User License Agreement)가 사용자에 의해 승인되었다는 것을 기록하기도 한다. 레지스트리에 대한 쓰기 작업은 레지스트리 키의 마지막 쓰기 시간 변경을 의미한다. 도구들은 이곳에 다양한 기록들을 남기게 된다.

-       DLL : 포렌식 도구가 DLL 파일을 필요로 한다면 해당 파일을 찾아서 읽을 것이며 파일의 접근 시간을 갱신할 것이다. 하지만 DLL 파일의 접근 시간 갱신은 크게 신경 쓸 필요가 없어 보인다. 하지만 사용하는 시스템 DLL이 이미 변조되거나 교체되었다면 문제는 달라진다.

-       로그 파일 : 도구가 에러를 발생시켰다면 기본적으로 그 정보는 이벤트 로그에 기록된다. 에러가 아니더라도 도구 자체가 이벤트 로그에 스스로 로그 기록을 남길 수 있다. 앞에서도 말했지만 이러한 로그들이 생성 될 때 하드 드라이브의 미할당 영역을 사용할 것이고, 이는 오래된 로그를 삭제할 수도 있다.

명심해야 할 것은 어떤 식으로 노력하든 라이브 리스폰스 도중에 실행하는 여러 도구와 조사관의 행위가 시스템에 전혀 영향을 미치지 않을 수는 없다. Write-Protection Device에 연결해서 하드를 카피하는 것과는 달리, 라이브 리스폰스는 중간에 어떤 보호 장치도 없으며 동작 중인 시스템을 대상으로 한다. 이 과정만으로도 시스템의 메모리, 레지스트리, 파일 시스템에 영향을 미친다. 따라서 영향의 배제가 아닌 최소화를 목적으로 해야 한다.

 

2      사전준비

포렌식에서 여러 사전 준비 단계가 있고 하드웨어 준비, 소프트웨어 준비, 절차에 대한 준비로 나눌 수 있다. 하드웨어에는 분석용 컴퓨터나 장비들도 속하지만 증거물을 만질 때 사용할 장갑이나 사진기, 시계 등도 포함되며 소프트웨어엔 분석용 도구들과 라이브 리스폰스에서 사용할 도구가 포함된다. 절차는 증거의 수집과 분석, 그리고 최종 보고서 작성에 이르기까지의 일련의 합의된 과정을 의미한다.

 

2.1    도구 선택 단계

라이브 리스폰스에서 사용하는 도구는 적법한 절차를 통해 구해야 하고, 임의로 수정되거나 바이러스에 감염되지 않은 파일임을 증명할 수 있어야 한다. 컴퓨터 포렌식은 언제나 소송 같은 법적인 절차를 대비해야 하기 때문에 사용하는 도구들도 항상 법의 테두리 안에 있는 것들만 사용해야 한다.

2.2    도구 테스트 단계

도구를 선택했다면 다음은 그 도구들이 과연 예상했던 것처럼 잘 동작하는지 테스트하고, 시스템에 어떤 영향을 미치는지를 모니터링 할 차례이다. 한 버전에서 잘 동작하는 도구가 다른 버전 혹은 다른 서비스 팩에서도 잘 동작하리라는 보장은 없다. 따라서 라이브 리스폰스에 사용할 도구들은 다양한 버전과 서비스 팩에서 반복적으로 실행해 보고 확인해볼 필요가 있다.

2.3    문서화 단계

문서화는 포렌식 전반에 걸쳐 항상 적용되어야 하는 필수 사항이다. 선택한 도구들의 목록을 만들고 그것의 출처와 해시 값을 기록하라. 도구들을 테스트하고 테스트한 시스템의 환경과 그 결과, 그리고 그것이 시스템에 미치는 영향을 꼼꼼히 기록하자.

특히 도구가 시스템에 미치는 영향에 대한 문서화는 필수적이다. 이것을 게을리하면 실제 분석 과정에서 악성 프로그램이 시스템에 미친 영향과 사용한 도구가 미친 영향을 구별하지 못해서 큰 혼란을 겪게 된다.

2.4    모니터링과 문서화

라이브 리스폰스 도구들이 시스템에 어떤 영향을 미치는가를 문서화할 때 가장 중점을 두어야 하는 부분에는 세가지가 있다. 하나는 실행될 때 로드되는 DLL 파일 목록, 다음은 레지스트리 접근 정보, 마지막은 프로그램이 수정 및 생성하는 파일 목록이다. 이는 프로세스 모니터로 확인이 가능하다.

 

2.5   시스템 DLL 파일 사용하지 않기

앞에서 말한 바와 같이 라이브 리스폰스가 시스템에 미치는 영향을 완전히 없애는 것은 불가능하며, 최소화하는 방안에도 많은 걸림돌이 있다. 대상 시스템에 미치는 영향 중에서 가장 최소화하기 쉬운 것이 DLL파일이다.

이러한 DLL을 최소화 하기 위하여 상대적으로 적은 DLL을 로드하는 CLI 프로그램들로 도구들을 구성하는게 좋다. GUI의 경우 CLI에 비하여 많은 DLL을 로드하기 떄문이다. 이에 더해 시스템 DLL 파일을 사용하지 않는 방법에는 크게 3가지가 있다.

-    DLL 파일들을 실행 파일이 있는 폴더로 모두 복사

-      Dynamic-Link Library Redirection 기능을 이용

-      실행 파일의 코드를 수정

세가지 방법 중에서 로드되는 DLL 파일들을 실행 파일과 같은 폴더로 복사해 넣는 방법이 가장 간단하다. 그러나 별 효과가 없기에 실무에선 적합하지 않다. 프로세스가 필요한 DLL 파일을 찾기 위해 검색하는 폴더의 순서는 다음과 같다.

1)     SxS 파일에서 지정된 폴더 안의 파일

2)     Dynamic-Link Library Redirection에 의해 지정된 폴더에 있는 DLL 파일

3)     lpPathName이 가리키고 있는 폴더의 DLL 파일

4)     알려진 DLL 파일 (Known-DLL File)

5)     실행 파일이 있는 폴더에 있는 DLL 파일

6)     현재 폴더에 있는 DLL 파일

7)     시스템 폴더에 있는 DLL 파일

8)     윈도우 폴더에 있는 DLL 파일

9)     윈도우 환경설정 정보(Path)에 있는 DLL 파일

 

가장 높은 순위에 있는 SxS는 프로그램을 만들 때 컴파일러에서 별도의 옵션을 지정해야만 만들 수 있으며, 3번의 경우 코딩 시에 SetDllDirectory 함수를 넣어주어야만 한다. 따라서 이미 컴파일이 끝난 도구는 이를 응용할 수 없다. 그러므로 가장 간단하고 편리한 것이 2번의 방법이다.

 

2.6    파일 이름 변경

사용할 도구들이 확정되었다면 파일 이름을 원래의 것과 구별되는 것으로 변경하는 것이 좋다. 그렇지 않으면 기존 프로그램과 별도의 도구가 혼동될 경우가 있기 때문이다.

 

3      휘발성 정보의 수집 순서

휘발성 정보에도 여러 종류가 존재하기에 어디에 우선순위를 두고 먼저 수집을 해야 할지 결정을 해야 한다. 이는 어떻게 기준을 잡느냐에 따라 다르므로 주관적이라 할 수 있다. 이제 이에 대하여 알아보자.

실전 윈도우 포렌식	RFC 3227
-       물리적 메모리	-       레지스터, 캐시
-       네트워크 연결 정보	-       라우팅 테이블, ARP 캐시
-       프로세스 정보	-       프로세스 정보
-       열린 파일 목록	-       물리적 메모리
-       로그온 사용자(세션)	-       임시 파일 시스템
-       열린 TCP/UDP 포트 정보	-       디스크
-       프로세스와 포트 맵핑	-       원격 로그온과 모니터링 데이터
-       라우팅 테이블	-       물리적 설정, 네트워크 토폴로지
-       네트워크 인터페이스	-       기타 저장 장치

물리적 메모리는 수집하는데 시간이 가장 오래 걸림에도 불구하고 다른 정보들보다 먼저 수집하려는 이유는 대부분의 휘발성 정보들이 모두 메모리에 들어있기 때문에 물리적 메모리를 수집함으로써 그것들을 한번에 수집할 수 있고, 물리적 메모리 이외의 휘발성 정보들은 변조나 은폐가 가능하기 때문에 그 신뢰성이 물리적 메모리에 비해 떨어지기 때문이다.

표 출처 : 서강대 박종석 선임 - 활성 시스템 분석.pdf   2013.11.14