[Qakbot 분석 (2)] PE 포맷 조작 및 API 리졸빙

지난 포스팅에서 언패킹한 Qakbot 악성코드를 이어서 분석해보겠습니다.

이번 포스팅에서는 PE 포맷과 API 리졸빙에 대해 알아보겠습니다.

샘플 해시(SHA256)는 73e4969db4253f9aeb2cbc7462376fb7e26cc4bb5bd23b82e2af0eaaf5ae66a8입니다.

 

 

 

[ Capa를 통해 스캔 ]

먼저 언패킹한 DLL을 Capa로 확인해보겠습니다.

Capa는 PE, ELF, .NET, shellcode 같은 실행파일이나 샌드박스 보고서를 입력하면, 해당 파일의 기능을 탐지하여 출력해주는 도구입니다. IDA plugin으로 연동하여 사용할 수도 있습니다(Capa Explorer).

 

아래는 Capa를 통해 언패킹된 DLL을 검사하여 출력한 내용입니다.

 

Capa를 통해 얻은 악성코드 분석에 도움이 되는 정보(징후)는 다음과 같습니다.

• HTTP 조작(manipulation)
• Adler32 체크섬 알고리즘
• CRC32 알고리즘을 사용한 해시 데이터
• Base64 인코딩 데이터
• XOR 연산이 사용된 인코딩 데이터
• SHA1 해시 알고리즘
• Mersenne Twister
• 파일 열거(file enumeration) 작업
• Import Table 재구성 작업

 

이 정보들을 이용하여 DllEntryPoint 함수를 시작으로 분석을 진행해보겠습니다.

 

 

 

[ 상세 분석 ]

DllEntryPoint

DllEntryPoint 함수의 30번째 줄의 서브루틴 sub_10009773를 먼저 분석해보겠습니다.

 

 

sub_10009773

 

첫 번째 파라미터는 크기이고 두 번째(unk_1001D5A8)와 세 번째 파라미터(unk_1001E3F8)는 아래와 같은 인코딩된 데이터 블롭입니다. v1과 v2에 대한 정보는 아직 없습니다.

unk_1001E3F8는 길이로 보아 키 문자열로 추측됩니다.

 

 

이어서 sub_1000865C 서브루틴으로 들어가보겠습니다.

sub_1000865C 서브루틴 내부 27번째 줄에서 흥미로운 연산 루틴을 발견했습니다.

a2, a3, a5는 입력 파라미터로 a2는 데이터 블롭1(unk_1001D5A8), a3는 데이터 블롭2(unk_1001E3F8)입니다.

해당 서브루틴에서 문자열로 추측되는 데이터 블롭1과 키로 추측되는 데이터 블롭2, 그리고 XOR 연산 루틴을 발견하였습니다. 이를 종합적으로 생각해보면 디코딩을 위한 서브루틴으로 추측됩니다.

 

알고 있는 정보를 기반으로 서브루틴(sub_10009773 → mw_decode_string_table, sub_1000865C → mw_decode_string_table), 인수, 변수 이름을 변경하여 정리하였습니다.

 

 

 

sub_10008773

다시 DllEntryPoint로 돌아와 32번째 줄의 sub_10008773 서브루틴을 확인해보겠습니다.

sub_10008773는 mw_ww_string_length로, sub_1000C52C는 mw_str_length_char로, sub_100087CB는 mw_str_length_wchar로 각각 변경하였고, 인수/변수 이름도 변경하였습니다.

 

15, 17번째 줄을 보면 첫 번째 파라미터가 -1인지 -2인지 확인하는 코드가 있습니다.

mw_ww_string_length (sub_10008773)의 두 번째 파라미터인 char_or_wchar는 크기를 입력받는 파라미터입니다. char_or_wchar가 -1인지 -2인지 확인합니다.

이때 "-1"은 "char"를 의미하고 "-2"는 "wchar"를 의미합니다. 아래 그림과 같이 mw_str_length_char (sub_1000C52C)의 파라미터는 _BYTE이고, mw_str_length_wchar (sub_100087CB)의 파라미터는 _WORD임을 확인할 수 있습니다

 

• char
  • 1바이트 크기입니다.
  • _byte는 1바이트 데이터를 의미하는 것으로 메모리에서 char를 다룰 때는 _byte로 표현됩니다.
    
    
• wchar
  • 보통 2바이트(또는 4바이트) 크기를 가집니다.
  • _word는 2바이트 데이터를 의미하는 것으로 메모리에서 wchar를 처리할 때는 _word로 다뤄질 수 있습니다.

 

 

서브루틴 sub_10008773 (mw_ww_string_length)은 문자열의 길이를 계산하는 함수이며 이후 코드에서도 자주 쓰입니다.

 

 

 

sub_10012C0A

DllEntryPoint 서브루틴 36번째 줄의 sub_10012C0A 함수입니다.

 

