Win32DiskImager로 부팅 가능한 USB 디스크 만들기

요즘 판매되는 노트북들 대부분이 태블릿과 유사하게 경량화를 추구하다 보니 가장 먼저 제거하는 부분이 디비디롬(DVD-ROM) 입니다. 그렇다 보니 윈도우나 리눅스 설치 시디만을 가지고 있는 사람들의 경우에는 어떻게 해야 될지 고민하게 됩니다.

그래서 윈도우 7에서부터는 USB를 부팅이 가능한 디스크로 만들어 윈도우를 설치 할 수 있도록 지원하고 있습니다. 그래서 저 역시 작년 12월에 구입한 노트북이 디비디롬이 제거된 경량화 버전이라, 윈도우 7과 윈도우 8.1을 설치 할 때 USB를 부팅 가능한 디스크로 만들어 노트북에 운영체제를 설치 할 수 있었습니다.

일반적으로 윈도우 7 이후 버전의 ISO 이미지 파일을 가지고 있는 경우에는, 네로(Nero)와 같은 디비디 레코딩 프로그램으로 디비디를 제작하던가 아니면 마이크로소프트에서 제공하는 "Windows 7 USB/DVD download tool"를 설치하여 부팅 가능한 USB 설치 디스크나 디비디로 제작을 할 수가 있습니다.

개인적으로 백트랙(BackTrack) 이후에 칼리(Kali) 리눅스에 관심이 있어, 개인적으로 친분이 있는 여성구씨가 번역한 "Kali Linux 실전 활용 70가지 예제로 익히는 모의침투 테스팅 툴킷 가이드"를 읽다 보니 USB를 부팅 디스크로 만들 수 있는 다른 방법이 있더군요.

해당 서적에서는 "Win32 Disk Imager"라는 공개용 도구를 이용하여 USB를 부팅 가능한 디스크로 제작할 수 있음을 알려주고 있습니다.

Win32DiskImager를 이용해 부팅 가능한 USB 디스크(FAT32 및 8 GB 이상)를 제작하기 위해서는 아래 이미지와 같이 Win32DiskImager를 실행 후 가지고 있는 ISO 파일 이미지를 선택 합니다.

그리고, "Device" 부분에서 현재 시스템에 연결되어 있는 USB 디스크의 드라이브를 지정해준 후, 하단에 위치한 "Write"를 클릭 합니다. 그렇다면 실제 USB 디스크에 ISO 이미지 파일의 내용을 쓰기 시작합니다.

USB 디스크에 쓰기가 완료되었다면, 아래 이미지와 같이 완료 메시지 창이 생성 되며, 사용하는 시스템의 BIOS에서 USB 부팅 기능이 지원된다면, 생성한 USB 디스크를 이용해 운영체제를 설치 할 수가 있습니다.

해당 Win32DiskImager로 부팅 가능한 USB 디스크를 만들면서 한 가지 재미 있는 사실을 알 수가 있었습니다.

백트랙, 칼리 및 우분투(Ubuntu)와 같은 리눅스 운영체제의 ISO 이미지 파일들은 해당 툴을 이용해 쉽게 부팅 가능한 USB 디스크를 생성 할 수가 있습니다. 하지만, 윈도우 운영체제의 ISO 이미지 파일의 경우에는 해당 툴을 이용해 부팅 가능한 USB 디스크를 만들 수가 없었습니다.

반대로 마이크로소프트에서 제공하는 Windows 7 USB/DVD download tool을 사용하는 경우에는 윈도우 운영체제의 ISO 이미지 파일을 이용해 쉽게 부팅 가능한 USB 디스크를 만들 수 있으나, 리눅스 운영체제의 ISO 이미지 파일들로 만들 수가 없었습니다.

이러한 결과가 나온 것에 대한 추정으로 파일 시스템(File System)의 구조가 서로 달라 이러한 현상이 나온 것이 아닌가 생각 됩니다.

결론적으로, 윈도우 운영체제가 대상이 되는 경우에는 Windows 7 USB/DVD download tool을 사용하고, 리눅스 운영체제가 대상이 되는 경우에는 Win32DiskImager을 사용하는 것이 좋을 것 같습니다.

RemoteDLL을 이용한 실행 압축된 DLL 파일 분석

악성코드를 분석 하다보면 다양한 형태의 파일들을 마주치게 됩니다. 그 중에는 PE 파일 형태인 EXE, DLL와 SYS에서부터 스크립트(Script) 그리고 마이크로소프트(Microsoft) 오피스(Office)와 어도비 리더(Adobe Reader) 문서 파일까지 다양한 파일 형태들을 마주치게 됩니다.

분석 당시에 접하게 되는 다양한 파일 형태의 악성코드들을 살펴보면, 그 시대 상황에 맞는 악성코드 형태가 어떠한 것들인지 비교적 쉽게 알 수가 있습니다.

과거 제가 처음으로 악성코드 분석 업무를 시작하던 시기에는 악성코드 감염을 위한 테스트 시스템이 윈도우 98(Windows 98)을 사용했던 시기였으며, 악성코드들 역시 대부분이 EXE, COM과 PIF 파일 형태 였기 때문입니다.

하지만 시간이 지나면서 다양한 파일 형태의 악성코드들이 발견되기 시작하였고, 악성코드 제작자들 역시 악성코드 자기 보호를 위한 목적으로, 보안 업체의 분석 시간을 지연시키고 안티 바이러스 소프트웨어(Anti-Virus Software)의 탐지를 우회하기 위해 실행 압축(Packer)와 프로텍터(Protector)를 사용하기 시작하였습니다.

이러한 실행 압축 및 프로텍터 프로그램들은 악성코드 분석가 입장에서는 비교적 피곤하게 만드는 여러가지 요소들 중 하나입니다.

악성코드 분석가 입장에서는 분석을 맡게 된 파일들을 비교적 빠르게 악성코드 인지 아니면 정상 파일인지 판단하고, 진단을 위한 적절한 진단 기법을 선정하는 작업들을 진행해야 됩니다. 하지만, 실행 압축과 프로텍터로 제작된 파일들에 대한 분석을 맡게 되면 실행 압축을 모두 풀려면 시간 소요가 크기 때문에 분석 진행 속도가 늦어지게 되는 것을 고려하지 않을 수가 없습니다. 특히나, 분석을 맡게 된 파일이 특정 이슈가 존재하는 파일이라면 분석가 입장에서는 시간적인 압박을 받을 수 밖에 없습니다.

