A Certified App That Wasn’t Clean
Routine certification testing caught what Hola’s own release process missed. During periodic integrity checks conducted under AppEsteem’s certification testing procedure — a program that Hola Browser had previously passed — security researchers from Sophos and other firms discovered an undeclared executable sitting inside a Windows installation of the browser. The file had no business being there, and what it was doing in the background was worse than a compliance failure.
The executable, named me.exe, was found in some installations under C:\Program Files\Hola\. It carried none of the standard markers of legitimate software: no digital signature, no timestamp, no certification, and its code was deliberately obfuscated. It could also write to memory. When Sophos dug deeper, the strings embedded in the binary pointed clearly to a Monero cryptocurrency miner — the kind designed to consume idle processing power without the user’s knowledge or consent.
What the Miner Actually Did
Once installed, the miner didn’t just sit quietly. It registered a Windows Defender exclusion rule to avoid detection by the default endpoint protection most Windows users rely on. It then copied itself into Program Files under a more innocuous-sounding name — HolaMonitorService.exe — and created an auto-starting Windows service named hola_monitor_svc. The service was configured to activate when the computer was idle, meaning it would begin consuming CPU resources precisely when a user was least likely to notice unusual activity.
This is a well-worn technique in cryptominer deployment. Running during idle periods reduces the chance of a user noticing slowdowns or fan noise, and naming the service something that resembles a legitimate system monitor further buries it among the dozens of background processes Windows runs at any given time. The Defender exclusion is the more aggressive element — actively carving out a blind spot in the very tool most users depend on.
The infection vector itself remains unclear. Hola confirmed to AppEsteem that the company had suffered a supply chain compromise, a finding that was independently corroborated by cybersecurity firm Sygnia. How the malicious binary entered the distribution pipeline, who introduced it, and whether other platforms beyond Windows were affected are questions that remain publicly unanswered. BleepingComputer reached out to Hola for those details and received no response before publication.
Hola’s History Makes This Harder to Dismiss
Hola is an Israeli company, and while it is best known for Hola VPN, it also develops Hola Browser — a Chromium-based browser with VPN and proxy features built directly into it. The VPN service works by routing traffic through other users’ devices or through paid proxy infrastructure, allowing people to bypass geographic content restrictions.
That model has drawn criticism before. Hola’s commercial operation, previously called Luminati Networks, effectively turned free users into proxy nodes — meaning their internet connections were being used to route other people’s traffic without most users fully understanding the arrangement. That background doesn’t prove any connection to the miner incident, but it does mean the company enters this situation with less goodwill than a first-time breach victim might otherwise carry.
The Response and What It Covers
Hola’s CEO, Avi Raz Cohen, confirmed the compromise and described the remediation steps the company has taken. According to Cohen: “We have since completely rebuilt our distribution pipeline, implemented advanced code-signing verification, and introduced tighter access controls and continuous monitoring across our infrastructure. These measures are designed to ensure that only declared, certified, and signed components are ever delivered to our users.”
The company also stated that approximately 0.1% of its users were affected. No evidence of user data access, theft, or broader system compromise was found beyond the miner itself.
That 0.1% figure deserves some context. Hola VPN claims tens of millions of users globally. Even at the lower end of plausible user counts, 0.1% translates to thousands of machines running unauthorized mining software — hardware that was consuming electricity and CPU cycles on behalf of whoever controlled the miner’s wallet address.
The rebuilt distribution pipeline and mandatory code-signing commitments are the right responses on paper. Code-signing verification is one of the most direct controls against this type of attack, since it creates a cryptographic checkpoint that unauthorized binaries cannot pass without access to the signing key. Whether those controls were absent before or simply bypassed is part of what the public statement doesn’t address. A supply chain compromise can mean many things — a compromised build server, a malicious insider, a hijacked dependency — and none of those possibilities carry the same implications for trust.
AppEsteem’s Role and What It Reveals
The fact that this was caught during AppEsteem certification testing rather than by Hola’s internal processes is the detail that should draw the most scrutiny. AppEsteem evaluates software for consumer safety, specifically looking for undisclosed behaviors, unauthorized installations, and deceptive practices. Hola Browser had passed this certification previously, which means either the miner was introduced after the last successful evaluation or it slipped through an earlier check.
The gap between “certified” and “safe at time of installation” is not an academic one.
Software certification programs operate on periodic snapshots. A binary that clears evaluation in January can be replaced by a compromised version in March, and users who installed the app between those two dates have no automated way to know that anything changed. This is the fundamental weakness that supply chain attacks exploit — the trust users extend to signed, certified software doesn’t automatically refresh when the underlying files change. That’s precisely why continuous monitoring and re-evaluation cycles exist, and precisely why the miner managed to reach real machines before anyone official caught it.
What Users Should Check
Anyone running the Windows version of Hola Browser should look for the presence of a service named hola_monitor_svc in the Windows Services panel (services.msc). The file HolaMonitorService.exe in C:\Program Files\Hola\ is the renamed miner binary. A Windows Defender exclusion pointing to Hola’s directory would also indicate a compromised installation.
Removing the service and the file is straightforward, but the more relevant step is verifying that Windows Defender exclusions don’t persist after removal. Exclusions created by malware don’t automatically disappear when the malware is deleted — they have to be cleared manually from Windows Security settings under Virus & Threat Protection > Manage Settings > Exclusions.
Hola has not published a specific installer version number or date range corresponding to the compromised builds. Without that information, users have no clear way to determine whether their installation falls within the affected 0.1% or outside it. The absence of that data is, on its own, worth noting.
