01 ProductCode & UpgradeCode
These two GUIDs define identity at the installer level. The ProductCode uniquely identifies a specific install instance, while the UpgradeCode defines the product family — it's what tells Windows "this is still AcrobatReader, just a newer version."
Understanding their relationship is critical for change control:
- ProductCode changes each release but UpgradeCode stays the same → normal versioning behavior
- UpgradeCode changes unexpectedly between builds → potential repackaging or a malicious fork
- Duplicate ProductCodes across different vendors → major red flag
Most change control failures happen because teams don't validate UpgradeCode behavior before pushing updates. A changed UpgradeCode means Windows won't treat the new version as an upgrade — you'll end up with two installs side by side, often silently.
02 Manufacturer Field
This field is self-declared. It is not cryptographic truth. Any installer can claim to be from "Microsoft Corporation" — and attackers do exactly this.
The critical cross-check is comparing the Manufacturer field against the actual digital signature chain:
manufacturer "Microsoft Corporation" signature Not signed publisher — (no certificate found) ✗ MISMATCH: Claimed manufacturer has no matching certificate
pkgprobe correlates the Manufacturer field, digital signature publisher, and full signing chain automatically — surfacing mismatches like this that would otherwise slip through a manual review.
03 Embedded Custom Actions
This is where MSI analysis gets serious. Custom actions are the mechanism that makes MSIs executable — they go far beyond "copy files." A custom action can launch PowerShell, execute arbitrary EXEs, modify the registry directly, or reach out to external network endpoints during installation.
A well-behaved enterprise MSI keeps custom actions minimal, uses deferred execution only when required, and makes no unexpected external calls. A malicious MSI looks very different:
Encoded PowerShell in custom actions, network calls during the install phase, and actions targeting HKCU\...\Run persistence keys are primary indicators of malicious or unauthorized behavior. pkgprobe flags these individually with severity scores.
04 Network Indicators
Some MSIs embed hardcoded IP addresses, region-based URLs, or telemetry domains that will be contacted during installation or first launch. You should know about this before the installer touches your endpoints — not after your EDR alerts fire.
network_indicators ├─ 37.220.90.14 (RU) ← hardcoded IP, Russian ASN ├─ telemetry.app.io ← analytics domain └─ download.vendor.com ← update check (expected)
The presence of a Russian or unexpected ASN doesn't necessarily mean malice — but it means you should ask before deployment, not after.
05 CVE Correlation
Even legitimate installers from known vendors ship with vulnerable embedded components. A vendored runtime that hasn't been updated in six months. A bundled OpenSSL that's two CVEs behind. pkgprobe maps product name, version, and embedded component strings against the NVD CVE database — giving you a pre-deployment vulnerability posture for every installer you analyze.
Deploying a vulnerable MSI is still deploying risk — even if the MSI itself is signed and legitimate.
06 Signature State
Signature analysis goes deeper than a pass/fail check. pkgprobe evaluates the entire chain: the MSI signature, embedded CAB signatures, and signatures on dropped EXEs. Inconsistencies between these are a major red flag — an outer MSI that's signed but drops unsigned payloads is a common evasion pattern.
- Unsigned MSI → block unless explicitly approved
- Unknown publisher → cross-check manufacturer field
- Expired certificate → was this installer meant for deployment now, or is it old?
- Chain mismatch → treat as potentially tampered
07 Clean vs. Risky: The Full Picture
After running analysis across all these fields, pkgprobe produces a normalized risk score. Here's what the two ends of the spectrum look like:
| Field | Clean MSI | Risky MSI |
|---|---|---|
| Signature | Signed, valid chain | Unsigned or expired |
| Manufacturer | Matches certificate | Mismatch or spoofed |
| UpgradeCode | Stable across versions | Unexpected change |
| Custom actions | Minimal, deferred only | Encoded scripts, net calls |
| Network indicators | Expected vendor domains | Unknown IPs, foreign ASNs |
| CVE matches | None or LOW severity | HIGH or CRITICAL |
An MSI is not just a file. It's a declaration of intent. You should read it before you trust it.
Deployment teams move fast. Security teams move slower. Installer metadata is the bridge. If you can detect risk before SCCM or Intune pushes the payload, you eliminate emergency rollbacks, endpoint infections, audit failures, and change board escalations — before they start.
Analyze your next installer before it ships
Drop any MSI, EXE, or MSIX into pkgprobe and get a full risk report in seconds — signature state, CVE matches, network indicators, and more.