Of seven controls in this spyware's console, one does exactly what its label says, and it only answers pong

A console with seven buttons and five that work

On 22 September 2026, Have I Been Squatted published an analysis by Ben Folland of an Android campaign against logistics companies. What makes it unusually useful is that the researchers recovered both halves: the implant, and the operator panel that drives it. Very few published analyses have both, and putting them side by side produces a finding that has nothing to do with this particular malware.

The panel exposes seven controls. The implant implements five of them, and only one does exactly what its label says without qualification.

ping returns pong. That is the one.

sync_sms replies "Sync initiated" and reads nothing. The researchers are explicit: the recovered code never queries the message store, despite the application having requested the permission that would let it. get_location and lock_device are not implemented at all; the command dispatcher falls through and reports them as unknown. self_destroy disables the components, stops the service and asks Android to clear the app's data, but does not uninstall the package and does not undo the thing that matters most. And forward_on and forward_off submit a carrier request whose outcome the application cannot verify, then cache a local boolean and report it as truth.

What that does not establish. It does not establish that the campaign was ineffective: interception of new inbound SMS is enough on its own, and the researchers say so. It does not establish who wrote it. It does not establish victim numbers, because none are published. And it does not establish that the panel was lying to its own users on purpose rather than simply running ahead of the build, which is the ordinary condition of most software.

The panel against the implant, control by control

Every control in the Corp MDM operator panel against the behaviour recovered from the implant, from Have I Been Squatted's analysis of 22 September 2026.

Control	What the client actually does	Does the label hold?
ping	Returns pong through the result endpoint	Yes
forward_on	Submits a carrier forwarding request, outcome unverified	Conditionally
forward_off	Submits a cancellation, clears the cached state on callback	Conditionally
sync_sms	Reports Sync initiated, reads no stored messages	No
self_destroy	Disables components and clears data, does not uninstall	No
get_location	Not implemented, falls through as unknown	No
lock_device	Not implemented, falls through as unknown	No

The panel additionally claims server side device deletion and denylisting, which the client does not reflect either.

The permission set tells the same story. The application requests both the permission to receive new messages and the permission to read stored ones, and only ever uses the first. A responder reading the manifest would reasonably conclude the whole inbox had gone. A responder reading the code finds that only messages arriving after the grant were taken. Both readings lead to different, defensible incident scopes, and only one of them is correct.

The one finding worth acting on whatever you run

Call forwarding is not application state. It is carrier state.

The implant enables unconditional forwarding by submitting a standard supplementary service code through Android's telephony API, using a destination number the operator supplies. The network, not the phone, then holds the diversion. The researchers spell out the consequence and it is the most important sentence in the report: removing the package, clearing its data, or watching the self destruct command run does not cancel the forwarding. The self destruct routine does not call the cancellation path at all.

So an incident that looks closed is not. The device is clean, the application is gone, the endpoint tool is green, and every voice call still routes to somebody else. Nothing on the handset will tell you, because the implant itself never asked the carrier what the real state was; it cached a boolean and reported that.

This briefing does not print the sequence that enables forwarding. The cancellation is a standard code your carrier can confirm, commonly ##21#, and the right move is to verify the state with the carrier rather than to trust any code typed into a handset that has recently been compromised.

The rest of the campaign, briefly

Delivery was two fake Google Play listings, branded for two real logistics firms, reproducing Play's navigation, ratings, reviews, data safety cards and install controls on domains that were not Google's. Both served the same file. Both resolved to the same server, which also hosted the operator panel, credential phishing pages and Windows malware aimed at the same sector.

The implant is a single small package labelled System Service. It shows a fake ten second setup sequence, asks for message and telephone permissions half a second after launch, then starts its service, disables its own launcher entry and disappears from the app drawer and the task switcher while remaining installed. It restarts after boot and after package replacement. It talks to a hardcoded IP address over cleartext HTTP with no authentication, reporting the sender, full body and timestamp of every newly received message.

That last combination deserves a sentence of its own. Message content, in clear, over HTTP, to a raw address, with no transport security in either direction. Anyone on the path saw everything the operator saw.

On attribution the researchers are careful. They assess an Armenian or Russian nexus at medium confidence. The Armenian element rests on the operator panel prefilling the country code +374 in two fields, which are operator side defaults rather than anything derived from a victim. The Russian element comes from source code elsewhere in the wider campaign and is explicitly not established by this application or this panel. A previously reported group targeting the same sector is mentioned, and the report states there is no evidence the two are the same.

On development, the researchers assess that the actor likely used AI, citing bugs that hinder the malware's own capabilities. That is an assessment, not an artefact, and it is worth separating from the case published this week where a complete assistant reply was recovered from a live phishing page. Half finished features are evidence of a half finished build. They are consistent with AI assistance and also consistent with a hurried developer, and the report does not claim more than it can.

What to do about it

The question this leaves

Have I Been Squatted sells domain intelligence and takedown services, and this research is also marketing for that. It is unusually generous marketing: the analysis publishes the command table, the routes, the file hash and the hunting guidance, all of which are checkable by anyone who wants to disagree with it.

The finding that survives the sector, the country and the malware is smaller and more awkward. Somebody built a console with seven buttons on it. Two of them were wired to nothing, one reported a job it never started, one was named for a destruction it did not perform, and the operator running it had no way to tell, because the console answered from its own records rather than from the device.

So the question for your own tooling: which numbers on your dashboard are measurements, and which are things an agent told you once and nobody has checked since?