[RTF] 문서형 악성코드 분석
요약
이 글은 .doc 확장자를 가진 샘플 하나를 대상으로, 실제 내부 포맷이 무엇인지, 어떤 OLE 객체가 문제의 시작점인지, 정적 분석에서 보였던 알 수 없는 데이터가 동적 분석에서 어떻게 실행 흐름으로 이어지는지를 정리한 분석 기록이다.
기존 분석 기록을 현재 블로그 구조로 재정리하면, 이 샘플은 내부적으로 RTF 구조를 가지며 eQuaTIon.3와 EQNEDT32.EXE 흐름이 맞물린다. 정적 분석에서 보였던 objdata는 동적 분석에서 스택 손상 이후 실행이 넘어가는 shellcode 영역으로 읽는 것이 가장 자연스럽다.
문서 정보
- 작성일: 2023-04-16
- 검증 기준일: 2026-04-16
- 문서 성격: analysis
- 테스트 환경: 기존 분석 기록 기준 Windows 문서 분석 환경, Word 2003,
.doc확장자 샘플,rtfobj,rtfdump.py, 디버거 - 테스트 버전: Office/Word 2003 확인,
rtfobj,rtfdump.py, 디버거 세부 버전 미기록 - 샘플 식별자: SHA-256
ffc735ea518844e8fb5276905b5368a23f9953ee18c235c51aebf9553dc2974f - 출처 등급: NVD, Microsoft advisory, Microsoft 문서, 도구 원저자 자료를 우선 참고했다.
- 비고: 이 글은 기존 분석 기록과 스크린샷을 현재 템플릿으로 재구성한 것이다. 이번 개정에서는 분석 범위, 근거 연결, 해석 경계를 더 분명히 적었다.
문제 정의
이 글이 답하려는 질문은 아래와 같다.
- 이 샘플은 왜
.doc확장자와 달리 RTF 구조로 읽히는가 - 정적 분석에서
objdata와eQuaTIon.3가 왜 중요한 단서인가 - 동적 분석에서 실행 흐름은 어느 지점에서 꺾이고, 알 수 없는 데이터는 무엇으로 보이는가
- 이 흐름이
CVE-2018-0798설명과 어디까지 맞물리는가
반대로 이 글은 Equation Editor 내부 버그의 패치 단위 원인 분석이나, shellcode 전체 기능 복원, 후속 페이로드의 완전한 행위 분석까지 다루지 않는다.
확인된 사실
- 공식 자료 기준으로
CVE-2018-0798은 Equation Editor와 메모리 처리 문제를 다루는 취약점으로 설명된다. 근거: NVD CVE-2018-0798, Microsoft advisory - 원저자 도구 자료 기준으로
rtfobj와rtfdump.py는 RTF/OLE 구조를 들여다보는 분석 도구로 제공된다. 근거: DidierStevensSuite - Microsoft 문서는 RTF 표현과 inline object/OLE 관련 구조가 메시지 표현 안에 포함될 수 있음을 설명한다. 근거: Inline Attachments in RTF Messages
직접 확인한 결과
1. 파일 형식과 정적 분석 출발점
- 기존 분석 기록 기준 직접 확인한 결과: 샘플은
.doc확장자를 쓰고 있었지만 내부 데이터는 RTF 구조로 읽혔다. - 기존 분석 기록 기준 직접 확인한 결과:
rtfobj만으로는 충분한 단서를 얻기 어려웠고,rtfdump.py로objdata영역을 추적해야 했다.
rtfobj sample.doc
rtfdump.py sample.doc
rtfdump.py sample.doc -s 4 -H
2. eQuaTIon.3와 객체 데이터 구조
- 기존 분석 기록 기준 직접 확인한 결과:
rtfdump.py -s 4 -H로 본 ASCII 데이터에서eQuaTIon.3문자열이 드러났다.
- 기존 분석 기록 기준 직접 확인한 결과:
objdata내부를 읽을 때 아래와 같은 구조를 확인했다.
3B B9 BD 5C : OLE version
02 00 00 00 : Format ID
0B 00 00 00 : Class Name Length
65 51 75 61 54 49 4F 6E 2E 33 : Class Name eQuaTIon.3
00 00 00 00 : Topic Name
00 00 00 00 : Item Length
C6 05 00 00 : Data Size
- 직접 관찰을 요약하면 이 시점에서 확인할 수 있었던 것은 아래 정도였다.
EQNEDT32.EXE와 연결되는 OLE class name이 보였다.- 그 뒤에 의미를 바로 알기 어려운 큰 데이터 블롭이 있었다.
- 따라서 정적 분석만으로는 최종 행위를 단정하기 어려웠고, 동적 분석이 필요했다.
3. 동적 분석에서 본 실행 흐름 변화
- 기존 분석 기록 기준 직접 확인한 결과: 문서를 열면
EQNEDT32가 함께 실행됐고, 이후 특정 함수 흐름에서 스택이 바뀌는 장면을 볼 수 있었다. - 기존 분석 기록 기준 직접 확인한 결과: 보조 루틴은 반복문으로 스택에 데이터를 써 넣는 형태였고, 함수가
ret될 때 반환 주소가 바뀌었다.
4. 알 수 없는 데이터의 정체
- 기존 분석 기록 기준 직접 확인한 결과:
ret이후 도달한 주소를 따라가면 RTF 내부 OLE 객체 데이터가 있는 영역으로 실행 흐름이 넘어갔다. - 기존 분석 기록 기준 직접 확인한 결과: 그 지점의 바이트는 정적 분석에서
objdata로 보였던 알 수 없는 데이터와 맞물렸고, shellcode로 읽는 것이 가장 자연스러웠다.
해석 / 의견
- 해석: 이 샘플은
.doc확장자를 달고 있지만 실질적으로는 RTF 문서 안에 OLE 객체 데이터와 exploit chain을 숨겨 둔 사례로 읽는 편이 맞다. - 해석:
eQuaTIon.3,EQNEDT32.EXE실행, advisory의 설명이 서로 맞물리기 때문에CVE-2018-0798계열 흐름으로 보는 해석이 가장 설득력 있다. 다만 이 글은 패치 비교나 심볼 수준 원인 분석까지는 하지 않았으므로, “가장 가능성이 높은 매핑” 이상으로 과장하지 않는다. - 의견: 이 글에서 핵심은 정확한 버그 클래스 이름보다, 정적 분석에서 보였던
objdata가 동적 분석에서 실제 shellcode 실행 영역으로 이어졌다는 연결을 확보한 점이다.
한계와 예외
- 이번 개정은 기존 분석 기록을 재정리한 작업이라, 당시 Word 2003의 정확한 빌드, 패치 수준, 디버거 버전은 남아 있지 않다.
CVE-2018-0798매핑은 강한 정황과 공식 advisory를 바탕으로 한 해석이지, 취약 코드 라인까지 증명한 루트 원인 분석은 아니다.- shellcode의 전체 기능, 후속 드롭 파일, 네트워크 통신 여부는 이 글에서 다루지 않았다.
- 단일 샘플 기반 분석이므로, 모든 RTF 문서 악성코드에 그대로 일반화하면 안 된다.
댓글남기기