Ransomware_Micro.pdf

* 참고 : PDF를 기준으로 만든 내용이기 때문에, 포스팅보다는 PDF 파일을 보는 것이 더 좋습니다.

1. 요약

대상 악성코드에 대해 이후에 분석한 내용을 정리한 페이지다. 해당 악성코드는 랜섬웨어로 파일들을 암호화 하여 금액을 요구한다. 암호화 방식은 RSA 방식을 사용하며, 암호화 대상 파일은 크기가 32 Bytes에서 327,155,712 Bytes 사이에 있을 경우에 암호화 된다. 만약 파일의 크기가 이에 해당하지 않을 경우 진행되지 않는다.

그림 1. Malware Summary

   최초 26.exe를 실행할 경우 %AppData%\Roaming에 새로운 이름으로 같은 파일을 생성 한 뒤 이를 실행한다. 이렇게 실행된 새로운 프로세스는 vssadmin 명령을 통해 볼륨 쉐도우를 제거하는 작업을 수행하는 스레드를 생성한다. 또한 CMD나 작업관리자, 또는 Process Explorer와 같은 프로세스의 실행 및 동작을 방해하도록 이들을 계속 종료한다.

  암호화가 진행되는 동안 해당 프로세스는 자기 자신을 레지스트리에 지속성을 위하여 등록한다. 하지만 여기서 말하는 지속성이란, 암호화가 완료되지 않은 채로 PC가 종료되었을 경우 다시 PC가 부팅되었을 때 암호화를 마저 진행하도록 하기 위함이다. 랜섬웨어는 모든 암호화가 완료되었을 경우, 자기 자신을 삭제한 뒤 프로세스 또한 종료한다.

2. 개요

분석하고자 하는 대상 악성코드는 랜섬웨어(Ransomware)로 파일을 암호화하여 이에 대하여 금전적인 요구를 강요하는 것이다. 일반적으로 랜섬웨어의 경우 복잡한 암호화 알고리즘을 사용하는 것이 대부분이기 때문에, 실질적으로 복구는 힘들다. 따라서 암호화 키를 찾는 것이 아닌, 어떻게 랜섬웨어가 동작하는지 확인하기 위하여 분석을 진행할 것이다.

  악성코드를 분석하는데 있어 크게 2 단계로 나누어 살펴볼 것이다. 동적 분석과 정적 분석으로, 동적 분석은 악성코드를 직접 실행시키므로 나타난 결과들에 대하여 살펴볼 것이다. 반대로 정적 분석의 경우 악성코드를 디버거를 통해 실행했을 때의 결과에 대하여 살펴볼 것이다. 필요하다면 메모리 분석 기법까지 사용할 것이다. 각 분석에 사용된 도구들은 다음의 표와 같다.

표 1. 사용 도구

  위의 도구들을 이용하여 전체적인 분석을 진행하였다. 동적 분석을 먼저 진행하여 어떠한 동작들이 이루어지는지 확인한 뒤, 정적 분석을 통해 이에 대하여 좀 더 구체적으로 알아볼 것이다.

3. 동적 분석

동적 분석은 악성코드를 실행하므로 나타나는 증상에 대하여 정리한 페이지다. 이러한 동적 분석을 통해, 나타나는 결과들을 명확하게 확인할 수 있다는 장점이 있다. 다만, 실행할 때 가상 환경에서 진행하여야 한다는 점과 놓치는 측면이 있을 수 있다는 단점이 존재한다. 분석 환경은 Windows 7 x64이며 구분을 위하여 최초 실행하는 악성코드의 이름은 26.exe로 변경 후 분석을 진행하였다.

3.1 Process 분석

해당 악성코드를 실행하면 새로운 프로세스를 생성한다. 여기서 해당 프로세스의 이름은 무작위로 정해진다. 분석을 하면서 생성된 프로세스의 이름이 ltwpiwd.exe였다. 해당 파일의 위치를 찾아 해시 값을 비교해본 결과, 최초 26.exe와 같은 해시 값을 가지고 있었다. 따라서 26.exe는 자신을 감추기 위해, 본래의 26.exe를 제거하고 새로운 파일을 %AppData%\Roaming\에 생성한 뒤 이를 실행한다.

그림 2. Process Hacker

  암호화 동작을 진행하며 볼륨 섀도우 카피와 관련된 프로그램들이 실행되는 것을 확인할 수가 있다. 이는 VSS를 통해 데이터 복구하는 것을 방지하기 위하여 존재하고 있는 VSS를 제거하는 동작(vssadmin delete shadows /all / Quiet)을 한다. 또한 암호화가 진행되는 동안 HELP_RECOVER_instructions+pgv(이하 Help파일) 라는 암호화를 풀기 위한 방법을 나타내는 파일이 Txt, Html, Png의 형태로 각 폴더에 생성된다.

  여기서 해당 프로세스가 진행되는 동안 cmd.exe, ProcessExp 등을 비롯한 몇 가지 프로그램이 계속 종료되는 현상이 나타났다. 이는 랜섬웨어 파일이 분석 또는 감염자가 다른 행동을 하지 못하도록 하기 위함으로 보인다. 암호화가 완료된 후, HELP파일들이 ltpiwd.exe의 하위 프로세스로 txt, html, png로생성된다. 그 후 해당 프로세스는 종료한다. Help 파일 중 html은 아래의 그림을 보자.

그림 3. HELP_RECOVER_instructions+pgv.html

  해당 내용을 확인해보면, 전형적인 랜섬웨어가 가지는 특성을 보인다. RSA 암호화 방식을 사용하고 있으므로 해제가 어려울 것이다라는 것을 경고하며, 퍼스널 홈 페이지를 제공한다. 각 페이지에 접속을 시도해본 결과 현재 접근할 수 없는 페이지로 나타난다.

3.2 MFT 분석

MFT에는 파일에 대한 메타정보들이 저장되어 있다. 여기서 $UsnJrnl에는 저널 로그가 기록되어있으며 $LogFile에 비하여 상대적으로 기록할 수 있는 로그의 크기가 크다. 따라서 $LogFile을 통해 트랜젝션 로그를 살펴볼 수 있으며, $UsnJrnl을 통해서는 많은 양의 저널 로그를 살펴볼 수 있다.

  일반적으로 랜섬웨어의 경우 많은 이벤트들이 발생하기 때문에, $LogFile의 경우 많은 부분이 덮어씌워진다. 따라서 해당 랜섬웨어가 초반에 남기는 정보들이 지워지게 된다. 이 경우 $UsnJrml을 확인할 경우 상대적으로 $LogFIle에 비하여 기록이 남아 있는 확률이 높다. 그러므로 각 용도에 맞게 이를 참고하면 된다.

표 2. NTFS Log Tracker

  위 표는 랜섬웨어가 종료된 후의 MFT이다. 우선 실행을 한 후 최초 실행된 26.exe와 같은 파일을 'Roaming'에 생성한다. 그 다음, recover_file_hbmmvstaw.txt라는 파일이 생성되었다는 것을 알 수 있다. 해당 파일은 4줄의 문자열이 구성되어 있다. 해당 파일이 어떠한 용도인지는 알 수가 없다. 내용은 아래와 같다. 

표 3. Recover_file_hbmmvstaw.txt

3.3 Prefetch 분석

프로세스가 실행되면 Prefetch 파일을 생성하게 된다. 이러한 프리패치 파일의 경우 어떠한 파일이 같이 로드되었는지 확인할 수가 있기 때문에, 좋은 단서들이 될 수 있다. 해당 파일의 경로와 관련된 다른 파일들에 대한 정보까지 확인할 수가 있다. 아래의 표를 확인하자.

표 4. WinPrefetchView

  표에서 볼 수 있듯이, 최초에 실행된 26.exe는 itpiwd.exe를 로드한 항목으로 가지고 있다. 이는 26.exe가 하위 프로세스로 생성한다는 점에서 알 수가 있다. 그리고 3.1에서 확인했듯이, 해당 랜섬웨어는 여러 번 VSSVS나 VSSADMIN과 관련하여 실행여부를 확인한다. 만약 이에 대해 "Yes"를 누르지 않을 경우, VSS가 삭제되지 않는다. 따라서 해당 여부를 묻는다면 "No"를 약 2초 간격마다 프로세스가 종료될 때까지 반복해서 눌러주거나 무시하여야 한다.

3.4 Registry 분석

해당 랜섬웨어를 실행한 뒤, 레지스트리에도 변화가 있다. 이를 확인하기 위하여 REGA를 사용하였다. 변화된 레지스트리 키 중 아래의 키를 보자. 해당 경로는 악성코드가 지속성을 유지하기 위하여 생성되는 부분이다.

