Trapdoor uses a two-stage distribution mechanism: organic app installs don’t trigger fraud, but instead trigger a malvertising campaign intended to coerce a user to download a second related app. This two-stage system helps the threat actors avoid detection by limiting invalid activity to installs that are less likely to be monitored by security researchers.

Many of the apps associated with the threat claim to perform a common utility, such as PDF readers, file managers, or cleanup apps. These attract a broad user base and don’t raise immediate suspicion.

Once an organically downloaded app is installed, users begin seeing ads claiming the current version of the app is outdated or unsupported. The ads are designed to suggest that clicking on a button in the ad will update the app, but instead install a second threat actor-owned app.

This sequence—initial organic install to malvertising campaign to secondary malicious install—suggests an ecosystem designed for users to inadvertently self-select into fraud. The fake update creative in the malvertising campaign creates urgency and exploits user trust in app update mechanisms, making users more likely to comply.

One of Trapdoor’s most notable techniques is its abuse of a mobile marketing attribution platform to determine whether an app was installed organically (i.e., a user visiting the Play Store directly) or non-organically (i.e., the user arrived via a paid ad campaign run by the threat actors).

Trapdoor-associated apps integrate attribution calls and inspect tracker_name values, treating installs whose tracker does not contain organic as ad-driven, which allows the threat actors to reserve malicious workflows for installs derived from their own malvertising campaigns.

This is a potent evasion technique. A security researcher who downloads the app directly from the Play Store or sideloads it for dynamic analysis will see only benign behavior. The malicious payload activates exclusively for users who arrived through the threat actors’ own advertising campaigns. Satori researchers observed a similar misuse of attribution technology in the SlopAds operation, and its reappearance in Trapdoor underscores that threat actors have identified attribution tools as a reliable method of separating real targets from researchers who might blow the whistle.

Once a Trapdoor-associated app determines it was installed non-organically and should proceed with its malicious workflow, the threat revolves around decrypting files bundled within the app’s assets.

The initial decrypted file strings contain critical values: the C2 domain, filenames of files containing clicking coordinates, and dynamic loading payload references.

Among the decrypted assets is an encrypted ZIP archive containing two files: move.txt and click.txt. These files contain instructions and locations for taps, swipes, and more complex gestures. The data is deserialized into model classes such as TouchConfig and TouchData and executed through Android’s dispatchTouchEvent, allowing the app to simulate realistic human touch interactions on the device.

Satori researchers simulated the gesture coordinates recovered from move.txt, revealing the structured nature of the automation. The coordinate plot below shows the pre-programmed movement paths, which form deliberate, repeatable patterns: these are not random taps, but carefully choreographed gestures designed to interact with specific ad placements.

The automated clicks described above occur within a fullscreen WebView launched by the secondary Trapdoor-associated app, which loads HTML5 domains served by the C2 infrastructure. The C2 request contains click-related configuration including delays and banner identifiers, ensuring that the clicks map to specific ad banners on the HTML5 pages.

The WebView is also configured to keep it hidden from users while it accesses HTML5 domains and requests/clicks on ads:

As noted above, the use of H5 cashout domains as the monetization layer connects Trapdoor to a broader pattern observed by Satori researchers, as several previously-reported operations used H5 game and news domains as cashout mechanisms. This convergence of cashout infrastructure across multiple distinct operations reinforces the need for ongoing monitoring of HTML5 domain networks as a common monetization tactic in modern ad fraud.

Beyond the abuse of the attribution technology, Trapdoor-associated apps employ several anti-analysis and obfuscation techniques designed to resist both static and dynamic examination.

Anti-analysis signals. A separate C2 request and response to /api/referrer includes anti-analysis signals, including riskPaths for rooted-device and debugging indicators, and checks for VPN usage. The VPN check is particularly notable: analysts frequently rely on VPNs and local interception tooling during mobile reverse engineering, meaning this check is specifically calibrated to detect researcher environments.

Native packing and code virtualization. Most samples analyzed by Satori researchers use a native packer combined with code virtualization and string encryption. These techniques make static analysis significantly more difficult and slow down reverse engineering efforts.

SDK impersonation. Some Trapdoor variants attempt to blend into the Android ecosystem by impersonating legitimate SDKs. Researchers observed code structures mimicking a commonly-used advertising SDK, which may help malicious logic pass initial inspection.

Taken together, these evasion tactics reflect a threat actor that has invested considerable effort in making Trapdoor difficult to detect and analyze through conventional means.