Malware Analysis Series (MAS) – Article 9

Alexandre Borges의 블로그 Exploit Reversing의 악성코드 분석 시리즈 'Malware Analysis Series(MAS)'를 번역하여 공부해보겠습니다. MacOS/iOS 내용의 아티클 8은 잠시 미뤄두고 9번째 아티클부터 공부해보겠습니다.

 

 

[Introduction]

악성코드 분석 시리즈(MAS)의 9번째 아티클에 오신 것을 환영합니다. 이번 아티클에서는 윈도우 실행 파일로 돌아와서 PE 포맷뿐만 아니라 일반적인 쉘코드(shellcode)를 다뤄보겠습니다.

요즘은 Sliver, Brute Ratel, Havoc, Covenant, Empire, Cobalt Strike 같은 수십 가지의 C2 프레임워크가 있습니다. Cobalt Strike는 실제 red team operation에서 사용되었지만 안타깝게도 유출된 복사본이 다양한 랜섬웨어 그룹에 의해 악용되기도 했습니다.

일반적으로 쉘코드 바이너리를 분석할 때의 특징 중 하나는 문제를 다른 관점에서 이해해야 한다는 것입니다. 대부분 저희는 PE, ELF, Mach-O 같은 포맷의 코드를 읽고 분석하는데 익숙하기 때문에 처음에는 다소 생소할 수 있습니다. 사실 쉘코드를 다루는 것이 더 어려운 이유는 상황을 이해하는데 도움이 되는 표준 포맷이 없기 때문이기도 합니다. 게다가 쉘코드를 자동으로 로딩하고, 디스어셈블하고, 전체 코드를 관리해주는 로더 모듈이나 프로세서 모듈도 존재하지 않습니다. 따라서 이런 로더나 프로세서 모듈의 도움이 없는 상태에서, 모든 것이 단순한 바이트 집합 요약본을 우리가 직접 분석하여 의미 있는 결과와 해석을 도출해내야 합니다.

결국 PE 바이너리와 쉘코드를 분석하는 것은 목표 면에서는 유사한 작업이지만 그 목표에 도달하는 경로는 약간 다르며, 이들 모두는 시스템을 우회하고 침해하기 위해 윈도우 구조를 조작합니다. 이 글에서는 쉘코드에 대한 몇 가지 사실과 기본 개념, 간단한 리버스 엔지니어링과 분석 기법에 대해 다뤄보겠습니다.

 

 

 

[Basic Information]

Malwoverview 도구를 사용하여 최신 쉘코드 바이너리 샘플을 얻을 수 있습니다. 이 도구가 제공하는 다양한 기능과 옵션 중, Malware Bazaar는 믿을 수 있는 무료 샘플 출처 사이트이고, 아래 명령어를 실행하여 해당 샘플 목록을 가져올 수 있습니다.

[Figure 01] Malware Bazaar의 쉘코드 샘플 목록

 

같은 도구를 사용하여 Metasploit, Cobalt Strike, Sliver 등 특정 페이로드를 직접적으로 검색하는 것도 매우 간단합니다.

• malwoverview -b 2 -B metasploit -o 0 | grep sha256_hash
• malwoverview -b 2 -B cobaltstrike -o 0 | grep sha256_hash

 

나열된 샘플 중 하나를 다운로드하려면 다음 명령어를 실행하면 됩니다.

• malwoverview -b 5 -B <hash> 

 

모든 페이로드는 비밀번호 'infected'로 암호 설정되어 있습니다. 샘플을 압축 해제하려면 다음 명령을 실행하세요: 7z -e <sample> -pinfected.

 

 

 

[Reversing]

저는 몇 가지 샘플로 기술들에 대한 필수 개념을 설명해보겠습니다. 쉘코드 분석은 까다롭지만 제 이전 글을 읽은 분들이라면 전혀 문제가 없을 것입니다. 굳이 언급할 필요는 없겠지만 아래 쉘코드 샘플은 윈도우 환경에서 실행되도록 설계되어 있습니다.

 

 

● Example 01

첫 번째 예제는 순수(raw) 쉘코드이며 저는 이를 shellcode_01.bin이라고 명명했습니다. 이 파일을 16진수 편집기(ex. HxD)로 열어 전체 내용을 빠르게 확인해보세요. (SHA256: 23ad215b73830b2478c19b3dda9bef3db2a53f016efdabeb535fc94e54c91ea7)

[Figure 02] raw 쉘코드의 헥사 표현

 

다음과 같이 처음 나오는 16진수 값들(opcode)을 빠르게 니모닉(mnemonic)으로 변환할 수 있습니다(인터넷에 다양한 opcode 테이블이 있습니다).

• 0xFC: cld(clear direction flag). 문자열 처리 시 ESI/EDI 레지스터가 증가할지 감소할지를 결정합니다.
• 0xE8: call
• 0x82: call 명령에 의해 호출될 루틴의 오프셋이며 실제 진입점(entry point)입니다.

 

겉보기에 유용한 문자열은 없고 이 쉘코드는 총 328바이트로 짧습니다. IDA로 쉘코드를 열어보면 다음과 같은 화면을 확인할 수 있습니다.

