月光愛靑狼

마그넷 엑시엄은 USB 동글 키를 사용하여 라이센스를 보호하고 있습니다.
USB 동글 키 내 파일을 삭제하면 복구받을 수 있으나,
USB 동글 키 자체를 잊어버리며 복잡해진다고 하니 분실하지 않도록 주의해야 겠습니다.

USB 동글 키를 빼서 뒤집어보면 고유번호가 각인되어 있습니다.

이전다음

012345

 
디지털 포렌식 분야는 빠르게 변화하고 있으며, 이 과정에서 전문가들은 점점 더 많은 데이터를 분석해야 하는 도전에 직면하고 있습니다. 이때, 마그넷 엑시엄(MAGNET AXIOM)은 디지털 포렌식 전문가들에게 강력한 도구로 자리매김하고 있으며, Forensic 4:cast 2023 Award DFIR 상업용 도구 투표에서 2017년부터 2023년까지 7년째 1등을 하고 있습니다. 이 블로그 글에서는 마그넷 엑시엄의 주요 기능과 장점을 소개하고, 왜 이 도구가 디지털 포렌식 조사에서 중요한 역할을 하는지 설명해 보겠습니다.

◎ 마그넷 엑시엄이란?
마그넷 엑시엄은 Magnet Forensics에서 개발한 디지털 포렌식 소프트웨어입니다. 이 도구는 컴퓨터, 모바일 장치, 클라우드 서비스 등 다양한 디지털 소스에서 데이터를 수집, 분석 및 보고하는 데 사용됩니다. 사용자 친화적인 인터페이스와 강력한 분석 기능을 통해, 디지털 증거를 효율적으로 찾아내고 해석하는 데 도움을 줍니다.

◎ 주요 기능
1. 광범위한 데이터 수집:
마그넷 엑시엄은 컴퓨터와 모바일 장치에서 데이터 수집을 지원하며, 이를 통해 파일 시스템, 메모리 덤프, 네트워크 트래픽 등 다양한 데이터 소스를 분석할 수 있습니다.
또한 클라우드 서비스에서 데이터를 수집할 수 있어, 현대 디지털 환경에서 발생하는 다양한 사건에 대응할 수 있습니다.

2. 강력한 분석 도구
데이터 카빙(Data Carving)을 통해 삭제되거나 숨겨진 데이터를 복구할 수 있습니다.
타임라인 분석 기능을 통해 사건의 전후 상황을 명확히 파악할 수 있습니다.
키워드 검색, 해시 매칭, 이미지 분석 등 다양한 분석 기법을 지원하여 포렌식 조사에 필요한 모든 데이터를 철저히 분석할 수 있습니다.

3. 보고서 생성 및 공유
마그넷 엑시엄은 포렌식 조사 결과를 다양한 형식으로 보고서를 생성할 수 있습니다.
보고서에는 발견된 증거, 분석 결과, 타임라인 등 모든 관련 정보를 포함할 수 있어, 법정에서도 유효한 증거로 활용할 수 있습니다.
공유 기능을 통해 팀 내 협업을 쉽게 할 수 있습니다.

4. 사용자 친화적 인터페이스:
직관적인 사용자 인터페이스를 통해, 복잡한 포렌식 작업도 쉽게 수행할 수 있습니다.
초보자부터 전문가까지 모두가 쉽게 사용할 수 있도록 설계되었습니다.

◎ 마그넷 엑시엄의 장점
효율성: 한 번의 수집으로 다양한 데이터 소스를 분석할 수 있어 시간과 노력을 절약할 수 있습니다.
정확성: 강력한 분석 도구를 통해 높은 정확도의 결과를 도출할 수 있습니다.
확장성: 다양한 디지털 소스와 포렌식 기법을 지원하여, 어떤 사건에도 유연하게 대응할 수 있습니다.
신뢰성: 법적 효력이 있는 보고서를 생성할 수 있어, 법정에서도 신뢰할 수 있는 증거로 사용할 수 있습니다.

◎ 결론
마그넷 엑시엄은 디지털 포렌식 전문가들에게 필수적인 도구로, 효율적이고 정확한 조사와 분석을 가능하게 합니다. 디지털 증거 수집부터 분석, 보고서 생성까지 모든 과정을 아우르는 마그넷 엑시엄을 통해, 디지털 포렌식 조사를 한층 더 효과적으로 수행할 수 있습니다.

디지털포렌식과 사고대응(DFIR, Digital Forensic and Incident Response)에 대해서 개인적인 생각을 정리해 봤습니다.
먼저 국가법령정보센터에서 디지털포렌식를 찾아보니
전자정보를 수집ㆍ보존ㆍ운반ㆍ분석ㆍ현출ㆍ관리하여 범죄사실 규명을 위한 증거로 활용할 수 있도록 하는 과학적인 절차와 기술을 말한다.
라고 정의되어 있습니다.

정의와 관련해서 정리하면 디지털포렌식은 주로 수사관 분들이 사용하던 기술이죠.
개인적인 생각으로는 국외나 국내 수사관 출신분들이 다양한 직군에 포진하면서 디지털포렌식 대중화(?)에 기여하신 것은 아닌지 싶습니다.
아무튼 회계감사 분야에서 디지털포렌식을 사용하기도 하고, 침해사고 대응과 관련해서도 법적 분쟁 발생 시 법원에서 디지털포렌식을 통해 제출된 자료에 대해서만 법적 증거력 인정을 받는 부분이 있다 보니 디지털포렌식을 사용하기도 합니다.

