[RTF] Analysis of a Document-Based Malware Sample

Summary

This post focuses on a single sample that uses a .doc extension, but asks a narrower set of questions: what the real internal format is, which OLE object becomes the key clue, how the unknown data seen in static analysis behaves during dynamic analysis, and how far the sample can be mapped to the CVE-2018-0798 exploit path.

Reorganized in the blog’s newer structure, the most defensible conclusion is that the sample is internally RTF, that eQuaTIon.3 and EQNEDT32.EXE are central clues, and that the objdata seen during static analysis later becomes the shellcode region reached after stack corruption.

Document Information

• Written on: 2023-04-16
• Verification date: 2026-04-16
• Document type: analysis
• Test environment: based on the original analysis record, Windows document-analysis environment, Word 2003, .doc sample, rtfobj, rtfdump.py, and a debugger
• Test version: Office/Word 2003 confirmed; exact versions of rtfobj, rtfdump.py, and the debugger were not recorded
• Sample identifier: SHA-256 ffc735ea518844e8fb5276905b5368a23f9953ee18c235c51aebf9553dc2974f
• Source quality: NVD, Microsoft’s advisory, Microsoft documentation, and tool-author references were preferred.
• Note: this revision restructures the original analysis notes and screenshots into the current template. The update mainly clarifies scope, source linkage, and fact-versus-interpretation boundaries.

Problem Definition

This post is trying to answer the following questions.

• Why does the sample behave like an RTF document even though it uses a .doc extension
• Why are objdata and eQuaTIon.3 the key static-analysis clues
• At what point does execution pivot during dynamic analysis, and what does the unknown blob appear to be
• How far can that flow be connected to the public description of CVE-2018-0798

It does not attempt to prove the full root cause inside Equation Editor, fully reverse the shellcode, or analyze every post-exploitation stage.

Verified Facts

• According to the official references, CVE-2018-0798 is described as an Equation Editor vulnerability involving memory processing. Evidence: NVD CVE-2018-0798, Microsoft advisory
• According to the tool-author references, rtfobj and rtfdump.py are provided as analysis tools for RTF/OLE inspection. Evidence: DidierStevensSuite
• Microsoft documentation describes RTF representations that can include inline objects and OLE-related structures. Evidence: Inline Attachments in RTF Messages

Directly Confirmed Results

1. Real file format and static-analysis starting point

• Result based on the original analysis record: although the sample used a .doc extension, the internal content read as an RTF structure.
• Result based on the original analysis record: rtfobj alone did not provide enough detail, and rtfdump.py was needed to isolate the objdata region.

rtfobj sample.doc
rtfdump.py sample.doc
rtfdump.py sample.doc -s 4 -H

2. eQuaTIon.3 and the object-data structure

• Result based on the original analysis record: the ASCII-converted output from rtfdump.py -s 4 -H revealed the string eQuaTIon.3.

• Result based on the original analysis record: the objdata structure was read as follows.

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

• In practical terms, that meant:

1. the sample referenced an OLE class name associated with EQNEDT32.EXE,
2. a large unknown blob followed it, and
3. static analysis alone was not enough to determine the final behavior.

3. Execution-flow change during dynamic analysis

• Result based on the original analysis record: opening the document also launched EQNEDT32, after which a function path showed visible stack changes.
• Result based on the original analysis record: a helper routine repeatedly wrote bytes onto the stack, and the return address changed when the function returned.

4. Identity of the unknown blob

• Result based on the original analysis record: following execution after ret led into the embedded OLE object-data region inside the RTF file.
• Result based on the original analysis record: the bytes at that address matched the same unknown blob observed during static analysis, making the shellcode interpretation the strongest one.

Interpretation / Opinion

• Interpretation: the sample is better understood as an RTF document carrying an embedded OLE object and an exploit chain, not as a conventional .doc file in the older binary-document sense.
• Interpretation: because eQuaTIon.3, EQNEDT32.EXE, and the advisory description all align, mapping this sample to the CVE-2018-0798 family is the most persuasive reading. That said, this post does not go as far as patch-diff or symbol-level root-cause proof, so it should be treated as a strong mapping rather than an absolute proof statement.
• Opinion: the most valuable analytical result here is not the exact bug-class label by itself, but the fact that the objdata seen in static analysis later becomes the shellcode execution region in dynamic analysis.

Limits and Exceptions

• This revision is based on the original analysis record, so the exact build and patch level of Word 2003, along with the debugger version, are unavailable.
• The CVE-2018-0798 mapping is an interpretation grounded in strong evidence and the public advisory, not a line-by-line proof of the vulnerable code path.
• The full shellcode behavior, any dropped payload, and network activity are outside the scope of this post.
• This is a single-sample analysis and should not be generalized to every RTF-based malware document.

References

• NVD CVE-2018-0798
• Microsoft advisory
• Inline Attachments in RTF Messages
• DidierStevensSuite