실행 압축과 프로텍터로 보호된 파일이라도 EXE 처럼 실행 가능한 파일이라면 동적 분석(Dynamic Analysis)를 통해 악의적인 기능이나 증상이 나타나면 그나마 비교적 쉽게 분석을 할 수 있지만, DLL 파일이 실행 압축이나 프로텍터로 보호된 파일이라면 고민이 되기 시작합니다.

그래서, 오늘 이야기 할 부분이 바로 실행 압축된 DLL(Dynamic Link Libraries) 파일에 대해 비교적 쉽고 빠르게 분석 할 수 있는 방법  입니다. PE 파일의 실행 압축 여부를 판단하는 기법들은 몇 가지가 있지만, 이는 다음 기회에 다루기로 하고 오늘은 실행 압축된 DLL 파일에 대한 이야기만 하려고 합니다. :)

개인적으로 좋아하는 악성코드 분석 관련 서적 중 하나인 "실전 악성코드와 멀웨어 분석 Practical Malware Analysis" 에서는 Rundll32.exe를 이용해 DLL 파일을 동적 분석 할 것을 알려주고 있습니다.

개인적인 경험으로 대부분의 DLL 파일을 동적 분석 할 때 Rundll32.exe가 요긴하지만, 일부 DLL 파일에 대해서는 해당 방법으로 분석이 가능한 것은 아닙니다. 그리고, DLL 파일을 분석 할 때 마다 커맨드라인(CommandLine) 명령을 입력하는 것은 여간 귀찮은 것이 아닙니다.

그래서, 실행 압축된 DLL 파일을 분석 할 때는 SecurityXploded에서 배포하는 "RemoteDLL"을 사용해, 분석 대상되는 DLL 파일을 특정 프로세스에 강제로 인젝션(Injection) 시킨 후 해당 DLL 파일에 대한 메모리 덤프(Memory Dump)를 생성하여 스트링(String)을 살펴본다면 비교적 빠르게 악의적인 기능 여부를 확인 할 수 있습니다.

우선 RemoteDLL의 외형을 살펴보면 기본적인 GUI는 아래 이미지와 같이 직관적으로 쉽게 사용 할 수 있게 되어 있습니다.

상단의 붉은 색 박스를 살펴보면, RemoteDLL의 기능은 2가지로, 특정 DLL 파일을 강제로 인젝션시키거나 이와 반대로 인젝션 되어 있거나 스레드(Thread)로 로딩되어 있는 DLL 파일을 풀기 위해 사용 할 수 있습니다.

그리고 아래 이미지의 붉은 색 박스와 같이 그 하단에는 선택한 DLL 파일을 어떠한 방식으로 인젝션 할 것인지 사용자가 선택 할 수 있습니다.

VMWare에 존재하는 윈도우 XP 32Bit 운영체제의 RemoteDLL은 선택 할 수 있는 인젝션 기법이 "CreateRemoteThread"와 "QueueUseAPC" 2개만이 존재 합니다. 하지만 64Bit 운영체제에서는 위 2개의 기법 외에도 "NtCreateThreadEx"를 추가로 선택 할 수 있습니다.

그리고, 그 하단에 윈치하는 윈도우 아이콘은 현재 RemoteDLL이 실행 중인 시스템에서 실행 중인 프로세스(Process) 리스트들이 나열 됩니다. 이는 현재 실행 중인 프로세스들 중 인젝션 대상이 되는 프로세스를 사용자가 임의로 선택 할 수 있습니다.

아래 이미지에 존재하는 붉은 색 박스에는 인젝션을 시킬 DLL 파일을 선택 할 수 가 있습니다. 다만 인젝션 시킬 DLL 파일의 확장자가 반드시 .dll로 정의되어 있어야 하며, 그렇지 않을 경우에는 인젝션 기능이 정상적으로 동작하지 않습니다.

인젝션 대상이 될 프로세스와 인젝션 시킬 DLL 파일이 모두 선택 되었다면, 하단에 존재하는 "Inject DLL" 버튼을 클릭하기만 하면 됩니다.

그렇다면 실제 실행 압축된 DLL 파일을 이용해 특정 프로세스에 인젝션 한 후 인젝션 된 DLL 파일의 메모리 덤프를 생성하여, 문자열 정보를 확인하는 과정을 살펴 보도록 하겠습니다.

테스트를 위해 "실전 악성코드와 멀웨어 분석 Practical Malware Analysis" 1장에서 제공하는 예제 DLL 파일을 UPX로 실행 압축하였습니다.

그리고, RemoteDLL을 실행 시킨 후 인젝션 대상이 될 프로세스를 위해 더미(Dummy) 프로그램으로 PEiD를 실행 합니다. 당연히 개인적인 취향에 따라 다른 프로그램을 실행 시켜도 무방합니다. 그리고 인젝션 된 DLL 파일의 메모리 덤프를 생성하기 위해 PETools를 실행 합니다. 이 역시 스레드 메모리 덤프를 생성 할 수 있는 다른 툴을 사용하여도 무방합니다.

이제 준비가 되었다면, 아래 이미지와 같이 "CreateRemoteThread" 를 선택 한 후에 앞서 설명한 바와 같이 인젝션 대상이 되는 프로세스인 PEiD를 선택 합니다. 인젝션 기법 중 "CreateRemoteThread" 을 선택한 이유는 개인적인 경험 상 가장 무난하게 인젝션이 성공하기 때문입니다.

인젝션 기법까지 모두 선택하였다면, 이제는 인젝션 시킬 DLL 파일을 선택 합니다.

모두 준비가 되었다면, 이제는 하단에 존재하는 "Inject DLL"을 클릭하여 인젝션 작업을 진행 합니다. 인젝션이 성공하게 되면, 아래 이미지와 같이 인젝션이 성공하였다는 로그가 남게 됩니다.

인젝션이 성공하게 되면 최초 실행하였던 PETools에서 아래 이미지와 같이 인젝션 대상이 되었던 PEiD 프로세스를 클릭 한 후 하단의 스레드 리스트 중 인젝션 시킬 DLL 파일을 선택 합니다. 그리고 오른쪽 마우스를 클릭하여 "Dump Full"을 클릭하여 적절한 위치에 메모리 덤프 파일을 생성 합니다.