표 5. REGA

  여기서 해당 레지스트리에 등록되는 새로운 26.exe(ltpiwd.exe)는 3.2의 표에서 나타낸 바와 같이, 프로세스의 기능을 다하면 자기 자신을 삭제한다. 이럴 경우 해당 키는 아무런 쓸모가 없다고 보일 수 있다. 하지만 해당 키에 등록되는 것은, 암호화가 진행되는 동안 사용자가 강제적으로 프로세스를 종료하거나, 컴퓨터를 종료하였을 경우를 대비한 행동이라 볼 수 이다. 다시 말해 프로세스가 진행 중에 종료가 되면 랜섬웨어는 암호화가 된 결과물이 적게 산출되기 때문에, 이를 방지하기 위함이라 볼 수가 있다.

3.5 Network 분석

암호화가 진행되는 동안 "212.85.98.241"와 네트워크 연결이 진행되는 것을 확인할 수 있다. 해당 패킷은 WireShark를 통해 캡처하여 확인할 수 있다. "212.85.98.241"와 네트워크 연결이 진행되기 때문에 Whois를 통해 해당 IP를 조회할 수가 있다. 조회한 결과는 아래의 표와 같다.

표 6. Whois

  여기서 해당 도메인 주소를 알 수가 있다. Southinstrument.org라는 사이트로 해당 사이트에 접속하려는 결과 백신으로부터 해당 사이트가 차단된다. 따라서 VM을 통해 접속해본 결과, 일반적인 장비 판매 업체의 사이트로 확인된다.

4. 정적 분석

정적 분석에서는 동적 분석을 통해 얻은 행위들에 대하여 좀 더 세부적으로 살펴볼 것이다. 분석을 진행하는데 있어 안티 디버깅 기법에 의하여 디버거로 분석을 계속 진행할 수 없었다. 따라서 실행되고 있는 해당 프로세스를 메모리에서 추출하여 이를 분석할 것이다.

  프로세스가 패킹이나 암호화 되어있을 때, 이를 디버거로 분석하기에는 난해하다. 하지만 이러한 프로세스들도 메모리에 올라오게 되면, CPU가 알아볼 수 있는 명령어로 전달되어야 하기 때문에 결국 암호화나 패킹을 해제한 상태로 메모리에 올라오게 된다. 이러한 측면을 활용하고자 메모리에서 추출한 것이다.

추출한 프로세스를 IDA를 통해 분석을 진행하였다. 해당 프로세스에서는 0041F3E0에 주요 함수들이 있는 것으로 확인된다. 해당 부분의 앞부분에 SHGetFolderPath API를 통해 여러 폴더의 경로를 구해오는 것을 확인할 수가 있다.

이렇게 진행된 후 CopyFile API와 CreateProcess API가 오는 것을 확인할 수 있다. 3.1에서 동작을 확인했던 바에 비추어 26.exe가 새로운 파일 이름을 갖는 ECX에 맞게 생성되는 것으로 보인다. 그 후 이를 실행하여 프로세스로 생성하는 것임을 알 수 있다.

그림 4. IDA – CreateProcess & CopyFile

3.1에 따르면 새로운 프로세스 ltwpiwd.exe이 생성된 것으로 확인할 수 있다. 이러한 프로세스는 암호화를 진행한다. 여기서 암호화가 진행되는 동안 vssadmin.exe가 실행되는 것을 확인할 수 있었다. 또한 해당 명령어가 "vssadmin.exe delete shadows /all /Quiet"로 기존의 VSC를 삭제하는 명령어였다. IDA를 통해 확인할 결과 해당 명령어는 스레드를 통해 진행된다. 다음 그림에서 CreateThread API가 사용되는 것을 확인할 수 있다. 여기서 해당 스레드의 내용은 StartAddress의 내용을 실행하는 것으로 해당 부분에 인자로 사용되는 명령어는 위에서 언급했던 vssadmin 명령어이다. 이렇게 vssadmin이 스레드를 통해 진행되는 것이다.

그림 5. IDA - CreateThread

VSS와 관련된 스레드가 생성된 후, 가장 핵심적인 스레드가 생성된다. 해당 스레드에 사용된 API들은 우측의 주석에 적어놓았다. 위에서와 마찬가지로 Start Address에 스레드가 수행할 명령어와 함수가 존재하고 있다. 주석을 보자. Wnet-으로 네트워크와 관련된 API들이 있으며, 그 외에 파일을 찾는 API들이 보이며, 찾은 파일들을 수정하는 함수들도 존재하고 있다.

그림 6. IDA – CreateThread

해당 Start Address를 좀 더 자세히 확인하면, 우선 FindFirstFile API를 통해 암호화 하고자 하는 첫 대상 파일을 찾는다. 대상이 된 파일은 CreateFile의 OPEN_EXISTING 인자를 통해 해당 파일 연다. 그리고 만약 파일의 사이즈가 32 Bytes보다 작거나, 327,155,712 Bytes 보다 클 경우 암호화가 진행되지 않고 다음 파일로 넘어가게 된다. 반대로, 사이즈가 이에 부합할 경우 해당 파일을 ReadFile을 통해 파일의 내용을 읽는다.

이렇게 읽은 후 해당 파일의 앞 부분에 0x170만큼 데이터가 기록된다. 여기서 0x16C까지의 내용은 모두 공통적인 바이트를 갖고 뒤 바이트부터는 서로 상이하다. 파일에 대한 기록이 완료되면 FindNextFile API를 통해 다음 파일에 대한 활동을 시작한다. 이렇게 스레드가 생성이 되고 스레드가 대상 모든 파일에 암호화가 진행되면, 스레드가 종료되며 해당 프로세스도 종료된다.

CSIDL_DESKTOP = 0
CSIDL_INTERNET = 1
CSIDL_PROGRAMS = 2
CSIDL_CONTROLS = 3
CSIDL_PRINTERS = 4
CSIDL_MY_DOCUMENTS = 5
CSIDL_PERSONAL 	 = 0x5

CSIDL_FAVORITES = 6
CSIDL_STARTUP = 7
CSIDL_RECENT = 8
CSIDL_SENDTO = 9
CSIDL_BITBUCKET = 0xA
CSIDL_STARTMENU = 0xB
CSIDL_MYMUSIC = 0xD
CSIDL_MYVIDEO = 0xE
CSIDL_DESKTOPDIRECTORY = 0x10
CSIDL_DRIVES = 0x11
CSIDL_NETWORK = 0x12
CSIDL_NETHOOD = 0x13
CSIDL_FONTS = 0x14
CSIDL_TEMPLATES = 0x15
CSIDL_COMMON_STARTMENU = 0x16
CSIDL_COMMON_PROGRAMS = 0x17
CSIDL_COMMON_STARTUP = 0x18
CSIDL_COMMON_DESKTOPDIRECTORY = 0x19
CSIDL_APPDATA = 0x1A
CSIDL_PRINTHOOD = 0x1B
CSIDL_LOCAL_APPDATA = 0x1C
CSIDL_ALTSTARTUP = 0x1D
CSIDL_COMMON_ALTSTARTUP = 0x1E
CSIDL_COMMON_FAVORITES = 0x1F
CSIDL_INTERNET_CACHE = 0x20
CSIDL_COOKIES = 0x21
CSIDL_HISTORY = 0x22
CSIDL_COMMON_APPDATA = 0x23
CSIDL_WINDOWS = 0x24
CSIDL_SYSTEM = 0x25
CSIDL_PROGRAM_FILES = 0x26
CSIDL_MYPICTURES = 0x27
CSIDL_PROFILE = 0x28
CSIDL_SYSTEMX86 = 0x29
CSIDL_PROGRAM_FILESX86 = 0x2A
CSIDL_PROGRAM_FILES_COMMON = 0x2B
CSIDL_PROGRAM_FILES_COMMONX86 = 0x2C
CSIDL_COMMON_TEMPLATES = 0x2D
CSIDL_COMMON_DOCUMENTS = 0x2E
CSIDL_COMMON_ADMINTOOLS = 0x2F
CSIDL_ADMINTOOLS = 0x30
CSIDL_CONNECTIONS = 0x31
CSIDL_COMMON_MUSIC = 0x35
CSIDL_COMMON_PICTURES = 0x36
CSIDL_COMMON_VIDEO = 0x37
CSIDL_RESOURCES = 0x38
CSIDL_RESOURCES_LOCALIZED = 0x39
CSIDL_COMMON_OEM_LINKS = 0x3A
CSIDL_CDBURN_AREA = 0x3B
CSIDL_COMPUTERSNEARME = 0x3D

CSIDL_FLAG_CREATE 	 = 0x8000

