ManualFinder shows how decoy apps turn Windows hosts into proxy nodes

At a glance

What this is: ManualFinder is a Trojan disguised as a legitimate utility, and Expel links it to a wider decoy-app chain that installs hidden JavaScript and residential proxy software.

Why it matters: It matters to IAM and security teams because covertly installed software behaves like an unmanaged identity and execution path on the endpoint, creating persistence, trust, and egress risks that traditional allowlists often miss.

👉 Read Expel's analysis of the ManualFinder decoy-app malware campaign

Context

ManualFinder sits in the overlap between endpoint compromise, software supply abuse, and covert proxy infrastructure. The key governance gap is simple: users and defenders often assume a signed utility with a plausible function is low risk, but decoy apps can still execute hidden code, create persistence, and alter how a host is used on the network.

The primary identity intersection is not human IAM, but the control of execution-bearing software and the credentials or trust relationships it can inherit on a Windows host. Where a decoy app can schedule scripts, call MSHTA, and install proxyware, it effectively gains a durable runtime presence that should be treated as lifecycle-managed software rather than a benign application. That pattern is increasingly typical across decoy-app campaigns, not an isolated oddity.

Key questions

Q: What breaks when a decoy app is allowed to run as trusted software?

A: The trust boundary breaks down because the app can execute hidden scripts, create persistence, and repurpose the endpoint for proxy traffic while still looking legitimate. Defenders lose the ability to distinguish normal utility behaviour from covert runtime abuse, which means software identity and execution control must be validated together.

Q: Why do signed utilities still create risk for endpoint and identity governance?

A: A signature proves that some publisher signed the file, not that the software has a trustworthy lifecycle, clean distribution path, or aligned legal identity. When the surrounding provenance is inconsistent, defenders should treat the executable as untrusted and require stronger lifecycle checks before granting execution trust.

Q: How do security teams know if hidden script persistence is actually contained?

A: Look for the absence of repeated task-driven launches, temporary JavaScript execution, and unexpected outbound connections from the affected host. If the scheduled task still exists or related DNS activity continues, containment is incomplete and the campaign may still have active footholds.

Q: Who is accountable when proxyware or decoy software reaches managed devices?

A: Accountability usually spans endpoint management, software approval, and security operations because the failure is not only technical. The organisation needs ownership for application trust decisions, alert handling, and removal workflows, otherwise decoy software will keep returning through the same weak control point.

Technical breakdown

How decoy apps use scheduled tasks and MSHTA for persistence

ManualFinder shows a common Windows abuse pattern: a scheduled task launches a script, which in turn invokes MSHTA, the Microsoft HTML Application Host. MSHTA can execute embedded script content, so it becomes a convenient bridge between a benign-looking application and hidden code execution. In this case, the task launches node.exe and a temporary JavaScript file, then closes the window so the activity remains invisible. The important detail is not just execution, but persistence through standard system components that look routine in telemetry. That makes the chain harder to distinguish from normal admin automation unless investigators inspect parent-child process relationships and task history.

Practical implication: Hunt for scheduled tasks that launch node.exe, wscript, or MSHTA from %TEMP% and treat that pattern as suspicious persistence.

Why code-signing and website legitimacy can still mislead defenders

The campaign uses code-signing certificates and polished websites to create the appearance of legitimacy, but the surrounding signals do not match a normal software vendor. When metadata, certificate issuer, registration details, and download paths do not align, defenders should treat the binary as untrusted even if it is signed. The deeper issue is trust leakage through software identity. Users often equate a signed executable with a known publisher, yet certificate validity only proves that a signer existed, not that the software behaves as expected or that the signer represents a real product lifecycle. That gap is where decoy apps thrive.

Practical implication: Validate signing metadata, publisher footprint, and download provenance together before allowing software onto managed endpoints.

How residential proxyware changes the risk profile of a supposedly free app

Residential proxy software turns an infected endpoint into a relayed network node, which changes the threat from local nuisance to infrastructure abuse. Even when the user thinks they are installing a utility, the app can redirect outbound traffic, monetize the host, or hide attacker traffic behind a consumer IP address. That introduces privacy exposure, lateral trust abuse, and compliance concerns because the endpoint is now participating in external traffic flows that the user did not intend. In operational terms, the host is no longer just compromised. It is being repurposed as a transit layer for someone else's network activity.

Practical implication: Review proxy installation events, unusual outbound destinations, and consent prompts as signs of endpoint repurposing, not just adware.

Threat narrative

Attacker objective: The objective is to turn victim endpoints into covert, monetisable infrastructure while preserving a believable software facade.

1. Entry occurs through advertising and download links that deliver a seemingly useful utility, such as a PDF tool or manual-search app, onto the host.
2. Escalation happens when the installed program uses scheduled tasks, node.exe, and MSHTA to execute hidden JavaScript outside the user's view.
3. Impact follows when the host is repurposed for residential proxy traffic and linked to a broader decoy-app network that can persist across multiple installations.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Cisco Active Directory credentials breach — Kraken ransomware group leaked Cisco Active Directory credentials.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Decoy-app campaigns now behave like software supply chain threats, not classic nuisanceware. The ManualFinder case shows a pattern where a plausible utility is only the front end for hidden script execution, proxy installation, and persistence. That means defenders should stop treating these as merely unwanted applications and start treating them as lifecycle-managed software abuse. The practical conclusion is that allowlisting, provenance checks, and telemetry review must cover the full delivery chain, not just the visible binary.