그 이후에는 파일 내부의 스트링을 확인 할 수 있는 "BinText"와 같은 툴을 이용하여 DLL 파일 내부의 스트링을 확인 할 수 있습니다. 다만, 메모리 덤프를 통해 생성한 DLL 파일임으로 IAT(Import Address Table)이 손상되었음을 참고 할 필요는 있습니다.

이렇게 RemoteDLL을 이용해 실행 압축이나 프로텍트로 보호 된 DLL 파일에 대해 비교적 쉽고 빠르게 내부에 존재하는 스트링 확인을 통해, 악의적인 기능이 존재하는지 살펴볼 수 있습니다.

디지털 포렌식(Digital Forensics)을 위한 운영체제, SANS SIFT 3.0 공개

일반적으로 디지털 포렌식을 위해서는 분석가의 능력이나 취향에 맞는 다양한 소프트웨어들을 많이 사용합니다. 윈도우 엔지니어인 저의 경우에는 악성코드 분석이나 멀웨어 포렌식(Malware Forensics)을 위해 사용하는 소프트웨어들 대부분이 마이크로소프트(Microsoft)의 윈도우(Windows) 운영체제에서 사용 가능한 것들 입니다.

그래서 일전에 공개한 "메모리 포렌식(Memory Forensic)을 위한 메모리 분석 툴 Mandiant Redline"이나 "볼라틸리티(Volatility)를 이용한 메모리 분석 사례" 블로그 글에서와 같이 윈도우 소프트웨어들이 주를 이루고 있습니다. 물론 그 중에는 백트랙(BackTrack)을 일부 사용하기도 하였지만, 이는 개인적인 연구 작업과 리눅스(Linux)를 익히기 위한 개인적인 취향으로 인한 부분들입니다.

악성코드 분석에서도 역시 "Windows 7에서 Windows XP Mode를 VMWare에 설치 하기" 블로그 글에서와 같이 윈도우 운영체제에 VMWare를 설치하여 분석 작업과 연구를하고 있습니다.

이렇듯 대부분의 악성코드나 취약점 그리고 디지털 포렌식 등을 전문으로 연구 하시는 분들은 특정 운영체제에 제한 받기 보다는 개인적으로 사용하기 편하고 작업 효율이 높은 운영체제를 선택해 사용하고 있습니다.

하지만 특이하게도, 전문적인 보안 대응 및 분석 기술을 강연하는 SANS에서는 별도의 리눅스 기반 운영체제를 제작하여 누구나 사용할 수 있도록 배포하고 있습니다. 그 중에는 악성코드 분석을 위해 제작된 "REMux(Reversing Engineering Malware liux)"와 디지털 포렌식을 위해 제작된 "SIFT(SANS Investigate Forensic Toolkit )"이 존재합니다. 

그래서 SANS에서 교육하는 악성코드 분석 과목과 디지털 포렌식 과목에서는 해당 운영체제를 사용해 분석을 진행하는 내용이 교재에 포함되어 있습니다. 그 중에서 REMux에 대한 이야기는 다음 기회에 실제 악성코드 분석 사례를 이용해 설명하기로 하고 오늘은 SIFT에 대해 이야기 하고자 합니다.

오늘 SANS 블로그 "SANS SIFT 3.0 Virtual Machine Released"을 통해 새로운 3,0 버전의 SIFT 가상화 이미지가 공개되었다는 글을 보게 되었습니다. 우선 이번 3.0 버전의 새로운 기능들로 SANS에서는 다음을 꼽고 있습니다.

Ubuntu LTS 12.04 Base

64 bit base system

Better memory utilization

Auto-DFIR package update and customizations

Latest forensic tools and techniques

VMware Appliance ready to tackle forensics

Cross compatibility between Linux and Windows

Option to install stand-alone via (.iso) or use via VMware Player/Workstation

Online Documentation Project

Expanded Filesystem Support

우선, SIFT 3.0 가상화 이미지를 다운로드 하기 위해서는 위 블로그에 존재하는 링크인 "Download SIFT Workstation VMware Appliance Now - 1.5 GB"를 통해 다운로드 할 수 있습니다. 

다운로드 전에 SANS 계정이 필요한데, 이는 누구나 간단한 정보 입력만으로 만들 수 있습니다. 그 이후에는 간단하게 SIFT 3.0 가상화 이미지를 7Zip으로 압축한 "SIFT Workstation 3.0.7z" 1.44 GB 크기의 파일을 다운로드 할 수 있습니다. 100 MB 광랜을 사용하는 집에서 다운로드하는데 대략 3시간 정도 걸렸던 것 같습니다.

다운로드 한 "SIFT Workstation 3.0.7z" 파일을 적당한 폴더에 압축을 풀고 VMWare를 실행 한 후 아래 이미지와 같이 "File"에서 "Open"을 클릭 합니다.

그리고, "SIFT Workstation 3.0.7z" 압축을 푼 폴더로 이동하여 아래 이미지와 같이 "SIFT Workstation 3.0.vmx" 을 선택 합니다.

선택이 완료되면 VMWare에서는 아래 이미지와 같이 자동으로 새로운 게스트 탭(Guest Tab)을 생성하게 됩니다.

게스트 탭 생성이 완료되었다면 VMWare의 실행(Power On)을 클릭하여 SIFT 3.0 가상화 이미지를 실행 시킵니다. 부팅 과정이 짧게 진행 된 후에는 아래 이미지와 같이 변경된 새로운 SIFT 3.0 로그인 화면이 나타나게 됩니다.

로그인 화면이 나타났다면, SANS 블로그에 공개되어 있는 것과 같이 "sansforensics"의 비밀번호인 "forensics"을 입력하고 로그인을 합니다. 

로그인이 성공하게 되면 아래 이미지와 같이 터미널 창이 생성되어 있는 메인 화면을 볼 수가 있습니다. 사용하는 노트북 화면이 16:9 크기를 지원하는 사양이라 아래 이미지 역시 조금 길어져 보입니다.

앞서 설명한 바와 같이 우분투(Ubuntu) LTS 12.04 커널을 기본으로 하여 SIFT 3.0을 제작하였음으로, 이미 우분투 리눅스에 대한 경험이 있으신 분들은 비교적 빠르게 적응 하실 수 있을 것으로 보입니다.