해당 서브루틴에서 60과 128을 발견할 수 있습니다. 각각 16진수로 변환하면 0x3C, 0x80입니다.

일반적으로 0x3C는 IMAGE_DOS_HEADER 구조체의 e_lfanew 필드를 나타내며, 0x80은 IMAGE_DATA_DIRECTORY 구조체 내의 Import Directory(_IMAGE_IMPORT_DESCRIPTOR 구조체)를 나타냅니다.

• IMAGE_DOS_HEADER 구조체
  
  • DOS 헤더에 해당하는 구조체로, DOS 시스템에서의 호환성을 유지하기 위해 사용됩니다.
  • DOS 파일 포맷의 헤더 정보를 담고 있습니다.
  • 그 중 e_lfanew 필드는 PE 헤더의 오프셋으로 0x3C 주소에 위치해있습니다.
    
    
• IMAGE_DATA_DIRECTORY 구조체
  • PE 헤더 내에 존재하는 데이터 디렉터리를 나타냅니다.
  • 데이터 디렉터리는 PE 파일 내에서 특정한 정보를 저장하는 영역을 지정하고, 이를 통해 운영체제는 실행 파일 내의 다양한 데이터를 효율적으로 찾고 사용할 수 있습니다.
  • IMAGE_DATA_DIRECTORY 구조체 배열 내에서 VirtualAddress 값이 0x80이면, Import Directory를 나타냅니다.
    
    
  • Import Directory
    • PE 파일의 import table을 나타냅니다.
    • import table은 _IMAGE_IMPORT_DESCRIPTOR 구조체들을 포함하고 있습니다.
      
      
    • _IMAGE_IMPORT_DESCRIPTOR 구조체
      • import table의 항목을 설명하는 구조체입니다.
      • 각 _IMAGE_IMPORT_DESCRIPTOR 항목은 PE 파일에 import되는 함수나 DLL에 대한 정보를 담고 있습니다.

 

 

이 정보들을 통해 구조체를 추가하여 PE 포맷을 조작(PE format manipulation) 해보겠습니다.

 

Structures 탭에서 표준 구조체 _IMAGE_DOS_HEADER와 _IMAGE_IMPORT_DESCRIPTOR를 추가합니다.

 

 

다시 의사 코드로 돌아와서 다음 작업을 수행합니다.

• 구조체 선택
  • e_lfanew 표현 바꾸기
    
    • 오프셋 60(0x3C)에 대해 Select a structure(단축키 T)으로 _IMAGE_DOS_HEADER를 선택합니다. 그리고 업데이트(단축키 F5)합니다.
      
      
  • 숫자 표현 바꾸기
    • 숫자 "20"을 클릭하고 Select a structure(단축키 T)을 누른 후 _IMAGE_IMPORT_DESCRIPTOR를 선택합니다. 그리고 F5를 눌러 디컴파일러를 업데이트합니다.
      
      
• 구조체 포인터 타입 바꾸기
  
  • 변수 v3
    • v3를 Set type(단축키 Y)를 "int v3"에서 "_IMAGE_IMPORT_DESCRIPTOR *v3"로 변경합니다. 그리고 업데이트(단축키 F5)합니다.
    • 오프셋 128(0x80)은 0x3C으로부터 0x80을 의미하며 _IMAGE_IMPORT_DESCRIPTOR 구조체(ImportDirectory)를 나타나는 것으로 추측됩니다. 이는 PE 형식을 참고하면 _IMAGE_DATA_DIRECTORY 구조체에 속합니다.
      
      
  • 변수 dword_1001E664
    • 변수 dword_1001E664에 대해서도 동일한 단계를 반복하여 타입을 "int"에 "_IMAGE_IMPORT_DESCRIPTOR *"로 변경합니다. 그리고 업데이트(단축키 F5)합니다.

 

위 작업을 수행하고 서브루틴 및 변수 이름을 바꾼 후의 코드입니다.

 

 

또한 mw_w_construct_import_structures (sub_1000881A) 서브루틴도 수정해주겠습니다. 

 

 

그리고 mw_HeapAlloc (sub_100087B5) 함수에 들어가서 HeapAlloc API의 파라미터를 수정합니다. 저는 두 번째 파라미터에 Enum member(단축키 M)를 눌러 HEAP_ZERO_MEMORY를 선택하였습니다.

 

 

서브루틴 mw_construct_import_structures (sub_10008892)도 아래 그림과 같이 변수와 인수 이름을 바꿔주었습니다.

 

sub_10012C0A (mw_prepare_Import_Structures) 서브루틴과 그 루틴 속 함수들(sub_1000881A(mw_w_construct_import_structures), sub_10008892(mw_construct_import_structures))은 구조체를 통해 힙 관련 작업을 하는 함수입니다.

 

 

 

sub_1000E369