국내 디지털포렌식 단체와 관련된 내용을 찾아보니 아래와 같습니다.

2003년 사이버포렌식전문가협회(KCFPA) 설립
2006년 한국디지털포렌식학회(KDFA) 설립
2009년 디지털포렌식산업포럼 출범
2010년 (사)한국포렌식학회(KAF) 설립
2013년 법무부와 한국포렌식학회의 공동 주최로 제1회 국가공인 디지털 포렌식 전문가 2급 자격시험 시행
2013년 디지털포렌식전문가 검정시험 국가 공인
2013년 디지털 포렌식 전문가 1급 자격시험 시행
2016년 (사)한국디지털포렌식전문가협회(KDFPA) 설립

디지털포렌식은 무결성에 문제가 발생하지 않도록 이미징만 수행하면 무료솔루션으로도 가능하지만 앞선 말씀드린 것과 같이 현재까지 법정에서 증거력 인정을 받은 솔루션은 오직 Encase 뿐이다 보니 상용이든 무료이든 그 외 솔루션은 무의미해집니다. 관련해서 디지털포렌식 후발주자로 엄청난 편의성을 제공하고 있는 Magnet AXIOM이 아직 법원에서 공식적인 증거력 인정을 받지 못하고 있다 보니 수사관분들이 Magnet AXIOM으로 분석해서 Encase에서 분석한 것처럼 문서를 만들고 법원에 자료를 제출한다고 합니다. 또한 국내 디지털포렌식 자격시험 시에도 Magnet AXIOM은 사용 불가라고 하죠. 디지털포렌식 솔루션이 발전해도 시험은 과거에 머무는 것은 아닌지 아쉽습니다.

디지털포렌식을 사용한다는 건 저장장치 이미징을 먼저 수행해야 되는데, 무조건 시스템 전원을 차단시켜야하죠. 이 때 무결성이 깨지지 않도록 쓰기방지 장치를 통해 이미징을 수행해야하는데, 무결성 때문에 이미징 수행 전 라이브 시스템에서 휘발성 증거를 수집하는 것이 디지털포렌식에 문제가 없는지 질문을 하게 되는 것 같습니다.
개인적으로 이미징 수행 전 휘발성 증거 수집 시 수집 방법과 도구, 수집 시간, 수집한 데이터의 위치와 보관 방법, 수집된 데이터의 무결성 검사 등 모든 단계와 결정이 정확하게 기록되어 문서화한다면, 이후 디지털포렌식을 수행하더라도 법원에서 증거력 인정을 받을 수 있지 않을까 생각해 봅니다.
 
근데, 대부분의 침해사고가 발생한 기업의 경우 보안에 최선을 다했다는 소명에 집중하지, 분석 결과 해커가 국내 B사를 해킹하여 손해를 입혔는데 국내 A사를 통해 경유한 흔적이 확인되었다고, B사가 A사에게 손해배상청구 고소ㆍ고발한 사건이 있는지와 과연 앞으로도 그렇게 손해배상청구 고소ㆍ고발 건이 발생할지 생각해 볼 때 낮다라는 생각이 들긴 합니다. 

아무튼, 전원을 차단하는 것과 관련해서 어떤 서비스담당자는 서버에서 스크립트를 실행하는 것조차 문제 발생 시 책임지겠다는 각서를 쓰라고도 하죠. 그렇다 보니 침해사고가 발생한 시스템이 대고객 서비스라고 가정했을 때, 수사기관 요청이 아닌 자체 정보보호팀에서 디지털포렌식 목적으로 이미징을 수행하기 위해 서버를 종료해야 된다고 했을 때 과연 얼마나 많은 서비스담당자나 관련 직책자들이 시스템 종료 결정을 내릴지 의문이 들기도 합니다.
 
디지털포렌식이 대중화(?)되기 전 침해사고대응은 라이브 시스템에서 빠르게 휘발성/비휘발성 증거를 수집하기 위해 스크립트를 이용하거나 로그를 분석했죠. 그래서 다양한 운영체제와 환경에서 테스트 되어 문제가 발생하지 않는 스크립트라고 한다면, 또한 손해배상청구 고소·고발 건에 대응 하기 위한 것이 아니라면, 라이브 시스템에서 휘발성/비휘발성 증거를 수집하여 분석하는 것도 원인을 파악하고 대응 방안을 마련할 수 있는 가이드를 제시할 수 있다고 생각이 듭니다.

마무리를 지어보자면, 침해사고분석에 있어서는 디지털포렌식이 만능은 아니다 입니다.
시스템관련 보안이 지속적으로 강화되다보니 취약한 시스템을 직접 공격하던 방법이 어려워지자, 사용자PC를 감염시켜 시스템에 접근하는 사고사례가 많아져 시스템보다는 사용자 PC에 대한 디지털포렌식이 주를 이루는 것 같습니다.
다운로드 되었으나 실행 후 삭제된 악성코드 관련 정보 분석은 디지털포렌식이 필요하겠지만, 라이브 상태에서 메모리덤프를 수행했다면 실제 악성코드 분석이 가능하겠죠. 파일리스 악성코드 분석 또한 라이브 상태에서 메모리덤프 수행이 필요하겠죠. 단편적으로 놓고 본다면 수사/감사기관에서의 디지털포렌식은 사용자PC에서 증거인멸을 복구하는 관점이었고 침해사고분석은 서버라면 어떤 취약점으로 어떻게 공격이 들어와서 무슨 피해가 발생했나, 사용자PC라면 어떤 취약점으로 어떻게 악성코드에 감염되서 무슨 피해가 발생했나로 볼 수 있겠습니다.
디지털포렌식이 대중화(?)되면서 디지털포렌식을 우선시하다보니 법정에서 증거력 인정을 받기 위해 무결성을 훼손하지 않아야 한다는 이유로  실행 중인 상태에서 휘발성 정보를 저장하는 것을  패스하지 않았으면 합니다. 앞서 말씀드린 대로 모든 단계를 기록하여 문서화하고 디지털포렌식을 위한 이미징을 수행하면 좋겠다는 생각이 듭니다. 디지털포렌식의 장점과 침해사고분석의 장점을 조화롭게 사용할 수 있는 노하우가 필요해 보입니다.