[Figure 03] IDA Pro로 열어본 raw 쉘코드

 

이건 PE 포맷도 아니고 쉘코드이기 때문에 단일 옵션만 있습니다.

[Figure 04] 디스어셈블리 모드

 

두 개의 디스어셈블리 모드가 있는데 저희는 32비트를 선택해야 합니다.

[Figure 05] 첫 번째 디스어셈블된 코드 라인들

파일을 IDA에서 열면 위 그림과 같은 이미지를 볼 수 있습니다. 볼 수 있듯이 어셈블리 명령어는 없고 파일이 바이너리 파일로 분석되었기 때문에 IDA는 추가적인 해석을 제공하지 않습니다. 따라서 다음 단계는 저희가 결정해야 합니다.

첫 번째 작업은 0x00000000의 첫 번째 바이트로 커서를 이동한 후 "C"를 눌러 이를 코드로 변환하는 것입니다. 그럼 다음과 같은 코드가 표시됩니다.

[Figure 06] 실제 명령의 첫 번째 코드 라인

 

그러면 즉시 두 개의 명령어를 확인할 수 있는데 이는 앞서 opcode를 디코딩하며 알아낸 내용과 정확히 일치합니다. 여기서 call sub_88 명령어를 확인할 수 있는데 이는 실행 흐름이 0x88로 점프했다는 것을 의미합니다. 하지만 여기에는 반드시 기억해야할 미묘한 포인트가 있습니다. call 명령어가 실행되면 다음 명령어의 주소가 스택의 맨 위에 푸시됩니다. 분석을 계속해보면 주소 0x88에서 다음과 같은 명령어들을 확인할 수 있습니다.

[Figure 07] 주소 0x88의 명령어

 

이 지점부터 분석이 흥미로워지기 시작합니다. 이전 그림들에 나온 명령어들은 이해하기 어려워보일 수 있지만 실제로는 그렇지 않습니다. 다음 설명들을 보면 이해하는데 도움이 될 것입니다.

• 0x00000088: EBP는 스택에서 꺼낸 값으로 설정되며, 이는 앞선 call 명령어에 의해 푸시된 값으로 이후 호출될 루틴의 주소로 사용됩니다. 이 부분은 곧 다시 다룹니다.
  
  
• 0x00000089: 부분 문자열(substring)을 스택에 푸시하고 있고 이는 함수 인자의 일부가 됩니다. 이 값을 문자열로 보려면 "R" 키를 누르세요.
  
  
• 0x0000008E: 또 다른 substring을 스택에 푸시하고 있고, 이것도 인자의 일부가 됩니다. 역시 "R" 키를 누르면 문자열로 변환할 수 있습니다.
  
  
• 0x00000093: 현재 스택 포인터인 ESP 값이 스택에 푸시되는데 살짝 이상해보일 수 있지만, 사실 주소 0x00000094에 있는 함수의 인자(주소 0x8E와 0x89의 부분 문자열들로 구성된 문자열)의 포인터로 사용됩니다.
  
  
• 0x00000094: 이 16진수 값은 실제로 호출될 함수(call ebp, 주소 0x99)의 첫 번째 인자입니다. 앞선 주소들(0x89, 0x8E)과 달리 이 값은 문자열이 아니라 해시입니다. 이전 글에서 배운 것처럼 이를 처리하는 여러 방법이 있는데 그 중 하나가 HashDB를 활용하는 것입니다(자세한 내용은 이전 글을 참조하세요).
  • 해당 값을 마우스 오른쪽 버튼 클릭한 후, HashDB Hunting Algorithm를 선택합니다.
  • 알고리즘으로 "metasploit"를 선택합니다.
  • 16진수 값에서 다시 마우스 오른쪽 클릭 후 HashDB Lookup을 선택합니다.
  • 선택된 모듈이 타당한지 확인한 후 Import를 누릅니다.
    
    
• 0x00000095: call ebp 명령은 실행 흐름을 어딘가로 전환하고 다음 명령어 주소인 0x9B를 스택에 리턴 주소로 푸시합니다.

 

동일한 분석을 반복하면 다음 그림과 같이 다음 명령(주소 0xAD)에 도달할 수 있습니다.

[Figure 08] 개선된 sub_88 루틴

 

코드에서 LoadLibrary 함수와 ws2_32(Winsock2 DLL)가 명확히 언급되어 있는 것을 확인할 수 있습니다. 또한 WSAStartup 함수도 언급되는데 이는 프로세스가 Winsock DLL을 사용하기 위해 준비하고 초기화할 때 사용되는 함수입니다. 하지만 이 외에도 흥미로운 세부 사항들이 있습니다.

