Search malvertising is back: signed installers + cloned brands are delivering loaders at scale

What we're seeing

Malvertising/SEO-poisoning campaigns are impersonating popular software (VPNs, IDEs, archivers, wallets). The flow is consistent: paid search ad → look-alike domain → signed MSI/EXE that side-loads a loader, then runs the legitimate installer to avoid suspicion. Some families now carry valid or recently revoked EV certs, bypassing naive “unsigned binary” controls.

Why this works

• Users trust “Ad” results for brand names and stop checking the domain.
• Newly signed binaries can have weak SmartScreen reputation for hours–days.
• Installers run with elevated privileges and broad AV exclusions (“allow app to make changes”).

Forensics & hunting cues

• Process tree: browser → downloaded MSI/EXE → temp child (DLL sideload) → legitimate installer.
• Filesystem: unusual DLLs near vendor EXEs (dxva2.dll, version.dll, winhttp.dll) in user writeable paths.
• Network: short-lived domains that visually mimic vendor (homoglyphs); burst of HTTP 301/302 between ad landing and payload CDN.
• Cert telemetry: recently issued code-signing certs; mismatched publisher vs product name.

EDR/KQL starter queries

DeviceFileEvents
| where FolderPath has_any ("\\AppData\\Local\\Temp\\", "\\Downloads\\")
| where FileName endswith ".dll"
| where InitiatingProcessFileName has_any ("*.msi","*.exe")
| where InitiatingProcessCommandLine has_any ("quiet","qn","norestart")

DeviceNetworkEvents
| where RemoteUrl has_any (".zip",".msi",".exe")
| where InitiatingProcessFileName in~ ("msiexec.exe","setup.exe","installer.exe")
| project Timestamp, InitiatingProcessFileName, RemoteUrl, RemoteIP

Controls that move the needle

1. Block ad click-through for high-risk keywords: via Secure Web Gateway/DNS policy; allow-list official domains only.
2. Browser hardening: show full URLs, block look-alike TLDs; deploy enterprise bookmarks for common software to avoid search.
3. Application control: WDAC/SAC “block unsigned AND low reputation installers”; restrict MSI to signed + reputation-established publishers.
4. ASR rules: Block executable content from email/web clients; block Win32 API calls from Office (if applicable).
5. Procurement habit: require software installs from a private package repository or vendor allow-listed links only.

Incident response (quick)

1. Quarantine the originating endpoint; capture the browser download history and %TEMP% artifacts.
2. Extract installer certificate chain; check revocation status; pivot in EDR for the same thumbprint.
3. Hunt DLL sideload locations; block hashes/paths tenant-wide; reset tokens/sessions for impacted users.
4. Report malicious ads/landing pages to the ad platform & registrar; add to blocklists.

Bottom line: Treat installer reputation and domain authenticity as first-class controls. Users will keep searching for “download <brand>” — make that path safe by policy, not training alone.