Verify Installer Hash Before Intune Win32 Packaging

I found nothing on Microsoft Learn saying Intune checks where an installer came from. You give it a file, it deploys that file to the devices you assign. If the file is wrong, the deployment is a fast way to put it on all of them.

That’s what a recent incident write-up describes. dfir.ch’s Field Notes: EtherRAT Distributed Through a Legitimate Intune Workflow (14 Oct 2026) says a customer “had imported what appeared to be a legitimate Advanced IP Scanner installer into its existing software distribution workflow, inadvertently deploying the malware to multiple systems.” The author reports the malware on four managed endpoints, delivered through the Windows MDM application deployment mechanism over roughly a month, and says “the deployment itself was not the result of an identified compromise of Intune.”

I’m relying on that one write-up for the case. I couldn’t open the X post that pointed me to it, and I haven’t independently confirmed the incident. Treat the details as dfir.ch’s account. The rest of this article is the check you run before packaging, which holds up whether or not you trust the story.

What the write-up says happened

Per dfir.ch, and only as far as the author could establish:

• The first alert was a Microsoft Defender for Endpoint detection of suspicious screen capture involving PowerShell.
• Browser history on the earliest affected endpoint showed a Bing search for “advanced ip scanner msi”, then visits to a GitHub repository impersonating the vendor, five days before the first known malicious Intune installation. The repository was gone by the time of the investigation.
• The author states they “could not conclusively determine whether the original download matched the package subsequently deployed through Intune.” The link between the download and the package is a plausible sequence, not proven.
• The MSI appeared in the Intune app inventory as Advanced IP Scanner, with ProductCode {6FB2BB4F-67D5-4B13-8829-001C1E5E05DF} and version 7.5.12.0, while the installed copy on endpoints showed a randomized display name and publisher.
• The author found a second impersonating repository offering Advanced_IP_Scanner_2.5.4594.1.msi and gives its SHA-256 as 48ce8681167128a8cd84b6befd98b94d97c00a4f4868a3dbdfc01c44d887e49f.

The malware family attribution (EtherRAT) in that post is described as “consistent with” earlier public reports, not proven. I’m not going to go further on the malware here. This article is about the step the admin controls.

A separate 2024 report from Trustwave SpiderLabs on a fake Advanced IP Scanner installer is a different campaign, but it matters for one reason: that report says the malicious installer “is digitally signed using a stolen certificate.” A signature on its own didn’t make the file safe there.

Quick checklist before you package

1. Get the installer only from the vendor’s own site, typed or bookmarked, not from a search result or a repository that claims to be the vendor.
2. Ask whether the vendor really ships the format you want. A search for an MSI of a tool that only ships an EXE should make you stop.
3. Compute the SHA256 hash with Get-FileHash.
4. Compare it with a hash the vendor publishes on its own site. If the vendor publishes none, record your hash and treat that as a gap.
5. Read the signature with Get-AuthenticodeSignature and check the signer name, not only the status.
6. Record the source URL, hash and signer in the app’s notes in Intune.
7. Package and test on one device before you assign widely.

Get the hash

Get-FileHash computes a hash for a file. Per Learn, it uses SHA256 by default, and -Algorithm accepts SHA1, SHA256, SHA384, SHA512 and MD5. Learn adds that MD5 and SHA1 “are no longer considered secure” and should only be used for simple change validation, so use SHA256 or better when you compare against a vendor value.

# Not executed for this article. Replace the path with your downloaded installer.
Get-FileHash -Path .\Installer.msi -Algorithm SHA256 | Format-List

The output includes Algorithm, Hash and Path. Learn’s example compares a computed hash with the hash a vendor publishes on its release page. The same idea for a local file:

$expected = '<hash the vendor published>'
(Get-FileHash -Path .\Installer.msi -Algorithm SHA256).Hash -eq $expected

$expected is a placeholder. -eq on strings is case-insensitive in PowerShell, which suits hex hashes.

A match only proves the file equals what the vendor page says. It proves nothing if you got the hash from the same untrusted place as the file, which is why the hash has to come from the vendor’s own site, and ideally a different page or channel from the download.

Read the signature

Get-AuthenticodeSignature returns information about a file’s Authenticode signature. It’s Windows only. Learn says that if the file isn’t signed, “the information is retrieved, but the fields are blank.”

# Not executed for this article.
$sig = Get-AuthenticodeSignature -FilePath .\Installer.msi
$sig.Status
$sig.SignerCertificate.Subject

Learn lists these Status values in the SignatureStatus enumeration:

Status	Meaning per Learn
Valid	”The file has a valid signature. This means only that the signature is syntactically valid. It does not imply trust in any way.”
NotSigned	The file has no signature.
HashMismatch	The hash of the file doesn’t match the hash stored with the signature.
NotTrusted	The certificate was signed by a publisher not trusted on the system.
UnknownError	The file has an invalid signature.
NotSupportedFileFormat	The system doesn’t support signing operations for this file type.
Incompatible	The signature can’t be verified because it’s incompatible with the current system.

Read that Valid row twice. It’s the reason the signer matters. Check that SignerCertificate.Subject names the publisher you expect, and compare it with a known-good copy of the same vendor’s installer from a previous version if you have one. A stolen-certificate case like the 2024 report would still pass a bare “is it signed” test. What would catch it is a signer or version that doesn’t fit the vendor, or a hash that doesn’t match the vendor’s published value.

I haven’t confirmed from Learn which installer file types Get-AuthenticodeSignature supports beyond the script examples it shows. NotSupportedFileFormat exists for that case. If you get it on an installer, verify the signature in File Properties > Digital Signatures instead, and say so in your notes.

Check the hash against what you already know is bad

If your security team shares indicators, you can check a file against a known-bad SHA-256 in one line. This uses the value dfir.ch gave for the impersonating repository’s MSI:

# Not executed for this article.
(Get-FileHash -Path .\Installer.msi -Algorithm SHA256).Hash -eq '48ce8681167128a8cd84b6befd98b94d97c00a4f4868a3dbdfc01c44d887e49f'

A False doesn’t clear the file. Attackers can change the file freely, and the write-up notes that on one endpoint a copied runtime had a different hash from the others, so hunting only on a hash would have missed part of the infection. Known-bad hashes are a quick tripwire, not a verdict.

After the file passes

Package as usual with the Win32 app workflow, keep the original download next to the .intunewin file, and store the hash and source in the app description or your packaging repo. If an install script is part of the package, remember it runs 32-bit unless you call Sysnative; see Win32 install scripts running as 32-bit PowerShell.

If you suspect a package already in your tenant, dfir.ch used the app inventory to connect endpoints to the Intune app: it queried Microsoft Graph for MSI apps and matched ProductCode and version against what the endpoints had installed. Their snippet used Connect-MgGraph -Scopes "DeviceManagementApps.Read.All" and Get-MgDeviceAppManagementMobileApp. I haven’t run it, so test it on a non-production tenant first. For reading what the Intune Management Extension did on a device, see reading AppWorkload.log and IME logs.

What not to rely on

• A search result or a GitHub repository that says it’s the vendor. The case above started with one.
• “It’s signed.” Learn says Valid implies no trust.
• Antivirus alone. The Defender alert in the write-up came from behavior after install, not before the package was assigned.
• A hash copied from the same page that hosts the file, when that page isn’t the vendor’s.

Prevention

Make source, hash and signer part of your packaging checklist, and add a second person for any app that comes from outside your usual vendors. Keep a short list of approved download locations. If your process lets anyone with the right role import and assign, decide whether it should.

Get the Deployment Doctor

Kit 1 founding presale is open: $39 (regular $49). The Autopilot + Device Prep Deployment Doctor checks your tenant, read-only, for the config that breaks ESP and Device Preparation. You pay now and get the files by Tuesday, December 1, 2026, sooner if they’re ready. Full refund any time before delivery, then 14 days after delivery. The founding price runs until Friday, December 4, 11:59 PM MT.

Want to look first? The free, read-only beta scripts are on GitHub: autopilot-deployment-doctor-beta. Its README says they haven’t been run against a live tenant.

FAQ

Does Intune verify an installer before deploying it?

I found nothing on Microsoft Learn saying it does, and the dfir.ch write-up describes an imported MSI being deployed as normal. Verify the file yourself before you package it.

Is a valid Authenticode signature enough?

No. Learn says Valid “does not imply trust in any way.” Check the signer name too, and compare the hash with the vendor’s published value.

What hash algorithm should I use?

SHA256, which is the Get-FileHash default. Learn says MD5 and SHA1 are no longer considered secure.

Sources

All retrieved 2026-10-27.

• Field Notes: EtherRAT Distributed Through a Legitimate Intune Workflow, dfir.ch, 14 Oct 2026: the incident account, ProductCode, second repository and SHA-256, Graph snippet. Third-party write-up, not independently verified.
• Fake Advanced IP Scanner Installer Delivers Dangerous CobaltStrike Backdoor, Trustwave SpiderLabs (LevelBlue), June 5, 2024: stolen-certificate signature.
• Get-FileHash, Microsoft Learn: default algorithm, accepted values, MD5 and SHA1 caveat, published-hash comparison.
• Get-AuthenticodeSignature, Microsoft Learn: Windows only, unsigned files return blank fields.
• SignatureStatus enumeration, Microsoft Learn: status values and meanings.