Fake Google Play Portals Deliver Corp MDM Spyware to Logistics Companies

Counterfeit app stores turn trusted logistics brands into lures

A malicious campaign is using counterfeit Google Play pages to distribute an Android surveillance tool known as Corp MDM, while also supporting credential theft and Windows malware delivery.

The operation, reported on September 24, 2026, impersonates logistics companies CEVA and TKW Logistics. Two identified distribution domains present themselves as Google Play-related services:

• playgoogle.logisticstkwcargo[.]com
• playgoogle.ceva-app[.]help

Rather than installing an application through the legitimate Google Play ecosystem, victims are directed to sideload an APK. Once installed, the app poses as a system service and uses the Android package name com.corp.mdm.

The specific social-engineering messages used to bring targets to these pages have not been disclosed. It is also unknown which Android versions are affected or whether the campaign relies on any software vulnerability. The attack instead depends on persuading a user to install an application from outside the official store and grant it sensitive permissions.

Although the visible lure is mobile-focused, the infrastructure connects Corp MDM to a wider operation. The same hard-coded IP address, 69.55.61[.]82, has been used for command-and-control communications, credential-phishing pages, and the delivery of additional Windows malware.

Permissions give the implant access to messages and calls

After sideloading, Corp MDM asks for permissions covering SMS messages, telephony functions, and notifications. Those permissions allow the implant to capture newly received text messages, manipulate call forwarding, and present notifications.

The malware does not retrieve SMS messages that were already stored on the device before access was granted. Its collection begins with messages received after the required permission becomes available.

For each captured SMS, Corp MDM can transmit:

• The sender
• The complete message body
• The time the message was received
• An identifier for the infected device

The information is sent to the operator over unencrypted HTTP. This creates a useful detection opportunity for defenders able to inspect outbound network traffic, particularly when requests match the known API routes.

The implant also removes its ordinary launcher entry, making it less visible in the device’s application menu. It then attempts to remain active as a background service.

Researcher Ben Folland warned that even this narrow form of SMS collection can expose valuable information. Newly arriving messages may contain one-time passcodes, password-reset links, account-recovery instructions, transaction notifications, and operational updates related to dispatches or deliveries.

That access can have consequences beyond the infected phone. A stolen authentication code could help an attacker enter corporate accounts, while intercepted delivery updates could reveal commercially sensitive shipment activity.

The command channel checks in every 30 seconds

Corp MDM begins its interaction with the command-and-control server by registering an Android identifier and sending basic device information. It then transmits heartbeat telemetry every 30 seconds.

The implant separately checks for operator instructions. The interval used for that command polling has not been disclosed.

Its known API routes are:

• /api/v1/devices/register — registers an infected device and supplies basic information.
• /api/v1/devices/heartbeat — sends recurring status telemetry.
• /api/v1/devices/{ANDROID_ID}/commands — requests commands assigned to a particular device.
• /api/v1/commands/result — returns the outcome of an attempted command.
• /api/v1/sms/report — uploads captured SMS data and the associated device identifier.

The infrastructure also exposes a password-protected administration panel on port 3456. Through that interface, operators can view and issue instructions to enrolled devices.

Because both the server address and application paths are known, defenders can search proxy, firewall, DNS, mobile-device-management, and network detection logs for related activity. The use of cleartext HTTP may also make the request paths and transmitted fields visible where traffic inspection is available.

The hard-coded nature of 69.55.61[.]82 is another weakness for the operator. Blocking that address could interrupt known samples, although it would not prevent the attacker from changing infrastructure or distributing a modified APK.

Call forwarding is the implant’s most consequential control feature

The malware supports a small set of remote commands rather than the broad surveillance capabilities associated with mature commercial spyware.

Its implemented commands include:

• ping — returns “pong,” allowing the operator to verify that the implant is responsive.
• forward_on — enables unconditional call forwarding to a telephone number chosen by the operator.
• forward_off — attempts to cancel forwarding by using ##21#.
• sync_sms — reports that synchronization has started but does not actually collect stored messages.
• self_destroy — disables implant components, stops its service, and requests the clearing of application data.

The administration panel additionally presents get_location and lock_device options. However, the Android implant does not implement either capability. An operator can select them in the panel, but the infected device cannot carry them out.

These inconsistencies, along with other bugs affecting functionality, led researchers to suspect that artificial intelligence may have been used during development. That assessment does not identify a particular model or prove that the complete malware was generated by AI.

Despite its limitations, call-forwarding control raises a distinct risk. Redirected calls could expose voice-based verification processes or prevent employees from receiving legitimate operational communications. The command also creates a device-level indicator that security and telecommunications teams can investigate.

Attribution remains uncertain amid wider logistics targeting

The actor operating Corp MDM has not been identified. Have I Been Squatted assessed that the campaign may have an Armenian or Russian connection, based on localized material found in the administration interface and source code associated with the broader activity.

That evidence indicates a possible regional link, not confirmed attribution.

The campaign also sits within a wider pattern of criminal activity directed at transportation and freight businesses. In November 2025, Proofpoint described attacks in which trucking and logistics organizations were infected with remote monitoring and management software. The apparent objectives included financial theft and cargo theft.

Ctrl-Alt-Intel and Have I Been Squatted have separately tracked a cluster called Diesel Vortex, which targeted freight and logistics entities in the United States and Europe. Reported targets included DAT Truckstop, TIMOCOM, Teleroute, Penske Logistics, Girteka, and Electronic Funds Source (EFS).

Another logistics-oriented phishing service, Global Profit, also called MC Profit Always, has been attributed to a Russian-Armenian threat actor. It reportedly captured more than 1,600 unique credentials between September 2025 and February 2026.

Global Profit operators impersonated platforms used by logistics personnel and intercepted passwords and multi-factor authentication codes in real time. Reported tactics also included spear-phishing and voice phishing aimed at trucking and logistics groups on Telegram. Compromised access was then used to obtain shipment information, redirect invoices, facilitate double-brokering, access personal information, and steal money.

No evidence provided so far establishes that Corp MDM, Diesel Vortex, and Global Profit are operated by the same actor.

What defenders should investigate now

There is no confirmed vendor remediation or dedicated removal procedure for Corp MDM. No affected Android version range has been disclosed, and the campaign is not described as exploiting a CVE.

Organizations can nevertheless take several immediate defensive steps:

1. Block or investigate the known infrastructure. Search for connections to 69.55.61[.]82 and the two counterfeit Play domains.
2. Restrict Android sideloading. Managed devices should install software only from approved stores or enterprise deployment systems.
3. Hunt for the package. Review enrolled devices for com.corp.mdm, including applications that lack a visible launcher icon.
4. Audit sensitive permissions. Unexpected access to SMS, telephony, and notifications should be investigated.
5. Check call-forwarding settings. Look for unexplained unconditional forwarding or recent changes that users did not authorize.
6. Monitor HTTP requests. Search for traffic containing the known /api/v1/ registration, heartbeat, command, and SMS-reporting paths.
7. Extend the investigation beyond Android. Affected environments should also look for logistics-themed credential phishing and unauthorized Windows malware delivery.

Users who installed an APK from either counterfeit page should disconnect the device from sensitive corporate services and report it to their security team. Because stolen SMS messages may include authentication and recovery data, the response should include reviewing account sessions, resetting exposed credentials, and checking whether multi-factor authentication methods need to be replaced.