[리버싱 실습] 악성코드 샘플 분석 (Malware Bytes 훈련용 샘플 사용)

728x90

샘플 정보 : "Malware Bytes" 백신회사에서 공개한 악성코드 분석 훈련용 샘플

확인할 정보

Anti-debugging, Anti-VM 등 분석 방해 기능
데이터의 인코딩/디코딩
프로세스 할로잉 기법

1. 동적 분석 - 샘플 실행 결과 확인

샘플 실행 시 위와 같은 실행 결과가 보여진다.

상세 분서에서는 x64dbg라는 디버거를 통해 분석을 진행한다.

2. 문자열 검색

위에서 동적 분석에 확인했던 문자열 "I am so sorry, you failed! :("을 찾아서 (분석에 필요한) 시작 위치를 확인한다.

[다음을 찾기] → [현재 모듈] → [문자열 참조]

"I am so sorry, you failed! :(" 확인

[덤프해서 따라가기]로 분석에 필요한 위치로 이동

점프가 취해지기 전 (jne)을 중단점(F2)으로 설정

3. 안티 디버깅

jne(jump not equal) 전 call 함수 (call 0x004085E9, call 0x004014F0)를 확인한다.

0X004014F0 함수에서 rdtsc 명령어를 사용하여 실행되는 시간을 저장하는 것이 확인되었다.

call 0x004014F0 함수 확인.

두 가지 체크할 사항이 확인된다.

rdtsc 명령어 사용을 통해 실행 시간 정보를 eax와 edx에 저장하여 8개의 함수를 지나간 후에 call 0x401BC0에서 비교한다.

function #1: call 0x4019D0 - 분석

ⓐ IsDebuggerPresent() 사용

IsDebuggerPresent()는 지금 동작 중인 시스템이 디버거 모드로 실행중인지 판단하는 API이다.

이 API를 통해 디버깅 모드 여부를 판단하여 디버깅 중이면 eax에 1을 저장한다. 그 후 test 명령어로 eax를 검사하여 (디버깅 → ZF = 0) CMOVNE 명령어로 ZF가 0이면 ESI에 1이 저장된다.

ⓑ CheckRemoteDebuggerPresent 사용

CheckRemoteDebuggerPresent()는 반환 값이 0이면 정상.

CheckRemoteDebuggerPresent() API를 통해 디버깅 모드 여부를 판단하여 디버깅 중이면 eax와 [ebp-4]의 위치에 1이 저장된다. 비교를 통해 현재 디버깅 중이면 ESI 값이 1로 증가 된다. ESI가 2이면 ZF가 1로 설정된다(ⓐ와 ⓑ를 거쳐 2로 된다). sete 명령어로 ZF가 1이면 eax를 1로 설정하고, 아니면 eax가 0이 된다

ⓒ 플래그 값 설정

앞에 두 단계 ⓐ, ⓑ를 거쳐서 현재 디버깅 중인지 판단하여, 디버깅 중이라면 ⓒ 부분이 실행된다.

이 부분은 훈련용 샘플이라서 특정 주소에 플래그 값을 설정하고 있다. [429F74]에 안티디버깅 기법을 찾은 횟수를 저장하였다.

function #1: call 0x4019D0 - 안티 디버깅 우회

9개의 함수들을 분석 중에 공통된 특징 하나를 발견하였다. 모든 함수에서 je(if문)을 거쳐서 [429F74]를 호출하여 무언가를 저장한다.

이 je(if문)에서 점프가 취해지지 않도록 je를 어셈블을 통해 ‘nop’상태로 인코딩 해주었다. 다음 나머지 8개의 함수들에서도 동일하게 ‘nop’으로 인코딩하여 점프가 취해지지 않고 차례대로 동작되게 하였다.

function #2: call 0x401A50 - 분석

ⓐ RaiseException() 사용

RaiseException() 함수: 매개변수 0x40010006를 사용하는 경우 디버깅 여부를 판단하여 디버깅 중 일 경우 예외가 발생하여 현재 시스템이 디버깅 모드인지 파악할 수 있다

ⓑ SHE 핸들러 설정