# CSIDL_DESKTOP = 0x0
# CSIDL_INTERNET = 0x1
# CSIDL_PROGRAMS 	 = 0x2
# CSIDL_COMMON_PROGRAMS 	 = 0x17
# CSIDL_PRINTERS 	 = 0x4
# CSIDL_PERSONAL 	 = 0x5
# CSIDL_COMMON_DOCUMENTS 	 = 0x2E
# CSIDL_FAVORITES 	 = 0x6
# CSIDL_COMMON_FAVORITES 	 = 0x1F
# CSIDL_STARTUP 	 = 0x7
# CSIDL_COMMON_STARTUP 	 = 0x18
# CSIDL_RECENT 	 = 0x8
# CSIDL_SENDTO 	 = 0x9
# CSIDL_STARTMENU 	 = 0xB
# CSIDL_COMMON_STARTMENU 	 = 0x16
# CSIDL_DESKTOPDIRECTORY 	 = 0x10
# CSIDL_COMMON_DESKTOPDIRECTORY 	 = 0x19
# CSIDL_NETHOOD 	 = 0x13
# CSIDL_FONTS 	 = 0x14
# CSIDL_TEMPLATES 	 = 0x15
# CSIDL_COMMON_TEMPLATES 	 = 0x2D
# CSIDL_APPDATA 	 = 0x1A
# CSIDL_COMMON_APPDATA 	 = 0x23
# CSIDL_LOCAL_APPDATA 	 = 0x1C
# CSIDL_PRINTHOOD 	 = 0x1B
# CSIDL_ALTSTARTUP 	 = 0x1D
# CSIDL_COMMON_ALTSTARTUP 	 = 0x1E
# CSIDL_INTERNET_CACHE 	 = 0x20
# CSIDL_COOKIES 	 = 0x21
# CSIDL_HISTORY 	 = 0x22
# CSIDL_WINDOWS 	 = 0x24
# CSIDL_SYSTEM 	 = 0x25
# CSIDL_PROGRAM_FILES 	 = 0x26
# CSIDL_PROGRAM_FILES_COMMON 	 = 0x2B
# CSIDL_MYPICTURES 	 = 0x27
# CSIDL_COMMON_PICTURES 	 = 0x36
# CSIDL_PROFILE 	 = 0x28
# CSIDL_ADMINTOOLS 	 = 0x30
# CSIDL_COMMON_ADMINTOOLS 	 = 0x2F
# CSIDL_MYMUSIC 	 = 0xD
# CSIDL_COMMON_MUSIC 	 = 0x35
# CSIDL_MYVIDEO 	 = 0xE
# CSIDL_COMMON_VIDEO 	 = 0x37
# CSIDL_RESOURCES 	 = 0x38
# CSIDL_RESOURCES_LOCALIZED 	 = 0x39
# CSIDL_CDBURN_AREA 	 = 0x3B

csidl_names = {
    CSIDL_DESKTOP: "CSIDL_DESKTOP",
    CSIDL_INTERNET: "CSIDL_INTERNET",
    CSIDL_PROGRAMS: "CSIDL_PROGRAMS",
    CSIDL_CONTROLS: "CSIDL_CONTROLS",
    CSIDL_PRINTERS: "CSIDL_PRINTERS",
    CSIDL_MY_DOCUMENTS: "CSIDL_MY_DOCUMENTS",
    CSIDL_FAVORITES: "CSIDL_FAVORITES",
    CSIDL_STARTUP: "CSIDL_STARTUP",
    CSIDL_RECENT: "CSIDL_RECENT",
    CSIDL_SENDTO: "CSIDL_SENDTO",
    CSIDL_BITBUCKET: "CSIDL_BITBUCKET",
    CSIDL_STARTMENU: "CSIDL_STARTMENU",
    CSIDL_MYMUSIC: "CSIDL_MYMUSIC",
    CSIDL_MYVIDEO: "CSIDL_MYVIDEO",
    CSIDL_DESKTOPDIRECTORY: "CSIDL_DESKTOPDIRECTORY",
    CSIDL_DRIVES: "CSIDL_DRIVES",
    CSIDL_NETWORK: "CSIDL_NETWORK",
    CSIDL_NETHOOD: "CSIDL_NETHOOD",
    CSIDL_FONTS: "CSIDL_FONTS",
    CSIDL_TEMPLATES: "CSIDL_TEMPLATES",
    CSIDL_COMMON_STARTMENU: "CSIDL_COMMON_STARTMENU",
    CSIDL_COMMON_PROGRAMS: "CSIDL_COMMON_PROGRAMS",
    CSIDL_COMMON_STARTUP: "CSIDL_COMMON_STARTUP",
    CSIDL_COMMON_DESKTOPDIRECTORY: "CSIDL_COMMON_DESKTOPDIRECTORY",
    CSIDL_APPDATA: "CSIDL_APPDATA",
    CSIDL_PRINTHOOD: "CSIDL_PRINTHOOD",
    CSIDL_LOCAL_APPDATA: "CSIDL_LOCAL_APPDATA",
    CSIDL_ALTSTARTUP: "CSIDL_ALTSTARTUP",
    CSIDL_COMMON_ALTSTARTUP: "CSIDL_COMMON_ALTSTARTUP",
    CSIDL_COMMON_FAVORITES: "CSIDL_COMMON_FAVORITES",
    CSIDL_INTERNET_CACHE: "CSIDL_INTERNET_CACHE",
    CSIDL_COOKIES: "CSIDL_COOKIES",
    CSIDL_HISTORY: "CSIDL_HISTORY",
    CSIDL_COMMON_APPDATA: "CSIDL_COMMON_APPDATA",
    CSIDL_WINDOWS: "CSIDL_WINDOWS",
    CSIDL_SYSTEM: "CSIDL_SYSTEM",
    CSIDL_PROGRAM_FILES: "CSIDL_PROGRAM_FILES",
    CSIDL_MYPICTURES: "CSIDL_MYPICTURES",
    CSIDL_PROFILE: "CSIDL_PROFILE",
    CSIDL_SYSTEMX86: "CSIDL_SYSTEMX86",
    CSIDL_PROGRAM_FILESX86: "CSIDL_PROGRAM_FILESX86",
    CSIDL_PROGRAM_FILES_COMMON: "CSIDL_PROGRAM_FILES_COMMON",
    CSIDL_PROGRAM_FILES_COMMONX86: "CSIDL_PROGRAM_FILES_COMMONX86",
    CSIDL_COMMON_TEMPLATES: "CSIDL_COMMON_TEMPLATES",
    CSIDL_COMMON_DOCUMENTS: "CSIDL_COMMON_DOCUMENTS",
    CSIDL_COMMON_ADMINTOOLS: "CSIDL_COMMON_ADMINTOOLS",
    CSIDL_ADMINTOOLS: "CSIDL_ADMINTOOLS",
    CSIDL_CONNECTIONS: "CSIDL_CONNECTIONS",
    CSIDL_COMMON_MUSIC: "CSIDL_COMMON_MUSIC",
    CSIDL_COMMON_PICTURES: "CSIDL_COMMON_PICTURES",
    CSIDL_COMMON_VIDEO: "CSIDL_COMMON_VIDEO",
    CSIDL_RESOURCES: "CSIDL_RESOURCES",
    CSIDL_RESOURCES_LOCALIZED: "CSIDL_RESOURCES_LOCALIZED",
    CSIDL_COMMON_OEM_LINKS: "CSIDL_COMMON_OEM_LINKS",
    CSIDL_CDBURN_AREA: "CSIDL_CDBURN_AREA",
    CSIDL_COMPUTERSNEARME: "CSIDL_COMPUTERSNEARME"
}

csidl_display_names = {
    CSIDL_ADMINTOOLS: "Administrative Tools",
    CSIDL_CDBURN_AREA: "CD Burning",
    CSIDL_COMMON_ADMINTOOLS: "Administrative Tools",
    CSIDL_COMMON_OEM_LINKS: "OEM Links",
    CSIDL_COMMON_PROGRAMS: "Programs",
    CSIDL_COMMON_STARTMENU: "Start Menu",
    CSIDL_COMMON_STARTUP: "Startup",
    CSIDL_COMMON_ALTSTARTUP: "Startup",
    CSIDL_COMMON_TEMPLATES: "Templates",
    CSIDL_DRIVES: "My Computer",
    CSIDL_CONNECTIONS: "Network Connections",
    CSIDL_CONTROLS: "Control Panel",
    CSIDL_COOKIES: "Cookies",
    CSIDL_DESKTOP: "Desktop",
    CSIDL_DESKTOPDIRECTORY: "Desktop",
    CSIDL_FAVORITES: "Favorites",
    CSIDL_COMMON_FAVORITES: "Favorites",
    CSIDL_FONTS: "Fonts",
    CSIDL_HISTORY: "History",
    CSIDL_INTERNET_CACHE: "Temporary Internet Files",
    CSIDL_INTERNET: "Internet Explorer",
    CSIDL_LOCAL_APPDATA: "Application Data",
    CSIDL_MYMUSIC: "My Music",
    CSIDL_NETHOOD: "NetHood",
    CSIDL_NETWORK: "My Network Places",
    CSIDL_COMPUTERSNEARME: "My Network Places",
    CSIDL_MYPICTURES: "My Pictures",
    CSIDL_PRINTHOOD: "PrintHood",
    CSIDL_PRINTERS: "Printers and Faxes",
    CSIDL_PROFILE: "The user's username (%USERNAME%)",
    CSIDL_COMMON_APPDATA: "Application Data",
    CSIDL_PROGRAM_FILES: "Program Files",
    CSIDL_PROGRAM_FILES_COMMON: "Common Files",
    CSIDL_PROGRAM_FILES_COMMONX86: "Common Files",
    CSIDL_PROGRAM_FILESX86: "Program Files",
    CSIDL_PROGRAMS: "Programs",
    CSIDL_COMMON_DESKTOPDIRECTORY: "Desktop",
    CSIDL_COMMON_DOCUMENTS: "Shared Documents",
    CSIDL_COMMON_MUSIC: "Shared Music",
    CSIDL_COMMON_PICTURES: "Shared Pictures",
    CSIDL_COMMON_VIDEO: "Shared Video",
    CSIDL_RECENT: "My Recent Documents",
    CSIDL_BITBUCKET: "Recycle Bin",
    CSIDL_RESOURCES: "Resources",
    CSIDL_APPDATA: "Application Data",
    CSIDL_SENDTO: "SendTo",
    CSIDL_STARTMENU: "Start Menu",
    CSIDL_STARTUP: "Startup",
    CSIDL_ALTSTARTUP: "Startup",
    CSIDL_SYSTEM: "system32",
    CSIDL_SYSTEMX86: "system32",
    CSIDL_TEMPLATES: "Templates",
    CSIDL_WINDOWS: "WINDOWS"
}