다음으로는 DllEntryPoint 함수의 37번째 줄의 sub_1000E369 서브루틴을 분석해보겠습니다.

sub_1000E369 서브루틴 내부에는 sub_1000E31E와 sub_10008773이 있습니다.

 

또한 sub_1000E369 서브루틴의 교차 참조를 확인하면 13번 호출되고,

 

이전에 분석했던 mw_w_decode_string_table (sub_10009773) 함수도 보이는데, 이 함수의 교차 참조를 확인하면 23번 호출됩니다.

 

 

12번째 줄에는 형식적인 이름이 아닌 dword_1001E684라는 이름으로 호출되는 API가 있습니다. 이는 .data 섹션에서 0으로 초기화된 데이터입니다.

 

이 정보들은 API 리졸빙의 큰 지표입니다.

• API Resloving
  • 동적 라이브러리(DLL)에서 함수나 기호(symbol)를 호출할 때 해당 함수의 주소를 찾는 과정입니다.
    
    
  • 프로그램이 실행될 때 필요한 외부 함수를 호출하기 위해 해당 함수의 주소를 동적으로 찾고 연결하는 작업입니다.
    
    
  • API 리졸빙은 크게 정적 리졸빙과 동적 리졸빙으로 나뉩니다.
    • 정적 리졸빙: 컴파일 타임에 API 주소가 이미 결정되어 있는 경우로 주로 링커가 처리합니다.
    • 동적 리졸빙: 프로그램이 실행 중일 때 런타임에 API 주소를 찾아 연결하는 경우, 주로 LoadLibrary와 GetProcAddress와 같은 함수를 사용하여 처리합니다.

 

 

이어서 sub_1000E369 서브루틴 14번째 줄의 sub_1000E31E에 들어가서 분석해보겠습니다.

 

sub_1000E31E로 들어와보니 이전에 봤던 HeapAlloc의 래퍼(wrapper) 함수인 mw_HeapAlloc도 있고, 처음 보는 서브루틴인 sub_1000E15A도 있습니다.

 

sub_1000E15A에도 들어가보겠습니다.

 

여기서 다음과 같은 정보들을 얻을 수 있었습니다.

• 잘 알려진 10진수들(60, 120, 124 등)이 사용됩니다.
• 두 개의 서브루틴 sub_1000C52C와 sub_1000D5AA를 호출합니다.
• XOR 연산을 수행합니다.
• 16진수 0x6C6C642E가 사용됩니다.
• LoadLibrary()와 GetProcAddress()를 호출합니다.

 

이 정보들을 통해 동적 API 리졸빙 과정이라는 것을 확실하게 알 수 있습니다.

 

앞으로 리버싱 과정이 복잡해질 것이기 때문에 구조체를 추가하고 sub_1000E15A의 서브루틴/변수 이름들을 정리해주겠습니다.

1) 60(0x3C)을 e_lfanew 필드로 변경해줍니다.

  - Select a structure(단축키 T)으로 _IMAGE_DOS_HEADER를 선택합니다.

 

2) v3를 Set type(단축키 Y)를 "int v3"에서 " _IMAGE_NT_HEADERS* v3"로 변경합니다.

 

3) Structures 탭에서 표준 구조체 _IMAGE_EXPORT_DESCRIPTOR를 추가합니다.

 

4) 120(0x78)을 Export Directory 필드로 변경해줍니다.

  - Select a structure(단축키 T)으로 _IMAGE_EXPORT_DESCRIPTOR를 선택합니다.

 

5) v4를 Set type(단축키 Y)를 "int v4"에서 "_IMAGE_EXPORT_DIRECTORY* v4"로 변경합니다.

 

6) ApplyCalleeType 플러그인을 이용하여 LoadLibraryA()와 GetProcAddress() 호출을 더 보기 좋게 만들어보겠습니다. ApplyCalleeType 플러그인을 사용하면 함수가 어떻게 호출되고 사용되는지 알 수 있고, 파라미터/반환값 타입을 추정하여 정리해줍니다.

API에 커서를 올리고 Edit → Plugins → ApplyCalleeType → Use Standard Type를 클릭하여 해당 API 이름을 검색하고 선택합니다.

LoadLibraryA

 

7) 서브루틴 및 변수명을 바꿔줍니다.

 

 

이 과정을 완료하면 아래와 같이 예쁘게 정리된 mw_hashing_api (sub_1000E15A) 코드를 얻을 수 있습니다.

근데 49번 줄의 XOR 연산에서 0x218FE95B라는 상수가 고정되어 있는 것을 볼 수 있는데 이는 XOR 키입니다.

 

 

mw_hashing_api (sub_1000E15A) 서브루틴 분석이 아직 끝난 것은 아닙니다. 해당 서브루틴 49번째 줄의 sub_1000D5AA에 들어가보겠습니다.

