1. ShellCode란
- Exploit의 페이로드로 이용되는 작은 크기의 코드
- 페이로드의 목적뿐만 아니라 악성코드 드엥 의해 다양한 상황과 목적에 활용됨
- 오늘날은 기계어와 데이터로 이루어져있음
셸코드를 분석하기에 앞서 셸코드의 동작방식을 이해해보자.
먼저 실행파일이 로더에 의해 로딩된 이후 다양한 DLL을 불러온다. (kernel32.dll , user32.dll)
프로그램이 실행되면 프로그램 내부의 헤더와 코드가 실행된다.
이후 라이브러리에 정의된 함수들을 호출하게 될 것이고, 리턴코드가 실행되면서 위 DLL들을 가져오게 된다.
만약 실행파일의 내부에 셸코드가 있다면, 가상 메모리 공간인 스택 버퍼 혹은 힙 버퍼에 적재될 수 있다.
셸코드는 각각의 라이브러리 내의 함수 주소를 알 수 없으므로 바인딩이라는 작업을 해야한다.
이렇듯 기존 프로그램의 비정상적인 동작을 이끌어내서 셸코드를 적재해야하므로 공격자는 Exploit을 해야한다.
그 과정에서 셸코드는 네트워크 보안 솔루션을 지나야하므로 암호화를 해야한다.
그래서 결론적으로 셸코드의 실행을 위해서는 1. 바인딩 과정, 2. 암호의 디코딩 과정이 필요하게 된다.
셸코드의 바인딩에서, 함수 실행 중 바인딩을 직접 수행하므로 동적 바인딩 혹은 셀프 바인딩이라고 한다.
이 때 셸코드는 필연적으로 로드 라이브러리나 GetProcAddress와 같은 API를 반복적으로 호출할 수 밖에 없다.
2. API 해시의 기본개념
먼저 앞서 이야기한 바인딩에 대해서 알아보자.
바인딩(Binding)이란?
- 실행파일이 로더에 의해 메모리에 매핑될 때 로더에 의해서 받는 서비스
실행파일이 메모리 어느 주소에 할당될 지 모르기 때문에
먼저 IAT(Import Address Table)에 함수의 이름 포인터들을 저장한다.
이후 로더에 의해 IAT가 Overwritting되면서 라이브러리의 함수 주소들을 가리키게 된다.
셀프 바인딩을 위해서는 LoadLibrary("DLL name")과 GetProcAddress(DLL Handle, "Function Name")이 필요하다.
*DLL Handle = DLL에 로딩된 메모리 주
셀프 바인딩을 위해서는 DLL 핸들의 이름을 알아야하므로 로드라이브러리를 호출해
GetProcAddress의 리턴값을 핸들로 주게 된다.
결국 악성코드 제작자는 다음과 같은 문제점을 해결하려 할 것이다.
1. 메모리 적재를 위한 셸코드의 경량화 ( 함수, 라이브러리 문자열 길이 )
2. 문자열 분석을 통한 정보의 노출
따라서 API 해시를 사용할 수 밖에 없다.
API 해시
- Function()의 값을 HASH()의 Input값으로 전달해 나온 해시값의 앞부분을 추출해 만든 값
- 길이도 짧아지며 정보의 노출도 막게 된다.
따라서 악성코드 분석가는 사전에 API 해시의 Dictionary를 만들어 해시값과 비교해보게 된다.
3. API Hash Matching - YARA Rule_Set
yara 룰은 악성 파일을 시그니처 기반으로 판별하고 분류할 수 있게 만든 툴이다.
기본적인 코드 틀은 다음과 같다.
rule RuleName
{
strings:
searching variable
condition:
searching condition
}
Yara 룰을 이용한 분석 예시를 보자.
yara는 구글링해보면 여러 룰들이 나온다.
위 사진은 yara64에 -r 옵션(recursive searching)을 더해 API 해시 매칭을 해본 것이다.
(사용한 rule은 ror13add)
물론 이것으로 끝난게 아니다.
여러 API들이 어떤 기능을 하는지에 대해 지식이 있어야하고 리턴값과 입력값에 대한 정보도 필요할 것이다.
물론 구글링을 통해 하나하나 찾아볼 수도 있다.
그럼 이제 이 정보들을 바탕으로 IDA를 통해 어셈블리 코드를 살펴보자
4. Debugging - API Hash Pattern Matching
IDA로 파일을 열어보면 다음과 같다.
loc_27부분을 보면 앞서 사용한 룰셋인 ror13add와 맞게
ror과 add연산이 이루어지고 있는 것을 볼 수 있다.
다음으로 Hex 툴을 통해 앞서 찾았던 API들을 검색해보자.
위 사진은 ExitProcess_56a2b5f0를 찾은 모습이다.
리틀 엔디언 방식으로 배열되었기 때문에 순서는 거꾸로 나온다.
위 16진수 값이 ExitProcess의 API 해시값이 되겠다.
그밖에도 힙 메모리를 할당하는 VirtualAlloc과 여러 Internet API들도 찾아볼 수 있는데,
Http와 관련된 API들이 있는 것으로 봐서, HTTP를 이용한 C2 통신을 한다고 추측할 수 있다.
이러한 API를 보면, 인터넷에서 다운로드하는지, 어느 디렉토리에 다운로드 하는지 직관적으로 알 수 있다.
5. Debugging - ShellCode Strings
우선 셸코드의 문자열을 분석하면 도메인이 어떤 통신을 하는지, 아이피 내에 어떤 URI로 요청을 발생시키는지 알 수 있다.
우선 문자열을 분석하기 이전에 위 Hex파일을 txt파일로 바꿔서 열어봤다.
열어본 결과 /iWWE가 보인다. 이것이 HTTP의 URI 패턴일 가능성이 높고 baidu.com이 C2 도메인일 수 있다.
그리고 그 아래에 http header정보인 user-agent가 나타난 것을 볼 수 있다.
정리해보면, 공격자가 C2통신을 위해 HTTP를 사용하며, 이 요청 메세지 안에 user-agent가 포함될 가능성이 높다.
또한 마지막에 나타난 아이피가 C2 IP일 수 있다.
C2 통신이란?
Command & Control
양방향 통신으로, 감염된 대상에게 공격자가 명령을 보내거나
대상으로부터 데이터를 다운로드 및 유출할 수 있는 통신
하지만 이러한 텍스트파일 분석은 어디까지나 정보수집이므로 분석을 위해서는 다른 방법을 사용할 필요가 있다.
따라서 scdbg.exe(Shellcode debugger)를 통해 분석해보자.
서버 아이피와 포트, 그리고 Http Request가 보이고
Internet으로부터 무언가를 받아와 힙 영역에 할당시킨다는 것을 볼 수 있다.
이제 직접적인 셸코드 디버깅을 해보자.
디버깅 방법에는 크게
1. 셸코드를 실행파일로 변환
2. 메모리에 로딩하는 프로그램 사용
3. 호스트 프로세스에 인젝션
이 있다.
이 중 3번을 이용해본다.
윈도우 텍스트 편집기인 notepad.exe(호스트 프로세스)에 셸 코드를 주입해서 디버깅해보자.
빈 공간에 우클릭하여 메모리 할당을 해준 후
셸코드를 복사해 크기를 무시하고 붙여넣어준다.
이제 셸코드가 실행되도록 시작지점을 설정해준다.
이제 다시 IDA로 돌아가서
export DLL 부분을 찾아준다. 이곳을 찾는 이유는 셸코드들도 API 해시값이 어떤 함수인지 알기 위해서
export DLL을 확인하므로 같이 비교해보기 위해서다.
위와 같은 코드는 call ebp와 push가 계속 등장하는 것으로 봐서 파라미터 전달을 하고 있는 것 같다.
로딩을 할 라이브러리는 push에 들어가는 값이고, 우클릭으로 확인해보면 wininet.dll을 확인할 수 있다.
이제 x32dbg로 돌아와 call ebp들에 중단점을 걸고 디버깅을 시작한다.
앞서 IDA에서 확인했던 것과 같이 wininet가 로드 라이브러리에 로딩시킬 파라미터 것을 알 수 있다.
다시 진행하다보면 C69F로 시작하는 값이 나오는데 이것은 앞서 scdbg에서 봤던
InternetConnectA의 API 해시값이 되겠다.
파라미터로는 IP주소가 들어감을 알 수 있고, 커넥션을 맺겠다는 유력한 증거가 된다.
따라서 정리하자면, 위 아이피 주소의 /iWWE 경로로 http 요청을 보낸다는 것을 알 수 있다.
'정보보안 > Spear-Phishing' 카테고리의 다른 글
| [Spear-Phishing] Malicious HWP Document Triage, PostScript Analysis (0) | 2023.08.28 |
|---|---|
| [Spear-Phishing] Malicious HWP Document Analysis (0) | 2023.08.27 |
| [Spear-Phishing] Malicious Document의 구성요소 (0) | 2023.08.27 |
| [Spear-Phishing] Spear-Phishing Email Analysis (0) | 2023.08.27 |
| [Spear-Phishing] Fileless Attack (0) | 2023.08.27 |