MCFE(Magnet Certified Forensics Examiner)는 마그넷 엑시엄(MAGNET AXIOM) 제품을 사용하여 디지털포렌식(Digital Forensic) 역량을 입증하는 자격증 중 하나입니다.
 
시험시간은 120분, 2023년 기준 온라인 객관식 75문제이고, 2번의 기회가 있으며, 100점 환산기준 80점이 넘으면 합격입니다.
시험을 등록하면 메일로 시험관련 링크를 받을 수 있습니다.
로그인해서 마그넷 엑시엄(MAGNET AXIOM) 제품을 다운받아 설치하고
증거파일을 다운받아 분석하여 정답을 체크하면 됩니다.
2년마다 갱신해야되는데, 자격증에 관리번호가 없다는게 조금 신기합니다.

◎ Windows hibernation files

자세한 내용은 [Windows] 메모리 덤프 형식(Memory Dump Format) 글에서 확인해주세요.

[최대절전모드]

> 1단계

최대절전모드의 시스템메모리는 일반적으로 c:\hiberfil.sys 파일에 저장됩니다. 최대절전모드를 사용 중인지 모르는 상태에서 종료해야된다면, 관리자권한으로 cmd를 실행한 뒤 아래 명령어로 최대절전모드를 켜고, 컴퓨터를 종료하면 됩니다.

• powercfg /h on : powercfg는 전원관리 명령어, /h는 hibernate(최대절전모드), on은 설정 켜기입니다.

• shutdown /f /h : shutdown은 시스템 종료 명령어, /f는 강제종료, /h는 대기모드입니다.

> 2단계

저장장치를 분리해서 Linux 컴퓨터에서 hiberfil.sys 파일을 USB에 복사합니다.

> 3단계

제작사 홈페이지에서 Comae 툴킷을 다운받아서 Hibr2Bin.exe 이용해 hiberfil.sys 파일을 압축되지 않은 바이너리로 변환합니다.

일반적으로 Windows 10 응용 프로그램의 경우 다음과 같이 실행합니다.

아래는 옵션 설명입니다.

> 4단계

이미지를 분석합니다.

◎ Expert witness format

EnCase 상용소프트웨어가 필요하기 때문에 생략합니다.

◎ HPAK Format

HBGary Responder 상용소프트웨어가 필요하기 때문에 생략합니다.

◎ Windows crach dump

자세한 내용은 [Windows] 메모리 덤프 형식(Memory Dump Format) 글에서 확인해주세요.

• Complete 메모리 덤프

• Kernel 메모리 덤프

• Small 메모리 덤프

[크래시 덤프 생성 설정]

설정 - 시스템 - 정보로 이동합니다.

고급 시스템 설정을 선택한 다음 고급 탭을 선택합니다.

시작 및 복구 영역에서 설정을 선택합니다.

디버깅 정보 쓰기에서 원하는 덤프 형식을 지정합니다.

덤프파일 위치는 변경가능합니다.

[전체 메모리 덤프]

저장위치 : %SystemRoot%\Memory.dmp

[커널 메모리 덤프]

저장위치 : %SystemRoot%\Memory.dmp

[작은 메모리 덤프]

저장위치 : %SystemRoot%\Minidump 폴더

[수동 메모리 덤프 생성 방법]

Microsoft Sysinternals NotMyFault 도구를 사용하여 덤프를 생성할 수 있습니다.

◎ RAW memory dump

자세한 내용은 [Windows] 메모리 덤프 형식(Memory Dump Format) 글에서 확인해주세요.

• Windd

• DumpIt

• Magnet Ram Capture

• Winpmem

• Belkasoft Live RAM Capturer

• FTK Imager

[Windd]

Unix 용 dd의 윈도우 버전이라고 보면 되겠습니다. win32dd(win64dd)는 MoonSols 사의 무료 메모리 덤프 툴입니다. 윈도우 XP, Vista 그리고 Win7 x86, x86_64를 지원합니다. 윈도우 10 22H2는 지원하지 않습니다(BSOD 발생).

[DumpIt]

win32dd와 win64dd의 기능을 하나로 통합한 MoonSols 사의 무료 메모리 덤프 툴입니다. MoonSols 사의 dumpit은 역시나 윈도우 10 22H2는 지원하지 않습니다(BSOD 발생)만, Comae 사(Magnet Forensics 사에 인수됨)의 dumpit은 윈도우 10 22H2를 지원합니다. 더블클릭하면 메모리덤프 진행여부를 묻고 진행 시 Dumpit이 실행된 폴더에 크래시 덤프 파일을 저장합니다.