Malware_ixaobny분석.pdf

분석을 하는데 있어 처음으로 IDA를 중점으로 사용하게 된 계기가 되었다. 막힌 부분도 많았던지라 구체적으로 어떠한 기능을 하는지 확인하기는 힘들었지만, 그래도 일단 문서로 남겨놓자.

$MFT Path Parsing

  추출된 $MFT에서 파일의 경로를 조합하기 위하여 만들어보았다. 영어의 경우 이상이 없지만, 한글의 경우 인코딩 문제로 인하여 깨짐 현상이 발생한다. 그러한 면에서는 아직 미완성이지만 $MFT에서 파일의 경로를 알아낼 때 필요하기에 만들어보았다.

+ 한글 인코딩 문제도 해결 

1. 개요

  이벤트 로그에 대하여 학습을 하기 위해 이벤트 ID에 대하여 알아보았다. 너무 많은 이벤트들이 존재하기에 어떤 이벤트가 중요한 것인지 불필요한지 직접 확인 하기에는 번거로움이 크다. 따라서 이번 문서에서는 많은 이벤트들 중에서 유심히 보아야 할 로그에 대하여 학습하고자 한다.

  이에 대하여 NSA에서는 Spotting the Adversary with Windows Event Log Monitoring에 대하여 글을 작성하였으며 이를 토대로 해당 문서를 작성하고자 한다. 위에서 언급한 해당 문서에서는 크게 16개의 카테고리에 대하여 설명을 한다. 이러한 로그에 대하여 학습해보자.

  아래의 테이블은 각 카테고리와 이를 나타내는 이벤트 ID에 대하여 정리된 것이다. 이러한 표에서 몇 가지에 대하여 상세하게 알아보자.

2. 이벤트 카테고리

2.1 Application Whitelisting

  응용프로그램 화이트 리스트 이벤트는 차단된 응용 프로그램을 찾기 위해 수집되어야 한다. 차단된 응용프로그램들은 악의적일 수가 있으며, 승인되지 않은 소프트웨어의 실행을 시도하고자 한다. 응용프로그램 화이트 리스트 이벤트는 SRP(소프트웨어 제한 정책)이나 AppLocker가 네트워크 상에서 사용될 때 수집 될 수 있다.

그림 1. Whitelisting Events

2.2 Application Crashes

  응용 프로그램 충돌에 관한 이벤트들은 충돌이 발생했을 때, 이것이 악의적인 것에 의한 것인지 아닌지 판단하는데 도움을 준다. BSOD, Windows Error Reporting(WER), 응용 프로그램 충돌들은 이벤트를 발생시킨다. 만약 EMET(Microsoft Enhanced Mitigation Experience Toolkit)을 사용하고 있다면, EMET 로그들도 수집될 것이다.

그림 2. Application Events

2.3 System or Service Failures

  시스템과 서비스 실패는 조사하는데 있어 흥미로운 이벤트들이다. 서비스 동작은 보통 실패하지 않는다. 만약 서비스가 실패했을 경우, 관리자로서 이를 검토하여야 한다. 만약 윈도우 서비스가 지속적으로 실패할 경우, 이는 공격자가 해당 서비스를 대상으로 하고 있음을 나타내는 것이다.

그림 3. System Events

2.4 Windows Update Errors

  컴퓨터는 알려진 취약점을 대비하기 위하여 최신 상태를 유지해야 한다. 그럴 가능성은 거의 없지만, 이러한 패치가 때로는 적용하는데 실패하기도 한다. 업데이트를 실패하는 것은 운영체제나 응용프로그램의 취약점을 피하기 위하여 해결해야만 한다.

그림 4. Windows Update Failed Event

2.5 Windows Firewall

  만약 클라이언트 환경이 호스트 기반의 윈도우 방화벽의 사용하고 있다면, 방화벽의 상태를 나타내는 이벤트들이 수집된다. 예를 들어, 만약 방화벽이 활성화에서 비활성화로 전환된다면 이에 대한 로그가 남는 것이다. 일반적인 사용자는 방화벽의 상태나 규칙을 변경하지 않는다.

그림 5. Firewall Events

2.6 Clearing Event Logs

  정상적인 동작을 하는 동안 이벤트 로그 데이터가 지워질 가능성은 거의 없으며, 악의적인 공격자들이 그들의 행동을 감추기 위해 이벤트 로그를 지웠을 가능성은 높다. 이벤트 로그가 지워져을 때 이는 분명히 의심할 만한 사항이다. 이벤트 로그를 수집하는 것은 공격자가 자신의 행동을 감추기 더 어렵게 하는 이점이 있다.

  하지만 공격자가 이벤트를 지웠을 경우 이것이 새로운 이벤트로 기록이 된다. 따라서 로그를 지웠다는 새로운 이벤트가 발견된다면, 이에 맞게 추가적인 행동을 취해야 한다. 가령 VSS를 확인한다거나 삭제된 로그를 복구하는 조치를 취하면 좋을 것이다.

그림 6. Log Activity Events

2.7 Software and Service Installation

  일반적인 네트워크 동작의 일부로써, 새로운 소프트웨어나 서비스가 설치되며 이러한 활동에 대해서 이벤트가 생성 된다. 관리자들은 새롭게 설치된 소프트웨어나 시스템 서비스에 대한 로그를 통해 확인할 수가 있으며, 네트워크에 위험하지 않은지 추가적인 확인할 수가 있다.

그림 7. Software and Service Events

  여기서 이벤트 ID 800에 대하여 알아야 더 언급하자면, 윈도우 7에서 해당 이벤트는 매일 오전 12:30에 응용프로그램 활동에 대하여 요약을 제공하기 위하여 생성된다. 이 이벤트는 설치되거나 제거된 응용 프로그램의 수를 찾는 관리자들에게 편의를 제공할 것이다.

2.8 Account Usage

  사용자 계정 정보는 수집과 감사 될 수가 있다. 로컬 계정 사용을 추적하는 것은 Pass the Hash 활동과 인가되지 않은 다른 계정의 사용을 탐지할 수 있게 도와준다. 원격 데스크톱 로그인 이나 권한 그룹에 사용자를 추가하거나, 계정 잠금과 같은 추가적인 정보들은 추적될 수가 있다.

  권한 그룹에 추가된 사용자 계정은 실제로 권한 그룹에 속한 사용자임을 보증하기 위하여 더 면밀히 감시되어야 한다. 권한 그룹의 인가되지 않은 멤버는 악의적인 활동이 발생할 수 있음을 나타낸다.

그림 8. Account Activity Events

  도메인 계정 잠금 이벤트는 로컬 계정 잠금 이벤트가 로컬 컴퓨터에 생성되는 것에 반하여 도메인 컨트롤러에 생성된다. 또 위에서 성공적으로 사용자 계정에 로그인한 이벤트 (ID: 4624)에서는 로그온 유형에 대하여 반드시 확인해주어야 한다. 이에 대한 설명은 2.15의 로그온 유형 표를 참고하자.

2.9 Kernel Driver Signing

  윈도우 비스타 64비트에서 커널 드라이브 서명은 커널에 악의적인 드라이버들이나 행동이 삽입되는 것에 대해 막도록 하는 효과가 있다. 변경되어 보호되고 있는 드라이버의 표시는 악의적인 활동을 나타낼 수가 있거나 디스크 에러와 조사를 보장한다.

그림 9. Kernel Driver Signing Events