우선 바탕화면을 살펴보면 총 8개의 PDF 파일이 존재하는데, SANS DFIR(Digital Forensics & Incident Response) 강의 소개와 관련된 PDF 파일인 "Brochure_SANSDFIR.pdf"와 "Poster_Fall_2013_Evidence_Of.pdf"가 있으며, SIFT 3.0을 활용하기 위한 가이드 문서인 "SIFT-Cheat-Sheet.pdf"가 있습니다. 

그 외에 윈도우와 리눅스 명령어를 담은 "windows-to-unix-cheatsheet.pdf", 침해 사고 현장에서 수집해야 될 로그들과 절차에 대한 "log2timeline-cheatsheet.pdf", 네트워크 포렌식을 위한 "network-forensics-cheatsheet.pdf" 그리고 메모리 포렌식을 위한 "Memory Forensics Cheat Sheet .pdf"과 함께 악성코드를 탐지하기 위한 방법론에 대해 다룬 "Memory Forensics Cheat Sheet .pdf"이 있습니다.

간단한게 살펴본 SIFT 3.0은 외형은 이러한 형태이며, 이제는 SIFT 3.0에 포함된 볼라틸리티(Volatility)와 DFF(Digital Forensics Framework)를 간단하게 살펴 보도록 하겠습니다.

우선 화면 왼쪽 상단에 포함된 터미널 아이콘을 클릭하면 아래 이미지와 같이 프롬프트가 생성됩니다. 여기서 간단하게 볼라틸리티의 약어인 "vol"과 도움말 명령인 "-h"을 이용해 SIFT 3.0에 포함된 볼라틸리티의 버전은 2.3.1 임을 알 수가 있습니다.

SIFT 3.0에는 기본적으로 DFF(Digital Forensics Framework)라는 포렌식 프레임워크가 포함되어 있습니다. DFF는 아래 이미지와 같이 왼편 하단에 아이콘이 존재하며 해당 아이콘을 클릭하면 DFF가 실행 됩니다. 

실행 후에는 생성한 메모리 덤프(Memory Dump) 파일과 디스크 이미지(Disk Image) 파일들을 읽어들여서 분석을 진행 할 수 있습니다. 

이상으로 SIFT 3.0에 대해 기본적인 사항들에 대해 살펴 보았습니다. 기본적으로 SIFT 3.0에는 다양한 디지털 포렌식 툴들이 포함되어 있으나, 우분투 리눅스를 이용하다 보니 저와 같이 리눅스에 익숙하지 않은 분들은 사용에 어려운 부분들은 있습니다. 

그래서, 일부 디지털 포렌식 커뮤니티에서는 "WinFE(Windows Forensic Environment)"라는 윈도우 기반의 포렌식 운영체제 제작 방법들을 소개하기도 합니다. WinFE와 관련된 사항들은 다음 기회에 다루어 보기로 하겠습니다.

Windows 7에서 Windows XP Mode를 VMWare에 설치 하기

악성코드를 분석 할 때 가상화 환경을 지원해주는 소프트웨어인 VMWare나 VirtualBox가 중요한 부분을 차지합니다. 특히 악성코드에 대한 동적 분석(Dynamic Analysis)를 진행 한 후에 감염된 윈도우 환경을 다시 빠르게 감염 이전의 초기 상태로 복원 시켜줌으로 분석 전반에 걸쳐 분석 시간을 단축 시켜주는 장점이 존재 합니다.

2002년 처음으로 악성코드 분석 업무를 담당할 때에는 이러한 가상화 소프트웨어가 없어 실제 윈도우 시스템에 노턴 고스트(Norton Ghost)를 설치하여 초기 이미지를 생성한 후 악성코드의 동적 분석을 진행 한 후 다시 초기 이미지로 복원하는 작업을 반복 하였습니다. 이러한 과정은 가상화 소프트웨어에 비해 상대적으로 시간 소요도 많을 뿐만 아니라 새로운 분석 툴을 설치하는 경우에는 다시 초기 이미지를 생성해야 되는 번거로움도 존재하였습니다.

그 이후에는 노턴 고백(Norton GoBack)으로 초기 이미지가 아닌 감염되기 이전 시점으로 복원을 하기도 하였습니다만, 아무래도 소프트웨어다 보니 악성코드 감염으로 인해 정상적으로 복원이 되지 않는 경우도 발생 하였습니다.

이렇게 편리한 가상화 환경이 악성코드 분석과 자동 분석에 많이 쓰여진다는 것이 알려진 이후에는 악성코드의 감염 환경이 가상화 인지 확인하는 코드들이 악성코드에 추가되기 시작하였습니다. 그래서 현재에는 실제 윈도우 시스템과 VMWare에 생성한 가상 윈도우 시스템 환경 이렇게 2개를 번갈아 가며 악성코드 분석에 사용하고 있습니다. 하지만, 대부분의 악성코드 분석 작업은 VMWare에 존재하는 가상 윈도우 시스템 환경을 이용하고 있습니다.

그래서 작년 12월 새롭게 노트북을 구매 한 이후 악성코드 분석 환경을 구축하기 위해 VMWare에 어떻게 윈도우 XP 환경을 설치할까 고민하는 과정에서 구글 검색을 통해 "Using Free Windows XP Mode as a VMware Virtual Machine"라는 좋은 블로그를 찾을 수 있었습니다.

Windows XP Mode는 윈도우 7 운영체제가 하위호환을 유지하기 위해 마이크로소프트(Microsoft)에서 별도의 윈도우 XP SP3 가상화 환경을 제공 해주는 것입니다만, 모든 윈도우 7 버전에서 설치가 가능한 것은 아니고 Professional, Ultimate와 Enterprise 이 3가지 버전에 한해서만 가능 합니다.

사용하는 환경이 윈도우 7이고 위 3가지 버전 중 하나라면 Windows XP Mode에서 정품 인증을 받은 후 WindowsXPMode_ko-kr.exe(558.4 MB), WindowsXPMode_K_ko-kr.exe(558.4 MB) 또는 WindowsXPMode_KN_ko-kr.exe(534.4 MB) 중 하나를 다운로드 할 수 있습니다.

다운로드 한 Windows XP Mode 설치를 완료하였다면, 이제는 VMWare를 실행 한 후 아래 이미지와 같이 VMWare의 "File" 메뉴에서 "Import Windows XP Mode VM"를 클릭 합니다.

그 후 VMware에서 아래 이미지와 같이 "VMWare vCenter Converter Standalone"이 필요하다는 팝업창을 보여주는데, "Yes"를 클릭하여 설치를 진행 합니다.

