프로세스를 공격하는 악성코드에 대한 이해 및 방어를 위해 서술한 문서(오래된 문서라 현재는 통용되지 않을 수 있습니다)

1. 프로세스 방어

2. ● 목 차
2
 CreateRemoteThread
 _beginThreadEx
 _beginThreadEx을 이용한 dll Injection 확인
 Level1 : IAT(Import Address Table) Hook Detection
 Dll 모듈 정보를 얻는데 쓰이는 API, 구조체
 Level2 : 쓰레드 생성 감지 및 Dll 주입 여부 감지
 Level3 : 비인가 코드 감지
 결론

3. ● CreateRemoteThread
3
 CreateRemoteThread
 타프로세스에서 타겟 프로세스로 쓰레드를 생성하기 위해 호출하는 API
 자신의 프로세스에서 쓰레드를 생성하기 위해 호출하는 beginThreadEx 함수와 궁극적으로 같은 역할을 한다.
 _beginThreadex
 uintptr_t _beginthreadex( void *security, unsigned stack_size, unsigned ( *start_address )( void * ),
void *arglist, unsigned initflag, unsigned *thrdaddr );
 start_address : Start address of a routine that begins execution of a new thread.
For _beginthread, the calling convention is either __cdecl or __clrcall; for _beginthreadex,
it is either __stdcall or __clrcall.
 stack_size : Stack size for a new thread or 0.
 arglist : Argument list to be passed to a new thread or NULL.

4. ● CreateRemoteThread
4
 _beginthreadex를 이용한 dll 로딩 시연
 HDModule 솔루션의 HDSample1, HDSample2 프로젝트 참조
 HDSample1 : Beginthreadex의 기본적인 사용 예제
 HDSample2 : Beginthreadex의 시작 엔트리를 LoadLibrary로 지정해서
Win32HooK.dll 인젝션하는 예

5. 5
Level 1 - IAT Hook Detection

6. ● Level1 – IAT Hook Detection
6
 IAT(Import Address Table)
 프로세스에서 필요로 하는 OS API, 또는 유저가 만든 모듈의 함수를 호출하기 위한 함수 주소 리스트 테이블
 로더가 프로세스를 메모리에 매핑시킬 때 필요 함수 주소를 결정한다.
 프로세스에 로드된 모듈 정보
 커널에는 해당 프로세스가 어떠한 모듈들을 로드했는지에 대한 정보를 유지하고 있다.
 OS는 이런 로드된 모듈들의 정보를 얻을 수 있도록 API를 제공하고 있다.

7. ● Level1 – IAT Hook Detection
7
 IAT는 어디에?? – PE 파일 구조
DOS_HEADER
MS-DOS Stub Program
PE
FILE_HEADER
OPTIONAL_HEADER
DATA_DIRECTORY[16]
SECTION_TABLE_HEADER[n]
.text
.data
.idata
.other
도스 헤더
NT 헤더
섹션들
섹션 테이블

8. ● Level1 – IAT Hook Detection
8
 IAT는 어디에?? – Import Section 에서 IAT 찾기
IMAGE_IMPORT_DESCRIPTOR
IMAGE_IMPORT_DESCRIPTOR
……
IMAGE_THUNK_DATA
IMAGE_THUNK_DATA
Name
Original First Thunk
First Thunk
IMAGE_IMPORT_DESCRIPTOR
……
IMAGE_THUNK_DATA
IMAGE_THUNK_DATA
……
Kernel32.dllIMPORT SECTION
……
IMAGE_IMPORT_BY_NAME
IMAGE_IMPORT_BY_NAME
……
IMAGE_THUNK_DATA
IMAGE_THUNK_DATA
Function Address
Function Address
……