제작사 홈페이지에서 다운받을 수 있습니다.

  > MoonSols Dumpit

  > Magnet(Comae) Dumpit

[Magnet Ram Capture]

Magnet Forensics 사가 Comae 사를 인수하기 전에 배포한 툴입니다. Comae 사를 인수한 이후 Magnet Forensics 사의 홈페이지에서 Magnet Ram Capture 내용 대신 Dumpit 내용을 보여주고 있습니다.

※ MoonSols 사의 홈페이지도 접속이 안되고, MoonSols 사의 Windd와 Dumpit은 왜 업데이트가 안되는건지 궁금해서 만든이(Mathieu Suiche)를 검색해봤습니다.  Mathieu Suiche(1988년 9월 22일 출생)는 프랑스의 해커 이자 기업가로 MoonSols 사의 창립자이자 VMWare 사에 의해 인수되기 전 CloudVolumes 사의 공동 창립자입니다. 이후 Comae 사를 설립하였으며, 회사는 Magnet Forensics 사에 인수되었습니다. 현재는 Magnet Forensics 사의 Incident Response R&D 이사로 재직하고 있습니다.

[Winpmem]

Google의 Rekall 프로젝트(오픈소스 메모리분석 프레임워크)에 속해 있다가 현재는 독립한 무료 메모리 덤프 툴입니다. 마지막 릴리즈가 2020년 10월인데 윈도우 10 22H2를 지원합니다. CMD창을 관리자모드로 실행하고 아래 명령어를 입력하면 메모리 덤프를 진행합니다.

Github에서 다운받을 수 있습니다.

[Belkasoft Live RAM Capturer]

Belkasoft 사의 메모리덤프 툴입니다. 더블클릭으로 메모리 덤프가 가능합니다. 윈도우 10 22H2를 지원합니다.

제작사 홈페이지에서 다운받을 수 있습니다.

[FTK Imager]

Exterro 사의 메모리덤프 툴입니다. FTK Imager를 설치하고 일반적으로 "C:\Program Files\AccessData\FTK Imager" 폴더를 USB에 복사하면 독립실행이 가능합니다. 메모리덤프를 진행하기 원하는 시스템에 USB를 연결하고 FTK Imager.exe를 더블클릭하면 GUI에서 File - Capture Memory메뉴를 통해 메모리 덤프가 가능합니다. 윈도우 10 22H2를 지원합니다.

제작사 홈페이지에서 다운받을 수 있습니다.

[Memory Dump 란?]
Memory Dump 는 System의 물리 Memory 를 File 형태로 저장하는 방법으로, 해당 File 의 구조는 실제 물리 Memory 구조와 동일합니다. 침해사고 분석 시 침해 시스템에 실시간 분석을 수행하면 해당 명령어로 인해 Memory 의 상태 및 Data 가 변경됩니다. 

이는 Memory 로부터 얻을 수 있는 중요한 정보를 놓칠 수 있는 가능성이 존재하므로 분석에 불리하게 작용할 수 있습니다. 이 같은 실시간 분석의 단점으로 인해 침해사고 시점의 휘발성 Data 를 File 로 간직하여 Memory 에 변화를 주지 않으면서 분석을 하기위해 Memory Dump 를 수행합니다. 

◎ Windows 에서 Memory Dump
Windows 운영체제에서 메모리 덤프는 수집방법에 따라 파일 형식이 달라지지만 일반적으로 사용되는 메모리 덤프형식은 5가지가 있습니다.
• RAW memory dump.
• Windows crash dump.
• Windows hibernation files.(최대 절전 모드 파일)
• Expert witness format (EWF).
• HPAK format.

[RAW memory dump]
RAW 메모리 덤프는 가장 일반적으로 사용되는 메모리 덤프 형식입니다. RAW 메모리 덤프에는 headers, metadata, magic values 이 포함되어 있지 않습니다.

원시 형식에는 일반적으로 의도적으로 건너뛴 메모리 범위(예: 디바이스 메모리)나 수집 도구에서 읽을 수 없는 메모리 범위에 대한 패딩이 포함되어 공간 무결성(데이터 간 상대적 오프셋)을 유지하는 데 도움이 됩니다.

[Windows crach dump]
모든 Windows 운영체제는 컴퓨터 충돌 시 컴퓨터의 상태에 대한 정보를 덤프하도록 구성되어 있습니다. 이러한 크래시 덤프는 _DMP_HEADER 또는 _DMP_HEADER64구조로 시작됩니다.
Windows 크래시 덤프에는 세가지 형식의 메모리 덤프를 사용할 수 있습니다.
> Complete 메모리 덤프
이 메모리 덤프는 the largest kernel-mode 메모리 덤프 파일입니다.  이 메모리 파일에는 실제 메모리에 있던 모든 내용이 포함되어 있습니다. 이 메모리 덤프에는 플랫폼 펌웨어에서 사용하는 물리적 메모리가 포함되어 있지 않습니다.
> Kernel 메모리 덤프
이 커널 모드 메모리 덤프에는 메모리 캡처 시 커널에서 사용된 모든 내용이 포함되어 있습니다. 이 파일에는 커널에서 사용된 콘텐츠만 포함되어 있으므로 이 메모리 덤프는 전체 메모리 덤프보다 훨씬 작습니다. 이 메모리 덤프에는 할당되지 않은 메모리나 사용자 모드 응용 프로그램에 할당된 메모리가 포함되지 않으므로 분석 범위를 좁힐 수 있습니다.
> Small 메모리 덤프
이름에서 알 수 있듯이 Windows 크래시 덤프에서 생성할 수 있는 가장 작은 메모리 덤프 파일입니다.
이 메모리 파일에는 다음 내용이 포함됩니다.
• 버그 확인 메시지와 매개변수, 기타 블루스크린 데이터
• 충돌이 발생한 프로세서에 대한 프로세서 컨텍스트(PRCB)
• 충돌이 발생한 프로세스에 대한 프로세스 정보 및 커널 컨텍스트(EPROCESS)
• 충돌이 발생한 스레드에 대한 스레드 정보 및 커널 컨텍스트(ETHREAD)
• 충돌이 발생한 스레드에 대한 커널 모드 호출 스택. 16KB보다 길면 최상위 16KB만 포함
• 로드된 드라이버 목록

