Yum_Yum

[Tool] Volatility

(1) Volatility란?

메모리 포렌식에서 메모리 덤프 파일을 분석할 때, 가장 많이 사용되고 있는 도구
오픈 소스 기반으로 CLI 인터페이스를 제공하는 메모리 분석 도구
컴퓨터(노트북)에서 덤프 된 파일을 분석 가능하며, 프로세스 정보와 네트워크 정보 등을 확인할 수 있음
유용 정보들이 자세하게 나오기 때문에 많이 사용
프로세스 덤프 기능을 제공하여 기존 컴퓨터나 노트북에서 실행되고 있던 프로세스 내용 확인 가능

볼라틸리티 도구는 현재 3 베타 버전까지 출시 되었지만, 필자는 2.6 버전대를 많이 사용하였으므로, 2.6 버전 소개 기준이다.

그리고 운영체제는 Windows 환경 기준이다.

설치 / 참조 사이트 : https://www.volatilityfoundation.org/

The Volatility Foundation - Open Source Memory Forensics

The Volatility Foundation is an independent 501(c) (3) non-profit organization that maintains and promotes The Volatility memory forensics framework.

www.volatilityfoundation.org

(2) 메모리 덤프

2-1. 물리 메모리 덤프

하드웨어를 이용한 덤프 : FireWire(IEEE 1394)를 이용한 메모리 덤프
장점 : 악성 프로그램에 영향을 받지 않으며, 빠른 메모리 덤프와 무결성 최소화
단점 : 안전성에 대한 검증이 필요하며, 간혹 시스템 크래시 발생

2-2. 소프트웨어 메모리 덤프

DD, MDD, Winen, WIN32(64)DD & DumpIt, Memorize ProDiscovery, HBGary, FastDumpPro etc...
장점 : 추가 장치 불필요, 오픈 소스 및 프리웨어, 사용 제품의 경우 원격 덤프 가능
단점 : 커널 루트킷에 취약, OS 제약, 수집 시 메모리에 흔적 남음

2-3. 크래시 덤프

시스템 유지에 치명적인 영향을 주는 문제가 발생하였을 때, 문제의 원인을 찾기 위해 윈도우가 자동 생성하는 메모리 덤프
Blue Screen of Death

(3) 설치 & 사용법

3-1. https://www.volatilityfoundation.org/ 접속

Releases > 2.6 선택
Volatility 2.6 Windows Standalone Executable (x64) 선택

3-2. 파일 압축 풀기

저장 경로 선택
zip 파일 압축 풀기

3-3. 덤프 파일 폴더 안에 넣기

내가 분석할 덤프 파일(dmp, vmss, vmem 등)을 압축 풀어준 폴더 안에 넣기

3-4. cmd 창(명령 프롬프트) 켜기

검색 기능을 이용하여 cmd(명령 프롬프트) 창 켜기
내가 저장한 경로로 이동 (cd 명령어)

3-5. 덤프 파일 시스템 정보 확인

사용 방법 1 : volatility_2.6_win64_standalone.exe -f [덤프 파일명] imageinfo 명령어 입력
덤프 파일의 시스템 및 프로파일 정보 확인

추가 내용 설명

KDBG : Debugger data block의 Header에 포함된 Signature
KPCR : 사용하고 있는 CPU의 정보를 담고 있는 구조체

3-5-1. Image 정보 확인

kdbgscan : KDBG 구조체 확인
volatility_2.6_win64_standalone.exe --profile=[프로파일명] -f [덤프 파일 경로] kdbgscan > [저장 할 텍스트 파일 이름]

필자는 이미 덤프 파일이 해당 폴더에 있고, 해당 폴더에 저장할 것이기 때문에 따로 경로를 지정해주지 않았지만, 필요하면 덤프 파일 경로와 저장 할 텍스트 파일 경로를 지정해주어야 한다.

3-5-2. Image 정보 확인

kpcrscan : 사용하고 있는 CPU의 정보를 담고 있는 구조체
volatility_2.6_win64_standalone.exe --profile=[프로파일명] -f [덤프 파일 경로] kpcrscan > [저장 할 텍스트 파일 이름]

덤프 파일 경로와 저장 할 텍스트 파일 경로에 대한 내용은 위 내용인 kdbgscan과 동일하다.

(4) 플러그인

이제 본격적으로 볼라틸리티 플러그인을 사용해보고, 내용을 확인해보자.

4-1. pslist

시스템에서 사용하고 있는 프로세스 리스트 (가상 주소)
-P 옵션은 물리적 주소를 확인할 때 사용
Offset(V) : 가상 주소
Start : Process 시작 시간
Exit : Process 종료 시간

사용법은 다음과 같다.

volatility_2.6_win64_standalone.exe --profile=[프로 파일명] -f [덤프 파일명] pslist

4-2. psscan

이미 종료된(Interactive) 프로세스와 루트킷에 의한 hidden / unlinked 프로세스 확인 가능

사용법은 다음과 같다.

volatility_2.6_win64_standalone.exe --profile=[프로 파일명] -f [덤프 파일명] psscan

4-3. pstree

hidden / unlinked 프로세스까지 확인 가능
자식 프로세스는 . 을 통해 트리 형태로 보여줌

사용법은 다음과 같다.

volatility_2.6_win64_standalone.exe --profile=[프로 파일명] -f [덤프 파일명] pstree

4-4. psxview

psscan과 pslist 등에서 True나 False로 보여줌
수상한 프로세스를 찾을 때 유용한 플러그인

사용법은 다음과 같다.

volatility_2.6_win64_standalone.exe --profile=[프로 파일명] -f [덤프 파일명] psxview

4-5. dlllist

Image에서 DLL 리스트를 보여줌
-p 옵션을 통해 pid를 넣어주면, 그에 해당하는 dll 리스트 보기도 가능

사용법은 다음과 같다.

volatility_2.6_win64_standalone.exe --profile=[프로 파일명] -f [덤프 파일명] dlllist

4-6. ldrmodules

PEB 안의 linkedl list에서 link를 끊는 것을 통해 DLL을 숨기는 DKOM 기법의 경우, VAD(Virtual address Descriptor)에 정보가 남아 있기 때문에 이를 탐지 가능
이 명령어는 unlinked 된 명령어를 출력
해당 명령어 결과에서 Memory Mapping 된 PE 파일이 PEB List에 존재하면 True, 존재하지 않으면 False을 출력
-v 또는 -verbose option을 사용하여 모든 Entry의 Full Path를 확인 가능

사용법은 다음과 같다.

volatility_2.6_win64_standalone.exe --profile=[프로 파일명] -f [덤프 파일명] ldrmodules

4-7. handles

프로세스에 의해 열린 핸들의 목록을 나타냄
프로세스는 CreateFile 같은 함수를 사용하여 핸들을 획득
그러한 핸들은 CloseHandle 함수가 호출되기 전까지 유효하게 사용

사용법은 다음과 같다.

volatility_2.6_win64_standalone.exe --profile=[프로 파일명] -f [덤프 파일명] handles

4-8. memdump

해당 명령어를 사용해서 프로세스의 다양한 Memory Segment에서 모든 데이터를 추출하여 덤프 파일로 생성
명령어에서 사용하는 ./는 해당 경로에 덤프 파일을 저장한다는 뜻

사용법은 다음과 같다.

volatility_2.6_win64_standalone.exe --profile=[프로 파일명] -f [덤프 파일명] -p [PID] memdump -D ./

4-9. vadwalk

VAD tree(Virtual Address Descriptor tree)란 자체 밸런싱 바이너리 트리를 뜻함
이는 특정 노드의 왼쪽은 특정 노드보다 낮은 값의 노드, 오른쪽은 특정 노드보다 높은 값의 노드로 이루어져 있는 트리를 뜻함
Windows memory manager에서 프로세스가 할당 받은 메모리를 표현하기 위해 사용

사용법은 다음과 같다.

volatility_2.6_win64_standalone.exe --profile=[프로 파일명] -f [덤프 파일명] -p [PID] vadwalk

4-10. vadtree

vad 노드들을 트리 형태로 보여주는 명령어

사용법은 다음과 같다.

volatility_2.6_win64_standalone.exe --profile=[프로 파일명] -f [덤프 파일명] -p [PID] vadtree

4-11. vadinfo

Virtual address의 시작/끝, Tag, Flag, Kernel Memory의 MMVAD 구조체 주소, Memory Protection 등을 보여주는 명령어

사용법은 다음과 같다.

volatility_2.6_win64_standalone.exe --profile=[프로 파일명] -f [덤프 파일명] -p [PID] vadinfo

4-12. vaddump

각각의 VAD Segment에 포함된 Data를 dump하는 명령어
memdump와는 달리 두 도구에서 dump되는 dmp 파일의 이름이 Memory 주소 영역으로 되어 있음
PhysicalOffset이 파일명에 들어가는 이유는 같은 이름을 가진 2개 이상의 프로세스들을 구분하기 위함
명령어에서 사용하는 ./는 해당 디렉토리에 저장한다는 의미

사용법은 다음과 같다.

volatility_2.6_win64_standalone.exe --profile=[프로 파일명] -f [덤프 파일명] -p [PID] vaddump -D ./

4-13. modules

시스템에 로드된 커널 드라이버들을 보여주는 명령어
이 명령어는 PsLoadedModuleList가 가리키는 _LDR_DATA_TABLE_ENTRY 구조의 이중 연결 목록을 살펴봄
hidden/unliked kernel driver는 출력하지 않음
기본적으로 Virtual Address로 출력하며, Physical Address를 확인하려면 -P 옵션을 추가

사용법은 다음과 같다.

volatility_2.6_win64_standalone.exe --profile=[프로 파일명] -f [덤프 파일명] modules

4-14. modscan

해당 명령어는 실제 메모리에서 풀 태그를 검색하여 LDR_DATA_TABLE_ENTRY 구조를 찾음
이전에 로드 되었던 드라이버, 루트킷에 의해 hidden/unlinked 된 드라이버도 출력
Volatility에서는 Physical Address로 출력

사용법은 다음과 같다.

volatility_2.6_win64_standalone.exe --profile=[프로 파일명] -f [덤프 파일명] modscan

4-15. moddump

해당 명령어는 커널 드라이버를 파일로 덤프해주는 명령어
이 명령어는 정규 표현식과 Physical Offset을 이용한 필터를 지원
모든 드라이버들을 덤프하고 싶으면 아무런 필터를 적용하지 않으면 됨

사용법은 다음과 같다.

volatility_2.6_win64_standalone.exe --profile=[프로 파일명] -f [덤프 파일명] moddump

4-16. ssdt

SSDT(System Service Descriptor Table)는 유저 영역과 커널 영역 사이의 주된 인터페이스
과거에는 악성코드가 SSDT 후킹을 시도하곤 했지만, MS사에서 PatchGuard를 발표하면서 지금은 거의 사라진 후킹 방법
해당 명령어는 Native/GUI SSDT의 함수들을 list 시켜주는 명령어
ETHREAD 객체를 스캔한 후, 모든 유일한 ETHREAD.Tcb.ServiceTable Pointer들을 모아서 확인하기 때문에 루트킷에 의해 덮어 쓰거나 복사된 SSDT 미탐을 탐지 가능

사용법은 다음과 같다.

volatility_2.6_win64_standalone.exe --profile=[프로 파일명] -f [덤프 파일명] ssdt

4-17. driverscan

해당 명령어는 메모리의 DRIVER_OBJECT를 스캔하는 명령어
이는 커널 모듈을 찾을 수 있는 또 다른 방법이며, 모든 커널 모듈이 DRIVER_OBJECT와 관련된 것은 아님

사용법은 다음과 같다.

volatility_2.6_win64_standalone.exe --profile=[프로 파일명] -f [덤프 파일명] driverscan

4-18. filescan