SEH 핸들러를 설정하면 예외사항이 발생할 때 SEH로 흐름이 바뀐다.

여기에서는 SEH 핸들러 주소 를 0X408EE0으로 설정하였다.

이 코드가 포함된 함수 구간에서 오류가 발생하면 0x408EE0의 코드가 수행된다.

ⓐ에서 RaiseException() 함수를 호출하면 예외사항이 발생하여 이 주소로 이동한다.

예외 사항을 회피하면 ⓐ 부분 마지막 코드인 “jmp 0x401AAA”로 이동하고 플래그 값을 설정한다. 0x429F74 값은 다시 1 증가된다

function #2: call 0x401A50 - 안티 디버깅 우회

function #3: call 0x401B00 - 분석

ⓐ GetThreadContext() 함수 사용

getThreadContext() : 현재 실행중인 쓰레드에 대한 컨텍스트를 가져와 수정
OpenThread()로 받아온 핸들과 [edp-2D0] 주소를 매개변수로 전달
ContextFlags [edp-2D0]는 0x10010이고, 4byte씩 뒤의 주소가 DR0~DR3 레지스터임
DR0부터 DR3까지 하나라도 중단점이 설정되어 있으면 ecx가 0이 아닌 값을 가짐

ⓑ 플래그 루틴

OR 연산 결과 ecx가 0이 아니면 ZF가 0이 됨
SETNE 명령으로 ebx에 1이 저장 / ebx가 1(zf=0)이면, eax에 1이 저장
결국 디버깅 중이면 아래 코드가 실행되지 않음 / [0x429F74] 값은 다시 1증가

function #3: call 0x401B00 - 안티 디버깅 우회

function #4: call 0x401C20 - 분석

ⓐ PEB 구조체의 멤버를 통한 안티 디버깅 탐지

PEB 구조체의 멤버 변수로 디버거의 동작 유무를 탐지
0x02 : BeingDebugged (1byte) / 0x68 : NtGlobalFlag (4byte)
PEB 구조체는 fs:[30]에 있음
0x68번째 값이 0이 아니면 ecx = 1
0x02번째 값이 0이 아니면 ecx 값을 1 증가

ⓑ 플래그 루틴

ecx가 2이면 eax가 1로 설정됨
eax가 1이 아니면 플래그 루틴이 수행되지 않음
[0x429F74] 값은 다시 1증가

function #4: call 0x401C20 - 안티 디버깅 우회

4. 안티 가상머신

QueryDosDevice() API 활용

MS-DOS 장치 정보를 가져오거나 VBoxMinRdrDN, VBoxGuest와 같은 가상머신 장치이름이 포 함되어 있는지 확인

가상머신 문자열이 있으면 쉽게 안티 가상머신 기법이 사용되는지를 알 수 있음

→ 중요한 문자열을 해시값으로 표현

function #5: call 0x402730 - 분석

ⓐ 문자열 해시값 처리

- 문자열 (VBoxMiniRdrDN) 해시 처리

- 문자열 (VBoxGuest) 해시 처리

function #5: call 0x402730 - 안티 디버깅 우회

2.3.2 function #6: call 0x402880 - 분석

ⓐ Virtual Box와 관련된 레지스트리 키 확인

- RegOpenKeyA() API를 사용 -> 레지스트리 키의 정보 확인

ⓑ 가상머신과 디버깅 관련 모듈 탐지

- CreateToolhelp32Snapshot() API 사용 – 32bit 프로세스의 스냅샷을 가져옴

: 현재 프로세스의 정보를 가져옴

- Module32First() API 사용 – 프로세스와 관련된 첫 모듈 정보를 검색

: 모듈 정보의 해시값을 변환하고 Module32First()함수와 Module32Next()함수로 검색

→ 두 API를 사용하여 현재 프로세스의 스냅샷을 가져와서 프로세스 정보에서 특정 이름의 프로 세스를 확인하여 가상환경 관련된 프로세스의 존재인지 확인한다.

function #6: call 0x402880 - 안티 디버깅 우회

function #7: call 0x402B70 – 분석

Module32First