• 400(0x190) 값이 EAX 레지스터로 이동되고 이 값이 ESP에서 차감됩니다. 이는 스택에 공간을 확보하는 동작으로 함수를 호출하기 전 스택을 준비할 때 일반적으로 수행되는 작업입니다.
  
  
• push 명령어는 주소 0x00000093에서 설명한 것과 동일한 의미를 가지며 WSAStartup 함수의 출력 결과가 저장될 스택 위치를 가리키는 포인터입니다.
  
  
• 동일한 값(400)이 WSAStartup 함수의 인자로서 스택에 푸시되며 이는 0xA9 주소에서 호출되는 루틴에서 사용됩니다. 이때 사용되는 EBP 값은 0x88 주소에서 설정된 것과 동일합니다.
  
  
• 마지막으로 call ebp 명령어가 실행됩니다.

 

분석을 계속하기 전에 쉘코드를 분석하기 위해(사용자영역 기준으로) 아래의 라이브러리와 구조체를 가져와야 합니다.

 

• View > Open subviews > Type Libraries > ntapi 또는 ntapi_win7 선택
  
  
• View > Open subviews > Local Types > INS > Import standard structure
  • _PEB
  • _IMAGE_DOS_HEADER
  • _IMAGE_NT_HEADERS
  • _IMAGE_FILE_HEADER (자동으로 _IMAGE_NT_HEADERS에 의해 가져와짐)
  • _IMAGE_OPTIONAL_HEADERS (자동으로 _IMAGE_NT_HEADERS에 의해 가져와짐)
  • _IMAGE_DATA_DIRECTORY (자동으로 _IMAGE_NT_HEADERS에 의해 가져와짐)
  • _IMAGE_EXPORT_DIRECTORY

 

 

import된 모든 구조체는 Local Types 뷰(SHIFT + F1)에서 다음과 같이 확인할 수 있습니다.

[Figure 09] import된 표준 구조체들

 

다시 돌아가보면 이 시점에서 분석을 잠시 멈추고 EBP에 저장된 값을 이해해야 합니다. 주소 0x88의 명령을 통해 설정된 현재 EBP는 함수 포인터를 보유하고 있습니다. 이 주소에 pop ebp 명령어가 존재하므로 EBP 값은 스택 최상단에서 가져온 것입니다. Figure 06에서 주소 0x06에는 일련의 바이트들이 있었고, 이를 코드로 변환(C 키 누르기)하면 다음과 같은 결과를 얻게 됩니다.

[Figure 10] 0x06 주소의 어셈블리

 

여기서 유용한 명령들을 확인하여 함수라는 것(prologue입니다)을 알 수 있습니다. 아직 함수로 지정되지 않았기 때문에 주소들이 빨간색을 표시되는데 P 키를 눌러 함수로 전환해줄 수 있습니다. P를 눌러 함수로 설정하면 다음과 같은 코드를 볼 수 있습니다.

[Figure 11] 0x06 주소의 명령 일부

 

완전히 만족스럽진 않지만 코드가 조금 나아져서 쉘코드 형태와 유사해졌습니다.그런데 왜 완전한 쉘코드 형태가 아닐까요? 이 코드는 32비트이고 일반적으로 이런 코드에서는 EBP 기반 프레임을 사용하는 거이 일반적이기 때문입니다. sub_6 함수에 커서를 놓고 ALT+P 키를 눌러 해당 설정을 변경할 수 있습니다. 대화 상자 오른쪽에 BP based frame 체크박스를 통해 활성화할 수 있습니다. 체크한 후 OK를 누르면 다음과 같은 결과를 얻을 수 있습니다.

[Figure 12] 개선된 0x06 주소의 명령

 

조금 더 나아졌지만 여전히 개선할 여지가 남아있습니다. 이 루틴은 이전에 표시되지 않았던 인자를 받습니다. sub_88 루틴에서는 여러 번의 call ebp 명령어가 있었고 EBP 값은 주소 0x88의 첫 번째 명령어인 pop ebp를 통해 스택에서 가져옵니다. 실제로 스택의 최상단에 있는 값은 sub_6 루틴의 주소였고 이는 이전의 call 명령어(0x01)가 해당 주소를 스택에 푸시했기 때문입니다. 여러 번의 call ebp 명령어는 하나의 인자만 가집니다. 왜냐하면 그 인자는 함수 포인터이기 때문입니다. 그리고 각 함수 포인터는 호출되는 함수에 필요한 각각의 인자를 가집니다.

쉘코드를 분석하다보면 모든 것이 Windows 구조와 관련되어 있다는 것을 알게될 텐데, 그렇기 때문에 분석을 진행하기 위해 알아야 할 개념들이 있습니다. pusha 명령어는 모든 레지스터 값을 스택에 저장하며 나중에 popa 명령어를 통해 복원될 수 있습니다.

주소 0x0B에 fs:[eax+ 30h]가 있습니다. 여기서 fs:[0]는 Threat Environment Block (_TEB)를 참조하고, 0x30 오프셋에서는 Process Environment Block (_PEB)에 대한 참조가 있습니다. 아래와 같습니다.

[Figure 13] TEB 구조체 (일부)

 

fs:[0]는 또한 TIB (Thread Information Block)의 포인터이지만, 흥미로운 부분은 아닙니다. IDA에서 제공된 PEB 구조체는 다음과 같습니다.

[Figure 14] _PEB 구조체 (일부)

 