해당 명령어는 메모리의 FILE_OBJECT를 스캔하는 명령어
이는 루트킷이 디스크 파일을 숨기고, 루트킷이 실제 시스템의 open handle을 숨기는 기능을 하는 API 함수들을 후킹하더라도 open File을 찾을 수 있음
FILE_OBJECT와 offset, file name, number of pointers to the object 등을 결과로 출력

사용법은 다음과 같다.

volatility_2.6_win64_standalone.exe --profile=[프로 파일명] -f [덤프 파일명] filescan

4-19. mutantscan

해당 명령어는 메모리에서 KMUTANT 객체를 스캔하는 명령어
mutant는 윈도우에서 named semaphore를 구현한 것
이것은 악성코드의 단일 복사본이 동시에 실행되도록 하기 위해 악성코드가 사용
CID 컬럼은 Process ID가 Thread ID를 보여줌
특정 악성코드 가닥이 사용하는 mutant의 이름을 분석하면, 악성코드가 시스템에서 실행 중인지 즉시 알 수 있음

사용법은 다음과 같다.

volatility_2.6_win64_standalone.exe --profile=[프로 파일명] -f [덤프 파일명] mutantscan

4-20. thrdscan

해당 명령어는 메모리의 ETHREAD 객체를 스캔하여 보여주는 명령어
ETHREAD는 부모 프로세스를 식별할 수 있는 정보를 가지고 있기 때문에 이는 hidden Process를 찾는데 도움을 줌

사용법은 다음과 같다.

volatility_2.6_win64_standalone.exe --profile=[프로 파일명] -f [덤프 파일명] thrdscan

4-21. threads

해당 명령어는 모든 프로세스를 반복하고, 모든 프로세스의 모든 스레드를 나열하는 명령어
각 쓰레드에 속한 레지스터 정보, 쓰레드 시작 주소와 디스어셈블 코드 등 조사에 관련된 다양한 정보를 제공해주는 명령어
ETHREAD 객체 가상 주소, PID, TID, Thread와 관련된 모든 tag(SystemThread, AttachedProcess, HookedSSDT), 생성/종료 시간, 상태, 순서, 시작 주소 등을 확인 가능
SSDT base 주소와 각 Service Table, Hook 된 함수도 출력해 줌

사용법은 다음과 같다.

volatility_2.6_win64_standalone.exe --profile=[프로 파일명] -f [덤프 파일명] threads

4-22. netscan

해당 명령어는 Vista, 2008, Windows 7 이미지에서 connections와 socket을 확인할 수 있는 명령어

사용법은 다음과 같다.

volatility_2.6_win64_standalone.exe --profile=[프로 파일명] -f [덤프 파일명] netscan

4-23. hivescan

해당 명령어는 메모리 덤프로부터 CMHIVEs(Registry hives)의 Physical Address를 찾아주는 명령어

사용법은 다음과 같다.

volatility_2.6_win64_standalone.exe --profile=[프로 파일명] -f [덤프 파일명] hivescan

4-24. hivelist

해당 명령어는 메모리 덤프로부터 Registry hives의 Virtual Address와 Disk상의 절대 경로를 출력해주는 명령어

사용법은 다음과 같다.

volatility_2.6_win64_standalone.exe --profile=[프로 파일명] -f [덤프 파일명] hivelist

4-25. userassist

해당 명령어는 시스템에서 실행되었던 프로그램의 목록과 실행 횟수, 그리고 마지막 실행 시간 등의 정보를 출력해주는 명령어

사용법은 다음과 같다.

volatility_2.6_win64_standalone.exe --profile=[프로 파일명] -f [덤프 파일명] userassist

4-26. malfind

해당 명령어는 일반적인 방법이나 툴로 찾아내지 못하는 Code/DLLs를 VAD tag나 Page Permission과 같은 특성에 기반하여 확인 가능
malfind의 목적은 일반적인 Method/Tool로는 확인할 수 없는 DLL들을 찾는 것
CreateRemoteThread > LoadLibrary를 이용하여 삽입된 DLL은 hidden 상태가 아니므로 dlllist 명령어를 사용해서 확인 필요

사용법은 다음과 같다.

volatility_2.6_win64_standalone.exe --profile=[프로 파일명] -f [덤프 파일명] -p [PID] malfind

4-27. svcscan

해당 명령어는 메모리에 어떤 서비스가 등록되었는지 확인하는 명령어
각 윈도우 서비스에 대한 프로세스 ID와 서비스 이름, 서비스 타임, 서비스의 현재 상태 등을 확인 가능

사용법은 다음과 같다.

volatility_2.6_win64_standalone.exe --profile=[프로 파일명] -f [덤프 파일명] svcscan

4-28. callbacks

해당 명령어는 다양한 소스들로부터 설치된 콜백 루틴들을 단순히 열거하는 명령어

사용법은 다음과 같다.

volatility_2.6_win64_standalone.exe --profile=[프로 파일명] -f [덤프 파일명] callbacks

4-29. driverirp

IRP Major Function Table을 보기 위해서 사용하는 명령어
해당 명령어는 드라이버의 IRP Inline Hooking을 감지하기 위한 명령어

사용법은 다음과 같다.

volatility_2.6_win64_standalone.exe --profile=[프로 파일명] -f [덤프 파일명] driverirp

4-30. devicetree

_DRIVER_OBJECT.DeviceObject.NextDevice를 통해 드라이버 객체와 장치의 관계를 보여줌
_DRIVER_OBJECT.DeviceObject.AttachedDevice를 통해 연결된 장치 관계를 보여줌
Windows는 계층화된 Driver Architecture 또는 Driver chain을 사용하므로, 여러 개의 Driver를 검사 또는 IRP에 응답 가능
RootKit은 Driver나 Device를 이러한 Chain에 검사 우회의 목적으로 삽입

사용법은 다음과 같다.

volatility_2.6_win64_standalone.exe --profile=[프로 파일명] -f [덤프 파일명] devicetree

4-31. timers

해당 명령어는 Kernel times(KTIMER)와 관련된 DPC(Deferred Procedure Calls)를 출력해주는 명령어
DPC 주소와 KTIMES를 통해 악성코드가 다양한 방법으로 커널 공간에 숨어 있는 것을 빠르게 찾을 수 있음

사용법은 다음과 같다.

volatility_2.6_win64_standalone.exe --profile=[프로 파일명] -f [덤프 파일명] timers

4-32. memmap

해당 image에서 할당 된 Memory 주소 Map을 보여줌

사용법은 다음과 같다.

volatility_2.6_win64_standalone.exe --profile=[프로 파일명] -f [덤프 파일명] -p [PID] memmap

4-33. getsids

Process와 관련된 Security ID를 보여주며, 권한 상승과 같은 의심 부분을 확인 가능
보안 식별자는 [그림 72]와 같음

사용법은 다음과 같다.

volatility_2.6_win64_standalone.exe --profile=[프로 파일명] -f [덤프 파일명] getsids

4-34. verinfo

PE 파일에 저장된 정보를 보여주며, 모든 PE 파일들이 버전 정보를 가지고 있지는 않음

사용법은 다음과 같다.

volatility_2.6_win64_standalone.exe --profile=[프로 파일명] -f [덤프 파일명] verinfo

4-35. procdump

실행 가능한 Process를 덤프
악성코드가 의도적으로 PE Header의 size 필드를 위조 시에도 확인 가능

사용법은 다음과 같다.

volatility_2.6_win64_standalone.exe --profile=[프로 파일명] -f [덤프 파일명] -p [PID] procdump

4-36. symlinkscan

Symbolic Link 객체 Scan

사용법은 다음과 같다.

volatility_2.6_win64_standalone.exe --profile=[프로 파일명] -f [덤프 파일명] symlinkscan

4-37. connscan

Pool tag scanning을 통하여 connection 구조체를 찾아 줌
이미 종료된 연결 정보도 찾을 수 있는 장점이 있음

사용법은 다음과 같다.

volatility_2.6_win64_standalone.exe --profile=[프로 파일명] -f [덤프 파일명] connscan

4-38. printkey

특정 레지스트리 키의 서브키, 값, 데이터, 데이터 타입 등을 보여줌
레지스트리 하이브의 가상 주소와 디스크 상의 절대 경로 확인 가능
해당 키를 출력하려면 -o [주소값] 옵션을 활용하면 됨

사용법은 다음과 같다.

volatility_2.6_win64_standalone.exe --profile=[프로 파일명] -f [덤프 파일명] printkey

4-39. consoles

마지막으로 사용한 콘솔 창의 명령어 확인

사용법은 다음과 같다.

volatility_2.6_win64_standalone.exe --profile=[프로 파일명] -f [덤프 파일명] consoles

(5) 추가 플러그인

해당 플러그인들은 실습 덤프 파일로 분석한 결과, 제대로 된 결과가 나오지 않아 참고하기 위한 플러그인

5-1. crashinfo

해당 명령어는 Crash dump header 정보를 출력해주는 명령어
Crash dump는 프로그램이 죽었을 때의 메모리 내용이 파일로 남기는 것을 뜻함
이 파일을 분석하면 어떤 프로그램의 오류 때문에 죽었는지 분석 가능

사용법은 다음과 같다.

volatility_2.6_win64_standalone.exe --profile=[프로 파일명] -f [덤프 파일명] crashinfo

5-2. apihooks

User-mode 또는 Kernel-mode에서의 API Hooking을 탐지하기 위해서 사용하는 명령어
IAT, EAT, Hooking을 찾아낼 수 있음

사용법은 다음과 같다.

volatility_2.6_win64_standalone.exe --profile=[프로 파일명] -f [덤프 파일명] apihooks

5-3. impscan

import 된 function에 대한 call을 검색하는 명령어
Base address를 지정해주지 않으면 프로세스의 main module 끝까지 검색

사용법은 다음과 같다.

volatility_2.6_win64_standalone.exe --profile=[프로 파일명] -f [덤프 파일명] impscan

5-4. volshell

WinDBG와 비슷한 인터페이스 제공
Memory Image를 대화 형식으로 조사 가능

사용법은 다음과 같다.

volatility_2.6_win64_standalone.exe --profile=[프로 파일명] -f [덤프 파일명] volshell

(6) DKOM을 이용한 프로세스 은닉 기법

커널 오브젝트란 커널에서 관리하는 정보를 담은 데이터 블록
윈도우는 실행 중인 프로세스를 EPROCESS 구조체로 관리하며, 이는 연결 리스트로 이어져 있음
EPROCESS 구조체 안에 LIST_ENTRY의 구조체 멤버에서 FLINK와 BLINK를 수정하여 프로세스를 은닉 시킴

(7) Volatility를 사용해 메모리를 분석할 때, 효율적인 분석을 위한 절차

침해 사고가 발생해 악성코드 감염이 의심되는 시스템에서 생성한 메모리 덤프 파일을 분석하기 위해서는 위와 같은 6단계의 절차를 이용하여 메모리 분석을 진행

# Reference

https://www.volatilityfoundation.org/

MEMORY ANALYSIS TOOLS BY C-Lab

저작자표시

'Tool' 카테고리의 다른 글

[Tool] 디지털 포렌식 유용 도구 소개 (Digital Forensics Tool) (0)	2020.05.11
[Tool] FTK Imager (0)	2020.03.01
[Tool] HxD Editor (0)	2020.03.01

[OS] 윈도우 메모리( Windows Memory)

(1) 윈도우 메모리

1-1. 메모리 내 정보

복호화 된 파일 컨텐츠
사용자 패스워드
프로세스의 임시 저장 데이터

1-2-1. 메모리 분석 이유 1

직접 메모리에 로드 되어 실행되는 악성코드 존재
소기의 목적 달성을 위해 반드시 실행 파일로 존재
압축 / 암호화 되지 않은 평문의 실행 코드가 메모리에 올라와야 함

1-2-2. 메모리 분석 이유 2

폰 노이만 아키텍처 (Von-Neumann Architecture)

(2) 메모리 구조

2-1. 32bit CPU

2^32 = 4294967296 (0 ~ 4294967295) = 4Gbyte