9. ● Level1 – IAT Hook Detection
9
 Dll 모듈 정보를 얻는데 쓰이는 API, 구조체
 EnumProcessModules : 프로세스에 로드된 모듈의 핸들 리스트를 구함
 GetModuleFileNameEx : 모듈 핸들을 이용해서 로드된 모듈의 이름을 구함
 GetModuleInformation : 모듈 핸들을 이용해서 모듈의 정보를 구한다.
 MODULEINFO 구조체
 typedef struct _MODULEINFO {
LPVOID lpBaseOfDll; : 모듈의 베이스 주소
DWORD SizeOfImage; : 모듈의 크기
LPVOID EntryPoint; : 모듈의 엔트리 포인트
} MODULEINFO, *LPMODULEINFO;
 모듈 정보를 이용하면 IAT Hook을 감지할 수 있다.

10. ● Level1 – IAT Hook Detection
10
 IAT Hook Check Procedure
 임포트 섹션에서 각각의 모듈에 대한 IAT를 구한다.
 만약 Kernel32.dll에 관한 IAT라면 각각의 함수들은 Kernel32.dll이 로드된 메모리 공간에 위치해야 한다.
 만약 해당 모듈의 메모리 공간에서 벗어나 있다면 해당 함수는 후킹당했다고 판별할 수 있다.
 각 모듈들의 메모리 점유 공간은 GetModuleInformation에서 얻은 ModuleInfo 구조체 정보로 파악 가능
 모듈의 메모리 공간 점유 크기
 시작 주소 : lpBaseOfDll
 마지막 주소 : lpBaseOfDll + SizeOfImage
 후킹 판단 여부
function address < lpBaseOfDll 또는 function address > lpBaseOfDll + SizeOfImage

11. ● Level1 – IAT Hook Detection
11
 IAT Hook Check 구현
 HDModule 솔루션의 HDSample3 프로젝트 참조

12. ● Level 2 – 쓰레드 생성 감지 및 Dll Injection 감지
12
 IAT Hook Detection의 한계
 모듈 정보를 얻기 위한 API 자체가 후킹이 되었다면 IAT Hook Detection은 무용지물
 대비책
 모듈 정보를 얻기 위해 쓴 API가 리턴한 값들 검증(주소값)
 이러한 API 자체를 후킹하여 로직을 추가한 후 원하는 결과를 리턴하지 않으면 후킹으로 간주

13. 13
Level 2 – 쓰레드 생성 감지 및 Dll Injection 감지

14. ● Level 2 – 쓰레드 생성 감지 및 Dll Injection 감지
14
 Dll Injection Flow
타겟 프로세스
0x00000000
0x80000000
Kernel32.dll : LoadLibrary(0xaaaaaaaa)
BaseThreadInitThunk
- EAX 레지스터(Thread Entry Point 값을 가지고 있음)
로드된 DLL. 로드되면서 프로세스를 휘저음

15. ● Level 2 – 쓰레드 생성 감지 및 Dll Injection 감지
15
 Legal Thread?? – 시나리오 1
성벽
합법적 작업장소
수상한 지역

16. ● Level 2 – 쓰레드 생성 감지 및 Dll Injection 감지
16
성벽
합법적 작업장소
수상한 지역
후후후. 좋아 성안의 정보를 빼내자.
OK

17. ● Level 2 – 쓰레드 생성 감지 및 Dll Injection 감지
17
 Legal Thread?? – 시나리오 2
성벽
합법적 작업장소
수상한 지역
검문소

18. ● Level 2 – 쓰레드 생성 감지 및 Dll Injection 감지
18
성벽
합법적 작업장소
수상한 지역
검문소
Where? Place A
Place A
Place B
Place C
Place D
Place E

19. ● Level 2 – 쓰레드 생성 감지 및 Dll Injection 감지
19
성벽
합법적 작업장소
수상한 지역
검문소
Okay!!
Thanks
Place A
Place B
Place C
Place D
Place E
검문소

20. ● Level 2 – 쓰레드 생성 감지 및 Dll Injection 감지
20
성벽
합법적 작업장소
수상한 지역
검문소
Where? Place D
Place A
Place B
Place C
Place D
Place E