PEB 구조체가 훨씬 크지만 지금 저희 목적에는 이 정도면 충분합니다. 오프셋 0xC(Figure 12의 오프셋 0xF 참조)에 PEB_LDR_DATA를 가리키는 포인터가 있습니다. 해당 구조체는 다음과 같은 형태입니다.

[Figure 15] PEB_LDR_DATA 구조체

 

 

이제 중요한 코드 조각이 등장합니다. 오프셋 0x14(Figure 12의 오프셋 0x12 참조)에는 InMemoryOrderModuleList 필드가 있습니다. 이 필드는 LIST_ENTRY 구조체 타입이며 아래와 같은 방식으로 구성된 이중 연결(doubled-linked) 구조체를 나타냅니다.

[Figure 16] _LIST_ENTRY 구조체

 

따라서 InMemoryOrderModuleList 필드는 다른 _LIST_ENTRY를 가리키는 *Flink 포인터를 포함하고 있습니다.

_LIST_ENTRY 구조체는 구조화된 체인을 이해할 수 있도록 해줍니다. InMemoryOrderModuleList 필드의 포인터(Flink와 Blink)는 앞뒤로 다른 _LIST_ENTRY 구조체를 가리키며, 어떤 다른 구조체의 일부일 가능성이 있습니다. 이 경우 우리가 DLL 모듈들을 다루고 있으므로 참조되는 구조체는 LDR_DATA_TABLE_ENTRY이며 이전에 설명한 동일한 절차를 따라 IDA에 추가해야 합니다.

[Figure 17] _LDR_DATA_TABLE_ENTRY 구조체

 

주소 0x15의 코드를 분석해보면 mov esi, [edx+28h] 명령어가 있는데, 오프셋 0x28을 참조하라는 의미입니다. 하지만 _LDR_DATA_TABLE_ENTRY 구조체를 살펴보면 해당 오프셋은 존재하지 않습니다. 왜냐하면 실제로는 코드가 오프셋 0x24 + 0x4 위치에 접근하고 있는데 이는 _UNICODE_STRING 구조체의 구성 때문입니다.

[Figure 18] _UNICODE_STRING 구조체

 

이 코드는 _UNICODE_STRING 구조체의 Buffer 필드에 접근하고 있습니다. 동일한 방식으로 주소 0x18(mov esi, [edx+26h]) 명령은 같은 _UNICODE_STRING 구조체의 MaximumLength 필드에 접근하는 것입니다. 지금까지 사용한 구조체들은 다음과 같습니다.

• _TEB
• _PEB
• _LDR_DATA
• _LDR_DATA_TABLE_ENTRY
• _UNICODE_STRING

 

이제 어떤 구조체들이 접근되고 있는지 알게 되었으니 이전에 설명한 절차대로 이 구조체들을 추가하고, T 키를 사용해 각 필드에 적절한 타입을 지정해주기만 하면 됩니다.

[Figure 19] 필요한 구조체 추가 및 각 타입 적용 후 코드

 

 

다음 코드는 아래와 같습니다.

[Figure 20] sub_6 루틴의 두 번째 파트

 

주소(또는 라인) 0x1E부터 0x23까지는 비교적 명확합니다. 이 코드는 전달받은 문자열이 소문자인지 대문자인지를 확인하고 만약 소문자라면 대문자로 변환합니다. 이는 0x23 주소에 있는 sub al, 20h 명령어 때문입니다. loadsb 명령어 (line 0x1E)는 소스 문자열(line 0x15에서 ESI가 가리킴)에서 한 바이트를 AL 레지스터로 불러오며, 매 loadsb 명령 실행 후 ESI는 증가하여 다음 바이트로 넘어갑니다. 흥미로운 부분은 주소 0x25부터 0x2A까지가 ROR-13을 수행하는 디코딩 루틴이라는 것이고, 이 방식은 metasploit 인코딩으로 잘 알려져 있습니다.

주소 0x2C와 0x2D에는 각각 push edx와 push edi 명령어가 있으며, 이는 각각 현재의 _LDR_DATA_TABLE_ENTRY 구조체(즉, 현재 DLL 구조체)를 가리키는 포인터와 문자열 배열의 현재 슬록을 가리키는 포인터를 스택에 저장하는 것입니다. 아직 확인하지 못했다면 주소 0x12와 0x28을 참고하세요. 그리고 0x2E 주소에 있는 mov edx, [edx+10h] 명령어는 Figure 17에 따르면 InInitializationOrderLinks 필드를 참조합니다. 이 필드 역시 _LDR_DATA_TABLE_ENTRY 구조체를 가리키며 오프셋 0x3C는 union 타입입니다. 아래 그림에 그 구조체가 나와있습니다.

[Figure 21] _LDR_DATA_TABLE_ENTRY 및 연관된 union들

위 그림을 분석해보면 대상 필드는 SectionPointer이며, 이는 바이너리 자체를 가리키는 포인터입니다. 이 지점부터는 PE 구조를 살펴보게 될 것입니다. 이전 글들에서 수행했던 동일한 방식으로 구조체를 적용하여 진행하면 됩니다.

 

