· Droidwatch Security Research team · 5 min de lectura · Investigación de amenazas anatsa teabot troyano-bancario overlay
🌐 Read in English →

Cómo Droidwatch detecta troyanos bancarios Anatsa en 3 segundos

Anatsa (TeaBot) es uno de los troyanos bancarios Android más sofisticados in-the-wild. Droidwatch lo marca como Malicioso en menos de 3 segundos — aquí están la

Cómo Droidwatch detecta troyanos bancarios Anatsa en 3 segundos

Publicado el 2026-05-16 por el equipo de investigación de seguridad de Droidwatch


Anatsa (también rastreado como TeaBot) es uno de los troyanos bancarios Android más sofisticados técnicamente que circulan hoy in-the-wild. Ha robado credenciales de clientes de más de 600 aplicaciones bancarias en 65 países, y sus operadores actualizan continuamente la cadena del dropper para evadir la detección.

Pese a esa sofisticación, Droidwatch clasifica las muestras de Anatsa como Malicioso en menos de 3 segundos de análisis estático. Este post explica exactamente qué señales lo delatan — y muestra las reglas de detección y el JSON de hallazgos que lo hacen posible.


Qué hace distintivo a Anatsa

Anatsa combina cuatro capacidades técnicas que, por separado, podrían aparecer en apps legítimas. Es la combinación lo que lo hace identificable:

1. Detección de overlay

Anatsa dibuja un overlay HTML a pantalla completa sobre las apps bancarias objetivo usando TYPE_APPLICATION_OVERLAY. El overlay es pixel-perfect — replica la pantalla de login legítima del banco y captura credenciales en silencio antes de reenviarlas a un servidor C2.

La huella estática: el permiso android.permission.SYSTEM_ALERT_WINDOW declarado en el manifest y referencias de string a TYPE_APPLICATION_OVERLAY y una lista de filtrado de paquetes (un array JSON con los nombres de paquete de los bancos objetivo) embebida en las clases DEX.

2. Abuso del servicio de accesibilidad

Anatsa registra un AccessibilityService para monitorear los cambios de la aplicación en primer plano. Cuando una app bancaria objetivo pasa a primer plano, el servicio dispara la inyección del overlay sin ninguna interacción del usuario.

El servicio de accesibilidad también intercepta eventos TYPE_VIEW_TEXT_CHANGED para capturar pulsaciones de teclas, y TYPE_WINDOW_STATE_CHANGED para detectar cuándo el usuario navega a otra parte.

3. Patrones de comunicación C2

Las primeras versiones de Anatsa usaban direcciones IP hardcodeadas. Las variantes nuevas (v4+) usan generación de dominios estilo DGA o codifican la dirección C2 en los assets de la app (habitualmente assets/strings.xml o un PNG con esteganografía). Los strings del DEX siempre contienen código de construcción de POST HTTP que referencia rutas como /bot/register, /bot/injectResult y /bot/task.

4. Ofuscación del DEX

Anatsa usa de forma consistente el troceo y recombinación de strings para evadir la detección ingenua por coincidencia de strings:

// Decompilado de una muestra de Anatsa (salida de JADX)
private static String a() {
    return "Ljavax/crypto/Ci" + "pher;";
}

El analizador profundo de DEX de Droidwatch detecta estos patrones mediante un score heurístico de ofuscación. Las muestras de Anatsa suelen puntuar entre 7 y 9 sobre 10.


Las reglas YARA que lo atrapan

Droidwatch incluye la siguiente regla YARA para la detección de la familia Anatsa:

rule Anatsa_BankingTrojan_v4 {
    meta:
        description = "Detects Anatsa/TeaBot banking trojan DEX patterns (v3-v4 dropper chain)"
        author      = "Droidwatch Security Research"
        date        = "2026-05-01"
        severity    = "critical"
        mitre       = "T1417.002, T1422, T1636.002"
        family      = "Anatsa"
        reference   = "https://threatfabric.com/blogs/anatsa-new-campaign.html"

    strings:
        // C2 endpoint fragments (split across methods in obfuscated variants)
        $c2_register  = "/bot/register"   ascii wide
        $c2_task      = "/bot/task"        ascii wide
        $c2_inject    = "/bot/injectResult" ascii wide

        // Overlay trigger string (recombined at runtime but partial is present)
        $overlay_type = "TYPE_APPLICATION_OVERLAY" ascii

        // Accessibility event types used for keylogging
        $a11y_text    = "TYPE_VIEW_TEXT_CHANGED"  ascii
        $a11y_window  = "TYPE_WINDOW_STATE_CHANGED" ascii

        // Package filter array — Anatsa embeds target bank package names
        $pkg_filter   = "targetPackages" ascii

        // DEX string split/join obfuscation pattern
        $obf_1 = "Ljavax/crypto/Ci" ascii
        $obf_2 = "Landroid/telephony" ascii

    condition:
        (2 of ($c2_*))
        and $overlay_type
        and (1 of ($a11y_*))
        and (
            $pkg_filter
            or (1 of ($obf_*))
        )
}

Esta regla salta con la combinación de fragmentos de endpoint C2, capacidad de overlay y abuso de accesibilidad — tres señales que juntas tienen una tasa de falsos positivos casi nula en apps legítimas.


Ejemplo de JSON de hallazgos

Aquí va un extracto del array real de hallazgos en un reporte de Droidwatch para un dropper de Anatsa (score: 91, verdict: "Malicious"):

{
  "overview": {
    "score": 91,
    "verdict": "Malicious",
    "severities": {
      "critical": 3,
      "high": 5,
      "medium": 4,
      "low": 2,
      "info": 8
    }
  },
  "findings": [
    {
      "id": "YARA_ANATSA_V4",
      "title": "Anatsa Banking Trojan — YARA match (v4 dropper chain)",
      "severity": "critical",
      "confidence": 0.97,
      "category": "malware_family",
      "description": "YARA rule Anatsa_BankingTrojan_v4 matched 7/8 strings including C2 endpoint fragments (/bot/register, /bot/task), overlay API references, and accessibility event abuse patterns.",
      "mitre_techniques": ["T1417.002", "T1422", "T1636.002"],
      "evidence": {
        "yara_rule": "Anatsa_BankingTrojan_v4",
        "matched_strings": [
          "/bot/register",
          "/bot/task",
          "/bot/injectResult",
          "TYPE_APPLICATION_OVERLAY",
          "TYPE_VIEW_TEXT_CHANGED",
          "targetPackages",
          "Ljavax/crypto/Ci"
        ]
      }
    }
  ]
}

¿Por qué 3 segundos?

La velocidad viene del pipeline de análisis:

  1. Descompresión del APK + parseo del manifest (~200 ms) — permisos, receivers y servicios se extraen de inmediato.
  2. Extracción de strings del DEX (~400 ms) — todos los literales de string de todos los archivos DEX se extraen a un índice plano.
  3. Escaneo YARA sobre el índice de strings (~80 ms) — el índice se contrasta con todas las reglas YARA cargadas. No hace falta desensamblar el DEX completo para el veredicto inicial.
  4. Motor de scoring (~50 ms) — las coincidencias de reglas alimentan el motor de scoring, que calcula el score final 0–100 y el veredicto.

El desensamblado profundo del DEX (call graph, análisis de flujo de datos) corre en segundo plano y enriquece el reporte de forma asíncrona, pero el veredicto inicial está disponible en la primera pasada.


Pruébalo tú mismo

Sube un APK sospechoso en droidwatch.app — sin registro para los tres primeros análisis. Si eres un equipo de seguridad que gestiona incidentes de troyanos bancarios a escala, el plan Pro o Enterprise te da acceso por API en bloque, export STIX 2.1 para ingesta en SIEM y un threat feed privado de todas las muestras analizadas por tu equipo.

Preguntas o envío de muestras: [email protected]

Threat Research

Droidwatch's research team analyzes Android & iOS malware — banking trojans, spyware, droppers and overlay kits — and writes up the static and dynamic signals that give them away. Every post is grounded in real platform output.

Analyze your first app free — drag an APK or iOS .ipa onto the homepage for a full static report in about a minute. Get started free