Beyond PE Files: Extracting Evidence from MSI and Legacy Word DOC Files with MalwareINFO Pro

Why look beyond PE files?

Our earlier introduction to MalwareINFO Pro Payload & Memory Analyzer focused mainly on Portable Executable files and retained memory artifacts. That is a natural starting point: an EXE or DLL exposes headers, sections, imports, resources, strings, signatures, and other structures that can be inspected directly.

Real investigations rarely stop at a standalone PE, however. Windows Installer packages can carry several files, define installation-time actions, write Registry values, and launch an extracted program. Legacy Microsoft Word documents can contain VBA projects, form data, OLE objects, external relationships, and code that reconstructs or launches another stage.

Those formats require different questions. For an MSI, we want to know what it contains and what the installer is configured to do. For a Word document, we want to know what the document can trigger, what source can be recovered, and whether embedded or derived content is available. In both cases, the first task is to extract and preserve evidence without running the sample.

This article demonstrates that workflow with two real analysis results:

• GlobalProtect.msi, a deceptive installer previously examined in our investigation of a fake GlobalProtect campaign targeting Myanmar; and
• dop0035-2025.doc, an encrypted legacy Word document associated with the delivery chain discussed in our DellHeuristics runtime and memory analysis.

The files and extracted content described below were inspected statically. Payload & Memory Analyzer did not install the MSI, open the document in Microsoft Word, execute VBA, run extracted files, or contact the observed infrastructure.

The screenshots below come from a later static-only review of the same SHA-256-identified files. They show the workflow and report surfaces; the cited findings remain tied to the retained analysis bundles.

One workflow, two different containers

The practical workflow is similar for both formats:

1. Select a preserved copy of the source file.
2. Confirm the file identity and detected container in Preflight.
3. Review expected coverage, resource limits, and any required analyst input.
4. Start the static analysis.
5. Separate directly observed content from derived or inferred findings.
6. Review extracted files or recovered source together with their hashes and provenance.
7. Read coverage and diagnostics before interpreting an empty or incomplete section.
8. Preserve the complete local report bundle for later verification.

The important difference is what “extraction” means. The MSI path can materialize files from installer media and send supported children through bounded static analysis. The Office path can recover VBA source and extract only supported embedded script evidence. Other document objects may be inventoried without being exported or executed.

Case 1: extracting the fake GlobalProtect MSI

The source package was 3,475,968 bytes with SHA-256:

A124CAA58D956C7430ECB8772A3794266235917670C5B56564342BD1456897E7

Preflight identified the package and preserved three useful Windows Installer identities:

The report also bound an embedded cabinet to its own length and SHA-256 before extraction. This matters because an installer database and the media it references are separate evidence objects. A filename or cabinet label alone is not enough to prove that the extracted bytes came from the expected source.

The extraction result

The operation completed with five declared files and five extracted files. Declared and extracted totals both equaled 7,029,332 bytes, and the report contained no terminal diagnostic.

Each file retained its installer File and Component identity, media identity, logical target path, stored report path, declared length, actual length, and digest. Supported PE children entered the Analyzer’s bounded child-analysis path; the PNG remained inventory evidence rather than being presented as an executable analysis result.

Installer configuration worth investigating

The MSI report highlighted three security-relevant categories: ElevatedCustomAction, RunOrRunOnce, and UpgradeRemoval. These names summarize installer configuration. They do not say that Windows Installer actually ran the package or that any child process executed.

The CustomAction row associates the extracted GlobalProtect.exe with the target argument /Install. The InstallExecuteSequence schedules that action at sequence 5999 when its component action state satisfies the recorded condition.

CustomAction target: /Install
CustomAction type:   3090
Sequence:            5999

The Registry table contains two RunOnce rows named GlobalProtectVPN, one under each recorded root, both pointing to:

C:\Program Files\PaloAlto\GlobalProtect VPN\GlobalProtect.exe

The action sequence also places RemoveExistingProducts at sequence 6550, supported by the matching Upgrade table row. Together, these rows describe intended installation, persistence, and upgrade behavior. Static inspection does not establish that the corresponding Registry values were written or that the executable ran.