21. ● Level 2 – 쓰레드 생성 감지 및 Dll Injection 감지
21
성벽
합법적 작업장소
수상한 지역
검문소
You
Die!!
Huhhh
Place A
Place B
Place C
Place D
Place E

22. ● Level 2 – 쓰레드 생성 감지 및 Dll Injection 감지
22
 Dll Injection Detection
타겟 프로세스
0x00000000
0x80000000
Kernel32.dll : LoadLibrary(0xaaaaaaaa)
BaseThreadInitThunk
MyCheckRoutine
BaseThreadInitThunk Start
MyCheckRoutine으로 점프
EAX 레지스터 값과 LoadLibrary
주소 값 비교
Dll Injection Detected
Kill Thread!!
같다면
- EAX 레지스터(Thread Entry Point 값을 가지고 있음)
(1)

23. ● Level 3 – 비인가 코드 감지
23
 Dll Injection 주입 프로그램 구현
 DllInjection 폴더의 솔루션 파일을 통해 실행
 SampleCreateRemoteThread.exe 프로세스이름 형태로 실행해서 해당 프로세스에 DLL 삽입
 Win32Hook 프로젝트 : 삽입될 DLL 모듈

24. ● Level 3 – 비인가 코드 감지
24
 코드 주입 및 불법 쓰레드 체크 루틴 회피 확인
 HDModule 솔루션의 HDSample4 프로젝트를 통해 확인
 getchar() 함수에서 프로그램이 멈춰 있을 때 dll 인젝션 프로그램을 실행해서 dll 인젝션을 감지하는
것을 확인

25. 25
Level 3 – 비인가 코드 탐지

26. ● Level 3 – 비인가 코드 탐지
26
비인가 코드 탐지의 필요성
 Level 2에서는 LoadLibrary 등의 알려진 함수 주소를 이용하여 불법 쓰레드를 탐지해 내었다.
 LoadLibray 함수 등을 이용하지 않고 타겟 프로세스에 실제 코드 데이터를 쓴 후 쓰레드의 엔트리 포인트
를 그 코드 데이터의 주소로 설정한다면 Level2의 알고리즘은 무용지물이 된다.
 궁극적으로 쓰레드의 엔트리 포인트가 비정상인지를 판별해 낼 수 있는 방법이 필요하다.

27. ● Level 3 – 비인가 코드 탐지
27
성벽
합법적 작업장소
수상한 지역
검문소
Legal
Place. But
No Order
Set My
Directive!!
Place A
Place B
Place C
Place D
Place E
Place D
Oh My
God!!

28. ● Level 3 – 비인가 코드 탐지
28
 Level2의 LoadLibrary 함수 체크를 피하기
타겟 프로세스
0x00000000
0x80000000
Kernel32.dll : LoadLibrary(0xaaaaaaaa)
BaseThreadInitThunk
MyCheckRoutine
BaseThreadInitThunk Start
MyCheckRoutine으로 점프
EAX 레지스터 값과 LoadLibrary
주소 값 비교
정상적인 쓰레드이군!!
실행….
Virtual Query 함수들에 의해서
주입된 코드 블럭
(1) (2)(3)
(4)

29. ● Level 3 – 비인가 코드 감지
29
 Dll Injection 주입 프로그램 구현(단 시작 엔트리가 LoadLibrary가 아니라 자신이 타 프로
세스에 넣은 코드 데이터임)
 ThreadInjection 폴더의 솔루션과 HDMoudle의 HDSample4 프로젝트를 이용하여 해당 인젝션을
감지하지 못하는 것을 확인

30. ● Level 3 – 비인가 코드 탐지
30
로더가 실행파일을 메모리에 로드할 경우
 로더는 프로세스의 정보를 가상 주소에 매핑
 가상주소에 매핑될 때 프로세스의 각각의 영역은 메모리타입이라는 정보를 가지게 됨
 PE 구조 형태를 띠는 실행파일은 코드 섹션을 가지고 있는데 이 코드섹션이 프로그램의 코드에 해당함
 이 코드섹션이 메모리에 로드되면 이 코드 섹션의 영역 또한 메모리 타입을 지니게 됨
 쓰레드의 초기 시작 관련 코드는 이 코드 섹션에 배치되어 있음
