Test

#About

평소에 컴퓨터로 업무와 간단한 게임 이외의 작업은 하지 않던 나잘난군은 최근 자꾸 컴퓨터가 이상동작을 함을 느끼게 되었고, 평소에 친분이 있던 당신에게 분석을 의뢰하여 당신은 나잘난군의 PC의 메모리 덤프를 요청하여 분석을 진행하게 되었다. 메모리상에 존재하는 악성 Process의 이름과 해당 악성 프로세스의 부모 프로세스의 부모 프로세스의 이름을 구하시오.

(인증형식 : Process Name_부모의 부모Process Name)

#Solution

[그림 1 ] - 문제 파일 확인

제공 받은 문제 파일에서 확장자 .raw이 가지는 특징을 검색해보았더니 포렌식 위키에서 정보를 얻을 수 있었다

http://forensic.korea.ac.kr/DFWIKI/index.php/메모리_획득_도구

[그림 2] - 메모리 이미지의 포맷 유형

위 그림에서 메모리 이미지 덤프 파일임을 확인하고 메모리 파일의 분석을 위해 파이썬 기반의 메모리 분석 도구인 Volatility를 이용했다

http://www.volatilityfoundation.org/

[그림 2] - Imageinfo

Imageinfo 명령은 메모리 덤프를 시킨 시스템 정보의 요약을 제공하며, Suggested Profile 필드에 나온 결과 값인 

서비스 팩 정보는 다른 플러그인을 사용함에 있어 --profile의 파라미터 값으로 전달되어 사용된다

문제에서 요구하는 것은 프로세스와 관련되므로 프로세스의 정보를 보여주는 명령어인 psscan를 사용했다

[그림 3] - 의심되는 프로세스 확인

psscan을 이용하여 프로세스 정보를 확인 결과, sms.exe라는 프로세스가 메모리에 상주하고 있었다

sms.exe라는 파일은, Session Manager SubSystem를 의미하는 smss.exe와 유사한 이름을 가지는 프로세스로, 

기본적으로 윈도우 시작 프로세스 과정에 실행되는 smss.exe와 달리, sms.exe는 따로 윈도우 기본 프로세스에 속하지 않는다

[그림 4] - PPID 확인

문제에서 요구하는, 메모리상의 악성 프로세스의 부모 프로세스를 따라 가보았더니 더욱이 의심되는 sms.exe.exe라는 

이름의 프로세스를 확인할 수 있었고, sms.exe.exe의 부모 프로세스를 따라가보았더니 explorer.exe라는 프로세스임을 확인할 수 있었다

Answer = sms.exe_explorer.exe

[ + ] 윈도우 기본 프로세스 목록

csrss.exe

csrss는 클라이언트/서버 런타임 하위 시스템을 나타내며 항상 실행되어야 하는 필수 하위 시스템이며 csrss는 콘솔 창, 스레드 생성과 삭제 및 16비트 가상 MS-DOS 환경의 일부를 담당한다

explorer.exe

작업 표시줄, 바탕 화면 등으로 표시되는 사용자 셸이며 윈도우의 대부분의 명령 처리를 관리한다

lsass.exe

로컬 보안 인증 서버인 이 프로세스는 Winlogon 서비스에 대해 사용자 인증 프로세스를 생성한다

smss.exe

사용자 세션의 시작을 담당하는 세션 관리자 하위 시스템으로, 시스템 스레드에서 시작되며 Winlogon 및 Win32(csrss.exe)프로세스의 시작과 

시스템 변수설정을 비롯한 다양한 작업을 수행한다 또한, smss.exe는 이러한 프로세스를 시작 후 Winlogon 또는 csrss가 끝나기를 기다린다. 

Winlogon 또는 csrss 정상적으로 끝나면 시스템이 종료되지만 예기치 않은 동작이 일어나면 smss.exe는 시스템이 응답을 중지하도록 한다

services.exe

시스템 서비스의 시작, 중지 및 시스템 서비스와의 상호 작용을 담당하는 서비스 제어 관리자이다

spoolsv.exe

스풀 서비스는 스풀링된 인쇄/팩스 작업 관리를 담당한다

svchost.exe

DLL에서 실행되는 다른 프로세스의 호스트 역할을 하는 일반 프로세스이다

system

대부분의 시스템 커널 모드 스레드가 System 프로레스로 실행된다

system Idle Process

각 프로세서에서 실행되는 단일 스레드로 시스템이 다른 스레드를 처리하지 않을 때의 프로세서 시간을 나타내는 역할을 한다

Taskmgr.exe

작업 관리자 자체에 대한 프로세스이다

Winlogon

로그온과 로그오프를 관리하는 프로세스이며, Winlogon은 사용자가 Ctrl+Alt+Del을 누를 때만 활성화되어 보안 대화 상자를 표시한다

출처 = spr2ad.tistory.com/192

#About