Signed binaries are not a sufficient trust boundary when the surrounding identity of the software is incoherent. A valid code-signing certificate, a branded website, and a download page can still conceal a decoy operator if the publisher footprint, legal entity, and distribution logic do not align. This is a software identity problem, and it intersects with IAM because trust is being assigned to a runtime artifact without strong lifecycle governance. Teams should require provenance validation before any executable earns operational trust.

Hidden JavaScript persistence is a named control gap: endpoint execution without reviewable lifecycle ownership. When a scheduled task can repeatedly launch a script for more than a month, the organisation has lost visibility into what code is running, when, and under which trust conditions. That gap mirrors the governance problems seen in unmanaged service accounts and long-lived machine credentials. The practitioner lesson is to govern execution paths as identities with owners, expiry, and revocation paths.

Residential proxyware turns endpoint compromise into network impersonation. Once a host can relay traffic for an outside party, the organisation inherits abuse risk that looks like legitimate consumer connectivity from the outside. That complicates detection, incident scoping, and acceptable-use policy enforcement. For practitioners, the implication is clear: network reputation alone is not a reliable control when software can repurpose endpoints as proxy nodes.

Decoy-app ecosystems scale through infrastructure reuse, which makes single-sample response insufficient. The shared certificates, domain patterns, and related app families show that one binary rarely tells the full story. Teams need to look for the campaign, not just the file. For practitioners, the right control posture is cross-telemetry correlation across EDR, DNS, certificate intelligence, and scheduled task data.

From our research:

• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to Ultimate Guide to NHIs , Key Research and Survey Results.
• From our research: Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs , Key Research and Survey Results.
• Forward look: The Ultimate Guide to NHIs is the right next read for teams mapping lifecycle gaps across secrets, service accounts, and revocation.

What this signals

Hidden script execution, certificate inconsistency, and residential proxy installation are all signs that endpoint trust is now a software lifecycle issue as much as a malware issue. For teams running identity-heavy environments, the lesson is to treat every executable that can schedule work, call out to the network, or install background components as a governed runtime asset, not a one-time download.

Software identity drift: when a branded application, its signer, and its distribution footprint do not line up, the control failure is usually trust assignment, not detection. This is where endpoint telemetry, certificate intelligence, and software approval policy need to converge, especially for tools that can create persistent background tasks or consume external network routes.

The practical signal for security programmes is that hidden automation behaves like unmanaged machine identity. Once the host can act on behalf of an external operator through proxy traffic or scheduled execution, access review logic that only tracks human users will miss the real control boundary.

For practitioners

• Hunt for persistence via scheduled tasks Query EDR and SIEM data for scheduled tasks that launch node.exe, wscript, or MSHTA from %TEMP% and quarantine the associated scripts and child processes immediately.
• Validate software provenance before trust is granted Check whether the binary signer, product name, download source, and legal entity all point to the same real publisher before allowing installation on managed endpoints.
• Block campaign infrastructure at the network edge Add known delivery and callback domains to DNS and web controls, then monitor for any residual connections to mka3e8.com, y2iax5.com, and 5b7crp.com style destinations.
• Remove proxyware and related decoy apps at source Search for the broader family of utility apps associated with the campaign, including PDF Editor, AppSuite-PDF, and OneStart, then remove them from all managed hosts.

Key takeaways

• ManualFinder is best understood as a decoy-app campaign that combines hidden execution, persistence, and proxy abuse rather than a simple nuisance program.
• The evidence points to a wider software identity problem, where signatures and branded websites do not guarantee trustworthy behaviour or trustworthy provenance.
• Security teams should hunt for scheduled JavaScript execution, validate publisher identity before trust, and remove the broader app family rather than a single sample.

Key terms

• Decoy App: A decoy app is software that presents a legitimate or useful face while hiding unwanted or malicious behaviour. In practice, it may install additional components, run scripts, or alter network behaviour after installation, making trust decisions based only on appearance unreliable.
• Residential Proxy: A residential proxy routes traffic through an address assigned to a real consumer device or household connection. That makes the traffic look more legitimate than datacentre-based proxies, which is why abuse actors use it to bypass reputation checks and blend into normal user traffic.
• Scheduled-Task Persistence: A condition where an AI agent creates or modifies recurring automation that continues after the original interaction. It matters because a one-time injection can become durable influence, making later actions look legitimate even though the underlying instruction was attacker-shaped.
• Software provenance: Software provenance is the evidence that shows where an artifact came from, who created it, and whether it was altered before use. For security teams, it means signed releases, controlled build paths, and verification steps that reduce the chance of trusted software carrying hidden malicious changes.

What's in the full analysis

Expel's full analysis covers the operational detail this post intentionally leaves for the source:

• EDR and SIEM hunting logic for tracing scheduled-task launches, node.exe execution, and MSHTA-backed persistence across an estate.
• IOC detail for hashes, callback domains, and related decoy-app families that can support your detection rules and containment workflow.
• Campaign-level evidence tying certificate signers, fake publisher footprints, and distribution infrastructure together across multiple samples.
• Removal guidance for the broader app family, not just the ManualFinder sample, so teams can scope cleanup consistently.

👉 Expel's full post covers the persistence chain, proxyware behaviour, and indicator list in more operational detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It gives identity and security practitioners a structured way to connect lifecycle control to broader access governance.