[Figure 22] 심볼 및 이름이 적용된 sub_6 루틴의 두 번쨰 파트

 

 

모든 구조체들은 아래와 같습니다.

[Figure 23] 이름 리졸빙에 관여하는 구조체들

 

간단히 말해서 이 코드는 address of names 배열의 RVA와 DLL의 개수를 얻기 위해 바이너리를 파싱하고 있는 것입니다.

Figure 20의 마지막 줄은 다음과 같습니다.

[Figure 24] Figure 20 코드의 마지막 줄

 

위 명령어들은 address of names의 주소를 파싱하는데 사용되고, 각각은 4바이트로 구성되어 있습니다. 이로써 해당 단계가 종료되고 다음 단계를 분석할 차례입니다.

 

 

[Figure 25] sub_6 루틴의 세 번째 파트

이 부분은 이전과 유사하지만 이번에는 함수 이름과 주소에 관한 것입니다.

• pop eax 명령은 스택의 최상단에 있는 데이터를 복구하며 이는 IMAGE_DATA_DIRECTORY를 가리키는 포인터입니다.
  
  
• 바이너리는 AddressOfNameOrdinals 배열에 접근하여 각 항목을 가져옵니다.
  
  
• 이렇게 가져온 순서값을 통해 해당 함수의 주소도 함께 복구됩니다.
  
  
• popa 명령어는 이전의 pusha 명령어를 되돌리기 전에 디코딩된 바이트를 가져오고, _LDR_DATA_TABLE_ENTRY를 가리키는 포인터도 복원됩니다.
  
  
• 이 시점 이후, 올바른 함수가 발견되면 해당 함수가 호출되며 그렇지 않으면 코드가 계속 검색을 수행하여 올바른 함수를 찾을 때까지 반복합니다.

 

일부 세부 내용은 생략했지만 지금은 이 정도면 충분합니다. 아래에 표시된 코드가 이어집니다.

[Figure 26] 간결하게 표시한 sub_6의 두 번째 파트

 

 

중요한 점은 sub_6 함수의 코드는 DLL이나 export 함수에서 나온 모든 해시값에 적용된다는 것입니다. 그리고 두 부분의 로직은 유사하지만 동일하지는 않습니다. 이제 우리는 다시 sub_88 루틴에서 중단했던 지점으로 돌아가 몇 가지 세부 사항을 분석해야 합니다. 이전과 비슷한 방식으로 저는 HashDB를 사용하여 함수 해시를 검색하고 실제 함수 이름으로 교체할 예정입니다.

[Figure 27] sub_88 루틴의 두 번째 파트 (첫 번째 파트: Figure 08)

 

 

WSASocketA 함수의 프로토타입은 다음과 같습니다.

[Figure 28] WSAScocketA 함수 프로토타입 (출처: Microsoft Learn)

 

 

WSASocketA 함수는 생성된 소켓을 참조하는 디스크립터(descriptor)를 반환합니다. Figure 28에 표시된 코드에는 다음과 같은 흥미로운 내용이 있습니다.

• WSAStartup 함수로부터 반환된 값은 0이고 이는 성공을 의미합니다.
  
  
• ECX 레지스터는 8로 설정되고 이는 루프 명령어에서 반복 횟수로 사용됩니다.
  
  
• EAX가 0인 값이 여러 번 스택에 push되는데 이는 do/while 구조를 나타냅니다.
  
  
• 추가적으로 두 번의 push가 있으며 이 값들은 순차적으로 1씩 증가합닏.
  
  
• 결과적으로 WSA_Socket 함수의 첫 번째 인자는 2(AF_INET), 두 번째 인자는 1(SOCK_STREAM)으로 TCP 통신에 사용됩니다.
  
  
• 세 번쨰 인자는 0으로 프로토콜은 자동으로 선택됩니다(물론 TCP입니다).
  
  
• 나머지 인자들은 모두 0입니다.

 

코드의 두 번째 부분에는 bind 함수 호출이 포함되어 있으며, 해당 함수는 다음과 같은 프로토타입을 가집니다.

[Figure 29] bind 함수 프로토타입 (출처: Microsoft Learn)

 

코드 두 번째 부분에 대한 미해결 사항은 다음과 같습니다.

• WSASocketA 함수에서 반환된 디스크립터는 EAX에 저장된 후 EDI로 교체되어 bind 함수의 첫 번째 인자로 사용됩니다(line 0xC7 참고).
  
  
• 두 번째 인자는 까다로운데 0x0F270002 값이 스택에 푸시되고(line 0xBD), 이 값에 대한 포인터가 ESI에 저장되어(line 0xC2), bind 함수의 두 번째 인자로 사용됩니다.
  
  
• 두 번째 인자의 실제 타입은 sockaddr_in이고, 이는 곧 다룰 특정 정의를 가지고 있습니다.
  
  
• 세 번째 인자는 addr(두번째 인자)가 가리키는 값의 길이로, 그 값은 0x10(16)이고 값(immediate value)으로 전달됩니다.

 