"VMWare vCenter Converter Standalone" 설치가 완료되었다면, 바탕화면에는 아래 이미지와 같이 "VMWare vCenter Converter Standalone Client"가 생성됩니다.

그렇다면 이제 다시 VMWare의 "File" 메뉴에서 "Import Windows XP Mode VM"를 클릭 하면, 아래 이미지와 같이 VMWare에 생성할 새로운 가상 환경의 명칭과 설치 경로를 지정 하는 팝업창이 생성됩니다.

여기에서 "Import"를 클릭하면 Windows XP Mode가 VMWare에 의해 변환이 진행되기 시작합니다.

변환 작업이 완료되면 아래 이미지와 같이 VMWare의 새로운 탭으로 "Windows XP Mode"가 생성된 것을 볼 수 있습니다.

새로 생성된 "Windows XP Mode" 탭의 가상 윈도우 환경을 실행하면, 이후에는 일반적으로 VMWare에 윈도우 XP 설치 CD를 이용하여 설치하는 과정과 동일하게 진행 됩니다. 다만 조금 다른 부분이 있다면, 라이센스에 필요한 CD-Key를 입력하는 단계가 없다는 것 정도 입니다.

설치 이후 특이점으로는 VirtualBox에서도 사용 가능한 OVF(Open Virtualization Format)으로 내보내기(Export)가 되지 않으며, Windows XP Mode가 설치되어 있지 않은 다른 윈도우 시스템의 VMWare에서는 설치 경로에 존재하는 "Windows XP Mode.vmx" 파일과 나머지 데이터 파일들을 읽어 올 수가 없다는 것 입니다.

이러한 사항들은 윈도우 라이센스와 관련된 사항이 아닌가 생각됩니다. 그래서 최초 윈도우 8.1 환경에서 Windows XP Mode를 VMWare에 설치하는 방법 역시 같이 다루고자 하였으나, 라이센스 문제가 있을 것 같아 다루지 않기로 하였습니다.

scdbg를 이용한 셸코드(ShellCode) 분석 방안

며칠 전 여느 때와 다름없이 아침 출근 길에 간밤에 일어난 상황들을 주욱 살펴보고 있었습니다. 그런데 그 중 미국 보안 업체인 Zscaler에서 작성한 "Probing into the Flash Zero Day Exploit (CVE-2014-0502)" 블로그 글이 눈에 들어오던군요.

어도비(Adobe) 플래쉬 플레이어(Flahs Player)의 새로운 제로 데이(Zero Day) 취약점이 발견되고 이슈화 되었으며, 그에 따른 분석 내용을 다루고 있는 내용이었습니다.

사실 제로 데이 취약점들이 하루가 멀다하고 발견되다 보니 예전 만큼 호기심을 자극하는 것 은 없는 것 같습니다.

새로운 플래쉬 플레이어의 제로데이 취약점을 다룬 Zscaler 블로그 중에서 특히나 눈에 띄었던 부분은 아래 이미지입니다.

위 이미지는 scdbg라는 셸코드(ShellCode) 분석을 위한 도구인데, Zscaler에서는 플래쉬 파일(.swf) 파일에서 셸코드를 추출 한 후 scdbg를 이용해 분석한 결과를 보여준 것 입니다.

scdbg는 셸코드를 분석하기에는 아주 유용하고 편리한 도구이며, libemu라는 x86 Shellcode Emulation을 이용해서 셸코드를 에뮬레이션(Emulation) 해주므로 셸코드를 포함한 악성코드를 분석할 때 발생하는 여러가지 번거로움을 줄여주기도 합니다

일반적으로 셸코드는 위키피디아(Wikipedia)에서 정의해놓은 바와 같이 "In computer security, a shellcode is a small piece of code used as the payload in the exploitation of a software vulnerability." 입니다.

즉, 셸코드는 실행코드에 대한 페이로드로 동작하는 작은 코드 덩어리 입니다. 그래서 실제 셸코드는 아래 이미지와 같이 데이터 덩어리들입니다.

셸코드에 대한 내용들은 "The Shellcoder's Handbook: Discovering and Exploiting Security Holes"라는 책 한 권으로 다룰 정도 방대합니다.

이러한 셸코드라는 데이터 덩어리를 분석하기 위해 다양한 방법들이 사용되지만 그 중에서 간편하게 셸코드를 분석 할 수 있는 방법 중 하나가 바로 scdbg 입니다.

scdbg는 "scdbg download"에서 "Windows Native Source/Binaries"라고 표기 되어 있는 "Win32 Binaries"를 클릭하면 약 0.9 MB 크기의 scdbg.zip 파일을 하나 다운로드 할 수 있습니다.

해당 파일의 압축을 풀게 되면 2개의 실행 파일과 1개의 메뉴얼 파일이 나오는데, 그 중 gui_launcher.exe 파일은 윈도우에서 GUI 모드로 실행 가능하도록 해줍니다. 나머지 scdbg.exe는 커맨드라인(CommandLine) 명령으로 사용 할 수 있습니다.

gui_launcher.exe를 실행하고 아래 그림과 같이 "실전 악성코드와 멀웨어 분석 Practical Malware Analysis"에서 제공하는 예제 셸코드 파일을 드래그앤드롭으로 끌어다 놓습니다.

그 후에 Launch를 실행하면 아래 그림과 같이 셸코드를 에뮬레이션 한 결과가 별도의 커맨드라인 창으로 나타나게 됩니다.

위 그림의 붉은색 박스 안의 코드를 살펴보게 되면 예제로 사용한 셸코드는 다음과 같은 코드를 수행하도록 제작되어 있는 것을 알 수 있습니다.

우선, GetSystemDirectoryA 함수를 이용해 시스템의 시스템 디렉토리 위치를 얻어 온 후 URLDownloadToFileA 함수를 이용해서 특정 웹 사이트에서 "annoy_user.exe"를 윈도우 시스템 디렉토리에 "1.exe" 파일명으로 다운로드 하게 됩니다. 그리고 다운로드 한 파일을 WinExec 함수를 이용해서 실행하게 됩니다.

scdbg의 결과를 검증하기 위해 이제는 일반적으로 많이 사용하는 "Shellcode 2 EXE"에 셸코드를 업로드 한 후 EXE 파일로 만들어 Ollydbg를 이용해 디버깅을 해보았습니다. 이 과정에서도 역시 위 그림에서 보았던 동일한 코드들이 존재하는 것을 확인 할 수 있습니다.

