It blocks screenshots
FLAG_SECURE is set. Its own screens capture as zero bytes while the
rest of the system captures normally — so neither the person holding the phone nor
an analyst can photograph what it displays.
Technical analysis
"Assistenza Clienti": an Android app whose server can switch on your microphone
An application distributed as customer support for an Italian mobile carrier turns
out to be a WebView shell driven in real time by its operator's server. A native
bridge named mysupport hands that server three levers on the phone:
read the pairing ID, record the microphone to a file, and take a file from the
device. This is what the app's own bytecode exposes — not what its permissions
suggest.
Riccardo Bacci — Mythos Sentinel, Terni, Italy · 5 September 2026
In one paragraph
What was found
com.itassistenzaclienti, published under the developer name
"Telecomunicazione Mobile", carries almost no interface of its own. On launch it
loads its screen from
https://telecomunicazioni-mobile.com/support/ and renders whatever the
operator serves. Because the HTML comes from their server, what the app does on a
given day is their decision, not something frozen in the package. The capabilities
it makes available to that HTML, however, are frozen in the package — and
those are the subject of this analysis.
The store listing declares that the app collects no data. Android's own network counters measured it sending 6.5 MB, rising to 15.1 MB, against 0.53 MB received — roughly twelve to one in the upload direction — to a single private server.
The decisive part
Three methods handed to remote HTML
The main activity registers a native object through
addJavascriptInterface under the name mysupport, exposing
three @JavascriptInterface methods to whatever page the server sends:
getToken()— returns the device↔operator pairing code. The page served at analysis time polled it once per second and displayed it as "your unique ID, give it to the operator".openVoiceNotesActivity()— starts a second screen of the app which holds anandroid.media.AudioRecordobject and a method returning ajava.io.File: it records the microphone and writes it to disk. This is the application's own code, not the third-party video library it bundles.pickFile(String)— opens a file chooser: takes a file from the device.
The same activity also carries onCallReceived(...) and
onUrlReceived(...) handlers, so the server can push "call" and "open
this address" events to the phone.
Corroboration
Things a support app has no reason to do
It hides its own strings
The name mysupport, the URLs and the intent actions are encrypted
strings decoded at runtime, and the bytecode is padded with opaque predicates —
multiplications, xors and remainders computed for no result.
It is machine-generated
Eight classes all named ComponentNNNNNNN with random numbering:
the code was produced by a tool, not written by hand.
Its publisher is anonymous
The signing certificate's Distinguished Name is CN=teleit — no
organisation, no country — against permissions for the microphone, call handling
and package installation.
Two further observations. The app requests the microphone,
MANAGE_OWN_CALLS and REQUEST_INSTALL_PACKAGES, and
not camera, SMS, contacts, location or storage: the permission set is
narrow and pointed rather than greedy. And during the analysis the operator's
backend returned HTTP 502 — at which point the app showed nothing and did nothing,
confirming from another angle that it is a pure remote shell.
Reproducible
How the traffic was read
The app does not trust the system's certificate authorities, nor any the user adds.
Its network_security.xml names a single root of trust: a raw file
shipped inside the package, res/raw/bundle.pem, holding 145 public root
certificates. There is no application-level pinning — no
CertificatePinner, no sha256 pin. That one file is the entire barrier.
- An analysis CA was appended to
bundle.pem, taking it from 145 to 146 certificates, and the last entry verified to be exactly ours. Because the bundle is a raw file rather than a compiled resource, no decompiler was involved. - The package was recomposed as an archive (527 entries, unchanged), aligned, and
all four parts re-signed — the base plus the
arm64_v8a,hdpianditsplits — with one throwaway key, since multi-part installation demands a consistent signature. - The device's traffic was routed to a local listening point. No certificate authority was added to the operating system: the trust was placed inside the application, where the application looks for it.
On launch, the decrypted traffic showed
GET /support/9.html?language=it&packagename=com.itassistenzaclienti
returning 200 (2,555 bytes), followed by main.css and
icon.png. The headers carried no sensitive identifier — only
x-requested-with and the device model in the User-Agent.
The limit, stated plainly
What this analysis does not claim
We did not capture the exfiltrated payload. Doing so would have meant impersonating the operator, ordering the phone to switch on its microphone, and reading the bytes it tried to upload — that is putting the surveillance tool into live operation, and it is not an action we take regardless of the purpose. So this is a report of demonstrated capability and measured behaviour, not of intercepted content.
For the same reason, two things present in the package are deliberately not counted as evidence. References to screen recording, WebSockets and multipart upload come from the bundled Stream video SDK and from Retrofit; their mere presence proves no use. And the recording screen does not start on its own — it opens a UI with buttons and needs a tap, which means the operator has to talk the victim through it. We say so because the rule we hold ourselves to is to describe behaviour rather than attribute intent.
For defenders
Indicators of compromise
- Domain —
telecomunicazioni-mobile.com - IP address —
93.186.254.171(host171-254-186-93.serverdedicati.aruba.it, a dedicated server at Aruba, Italy — the sole destination across 30 samplings) - Android package —
com.itassistenzaclienti - Signing certificate — DN
CN=teleit, SHA-256c37ab648 96d44ffe 831f6309 e5f66541 3f47b42f 6341d1ef a81b23ba 5d6545ad - On-disk trace — a hidden directory
/storage/emulated/0/.AReapercontaining an identifier file
Re-checked on 5 September 2026: the domain still resolves to that address, the
Let's Encrypt certificate was renewed on 21 July 2026, and the panel still returns
HTTP 200 with the same mysupport.getToken() script. The infrastructure
is actively maintained.
These indicators are being submitted to mvt-indicators, the indicator set used by Amnesty International's Mobile Verification Toolkit, so that anyone running MVT can check a device against them.
Not the same thing
A note on Spyrtacus
The disguise resembles Spyrtacus,
the Italian spyware whose delivery domain is supporto-mobile.it, and
the obvious reaction is to call them the same thing. We checked instead of saying
it. The IP here is unrelated to the addresses listed there; the Spyrtacus collection
includes a C2 favicon hash, and this server serves no favicon at all, so that
comparison cannot even be made; and the architecture differs — Spyrtacus is a native
implant that takes screenshots, records calls and exports WhatsApp messages, while
this is a remote-driven WebView with a three-method bridge. We report it as a
separate case and leave the question open.
If you are worried about your own phone
What to take from this
The lure works because it is boring: an app called "customer support", an operator on the phone, an ID to read out. Nothing about the screen looks like an attack. The practical defences are the dull ones — install from the store listing you reached yourself rather than from a link someone sent you, be suspicious of any "support" that needs its own app and a code read aloud, and check which apps hold the microphone permission.