진행하기 전에 두 번째 인자의 구조체를 올바르게 해석할 수 있도록 복습해야 합니다. 하지만 Microsoft Learn 웹사이트에서 언급된 세부 사항이 있습니다.

"SOCKADDR_IN 구조체의 모든 데이터는 주소 패밀리를 제외하고는, 네트워크 바이트 순서(빅 엔디안)로 지정되어야 합니다."

sockaddr_in 구조체는 다음과 같습니다.

[Figure 30] sockaddr_in 구조체 (출처: Microsoft Learn)

 

두 번째 인자 값은 0x0F270002이고, 다음과 같은 내용을 알 수 있습니다.

• sin_family = 0200: AF_NET
• sin_port = 270F (9999): 소켓은 해당 포트에 바인딩됩니다.
• in_addr = 0.0.0.0: 서버는 모든 IP 주소에 바인딩됩니다.

 

이전 아티클들에서 소켓 통신을 설정하기 위한 함수 호출 순서에 대해 이미 언급했지만, 다시 한 번 설명해도 좋을 것 같습니다.

• 클라이언트 측 연결을 설정하기 위한 순서는 다음과 같습니다.
  
  • WSAStartup
  • socket
  • connect
  • send | recv
    
    
• 서버 측 연결을 설정하기 위한 순서는 다음과 같습니다.
  • WSAStartup
  • socket
  • bind
  • listen
  • accept
  • recv | send

 

이 바이너리 코드에서의 구성은 서버 측입니다.

따라서 이 쉘코드는 기본 네트워크 어댑터(메인 IP주소)와 포트 9999에 바인딩된 소켓을 유지하며, TCP를 전송 프로토콜로 사용합니다. sub_88 함수의 다음 부분은 이전 부분보다 분석이 더 쉽고 몇 가지만 언급해보겠습니다.

[Figure 30] sub_88 루틴의 세 번째 파트

기본적으로 다음과 같은 사실들을 알 수 있습니다.

• 서버 측 연결에는 예상되는 모든 함수가 포함되어 있고, 유일한 변경 사항은 마지막 부분에서 recv/send 함수가 호출되지 않고 대신 CreateProcessA가 호출된다는 것입니다.
  
  
• 클라이언트가 서버에 연결되자마자 명령 프롬프트가 실행됩니다(주소 0xEB에서 "cmd" 확인).
  
  
• WaitForSingleObject는 객체(프로세스)가 신호를 받을 때까지 기다립니다(finished).
  
  
• 마지막으로 프로세스와 관련된 스레드가 종료됩니다.

 

이 첫 번째 쉘코드는 분석하기 어려운 것은 아니었지만, 다양한 개념과 관점을 제공합니다. 분명히 많은 세부 사항을 분석에서 생략했지만, 제시된 내용은 다른 쉘코드 분석에서도 재사용할 수 있습니다.

 

 

● Example 02

이번 시간에는 이 샘플을 분석해보겠습니다: d26d5e9e0b05f94be8b86dc7410604cac85557a8f7bdf709beb95ee8cbb98c60.

HxD로 확인해보겠습니다.

[Figure 32] HxD로 본 shellcode_02.bin

 

이 샘플은 PE 실행 파일입니다. IDA로 열어서 전체 바이너리를 디컴파일합니다: File → Produce File → Create C File.

[Figure 33] IDA Pro로 본 shellcode_02.bin

 

여기서 몇 가지 중요한 주의사항이 있습니다.

• IDA Pro에서 처음 표시되는 루틴은 main입니다.
• 그러나 이것은 이 바이너리의 진입점(entry point)이 아닙니다.
• .tls와 같은 다른 섹션들이 결국 중요할 수 있습니다.

 

진입점 목록은 CTRL+E를 눌러 확인할 수 있습니다.

[Figure 34] 진입점 목록

 

보시다시피 두 개의 TLS 콜백이 있고 시작 루틴이 주요 진입점이 표시되어 있습니다.

CTRL+S를 사용하여 섹션을 나열할 수 있습니다.

[Figure 35] 섹션 목록

실제로 TLS 섹션이 있었습니다.

시작 루틴을 조사해보면 다음과 같습니다.

[Figure 36] 시작 루틴

 

 

start → sub_401180 → sub_4020F0 → sub_0x401EB0 순서로 함수 호출을 따라가보면, 이 함수에서 VirtualProtect를 통해 메모리 권한으로 RWX로 변경하려는 것을 볼 수 있습니다.

[Figure 37] sub_401EB0

 

지금으로서는 이 RWX 영역의 목적을 알 수 없지만(사실 완전 모르는 건 아닙니다), 이는 TlsCallback_0 호출(invocation) 직후에 나타납니다. TlsCallback_0 및 TlsCallback_1에 대해서는 바이너리 내에 존재할 수 있는 쉘코드를 찾고 이해하는 것이 우리의 주요 목표이므로 분석하지 않겠지만, 진입점으로 지정된 함수들은 예기치 않은 상황을 피하기 위해 항상 확인하고 분석하는 것이 중요합니다.

이제 main 함수로 초점을 옮겨보면(Figure 33), sub_401840(주소 0x402CEE) 호출이 있으며 그 내용은 아래와 같습니다.