A고등학교 컴퓨터실은 최신 컴퓨터를 기반으로 다양한 IT수업을 진행한다. 최근 학생들이 학교 컴퓨터실 몰래 침입해 게임을 한다는 소문을 듣고 분석을 시도하였다. 하지만 알 수 없는 이유로 학교 컴퓨터에 존재하는 모든 Prefetch 파일과 링크 파일이 삭제되어 과거 실행된 프로그램에 대한 정보를 얻을 수 없었다. 아쉬운 대로 학교측에서는 레지스트리 파일만 확보하여 분석을 의뢰해 왔다. 주어진 레지스트리 파일을 분석하여 학생들이 즐긴 것으로 의심되는 게임의 이름을 알아내라.

(영어로 입력, 대소문자 구분 없음)

#Solution

[그림 1] - 문제 파일 확인

문제로부터 제공받은 SHIM CACHE_2 폴더 안에는 5개의 레지스트리 하이브 파일을 확인할 수 있었으며

 그 중 윈도우에 설치 된 응용 프로그램 및 소프트웨어에 관련한 레지스트리 하이브 파일은 SOFTWARE에 해당한다

[그림 2] - 레지스트리 트리 확인

레지스트리 파일의 분석을 위해 REGA라는 도구를 사용 했으며 출처는 아래와 같다

http://forensic.korea.ac.kr/tools/rega.html

[그림 2]의 레지스트리를 확인하면 Blizzard Entertainment의 하위 트리에서 Starcraft를 확인할 수 있다

Answer = Starcraft

#About

주어진 바로 가기 파일이 가리키는 대상 중 복사되지 않은 대상의 크기를 찾시오.

(단위는 Byte이며 정답 입력시 단위를 제외한 십진수 아라비아 숫자만 입력)

#Solution

[그림 1] - 문제 파일 확인

해당 문제에서 제공받은 폴더를 열어본 결과 5개의 바로 가기 파일을 확인할 수 있었으며, 문제에서 요구하는 핵심인

복사되지 않은 파일을 찾기위해서는 먼저 MAC Time에 대해 알아야 하며 MAC이 의미하는 바는 아래와 같다

Modified Time

수정 시간

Access Time

접근 시간

Creation Time

생성 시간

문제를 해결하기 위해서는 MAC Time의 시간 정보를 확인하고, 해당 정보가 가지는 의미를 파악하는 능력이 필요하다

[그림 2] - MAC Time 상태 변화

위 [그림 2]는 MAC Time이 상황에 따라 보존 or 변경되는 경우를 표로 나타낸 것이며 포렌식 위키에서 확인할 수 있었다

http://forensicswiki.org/wiki/MAC_times

이 중에서 문제에서 요구하는 것은 "복사되지 않은 대상"이므로 [그림 1]에서 확인했던 바로 가기 파일 5개 중 4개는 복사가 되었음을 추측할 수 있다

파일이 복사가 된 경우, [그림 2]에서 확인할 수 있듯 Access와 Creation 시간이 복사된 시점으로 바뀌고 Modified 시간은 보존 된다.

위 자료를 토대로 파일을 분석한 결과 아래의 (1,2,3,5).lnk 파일이 Modified Time이 2015년으로 보존 된 채로 Creation,Access Time이 2016년으로 변경되었다

[그림 3] - 1.lnk

[그림 4] - 2.lnk

[그림 5] - 3.lnk

[그림 6] - 5.lnk

위 파일들은 전부 복사가 됨으로 인해서 Creation Time과 Access Time이, Modified 시간보다 최근을 가리키며

오로지 4.lnk 파일만이 복사 되지않은 시간을 가리킨다 ( Creation Time < Modified Time < Access Time )

[그림 7] - 4.lnk

따라서 복사 되지 않은 파일은 4.lnk이며 해당 파일의 바이트 크기는 [그림 7]에서 확인할 수 있듯 248435이다

Answer = 248435

[ + ] 문제를 풀며

[그림 1]의 수정한 날짜의 시간과 010 Editor에서 파싱된 시간의 Modified 시간이 서로 일치 하지 않던 것이 궁금했고

궁금증을 해결하기 위해 010 Editor가 아닌 LNK Parser에서 링크 파일 파싱의 결과를 살펴보던 중 궁금증을 해결할 수 있었다

[그림 8] - 시간 비교 ( 010 Editor의 UTC+9 값과 동일 )

[그림 1]의 수정 시간은 링크 파일 자체의 수정 시간을 의미하며, 010 Editor에서의 수정 시간은 링크 파일이 가리키는 원본 파일의 수정 시간을 의미한다

[ + ] TIPS

Windows XP이후 Access Time의 경우 기본적으로, 읽기 작업을 진행할 때마다 Access Time을 업데이트하는 것은 성능면에서 비효율적이기 때문에

Access Time의 업데이트 기능이 비활성화 되어 있으며 활성화를 시키기 위해서는 아래의 경로에서 레지스트리 값을 수정해주어야 한다

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\FileSystem\NtfsDisableLastAccessUpdate

0 = 활성화 

1 = 비 활성화