크래시 덤프가 생성될 수 있는 이유는 다음과 같습니다.
• Blue Screens
• CrashOnScrollControl
• Debuggers

그러나 위의 모든 방법이 법의학에 적합한 것은 아닙니다.

[Windows hibernation files]
최대 절전 모드는 컴퓨터의 상태를 유지하면서 컴퓨터의 전원을 끄는 것입니다. 최대 절전 모드 시 컴퓨터는 RAM(Random Access Memory)의 내용을 하드 디스크나 기타 비휘발성 저장소에 저장하며, 컴퓨터를 다시 시작하면 최대 절전 모드에 들어가기 전과 똑같은 상태가 됩니다. 컴퓨터에서 최대 절전 모드가 활성화되면 메모리 전체 덤프 내용이 포함된 최대 절전 모드 파일이 시스템 폴더 아래에 생성됩니다.

[Expert witness format]
EnCase 소프트웨어로 메모리를 획득할 때 사용하는 형식입니다. 이 형식은 EnCase 소프트웨어에서 사용하지만, 그 인기로 인해 표준화된 파일 형식 중 하나가 되었습니다. 이 파일 형식은 EnCase 소프트웨어에서 메모리 파일을 분석하기 위해 사용하는 파일 형식이므로 사용할 수 있는 도구는 몇 가지뿐입니다. 조사자는 다음과 같은 EWF 메모리 덤프 분석 방법을 숙지하고 있어야 합니다.
• EWFAddressSpace
• Mounting with EnCase
• Mounting with FTK Imager

[HPAK Format]
HPAK Format은 HBGary 소프트웨어에서 사용하는 파일 형식입니다. HPAK를 사용하면 대상 시스템의 물리적 메모리와 페이지 파일을 동일한 출력 파일에 포함할 수 있습니다. HPAK Format은 독점 형식이므로 HBGary 도구로만 생성할 수 있습니다.

[Windows] 메모리 덤프#01
[Windows] 메모리 덤프#02
[Windows] 메모리 덤프#03

