윈도우즈 말웨어 분석 방법론 - artifacts 확보
윈도우즈 플랫폼에서의 말웨어 분석은 점점 더 어려운 작업이 되어 가고 있습니다. Living-Off-The-Land 공격 기법과 같은 탐지 회피를 위한 여러 종류의 공격 기법으로 다분화하면서 한 리서처가 다양한 분야의 말웨어를 분석하는 것이 점점 어려워지고 있으며, 최근에는 PE에 대해서는 행위에 기반한 분석 기법에 의존하는 경향성이 커지고 있습니다. 이러한 분석 기법만으로는 적에 대한 프로파일링이나 공격 의도, 매크로 행위 데이타로 잡히지 않는 조그만한 행동 양식 등을 놓칠 가능성이 많습니다. 말웨어 분석 방법론과 스타일은 굉장히 다양할 수 있습니다. 최근 추세는 EDR 등이 구축된 조직일 경우 EDR의 이벤트를 통해서 이미 말웨어의 많은 행위 데이타가 수집된 상태이므로 깊은 분석을 하지 않는 경우가 많습니다. 하지만, 이러한 경우 threat actor에 대한 프로파일링의 정확도가 떨어지거나 정확한 어트리뷰션이 불가능한 경우가 생기거나, 말웨어의 숨겨진 행위나 마이크로 행위 데이타들에 대해 간과할 가능성이 많습니다. 이 시리즈를 통해서 윈도우즈 말웨어 분석에 대한 명확한 접근 방법들에 대해서 알아 보겠습니다.
모든 threat 들에 대한 프로파일링이나 deep analysis가 필요하지는 않지만, 필요한 경우에 샌드박스 이상의 분석가가 직접 개입한 분석을 할 수 있어야 합니다. 이는 곧 APT 등의 공격 징후 발견이나 commodity malware의 경우에라도 실제 공격으로 인한 피해 상황과 향후 대책 수립에 대증적인 행동 데이타로는 제공하기 힘든 여러 인사이트와 데이타를 제공해 주기 때문입니다.
케이스 스터디: Emotet
이러한 분석 예를 보이기 위해서 최근 몇년간 활발한 활동을 보이고 있는 Emotet 샘플에 대한 분석을 통해서 일반적으로 윈도우즈 시스템에서의 PE 파일 deep analysis가 어떻게 수행될 수 있는 지에 대해서 알아 보겠습니다.
일반적인 행위 패턴
Emotet 자체는 그 동안 많은 분석이 이뤄지고 있어서, 많은 행위 패턴들이 파악 되어 있습니다. 이 특정 샘플 또한 Emotet의 일반적인 행위 유형을 그대로 보여 주며, 다음과 같은 과정을 거쳐서 시스템에 유입되고, persistence를 확보합니다.
Delivery는 주로 피슁 이메일의 링크를 통해서 전달 되며, 사용자가 이 링크를 클릭하고 오피스 문서를 열었을 경우 매크로를 사용하여 코드를 실행합니다. 매크로 사용후 PowerShell이나 여러 Living-Off-The-Land 공격 기법을 여러 형태로 혼용하는 경우 또한 흔합니다. 이러한 오피스 문서를 통한 매크로 실행은 전체 공격의 전달 단계에 불과하고, 최종적인 페이로드는 PE 파일 형태로 구성 되어 있습니다. 결국 Emotet의 최종 행위를 분석하기 위해서는 PE 파일에 대한 자세한 분석이 필요합니다.
샘플
이 실험에 사용된 샘플은 다음과 같습니다.
SHA256: 4d0539b3f9eb7d08f259aee1935e7bd75644579c659ac1be2f103988f763d4a8
이 샘플은 bazaar.abuse.ch에서 다운로드 가능합니다. 이 샘플에 대한 샌드박스 결과는 capesandbox에 자세히 로드 되어 있습니다.
사용 툴들
이 실험에 사용된 툴은 모두 무료이거나 저렴하게 구매할 수 있습니다. 윈도우즈 사용자의 경우 유료용 VMWare 대신 Hyper-V나 샌드박스 환경을 사용할 수도 있습니다.
- Process Explorer
- WinDbg
- 가상화 환경
- VMWare
- Hyper-V
- VirtualBox
- 디스어셈블러
- IDA
- Ghidra
PE 파일
다음 다이어그램에서 설명하듯이 Emotet의 PE 파일은 난독화가 된 상태로 배포 되는 경우가 많습니다. 난독화 이후 해독된 바이너리를 바로 올리는 대신, 많은 경우 중간에 여러 레벨의 쉘코드 레이어를 두어서 분석을 방해합니다. 따라서 다음과 같은 2-3단계 이상의 해독과 reflective DLL loading 과정을 거쳐 공격 모듈이 로딩 되고, C&C와의 통신이 일어 납니다.
Forensic Approach - artifacts의 확보
말웨어 분석의 여러 기법 중에서 먼저 포렌지 어널리시스 분석 기법에 대해서 알아 보겠습니다. PE threat의 경우 여러 분석 방법이 존재하지만, 단지 프로세스의 메모리 스냅샷을 통해서 많은 정보들을 뽑아 낼 수 있습니다.
여러 툴의 사용이 가능하지만, Process Explorer를 통해서도 쉽게 프로세스 이미지 덤프를 얻어 내고, 사후 분석용으로 사용 가능합니다.
-
먼저 가상환경에 해당 말웨어를 복사하고, 실행시킵니다.
-
다음은 Process Explorer를 통해서 타겟 말웨어인 rtmmvrotc.exe 이미지를 파악한 화면입니다.
- 다음과 같이 properties 메뉴를 통해 해당 프로세스에 대한 정보 확인이 가능합니다.
단순한 MFC Application을 가장한 말웨어임을 확인할 수 있습니다. 또한 원래 실행 위치에서 새로운 곳에 랜덤한 이름으로 복사되어 실행 되고 있음을 확인할 수 있습니다.
- 다음은 해당 프로세스의 여러 thread들을 확인한 화면입니다. 총 5개의 thread가 작동중입니다.
Memory Dump
이러한 실제 실행 환경에 대한 디버깅은 정확한 데이타나 행위 데이타를 뽑아 내는 데에는 도움이 되지만, 한번 테스트한 환경을 보존하기 힘들다거나 악성 코드가 실행 되는 환경에서 여러 툴을 구동해야 하는 등의 크고 작은 문제들이 존재합니다. 이러한 문제를 프로세스의 메모리 덤프를 받아 정적 분석을 시행하는 방법으로 해결합니다.
- 다음과 같이 해당 프로세스를 선택하고 right click을 통해서 메뉴에서 Create Dump -> Create Full Dump를 선택합니다.
- 다음과 같이 덤프를 저장할 파일을 선택합니다.
- 이렇게 생성된 dump 파일을 호스트 머신으로 카피하여, WinDbg로 드래그앤 드랍이나 File -> Open Crash Dump 메뉴로 로딩이 가능합니다.
이렇게 준비된 dump 파일을 통해서 이제 사후 분석 작업이 가능해집니다. 이러한 사후 분석 작업은 말웨어에 대한 심층 분석을 통한 추가적인 artifacts 확보와 동시에 추가적인 동적 분석을 돕기 위한 단계로 활용 가능합니다.
심볼
윈도우즈 환경에서는 마이크로소프트사의 여러 심볼들을 이용하여 바이너리에 대한 심화된 분석이 가능합니다. WinDbg 환경에서는 다음과 같은 명령을 통해서 마이크로소프트사의 공개된 심볼 서버를 사용하도록 설정할 수 있습니다.
0:000> .sympath srv*https://msdl.microsoft.com/download/symbols
Symbol search path is: srv*https://msdl.microsoft.com/download/symbols
Expanded Symbol search path is: srv*https://msdl.microsoft.com/download/symbols
************* Path validation summary **************
Response Time (ms) Location
Deferred srv*https://msdl.microsoft.com/download/symbols
.sympath 명령이 성공한 이후 .reload 명령으로 전체 심볼을 릴로드하도록 설정해 줍니다.
0:000> .reload
.......................................................
만약 이러한 심볼 셋업이 제대로 이뤄지지 않았을 경우 다음과 같이 심볼의 여러 데이타를 사용하는 명령들이 실패하는 경우가 있습니다. 많은 경우 이러한 디버깅 명령들은 프로그램의 내부 구조체를 분석하여 동작하는 경우가 많고, 심볼을 통해서 정확한 데이타 구조체에 대한 정보를 뽑아 내기 때문입니다.
0:000> !address 00538800
*************************************************************************
*** ***
*** ***
*** Either you specified an unqualified symbol, or your debugger ***
*** doesn't have full symbol information. Unqualified symbol ***
*** resolution is turned off by default. Please either specify a ***
*** fully qualified symbol module!symbolname, or enable resolution ***
*** of unqualified symbols by typing ".symopt- 100". Note that ***
*** enabling unqualified symbol resolution with network symbol ***
*** server shares in the symbol path may cause the debugger to ***
*** appear to hang for long periods of time when an incorrect ***
*** symbol name is typed or the network symbol server is down. ***
*** ***
*** For some commands to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: ${$ntdllsym}!_PEB ***
*** ***
*************************************************************************
Thread
이렇게 심볼까지 로딩된 이후에 첫번째 단계는 해당 프로세스에 존재하는 thread들을 확인하는 것입니다.
- 다음과 같이 ~*kp 명령을 수행합니다.
- ~ 명령은 thread를 확인하는 명령으로서 ~는 모든 thread에 적용되는 명령을 실행시킨다는 의미입니다. kp는 스택을 확인하는 명령으로서 ~kp는 결국 모든 thread의 콜스택을 보여 줍니다.
0:000> ~*kp
. 0 Id: 964.1288 Suspend: 0 Teb: 00318000 Unfrozen
# ChildEBP RetAddr
00 0019fc3c 75bfac89 ntdll!NtWaitForSingleObject+0xc
01 0019fcb0 75bfabe2 KERNELBASE!WaitForSingleObjectEx+0x99
02 0019fcc4 00538800 KERNELBASE!WaitForSingleObject+0x12
WARNING: Frame IP not in any known module. Following frames may be wrong.
03 0019fd88 005351f5 0x538800
04 0019fd8c 005203da 0x5351f5
05 0019fdf4 00520029 0x5203da
06 0019fe0c 00402a2d 0x520029
07 0019fe40 00402ad4 rtmmvrortc+0x2a2d
08 00000000 00000000 rtmmvrortc+0x2ad4
1 Id: 964.274 Suspend: 0 Teb: 0031e000 Unfrozen
# ChildEBP RetAddr
00 0264fdd8 772462c1 ntdll!NtWaitForWorkViaWorkerFactory+0xc
01 0264ff80 76df62c4 ntdll!TppWorkerThread+0x2a1
02 0264ff94 77270609 kernel32!BaseThreadInitThunk+0x24
03 0264ffdc 772705d4 ntdll!__RtlUserThreadStart+0x2f
04 0264ffec 00000000 ntdll!_RtlUserThreadStart+0x1b
2 Id: 964.628 Suspend: 0 Teb: 00321000 Unfrozen
# ChildEBP RetAddr
00 0274fc74 75c02afa ntdll!NtDelayExecution+0xc
01 0274fcdc 75c02a5f KERNELBASE!SleepEx+0x8a
02 0274fcec 71e9d56c KERNELBASE!Sleep+0xf
03 0274fd0c 71e9d8da winhttp!SafeTerminateDll+0xac
04 0274fd50 77236375 winhttp!FailFastThreadpoolWaitCallback<&SafeTerminateDll>+0x2a
05 0274fdbc 772362ba ntdll!TppExecuteWaitCallback+0x7a
06 0274fddc 7724653a ntdll!TppWaitCompletion+0x8a
07 0274ff80 76df62c4 ntdll!TppWorkerThread+0x51a
08 0274ff94 77270609 kernel32!BaseThreadInitThunk+0x24
09 0274ffdc 772705d4 ntdll!__RtlUserThreadStart+0x2f
0a 0274ffec 00000000 ntdll!_RtlUserThreadStart+0x1b
3 Id: 964.bec Suspend: 0 Teb: 00324000 Unfrozen
# ChildEBP RetAddr
00 0284fdd8 772462c1 ntdll!NtWaitForWorkViaWorkerFactory+0xc
01 0284ff80 76df62c4 ntdll!TppWorkerThread+0x2a1
02 0284ff94 77270609 kernel32!BaseThreadInitThunk+0x24
03 0284ffdc 772705d4 ntdll!__RtlUserThreadStart+0x2f
04 0284ffec 00000000 ntdll!_RtlUserThreadStart+0x1b
4 Id: 964.12f0 Suspend: 0 Teb: 00327000 Unfrozen
# ChildEBP RetAddr
00 0294fdd8 772462c1 ntdll!NtWaitForWorkViaWorkerFactory+0xc
01 0294ff80 76df62c4 ntdll!TppWorkerThread+0x2a1
02 0294ff94 77270609 kernel32!BaseThreadInitThunk+0x24
03 0294ffdc 772705d4 ntdll!__RtlUserThreadStart+0x2f
04 0294ffec 00000000 ntdll!_RtlUserThreadStart+0x1b
- 이 명령을 통해서 첫번째 thread이 0번 thread의 콜스택에서 수상한 frame 들을 확인할 수 있습니다.
. 0 Id: 964.1288 Suspend: 0 Teb: 00318000 Unfrozen
# ChildEBP RetAddr
00 0019fc3c 75bfac89 ntdll!NtWaitForSingleObject+0xc
01 0019fcb0 75bfabe2 KERNELBASE!WaitForSingleObjectEx+0x99
02 0019fcc4 00538800 KERNELBASE!WaitForSingleObject+0x12
WARNING: Frame IP not in any known module. Following frames may be wrong.
03 0019fd88 005351f5 0x538800 <--- 심볼 없음
04 0019fd8c 005203da 0x5351f5 <--- 심볼 없음
05 0019fdf4 00520029 0x5203da <--- 심볼 없음
06 0019fe0c 00402a2d 0x520029 <--- 심볼 없음
07 0019fe40 00402ad4 rtmmvrortc+0x2a2d
08 00000000 00000000 rtmmvrortc+0x2ad4
위에서 보듯이 03 ~ 06까지의 콜스택 프레임의 RetAddr 인자의 심볼과 모듈이 없다는 것입니다. 이러한 경우 여러 다른 의미를 가질 수 있는데, 예를 들어 JIT (Just-In-Time) 코드의 경우도 이렇게 모듈 이름이 없는 힙 영역에서 코드가 실행되는 경우가 많습니다. 이 케이스의 경우에는 말웨어가 쉘코드를 힙 영역에 풀거나 reflective DLL loading 기법을 사용하여 추가적인 PE 말웨어를 메모리에 로딩한 경우입니다. 이 경우 이 주소 영역을 확인하여 해당 메모리 영역을 파일로 저장하여 artifact 확보가 가능합니다.
예를 들어 프레임 03에 나온 주소인 0x538800경우 다음과 같은 명령으로 해당 메모리 영역의 속성과 위치등을 확인 가능합니다.
0:000> !address 00538800
Mapping file section regions...
Mapping module regions...
Mapping PEB regions...
Mapping TEB and stack regions...
Mapping heap regions...
Mapping page heap regions...
Mapping other regions...
Mapping stack trace database regions...
Mapping activation context regions...
Usage: <unknown>
Base Address: 00531000
End Address: 0053a000
Region Size: 00009000 ( 36.000 kB)
State: 00001000 MEM_COMMIT
Protect: 00000020 PAGE_EXECUTE_READ
Type: 00020000 MEM_PRIVATE
Allocation Base: 00530000
Allocation Protect: 00000004 PAGE_READWRITE
Content source: 1 (target), length: 1800
주소 0x00538800이 존재하는 영역은 0x00531000부터 0x0053a000로서 0x9000 바이트를 가지고 있습니다. 이 메모리 영역은 PAGE_EXECUTE_READ 속성을 가지고 있습니다. 즉 해당 메모리 영역은 실행 가능한 영역으로서 MEM_PRIVATE 타입을 가지고 있습니다.
MSDN의 MEMORY_BASIC_INFORMATION structure 문서에 의하면 메모리 타입들은 다음과 같은 의미를 가집니다.
| Type | Definition | Meaning |
|---|---|---|
| MEM_IMAGE | 0x1000000 | Indicates that the memory pages within the region are mapped into the view of an image section. |
| MEM_MAPPED | 0x40000 | Indicates that the memory pages within the region are mapped into the view of a section. |
| MEM_PRIVATE | 0x20000 | Indicates that the memory pages within the region are private (that is, not shared by other processes). |
MEM_PRIVATE은 다른 프로세스의 공유되지 않는 이 프로세스만이 사용하는 메모리 영역이라는 것을 알 수 있습니다. 윈도우즈 시스템에서는 DLL 들의 공유 모듈들의 경우 MEM_IMAGE 타입으로 다른 프로세스 사이에 공유가 가능하게 하는 방법으로 메모리 사용량을 줄이는 기법을 사용하고 있습니다. 따라서 MEM_PRIVATE 영역에서 나온 코드의 경우 이러한 DLL이 아닐 가능성이 높아집니다.
Artifacts Extraction
위의 콜스택 확인으로 얻어진 정보를 바탕으로 !address 명령을 사용하여 프로세스에 존재하는 의심스러운 실행 영역들을 조사해 볼 수 있습니다.
- 다음과 같이 !address 명령에 -f로 필터를 달아 줍니다. PAGE_EXECUTE 필터를 통해서 실행 가능한 메모리 영역만을 덤프해 줍니다.
0:000> !address -f:PAGE_EXECUTE
BaseAddr EndAddr+1 RgnSize Type State Protect Usage
-----------------------------------------------------------------------------------------------
401000 406000 5000 MEM_IMAGE MEM_COMMIT PAGE_EXECUTE_READ Image [rtmmvrortc; "C:\Users\tester\AppData\Local\rtmmvrortc\rtmmvrortc.exe"]
511000 513000 2000 MEM_IMAGE MEM_COMMIT PAGE_EXECUTE_READ Image [mshta; "C:\Windows\System32\mshta.exe"]
520000 52a000 a000 MEM_PRIVATE MEM_COMMIT PAGE_EXECUTE_READWRITE <unknown> [.....X..........]
531000 53a000 9000 MEM_PRIVATE MEM_COMMIT PAGE_EXECUTE_READ <unknown> [....S..A...A..8.]
2180000 21c1000 41000 MEM_PRIVATE MEM_COMMIT PAGE_EXECUTE_READWRITE <unknown> [MZ..............]
53a21000 53a54000 33000 MEM_IMAGE MEM_COMMIT PAGE_EXECUTE_READ <unknown> [................]
53a81000 53abf000 3e000 MEM_IMAGE MEM_COMMIT PAGE_EXECUTE_READ <unknown> [................]
53b01000 53b04000 3000 MEM_IMAGE MEM_COMMIT PAGE_EXECUTE_READ <unknown> [................]
53b07000 53b08000 1000 MEM_IMAGE MEM_COMMIT PAGE_EXECUTE_READ <unknown> [..p.S3...A......]
6c921000 6c990000 6f000 MEM_IMAGE MEM_COMMIT PAGE_EXECUTE_READ Image [apphelp; "C:\Windows\System32\apphelp.dll"]
6f5a1000 6f5a3000 2000 MEM_IMAGE MEM_COMMIT PAGE_EXECUTE_READ Image [dpapi; "C:\Windows\System32\dpapi.dll"]
6f6a1000 6f6a4000 3000 MEM_IMAGE MEM_COMMIT PAGE_EXECUTE_READ Image [winnsi; "C:\Windows\System32\winnsi.dll"]
6f6b1000 6f6bb000 a000 MEM_IMAGE MEM_COMMIT PAGE_EXECUTE_READ Image [ondemandconnroutehelper; "C:\Windows\System32\ondemandconnroutehelper.dll"]
6fea1000 6ff08000 67000 MEM_IMAGE MEM_COMMIT PAGE_EXECUTE_READ Image [dnsapi; "C:\Windows\System32\dnsapi.dll"]
...
76df0000 76e54000 64000 MEM_IMAGE MEM_COMMIT PAGE_EXECUTE_READ Image [kernel32; "C:\Windows\System32\kernel32.dll"]
76ec1000 76fa8000 e7000 MEM_IMAGE MEM_COMMIT PAGE_EXECUTE_READ Image [crypt32; "C:\Windows\System32\crypt32.dll"]
77041000 77051000 10000 MEM_IMAGE MEM_COMMIT PAGE_EXECUTE_READ Image [win32u; "C:\Windows\System32\win32u.dll"]
77061000 7709c000 3b000 MEM_IMAGE MEM_COMMIT PAGE_EXECUTE_READ Image [shlwapi; "C:\Windows\System32\shlwapi.dll"]
770b1000 771e6000 135000 MEM_IMAGE MEM_COMMIT PAGE_EXECUTE_READ Image [gdi32full; "C:\Windows\System32\gdi32full.dll"]
77211000 7731c000 10b000 MEM_IMAGE MEM_COMMIT PAGE_EXECUTE_READ Image [ntdll; "C:\Windows\System32\ntdll.dll"]
수 많은 영역들이 리스트 되는데, Type이 MEM_IMAGE나 Usage가 Image로 되어 있는 경우는 프로세스에서 DLL을 로딩해서 올린 경우로서 그 외의 Type 이 MEM_PRIVATE이면서 “unknown” 영역들이 악성코드들이 존재할 가능성이 높은 영역들입니다. 윈도우즈 process에서 아무런 의미 없이 Execute 비트가 추가된 경우는 보안상의 문제가 되기도 하므로 DLL이 아닌 Executable 영역은 항상 의심스러운 영역입니다.
- 결국 다음과 같은 세 영역에 악성 코드 모듈들이 존재할 가능성이 높다고 판단됩니다. 특히 0x2180000 영역은 MZ 문자열로 시작하는 것으로 보아서 reflective DLL loading을 통해서 로딩된 악성 코드 모듈일 가능성이 높은 것으로 보입니다.
520000 52a000 a000 MEM_PRIVATE MEM_COMMIT PAGE_EXECUTE_READWRITE <unknown> [.....X..........]
531000 53a000 9000 MEM_PRIVATE MEM_COMMIT PAGE_EXECUTE_READ <unknown> [....S..A...A..8.]
2180000 21c1000 41000 MEM_PRIVATE MEM_COMMIT PAGE_EXECUTE_READWRITE <unknown> [MZ..............]
- 이렇게 메모리 영역이 확인된 후에는 해당 영역의 메모리 내용을 파일로 저장하는 과정을 거칩니다. 예를 들어 0x00531000 메모리 영역은 다음과 같이 L에 길이 인자를 주어 파일로 저장이 가능합니다.
0:000> .writemem d:\00531000.dmp 00531000 L00009000
Writing 9000 bytes..................
Shellcode Analysis
이렇게 추출된 파일을 바탕으로 추가적인 분석이 가능합니다. Reflective DLL loading으로 로딩된 파일들도 존재하지만, 일단 쉘코드부터 분석을 수행합니다.
- 다음과 IDA 등의 디스어셈블러를 통해서 해당 파일을 로딩해 줍니다. 해당 쉘코드 파일의 경우 파일의 메타 데이타가 존재하지 않기 때문에 해당 시스템의 bitness나 아키텍쳐를 수동으로 선택해줍니다. 이 경우 MetaPC 프로세서에 32비트로 선택할 경우 무난히 디스어셈블이 가능합니다.
- 다음과 같이 쉘코드의 경우 강제 analysis를 수행해 주고 영역들을 코드로 변경해 주면, 대부분 디스어셈블이 되면서, 읽을 수 있는 형태로 변환됩니다.
Rebase
쉘코드 자체에는 메타 데이타가 존재하지 않기 때문에 base 주소가 0으로 세팅됩니다. 이 경우 메모리 주소 0x00531000에서 추출한 코드이므로, 베이스를 rebase해주어 향후 작업을 수월하게 진행할 수 있도록 합니다.
- 다음과 깉이 Edit -> Segments -> Rebase program 명령을 사용하여 rebase를 시행합니다.
- Rebase 다이얼로그가 뜨면, Value에 0x00531000 값을 입력해 줍니다.
- Rebase가 끝나면 다음과 같이 base 주소가 변경됩니다. 이로서 WinDbg 세션과 IDA 세션 둘 사이에 주소가 일치하도록 만들 수 있습니다.
이로서 이제 쉘코드 분석을 위한 기본 단계가 모두 수행되었습니다.
결론
이로서 윈도우즈 말웨어 심화 된 분석을 위한 한 방법론에 대해서 입문하게 되었습니다. 윈도우즈 말웨어의 경우 수많은 툴과 방법론들이 존재하고 어떠한 APT 공격 모듈들의 경우 정확한 리버스 엔지니어링을 위해서 수많은 시간을 소비하기도 합니다. 여기에서 소개해 드리는 방법은 윈도우즈의 기본적인 툴셋들을 이용하여 체계적으로 artifacts 들을 확보하고, 샌드박스등을 사용해서 얻기 힘든 고급 정보들을 추출하기 위한 방법론입니다.
앞으로 이렇게 추출된 쉘코드와 reflective DLL loading으로 로딩되어 있는 모듈들에 대한 분석 방법론에 대해서 설명할 예정입니다.
트레이닝
다른그림은 Threat 인텔리젼스와 지식 제공 회사로서 다음과 같은 Windows Mitigation과 커널과 관련된 트레이닝을 제공합니다. 많은 관심 바랍니다.