2-2. 가상 메모리

32bit CPU
프로세스는 자신만의 가상 주소 공간을 가짐
프로세스가 소유하고 있는 메모리에 대해서만 접근
프로세스가 실제 필요한 부분만 메모리에 올리는 Demand-Paging 기법 사용
디스크 공간을 메모리처럼 활용 - 디스크 상에 존재하는 Paging File (Swap File)
모든 프로세서 사용 가능

CODE 영역

코드 자체를 구성하는 메모리 영역
프로그램 명령이 위치하는 곳 (기계어로 제어되는 메모리 영역)

DATA 영역

전역 변수(global), 정적 변수(static), 배열(array), 구조체(structure) 등이 저장
초기화 된 데이터 저장
프로그램이 실행 될 때 생성, 종료 시 반환

BSS 영역

Block Stated Symbol
전역 변수(global), 정적 변수(static), 배열(array), 구조체(structure) 등이 저장
초기화 되지 않은 데이터 저장
프로그램이 실행 될 때 생성, 종료 시 반환

Heap 영역

동적 데이터 영역
필요에 의한 동적 메모리 할당 시 위치하는 메모리 영역
사용자 요구에 맞게 메모리 할당
메모리 주소 값에 의한 참조

Stack 영역

프로그램이 자동으로 사용하는 임시 메모리 영역
지역 변수(Local), 매개 변수(Parameter), 리턴 값 등 잠시 사용되고 사라지는 데이터 저장
함수 호출 시 생성, 함수 끝나면 반환

예시

int A 선언
실행 파일 .exe 생성 : Header(code, bss, data) > PE(Portable Executive)

(3) 메모리 구조체

3-1. EPROCESS

윈도우에서 프로세스와 관련된 정보는 EPROCESS 구조체를 사용하여 관리
메모리 덤프는 EPROCESS 구조체와 EPROCESS 구조체 앞에 나오는 헤더 정보 추출
프로세스에 대한 구조체 여부 판단 > 공격자가 수행했던 프로세스에 대한 정보 획득

3-2. EPROCESS 정보

PCB(Process Control Block) : 스케줄링 관련 정보, KPROCESS 구조체, Type 값과 Size 값 확인
Create Time / Exit Time : 프로세스 실행 / 종료 시간
UniqueProcessId : 프로세스를 식별하는 고유한 PID 값 저장
ActiveProcessLinks(이중환형 링크드 리스트) : 두 개의 값이 각각 이전 프로세스와 이후 프로세스 가리킴
PEB(Process Environment Block) : 메모리에 올라가 있는 모듈 및 실행 커맨드 명령어 등

3-3. ActiveProcessLink

Flink 값 : 다음 프로세스 ActiveProcessLink를 가리킴
Blink 값 : 이전 프로세스의 ActiveProcessLink 시작점을 가리킴
PSActiveProcessHead 전역 변수 : Flink, Blink 값을 가지고 있음

KPROCESS의 Type 값과 Size 값 확인

Process인 경우 85343690 값을 가지고 있으며, PsProcessType 값과 동일

POOL_HEADER 의 PoolTag 값 확인

(4) DKOM(Direct Kernel Object Manipulation)

커널 객체(구조체)를 변경하여 은닉하는 방식
커널 디버깅을 통해 은닉하고자 하는 프로세스의 FLINK / BLINK 변경

4-1. 프로세스 은닉

1) 프로세스 확인

2) 해당 프로세스 상세 정보 확인

blink / flink 주소 값 변경
ed [blink 주소 값] [flink 주소 값]
ed [flink 주소 값 + 0x4] [blink 주소 값]
g

.dump /f c:\dfl\dbg.dmp

이후 volatility 메모리 분석 도구를 통하여 분석할 수 있으며, 사용 플러그인은 pslist, pstree, psscan 명령어로 확인 가능하다.

(5) 메모리 분석 요구사항

커널 오브젝트 구조
프로세스 관리
메모리 관리 기법

5-1. 커널 오브젝트

커널 오브젝트에 대한 내용 및 구조는 다음 [그림 25]와 같다.

저작자표시

'OS' 카테고리의 다른 글

[OS] Windows Structure & Folder (0)	2020.05.21
[OS] Windows Boot Process (0)	2020.05.21

[OS] Windows Structure & Folder

(1) 윈도우 구조체 (Windows Structure)

1-1. HAL (Hardware Abstraction Layer)

새로운 하드웨어가 개발되어 시스템이 장착되더라도 드라이버 개발자가 HAL 표준에 따라 드라이버가 개발하면 장착된 하드웨어와 시스템 간 원활한 통신이 가능
번역자 역할

1-2. 마이크로 커널 (Micro Kernel)

본래 커널의 역할을 여러 관리자에게 분담시키고 자신의 하드웨어와의 통신만을 제어
%SystemRoot%system32%ntoskrnl.exe 파일이 수행

1-3. 입출력 관리자

시스템의 입출력을 제어
장치 드라이버 사이에어 메시지를 전달
응용 프로그램이 하드웨어와 곧바로 통신할 수 있는 통로 제공

1-4. 객체 관리자

파일, 포트, 프로세스, 스레드와 같은 각 객체에 대한 정보 제공

1-5. 보안 참조 관리자

각 데이터나 시스템 자원의 제어 허가 / 거부함으로써 강제적으로 시스템 보안 설정을 책임

1-6. 프로세스 관리자

스레드를 생성하고 요청에 따라서 처리

1-7. 로컬 프로시저 호출 (Local Procedure Call)

프로세스는 서로의 메모리 공간을 침범하지 못하기 때문에 프로세스 간에 통신이 필요한 경우에 이를 대신해 줄 수 있는 장치

1-8. 가상 메모리 관리자

응용 프로그램의 요청에 따라 RAM의 메모리를 할당해주고, 가상 메모리의 페이징(Paging) 제어

1-9. Win32 서브 시스템

Win32 서브 시스템은 윈도우의 기본적인 서브 시스템
32비트 응용 프로그램이 동작할 수 있게 도와주고, 기본적인 윈도우의 사용자 인터페이스 제공
비디오 디스플레이, 키보드, 마우스 등을 지원하는 서브 시스템

1-10. POSIX (Portable Operating System Interface)

유닉스 운영체제에 기반을 두고 있는 일련의 표준 운영체계 인터페이스

1-11. 보안 서브 시스템

사용자가 로그인 할 때, 데이터를 보호하고 운영체제가 이를 제어할 수 있도록 만든 서비스 시스템

1-12. OS/2 서브 시스템

OS/2와 호환을 위한 서브 시스템

1-13. 프로세스

실행 중인 프로그램
개별 프로세스는 자신의 가상 주소 공간에서 실행
커널이 제공하는 인터페이스를 통해서만 다른 프로세스와 연동
운영체제는 각각의 프로세스가 사용하는 시스템의 자원을 추적 및 제어

(2) Kernel (커널)

운영체제의 핵심 부분
하드웨어와 프로세스의 보안을 책임지는 역할
한정된 시스템 자원을 효율적으로 관리하는 자원 관리 역할
일관성 있는 인터페이스 제공하는 추상화 역할

(3) Windows Folder

3-1. C:\Documents and Settings

각기 다른 사용자 계정이 존재하며, 각 계정 아래에 계정 별 환경 정보를 저장
즐겨 찾기, 내 문서, 시스템 폰트, Outlook Express 편지함 등의 폴더 존재
All Users 폴더의 하위 폴더에는 모든 사용자들이 공통적으로 가지고 있는 바탕 화면과 시작 메뉴에 대한 정보 존재

3-2. C:\Program Files

각종 응용 프로그램들이 설치되는 폴더
C:\Program Files\Common Files에는 시스템 정보 파일 존재

3-3. C:\Windows

운영체제를 구성하는 핵심 파일들과 마우스 사용 커서, 글꼴 등 저장
Cursors : Windows 사용 각종 커서
Downloaded Program Files : 인터넷에서 다운로드 받은 플러그인이나 Active X 등 저장
inf : 각종 프로그램 설치 파일, inf 확장자 파일들만 모아 둔 폴더
Repair : '마지막으로 성공한 구성'으로 부팅할 때, 사용하는 레지스트리 정보 저장
System : 16bit 처리를 담당하는 시스템 드라이브와 DLL 파일 저장
System32 : Windows 실행에 핵심이 되는 DLL, Drive가 저장되어 있는 폴더
System32/config : Windows의 레지스트리 파일 저장

이외에 다른 Windows 폴더들은 다음과 같다.

저작자표시

'OS' 카테고리의 다른 글

[OS] 윈도우 메모리(Windows Memory) (0)	2020.05.21
[OS] Windows Boot Process (0)	2020.05.21

[OS] Windows Boot Process

(1) 윈도우 부팅 과정

윈도우 운영체제의 부트 프로세스 과정은 다음과 같다.

1. POST (Power On Self Test)
2. BUS Test
3. RTC (Real Time Clock)
4. Video (POST)
5. RAM Test
6. CMOS (Complementary Metal-Oxide-Semiconductor)
7. MBR (Master Boot Record)

1. MBR (Master Boot Record)
2. 부트 섹터 (Boot Sector)
3. NTLDR (Winload.exe)
4. Ntoskrnl.exe
5. Smss.exe
6. Csrss.exe
7. Wininit.exe
8. Lsass.exe
9. Services.exe
10. 프로그램 실행
11. 커널 요청

(2) 윈도우 프로세스 설명

1. csrss.exe (Client / Server Runtime SubSystem, Win32)

윈도우 콘솔 관장
스레드 생성 / 삭제
32비트 가상 MS-DOS 모드 지원

2. explorer.exe

작업 표시줄, 바탕 화면과 같은 사용자 셀 지원

3. lsass.exe (Local Security Authentication Server)

Winlogon 서비스에 필요한 인증 프로세스 담당

4. mstask.exe (Windows Task Scheduler)

시스템에 대한 백업이나 업데이트 등에 관련된 작업 스케줄러

5. smss.exe (Session Manager System)

사용자 세션을 시작
Winlogon / Win32(csrss.exe) 구동
시스템 변수 설정
Winlogon이나 csrss가 끝나기를 기다려 정상적인 Winlogon과 csrss 종료 시 시스템 종료

6. Spoolsv.exe (Printer Spooler Service)

프린터와 팩스의 스풀링 기능 담당

7. Service.exe (Service Control Manager)

시스템의 서비스들을 시작 / 정지
서비스들간 상호 작용 기능 수행

8. System

대부분의 커널 모드 스레드의 시작점이 되는 프로세스

9. System Idle Process

각 CPU마다 하나씩 실행되는 스레드로서 CPU의 잔여 프로세스 처리량을 %로 표시

10. winlogon.exe (Windows Logon Process)

사용자 로그온 / 로그오프를 담당
윈도우 시작 / 종료 시에 활성화
<단축키 : Ctrl + Alt + Del>

11. taskmgr.exe (task manager)

작업 관리자 자신

12. winmgmt.exe (Windows Manager Service)

장치들에 대한 관리
계정 관리
네트워크 등의 동작에 관련된 스크립트를 위한 프로세스

13. msdtc.exe (Distributed Transaction Coordinator)

웹 서버 및 SQL 서버 구동 시 다른 서버와의 연동을 위한 프로세스

14. ctfmon.exe (Alternative User Input Services)

키보드, 음성, 손으로 적은 글 등 여러 가지 텍스트 입력에 대한 처리를 할 수 있도록 지원

15. dfssvc.exe

분산 파일 시스템(DFS, Distributed File System)에 대한 지원을 위해 백그라운드로 실행 되는 프로세스

16. Wininit.exe

코어 시스템 프로세스, 백그라운드 프로세서

(3) Svchost.exe 프로세스

Svchost.exe