[Figure 38] sub_401840

위 코드에서 몇 가지 중요한 사항이 있습니다.

• 문자열 \\.\pipe\MSSE-<value>-server가 스택에 생성되며 여기서 value는 TickCount % 9898의 결과입니다. 물론 이는 전형적인 Cobalt Strike 아티팩트입니다. 이에 대한 자세한 내용은 여기서 확인할 수 있습니다: https://www.cobaltstrike.com/blog/learn-pipe-fitting-for-all-of-your-offense-projects.
  
  
• CreateThread 함수가 호출되어 스레드를 생성하며 실행을 담당합니다. 여기서 우리에게 가장 중요한 인자는 세 번째 인자(lpStartAddress)입니다. 다음 단계는 스레드로 시작되는 sub_401713 루틴을 확인하는 것입니다.

 

 

다음 단계는 스레드로 시작되는 sub_401713 루틴을 확인하는 것입니다.

[Figure 39] sub_401713

 

byte_403014 내용은 다음과 같습니다.

[Figure 40] byte_403014

 

 

SHIFT+E를 눌러 이 내용을 추출하고 raw 바이너리로 저장하세요.

[Figure 41] 데이터 추출

 

파일의 기본적인 정보를 확인해겠습니다.

[Figure 42] 추출된 파일의 기본적인 정보 확인

 

IDA Pro로 열어보면 다음과 같습니다.

[Figure 43] IDA Pro로 본 추출된 파일: 이상한 명령들

 

이러한 동작은 위 코드가 인코딩되어 있다는 명확한 신호이기 때문에 먼저 이를 디코딩해야 합니다.

원래의 바이너리로 돌아가서 특히 Figure 39에서는 sub_401648 호출이 있으며 그 내용은 아래와 같습니다.

[Figure 44] sub_401648

 

이 함수는 명명된 파이프(named pipe)를 생성하고, 해당 파이프에 연결한 뒤 버퍼의 내용을 저장하는데, 이 버퍼 내용이 바로 우리가 추출한 (그리고 인코딩한) 데이터입니다.

Figure 38 (sub_401840)로 다시 돌아가보면 주소 0x004018F5에서 jmp sub_4017E2 명령어가 있으며 그 내용은 아래에 나와있습니다.

[Figure 45] sub_4017E2

 

sub_401732 루틴(주소 0x401815)은 기본적으로 ReadFile과 WriteFile 함수 호출 쌍을 포함하고 있습니다. 이 루틴은 NumberOfBytesToRead와 lpBuffer를 인자로 받고, 이 버퍼(lpBuffer)는 Figure 40에서 추출된 인코딩된 바이트를 가리킵니다.

그 다음 함수인 sub_40158E에는 데이터의 크기, unk_403008에서 가져온 일부 바이트들, 그리고 동일한 버퍼가 인자로 전달됩니다. 이는 전형적인 복호화 루틴의 동작 방식이고, 인자는 다음과 같이 구성됩니다.

• 디코딩할 버퍼 (ebx)
• 디코딩할 데이터의 크기 (dwSize)
• 키 (unk_403008)

 

Figure 40에서도 확인했던 키는 아래에 다시 볼 수 있습니다.

[Figure 46] unk_403008

 

 

sub_40158E 루틴을 살펴보면 다음과 같은 내용을 확인할 수 있습니다.

[Figure 47] sub_40158E

 

강조된 코드 부분이 실제 복호화가 이루어지는 곳이며 이를 디컴파일러로 보면 더 명확하게 이해할 수 있습니다.

[Figure 48] sub_40158E (디컴파일됨)

 

이제 어떤 일이 일어나고 있는지 확실히 알 수 있으며 앞서 추출한 코드가 예상대로 인코딩되어 있었다는 것이 드러났습니다. 이해를 더 쉽게 하기 위해 일부 수정한 코드는 아래와 같습니다.

[Figure 49] sub_40158E (디컴파일 및 재명명된 코드)

여기 몇 가지 주목할 사항이 있습니다.

• dwSzie는 836바이트로 지정되어 있지만(.data:00403004에서 확인), 실제 추출된 코드는 1016바이트입니다. 그러나 이는 자동으로 처리되므로 지금은 당장 걱정하지 않아도 됩니다.
  
  
• 키는 단일 바이트가 아니라 4바이트입니다.
  
  
• 복호화 과정은 Figure 49의 line 13이 핵심입니다.

 

이제 해야할 일은 앞서 추출한 인코딩된 코드를 읽고 복호화하여 결과를 새로운 파일로 저장하는 파이썬 스크립트를 작성하는 것입니다. 물론 원하는 언어로 구현해도 괜찮습니다.

[Figure 50] decryptor_final.py

스크립트에는 적절한 주석이 포함되어 있고 다음과 같은 유효한 사항들이 있습니다.

• 키는 line 24에 입력하였습니다(Figure 46에서 키를 확인하세요).
  
  
• 디컴파일된 코드의 변수 이름을 거의 그대로 사용하지만 이름 ptr_mem은 decoded로 변경하였습니다.

 

