[Malware analysis] Ursnif Unpacking

[Malware analysis] Malware Unpacking(Ursnif)

Ursnif 분석 시 Unpacking 부분을 정리한 내용이다.

- 샘플 파일 다운로드

> 첨부 파일

1. Unpacking(Payload) 

동적 분석 시 현재 “Error Initializing Client App!” 라는 메시지와 함께 다른 행위를 하지 않는 것을 확인 할 수 있었다. 

디버깅을 통해 packing 유무의 확인이 필요하다. 

Main()을 살펴보면 CALL 4015A1과 CreateWindowExA()을 볼 수 있다. 

0x4015A1()을 살펴보게 되면 RegisterClassExA()를 만나게 되는데 정보 검색을 하게 되면 윈도우를 만드려면 윈도우 클래스를 먼저 등록한 후 CreateWindow()을 호출해야 한다. 

(그림 1)을 살펴보면 CreateWindowExA()을 호출하기 전 RegisterClassExA()을 이용하는 걸 확인 할 수 있다. 즉, RegisterClassExA()의 WNDCLASSEXA 멤버와 관련이 있다는 걸 확인 할 수 있다.  

 

그림 1 – Main() 

(그림 4)의 스택 부분을 살펴보면 0x12FE98을 가르키는 걸 확인 할 수 있다. 해당WndClassEx 구조체을 중 3번째 멤버를 살펴보면 lpfnWndProc Callback이라는 걸 확인 할 수 있다. 

다음으로 스택에 들어있는 Callback() 주소인 0x401612을 살펴보자.

 

그림 2 – WindowProc 

(그림 3)은 0x401612 주소에 있는 CreateThread() 부분이다. CreateThread()의 함수의 매개변수를 살펴보면 ThreadProc Callback이라는 걸 확인 할 수 있다. 

또, 위와 같이 CreateThread()의 ThreadFunction 0x4017C9 주소를 살펴보자 

 

그림 3 – 40122A(), CreateThread() 

(그림 4)의 CALL 4019D4을 진행 후 retune 전 EnumWindows()을 진입하게 되면 메모리 생성, 권한, 영역을 지정해주는 걸 확인 할 수 있다. 

결국 packing file은 VirtualProtect()을 이용하여 영역에 대한 속성 변경이 필요하기 때문에 Ollydbg command line | 주소 이동을 이용해 VirtualProtect() BreakPoint를 설정하여 진행을 할 수 있다. 

인코딩 되어 있던 데이터는 해당 메모리 주소에 디코딩이 된 걸 확인 할 수 있다. 

 

그림 4 – VirtualProtect()