2.10 Group Policy Errors

  도메인 컴퓨터의 관리는 관리자가 보안과 그룹 정책의 규제를 높이는 것을 허가한다. 그룹 정책 에러로 인해 정책을 적용하지 못하는 것은 보안의 안전함을 감소시킨다. 따라서 관리자는 즉시 이러한 이벤트들에 대해 조사하여야 한다.

그림 10. Group Policy Errors Events

2.11 Windows Defender Activities

  Spyware나 Malware는 심각한 문제들을 남기기에 마이크로소프트는 Windows Defender라는 Anti-Spyware와 Anti-Virus를 개발하였다. 이러한 악의적인 프로그램을 감지, 제거, 예방한다는 알림은 조사되어야 한다. Windows Defender가 도작하는데 실패했다는 알림은, 관리자가 추가적인 감염이나 이러한 가능성을 방지하기 위해 즉시 올바르게 만들어야 한다. 만약 서드파티 안티바이러스나 안티스파이웨어 제품이 올바르게 사용되고 있다면, 이러한 로그는 필요하지 않다.

그림 11. Windows Defender Activities Event

2.12 Mobile Device Activities

  무선 장치들은 많은 곳에 존재하며 기업의 무선 장치 활동을 기록하는 것은 중요하다. 프로토콜에 관계 없이 통신을 위해 사용되는 무선장치들은 다른 네트워크를 오가며 손상될 수가 있다. 그러므로 어떤 휴대용 네트워크 장치를 추적하는 것은 손상이 일어나는 것을 방지하는데 유용하다. 아래의 이벤트들의 생성은 얼마나 자주 장치를 연결해제 하거나, 재연결 하는 가에 따라 빈번히 생성된다.

그림 12. Mobility related Events

2.13 External Media Detection

  USB 장치를 감지하는 것은 많은 환경에서 중요하다. 아래의 나타나는 이벤트와 이벤트 로그들은 오직 윈도우 8 이상에서만 사용이 가능하다.

그림 13. External Media Detection Events

  만약 윈도우 7이하의 경우에는 Microsoft-Windows-Driverframeworks-Usermode를 확인하면 된다. 해당 부분에서 이벤트 ID 1003, 2000, 2001, 1004를 통하여 USB가 연결되었다는 것을 확인할 수가 있으며 반대로 해당 USB가 해제된 것은 1006, 1008, 2900, 2901 등을 통해 확인할 수가 있다.

2.14 Printing Services

  문서를 인쇄하는 것은 많은 환경에서 일상적인 작업을 위해 필수적이다. 매우 많은 양의 인쇄는 어떤 문서가 인쇄되었는지, 누구의 것인지에 대하여 추적하거나 확인하는데 있어 어렵게 한다. 처리를 위해 프린터로 전달되는 문서들은 다양한 방식으로 로깅하기 위해 기록될 수 있다.

  각 인쇄 작업은 프린터 서버나 프린터 그 자체 또는 요청된 기계에 기록될 수가 있다. 이러한 동작들에 대한 로그를 기록하는 것은 인쇄된 특정 문서들을 발견할 수가 있다. 아래의 이벤트들은 문서를 인쇄하기 위해 요청되는 클라이언트 장비에서 생성된 것이다.

그림 14. Printing Services Events

2.15 Pass the Hash Detection

  사용자 계정에 Pass the Hash(PTH)를 검출하는 것은 XML로 고급 필터링 옵션을 구성하는 커스텀 뷰를 생성하는 것이 요구된다. 이벤트 쿼리 언어는 XPath에 기반한다. 아래의 추천된 쿼리 리스트는 PTH 공격을 감지하는데 제한된다. 이러한 쿼리들은 도메인의 일부가 아닌 로컬 계정을 사용하는 공격자의 행동을 밝히는데 초점이 맞추어져 있다.

  아래의 쿼리 리스트는 도메인의 일부가 아닌 다른 장치로 원격 연결을 시도하는 로컬 계정이 보여주는 이벤트들을 포착한다. 아래의 XPath 쿼리들은 이벤트 뷰어의 Custom Views를 통해 사용된다.

  성공적인 PTH은 Securiy Log의 이벤트 ID 4624를 야기한다. 도메인 로그온이 아닌 익명의 NTLM 인증은 로그온 유형이 3으로 나타난다. 아래에는 해당 이벤트에 대한 설명이 나와있으며 아래의 표에서 로그온 유형에 따른 설명들을 확인할 수가 있다.

그림 15. Logon Success – PTH Event

표 2. Logon Type

  로그온 유형에 따라 해당 로그인의 의미가 많이 중요해질 수가 있으므로 위의 표를 상기하여야 한다. 아래에 있는 쿼리 리스트에서 <DOMAIN NAME>에 실제 도메인 이름을 넣어주면 해당 쿼리가 올바르게 동작한다.

  PTH를 통한 로그온 시도에 실패했을 경우 이는 이벤트 ID 4625를 야기한다. 이 역시 로그온 타입이 3으로 도메인 로그온이 아닌 익명의 로그온 계정이 NTLM 인증을 하고자 할 때 생성된다.

그림 16. Logon Fail – PTH Events

2.16 Remote Desktop Logon Detection

  원격 데스크탑 계정 활동 이벤트는 GUI 이벤트 뷰어를 통해 확인하기 쉽지 않다. 계정이 원격으로 클라이언트에 연결될 때, 일반적인 로그온 성공 이벤트가 생성된다. 커스텀 쿼리 필터는 행해진 로그온 유형을 분류하는데 도움을 줄 수 있다. 아래의 쿼리는 원격 데스크톱을 사용한 로그인을 보여준다. 원격 데스크톱 활동은 특정 관리자가 이를 사용하며 이는 제한된 설정에서 진행되어야 한다. 또한 이러한 활동은 모니터링 되어야만 한다. 만약 예상치 못한 로그인 활동이 있을 경우 이에 대해선 반드시 조사하여야 한다.

  아래의 XPath 쿼리는 이벤트 뷰어의 커스텀 뷰를 통해 사용된다. 이벤트 ID 4624와 4634는 각 각 언제 사용자가 로그온 했는지, 로그오프 했는지를 나타낸다. 로그온 타입 10은 이러한 원격 로그인에 대해 나타낸다.

그림 17. Remote Desktop Login Events

3. 결론

2장의 내용을 통하여 어떠한 로그들이 어떠한 용도로 활용되어야 하는지에 대하여 알아보았다. 위의 내용이 옳다는 것만은 아니다. 당연히 이외에도 유심히 보아야 할 이벤트로그는 많이 존재할 것이다. 그러한 추가적인 내용을 공부하기 전에 이번 문서를 통해 어떠한 식으로 접근하여야 하는가에 대하여 알아보았다고 할 수 있다.

이벤트 로그를 공부하면서 많은 이벤트를 접하게 될 때 www.eventid.net/을 통해 찾아볼 수 있으며, 대부분의 경우 구글에 검색하면 많은 정보들을 볼 수가 있다.

출처

* 블로그, Spotting the Adversary with Windows Event Log Monitoring

http://www.redblue.team/2015/09/spotting-adversary-with-windows-event.html

* 블로그, 윈도우 이벤트 로그 분석 #기초

http://elven.kr/archives/361

* 문서, Spotting the Adversary with Windows Event Log Monitoring.pdf

    https://www.nsa.gov/ia/_files/app/spotting_the_adversary_with_windows_event_log_monitoring.pdf

1. 이벤트 로그

  로그란 감사 설정된 시스템의 모든 기록을 담고 있는 데이터라 할 수 있다. 이러한 데이터에는 성능, 오류, 경고 및 운영 정보 등의 중요 정보가 기록되며, 특별한 형태의 기준에 따라 숫자와 기호 등으로 이루어져 있다. 이러한 로그는 운영체제가 업그레이드 됨에 따라 버전 별로 형태와 경로가 조금 상이하다. 각 운영체제 별 이벤트 로그의 특징은 아래의 그림과 같다.

그림 1. 운영체제 별 로그 특징

  이러한 로그를 분석하여 필요로 하는 유용한 정보를 만들어 낼 수가 있으며 로그 데이터 분석을 통해 얻을 수 있는 정보는 다음과 같이 다양하게 활용될 수가 있다.

표 1. 로그 데이터 분석의 활용

  이러한 로그 데이터는 시스템에서 발생하는 모든 문제에 대한 유일한 단서가 될 수 있으며, 시스템에서 발생한 오류 및 보안 결함에 대하여 검색이 가능하다. 또한 잠재적인 시스템 문제를 예측하는데 사용할 수가 있다.

  장애 발생시 복구에 필요한 정보로 활용하거나, 침해 사고가 발생된 경우 로그에 남아 있는 근거들을 자료로 활용할 수가 있다. 이렇게 살펴본 바와 같이 로그 데이터는 중요한 의미를 가지고 있으며, 그렇기에 올바른 분석이 더욱 요구 된다.

