[악성코드] 동적 분석 실습 - Immunity debugger를 사용하여

1. 악성코드 동적분석

본 분석은 루마스틸러(Lumma Stealer) 드로퍼 계열로 추정되는 exe 파일을 대상으로 진행하였다.
동적분석 환경은 Windows 7 가상머신(VM) 환경에서 구성하였으며, 분석 도구로 Immunity Debugger를 사용하였다.

초기 분석 단계에서는 악성코드 실행 후 내부 코드 흐름을 확인하기 위해 단일 명령 단위 실행(Step Into, F7)을 반복 수행하였다.

1-1. 초기 코드 흐름 분석

악성코드를 Immunity Debugger에 로드한 뒤 F7(Step Into)을 사용하여 내부 흐름을 추적하였다.

코드를 따라 내려가던 중 특정 루프 형태의 명령어가 반복적으로 실행되는 것을 확인하였다.
이는 일반 프로그램에서 흔히 나타나는 흐름이라기보다는 패커(Packer) 또는 난독화(Obfuscation) 루틴에서 자주 사용되는 구조와 유사하였다.

1-2. MMX 관련 문자열 및 비정상 흐름 확인

이후 F8(Step Over)을 사용하여 메인 루틴으로 추정되는 영역까지 이동하였다.

분석 과정에서 다음과 같은 ASCII 문자열을 확인하였다.

"This program can only be run on processors with MMX support."

해당 문자열은 MMX 명령어 지원 여부를 검사하는 루틴과 관련된 것으로 보이며, 일부 악성코드 및 패커에서 분석 환경 탐지 또는 실행 조건 확인 목적으로 사용되는 경우가 있다.

추가 실행 과정에서는 다음과 같은 오류 메시지가 발생하였다.

Don't know how to step because memory at address 00000000 is not readable.
Try to change EIP or pass exception to program.

당시 레지스터 상태는 다음과 같았다.

EIP = 00000000

이는 CPU 실행 흐름이 NULL 주소(0x00000000)로 이동했음을 의미한다.

즉, 내부적으로 다음과 같은 비정상 흐름이 발생한 것으로 추정된다.

JMP 00000000

정상적인 프로그램에서는 거의 나타나지 않는 흐름이며, 악성코드의 안티디버깅(Anti-Debugging) 또는 패커 내부 예외 처리 루틴에서 자주 사용되는 기법이다.

2. API 브레이크포인트 기반 동적 추적

루마스틸러 드로퍼 계열은 일반적으로 다음과 같은 흐름으로 동작하는 경우가 많다.

VirtualAlloc을 통한 메모리 할당
쉘코드 또는 PE 데이터 복호화
VirtualProtect를 통한 실행 권한 변경
CALL EAX, JMP EAX 등을 이용한 메모리 실행
최종 페이로드(Lumma Stealer) 로드

따라서 주요 Windows API에 브레이크포인트를 설정하여 악성코드의 런타임 동작을 추적하였다.

분석 대상으로 지정한 API는 다음과 같다.

kernel32.VirtualAlloc
kernel32.VirtualProtect
kernel32.WriteProcessMemory
kernel32.CreateProcessA
kernel32.LoadLibraryA
kernel32.GetProcAddress

각 API에 대해 F2를 사용하여 브레이크포인트를 설정한 뒤, F9(Run)를 사용하여 실행 흐름을 추적하였다.

3. VirtualAlloc 호출 분석

실행 도중 kernel32.VirtualAlloc API에서 브레이크가 발생하였다.

호출 당시 스택 정보는 다음과 같았다.

Size = 1000
AllocationType = MEM_COMMIT | MEM_RESERVE
Protect = PAGE_EXECUTE_READWRITE

이는 악성코드가 실행 가능한 메모리 영역(RWX)을 동적으로 할당하고 있음을 의미한다.

특히 PAGE_EXECUTE_READWRITE 권한은 일반 응용프로그램에서는 흔하지 않으며, 쉘코드 실행 또는 메모리 언패킹 과정에서 자주 사용된다.

4. 할당 메모리 영역 분석

Ctrl + F9를 사용하여 API 반환 지점까지 실행한 뒤 레지스터 값을 확인하였다.

EAX = 00340000

이는 VirtualAlloc 호출이 성공적으로 수행되었으며, 주소 0x00340000에 실행 가능한 메모리 영역이 생성되었음을 의미한다.

이후 해당 주소를 Follow in Dump 기능으로 이동하여 메모리 상태를 확인하였다.

그러나 초기 상태에서는 대부분의 메모리 값이 00으로 채워져 있었으며, 아직 실제 Payload 데이터가 기록되지는 않은 상태였다.

즉, 현재 단계에서는:

메모리 할당 완료
아직 복호화 미수행
아직 실제 PE 로딩 전

상태로 판단하였다.

5. 언패킹(Unpacking) 단계 추정

이후 추가 실행 과정에서 기존에 할당된 0x00340000 메모리 영역이 더 이상 사용되지 않는 현상을 확인하였다.

이는 다음과 같은 악성 행위 가능성을 시사한다.

VirtualFree를 통한 메모리 해제
새로운 메모리 영역 재할당
프로세스 할로잉(Process Hollowing)
다단계 쉘코드(Stage Shellcode) 실행
언패킹 이후 새로운 Entry Point(OEP) 이동

추가 분석 중 현재 실행 지점(EIP)이 다음 주소로 이동한 것을 확인하였다.

EIP = 01084DA0

해당 주소는 일반적인 Windows 시스템 DLL 영역(0x75xxxxxx, 0x77xxxxxx)이 아닌 사용자 메모리 영역에 해당하였다.

따라서 이는 다음 중 하나일 가능성이 높다고 판단하였다.

언패킹 완료 후 실제 Payload 코드
쉘코드 실행 영역
Reflective Loading 이후 실행 코드

또한 Memory Map 상에서 Private + Execute 속성을 가진 메모리 영역이 생성될 가능성이 높다고 판단하였다.

6. 종합 분석 결과

본 악성코드는 다음과 같은 전형적인 악성 행위를 수행하는 것으로 분석되었다.

동적 메모리 할당(VirtualAlloc)
실행 권한 변경(VirtualProtect)
메모리 기반 코드 실행
언패킹(Unpacking) 수행
비정상 EIP 흐름 유도
쉘코드 기반 실행 가능성
다단계 드로퍼 구조 가능성

특히 실행 가능한 메모리(RWX)를 할당한 후 실제 Payload를 메모리 내부에서 복호화 및 실행하려는 흐름이 확인되었으며, 이는 루마스틸러(Lumma Stealer) 계열 드로퍼에서 자주 사용되는 방식과 유사하였다.

또한 NULL EIP 예외 및 반복 루프 구조는 분석 방해(Anti-Debugging) 또는 패킹 기법의 일부로 판단된다.

따라서 본 샘플은 메모리 기반 언패킹 및 쉘코드 실행 기법을 사용하는 드로퍼형 악성코드일 가능성이 높은 것으로 분석하였다.

IC tistory