앞서 살펴본 것 처럼 scdbg는 간편하게 셸코드를 분석 할 수 있도록 해주는 도구입니다. 그래서 비교적 간단한 포트 바인딩(Port Binding)이나 파일 다운로드 관련 셸코드는 에물레이션이 가능합니다만, 모든 셸코드를 충분히 분석이 가능하도록 지원하는 것은 아님으로 "Distorm Powerful Disassembler Library For x86/AMD64"와 같이 다르게 분석 할 수 있는 기법들 역시 파악하고 있는 것도 중요 합니다.

다음에는 시간적인 여유가 있을 때 실제 취약점이 존재하는 PDF와 DOC 같은 전자문서 파일에서 셸코드를 추출하여 scdbg와 Kali Linux를 이용한 분석 방안에 대해서도 다루어 보도록 하겠습니다.

자바(Java) 바이트코드(Bytecode) 디버깅(Debugging)

며칠 전 출근 길에 흥미로운 블로그 내용을 읽게 되었습니다. 제가 읽는 블로그 내용들이 대부분 새로운 악성코드 분석 정보나 이와 관련된 분석 기법들을 다루는 내용들이 대부분인데, 며칠 전 흥미롭게 읽은 블로그는 미국 보안 업체인 Crowdstrike에서 작성한 “Native Java Bytecode Debugging without Source Code” 입니다.

최근 몇 년 사이에 외국도 마찬가지이지만 한국에서도 역시 Gongda Web Exploit Toolkit에서 자바(Java)에 존재하는 여러 가지 취약점들을 악용하여 다른 악성코드를 드라이브 바이 다운로드(Drive By Download)으로 감염시키는 기법들이 많이 사용되고 있습니다. 그래서, 저 역시 취약점이 존재하는 자바 파일 형식인 JAR 파일들을 자주 접하게 됩니다.

일반적으로 자바에서 사용하는 JAR 파일 형식은 압축 파일 형식인 PKZip과 동일한 형태를 가지고 있어, 헥사 에디터(Hex Editor)로 JAR 파일을 살펴 보게 되면 다음과 같은 구조를 가지고 있습니다.

위 헥사 코드를 보면 파일 오프셋(Offset) 0h의 첫 번째 두 바이트(Byte)가 PKzip으로 압축된 파일과 동일한 시그니처(Signature)을 가지고 있고, 매니패스트(MANIFEST) 역시 정의되어 있는 것을 볼 수가 있습니다. 하지만, 경우에 따라 특정 JAR 파일의 경우에는 아래 헥사 코드처럼 매니패스트 없이 바로 클래스(Class) 파일명이 정의되어 있는 것도 볼 수가 있습니다.

그래서, JAR 파일은 7Zip과 같은 범용 압축 라이브러리(library)를 사용하는 압축 프로그램으로 압축을 풀 수 있으며, 파일이 손상되지 않은 경우에는 아래 이미지와 같이 내부에 포함되어 있는 클래스 파일을 볼 수가 있습니다.

압축 파일 형태를 가지는 JAR 파일에 대해 대부분의 안티 바이러스(Anti-Virus) 소프트웨어에서는 JAR 파일의 압축을 풀고 내부에 존재하는 클래스 파일에 존재하는 익스플로잇(Exploit) 코드들을 이용해 진단 합니다.

일반적으로 JAR 파일을 분석은 자바 디컴파일러(Java Decomplier)를 이용해 아래 이미지와 같이 JAR 파일 구조와 내부 클래스 파일들에 포함되어 있는 디컴파일된 코드들을 살펴볼 수가 있습니다.

자바 디컴파일러를 이용하는 경우에는 위 이미지에 존재하는 붉은 색 박스의 클래스 박스를 확장하면 내부 코드들을 확인 할 수가 있습니다. 그래서 비교적 간단한 JAR 파일들의 경우에는 자바 디컴파일러를 이용하여, 아래 이미지와 같이 클래스 파일의 코드들에 존재하는 악의적인 코드를 읽어 볼 수 있습니다.

이러한 방식은 일반적으로 비교적 간단한 JAR 파일을 디컴파일하여 볼 수 있는 방법이지만, 실제 코드를 디버깅하면서 볼 수 없기 때문에 실제 악의적인 코드의 흐름을 자세히 파악하기 어려운 부분이 있습니다.

그런데, 앞서 언급한 Crowdstrike 블로그에서는 몇 가지 프로그램들을 설치하여, JAR 파일을 디버깅(Debugging) 할 수 있는 방안을 설명하고 있습니다. 그래서 해당 업체에서 설명한 방안으로 실제 JAR 파일을 디버깅 가능한지 확인 해보았습니다.

우선 JAR 파일을 디버깅하기 위해서는 2개의 소프트웨어를 별도로 설치를 하여야 됩니다. 우선, 오라클(Oracle)에서 제공하는 자바 개발 도구(Java SE Development Kit 7)를 설치하여야 됩니다. 설치하고자 하는 버전은 오라클에서 항상 최신 버전을 제공해주고 있음으로 운영체제에 맞는 버전만 설치하면 됩니다.

자바 개발 도구(Java SE Development Kit 7) 설치가 완료되면, 두 번째로 필요한 소프트웨어는 자바 개발자용 이클립스 IDE(Eclipse IDE for Java Developers)가 필요 합니다. 이클립스의 경우에는 파일 설치 없이 압축 파일 다운로드 이후 내부에 존재하는 실행 파일 클릭만으로 바로 사용이 가능합니다.

JAR 파일을 분석하기 위해서는 추가적으로 이클립스 마켓플레이스(Eclipse Marketplace)에서 “Dr.Garbage’s Bytecode Visualizer” 프로그램을 하나 더 설치하여야 됩니다. 그러므로, 이클립스 마켓플레이스에서 검색을 통해 최신 버전인 “Bytecode Visualizer 4.3.5” 최신 버전을 설치 합니다.

“Bytecode Visualizer 4.3.5”가 설치 완료되면 자바 개발자용 이클립스 IDE가 재시작을 하면 이제 JAR 파일을 디버깅 할 수 있는 환경은 모두 완료되었다고 생각하시면 됩니다.

이제 실제 취약한 JAR 파일을 자바 개발자용 이클립스 IDE에서 읽어 들이기 위해 새로운 자바 프로젝트(Java Project)를 하나 생성합니다.