2. 로그 관리 및 분석

  로그 분석에 필요한 정보로는 로그 설정 방법, 파일의 저장 위치, 로그에서 나타내는 정보를 말할 수가 있다. 그리고 로그를 관리하기 위해서는 로그의 실시간 저장 및 무결성을 확보해야 하는데, 이를 위해선 시스템의 로컬에 로그를 저장하기 보다는 원격 로그서버를 구축하거나 DB서버와 연동하는 방식도 사용된다. 기초적인 Windows의 로그에 대하여 알아보자.

2.1 이벤트 로그의 이해

  Windows 시스템에서는 시스템의 로그가 이벤트 로그형식으로 관리되며, 이벤트 로그를 확인하기 위해서는 Windows의 Event Viewer를 이용하여야 한다. Event Viewer를 실행시키면 아래의 그림과 같은 모습을 나타내는 것을 확인할 수가 있다.

그림 2. 윈도우 이벤트 뷰어

  Windows 시스템은 응용 프로그램 로그, 보안 로그, 시스템 로그와 같이 세 가지 로그를 이벤트에 기록하며, OS 구성에 따라 디렉터리 서비스 로그, 파일 복제 서비스 로그, DNS 서버 로그가 추가될 수가 있다. 주요 이벤트 별 특징은 다음과 같다.

표 2. Windows 시스템 이벤트 로그 종류

이러한 로그들은 이벤트 뷰어를 통해 쉽게 확인할 수가 있다. 그렇다면 이벤트 뷰어를 통해 어떻게 나타나는지 아래의 그림을 통해 확인해보자.

그림 3. 이벤트 헤더와 설명

  각 이벤트를 확인하면 위와 같은 정보들이 나타난다. 위의 상자와 같은 부분에서 어떠한 경로에 있는지 등에 대한 정보가 있으며, 아래에는 해당 이벤트에 대한 정보들이 나타나 있다. 상단의 탭에서 Details를 누르면 좀 더 많은 정보들을 확인할 수가 있다.

  위 그림에서 하단의 Level이라 되어 있는 곳을 보자. Level에는 Information이라 되어 있다. 이처럼 이벤트 뷰어에서는 이벤트의 형태를 다섯 가지의 유형으로 구분한다. 이러한 다섯 가지 유형에 대해 아래의 그림을 통해 확인하자.

표 3. 이벤트 유형

2.2 이벤트 로그 설정 확인

  이벤트 로그에 대하여 개략적으로 알아보았다. 그렇다면 이러한 이벤트 로그의 설정을 확인하는 방법에 대하여 알아보자. 이벤트 로그를 설정하기 위해선 크게 두 가지 방법이 있으며 바로 레지스트리를 이용하는 방법과 이벤트 뷰어를 이용하는 방법이다. 이에 대해 알아보자.

레지스트리를 통한 확인

  레지스트리를 통해 확인하는 방법에 대하여 먼저 알아보자. 우선 Win+R을 통해 실행 창이 나타나면 regedit를 입력하여 레지스트리 편집기를 띄우자. 그리고 아래의 경로로 이동하면 이벤트 로그에 관한 설정이 나타나는 것을 확인할 수가 있다.

그림 4. 레지스트리를 통한 이벤트 로그 설정

위와 같이 나타나는 것을 확인할 수가 있다. 좌측의 키에는 응용프로그램, 보안, 시스템 등이 존재하는 것을 확인할 수가 있다. 우측은 각 항목들을 통해 로그에 대한 설정이 기록되어 있는 것을 확인할 수가 있다. 몇 가지 항목이 의미하는 것에 대하여 알아보자.

표 4. 레지스트리 - 항목 설명

이벤트 뷰어를 통한 확인

이벤트 뷰어에서도 각 이벤트 로그에 대한 속성을 변경할 수가 있다. 해당 속성을 변경하고자 한다면, 해당 이벤트의 속성에 들어가야 한다. 아래의 그림을 보자.

그림 5. 이벤트 뷰어 - Disabled

  현재 위의 그림에서 붉게 표시한 바와 같이, Driverframeworks-UserMode는 모니터링 설정이 되어 있지 않은 것을 확인할 수가 없다. 만약 모니터링 되고 있지 않은 항목에 대하여 모니터링이 필요하다고 생각되면 우측을 클릭하면 된다.

그림 6. 이벤트 뷰어 – 설정

우클릭을 하여 나타나는 목록 중에서 Properties에 들어가서 설정을 할 수가 있으며, Properties 밑에 있는 Enable Log를 통해서도 모니터링 하도록 설정할 수가 있다. 이렇게 설정을 바꾼 뒤, 해당 이벤트가 발생하게 되면 로그가 남는 것을 확인할 수가 있다.

그림 7. 이벤트 뷰어 - Enable

3. 이벤트 로그 감사 정책

  감사정책이란 개체 액세스, 로그온/로그오프, 감사 정책 설정 변경 등의 보안 관련 로그를 기록하며, 지정한 이벤트 범주의 사용자나 시스템 동작을 기록하도록 정책 설정이 가능하다. 감사 정책의 자세한 설명 및 로그 관리를 위한 권장 값은 다음과 같다.

표 5. 감사 정책 권장 값

3.1 로컬 보안 정책 설정

  이러한 감사 정책을 확인하기 위해 로컬 보안 정책을 확인해보자. 제어판에서 관리도구 중 로컬 보안 정책을 선택하거나 Local Security Policy를 찾아서 실행한 다음 Local Policies의 하위에 있는 Audit Policy를 확인하면 된다. 아래의 그림을 보자.

그림 8. Local Security Policy

  위와 같이 설정되어 있는 것을 확인할 수가 있다. 현재 감사하지 않음으로 되어 있는 것을 확인할 수가 있다. 이를 감사로 변경하면 감사가 시작된다. 이러한 감사정책을 구성하기 전에 유의해야 할 사항들에 대하여 알아보자.

  첫 째, 지나친 감사 범위 설정은 중요 로그 검색에 어려움을 동반한다. 불필요한 로그까지 저장되기 때문에, 검색의 어려움뿐만 아니라 시스템의 성능 저하 및 로그 관리의 어려움을 발생 시킬 수 있으므로 시스템 감사 구성에 필요한 항목을 사전에 선정하여야 한다.

  둘 째, 잘못된 이벤트 로그 크기 설정은 용량 한계로 시스템이 중지될 수가 있다. 시스템 장애가 발생한다는 것은 서비스를 위해 서버를 운영하는 기업에서는 많은 손실을 야기할 수 있다. Windows는 이러한 문제를 방지하기 위해 기본 설정으로 오래된 항목을 덮어씌우는 옵션이 설정되어 있다.

3.2 보안 템플릿을 통한 감사 정책 구성

  보안 템플릿이란 보안 구성을 표시하는 파일로 로컬 컴퓨터 및 그룹 정책 개체를 적용하거나 보안 분석에 사용된다. 이러한 보안 템플릿을 이용하면 손쉽게 감사 정책 구성을 공유할 수가 있고, 반대로 공유된 감사 정책을 구성할 수가 있다.

그림 9. 보안 템플릿 구성

  템플릿을 구성하는 방법은 위의 그림과 같다. 좌측의 키에서 Security Settings에 놓고 상단 탭의 Action을 선택하면 위와 같이 나타나는 것을 확인할 수가 있다. Import Policy를 선택하면 다른 템플릿을 통해 감사 정책을 구성할 수가 있다.

  반대로 현재의 감사 정책 구성을 다른 PC에 공유하거나 백업해놓고자 할 경우 Export Policy를 선택하여야 한다. 선택 후 저장 경로를 설정해주면 *.inf와 같은 형식으로 저장이 되는 것을 확인할 수가 있을 것이다.

4. 보안 감사 이벤트 설명

