[Spear-Phishing] Malicious HWP Document Object Analysis

1. HWP Architecture

• HWP 3.X 버전의 시그니처 "48 57 50 20 44 6f 63 75"
• HWP 5.0 버전의 시그니처 "d0 cf 11 e0 a1 b1 1a e1"
• 5.0의 경우 OLE(Object Linking and Embedding)파일 기반
• 여러 개의 스토리지와 데이터 스트림으로 구성

---

2. OLE Based HWP Analysis

 

우선 버전을 확인하기 위해 시그니처를 살펴보면, 아래와 같이 5.0버전인 것을 알 수 있다.

 

5.0

 

이후 Oledump를 이용해 파일을 확인하고 png파일부터 OLE파일까지 모두 추출해줬다.

 

 

우선 추출된 파일들의 경우 한글 문서의 파일이므로 zlib을 통해 압축되어있을 것이다.

 

이를 decompress해줘야 정상적인 png파일의 시그니처도 살아날 것이다.

 

변환된 png파일은 다음과 같다.

 

 

 

위 두 png파일에 대해 자세히 알아보기 위해 악성 문서를 열어봤다.

 

 

HWP

 

열어본 결과 묶음 개체로 사용자가 클릭하도록 유도하는 화면을 볼 수 있다.

 

check

 

확인버튼의 하이퍼링크를 살펴보면 apisecurity.vbs와 연결된 것을 볼 수 있다.

 

다음으로 OLE 파일 3개를 살펴보면 다음과 같은 결과가 나온다.

 

BIN0003

BIN0004

BIN0005

 

3번 파일에서는 apisecurity의 key파일, 4번에서는 bat파일과 PE파일의 시그니처인 MZ,

 

그리고 5번에서는 vbs파일이 등장했으며, 아래에 코드들도 보인다.

 

우선 정리하자면, 이 파일은 악성 문서가 실행되면 사용자에게 가짜 창을 띄워, 확인 버튼 이미지에

 

악성 OLE 오브젝트를 연결해 사용자가 실행하도록 유도하는 방법을 사용한다.

 

한글 파일이 실행될 때 OLE파일은 Temp경로에 생성되므로 apisecurity파일을 수집해보자.

 

Temp

 

vba파일을 살펴보자.

 

vba

 

위 코드를 살펴보면 CreateObject로 파일시스템오브젝트와 셸 객체를 만들고 있다.

 

이후 파일들의 경로를 지정하고, Resources.pri 파일이 있는지 확인하고, 존재하지 않으면 지정경로로 옮긴다.

 

이후 파일이 patch 파일의 존재유무를 확인한 후 없다면 오류를 일으키고 LogBat파일을 숨김으로 실행한다.

 

이는 DLL Planting 기법을 활용한 것으로, DLL을 특정 위치에 심어서 로그시키는 기법이다.

 

DLL 로드 우선순위

1.  프로그램이 설치된 디렉토리
2. GetSystemDirectory 함수를 통해 반환되는 시스템 디렉토리
3. 16-bit 시스템 디렉토리
4. GetWindowsDirectory 함수를 통해 반환되는 윈도우 디렉토리
5. 현재 디렉토리
6. PATH 환경변수에 등록된 디렉토리

 

위 코드는 따라서 정상적인 OneDrive.exe 프로그램이 실행될 때, 동일 경로의 악성 xmllite.dll 파일이 함께 로딩되어 실행된다.

 

다음은 bat 파일을 살펴본다.

 

bat

 

우선 Echo off로 배치파일의 프롬프트와 내용이 표시되지 않게 설정하고, 현재 실행하는 hwp.exe를 강제종료 시킨다.

 

다음으로 key파일을 살펴보기 전에 PE파일의 구조를 알아보고 가자.

 

PE파일의 구조

PE Header
- Dos 호환성
- PE 시그니처를 가짐

Section Header
- Text Section
- RData Section
- DataSection

Section
- PE 파일의 실제 내용을 담은 블록

 

이제 PEView를 통해 PE 구조를 분석해보자.

 

공격자는 추가 바이너리와 문서, 설정데이터와 같은 정보를 리소스 섹션에 저장해 추가 악성파일을 드랍하는 경우가 있다.

 

리소스 섹션은 아이콘, 이미지와 같이 실행파일로 간주되지 않는 것, 실행파일에 필요한 리소스를 저장하는 공간이다.

.rsrc

 

리소스 섹션은 .rsrc확장자로 되어있으며, 의심스러운 부분이 없기에 정상적인 파일로 보인다.

 

이번엔 SysinternalTools도구 중 SigCheck 를 통해 파일의 서명정보를 확인해보자.

 

Certification

 

이 파일은 서명되지 않은 신뢰할 수 없는 파일이다.

 

이번엔 API함수를 살펴보자.

 

.rdata 이름의 섹션에서 IMPORT Address Table에 존재한다.

 

api

 

WinExec, CreateThread, ExitProcess등이 있는 것으로 보아, 추가적인 파일 실행을 수행하는 것으로 보인다.

 

그리고 WriteFile, ReadFile, SetFilePointer, CreateFile이 있으므로 특정파일을 생성, 쓰기, 읽기 행위를 하는 것으로 보인다.

 

GetConsoleMode, WiteConsole, ReadConsole을 사용하므로, 콘솔창과 관련된 함수도 사용하는 것으로 보인다.

 

정리하면, 파일, 프로세스 실행, 콘솔 명령어 실행과 관련된 행위를 하는 것으로 확인된다.

 

이제 Strings 명령어를 통해 문자열을 추출해보자.

 

strings

 

살펴보면 base64인코딩된 문자열과 bat관련 명령어가 보인다.

 

base64를 디코딩해주자

 

C2

 

C2 도메인 주소가 보인다. 앞의 명령어는 정상 명령어지만, 이 명령어를 악용하여 C2도메인으로 부터 악성 스크립트를 받아 실행하는

 

XSL Script Processing 공격기법을 사용한 것으로 보인다. 이 XSL파일에는 JScript, VBScript가 들어있을 수 있다.