해당 서브루틴에는 데이터를 XOR 연산과 비트 시프트 연산이 결합된 연산 과정이 있습니다. 이는 CRC 계산에서 자주 사용되는 패턴입니다. 맨 처음 capa로 분석한 결과를 통해서도 CRC32 알고리즘을 사용한 해시 데이터가 존재하는 것을 알고 있었기 때문에 이는 CRC32 알고리즘 계산을 하는 서브루틴임을 알 수 있습니다.

 

CRC32 계산 서브루틴에 맞게 서브루틴/변수 이름을 예쁘게 정리해주었습니다. ( sub_1000D5AA 서브루틴명: mw_crc32)

 

 

다시 sub_1000E369 (mw_w_function_api_resolving) 서브루틴으로 돌아가겠습니다.

mw_w_function_api_resolving (sub_1000E369)의 교차 참조를 확인해보면 13번 호출되고 있는데, 그 중 sub_1000606C 서브루틴에서 여러 번 호출되는 것을 발견하였습니다. 

 

sub_1000606C 서브루틴에 들어가서 확인해보겠습니다.

 

sub_1000606C 서브루틴에 들어와보니 탐색되지 않은 바이트 참조(unk_)를 확인해보면 암호화된 바이트가 많이 있습니다. 그중 일부를 더블 워드로 변환해보면 다음과 같습니다.

이 dword들이 CRC32 해시일 가능성이 큽니다.

 

해시 데이터들이 있으니 HashDB 플러그인을 사용해서 확인해보겠습니다. HashDB를 통해 특정 해시값을 생성하는데 사용된 해시 알고리즘을 식별할 수 있습니다.

 

먼저 XOR 키를 설정합니다. Edit → Plugins → HashDB로 이동하여 XOR 키를 설정합니다.

Enable XOR를 클릭하여 218FE95B (mw_hashing_api 서브루틴에서 본 xor 키)를 입력하고 Refresh Algorithms를 클릭합니다.

 

첫 번째 해시(1E4E54D6h)를 오른쪽 클릭해서 HashDB Hunt Algorithm을 선택합니다.

 

생각한대로 crc32 알고리즘이 탐지되었습니다. crc32를 클릭하여 OK를 누릅니다.

 

 

이제 문자열 해시를 조회하기 위해서 첫 번째 해시를 다시 오른쪽 클릭하여 HashDB Lookup을 클릭하면

 

아래 그림과 같은 결과가 출력됩니다.

이는 해당 해시가 kernel32.dll의 LoadLibraryA 함수를 나타낸다는 것을 나타냅니다.

 

이 모든 해시는 동일한 모듈의 CRC32 해시일 것입니다. 그렇기 때문에 모든 해시(dword_1001BA30 데이터)를 IDA 데이터베이스로 가져오겠습니다. 이를 위해 모든 해시를 선택하여 HashDB Scan IAT를 클릭합니다.

 

스캔이 완료되면 다음과 같은 결과를 볼 수 있습니다.

스캔 결과 일부

 

이런 식으로 모든 해시 그리고 해당 함수의 이름은 .rdata 섹션에 있습니다. 방금 스캔한 주소로부터 아래로 검색하면 다른 함수들의 API 이름을 나타내는 바이트 시퀀스가 많습니다. 따라서 이를 찾아서 모든 바이트 블록을 선택하고(제로 바이트 시퀀스까지) 오른쪽 클릭한 후 HuntDB Scan IAT를 선택하여 스캔 작업을 반복해야 합니다. 귀찮지만∼

아래는 HuntDB Scan IAT가 모두 완료된 (일부) 화면입니다. 

 

 

모든 API 이름을 복호화하였으니 이제 각 DLL에서 API 블록을 저장할 구조체를 만들어보겠습니다.

첫 번째로 복호화한 API들은 모두 kernel32.dll에서 가져온 것이므로 해당 API들을 모두 선택하여 오른쪽 클릭한 후 Create struct from select를 선택하여 구조체를 생성하고 이름을 변경해주겠습니다. 이 방법을 각 API들에 대해 동일하게 작업해줍니다. 

그런 다음 Strucrtures 탭에서 확인하면 아래와 같습니다.

 

 

다시 sub_1000606C 서브루틴으로 돌아오면 해시 데이터(dword) 이름이 변경된 것을 볼 수 있습니다.

 

여기서 추가적으로 sub_1000606C 서브루틴명을 mw_iat_construction으로 바꾸고, 변수명들도 수정해주겠습니다. 그러면 아래와 같이 예쁜 코드를 얻을 수 있습니다.

 

 

 

이렇게 PE 포맷을 추가하고 API를 모두 추출을 완료하였습니다.

나머지는 다음번에 이어서 진행해보겠습니다. 

 

 

 

Ref. "Malware Analysis Series(MAS) – Article 2", Alexandre Borges