그렇다면 어떤 이벤트를 보아야 할까? 우선 이벤트 로그는 기존의 Evt에서 비스타 이후 부터 Evtx로 사용되고 있다. 실제 로그 파일의 헤더 및 구성의 변경이 있지만 대부분의 이벤트가 Evt ID 값에 4096 값을 더해주면Evtx 형태의 이벤트 ID 값이 된다. 각 감사에 따른 주요한 이벤트들의 목록의 아래의 표들과 같다. [표 출처 - http://elven.kr/archives/361 ]

  위의 표는 보안 감사 정책에 따라 구분된 것으로 실제 이벤트 뷰어를 통해서 확인할 때는 해당 항목을 찾는데 번거로움이 있을 수 있다. 따라서 아래의 그림과 같이 주요한 몇 개의 이벤트만 따로 정리할 수가 있다.

출처

* 블로그, 윈도우 이벤트 로그 분석 #기초

• http://elven.kr/archives/361

* 안랩, 전문가 칼럼, 윈도우 로그 관리 및 분석 방법

• http://www.ahnlab.com/kr/site/securityinfo/secunews/secuNewsView.do?menu_dist=3&seq=7887

* MSDN, 보안 템플릿 정의

• https://msdn.microsoft.com/ko-kr/library/cc738340(v=ws.10).aspx

1.  요약

  중요한 파일이 유출되었을 경우 많은 상황들이 나타날 수가 있다. 이러한 많은 상황들 중 이번 문서에서는 USB를 통해 문서파일이 유출된 경우에 대하여 다루어보았다. 따라서 이외의 상황에 대해선 다루지 않는다.

  문서 유출과 관련되어 기술적인 측면만으론 정확하게 확인하기가 힘든 것은 사실이다. 그래도 그러한 가능성의 여부를 좀 더 확인하고자 하는 것은 충분히 가능하다. 특정 파일이 유출되었는가를 확인하기 위해선 이후에 설명할 바와 같이, 하나의 요소만으로는 확인할 수가 없다.

  남겨진 여러 가지의 흔적들의 연관성을 통해 당시 그 상황에 어떠한 일이 이루어졌는지를 확인하므로, 당사자가 하지 말아야 할 행동을 했거나 의심되는 행동을 했는지 확인하는 과정이 될 것이다.남아 있는 흔적의 수가 하나 하나 늘어날수록 더 유용할 수도 있지만, 오히려 분석을 하는데 있어 시간을 지체하게 만들기도 한다.

  PC에서 문서가 열람이 된 경우 남는 흔적들을 통해 본인이 자리를 비웠을 때 어떠한 문서들이 열람되었는지를 확인할 수가 있으며, USB를 통해 유출된 경우 USB 연결 흔적과 USB에서 문서를 열람했다면 좀 더 결정적인 흔적이 남는다.

  가장 많은 흔적이 남는 부분은 레지스트리이지만, RecentDocs의 항목만으로는 유출에 대하여 확정 짓기에는 많이 부족한 감이 있다. 따라서 레지스트리 외에도 프리패치, 링크파일 등을 통해서 종합적으로 추론할 수가 있다.

2. 개요

  일반적으로 특정 파일이 의도치 않게 유출 되는 경우가 발생할 수 있다. 가령 같은 직장의 다른 직원이 내 PC의 중요파일이나 기밀 문서 등을 가져가므로 유출되었을 수가 있다. 이러한 사항들로 인해 많은 사람들이 유출 여부를 확인하고자 하지만 막상 구체적인 방법에 대해 제시된 글은 많지 않다.

  실제로 특정파일이 유출되는 경우와 관련해서는 많은 사항들을 고려해야 한다. 하지만 이 모든 것을 다루기에는 어려우므로 한정적인 상황에 대해서나마 방법에 대하여 고려해보자. 기술적인 측면뿐 아니라 심리적인 측면 또한 들어가므로 유념하여야 한다.

2.1 실습 준비

  많은 사항들 중 USB를 통해 PC의 파일이 유출되는 경우에 한해 다룰 것이다. 따라서 특정 파일을 가지고 있는 PC와 USB가 있어야 한다. 그리고 실습을 위해 특정 파일을 3가지 준비하였다. 주로 문서와 관련한 사항이 중요하므로 이에 대하여 초점을 맞추었다.

그림 1. Target File List

  이외에 EXE파일이나, USB를 통한 유출이 아닌 부분은 여기서 다루지 않을 것이다. 문서에서 가장 자주 쓰이는 3가지 종류로 PDF, MSWord, HWP를 가지고 이제 어떠한 방향으로 접근해야 할 지 알아보자.

2.2 접근 방향

  특정 파일들을 준비하였으므로, 어떻게 접근할 것인가에 대해 먼저 논의할 것이다. 그리고 이러한 방향에 대하여 직접 실습을 통한 작업을 첨부하여 더 자세하게 알아볼 것이다.

  PC를 만든 것은 결국 인간이며, 범죄를 저지르는 사람도 결국 인간이다. 따라서 기술적인 측면뿐만 아니라 심리적인 요소 또한 고려를 해야 편협적이지 않게 접근할 수가 있다. 한번 직접 범법자가 되었다 생각하고 타인의 PC에서 파일을 가져오는 방법에 대해 생각해보자.

표 1. 고려사항

  이러한 고민을 한다는 것에 이의를 제기할 사람을 아마 없을 것이다. 대상 PC에 접근하는 방법은 같은 회사라면 대상이 자리를 비웠을 때 접근을 할 것이며, 파일을 가져오는 방법으론 FTP나 메일을 통해 보내는 것도 있지만, 가장 편하게 USB를 연결하여 바로 보내는 것이 빠르다. 또한 마지막으로 파일의 위치는 기존에 조사를 통해 위치를 알고 있거나 당장에 찾을 것이다.

  바로 이러한 과정 중에 중요한 요소가 한 가지 더 발생하게 된다. 바로 해당 파일이 올바른지, 또는 올바르게 옮겨졌는지 확인을 한다는 것이다. 어느 위치에 있는지 모를 경우 유사한 이름의 많은 파일들을 열어보게 될 것이며, 이름을 안다 해도 이것이 맞는지 확인할 것이다.

  후자의 경우 전자의 과정을 거치거나 거치지 않더라도, 올바르게 파일이 옮겨졌는지 바로 그 현장에서 USB에 담긴 파일을 실행하여 확인해 볼 수가 있다. 바로 이러한 요소가 이 문서가 초점을 맞춘 부분이다.

3. PC에서 열람

  용의자가 파일을 복사해 가기 이전에 PC에서 열람을 했다는 가정하에 어떠한 흔적들이 남는지 조사해볼 것이다. 준비된 3가지 문서에 따라 어떠한 흔적들이 남는지 확인해보자.  

3.1 ReadMe.PDF

그림 2. PDF – Opened Time

  PDF파일을 먼저 열어보았다. 시간은 위와 같이 01:17:11초 근처에 열었으며 종료는 이로부터 13초후에 종료하였다. 어떠한 변화가 있는지 레지스트리를 확인해보았다. 아래의 그림을 보자.

그림 3. PDF – Registry (1)

  위의 그림과 같이 PDF는 Adobe의 하위에 있는 Acrobat Reader\DC\AVGenerel의 하위 항목 값들이 변화한 것을 확인할 수가 있다. 해당 문서를 열람하고자 할 경우 PDF 리더기가 먼저 실행이 되므로 이와 관련된 부분들이 변화한 것이다.

  Acrobat Reader의 cRecentFile의 하위에 c1의 값들이 변화한 것을 확인할 수가 있다. C1이 나타내는 FileName이 ReadMe.pdf인 것과 경로를 확인할 수 있으며, 해당 키의 마지막 쓰기 시간이 PDF를 실행한 시점과 같다는 점에서 실행한 흔적임을 알 수 있다.

그림 4. PDF – Registry (2)

  레지스트리에서 가장 보편적으로 확인해야 할 항목 중 하나인 RecentDocs에도 해당 PDF 파일의 항목이 추가된 것을 확인할 수가 있다. 레지스트리 외의 항목들은 무엇이 있을까? 아래의 그림을 보자.

그림 5. PDF – Prefetch File

  우선 PDF Viewer인 Acrobat Reader가 실행되었으므로, 이에 해당하는 프리패치 파일이 생성된 것을 확인할 수가 있다. 여기서 해당 프로세스가 로드한 항목들 중 ReadMe.pdf가 존재하는 것 또한 확인할 수가 있다.

그림 6. PDF – Link File

  다른 항목으로는 바로 링크파일이다. 프리패치의 항목에서도 링크파일이 로드 된 것을 확인할 수가 있으며, 실제로 링크파일 분석 도구를 통해 확인하면 해당 시간에 맞는 흔적이 존재하는 것을 확인할 수가 있다. 만약 기존에 열어보았던 문서라면 LnkCreation Time과 AccessTime 등이 다르다. 

3.2 ReadMe.hwp

그림 7. HWP – Opened Time

  HWP의 경우 특이하게 대한민국에서만 사용률이 높은 문서양식이다. Hwp와 MS 워드 중 hwp를 쓰는 기업도 있기 때문에, 이에 중요한 내용이 담겨 있을 경우를 고려하여 어떠한 흔적이 남는지 확인해보았다.

그림 8. HWP – Registry (1)

  위의 그림은 문서를 연 시간대 이후 변화한 레지스트리 항목들을 나타내고 있다. 전체적으로 PDF와 유사한 변화들을 보이고 있다. 우선 RecentDocs에 대해선 PDF에서도 다루었기에 다루지 않을 것이다. 그림 8의 마지막 항목을 보자.

그림 9. HWP – Registry (2)

   PDF Viewer와 같이, HWP는 한컴오피스에 관련되어 레지스트리 항목이 저장되는 것을 확인할 수가 있다. 해당 값에는 문서의 경로까지 나타나고 있다.

그림 10 HWP – Prefetch File

  프리패치 파일 또한 생성되는 것을 확인할 수가 있다. 로드된 항목엔 이전과 같이 링크파일의 존재를 확인할 수가 있으므로 Lnk파일 또한 확인해보자.

그림 11. HWP – Link File

  HWP를 연 시간에 AccessTime이 나타나고 있다. 여기서 Creation Time과 Access Time이 다른데, 이는 이전에 설명한 바와 같이 이전에 한번이라도 열어본 파일인 것이다. 이전에 열었을 때 링크 파일이 생성되었으며, 마지막 접근 시간은 22일 이므로 서로 다르다. 이를 통해서도 언제 마지막으로 접근했는지 확인할 수가 있다.

3.3 ReadMe.Docx

그림 12. Docx – Opened Time

  MS 워드 또한 Hwp와 마찬가지로 많이 사용되는 문서 양식이다. 위 그림과 같이 해당 문서를 연 시간은 01:10:19초 가량이며 이전과 마찬가지로 해당 시간대 이후의 레지스트리 변화를 살펴보자.

그림 13. Docx – Registry (1)

  RecentDocs에 값이 추가된 것을 확인할 수가 있다. 이외에 특이한 점으로 Microsoft의 하위에 Office\14.0\Word 밑에 있는 값들에 변화가 있다는 것을 확인할 수가 있다. 여기서 중요한 부분은 File MRU이다.

그림 14. Docx – Registry (2)

  Fil MRU를 보면 Item으로 값이 존재한다. 여기서 Item에 순서가 주어져 있는데 가장 최근에 열어본 문서의 경로와 이름이 1번이 된다. 이후 새로운 문서를 확인했을 경우 해당 번호가 뒤로 밀리므로 유의하여야 한다.

  마지막으로 앞의 두 경우와 마찬가지로 프리패치 파일과 링크 파일을 통해 해당 문서를 열었는지 확인할 수가 있다.

그림 15 Docx – Link File

4. USB에서 열람

  이전 장의 내용들을 통해 어떠한 문서가 열람되었는지 많은 흔적들을 살펴볼 수가 있었다. 하지만 이러한 하나의 흔적들만으로는 파일 유출에 대해 확신할 수가 없다. 그러므로 이번 장에선 USB 내에서 열람된 경우를 살펴보자.

  USB에서 열람되었다는 것은, 이전의 흔적들보다 좀 더 큰 유출 가능성을 나타낸다. 만약 연결되지 않아야 할 USB가 연결되었을 수도 있으며, USB로 옮겨져선 안될 문서가 존재할 수도 있다. 또한 USB의 경우 언제 연결되었는지 시간을 확인할 수가 있으므로 더 많은 흔적들을 남긴다고 볼 수 있다.

4.1 USB 최초 연결 흔적

  USB에 관한 흔적의 경우 크게 2가지로 볼 수가 있다. 바로 최초 연결된 시점과 마지막으로 연결된 시점이다. 최초 연결 시 많은 흔적들을 남기지만, 마지막 연결된 시점의 경우 이에 비해 흔적이 많이 적다. 이에 대해 하나 하나 알아보자.

그림 16. USB – Setupapi.dev.log

  %SystemRoot%\INF\Setupapi.dev.log는 대표적으로 최초 연결 흔적이 남는 항목이다. 어떠한 USB가 최초로 연결될 경우 위의 그림과 같은 항목들이 형성된다. 하지만 log 파일에 많은 내용이 저장되면 이전의 내용들이 지워진다는 것을 잊으면 안된다.

그림 17. USB – Registry [Portable Devices]

  최초 연결과 관련된 많은 항목들 중 하나만 이야기 더 한다면 위 항목과 같다. 기존의 레지스트리엔 KALI LIVE란 항목이 없지만 USB를 연결한 이후 해당 라벨명이 기록되는 것을 확인할 수가 있다.

  이외에도 최초 연결과 관련되어 많은 흔적들이 존재한다. 만약 본인의 PC에 본인이 사용하지 않는 USB 연결 흔적이 있을 경우 유출에 대하여 더 의심해볼 수 있는 상황이 될 것이다. 하지만 최초 연결은 최초 연결된 시점만 다루기에 마지막 연결 시점이 필요하다.

4.2 USB 마지막 연결 흔적

  본인의 PC에 직장 동료나 친구가 이미 USB를 연결했던 적이 있다면 위의 흔적들은 최초 연결된 시점만을 가리키기에 아무런 소용이 없다. 따라서 이러한 상황에 필요한 것이 바로 마지막 연결 시점이다.

그림 18. USB – Registry

  위 그림은 이전에 연결한 적이 있던 USB를 다시 연결한 것이다. 항목에서 나타내는 것과 같이 항목에는 USB의 VID나 PID등이 기록되어 있다 .따라서 다시 연결한 경우 해당 항목의 마지막 쓰기 시간이 갱신되어 있는 것을 확인할 수가 있다.

  하지만 이러한 방법으로 확인하는 것을 어려움이 따른다. 따라서 간단하게 확인할 수 있는 방법에 대하여 알아보자.

그림 19. USB – Event Log

 이벤트 로그에는 많은 내용들이 기록이 된다. 여기서 우리가 살펴보아야 할 이벤트 항목은 응용프로그램 로그의 Microsoft\Windows\DriverFrameworks-UserMode이다. 해당 로그엔 USB를 연결한 시간과 해제한 시간이 기록되어 간편하게 확인할 수가 있다.

  하지만 해당 로그는 윈도우 7까지만 기본적으로 활성화되며, 윈도우 8부턴 비활성화되어 있기 때문에 활성화 해놓는다면 이후 분석에 있어서도 많은 편의를 가질 수가 있을 것이다.

4.3 USB에서 문서 열람

그림 20. USB – Time

  위 그림은 이후에 분석할 내용을 나타낸 시간이다. 03:13:45 가량에 USB를 연결한 이후부터 연결을 해제한 03:15:16 근처까지의 시간을 나타내는 것이며 이와 관련하여 분석해보자.

그림 21. USB – Connected Time

  USB가 최초 연결이 아니기 때문에 많은 흔적이 남지는 않는다. 하지만 기존의 형성되어 있는 항목들의 몇 가지 값들이 갱신되어 마지막 쓰기 시간이 변화된 것들을 확인할 수가 있다. 이외에도 USB 연결과 관련된 항목은 생략하겠다.

그림 22. Registry - Docx

  이전에 PC에서 문서를 열람했을 때와 마찬가지로 유사하다. 하지만 한 가지 필요 없어진 점이 있다면, 바로 RecentDocs이다. 해당 항목에선 열람된 파일의 경로가 나타나지 않기 때문에 외부에서 실행한 것임을 알 수 없다.

  그에 반해 MS Word의 File MRU 항목에서는 해당 경로까지 나오므로 새로 마운트된 볼륨 F: 에서 문서가 열람된 것임을 확인할 수가 있다.

그림 23. Registry - PDF

  PDF의 경우도 위와 유사하다. RecentDocx에서는 파일의 경로를 알 수가 없지만 Acrobat Reader의 하위 항목인 RecentFile에선 가장 최근에 열람된 항목이 되는 c1에서 파일의 경로까지 확인할 수가 있다.

그림 24. Registy - HWP

  한글파일의 경우도 마찬가지다. HwpFrame 밑에 있는 RecentFile의 값을 통해 가장 최근에 열람된 'file0'의 데이터가 F:\OpenMe.hwp를 가리키고 있는 것을 확인할 수가 있다.

그림 25. Prefetch File

  위는 프리패치 파일의 정보를 나타내는 것으로 각 뷰어들이 실행된 시간을 확인할 수가 있고, 문서의 위치는 로드된 파일 정보에서 'Device Path'를 통해 외부에서 로드가 된 것인지 확인할 수가 있다. 아래의 그림을 보자.

그림 26. Prefetch File (2)

  그림에서 볼 수 있듯이, 기존의 C: 에서 로드된 항목들은 경로가 올바르게 나타나지만 외부에서 로드된 항목은 경로가 제대로 나타나지 않는다. 하지만 Device Path를 통해 볼륨ID가 다른 것을 확인할 수가 있으며, 이를 통해 외부 장치임을 알 수가 있다.

그림 27. Link File

  링크 파일의 경우 바로 해당 파일이 열람된 위치인 F: 가 나타나는 것을 볼 수가 있으며, 이를 통해 쉽게 외부에서 문서가 열람된 것임을 알 수가 있다.

5. 참고

* 블로그, USB를 통한 자료 유출의 흔적

• http://egloos.zum.com/ykei/v/4761463

* 블로그, 개인정보 보호를 위한 USB 장치 사용내역 확인할 수 있는 프로그램

• http://wezard4u.tistory.com/2692

* 블로그, 어떤 사용자가 어떤 파일을 cp 했는지 기록이 남는가

• https://kldp.org/node/48984

* 블로그, USB 연결 흔적 관련 아티팩트

• http://kali-km.tistory.com/entry/Practice-USB-Artifacts