새로운 자바 프로젝트는 아래 이미지와 같이 간단하게 새로운 자바 프로젝트의 명칭만을 정의 해주고 다음을 클릭합니다.

여기에서 아래 이미지와 같이 새로운 자바 프로젝트의 환경 설정들이 나타나게 됩니다. 여기에서 상단의 “Libraries” 탭을 선택 한 후, 디버깅을 하고자 하는 취약한 JAR 파일을 지정해주기 위해 “Add External JARs”를 클릭합니다. 그리고 준비 한 취약한 JAR 파일을 선택 합니다.

준비한 취약한 JAR 파일을 새로운 프로젝트에서 읽어 들이게 되면 자바 디컴파일러에서 보아왔던 것과 동일하게 JAR 파일의 구조가 전부 보이게 됩니다. 여기에서 JAR 파일 내부에 존재하는 클래스 파일을 선택 한 후 오른쪽 마우스를 클릭하여 “Open with Bytecode Visualizer”를 선택 합니다.

해당 클래스 파일을 “Bytecode Visualizer”에서 읽어 들이게 되면 아래 이미지와 같은 코드들이 나타나며, IDA에서와 같이 전체 코드 플로우(Code Flow)와 함께 코드들이 나타나게 됩니다.

여기에서 코드 시작 부분을 오른쪽 마우스로 클릭하여 브레이크포인트(BreakPoint)를 설정한 후에 디버깅을 진행 할 준비를 합니다.

코드 시작 부분에 브레이크포인트 설정을 완료 했다면, 다시 클래스 파일에서 오른쪽 마우스를 클릭하여 나타나는 항목 중 “Debug As”를 선택 한 후 “Java Application”을 클릭해야 됩니다.

그런데, 제가 준비한 취약한 JAR 파일의 클래스 파일에서는 이상하게도 디버그 설정에 “Java Application”이 나타나지 않았습니다.

무언가 설정이 잘못되거나 준비한 JAR 파일에 문제가 있는지 구글(Google) 검색을 통해 확인 해보니 디버깅을 위한 JAR 파일 내부의 클래스 파일에 메인 코드 시작 부분이 존재해야 되었습니다.

즉, 윈도우(Windwos) PE 파일이 WinMain에서 시작하듯이 JAR 파일의 클래스 파일에서도 메인 코드(Main Code) 시작 부분이 존재하는데, 제가 준비한 JAR 파일에는 해당 메인 코드가 존재하지 않았기 때문에 디버그 설정에 “Java Application”이 나타나지 않았던 것으로 보입니다. 그래서 최근에 발견된 악의적인 JAR 파일들을 확인 해보니 모두 메인 코드가 존재하지 않는 샘플들이었습니다.

하지만, 이 부분은 조금 더 조사와 연구를 해보고 가능한 방법들이 있는지 찾아 봐야 할 것 같습니다. 이후에라도 가능한 방법들을 찾게 된다면 블로그를 업데이트 하도록 하겠습니다.

메모리 포렌식(Memory Forensic)을 위한 메모리 분석 툴 Mandiant Redline

컴퓨터 포렌식 중에서도 멀웨어 포렌식(Malware Forensic) 분야를 기법적인 면을 기준으로 본다면 크게 4가지 정도로 나눌 수 있다고 보여집니다.

첫 번째가 메모리 포렌식(Memory Forensic)으로서 램(RAM)에 존재하는 악성코드 감염과 관련된 다양한 흔적(네트워크 접속 정보 및 프로세스 정보 등)들을 분석하는 것입니다. 

두번째로는 레지스트리 포렌식(Registry Forensic) 입니다. 일반적으로 거의 대부분의 악성코드들(일부 그렇지 않은 악성코드들도 존재 합니다.)은 감염된 시스템이 재부팅을 하거나 시스템 사용자가 특정 행위를 수행 하였을 때 악성코드 자신이 실행되기 위하여 윈도우 시스템의 레지스트리에 새로운 키(Key)를 생성 및 변경 하게 됩니다. 

특정 악성코드의 경우에는 윈도우 XP에 존재하는 안전모드 부팅(Safe Mode Booting) 관련 레지스트리를 삭제하여 안전모드 부팅을 방해하기도 합니다.

세번째로 인터넷 포렌식(Internet Forensic) 입니다. 이메일(E-Mail), 메신저(Instant Messenger)  그리고 웹 브라우저(Web Browser)와 같이 인터넷 활동과 관련된 어플리케이션(Applications)으로 인해 악성코드에 감염되는 사례들이 다수를 차지하고 있습니다. 이러한 경우에는 인터넷 관련 어플리케이션들의 행위를 분석하는 것만으로도 의외로 쉽게 악성코드의 감염 경로를 파악 할 수 있습니다.

최근 수행한 멀웨어 포렌식의 대상은 방송 관련 업무를 하시는 분들의 노트북들이었습니다. 분석을 하는 과정에서 1대의 노트북에서 악성코드 감염으로 인해 안랩(AhnLab)의 전용백신으로 진단, 치료 하였던 흔적을 발견 할 수가 있었습니다. 

결론적으로 그 악성코드의 감염 경로는 웹 브라우저 취약점을 악용한 중국산 웹 익스플로잇 킷(Web Exploit Kit)인 공다(GongDa)에 의해서 였으며, 이러한 감염 경로를 파악하는데 결정적인 역할을 한 것이 바로 인터넷 포렌식과 레지스트리 포렌식 기법의 복합적인 사용이었습니다.

그리고 마지막으로 디스크 포렌식(Disk Forensic) 입니다. 이는 전통적인 컴퓨터 포렌식에서 이야기하는 디스크 이미징(Disk Imaging) 이 후 엔케이스(EnCase)나 FTK와 같은 분석 툴을 이용해 디스크 전체를 분석하는 과정 입니다.

그 중 오늘 이야기 할 주제는 첫번째인 메모리 포렌식을 할 경우에 무료로 사용할 수 있도록 맨디언트(Mandiant)에서 개발한 레드라인(Redline)이라는 메모리 분석 툴입니다.

메모리 분석 관련 툴들 중에서 많이 사용되는 것으로 오픈소스(Open Source) 인 볼라틸리티(Volatility)와 커맨드라인(Command-Line) 형태로 동작하는 맨디언트의 메모라이즈(Memoryze)가 존재 합니다. 그래서 컴퓨터 포렌식이나 멀웨어 포렌식 관련 서적들에서는 위 2가지 툴에 대해 빼놓지 않고 언급 하고 있습니다.