동적 연결 라이브러리(DLL)에서 실행되는 서비스의 일반 호스트 프로세스 이름
저장 위치 : %SystemRoot%\System32
Svchost.exe 정보 : HKLM/Software/Microsoft/WindowsNT/CurrentVersion/Svchost
Svchost에서 실행 중인 서비스 목록 확인 : 프로세스 모니터링 Tools (procexp, tlist, pslist...)
Svchost와 유사한 이름을 갖는 바이러스 : Win32.HLLP.Jeefo.36352, Win32.HLLW.Agobot...
Svchost로 인한 오류 현상 : CPU 점유율 상승 (시스템 지연), 메모리 증가

해당 프로세스는 작업 관리자에서 실제 악성 프로그램으로 보이지 않고, 다수의 Svchost.exe 프로세스가 실행되므로 악용되는 사례가 매우 많다.

저작자표시

'OS' 카테고리의 다른 글

[OS] 윈도우 메모리(Windows Memory) (0)	2020.05.21
[OS] Windows Structure & Folder (0)	2020.05.21

[Digital Forensic] 악성코드 포렌식 (Malware Forensics)

(1) 악성코드 포렌식(Malware Forensics)이란?

디지털 포렌식은 크게 두 가지로 나누게 되면 침해사고 포렌식과 법정 증거를 수집하여 분석하는 법정 포렌식으로 나눌 수 있음
일상적으로 이야기하는 디지털 포렌식은 법정 증거를 수집하여 분석하는 법정 포렌식이므로 정확하게 구분지어 이해해야 함

악성코드 포렌식은 침해사고 포렌식에 속하는 분야라고 할 수 있다.

적법 절차를 거쳐 증거를 수집한 후 여러 무결성 조치를 취해 증거를 보존하며 분석 해 법정에 제출하는 것이 주 목적이 아닌 침해사고의 원인과 침해 정도, 침해에 알맞은 대응, 침해 시스템에서 흔적을 수집 및 분석하여 침해사고를 일으킨 장본인을 추적하는 분야이다.

다음 내용은 일상적으로 악성코드 포렌식을 수행할 때의 일반적인 수행 과정이다.

1-1. 침해 시스템 발견

침해 시스템은 대부분 눈으로 보이는 피해를 가지고 있기도 하지만, 눈으로 보이지 않는 피해를 가지고 있기도 함
그러므로 분석 전 여부는 침해 시스템의 소유주와의 인터뷰를 통해 결정하는 것이 좋은 방법
만약 침해 시스템으로 의심이 된다면 악성코드에 의한 침해인지, 해킹에 의한 침해인지 판단
악성코드에 의한 침해라면 [그림 1] 과 같은 수행 과정을 수행해야 함

1-1-1. 휘발성 데이터 수집 (메모리 덤프 포함)

침해 시스템이 활성 상태라면 당연히 휘발성 데이터를 수집해야 함
간혹 악성코드들은 난독화가 되어 있는 경우가 있음
이럴 때 메모리 덤프를 수집해 두면 추후에 난독화 되어 있지 않은 악성코드를 메모리에서 추출하여 손쉽게 악성코드 분석이 가능

1-1-2. 시그니처 기반 분류

침해 시스템에 있는 실행파일들을 시그니처 별로 분류하여야 함
이는 툴로 수행하는 과정으로 해시 셋 적용 과정을 수행하기 위한 준비 단계라고 볼 수 있음

1-2. 해시셋 적용

해시 셋은 화이트 리스트 해시(White List Hash)와 블랙 리스트 해시(Black List Hash)로 나뉨
화이트 리스트 해시는 알려진 정상 파일들에 대한 해시 데이티베이스
블랙 리스트 해시는 알려진 악성 파일들에 대한 해시 데이터베이스
대표적으로 미국 국립표준원(NIST)에서 진행하고 있는 NSRL 프로젝트가 있으며, NSRL 프로젝트는 화이트 리스트 해시 데이터베이스를 기반으로 계속해서 알려진 정상 파일들의 해시 추가와 데이터베이스 관리를 진행
배포는 RDS(Reference Data Set)을 활용하여 매년 4번(3월, 6월, 9월, 12월)에 진행하며, 각 운영체제와 패치별로 데이터베이스를 생성하여 배포
하지만 NSRL의 해시 셋을 우리나라에 적용하기에는 약간의 문제가 있으며, NSRL은 미국이 주도적으로 하고 있기 때문에 국내 파일들에 대한 해시가 추가되어 있지 않으며, 다국어 운영체제에 대한 지원이 아직까지 미흡하기 때문
그러므로 화이트 리스트 해시 또는 블랙 리스트 해시를 적용한 결과에서 아무런 결과도 얻지 못했다고 하여 해당 시스템이 침해 시스템이 아니라는 판단을 하는 것은 굉장히 위험한 판단

1-3. 1차 분석

해시 셋에서 만약 검색 결과를 얻지 못한다면, 이제는 침해 시스템 분석을 통해 침해사고를 일으킨 악성코드 파일을 찾아야 함

1-3-1. 아티팩트 수집 / 분석

악성코드 파일을 찾기 위하여 여러 가지 흔적들을 수집하는 과정
해당 과정에서 수집한 흔적과 침해 시스템의 소유주 또는 관리자의 인터뷰를 토대로 악성 파일을 추측 / 발견해 내야 함

1-3-2. 동적 분석

빠른 대응을 위하여 우선 동적 분석을 통해 악성 파일이 어떤 행위를 하는지 파악해야 함
대표적인 동적 분석으로는 파일 생성 / 삭제 감시, 레지스트리 변경, 네트워크 통신 등이 있음

1-3-3. IOC(침해지표)

IOC(Indicator Of Compromise)는 한 문장으로 표현하면, "여러 침해사고의 흔적들을 일정한 포맷으로 정리해 놓은 문서 또는 파일"이라고 표현
IOC 관련 표준으로는 대표적으로 CSIRTs(Computer Security Incident Response Teams)의 IODEF(The Incident Object Description Exchange Format, RFC 5070)이 있음
문서를 보면 여러 개의 그룹별로 엔트리를 나누어 해당 포맷을 작성하는 사람이나 보는 사람이 이해하기 편하도록 구성되어 있음
이와 같은 개념을 바탕으로 확장성을 겸비한 Mandiant사의 OpenIOC가 탄생했다고 볼 수 있음

그렇다면 IOC, 즉 침해지표는 왜, 어디서, 어떻게 사용을 할까?

침해 지표의 이름 그대로 사용처는 대부분 침해사고 부분이다.

보통 침해사고는 악성코드에 의한 침해사고를 생각하기 쉬운데 OpenIOC의 프로젝트 목적을 보면 악성코드 침해사고는 물론 해커에 의한 침해사고에도 IOC가 적용되게끔 설계했다고 나와 있다.

그리고 IOC를 이용해 침해사고 PC에서 흔적을 찾아내는 것 뿐만이 아닌 해당 침해지표를 이용해 여러 방화벽이나 탐지 시스템, 차단 시스템의 룰을 정의할 수 있도록 포맷 자체를 간단히 OR, AND와 Item을 직관적으로 표현해 두었다.

IOC는 XML을 이용하여 작성할 수도 있고, Mandiant사에서 제공하는 IOC Editor를 이용해 작성할 수도 있다.

그렇다면 IOC 프로세스는 어떠할까?

다음 내용은 IOC의 LifeCycle이다.

IOC의 LifeCycle에 진입을 하게 되면 먼저 IOC를 생성하게 된다. (IOC Creation)

생성할 때의 내용은 기본적인 침해사고의 흔적들인데 흔적들로는 대표적으로 파일 해시 값, 네트워크 트래픽 또는 통신 서버의 주소(Domain or IP), 레지스트르 키 또는 값, 프로세스명 등을 예로 들 수 있다.

다음으로 생성한 IOC를 여러 기관들에게 배포하게 된다. (Deploy IOCs)

배포했을 때, IOC는 독립적으로 침해사고의 지표가 될 수 있지만, 기관의 성격에 따라 IOC를 근거로 침입 관련 시스템의 룰로 재생성 될 수 있다.

배포가 되었다고 끝이 나는 것이 아니다.

현대의 침해사고는 굉장히 많은 변형을 생산해 낸다.

그러므로 추가적인 침해가 의심되는 시스템을 분석해야 한다. (Identify Suspect Systems)

추가적으로 분석해야 할 시스템이 선정되면 침해사고와 관련된 흔적들을 수집한다. (Preserve / Collect Evidence)

마지막으로, 수집 된 증거들을 분석한다. (Analyze Data)

그리고 분석한 결과를 IOC 포맷으로 작성한다. (IOC Creation)

IOC는 한 번으로 끝나는 것이 아니라 계속해서 증거 수집과 분석을 통해 IOC 자체를 확장시켜야 한다.

그러므로 위와 같은 LifeCycle이 절대적으로 필요하며, 멈추어서는 안된다.

1-3-4. 백신 검사

백신 검사 단계를 의아하게 생각하는 사람도 있을 것이지만, 물론 침해 시스템이 백신이 설치되어 있었고 악성 파일을 탐지할 수 있었다면 침해사고가 일어나지 않았을 것이다.

백신이 탐지하지 못했기 때문에 침해사고가 일어난 것이 대부분인데 왜 백신 검사 과정이 포함되어 있을까?

이유는 실시간 분석은 대부분 악성 파일 데이터베이스 기반으로 하는 경우가 많다.

그러므로 백신에서 지원하는 휴리스틱 탐지 등을 이용해 악성 파일을 검사해보고 실제 악성 파일인지 확인해 보는 것이다.

1-4. 2차 분석

1차 분석 결과를 토대로 2차 분석을 수행하는데, 사실 흐름도에서는 표시가 되어 있지 않지만 이 부분에서 초기 대응이 이루어져도 좋음
2차 분석의 주요 목적은 침해 시스템의 손실 및 복구, 추적
요즘은 큰 사건의 경우 조직적으로 움직이는 단체에 의해 공격 받는 경우가 대부분이어서 실체를 추적한다 하여도 실체 파악까지만 가능하고, 실제 검거 등의 과정은 많은 어려움을 겪음
하지만 계속해서 이런 과정들의 절차가 간소화되고 추적 기술도 나날이 발전하고 있어 빠른 시일내에 침해사고 원인을 제공한 이들의 검거가 이루어질 것임

1-4-1. 파일 시스템 분석

침해 시스템에서 가장 많은 피해는 저장소
저장소에서는 다연히 파일 시스템이 존재하기 때문에 파일 시스템 조사를 통해 손상되거나 삭제된 파일이 있는지 파악하고 이러한 파일들에 대해서는 조금의 가능성이라도 있다면 당연히 복구 과정을 수행해야 함
또 사용자가 생성한 여러 파일들 말고 시스템이 생성한 로그 등의 유용한 정보가 저장된 파일들을 파괴했을 수도 있음
이러한 파일들도 사후 분석에 사용을 하기 위해 복구해야 함
해당 과정은 파일 시스템의 전반적 이해가 필요

1-4-2. 타임라인 분석

침해 시스템에 언제, 어떻게 악성 파일이 침투하여 침해사고를 일으켰는지 밝혀내야 함
이때 각 침해사고 단계를 정리하고 분석하여 시간별로 나열 하여 시간 별 악성 파일의 행동을 추적하고 문서화 해야 함
특히 큰 사건의 경우 타임라인 분석은 굉장히 중요
타임라인 분석에 따라 침해사고의 책임을 질 사람이 바뀔 수도 있고, 앞으로의 침해사고 전개를 잘못된 방향으로 이끌 수도 있기 때문

1-4-3. 정적 분석

이제부터는 정식 대응을 시작해야 함
그러기 위해서는 악성 파일이 정확히 어떻게 악성 행위를 하는지 밝혀내야 함
취약점으로 침해 시스템에 침투하고 장악한 것인지, 또 자신의 사본을 생성해 숨겨놓았는지 등에 대한 행위는 정적 분석을 통해 알아내는 것이 가장 정확
동적 분석으로도 이런 것들을 알아낼 수는 있지만, 동적 분석의 경우 시스템에서 동작하는 프로세스의 모든 활동을 감지하고 그 가운데 악성 파일의 행동을 추출해내야 하기 때문에 분석하는 사람이 놓치는 부분이 있을 수도 있음

