An undeclared executable bundled with Hola Browser for Windows (version 1.251.91.0) that later proved to be a crypto‑miner.
The binary, written to C:Program FilesHolame.exe in affected installs, was not part of the certified footprint, lacked code signing and a timestamp, contained obfuscated code and memory‑write capabilities.
Analysis identified miner‑related strings, XMRig indicators, and behavior to establish persistence: when run with elevated privileges it copies itself to C:Program FilesHolaHolaMonitorService.exe, installs a hola_monitor_svc service configured to autostart and run during idle, and attempts to exclude itself from Windows Defender scan. Sophos classifies the sample as Troj/GoMiner‑B.
Matched telemetry seen by Sophos under SHA256 e3541caf708c075f0bb22fc68b03acd8457fea7cf0732ea935b1eb016d1c7721.
AppEsteem had previously certified Hola Browser with specific hashes (SHA256: 17408653…7bdb, SHA1: 8046735d…61f2, MD5: 8462f61e…), indicating the tested snapshot contained only known and vetted components.
According to Sophos, the discovery originated from routine certification testing by AppEsteem, an AMTSO‑certified organization that validates that vendor‑declared binaries match what is actually distributed.
The presence of me.exe in some test runs but not others ruled out a static installer payload and instead pointed to delivery‑path variance a classic supply‑chain integrity issue where build channels, CDN behavior, post‑install fetches, or release pipeline misconfiguration can cause divergent outputs for ostensibly identical releases.
Hola Browser Windows Delivery Pipeline
Hola confirmed, after being alerted, that me.exe was not intended to be delivered by their installer.
The company said their internal monitoring had flagged anomalous activity in the update distribution pipeline; they halted the affected path, removed the unwanted component, engaged Sygnia for a forensic investigation, and rebuilt their delivery pipeline with stronger code‑signing checks, tighter access controls, and continuous monitoring.
Hola stated the incident affected approximately 0.1% of users and that no user data was accessed or exfiltrated.
From a technical standpoint the incident underscores several systemic risks. First, unsigned, untimestamped, obfuscated executables with memory‑write and persistence behaviors are high‑risk artifacts even if individually they might not prove intent.
Second, inconsistent delivery across test runs highlights the need for end‑to‑end reproducible builds, artifact immutability (immutable storage and artifact registries), and cryptographically enforced provenance from build to CDN to client.
Third, continuous third‑party validation such as AppEsteem certification combined with telemetry from independent vendors like Sophos provides crucial detection coverage for delivery pipeline deviations that vendor testing can miss.
Operational mitigations for vendors include enforcing strict code‑signing policies with hardware‑backed keys, signing and timestamping every release artifact, implementing reproducible builds and manifest‑based installers, restricting pipeline access with strong identity and permission controls, and deploying runtime integrity checks in updaters.
For defenders and enterprises, detecting miner activity requires monitoring for new services, unusual CPU usage spikes during idle periods, unsigned executables in program directories, and attempts to create Defender exclusions; behavioral detections should complement signature checks.
This case demonstrates how certification and multi‑vendor telemetry can surface supply‑chain compromises before widespread impact.
Hola’s remediation and rebuild of its pipeline closed the immediate problem, but the event is a technical reminder: maintaining distribution integrity demands cryptographic provenance, strict pipeline hygiene, and continuous independent validation.
Follow us on Google News, LinkedIn, and X to Get Instant Updates and Set GBH as a Preferred Source in Google.