위에서 언급한 2개의 메모리 분석 툴은 여러가지 장점들로 인해 일반적으로 많이 사용되는 툴들이며, 분석 과정에서 오류가 없다는 것을 인정을 받았습니다. 하지만 악성코드 감염으로 인해 침해사고가 발생하여 신속하게 실시간 대응(Live Response)를 진행해야 되는 상황에서 앞서 언급한 2개의 메모리 분석툴들은 모두 커맨드 라인 형태를 가지고 있어 조금 불편함이 존재합니다.

이러한 관점에서 본다면 레드라인은 맨드언트에서 언급한 문구인 "Accelerated Live Response"와 같이 신속하게 메모리 분석을 진행 할 수 있도록 도와주는 GUI 기반의 툴입니다.

레드라인을 설치하고 실행을 하기 위해서는 설치 대상이 되는 시스템에 닷넷 프레임워크(.Net Framework) 4.0 을 필요로 합니다. 그래서 이를 설치하고 맨드언트에서 무료로 제공하는 레드라인 설치 파일인 Redline-1.9.2.msi (56,139,776 바이트)을 설치합니다.

설치가 완료되고 레드라인을 실행하면 맨디언트사 특유의 붉은 색이 주를 이루는 GUI를 볼 수가 있습니다.

레드라인은 메모리 분석을 위한 툴이기도 하지만, 이와 함께 침해 사고가 의심되는 컴퓨터 시스템에서 메모리 덤프(Memory Dump)를 제작 할 수 있는 기능도 포함되어 있습니다. 하지만 닷넷 프레임워크를 필요로 한다는 점에서 이 기능이 그렇게 활용 가능성이 높다고 보기 어려울 것 같습니다.

레드라인을 테스트 해보기 위해 기존에 제작해둔 악성코드 감염 시스템에서 생성한 메모리 덤프 파일들을 레드라인으로 분석을 진행 해봤습니다.

약 130 MB의 메모리 덤프 파일을 레드라인에서 읽어들이는 과정에서 시간 소요가 조금은 필요 했습니다. 이는 기존에 사용되던 메모라이즈에 포함되어 있던 모든 기능들을 레드라인에 포함시켜 이를 활용하는 과정에서 시간 소요가 발생하는 것으로 보여집니다.

130 MB의 메모리 덤프에서 사용자가 체감할 정도의 시간 소요가 발생 했다는 점에서 최근에 사용되는 윈도우 시스템의 메모리가 대부분이 2, 3 GB가 넘는 것을 감안 할 경우, 실제 침해 사고 발생 시스템의 메모리 분석시에는 더 긴 시간 소요가 필요 할 것으로 보여집니다.

기본적으로 레드라인에서 제공하는 메모리 분석 기능은 기존 맨디언트에서 제공하는 커맨드 라인 메모리 분석 툴인 메모라이즈에서 제공하는 기능들을 모두 포함하고 있습니다. 

그리고 여기에다 MRI(Mandiant for Intelligent Response)라는 기능이 추가 되어 있습니다. 이 MRI 기능은 메모리 분석 과정에서 프로세스(Process)나 핸들(Handle) 등에서 악성코드와 관련 있는 의심스러운 아티팩트(Artifact)를 발견하게 될 경우 붉은 색으로 표기를 해줍니다.

아래 이미지는 Oficla(a.k.a Sasfis)에 감염된 윈도우 XP 시스템에서 생성한 메모리 덤프 파일들을 분석한 내용입니다. 

붉은 색으로 표기된 MRI가 존재하는 svchost.exe는 정상 윈도우 시스템 프로세스입니다만, Oficla가 자신의 코드를 임의로 svchost의 메모리 영역에 코드 인젝션(Code Injection)을 수행한 상태입니다. 

결론적으로 코드 인젝션이 발생한 svchost.exe에 MRI가 표기 되었다는 점에서 레드라인이 Oficla 악성코드 감염 흔적을 메모리에서 발견했다라고 생각 해볼 수 있습니다.

그리고 다른 메모리 분석 툴에서 제공하지 않는 타임라인(TimeLine) 분석 기능을 제공 합니다.이 타임라인 분석 기능은 아래 이미지에서와 같이 메모리에 존재하는 정보들을 조합하여 시간 순서로 정렬하여 보여줍니다.

그래서 아래 이미지와 같이 악성코드의 코드 인젝션이 발생한 svchost.exe가 실행 된 시간을 기준으로 대략 이 시점 이전에 해당 시스템으로 악성코드가 유입되어 감염이 발생하였다는 것을 판단 할 수 있습니다.

이렇게 간편하고 빠르게 메모리 분석을 수행 할 수 있도록 도와주는 장점을 가진 레드라인은 MRI라는 기능으로 인해 더 신속하게 악성코드로 의심되는 메모리 영역과 파일을 판단 할 수가 있습니다.

이 MRI라는 기능의 알고리즘이 어떻게 제작되었는지 멘디언트에서 공개하지 않아 알 수가 없어 쉽게 판단을 할 수가 없습니다만, 다른 악성코드 감염 시스템에서 제작한 메모리 덤프들로 테스트를 하는 과정에서 일부 악성코드와 관련된 메모리 정보들을 MRI가 붉은 색으로 표기 해주지는 못하는 것을 확인 하였습니다.

그러므로, MRI의 붉은 색 표기만을 전적으로 신뢰하기 보다는 이 정보는 참고용으로 사용하고, 분석가의 경험과 역량이 더 중요하게 적용된다는 점을 생각해야 됩니다.

그리고, 오픈소스와 파이선(Python)의 장점들을 모두 가진 볼라틸리티와 비교를 한다면 향후 확장성과 성능 개선이라는 면에서는 발전이 빠르지는 않을 것으로 보여집니다. 하지만 경험이 풍부한 침해 사고 대응 전문 업체에서 제작한 메모리 분석 툴임으로 오픈소스와는 또 다른 분석 기능을 보여줄 것으로 기대 됩니다.

이러한 장, 단점을 고려해두고 신속하게 메모리 분석을 수행하여야 되는 경우에 레드라인을 사용한다면 조금 더 편하고 빠르게 메모리 분석을 진행 할 수 있을 것으로 생각 됩니다.