IDA Python으로 동일한 스크립트를 작성해 디코딩할 바이트와 키를 자동으로 추출할 수 있지만, 다른 샘플에 재사용할 가능성이 낮기 때문에 시간 낭비일 수 있습니다.

[Figure 51] 복호화 스크립트 실행

 

잘 작동했습니다! 물론 제대로 복호화되었는지는 IDA Pro에서 검토해봐야 되지만, User-Agent와 IP 주소가 중간에 이상한 문자 없이 평문으로 보인다는 것은 복호화 스크립트가 올바르게 작동했음을 보여주는 좋은 신호입니다. 다음 섹션에서는 추출된 코드를 다른 방법으로 검토하여 실제로 쉘코드인지 확인할 것입니다.

따라서 아래와 같이 IDA Pro에서 decoded_shellcode.bin을 열어보겠습니다.

[Figure 52] 복호화된 쉘코드

 

완벽하게 복호화되었습니다! 모든 단계를 보여주지 않았지만 다음 작업들이 수행되었습니다.

• 파일은 바이너리(32비트)입니다.
  
  
• 첫 번째 바이트가 코드로 변환되었습니다(C 단축키).
  
  
• 첫 번째 명령어에서 P 키를 눌러 새 함수를 생성하였습니다.

 

이 시점 이후로는 첫 번째 예제에서 사용한 동일한 접근 방식과 기술을 반복할 수 있고 모든 것이 잘 작동해야 합니다.

IDA Pro에서 쉘코드를 분석하는 것은 항상 가능하지만 여러 경우에 바이너리가 준비되어 분석될 수 있도록 사전 작업이 필요할 수 있습니다.

 

 

 

[Emulation]

쉘코드를 가지고 있다면, 그 실행을 에뮬레이션하여 무엇을 하고 시스템과 어떻게 상호작용하는지 알 수 있습니다. 여러 쉘코드 에뮬레이터가 있지만 잘 알려진 두 가지는 다음과 같습니다.

• scdbg: https://sandsprite.com/blogs/index.php/index.php?uid=7&pid=152
• speakeasy: https://github.com/mandiant/speakeasy

 

두 가지 모두 쉘코드 에뮬레이션에 효율적이지만, Speakeasy는 훨씬 더 많은 기능을 제공하고, 예를 들어 Cobalt Strike 비콘과 같은 도구를 관리하는데 매우 적합합니다.

example 02에서 추출한 쉘코드는 다음 명령어를 실행하여 쉽게 에뮬레이션할 수 있습니다(심지어 Wine을 통해 Linux에서도 가능합니다).

[Figure 53] scdbg를 통한 쉘코드 에뮬레이션

 

위 명령어는 간단하니 모든 명령어가 실행되는 과정을 보여줄 수 있도록 단계(/s 옵션)를 변경했습니다. IP 주소에 대한 정보는 다음 명령어를 실행하여 수집할 수 있습니다.

[Figure 54] IP 주소 정보

 

speakeasy를 사용해도 다르지 않고 이를 사용하여 쉘코드 샘플을 에뮬레이션할 수 있습니다.

[Figure 55] speakeasy를 통한 쉘코드 에뮬레이션

 

 

다른 예로는 Cobalt Strike 비콘과 같은 약간 다른 유형의 쉘코드를 분석하는 것입니다. 이 쉘코드는 이전 쉘코드와 동일한 행위를 하지만 추가적인 지표를 제공합니다.

• shellcode_03.bin: f067744430110ffc62618ceac48f764d4be90ee44f3bd6bcf8c5d1ba0a8d046e

 

확인해보면 다음과 같습니다.

[Figure 56] shellcode_03.bin 내용

 

이 코드가 쉘코드라는 강력한 단서가 있습니다. IDA Pro에서 분석하는 대신(절차는 이전과 동일하므로), 이번에는 speakeasy를 사용하여 이를 에뮬레이션하겠습니다.

[Figure 57] speakeay를 통한 shellcode_03.bin 에뮬레이션

 

에뮬레이션 결과로 생성된 report.json의 마지막 줄을 확인해보면 다음과 같습니다.

[Figure 58] report.json

 

IP 주소를 통해 수집한 정보입니다.

[Figure 59] IP 주소 정보

 

memory_dump.zip 파일을 별도의 디렉토리에 복사하고 그곳에서 압축을 해제하세요. 압축을 해제하면 여러 파일이 생성되는데 에뮬레이션 보고서(Figure 58)에 따르면 실제로 중요한 코드 세그먼트는 api.VirtualAlloc.0x50000이고, 이 세그먼트는 에뮬레이션된 쉘코드의 내용을 포함하고 있습니다.

[Figure 60] 동적 코드 세그먼트의 내용

 

 

 

[Conclusion]

이 글에서는 쉘코드 분석에 대한 입문 내용을 제공했습니다. 더 많은 예제를 다룰 수도 있지만 이미 제시된 예제들과 상당히 유사하므로 두 개만 다뤄봤습니다.

Keep learning, reversing, and exploiting everything, and I will see you next time!