1-5. 대응

지금까지 분석한 결과를 토대로 침해 시스템에 알맞는 대응을 해야 함
대응에는 여러 종류가 있으며, 공통적으로 대응하는 부분은 네트워크 통신 차단, 악성 파일의 서비스 등록 삭제, 원본 파일 삭제 등이 있음
만약 대응하는 기간 도중 변종이 침해 시스템에 침투한 것을 발견한다면 다시 해당 변종의 침해 여부와 침해 정도 등을 파악하고 대응하기 위해 1차 분석부터 다시 수행해야 함
해시셋 적용부터 하지 않는 이유는 변종이라는 것은 기존 악성 파일이 변형된 것이기 때문에 해시 셋에 등록되어 있지 않기 때문

1-6. 종료

모든 대응이 끝나면 지금까지의 과정들은 문서화 되고, 보고 체계에 의해 보고 되어야 함
그 후에 악성코드 포렌식 수행을 종료

여기서 중요한 것은 과연 꼭 저러한 수행 과정을 통해 악성코드 포렌식을 수행해야 하는지이다.

아직까지 악성코드 포렌식의 수행 과정은 표준화 되지 않았고 악성코드 포렌식이라는 부분도 침해사고 대응과 많이 중복되는 부분이 있어 그 정립 자체가 불분명하다.

침해 시스템에 따라 [그림 1]과 같은 수행 과정을 수행할 수 있기도 하고 수행하지 못할 수도 있다.

그러므로 침해 시스템에 따라 수행 과정을 조금씩 변경하여 해당 침해 시스템에 적합한 수행 과정을 그릴 수 있는 능력을 길러야 한다.

그리고 꼭 "침해사고는 완전히 막을 수 없다"라고 생각하여아 하며, "침해사고를 완전히 막는다"라는 의미는 불현실성이 굉장히 많은 문장이며 사람의 보안 인식을 안일하게 만든다.

그러므로 매번 대응을 할 때마다 최선을 다하여 대응하고 추후에 있을 침해사고를 예측하고 예측 침해사고에 대한 대응 방안을 수립하는 자세를 가져야 한다.

(2) 악성코드 포렌식을 하기 위해 준비해야 할 것

2-1. 악성코드 포렌식을 수행하기 위한 환경

악성코드를 로컬에서 분석하는 분석가는 아마 없을 것이며, 요즘은 가상화 환경이 굉장히 구축이 잘 되어 있어 악성코드를 자신의 로컬 환경 내부의 가상화 환경에서 분석해도 무리가 전혀 따르지 않음
그러므로 자신의 분석 시스템에 적합한 가상화 환경을 구축하고 가상화 환경 내부에 여러 가지 도구들을 저장하여 분석 수행 시 빠르고 정확하게 분석할 수 있도록 평상시에 준비하고 있어야 함
간혹 가상화 환경을 탐지하여 실행되지 않는 악성코드가 있을 수도 있으니 가상화 환경에 대한 이해도 당연히 되어 있어야 함
그래야 악성코드가 탐지하는 가상화 환경의 특징을 변경해 악성코드이 가상화 환경 탐지를 우회할 수 있기 때문

2-2. 리버스 엔지니어링 (리버싱)

리버스 엔지니어링이란, 완전한 소프트웨어 또는 문서를 역으로 분석하여 원래의 소스코드 또는 데이터를 얻는 기술을 말함
우리말로는 흔히 역공학이라고 하며 해당 기술을 익히기 위해서는 굉장히 많은 시스템 지식이 필요
대표적으로 어셈블리어, 운영체제, 파일 구조(PE, ELF 등), 프로그래밍 언어 등이 있음
악성코드 정적 분석 과정에서 리버스 엔지니어링 기술이 사용된다고 보면 됨
흔히 말하는 디버깅과는 개념에서 약간의 차이가 존재하므로 정확하게 이 둘을 구분하고 구사하는 것이 중요

2-3. 흔적(아티팩트) 수집 / 분석 능력

원본 악성코드를 찾고 해당 악성코드가 어떻게 생성되었는지 파악하기 위해서는 악성코드가 운영체제가 생성한 흔적을 찾을 수 있어야 함
악성코드의 대부분은 Windows 이므로 Windows에서 생성되는 여러 흔적들에 대해 알고 있어야 함
수집할 수 있는 능력과 분석할 수 있는 능력도 준비되어 있어야 함

2-4. 여러 가지 도구 사용법

디지털 포렌식 분야 자체가 시스템의 굉장히 낮은 레벨의 데이터들을 다루기 때문에 사람이 수동적으로 접근할 수 있는 부분에는 한계가 존재
악성코드 포렌식도 이와 마찬가지로 사람이 수동적으로 접근하거나 모니터링 할 수 있는 부분이 굉장히 극소수
그러므로 악성코드를 분석할 때에는 여러 기능들을 지원하는 도구들을 미리 사용해보고 그 방법을 숙지하고 있어야 함
악성코드 분석 툴이란 카테고리는 정해진 것이 없으므로 자신이 필요한 기능을 지원하는 도구들을 찾아 그 사용법을 익혀야 함

2-5. 여러 가지 보안 지식

분석을 할 수 있지만 그에 맞는 대응 방안을 수립하지 못한다면 완전한 악성코드 포렌식을 수행할 수 없음
그러므로 보안 뿐만이 아닌 IT 분야 전체의 기본이 되는 시스템, 네트워크 등의 지식을 갖추고 있어야 함
보안 대책 수립 방법(서버 설정, 네트워크 트래픽 설정, 장비 설정 등) 등에 대한 지식도 갖추고 있어야 함

지금까지 나열한 여러 가지 요소들 말고도 전반적으로 보안 분야와 IT 분야에 대한 지식이 많아야 한다.

악성코드는 꼭 우리가 생각하는 시스템, 네트워크만 공격하는 것이 아니기 때문에 언제 어떤 시스템이 공격당하고 우리가 그 시스템을 대응조치 해주어야 할지 모르기 때문에 평상시에 차근차근 준비해야 한다.

(3) 결론

악성코드 포렌식은 침해대응 업무에 거의 속하는 분야이기 때문에 꼭 디지털 포렌식을 전문으로 하는 사람이 아니더라도 관제, 침해대응, 악성코드 분석 등의 업무를 하는 사람도 모두 할 수 있는 극히 드문 포렌식 분야 중 하나이다.

디지털 포렌식 분야는 일전에도 언급하였지만, 디지털 포렌식 분야만의 새로운 기술은 많지 않다.

그렇기 때문에 누구나 관심을 갖고 공부만 한다면 누구나 디지털 포렌식을 수행할 수 있지만, 누구낙 디지털 포렌식을 수행한다고 하여 디지털 포렌식 전문가라고 할 수는 없다.

디지털 포렌식 전문가와 일반 보안 전문가의 차이는 숙달과 훈련, 지식의 차이에 있다.

모든 분야가 그렇겠지만, 디지털 포렌식은 특히나 더 그렇다.

숙달되지 않은 자가 어중간하게 디지털 포렌식을 수행한다면 수행하지 않은 것만 못하다.

악성코드 포렌식도 이러한 이유에서 침해대응이 아닌 악성코드 포렌식으로 따로 분류되는 것이며, 숙달되지 않은 자가 침해사고 시스템을 분석하면 실수로 중요한 원인 프로그램이나 유출 흔적 등을 훼손 시킬 수 있다.

그러므로 악성코드 포렌식이 어떤 전문가나 누구든지 할 수 있다고 하여 가볍게 생각하지 말고 정확하고 깊게 공부해야 한다.

# Reference

http://www.yes24.com/Product/Goods/8511539

저작자표시

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

[Digital Forensic] 이미지 포렌식 (0)	2020.05.18
[Digital Forensic] 클라우드 보안과 디지털 포렌식 (0)	2020.05.17
[Digital Forensic] 디지털 포렌식 관련 법규 (0)	2020.05.11
[Digital Forensic] 디지털 포렌식 어카운팅 (0)	2020.05.11
[Digital Forensic] 디지털 포렌식 준비도 (0)	2020.05.11

[Digital Forensic] 이미지 포렌식

(1) 서론

디지털 포렌식은 많은 분야에 적용되어 왔지만, 모든 분야가 고루 관심을 받아 연구되어 온 것은 아님
대부분 컴퓨터, 모바일, 네트워크 중심의 디지털 포렌식이 주를 이루었는데, 그 외에도 관심을 가지고 연구해야 할 분야가 많음
예로 현재 주를 이루는 포렌식 분야를 제외한다면 우리가 관심 가져야 할 분야는 대표적으로 이미지, 음성 분야 등이 존재
요즘은 우리 일상 속에서 디지털 이미지를 손쉽게 볼 수 있고 접할 수 있음
이런 이미지들은 우리들에게 직/간접적으로 영향을 줄 때도 있으며, 영향을 주는 이미지에 대해서는 그 진위 판별 여부가 중요
예로 한 시대를 담고 있는 사진이 역사적으로 가치가 높아 진이 여부를 판별했더니 진짜 이전 시대의 사진이 맞는다고 판명이 남
이런 경우 해당 사진을 기준으로 역사가 재해석 됨

그리고 계속해서 후세에 교육 되어져 오는데 만약 후세에 어떤 인물이 조금 더 발전 된 이미지 분석 기술과 논리적 증거로 해당 사진이 위조 되었다고 주장하게 되면 어찌 될까?

아마 많은 역사적 혼란이 초래되지 않을까?

예를 극단적인 예로 들었지만, 사실 충분히 있을 수 있는 일이다.

해당 글은 이미지 분석 기술과 이미지에서 얻을 수 있는 증거 등에 대한 내용이다.

컴퓨터 이미지는 사실 수학적 개념이 들어가야 하지만, 이 글에서는 수학적 개념은 되도록 들어가지 않는다.

예제를 통해 기술이 어떤 형태를 띄고 있는지 파악해 볼 것이다.

(2) 이미지 관련 법

사실 디지털 이미지 등의 이미지를 수정하는 것은 법에 저촉되는 행위가 아님
하지만, 수정 된 이미지가 배포되고 그 이미지로 인해 누군가가 피해를 입는다면 이런 경우 법을 위반하는 경우가 됨
대표적인 예로 명예훼손과 초상권침해가 있음

2-1. 명예훼손

형법상으로는 명예훼손죄, 민법상으로는 불법 행위가 성립되는 죄목

형법상에서 명예는 "사람의 인격적 가치에 대한 사회적 평가로 정의되고 있다."

세부적으로 나누면 외부적 명예(사람의 신분, 성격, 혈통, 용모, 지식, 능력, 직업, 건강, 품성, 덕행, 명성 등)와 내부적 명예(그 사람이 가지는 진가)가 있다.

이미지 수정으로 인한 명예훼손죄는 내부적 명예보다는 외부적 명예를 훼손했다고 볼 수 있으며, 사실 형법상에서도 내부적 명예는 관계가 없다.

형법상 명예훼손죄가 성립되려면 공연히 또는 불특정 다수인이 인지할 수 있는 상황에서 사실 또는 허위의 사실을 적시 해야 한다.

그러므로 이미지를 수정했을 때 자신만 보기 위해 배포하지 않고 있다면 형법상 명예훼손죄가 성립되지 않는다.

하지만 이미지 수정 후 배포하여 불특정 다수인이 그 이미지를 보게 된다면 명예훼손죄가 성립된다.

명예훼손죄는 반의사불론죄이며, 진실한 사실을 적시한 경우와 허위의 사실을 적시한 경우 처벌이 달라진다.

2-2. 초상권침해

초상권은 자신의 초상이 허가 없이 촬영되거나 그려졌을 때 공표되지 않을 권리