Reading Partial coverage correctly

The MSI operation status was Completed, while overall coverage was Partial. Those states answer different questions. Completed means the bounded operation reached a terminal completed state. Partial means the report did not claim complete semantic projection of every table or every possible evidence family.

The detailed result recorded 230 MSI evidence rows, three summarized findings, and no terminal diagnostics. Extracted-child analysis published another 73 evidence records without omitted records. The report’s coverage section should therefore be read alongside the findings rather than replaced by a simple “analysis succeeded” statement.

Case 2: recovering evidence from dop0035-2025.doc

The second sample was 882,176 bytes with SHA-256:

EADD9F97166B59A02D9C25CD2FF721ED06B7C28050AA08DB3FE80B97ACBB80BA

Content-based Preflight identified it as EncryptedCompoundOffice. This is more meaningful than trusting the .doc suffix: legacy Word documents use the Compound File Binary/OLE container, while modern .docx and .docm files normally use an Open XML ZIP container.

The report records a completed analysis and two recovered VBA modules:

• ThisDocument, recovered from word/vbaProject.bin!/VBA/ThisDocument; and
• UserForm1, recovered from word/vbaProject.bin!/VBA/UserForm1.

The bundle manifest binds both recovered text files by length, SHA-256, evidence ID, and source-container location.

Why the coverage is Partial

Container parsing, VBA recovery, document-mechanism inspection, deterministic decoding, and script extraction each reported Complete. Overall coverage remained Partial because schema v1 did not implement VBA P-code comparison.

This is an important reporting distinction. The Analyzer recovered the source available to it, but it did not compare that source with compiled P-code and therefore could not make a VBA-stomping assessment. The missing comparison should not be translated into either “stomping detected” or “stomping absent.”

Following the recovered VBA rather than stopping at the alert

The automated report produced two behavior findings:

• a high-severity office.autoexec.command inference with confidence 85; and
• a medium-severity office.network-download inference with confidence 75.

Those findings are useful starting points, not a substitute for reading the recovered module. ThisDocument contains an actual Document_Open procedure that calls four deliberately unhelpful function names:

Sub Document_Open()
    HDFKJH98549J
    GFUYG7TRRYDRGJHF4758
    JFDBJDHHGJHHFD857
    FDJHD745UFGU75HG
End Sub

The procedure establishes an automatic execution entry point in the document source. Because this was a static analysis, the report establishes the presence of that entry point; it does not claim that a user opened the document with macros enabled.

Reconstructing a ZIP from UserForm data

One called function declares a byte array, splits UserForm1.TextBox1.Text on hyphens, converts each element to a byte, and writes the result to:

%LOCALAPPDATA%\Microsoft\DellHeuristics.zip

A shortened representation of the recovered logic is:

Dim bytesArr(141490) As Byte
values = Split(UserForm1.TextBox1.Text, "-")

For Each value In values
    bytesArr(index) = CByte(value)
    index = index + 1
Next

Open outputPath & ".zip" For Binary Access Write As #3
Put #3, , bytesArr
Close #3

This is a strong example of why source recovery matters. The apparent payload is not represented as a normal embedded executable in the published analysis bundle. The VBA expects to reconstruct a ZIP from form-control text when the macro runs.

The report’s EmbeddedArtifacts and ExtractedScripts collections are empty. MalwareINFO Pro therefore did not claim to have extracted DellHeuristics.zip or DellHeuristics.exe from this document. The recovered source establishes the reconstruction logic and intended output path, but the supplied report does not contain the UserForm byte stream, a reconstructed ZIP hash, or a child executable extracted from it.

Startup and scheduled-task persistence

Another function writes a VBS file into the current user’s Startup folder:

%APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\HDFSGF756yI9aUaB.vbs

The generated script waits for 120 seconds, queries Win32_PingStatus for www.google.com, waits again, and then launches a batch file with a hidden window. The code writes additional VBS and batch stages that use Shell.Application.CopyHere to unpack DellHeuristics.zip and continue the chain.

The final batch content includes a scheduled-task command:

schtasks /create /SC minute /MO 5 /TN DellHeuristicsUpdate /TR "%LOCALAPPDATA%\DellHeuristics.exe" /F

Other generated commands remove the temporary VBS and batch files after the chain has been staged. These operations appear in recovered VBA strings. The static report does not establish that the files were created, the archive was expanded, the task was registered, or DellHeuristics.exe executed on the analyzed host.

Network-related document evidence

The recovered macro creates MSXML2.XMLHTTP and prepares a synchronous GET request to:

hxxps://edmsvpn[.]gov[.]en-mm[.]com/lang=mm

The Office report independently records an observed external relationship:

hxxps://edmsvpn[.]gov[.]en-mm[.]com/favicon.ico

The rule name office.network-download is broader than the exact source shown here. The recovered code demonstrates an HTTP request capability, but it does not show the response body being saved as the ZIP or another file. For that reason, this article does not convert the rule label into a confirmed payload download.

The macro also deletes ActiveDocument.Shapes(2) after sending the request. That can change what the user sees in the document, but static source alone does not establish the visual result or the operator’s intent.

Derived values still require analyst review

The deterministic decoder retained four Base64-derived previews. Their output is short and not readable as a command, URL, script, or configuration value. They remain provenance-linked Derived evidence, but they are not used as headline indicators in this analysis.

This is another reason to retain evidence classifications. A successful transform means that bytes could be decoded under a named operation. It does not guarantee that the source string was intentionally encoded data or that the decoded result has investigative meaning.

What the reports establish—and what they do not

The two cases demonstrate different kinds of static evidence.

The MSI report establishes that the package contains five named files, binds them to exact hashes, and defines CustomAction, RunOnce, and upgrade-related behavior. It does not prove that the package was installed or that GlobalProtect.exe /Install ran.

The DOC report establishes an encrypted compound Office container, two recovered VBA modules, an auto-execution procedure, file-generation and persistence logic, an HTTP request, and an external relationship. It does not prove that Word executed the macro, that the form data was reconstructed into a valid ZIP, that the scheduled task was created, or that the remote server responded.

In both reports:

• Observed identifies content read directly from the validated source;
• Derived identifies output mechanically produced from cited evidence;
• Inferred identifies a rule-based interpretation with stated confidence and known false-positive conditions;
• Completed describes the terminal operation state; and
• Partial preserves a coverage boundary rather than turning missing analysis into a clean result.

A practical review checklist

When analyzing an MSI package:

• Verify source, package, media, and extracted-child identities before interpreting behavior.
• Compare declared and extracted counts and byte totals.
• Review logical target paths as well as stored report paths.
• Read Registry, CustomAction, service, task, and sequence evidence separately.
• Treat static installer intent as configuration, not observed execution.
• Review each child’s own analysis and coverage instead of inheriting the parent result.

When analyzing a legacy Word document:

• Trust the detected container signature rather than the extension alone.
• Check encryption and password-handling state before expecting VBA recovery.
• Start with auto-execution procedures, then follow every called function.
• Review forms, document mechanisms, external relationships, and embedded inventory.
• Distinguish recovered source from an actually extracted child artifact.
• Treat decoder output as evidence only when its content and provenance are meaningful.
• Read P-code comparison coverage before making any statement about VBA stomping.

Final assessment

Payload & Memory Analyzer is not limited to asking whether an EXE or DLL looks suspicious. In the GlobalProtect case, it opened the installer structure, preserved package and cabinet identity, extracted five files, calculated their hashes, and exposed the configuration that would invoke and persist the primary executable. In the Word case, it validated an encrypted legacy Office container, recovered two VBA modules, and exposed a staged chain for ZIP reconstruction, Startup-folder persistence, archive expansion, scheduled-task creation, cleanup, and HTTP communication.

The strongest result is not a single severity label. It is the ability to move from a container to reviewable evidence while keeping identity, provenance, classification, coverage, and non-execution boundaries intact.

That distinction is what makes static extraction useful in a real investigation: analysts can see what the package or document contains and what its code is designed to do before deciding whether any separate runtime experiment is necessary.