function #7: call 0x402B70 - 안티 디버깅 우회

function #8: call 0x402DE0 – 분석

Process32First

function #8: call 0x402DE0 - 안티 디버깅 우회

function #9: call 0x401BC0 - 분석

경과시간 비교

function #9: call 0x401BC0 - 안티 디버깅 우회

5. rdtsc 명령어로 경과 시간 비교 (안티 디버깅)

6. 파일 패치

9개 함수를 다 우회하고 나면 파일 패치를 통해 새 파일 생성

첫 번째 우회 결과

두 번째 우회의 힌트로 사용할 수 있는 문자열 “You are on the right track!” 메시지 박스 확인

7. 패치 파일로 디버깅 진행

앞에서 얻었던 자열 검색하여 해당 위치로 이동

앞에서 1차 디버깅 우회로 얻었던 두 번째 메시지박스에 “Better luck next time!”을 힌트로 해당 문자열 위치로 이동하여 그 위치에서 중단점(f2)을 걸어준다.

디버깅 다시 진행

첫 번째 문자열 “I am so sorry...”가 나오기 전 jne와 안티 디버깅이 동작하던 call 함수에도 중단 점(f2)을 건 후에 실행시켜보았다

암호화 상태였던 url 값이 우회하고 지나온 후에 복호화된 것을 확인되었다.

해당 url을 복사하여 인터넷 주소창에 입력하면 다음과 같이 암호화(XOR)된 악성코드가 뜨는 것을 볼 수 있다.

복호화 방법은 따로 있겠지만, 여기서는 미리 알고있던 특정 데이터를 사용하여 XOR 복호화를 수 행한다. 메모장을 켜서 malwarebytes 라고 입력한 후 복사하기를 통해 클립보드에 저장해준다.

복사 후 디버깅을 다시 실행해보면 “You are one the right track!” 문자열 위치까지 디버깅이 실 행되었다.

그리고 아래 위에서 봤던 악성코드들이 다운로드 된 것 또한 확인할 수 있다.

8. 프로세스 할로잉 기법

그 전에 [다음을 찾기] → [현재 모듈] → [모듈간 호출]을 통해 이 프로그램에서 사용되는 모듈들 을 확인해보았다. setThreadContext / ResumeThread 등을 확인할 수 있다.

setThreadContext : 현재 실행중인 쓰레드에 대한 컨텍스트를 가져와서 수정
ResumeThread : 현재 쓰레드를 중지/재시작

해당 모듈 위치로 이동하여 중단점을 걸어준다

중단점을 건 후 계속 실행하다보면 SetThreadContext까지 실행점이 온 것을 확인할 수 있다.

위에서 봤던 악성코드의 암호가 풀렸다는 것이다.

Suspend 모드로 프로세스 실행

Suspend 모드로 rundll32.exe를 실행한다.

사용자 프로세스의 진입점 찾기

중단된 프로세스를 디버깅하려면 Suspend 상태의 rundll32.exe 프로세스를 디버거로 부착하고 중 단점을 EP에 설정한다.

EIP 수정하고 계속 수행하기

디버거에 부착된 rundll32.exe 중단점을 설정한다

중단점 설정 후 다시 sample.exe 디버거로 돌아와서 이어서 실행해보면 rundll32.exe 디버거 내용 이 달라진 것을 확인할 수 있다.

SetThreadContext() API를 사용하여 PE의 EP가 저장된 쓰레드 컨텍스트를 변경
ResumeThread() API를 사용하여 중단되었던 새로운 rundll32.exe 프로세스를 실행

9. 성공 메시지 출력

성공 메시지 출력 조건

현재 디버깅 중인 “rundll32.exe”이 system32 경로인지 확인
실행 중인 프로세스의 윈도우 이름 중 프로세스 익스플로(“procexpl.exe”)가 있는지 확인
위 두 조건을 만족하면 “rundll32.exe”는 프로세스 익스플로러에 쉘코드를 인젝션 시켜 실행

인젝션에 성공하면 다음과 같이 성공메시지가 프로세스 익스플로러를 통해 실행된 것을 확인할 수 있다.