Hace unos días contamos que un dispositivo OPPO había realizado una conexión nocturna hacia un dominio que no reconocíamos. En lugar de quedarnos con una única observación, decidimos ampliar la prueba: capturamos tráfico de tres dispositivos OPPO distintos, en condiciones diferentes y durante varias noches, utilizando PCAPdroid en los terminales y la infraestructura del CPD de Tecnidom para correlacionar y analizar el tráfico de red.
El objetivo no era demostrar de antemano una conclusión, sino responder a una pregunta más sencilla: ¿qué servicios se activan cuando los dispositivos están en reposo, con qué frecuencia y qué diferencias aparecen entre modelos, compilaciones y condiciones de energía?
El dominio que inició la investigación, clickfunax.top, no volvió a aparecer después de desactivar la aplicación de Música de fábrica que PCAPdroid había asociado previamente con esa comunicación. En las capturas posteriores no observamos ni consultas DNS ni conexiones TLS hacia ese dominio durante más de nueve horas de observación simultánea. Es una pista fuerte, aunque conviene distinguir siempre entre correlación técnica y prueba definitiva de causalidad.
Los tres dispositivos analizados
- OPPO CPH2173, Android 14 / ColorOS 14.0, build CPH2173_14.0.0.2102 (ES01V60P01).
- OPPO CPH2173, Android 14 / ColorOS 14.0, build CPH2173VF_14.0.0.2102 (EX01).
- OPPO OPD2102A, Android 13 / ColorOS 13.0, build OPD2102A_11_C_34.
También disponemos de wearables OPPO, pero no fue posible instalar PCAPdroid directamente en ellos. Por tanto, cualquier observación relacionada con el reloj procede del tráfico visto desde el móvil asociado, no de una captura directa del propio wearable.
Metodología y límites de la prueba
Las capturas se realizaron con la pantalla apagada, sin interacción del usuario y sin aplicaciones abiertas en primer plano. En varias pruebas repetimos el mismo escenario con el dispositivo conectado al cargador y funcionando únicamente con batería.
Hay una limitación importante: ver una consulta DNS o una conexión no permite saber por sí sola qué datos se están enviando. Gran parte del tráfico utiliza TLS y, por tanto, está cifrado. Lo que sí podemos observar es qué dominios se consultan, cuándo se establecen conexiones, qué proceso las origina cuando la herramienta puede atribuirlo y qué patrones se repiten.
También tuvimos en cuenta que los primeros y últimos minutos de una captura pueden quedar contaminados por la propia interacción necesaria para iniciar o detener PCAPdroid. Por eso no tratamos una única consulta aislada como una prueba concluyente.
Lo que se repite en los dispositivos
En los tres equipos apareció tráfico hacia infraestructura de servicios de HeyTap asociada al ecosistema OPPO, OnePlus y realme. Entre los nombres observados estaban mdp-appconf-eu.heytapdl.com, cloudconf-app-eu.heytapmobile.com y obus-dc-eu.heytapmobile.com.
También aparecieron distintos hosts bajo allawnos.com. El patrón no fue idéntico en todos los dispositivos: algunos servicios aparecían en un terminal y no en otro, incluso cuando ambos teléfonos eran del mismo modelo.
La batería cambia claramente el patrón
Una de las comparaciones más útiles fue repetir la captura nocturna en el mismo teléfono, primero conectado al cargador y después funcionando con batería.
Con el terminal cargando registramos 155 consultas DNS hacia mdp-appconf-eu y 87 hacia cloudconf-app-eu, repartidas prácticamente durante toda la noche. A batería, las mismas consultas bajaron a 44 y 26, con un periodo de silencio de varias horas.
Repetimos la prueba a batería con los dos CPH2173 durante la misma noche. En uno de ellos, durante 9 horas y 13 minutos, contamos 44 consultas DNS hacia mdp-appconf-eu.heytapdl.com, 26 hacia cloudconf-app-eu.heytapmobile.com y 4 hacia obus-dc-eu.heytapmobile.com. En el segundo teléfono las resoluciones fueron 30, 5 y 3 respectivamente.
Pero aquí apareció un matiz importante: contar DNS no equivale a contar comunicaciones. Debido a la caché DNS, un dispositivo puede reutilizar una resolución anterior. Al revisar también los inicios de sesión TLS observamos al menos 53 conexiones hacia mdp-appconf-eu en uno de los terminales y 71 en el otro.
La diferencia entre funcionamiento con cargador y con batería encaja con el comportamiento esperado de los mecanismos de ahorro energético de Android, que restringen progresivamente parte de la actividad en segundo plano. Aun así, la tablet no reprodujo exactamente el mismo patrón, por lo que no sería correcto extrapolar una única explicación a todos los dispositivos.
Dos endpoints relacionados con publicidad
En uno de los teléfonos aparecieron dos nombres especialmente llamativos: adx-ads-fr.heytapmobile.com y adx-op-fr.heytapmobile.com. Para el primero observamos además una conexión TLS posterior; para el segundo, en esa captura concreta, únicamente la consulta DNS.
El nombre de un endpoint puede aportar contexto, pero no permite afirmar qué información concreta se intercambia. Esa distinción es fundamental: podemos documentar la existencia y el momento de la comunicación, no el contenido de una sesión TLS cifrada.
AppBox: aquí sí podemos atribuir la conexión a una aplicación
En uno de los CPH2173 encontramos una aplicación de sistema llamada AppBox, versión 20.26.0.1.48. Desde la información de la aplicación el sistema permitía inhabilitarla, pero no ofrecía una opción normal de desinstalación.
Durante la captura nocturna, PCAPdroid atribuyó directamente a AppBox conexiones hacia ape-androids2.isappcloud.com e ib.isappcloud.com. En ambos casos observamos primero resoluciones DNS y, aproximadamente un minuto después, conexiones TLS por el puerto 443, con alrededor de 12,3 KB y 11,2 KB transferidos respectivamente.
Esta observación es más fuerte que una simple coincidencia de dominios, porque la herramienta identifica el proceso que origina la conexión. Lo que no podemos inferir únicamente a partir de esa captura es qué datos se transfirieron ni con qué finalidad concreta.
Mismo modelo, misma noche, tráfico diferente
Los dos teléfonos eran el mismo modelo y estuvieron conectados a la misma red durante la misma noche, pero utilizaban compilaciones distintas: ES01 y EX01. El comportamiento observado tampoco fue idéntico. Los endpoints adx-* aparecieron en uno; AppBox y la infraestructura isappcloud.com, en el otro.
¿Influye la compilación instalada en los servicios habilitados o en el software preinstalado? Es una posibilidad que merece investigación, pero con estas capturas todavía no tenemos datos suficientes para afirmarlo.
Cómo comprobar el tráfico de tu propio móvil
La prueba básica puede hacerse sin root y sin herramientas de pago:
- Instala PCAPdroid desde una fuente oficial.
- Inicia una captura local. La aplicación crea una VPN local para observar el tráfico del propio dispositivo.
- Deja el móvil varias horas con la pantalla apagada y sin interacción.
- Si quieres comparar condiciones, repite la prueba una noche conectado al cargador y otra únicamente con batería.
- Revisa la sección de conexiones y observa qué dominios y procesos aparecen de forma recurrente.
La interpretación de los resultados requiere prudencia. Una consulta DNS no demuestra que se haya transferido información, una conexión TLS no revela su contenido y un dominio con un nombre llamativo no prueba por sí mismo una finalidad concreta.
La pista de los wearables
Aunque no pudimos capturar directamente el tráfico del reloj, en uno de los móviles registramos 5 consultas DNS y 6 conexiones TLS hacia eu-sport.health.heytapmobile.com, relacionado con la aplicación que sincroniza los wearables y los datos de actividad. Esto demuestra actividad desde el teléfono, pero no permite concluir qué información envía el reloj.
Qué podemos concluir por ahora
Las pruebas muestran que dispositivos aparentemente inactivos mantienen actividad de red en segundo plano y que el patrón puede variar según el equipo, la compilación y si está conectado a la corriente o funciona con batería.
También muestran por qué conviene separar cuidadosamente hechos de hipótesis. Podemos documentar dominios, horarios, frecuencia, conexiones y, en algunos casos, la aplicación que origina el tráfico. No podemos afirmar el contenido de comunicaciones cifradas sin evidencia adicional.
La investigación continúa. En Tecnidom estamos utilizando esta serie no solo para analizar un fabricante concreto, sino para mostrar algo más amplio: tener dispositivos conectados implica confiar en una cantidad de comunicaciones que normalmente el usuario nunca ve. La forma de evaluar esa confianza es medir, comparar y documentar antes de sacar conclusiones.
Para profundizar
Si este tema te interesa, estos artículos amplían la parte técnica y operativa:
¿Necesitas ayuda con la tecnología de tu empresa?
Podemos revisar contigo qué está ocurriendo, qué riesgos existen y por dónde tiene sentido empezar.