◎ Miscellaneous : 기타 등등
 > strings : <decimal_offset>:<string> line 형식으로 된 주어진 Image와 File에서 해당 문자열을 찾을 수 있는 Process와 Virtual Address를 출력해 주는 명령어입니다.
  - 해당 명령의 입력은 Sysinternals의 Strings Utility 또는 유사한 Tool 들의 출력(offset:string)이며, 입력 Offset 은 File/Image의 시작 지점의 물리 Offset입니다.
  - Sysinternals 의 Strings는 Linux/MAC 에서 Wine을 이용하여 사용 가능하며, 이에 대한 출력은 File 형식으로 Volatility에게 Redirect 되어야 합니다. 
  - GNU 의 Strings 명령어를 사용한다면 -td Option을 통해 Offset을 10 진수로 출력 가능합니다.(GNU strings는 십육진 오프셋 미지원) 
  - File/Image 를 Sysinternals의 Strings Utility를 수행하면 많은 시간이 걸리며, -q와 -o는 Header 출력의 생략(-q)과 각 줄의 Offset(-o)을 구하기 위해 필수적인 Option입니다

  - Default 로 PsActiveProcessHead를 이용해 Double-linked 형태로 Process 들을 출력하며, -S Option을 통해 Hidden Process 들도 출력 가능합니다.

  - EPROCESS Offset 도 지원해 줍니다.

 > volshell : 메모리 덤프 파일 분석 시에 Windbg와 유사한 명령 형식으로 분석 할 수 있습니다.
 ※ 제공 기능
  - 프로세스들의 목록화(List processes)
  - 프로세스들의 문맥 교환(witch into a process's context)
  - 구조체와 객체들의 형식 출력(Display types of structures/objects)
  - 주어진 주소에 타입 덮어씌우기(Overlay a type over a given address)
  - 링크드 리스트 순회(Walk linked lists)
  - 주어진 주소의 코드 디스어셈(Disassemble code at a given address)
  - db, dd, dt, dis 명령어는 특정 주소 공간을 인자로 전달 가능하며, 사용하는 주소 공간에 따라 다른 결과를 출력하는 것을 확인 가능합니다.

 > bioskbd : Memory 의 BIOS 영역에서 Key 입력을 읽을 때 사용하는 명령어입니다.
  - Lenovo 의 BIOS와 SafeBoot, TrueCrypt, BitLocker에 입력한 비밀 번호를 확인 가능합니다.
  - 메모리 덤프 툴에 따라서 필요한 BIOS 영역을 포함할 수도 있고 아닐 수도 있습니다.

 > patcher : Patches memory based on page scans
  - patcher 플러그인을 실행할때, 명령줄에 쓰기 옵션(-w) 지정하지 않으면 수정이 안됩니다.

 > pagecheck : pagecheck 플러그인은 커널 DTB (System/Idle 프로세스로부터)을 사용하고 페이지들(pages)이 위치하고 있는 메모리(AddressSpage.get_avaliable_pages 메서드를 사용) 정보를 출력하는 명령어입니다.
  - 각 페이지별로 그 페이지 데이터에 접근하는 것을 시도하고 자세하게 결과를 출력합니다. 만약 그 시도한 것이 실패되면 PDE, PTE 주소 정보들도 나타냅니다.
  - 이 플러그인은 기본적으로 지원되지 않고, contrib 디렉터리 안에 위치하고 있으며 non-PAE x86 주소 공간들에서 작동이 됩니다.

 > mftparser : 파일이 디스크에 있는지 확인하는 명령어입니다.

  - 내용이 상당히 길기 때문에 --output-file 옵션을 사용하여 파일에 저장하는 것이 좋습니다.

Volatility 볼라틸리티 2.1 Plugins - 윈도우#01

◎ Image Identification : 이미지 식별

Volatility 볼라틸리티 2.1 Plugins - 윈도우#02

◎ Processes and DLLs : 프로세스와 DLLs 분석
Volatility 볼라틸리티 2.1 Plugins - 윈도우#03

◎ Process Memory : 프로세스 메모리 분석
Volatility 볼라틸리티 2.1 Plugins - 윈도우#04

◎ Kernel Memory and Objects : 커널 메모리와 오브젝트 분석
Volatility 볼라틸리티 2.1 Plugins - 윈도우#05

◎ Networking : 네트워크 정보
Volatility 볼라틸리티 2.1 Plugins - 윈도우#06

◎ Registry : 단지 Registry data를 추출하는데 도움을 줍니다.
Volatility 볼라틸리티 2.1 Plugins - 윈도우#07

◎ Crash Dumps, Hibernation and Conversion : 크래쉬 덤프, 하이버네이션 정보확인 및 파일변환
Volatility 볼라틸리티 2.1 Plugins - 윈도우#08

◎ Malware and Rootkits : 맬웨어와 루트킷 분석
Volatility 볼라틸리티 2.1 Plugins - 윈도우#09

◎ Miscellaneous : 기타 등등

◎ Malware and Rootkits : 맬웨어와 루트킷 분석
 > malfind : 사용자 모드 형태로 은폐되어 있거나 인젝션 된 코드 또는 DLL 정보를 분석하는 명령어입니다.
  - VAD 태그와 페이지 권한들 같은 문자들을 기반으로 사용자 모드 메모리에 숨겨져 있거나 삽입되어 있는 코드가 DLLs를 찾아냅니다.
  - CreateRemoteThread -> LoadLibrary로 사용되는 프로세스에 삽입되는 DLLs은 탐지하지 않습니다. 이 기술로 삽입된 DLLs는 숨겨지지  않으며 dlllist에서 이것들을 확인할 수 있습니다. 
  - malfind의 목적은 기본적인 메서드/도구들이 보지 못하는 것을 DLLs의 위치를 찾아내는 것입니다. malfind에 의해 인식되는 메모리 세그먼트의 압축된 복사 파일을 저장하고 싶다면 -D 옵션과 결과가 저장될 dir를 지정해주면 됩니다.

 > yarascan : YARA를 이용하여, 사용자 및 커널 모드 메모리 영역에 포함된 바이트(Byte) 순서, ANSI 및 유니코드 (Unicode) 문자열 검색하는 명령어입니다.
  - 의심스러운 드라이버(xxx.sys)에 대한 메모리 스캔

  - YARA 패턴(Rules)을 만들 수 있고, --yara-file=RULESFILE 옵션을 이용하여 명시할 수 있습니다.
  - 프로세스에서 rules.yara 파일 내에 정의되어 있는 문자들을 검색하기 위해서 아래와 같은 명령어를 입력하고, 간단하게 결과를 확인할 수 있습니다.

  - 프로세스에서 간단한 문자를 검색하고, 매칭 되는 문자가 포함되는 메모리 세그먼트들을 덤프 하기 위해서는 아래 명령어를 입력하면 됩니다.

  - 커널 메모리에서 바이트 패턴을 검색하기 위해서, 아래 명령어를 사용합니다.(kernel driver들에 의해 Load되어 있는 Memory만 탐색)

  - 각 프로세스 안에 있는 byte패턴을 얻기 위한 검색은 아래 예제와 같습니다.

  - 각 프로세스 안에 있는 정규 표현식에 대한 검색은 아래 예제와 같습니다.

 > svcscan : Memory Image에 등록된 service 목록을 확인할 수 있는 명령어입니다.
  - Process ID, Service name, Service display name, Service type, Current status, Binary path을 확인할 수 있습니다.
  - Binary path의 경우 User-mode service 뿐만 아니라, Kernel-mode에서 사용된 service의 Driver 이름까지도 출력합니다.

 > ldrmodules : 특정 프로세스나 DLL에 의해 은폐된 DLL 정보 분석하는 명령어입니다.
  - PEB 안의 linked list에서 Unlinking을 통해 DLL을 숨기는 기법의 경우 VAD(Virtual address Descriptor)에 정보(Base address, Full path)가 남아 있기 때문에 탐지가 가능합니다.
  - Unlinked 된 명령어를 출력해 주며, Memory mapping 된 PE File 이 PEB List에 존재하면 1, 하지 않으면 0을 출력해 줍니다.
  - 경로를 덮어쓰기 함으로써 악성코드가 DLL을 숨길 수 있으며, 이는 모든 Entry의 Full path를 보는 -v 또는 --verbose Option을 사용하여 확인할 수 있습니다.

 > impscan : 코드가 import 하고 있는 함수를 보여줍니다.
  - Impscan은 PE의 IAT(Import Address Table)를 파싱 할 필요 없이 API들을 불러와 정의하며, 만약 악성코드가 완벽하게 PE Header를 지우고 커널 드라이브에서 실행되고 있다면 여기엔 나오지 않을 것입니다.
  - IAT(Import Address Table) :  프로그램에서 사용할 외부 라이브러리가 메모리에 로드되고 난 후, 해당 함수의 주소를 가지고 있는 테이블입니다.
  - 명령어 라인에  -b 또는 -base 옵션으로 탐색 시작 베이스 주소 지정이 가능합니다.(Kernel driver의 Base address 도 지정 가능) 만약 Base address를 지정해 주지 않으면, Process의 main module 끝까지 탐색할 것입니다.

  - 명령어 라인에 -D 옵션으로 modules 명령으로 확인한 base address를 통하여 Rebuild가 가능합니다.

 > apihooks : 사용자 및 커널 모드에서 API 후킹 정보를 분석하는 명령어입니다.
  - IAT, EAT, Inline Hooking을 찾아낼 수 있습니다.
  - Inline Hooking을 탐지하기 위해서 CALL, JMP Operand 가 직접 또는 간접적으로 위치를 참조하는 것, PUSH/RET 명령어를 탐지하며, ntdll.dll의 syscall이나 Kernel memory의 unknown code page를 호출하는 것을 탐지합니다.
  - Kernel driver의 unknown code page를 CALL 하는 부분도 탐지할 수 있습니다.(cf. tcpip.sys 에 의심스러운 redirection)

 ※ hook을 포함하는 Code 추출 가이드
  - malfind 명령어가 자동으로 찾고 추출 가능한지 확인
  - volshell의 dd/db 명령어를 통해 MZ header를 찾은 후, dlldump를 --base 값과 함께 사용하여 추출
  - vaddump 명령어를 통해 모든 Code segment 들을 추출 한 후(File 명은 주소 범위) 해당 범위에 해당하는 Dump File을 찾음.

 > idt : System의 IDT(Interrupt Descriptor Table) 현재 주소, Module, Interrupt 목적 등을 보여주는 명령어입니다.
  - IDT(Interrupt Descriptor Table) : 인터럽트가 발생했을 때 처리해주는 함수의 루틴을 포함하고 있는 테이블입니다.
  - Inline Hooking을 탐지하기 위해 IDT Entry 들도 Check 합니다.
  - IDT 변경사항에 대해서 자세한 정보를 얻고 싶다면, --verbose 옵션을 사용합니다.

 > gdt : System의 GDT(Global Descriptor Table)를 탐지하는 명령어입니다.
  - GDT(Global Descriptor Table) : 커널 모드 메모리 내에 존재하는 구조체입니다.
  -  호출 문(call gate)에 설치된 Alipop 같은 루트킷들을 탐지하는데 유용합니다.
  - 조금 더 많은 조사를 원한다면 volshell을 사용하면 됩니다.

 > threads : 각 Thread에 속한 Register 정보, Thread 시작 주소의 Disassemble Code 등 조사에 관련된 다양한 정보를 제공해주는 명령어입니다.(Investigate _ETHREAD and _KTHREADs)
- ETHREAD 객체의 가상 주소, pid, tid, Thread와 관련된 모든 tag(SystemThread, AttachedProcess, HookedSSDT), 생성/종료 시간, 상태, 순서, 시작 주소 등을 확인 가능하며 SSDT base 주소와 각 Service Table, Table 안의 Hook 된 함수도 출력해 줍니다.

  - 가능한 tags/filters의 리스트 항목을 보고 싶다면, -L 옵션을 사용합니다.

  - Default로 모든 Thread에 대한 정보를 제공해 주기 때문에 정렬에 어려움이 있을 것이며, 이 때는 -F Option을 인자에 ", "를 이용하여 여러 개의 Filter를 적용 가능합니다.

 > callbacks : Rootkit, Anti-virus, Dynamic Analysis, Windows Monitoring Tool 들에 사용됩니다.
  - 중요한 알림 루틴(notification routines)과 커널 콜백(callbacks)의 모음을 출력할 수 있습니다.
 ※ Callbakck 모음
  - PsSetCreateProcessNotifyRoutine(process creation)
  - PsSetCreateThreadNotifyRoutine(thread creation)
  - PsSetImageLoadNotifyRoutine(DLL/image load)
  - IoRegisterFsRegistrationChange(file system registration)
  - KeRegisterBugCheack and KeRegisterBugCheackReasonCallback
  - CmRegisterCallback(registry callbacks on XP)
  - CmRegisterCallbackEx(registry callbacks on Vista and 7)
  - IoRegisterShutdownNotification(shutdown callbacks)
  - DbgSetDebugPrintCallback(debug print callbacks on Vista and 7)
  - DbgkLkmdRegisterCallback(debug callbacks on 7)

 > driverirp : Driver의 IRP(Major Function) Table을 보기 위해서 사용하는 명령어입니다.
  - 해당 명령어는 driverscan에 속해 있기 때문에 해당 DRIVER_OBJECT 들을 찾을 수 있으며, 이후 함수 Table을 통해 Cycle을 순회하면서 각 함수들의 목적, 주소, 주소의 소유 Module 들을 출력해 줍니다.
  - 해당 명령어는 IRP 함수의 Inline Hooking 탐지를 지원하며 -v 또는 --verbose Option으로 해당 IRP 주소의 명령어들을 Disassemble 하여 제공합니다.
  - 해당 명령어는 특정 정규 표현식을 사용하지 않는 경우 Default로 모든 Driver에 대해 출력해 줍니다

 > devicetree : Show device tree
  - 장치(_DRIVER_OBJECT.DeviceObject.NextDevice)를 통해 해당 Driver 또는 Device 들의 관계를 보여주며 첨부된 장치(_DRIVER_OBJECT.DeviceObject.AttachedDevice)를 통해 Attach 된 Device 들을 보여줍니다
  - Driver를 "DRV"로, Device를 "DEV"로 표현하며, Attached Device를 "ATT"로 표현합니다.

 > psxview : pslist 및 psscan에서 확인한 프로세스 정보를 비교하여 나열함으로써, 은폐된 프로세스를 탐지하는 명령어입니다.
 ※ 비교대상
  - PsActiveProcessHead linked list
  - EPROCESS pool scanning
  - ETHREAD pool scanning(EPROCESS를 참조)
  - PspCidTable
  - Csrss.exe handle table(Vista,7 에서는 불가, 몇몇 XP image에서는 불가)
  - Csrss.exe internal linked list(Vista,7 에서는 불가, 몇몇 XP image에서는 불가)

  - 해당 열에 0으로 나타난 것은 Process 가 손실된 것을 나타내며, pslist에서 제외된 것을 통해 수상한 것을 확인할 수 있는데, 각각의 프로세스에서 탐지가 되지 않는다면 칼럼에 “False”라고 표시된다.

 > ssdt_ex : Rootkit에 의해 설치된 SSDT hooking에 대한 흔적을 검색해주는 명령어입니다.
  - 자동으로 어떤 SSDT 함수가 Hooking 되었는지 확인해 주며, Hooking kernel driver를 디스크로 추출, IDA Script File 인 IDC File을 Rookit의 함수 Label을 포함하여 생성해 줍니다.
  - idag.exe(Windows), idal(Linux/OS X)가 $PATH에 있으면 IDB 파일을 Kernel driver로부터 생성하여 IDC Script를 실행할 수 있습니다.

  - folder_name을 살펴보면 추출된 Kernel Driver(sys 파일), IDC Script(sys.idc 파일), IDA Database(idb 파일)를 확인할 수 있습니다.
  - IDB File을 열어 "Hook" 단어가 앞에 붙은 함수를 유심히 살펴보면 됩니다.

 > timers : Installed 된 Kernel times(KTIMER)와 관련된 DPC(Deferred Procedure Calls)를 출력해 주는 명령어입니다.
  - Zero Access, Rustock, Stuxnet 의 경우 DPC 를 이용하여 timer 를 등록합니다다. DPC 주소와 KTIMES 를 통해 악성코드가 다양한 방법으로 Kernel 공간에 숨어 있는 것을 빠르게 찾을 수 있습니다

  - Windows XP, 2003, 2008, VISTA 의 경우 times 를 전역 변수에 저장하지만, Windows 7 의 경우 KPCR(Kernel Processor Control Region)에 저장하고 있습니다. 
  - 그렇기 때문에 Windows7 에서 모든 timers 들을 확인 하려면 kpcrscan 을 통해 KPCR 주소들을 --kpcr Option 을 통해 인자로 넣어 주어야 합니다.
  - KPCR 에 따라 다른 timers 의 목록을 볼 수 있으며, 이는 각 Processor 가 자신만의 timers 의 set 을 가지고 있기 때문입니다.

Volatility 볼라틸리티 2.1 Plugins - 윈도우#01

◎ Image Identification : 이미지 식별

Volatility 볼라틸리티 2.1 Plugins - 윈도우#02

◎ Processes and DLLs : 프로세스와 DLLs 분석
Volatility 볼라틸리티 2.1 Plugins - 윈도우#03

◎ Process Memory : 프로세스 메모리 분석
Volatility 볼라틸리티 2.1 Plugins - 윈도우#04

◎ Kernel Memory and Objects : 커널 메모리와 오브젝트 분석
Volatility 볼라틸리티 2.1 Plugins - 윈도우#05

◎ Networking : 네트워크 정보
Volatility 볼라틸리티 2.1 Plugins - 윈도우#06

◎ Registry : 단지 Registry data를 추출하는데 도움을 줍니다.
Volatility 볼라틸리티 2.1 Plugins - 윈도우#07

◎ Crash Dumps, Hibernation and Conversion : 크래쉬 덤프, 하이버네이션 정보확인 및 파일변환
Volatility 볼라틸리티 2.1 Plugins - 윈도우#08

◎ Malware and Rootkits : 맬웨어와 루트킷 분석
Volatility 볼라틸리티 2.1 Plugins - 윈도우#09

◎ Miscellaneous : 기타 등등