Deliver Malicious Application via Other Means

What this technique means in practice

This technique describes an installation path that bypasses the normal app store or approved download flow. The security issue is not just the payload itself, but the fact that the delivery path weakens device trust, review, and user expectations.

It often succeeds because the user is persuaded to install something that appears legitimate, or because the device accepts software from a source the organisation does not normally supervise. That makes the technique relevant to both unmanaged consumer devices and enterprise fleets with weak installation controls.

Why this delivery path is dangerous

By stepping outside normal distribution channels, malicious apps can evade the controls that users and defenders often rely on, such as store vetting, reputation signals, and central visibility. The technique is especially effective when the attacker combines social engineering with a convincing lure, such as a fake update, a helpful utility, or a file received through messaging or email.

Once installed, the app can request excessive permissions, hide its icon, abuse accessibility features, or persist across reboots. On mobile platforms, the delivery method can also be paired with overlays, credential theft, and device-admin abuse, which makes the initial installation only the first stage of compromise. NHI Management Group’s Mobile Malware Guide covers how these mobile infection chains often combine sideloading with post-install abuse.

How defenders reduce exposure

Exposure review starts with knowing which devices allow installation from outside approved channels, which enrolment states are trusted, and which management paths can push software to endpoints. In practice, defenders should treat installation source control as part of device hardening, not as a one-time policy checkbox.

Controls that matter most are the ones that narrow the accepted software paths, tighten mobile device management enrolment, and make unsupported installation channels visible for audit and response. The relevant control problem is broader than one operating system or one malware family: any channel that can deliver code outside policy deserves review, especially where users can approve installation without strong verification. For broader control baselines, NIST SP 800-53 Rev 5 Security and Privacy Controls provides a catalogue for access control, configuration management, and monitoring expectations.

Detection and post-compromise response

Detection should look for signs that software was installed through an unexpected path, especially when the source, package name, certificate, or enrolment history does not match normal patterns. On mobile estates, a suspicious install may be visible only after the app requests unusual permissions, contacts unfamiliar infrastructure, or begins suppressing its own presence.

After a malicious install is confirmed, responders should assume the device may have exposed credentials, tokens, messages, or session material, depending on the app’s access and permissions. Where malware persists after removal, defenders need to review whether the device was rooted, whether the management profile was altered, and whether the installation source can be abused again. Technique mapping for this kind of adversary activity is well covered in MITRE ATT&CK Enterprise Matrix.

Risk and Threat Considerations

Bypassing normal software distribution increases the chance that a malicious app will reach a device without the scrutiny that stores, managed catalogs, or enterprise allow-lists would normally provide. The main risk is not only infection, but also the loss of trust in the device as an endpoint for business data, authentication, and sensitive communications.

Failure mechanism: The attacker uses a non-standard delivery path, often paired with deception or a compromised management route, to place code on the device and then leverages permissions, persistence, or stealth to keep control.

Impact: The result can include data theft, credential capture, surveillance, service disruption, and a widened attack surface for lateral movement or re-entry.

Practitioner Guidance

Why practitioners should care: The critical decision is not just whether an app is malicious, but whether the organisation can reliably prevent unsanctioned installation paths from being used at all. If device policy still allows ad hoc installs, defenders are relying on user judgement where policy enforcement should exist.

What to watch for: Treat repeated sideload prompts, unexpected enrolment changes, and installs that originate from messaging, removable media, or unofficial portals as warning signs that the device is being steered outside normal trust boundaries.

Practitioner takeaway: Reduce the number of software entry points first, then monitor the remaining ones closely, because the easiest malicious app to detect is the one that never gets installed.

Related resources from NHI Mgmt Group

• Dynamic Application Security Testing
• Interactive Application Security Testing
• Runtime Application Self-Protection
• Who is accountable when a malicious OAuth application is approved by a user?