메모리 타입
 디버깅할 때 보이는 주소는 가상 주소로 실제의 물리 주소가 아니다.
 가상 주소는 세그멘테이션과 페이징 기법에 의해 물리 주소로 변경된다.
 32비트 PC는 4기가의 가상 주소 공간을 가지고 있으며 이 공간은 페이지에 의해 기술되어 진다.
 페이지에는 실제 물리 주소 값과 메모리 타입 등의 정보를 가지고 있다.
 로더에 의해 메모리에 올려지는 코드섹션은 독특한 메모리 타입 값을 가지게 된다.

31. ● Level 3 – 비인가 코드 탐지
31
 메모리 타입(계속)
#define MEM_PRIVATE 0x20000 : VirtualAllocEx 등의 함수로 타겟 프로세스에 코드를 주입했을 때
해당 코드 블록을 위한 공간은 힙에 할당된다. 이런 공간의 메모리는 MEM_PRIVATE 속성을 갖는다.
 #define MEM_MAPPED 0x40000
 #define SEC_IMAGE 0x1000000
 #define MEM_IMAGE SEC_IMAGE : 로더등에 의해 코드 섹션 등이 메모리에 로드될 경우
해당 메모리는 MEM_IMAGE의 속성을 갖는다.
따라서 코드가 주입된 영역의 메모리 타입을 검사해서 그 타입이 MEM_PRIVATE이라면
불법 쓰레드 루틴이 실행되고 있다고 간주할 수 있다.

32. ● Level 3 – 비인가 코드 탐지
32
 디폴트 쓰레드 엔트리와 주입된 코드 블록 엔트리의 비교
타겟 프로세스
0x00000000
0x80000000
Virtual Query 함수들에 의해서 주입된 코드 블록
메모리 타입 : MEM_PRIVATE
합법적인 쓰레드의 Thread Entry Point
메모리 타입 : MEM_IMAGE
Heap 영역
코드 섹션 영역

33. ● Level 3 – 비인가 코드 탐지
33
성벽
합법적 작업장소
수상한 지역
검문소
Place A
Place B
Place C
Place D
Place E
Place D
You can’t
your job
there. Die!!
Validation Ok
Validation Ok
Validation Ok
Validation ?? Huhhh

34. ● Level 3 – 비인가 코드 감지
34
 코드 주입 및 불법 쓰레드 막기 확인
 HDModule 솔루션의 HDSample5 이용
 HDCreateRemoteThread.cpp의 24번째 라인의 주석을 풀어서
메모리 타입에 의한 dll 인젝션 감지를 활성화 시키도록 한다.

35. 35
결 론

36. ● 결 론
36
Dll이 먼저 주입되는 상황을 100% 막는 것은 현재 구조상 불가능
 그러나 지금까지 구현한 모듈이 먼저 로드되어 진다면 원격 쓰레드를 통한 코드 주입을 원천적으로 막는
것이 가능하다.
 프로세스가 dll 등에 의해 코드 주입이 이뤄졌다고 해도 IAT Hook Detection은 여전히 유효하다.
 WindowHook, 코드변조, 메모리 조작 등 보안모듈의 면모를 갖추기 위해서는 여러 요소가 필요하나 지금
까지 구현한 모듈의 내용이 가장 중요하다고 생각.
해결해야될 과제
 해당 모듈은 WindowXP에서만 동작. Window7에서도 돌아가도록 만들기 위해 현재 시그너처를 찾고 있음
(IAT Hook 또한 커널 DLL의 추가와 함수 위치의 변경, 함수 포워딩 등에 의해 Window7에서 조금 부정확함)