초상권침해는 형법상 처벌 대상은 아니지만, 민법상으로 피해 보상 등의 문제를 야기시킬 수 있다.

디지털 기기 등이 발전되기 전에는 초상권은 그림이나 조각으로 제작 된 초상에만 적용되어 왔었는데 19세기 후반부터 사진 기술이 발전되고 디지털 기기 등의 발전으로 인해 적용 범위가 많이 확대 되고 중요성이 이전보다 더 많이 부각되었다.

만약 인물 사진의 얼굴을 다른 사람의 얼굴로 바꾸는 등의 이미지 합성 및 수정을 하여 배포할 경우 초상권침해 죄에 해당 된다.

(이때 이미지 내용에 따라 명예훼손 죄도 같이 해당될 수 있다.)

그러나 희극적 패러디, 만평 등에 이미지가 사용되었다면 새로운 저작물 창작으로 인정되어 법적 처벌을 피할 수 있다.

2-3. 그 외 기타

(3) 이미지 분석 방법 (접근법)

먼저 이미지를 분석하기 전, 분석가는 다음과 같은 여러 가지의 생각을 할 필요가 있다.

분석하려는 이미지는 과연 진짜일까? 가짜일까?
분석하려는 이미지가 진짜라면 언제, 누가, 왜, 어떻게, 무엇을, 어디서 생성 하였을까?
이미지가 가짜라면 어떤 방법으로(어느 부분이) 수정이 가해졌는가?
왜 이미지를 조작하였는가?

위와 같은 생각에 대한 해답을 찾기 위해 이미지를 분석할 때에는 대표적으로 다음과 같은 방법들을 이용해 이미지에 접근하고 분석을 시도한다.

3-1. 이미지 내용 속 관찰

가장 일반적이면서 쉬운 방법
이미지 내용 속에서 도움이 될 만한 것들을 찾는 것
가장 쉬운 방법이지만, 쉬운 만큼 정확성이나 진정성은 보장받지 못함
만약 조작된 이미지라면, 이미지 내용에 보이는 것 또한 조작 되었다는 가정이 성립되기 때문

예로 다음 이미지를 관찰해보자.

[그림 1]에서 분석가는 어떠한 정보를 얻을 수 있을까?

이미지 속 내용을 보면 '국립고궁박물관' 이라는 부분이 보이면서, 이 이미지는 '국립고궁박물관' 에서 생성되었을 가능성이 가장 높다.

(확정 짓는 것은 금물이며, 조작되었을 가능성이 있기 때문)

이 이미지가 생성되었던 날짜(기간)은 이미지 내용 속 광고를 기준으로 추측할 수 있다.

대략 2012년 12월 ~ 2013년 1월로 추정 가능하며, 날짜의 가정이 맞는다는 판단에 힘을 실어주는 사람의 복장 또한 분석가가 획득할 수 있는 정보로 볼 수 있다.

이렇게 이미지 속에서 이미지 별로 다르긴 하지만 여러 정보를 얻을 수 있다. (정확한 정보는 아님)

이미지 관찰 예시

EXIF 라는 포맷에 여러 가지 메타데이터가 저장되며, 이 메타데이터에는 시간 정보를 포함하여 GPS 정보 등이 포함
그러나 이런 메타데이터 정보는 쉽게 수정이 가능하여 분석가에게 신빙성을 제공하지 못함
결국 분석가는 자력으로 이미지에 나타내져 있는 장소를 찾고 이미지가 생성 된 시간을 판별해야 함
이때 제일 좋은 분석 도구는 분석가의 눈이며, 부수적으로 인터넷과 여러 알고리즘이 필요
요즘은 Geo-Tag가 많이 발전하여 각 지역마다 Tag가 붙어 있고 Tag를 이용해 손쉽게 장소 이미지 찾기가 가능
대표적으로 Google Street View, flickr, Photobucket 등이 있으며, 우리나라의 경우에는 다음 로드뷰가 있음

만약 자신이 아는 장소이거나 적어도 어느 국가인지 판단이 된다면 여러 스트리트 뷰를 통해 눈으로 해당 장소를 찾거나 그 범위를 좁힐 수 있다.

하지만 외국 등의 장소를 찾게 될 때는 앞서 소개 했던 여러 스트리트 뷰 또는 이미지 검색 엔진과 여러 알고리즘을 이용해 정확한 장소 이미지나 그 범위를 좁혀 볼 수 있다.

여러 알고리즘에는 Color Histograms, Texton Histograms, Line Features, Gist Descriptor+Color, Geometric Context 등 다양한 알고리즘이 존재한다.

이미지에 포함되어 있는 특정 물체 등을 보면 각 지역을 추측할 수 있는데 [그림 2]는 그 예시이다.

[그림 3]은 왼쪽 상단 위의 이미지 장소를 특정 알고리즘을 사용하여 찾은 이미지를 나열 해놓은 것이다.

오른쪽 상단의 지구 모양은 실제 육지에서의 장소를 나타낸 것이며, 아래에는 가장 흡사한 장소들을 나열 해둔 것이다.

3-2. 이미지 퀄리티 향상 기법

요즘은 카메라 화질이 좋아져서 이미지가 흐리거나, 깨지는 일이 자주 발생하지 않음
하지만, 간혹 카메라 화질이 좋지 않거나 여러 번 수정되어 이미지의 화질이 손상되어 분석하기 어려운 이미지들이 존재
이런 이미지들을 분석할 때에는 기본적으로 이미지의 화질을 향상시킨 후 분석을 수행해야 함

이미지 향상 기법에는 여러 가지 기법들이 있는데 하나씩 알아보도록 하자.

이미지 향상 기법의 대부분은 포토샵으로 가능한 기법들이지만, 기법들의 방법을 다루기에는 그 양이 굉장히 많다.

Motion Deblurring

해당 기술은 이미지를 생성하는 과정에서 사용자의 잘못된 기기 사용법이나 기기 자체의 문제로 인해 이미지가 흐릿하거나 흔들린 상태에서 생성된 이미지를 원래의 피사체와 동일하게끔 만드는 기술
이러한 기술은 Motion Deblurring이라 하며, 간단히 Deblurring 이라고도 함

[그림 4]는 현재 Blurring이 적용되어 있는 사진이다.

위 그림을 증거로 사용하기 위해 자동차의 번호판을 촬영하였거나, CCTV에서 용의자의 얼굴을 확인해야 하는데 이미지가 Blurring 되어 있으면, 굉장히 난감할 것이다.

이때 Motion Deblurring 기술을 사용하여 해당 이미지를 원본에 가깝게 복원할 수 있다.

[그림 5]가 [그림 4]보다는 좀 더 확연하게 우리가 확인하고자 하는 정보가 보인다.

좀 더 확실히 구분하기 위해 다음 예제를 살펴보자.

UnDistort

해당 기술은 렌즈로 인해 생기는 이미지의 왜곡 현상을 제거해주는 기술
왜곡으로 인해 식별이 불편했던 이미지 등에 적용하면 이미지 식별이 쉽거나 수월해 짐

다음 예제를 살펴보자.

[그림 7]에서 왼쪽이 렌즈 왜곡 현상이 있는 이미지이고, 오른쪽이 제거 된 이미지이다.

구분이 가지 않는다면, 체크판의 각 변들을 보면 조금은 이해가 갈 것이다.

왼쪽 그림을 보면 체크판의 왼쪽 변이 휘어져 있는 것을 볼 수 있다.

Periodic Noise Removal

해당 기술은 정규 패턴으로 이루어져 있는 노이즈를 이미지에서 지워주는 기술
대표적인 예로 우리가 쉽게 접하는 지폐에서 지문을 채취할 때 사용할 수 있음

다음 예제 이미지를 살펴보자.

세로로 이루어져 있는 물결 무늬가 보이며, 이 무늬는 우리 지폐에서 볼 수 있는 흔한 워터 마킹 중 하나이다.

하지만, 이 물결 무늬로 인해 지문이 잘 보이지 않는다.

이제 [그림 8]에 해당 기술을 적용해 보자.

[그림 9]에 빨간 박스로 강조해 놓은 영역을 보면 지문을 볼 수 있다.

약간 흐릿하지만 이 정도의 선명도로 지문 인식을 하는 데에는 문제 없다.

Rational Sharpening

이 기술은 각 컬러가 비슷한 부분을 동시에 강조해주는 부분
이 기술에서 필요한 값으로는 Strength, Attenuation, Iterations 가 있음
각 값은 이미지의 픽셀 값을 조정해 주는데 사용

그림 예제를 살펴보자.

[그림 10]에는 해당 기술을 적당히(세 가지 값을 이용) 적용하면, 다음과 같이 각 이미지의 요소들(사람, 가로등, 도로의 물고임 등)이 픽셀 별로 구분이 되는 것을 볼 수 있다.

만약 이 세 가지 값이 불균형을 이루게 되면 다음과 같이 이미지를 전혀 알아볼 수 없도록 픽셀들이 폭주하게 된다.

Contrast / Brightness

해당 기술은 이미지의 명암을 조절하는 기술
우리도 일상적으로 이미지를 꾸미거나 할 때 사용하는 기술
Contrast는 컬러의 옅음과 짙음을 조절하는 것
Brightness는 이미지 자체의 밝기를 조절하는 기술

그림 예제를 살펴보자.

[그림 13]에는 하늘은 밝지만, 이미 시간이 지나 밤으로 가고 있는 어슴푸르한 주변 빛 때문에 사람의 얼굴이 잘 보이지 않는다.

이때 해당 기술을 사용하면 사람의 얼굴을 확인할 수 있다.

[그림 14]를 보면 사람의 얼굴이 선명하게 보이는 것을 확인할 수 있다.

Line Shift

일부 비트가 옆으로 이동되어 정상적인 이미지가 아닐 때 정상적인 이미지로 복원하기 위해 사용하는 기술

설명 보다는 예제를 보는 것이 이해가 더 빠르니 예제를 살펴보자.

[그림 15]는 CCTV의 일부 화면이다.

가로로 비트 줄이 보이는데, 해당 비트 줄들이 주변 비트들과 울리지 않고 옆으로 이동되어 이미지 내용이 깨져 보이는 것을 볼 수 있다.

이런 이미지에 해당 기술을 사용하면 원본에 가까운 이미지를 얻을 수 있다.

3-3. 동영상 퀄리티 향상 기법

동영상 분석의 기본은 프레임 별 분석

프레임 별로 동영상을 나누어 분석을 수행하며, 이 프레임의 화질을 어떻게 향상 시켜 분석에 도움이 되게 하는지 알아보자.

Frame Averaging

동영상 프레임은 굉장히 짧은 시간의 장면을 나눈 단위로 생각할 수 있음
이런 프레임의 값이 각 프레임 별로 모두 다를 경우 사람이 동영상을 인지하는데 굉장히 어려움을 겪을 수 있음

이런 이유로 동영상의 프레임 평균을 구하여 모든 프레임이 적용시키면, 사람이 지속적으로 안정적인 프레임을 주시할 수 있기 때문에 화질이 좋지 않는 동영상에는 이 기술을 사용하면 어느 정도의 화질 향상 효과를 볼 수 있다.

[그림 17]은 해당 기술을 적용하기 전의 모습이다.

이미지의 노란색 박스에 무엇인가 적혀져 있는 듯 하지만, 그 내용을 정확히 파악하기에는 아직 어려운 상황이다.

[그림 17]에 해당 기술을 적용하면 어떻게 화질이 향상되는지 살펴보도록 하자.

[그림 18]을 보면, 노란색 박스에 어떤 글씨가 [그림 17]보다 좀 더 잘 보이는 것을 느낄 수 있다.

정확히는 아니지만, "525257", 또는 "526257" 로 보인다.

해당 이미지를 조금 더 정확히 파악하기 위해서는 다음 기술을 적용햐면 된다.

Histogram Equalization

Histogram은 명암의 분포도를 파악하는 것
간혹 어떤 동영상이나 이미지의 경우 픽셀이 집중 포화되어 있는 영역이 존재
이럴 때 우리가 파악하려는 물체와 그 주변 물체들과 겹치거나 비슷한 색상이어서 구분이 잘 되지 않음

이럴 때 해당 기술을 사용하는데 해당 기술은 픽셀이 집중되어 있는 영역의 픽셀을 다시 골고루 재배치하여 영상의 화질을 향상시킨다.

이제 [그림 18]에 해당 기술을 적용 시켜 보자.

[그림 19]가 [그림 18]보다 조금 더 선명하게 보이면서, 해당 기술을 적용함으로써 노란 박스에 "526257" 이란 숫자가 적혀져 있다는 것을 정확하게 확인할 수 있다.

(4) 기타 이미지 분석 기술

위 절에서는 이미지, 동영상에 대한 화질 향상 기술에 대해서 알아보았다.

이미지(동영상)의 화질(퀄리티)를 향상 시킨다고 하여 합성 여부까지 판단할 수 있는 것은 아니다.

이 부분에서는 합성에 대한 이미지(동영상)에 대해 알아보고자 한다.

여기서 소개하는 기술들은 이미지와 동영상 모두에 해당하므로 구분 없이 생각하면 된다.

4-1. Vanishing Point

해당 기술은 4개의 포인트를 정하고, 정해진 포인트를 직선으로 이어 겹치는 중앙 원점을 찾음
그 원점을 기준으로 이미지를 이동시켜 측면의 이미지가 정면으로 오게끔 하여 사용자가 이미지를 정면에서 볼 수 있도록 해주는 기술

그림 예제를 살펴보자.

[그림 20]을 보면 자동차의 번호판이 측면에서 찍혀 정확히 번호판의 내용이 보이지 않는다.

하지만 번호판의 각 꼭지점을 직선으로 연결하면 번호판 중간에 중앙 원점이 만들어지는데 해당 원점을 기준으로 번호판을 이동시키면 된다.

번호판의 측면이 정면으로 바뀌면서 번호판의 내용을 확인할 수 있는 것을 [그림 21]에서 볼 수 있다.

이렇듯 해당 기술은 측면의 이미지를 정면의 이미지로 변경하여 이미지의 내용을 정확히 파악할 수 있도록 도와준다.

4-2. Measure

해당 기술은 이미지 내에 있는 물체의 길이를 재는 기술
이 기술의 결과는 수치로 그 수치의 오류율은 크지 않다.
따라서 이 기술은 용의자의 인상착의를 파악하는데 꽤 유용하게 작용

만약 다음과 같이 사람이 찍힌 이미지가 있다고 가정해보자.

[그림 22]만 보고 사람의 키를 가늠할 수 있을까?

발판 위에 올라가 있어 그 키를 가늠하기가 매우 어렵다.

[그림 22]에 해당 기술을 사용하여 조금 더 정확한 사람의 키를 알아보자.

기술을 적용시켜본 결과, 사람의 키는 178cm 인 것으로 파악이 되었다.

또 위 예제에서 사용된 기술은 Measure 3D 기술이고 Measure 1D, 2D 기술도 있다.

아래 예제에서 그 차이를 확인할 수 있다.

4-3. 이미지 파일 메타데이터

요즘 디지털 기기로 인해 생성되는 이미지 파일에는 EXIF라는 메타데이터 포맷이 존재
EXIF 포맷에는 사진의 화질과 관련된 기본 정보부터 시작하여 이미지 파일을 생성한 디지털 기기의 명칭(모델명), 생성 날짜, 기기의 렌즈 종류, GPS 정보 등의 많은 정보들이 저장되어 있음
EXIF 포맷은 간단한 툴로 확인이 가능하며, 확인할 때 사용하는 도구들은 셀 수 없이 많으므로 어떤 도구를 사용하는가는 전적으로 사용자 취향

다음 그림은 GUI 형태의 EXIFtool로 확인한 어떤 이미지 파일의 EXIF 메타데이터 정보이다.

한 눈에 봐도 굉장히 많은 정보가 보이지만, EXIF 메타데이터의 가장 큰 단점이 있다.

다른 곳에 존재하는 메타데이터처럼 수정이 쉽다는 점과 수정된 메타데이터는 복구가 불가능하다는 점이다.

메타데이터가 수정되었다는 것을 증명할 방법으로는, 확실한 방법은 아니지만 일반적인 방법으로 이미지 관찰 방법과 메타데이터 정보를 상호 분석하는 방법이 있다.

EXIF에서 가장 많이 변경되는 메타데이터가 GPS 정보와 시간 정보이다.

GPS 정보의 경우, 그 장소를 미리 인터뎃 등으로 검색하여 본 후 GPS 장소와 이미지에 찍힌 장소가 동일한지 비교하는 방법이 있다.

만약 다르다면 GPS 정보는 변경되었다고 할 수 있다.

그럼 이미지 분석에 있어 EXIF 메타데이터 정보는 쓸모 없는 정보일까? 라는 의구심이 들 수도 있다.

왜냐하면 수정이 쉽고 복구가 불가능하기 때문에 누군가 이미지의 픽셀이나 메타데이터 수정을 한번이라도 했다면 해당 이미지의 신뢰성은 보장되지 못하기 때문이다.

이제 메타데이터를 이용하여 누군가 이미지를 조작하였는지 판단할 수 있는 방법을 알아보도록 하자.

1) 수정 여부 판별 방법

처음 사진 파일을 접했을 때 그 누구도 어떠한 검증 방법을 거치지 않는 이상 그 사진 파일의 데이터가 수정 되지 않았다거나 수정되었다고는 확신할 수 없음
하지만 해당 방법을 통해 이미지 파일이 수정되었다는 것을 의심할 수 있고 그 의심을 증명할 수 있음

EXIF에는 3개의 타임스탬프 값이 저장된다.

DataTime(Tag ID : 132) : 디지털 카메라 디바이스 내에서의 사진 파일 생성 시각을 나타냄
DateTimeOriginal(Tag ID : 9003) : 사진을 찍힌 대상이 촬영 된 시각을 나타냄
DateTimeDigitized(Tag ID : 9004) : 사진을 찍힌 대상이 디지털 이미지로 처리 된 시각을 나타냄

위 3개 필드의 타임스탬프 값은 기본적으로 동일한 시간 정보를 갖게 된다.

아래는 샘플 사진을 EXIF Viewer로 열어 각 정보를 확인해 본 모습이다.

빨간 박스로 하이라이트 되어 있는 부분들은 위에서 언급한 타임스탬프 필드들이며, 동일한 시간 값을 볼 수 있다.

EXIF 파일의 사진 정보를 수정하기 위해서는 첫 번째 단계로 자신의 PC나 또 어떠한 PC로 사진 파일을 이동하는 행위이다.

이 행위에서 이 시간 값들은 부동적이다.

첫 번째 단계를 진행하게 되면 NTFS에서는 사진 파일에 대한 MFT 엔트리를 생성하고 MFT 엔트리에 시간 정보를 저장하게 된다.

이때 수정 날짜만 EXIF 내에 저장되어 있는 시간 값을 따라 저장되고 나머지 시간 정보인 생성 시간과 접근 시간은 파일이 복사되거나 이동하는 시간을 참고해 저장되게 된다.

즉, EXIF 데이터가 들어있는 사진 파일을 컴퓨터로 이동해 사진 파일을 열어 보기만 하거나 수정을 하지 않는다면 사진 파일의 시간 정보는 수정 시간이 생성 시간과 접근 시간보다 무조건 몇 분이나 몇 시간 전이어야 하고, 생성 시간과 접근 시간이 동일하여야 한다.

현재 상태에서 사진 파일의 데이터를 조작하면 수정 시간만 업데이트 되게 된다.

다음은 사진 파일에 0x00이란 데이터를 추가 했을 때의 시간 정보이다.

(크기를 보면 918,977 바이트에서 918,978 바이트로 1바이트 추가된 것을 확인할 수 있음)

사진 파일 데이터가 조작 되었을 때에는 조작을 수행한 시간이 저장되는데 일단 이 정보를 EXIF에 저장된 정보와 비교를 하여 동일하지 않다면 해당 사진 파일이 수정되었다고 판단할 수 있다.

속성에서 보이는 시간 값은 MFT 메타데이터이기 때문에 업데이트가 되지만, EXIF의 시간 정보는 파일 구조에 저장되어 있는 값이기 때문에 인위적으로 조작하지 않는 이상 변하지 않는다.

그런데 EXIF 시간 값 자체가 수정 되었다면 어떻게 확인을 할 수 있을까? 사진을 수정한 사용자가 EXIF 구조를 알고 있어 모두 똑같은 임의의 시간으로 변경하였다면 매우 까다로운 조건이 걸리기 때문에 쉽사리 시간 값을 조작하지 못한다.

EXIF의 시간 값을 조작하면 계속해서 파일 시스템의 해당 파일의 메타데이터에 포함되어 있는 수정 시간이 업데이트 된다.

여기서 더 한번 사용자가 머리를 써 파일 시스템의 수정 시간을 예측해 EXIF 포맷의 시간 값을 파일 시스템의 수정 시간과 동일하게 수정한다면 이때는 MFT 엔트리에 FNA(File Name Attribute) 시간 값을 참고하면 된다.

그러나 파일 시스템의 수정 시간을 예측해 수정하는 방법에는 한 가지 문제점이 존재하며, 바로 자신의 알리바이이다.

자신의 알리바이 시간까지 고려해 수정을 해야만 파일의 수정하지 않았다는 것을 정확히 증명할 수 있다.

cron과 같은 예약 프로그램을 쓰면 되지 않을까? 라고 생각할 수 있지만, 프로그램을 사용하면 그 흔적 또한 남기 때문에 적절한 방법이 아니다.

만약 시간 값을 수정한 사용자는 어떠한 시간에 누구와 같이 있었거나 컴퓨터를 만지지 않았음에도 불구하고 파일의 시간이 그 때의 시간을 가리키고 있다면 이는 수정 된 시간으로 볼 수 있다.

즉 사용자는 시간을 수정하기 위해서는 여러 가지 제한 사항을 고려해야만 하기 때문에 섣불리 시간을 조작해서도 안되고 조작하더라도 여러 가지 난관에 부딪혀 결국 시간 조작에 실패하고 말 것이다.

정리를 해보면 사진 파일의 데이터가 수정 되지 않은 파일들의 시간적 특징은 다음과 같다.

(디지털 카메라 디바이스에서 NTFS 파일 시스템으로 파일을 복사하거나 이동했다고 가정 했을 때)

EXIF 3개 필드 시간 값이 동일
파일 시스템의 파일 생성 시간과 접근 시간이 동일하며, 수정 시간은 EXIF의 3개 필드 시간 값과 동일
파일 시스템의 파일 생성 시간과 접근 시간이 수정 시간보다 느림

위 3개의 조건이 공개된 지금 사진 파일 데이터를 수정하던 사용자는 위 조건에 맞는 시간 값을 생각해 파일 시스템과 EXIF의 시간 값도 수정하려고 할지 모른다.

하지만, 시간 값 수정에는 많은 조건이 따르기 때문에 자신의 상황을 생각해 수정하려 할 때 많은 생각을 하게 되며 섣불리 시간 값을 수정하지 못할 것이다.

또 수정한다고 하더라도 파일 시스템 메타데이터 시간 값이 존재하기 때문에 그 시간 값을 또 생각해야 하며 생각한 파일 시스템 메타데이터 시간 값을 수정하기 위해서는 파일 시스템 레벨의 도구를 사용해 수정해야만 한다.

하지만 이 또한 프리패치 등의 흔적으로 발견되며, 프리패치를 지운다고 하여도 복구가 가능하고 하기 때문에 여러 가지 면들을 생각한다면 결국 수정을 포기하게 되고 만다.

이러한 방법으로 사진 조작 여부를 판별하고 해당 사진의 분석을 진행할 것인지, 아니면 조작 되었으므로 분석을 진행하지 않거나 해당 파일의 조작 여부 자체를 증거로 제출한 것인지 판단할 수 있다.

4-4. Image Search

해당 내용은 기술보다는 이미지 분석을 수행하기 전에 간단한 방법으로 이미지 분석의 절차를 간소화하는 방법
이미지 분석에 있어 정말 정밀하게 조작된 이미지는 분석 결과가 정확하지 않을 수 있음
이런 경우 법원에 제출하여 증거로 채택 받는 것이 힘들어지는데, 혹시나 모를 이미지의 다른 조작 이미지를 찾게 된다면 조작 결과의 근거로 찾은 이미지를 제출할 수 있음 (미국의 경우이며, 우리나라는 아직 사례 없음)
이미 검색 기술이 발전하여 이미지만을 가지고 검색을 할 수 있게 되었으며, 대표적으로 Tineye와 Google 검색 엔진이 존재

그림 예시를 통해 한 번 살펴보자.

[그림 30]을 보면 하나의 이미지가 조작되고 합성되고 인용되는 것을 볼 수 있다.

만약 이런 결과물들을 검색 엔진을 통해 얻을 수만 있다면 정말 정밀하게 조작된 이미지라도 부정확한 분석 결과에 신빙성을 더해 줄 수 있게 된다.

4-5. Camera 기종에 따른 이미지 분석

요즘은 디지털 카메라가 보편화 되어 있다는 것을 누구나 알고 있지만, 분석가는 이런 시대적 현상이 달갑지만은 않음
이유는 디지털 카메라의 제작 규격이 표준화 되어 있지 않기 때문에 그 모양이 모두 다르기 때문
모양으로 인해 플래시 위치가 제각각 이어서 피사체의 그림자 위치가 모두 달라짐
그러므로 분석가는 각 렌즈 위치 별 그림자 위치를 모두 파악하고 있어야 이미지 분석에 있어 조금 더 정확하고 신빙성 있는 결과를 도출할 수 있음

조금 더 직관적인 예를 들어보자면, 다음 그림은 동일한 위치에서 동일한 피사체를 촬영한다는 가정하에 제작된 3D 이미지이다.

[그림 32]를 보면 동일한 위치에서 촬영을 했음에도 불구하고 피사체의 그림자 위치가 다른 것을 확인할 수 있다.

왼쪽의 피사체의 그림자는 오른쪽으로 치우쳐져 있고 오른쪽 피사체의 그림자는 왼쪽으로 치우져져 있다.

다음 이미지를 본다면 왜 위치가 이렇게 달라지는지 한 눈에 파악할 수 있다.

왼쪽 피사체 그림자의 경우 왼쪽에 플래시가 위치한 디지털 카메라로 촬영 했다고 가정하에 이미지를 생성한 것이고, 오른쪽 피사체 그림자의 경우 오른쪽에 플래시가 위치한 디지털 카메라로 촬영 했다고 가정하고 이미지를 생성한 것을 알 수 있다.

빛의 시작 위치가 달라 그 빛을 받고 만들어지는 그림자의 위치가 달라지게 되는 것이다.

이런 이유로 카메라의 플래시 위치는 상당히 중요하다.

플래시 위치는 결국 빛의 시작 위치라고 말할 수 있기 때문이다.

4-6. Shadow Analysis

이미지 합성 여부를 가리는 가장 대표적인 방법으로 그림자 분석(Shadow Analysis) 기술이 있음
그림자는 아주 자연스러운 자연 현상으로, 모든 피사체가 빛을 만났을 때 피사체의 크기와 비슷하게 그늘이 지는 영역 또는 현상
대부분의 이미지 합성을 시도하는 자들은 그림자를 간과하게 됨
조금 신경을 쓴다고 하여 그림자를 삽입한다 하더라도 정확하게 자연 현상의 그림자를 표방하여 합성을 시도하기란 여간 쉬운 일이 아님

그림 예제를 통해 살펴보도록 하자.

얼핏 보면 동일한 두 예제는 자세히 보면 탁자에 올려져 있는 초록색 병의 그림자 방향이 다른 것을 알 수 있다.

여기서 두 예제에 대해서 합성 또는 조작 진위 여부를 생각한다면 우리는 총 네 가지의 경우의 수를 생각할 수 있다.

[그림 34]가 진짜이거나 [그림 35]가 진짜일 수도 있고, 둘 중 하나가 진짜일 수도 있다.

또, 두 개가 모두 가짜일 수도 있다.

하지만, 두 개 모두 진짜일 수는 없으며, 그림자는 하나의 자연 현상이므로 동일한 환경에서 두 가지의 그림자가 나타날 수는 없기 때문이다.

여기서 그림자의 특성을 생각해보면, 그림자는 빛에 의해 생겨나는 것으로 빛은 한 곳에서 분산되어 피사체에 비춰진다.

그러므로 여러 조명이 있지 않고 하나의 조명이 있거나 야외에서 찍힌 피사체의 이미지라고 생각한다면, 이미지에 표현되어 있는 그림자는 모두 한 곳에서 비추어지는 빛에 의해 생겨난 그림자라고 생각할 수 있다.

이런 논리를 통해 두 이미지의 빛의 발원지를 추적해 선으로 연결 해보면 다음과 같은 차이점을 발견할 수 있다.

선으로 각 그림자를 빛의 발원지로부터 이어보면 [그림 36, 37]처럼 확연히 차이가 나는 것을 볼 수 있다.

[그림 36]의 경우 정확하게 식탁 위 조명에서 빛이 발산되어 그림자를 생성한 것을 확인할 수 있는 반면, [그림 37]의 경우 초록색 병의 그림자가 초록색 병과 이었을 경우 빛의 발원지인 조명일 빗겨 간다는 것을 볼 수 있다.

즉, 초록색 병이 다른 이미지에서 잘려 현재 이미지와 합성되었다는 것을 입증하는 것이다.

여기서는 예제를 만들어 알아보았지만, 실제로 해당 기법을 통해 분석을 할 수 있는 합성 논란 이미지나 동영상은 많이 존재한다.

한 가지 실제 예를 살펴보도록 하자.

인터넷 포털 사이트에서 핫이슈로 네티즌들 사이에서 화제가 되었던 유튜브 동영상으로 독수리가 공원에서 놀고 있는 아기를 낚아 채 납치하는 동영상이다.

처음 공개가 되었을 때에는 동영상을 보고 네티즌들은 놀랍다는 반응이었지만, 시간이 지나자 일부 네티즌들은 합성을 제기하였다.

하지만 그 누구도 뚜렷한 합성의 논리적 근거를 밝히지는 못하였는데 해당 동영상은 간단한 분석으로 합성 여부를 판단할 수 있는 사례이다.

독수리가 아기를 낚아 챌 때 지면에 생기는 그림자를 포착하여 분석하면 위 [그림 39]와 같은 결과가 나오게 된다.

합성의 여지가 있는 독수리와 일반 사람들의 그림자를 대상으로 빛의 발원지를 추적하여 보면 독수리의 그림자와 사람들의 그림자가 서로 다른 빛을 받아 생겼다는 것을 확인할 수 있다.

어떤 피사체가 원본 피사체이고 원본 피사체에 합성된 피사체가 어떤 것인지는 정확히 판별할 수 없지만, 적어도 의심이 가는 일반 사람들 피사체 또는 독수리의 피사체는 같은 공간에서 찍히지 않았다는 것은 증명할 수 있는 셈이다.

(5) 이미지 분석 도구

아직까지 디지털 이미지 포렌식을 전문적으로 지원하는 도구는 그리 많지 않음
대표적으로 AmpedSoftware사에서 개발한 Amped Five가 디지털 이미지 포렌식 도구라고 할 수 있음
또, 전문적인 도구는 아니지만, Adobe사에서 개발한 PhotoShop이 있음

PhotoShop은 전문적인 디지털 포렌식 도구는 아니지만, 현재까지 연구되었던 대부분의 기술들이 집약되어 있는 도구이기 때문에 디지털 이미지 포렌식을 수행하는 데 큰 어려움이 없다.

(6) 결론

지금까지 디지털 이미지 포렌식에 대한 여러 기술들을 알아 보았다.

사실 위 기술들은 디지털 이미지 포렌식의 기술들이기 보다는 이미지 프로세싱에 포함되는 기술들이 대부분이다.

이미지 프로세싱에 대한 기술 연구는 외국뿐만 아니라 우리나라에서도 많이 연구되고 있는 한 분야로 우리나라의 기술 수준 또한 외국 기술 수준에 비해 전혀 뒤쳐지지 않는다.

하지만, 이런 기술 수준을 디지털 포렌식에 접목하는 시도는 아직까지 우리나라에서 찾아보기가 힘들다.

현재로서는 미국에서 이미지 프로세싱을 디지털 포렌식에 결합하여 연구하고 있는 것이 전부이며, 해당 연구원들은 이런 연구를 포토 포렌식(Photo Forensic)이라고 부르고 있기도 하다.

앞으로 이런 연구가 우리나라에서도 활발히 진행되어 우리나라의 독자적인 디지털 이미지 포렌식 기술과 도구가 나와야 하겠다.

# Reference

http://www.yes24.com/Product/Goods/8511539

저작자표시

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

[Digital Forensic] 악성코드 포렌식 (1)	2020.05.20
[Digital Forensic] 클라우드 보안과 디지털 포렌식 (0)	2020.05.17
[Digital Forensic] 디지털 포렌식 관련 법규 (0)	2020.05.11
[Digital Forensic] 디지털 포렌식 어카운팅 (0)	2020.05.11
[Digital Forensic] 디지털 포렌식 준비도 (0)	2020.05.11

Yum_Yum

전체 글

[Tool] Volatility

[Tool] Volatility

(1) Volatility란?

(2) 메모리 덤프

2-1. 물리 메모리 덤프

2-2. 소프트웨어 메모리 덤프

2-3. 크래시 덤프

(3) 설치 & 사용법

3-1. https://www.volatilityfoundation.org/ 접속

3-2. 파일 압축 풀기

3-3. 덤프 파일 폴더 안에 넣기

3-4. cmd 창(명령 프롬프트) 켜기

3-5. 덤프 파일 시스템 정보 확인

추가 내용 설명

3-5-1. Image 정보 확인

3-5-2. Image 정보 확인

(4) 플러그인

4-1. pslist

4-2. psscan

4-3. pstree

4-4. psxview

4-5. dlllist

4-6. ldrmodules

4-7. handles

4-8. memdump

4-9. vadwalk

4-10. vadtree

4-11. vadinfo

4-12. vaddump

4-13. modules

4-14. modscan

4-15. moddump

4-16. ssdt

4-17. driverscan

4-18. filescan

4-19. mutantscan

4-20. thrdscan

4-21. threads

4-22. netscan

4-23. hivescan

4-24. hivelist

4-25. userassist

4-26. malfind

4-27. svcscan

4-28. callbacks

4-29. driverirp

4-30. devicetree

4-31. timers

4-32. memmap

4-33. getsids

4-34. verinfo

4-35. procdump

4-36. symlinkscan

4-37. connscan

4-38. printkey

4-39. consoles

(5) 추가 플러그인

5-1. crashinfo

5-2. apihooks

5-3. impscan

5-4. volshell

(6) DKOM을 이용한 프로세스 은닉 기법

(7) Volatility를 사용해 메모리를 분석할 때, 효율적인 분석을 위한 절차

# Reference

'Tool' 카테고리의 다른 글

[OS] 윈도우 메모리(Windows Memory)

[OS] 윈도우 메모리( Windows Memory)

(1) 윈도우 메모리

1-1. 메모리 내 정보

1-2-1. 메모리 분석 이유 1

1-2-2. 메모리 분석 이유 2

(2) 메모리 구조

2-1. 32bit CPU

2-2. 가상 메모리

CODE 영역

DATA 영역

BSS 영역

Heap 영역