# T1417.002 - Input Capture: Keystroke Capture > [!warning] Captura de Teclado em Dispositivos Móveis > Malware móvel abusa do serviço de **Acessibilidade** do Android e de APIs de entrada do iOS para capturar silenciosamente tudo que o usuário digita - senhas bancárias, códigos PIX, credenciais corporativas e dados pessoais - sem qualquer sinal visível de comprometimento. ## Visão Geral A captura de teclado (keystroke capture) em dispositivos móveis representa uma das formas mais eficazes de roubo de credenciais porque opera de forma completamente transparente para a vítima. Diferentemente de ataques de phishing que exigem uma ação específica do usuário, um keylogger móvel opera de forma contínua e silenciosa, capturando todos os campos de entrada de texto - desde senhas de aplicativos bancários até mensagens privadas e códigos de autenticação de dois fatores. No Android, a técnica é implementada principalmente através do **Accessibility Service**, um mecanismo legítimo do sistema operacional projetado para auxiliar usuários com deficiências. Quando um malware obtém permissão de acessibilidade, ele pode registrar eventos de digitação em qualquer aplicativo, interceptar conteúdo de campos de texto (incluindo campos marcados como "senha"), capturar notificações e até mesmo executar ações em nome do usuário. Essa abordagem é documentada em famílias como [[brata-malware|BRata]], [[flubot-malware|FluBot]] e [[triout-spyware|Triout]]. No contexto do Brasil, a relevância é crítica: trojans bancários móveis combinam keystroke capture com [[t1417-001-input-capture-gui-input|overlay attacks]] (sobreposição de telas falsas) para capturar credenciais do [[financial\|setor financeiro]]. A proliferação do PIX como sistema de pagamento instantâneo tornou esse vetor ainda mais lucrativo, pois credenciais capturadas podem ser imediatamente utilizadas para transferências irreversíveis. ## Attack Flow ```mermaid graph TB IA["🎯 Initial Access<br/>App malicioso ou<br/>update trojanizado"] --> EX["⚡ Execution<br/>Instalação e<br/>execução do payload"] EX --> PE["👑 Privilege Escalation<br/>Solicita permissão<br/>de Acessibilidade"] PE --> P["🔒 Persistence<br/>Registra AccessibilityService<br/>no sistema"] P --> CA["🔑 Credential Access<br/>Intercepta eventos<br/>TYPE_VIEW_TEXT_CHANGED"] CA --> COL["📦 Collection<br/>Acumula keystrokes<br/>e contexto do app"] COL --> C2["📡 Command & Control<br/>Exfiltra dados<br/>criptografados ao C2"] C2 --> IMP["💥 Impact<br/>Fraude bancária<br/>Acesso a contas"] style COL fill:#e74c3c,color:#ecf0f1 style CA fill:#9b59b6,color:#ecf0f1 style IMP fill:#e67e22,color:#ecf0f1 ``` ## Como Funciona ### Android - Abuso do Accessibility Service O vetor primário no Android é o `AccessibilityService`, uma API poderosa que recebe eventos de acessibilidade de todos os aplicativos em execução. Para ativar o serviço, o malware precisa convencer o usuário a conceder permissão manualmente (via Configurações > Acessibilidade), frequentemente usando engenharia social - alegando ser necessário para "proteção antivírus" ou "modo de baixo consumo de bateria". Uma vez ativo, o serviço captura eventos como: ```xml <!-- Declaração maliciosa de AccessibilityService no AndroidManifest.xml --> <service android:name=".MaliciousAccessibilityService" android:permission="android.permission.BIND_ACCESSIBILITY_SERVICE"> <intent-filter> <action android:name="android.accessibilityservice.AccessibilityService"/> </intent-filter> <meta-data android:name="android.accessibilityservice" android:resource="@xml/accessibility_service_config"/> </service> ``` ```java // Captura de texto digitado via evento de acessibilidade @Override public void onAccessibilityEvent(AccessibilityEvent event) { if (event.getEventType() == AccessibilityEvent.TYPE_VIEW_TEXT_CHANGED) { String packageName = event.getPackageName().toString(); CharSequence text = event.getText().toString(); // Keystrokes capturados com contexto do app (ex: "br.com.bradesco.prime") logKeystroke(packageName, text); } } ``` O evento `TYPE_VIEW_TEXT_CHANGED` é disparado a cada modificação em um campo de texto, permitindo captura em tempo real. Campos de senha (`android:inputType="textPassword"`) deveriam mascarar o conteúdo, mas o AccessibilityService pode frequentemente acessar o texto em claro dependendo da implementação do aplicativo alvo. ### Android - InputMethodService (IME Malicioso) Uma segunda abordagem é a instalação de um **teclado malicioso** (InputMethodService). O usuário é persuadido a trocar seu teclado padrão pelo teclado malicioso, que captura cada tecla pressionada. Essa técnica é mais invasiva mas requer ainda mais consentimento do usuário. ### iOS - Restrições e Vetores Alternativos O iOS implementa um modelo de sandbox mais restritivo que impede o acesso direto a eventos de teclado de outros aplicativos. No entanto, existem vetores alternativos documentados: - **Teclados de terceiros maliciosos**: apps de teclado custom com permissão "Acesso Total" podem transmitir tudo que é digitado para servidores externos - **Perfis MDM comprometidos**: em ambientes corporativos, perfis de gerenciamento mal configurados podem conceder privilégios excessivos - **Jailbreak**: dispositivos com jailbreak perdem as proteções de sandbox do iOS, tornando-se vulneráveis a keyloggers tradicionais ### Exfiltração e Correlação de Contexto Keyloggers móveis avançados não capturam apenas o texto, mas também o **contexto**: nome do aplicativo, título da janela ativa e timestamps. Isso permite que o atacante correlacione automaticamente uma senha com o aplicativo bancário específico ao qual ela pertence, sem necessidade de análise manual. ## Detecção ### Indicadores Comportamentais Em soluções MTD (Mobile Threat Defense) como Lookout, Zimperium (zIPS) ou CrowdStrike Falcon for Mobile: - Aplicativos com `AccessibilityService` ativo sem função legítima de acessibilidade - Serviços de acessibilidade de apps não reconhecidos persistindo após reboot - IMEs (teclados) instalados de fontes fora da Play Store - Tráfego de rede de baixo volume, alta frequência, para IPs não categorizados ### Regra de Detecção (Mobile EDR) ```yaml title: Keystroke Capture via Accessibility Service - Android id: mobile-t1417-002-keystroke status: experimental description: > Detecta aplicativos utilizando AccessibilityService para captura potencial de teclado fora do contexto de acessibilidade legítima logsource: product: android service: accessibility detection: selection_event: EventType: TYPE_VIEW_TEXT_CHANGED filter_legitimate: AppPackage|startswith: - 'com.google.android.accessibility' - 'com.android.talkback' - 'com.samsung.accessibility' filter_known_keyboards: AppPackage|contains: - 'keyboard' - 'gboard' - 'swiftkey' condition: selection_event and not (filter_legitimate or filter_known_keyboards) falsepositives: - Leitores de tela legítimos (TalkBack, VoiceOver) - Gerenciadores de senha com acessibilidade ativa level: high tags: - attack.collection - attack.credential_access - attack.t1417.002 ``` ### Auditoria de Permissões ```bash # Verificar apps com AccessibilityService ativo via ADB adb shell settings get secure enabled_accessibility_services # Listar IMEs instalados adb shell ime list -a # Verificar apps com permissão de sobreposição (overlay) adb shell appops get <package> SYSTEM_ALERT_WINDOW ``` ## Mitigação | Controle | Mitigação MITRE | Descrição | |----------|----------------|-----------| | Boas práticas de usuário | [[m1011-user-guidance\|M1011]] | Nunca conceder acessibilidade a apps desconhecidos | | Versão atualizada do SO | [[m1006-use-recent-os-version\|M1006]] | Android 13+ restringe AccessibilityService de apps sideloaded | | Triagem de aplicativos | [[m1005-application-vetting\|M1005]] | Bloquear apps fora da Play Store em dispositivos corporativos | | Política MDM | [[m1030-network-segmentation\|M1030]] | Isolar dispositivos móveis corporativos em segmento separado | **Medidas defensivas prioritárias:** 1. **Nunca** conceder permissão de Acessibilidade a aplicativos que não sejam leitores de tela ou assistentes de motor comprovados 2. Revisar mensalmente a lista de serviços de acessibilidade ativos em Configurações > Acessibilidade 3. Em dispositivos corporativos, usar MDM para bloquear habilitação de acessibilidade por apps não-homologados 4. Implementar MTD com detecção comportamental de AccessibilityService 5. Habilitar Google Play Protect e manter ativo o escaneamento periódico ## Contexto LATAM > [!latam] Relevância Regional - Brasil e América Latina > O Brasil lidera o ranking LATAM de incidentes com trojans bancários móveis que utilizam keystroke capture. **BRata** (2019-presente), **Ghimob** e variantes do **Grandoreiro** mobile combinam esta técnica com overlay attacks para capturar credenciais de aplicativos do Itaú, Bradesco, Banco do Brasil e Nubank. A popularidade do **PIX** tornou o ataque ainda mais crítico: credenciais capturadas podem ser usadas para transferências instantâneas irreversíveis. O **CERT.br** e a **Febraban** emitiram alertas específicos sobre essa combinação de técnicas em 2024. ## Referências - [MITRE ATT&CK T1417.002](https://attack.mitre.org/techniques/T1417/002/) - [ESET - BRata: Brazilian Remote Access Tool Android](https://www.welivesecurity.com/la-es/) - [Kaspersky - Ghimob: um Trojan Bancário Brasileiro para Android](https://latam.kaspersky.com/blog/) - [CERT.br - Códigos Maliciosos em Dispositivos Móveis](https://www.cert.br/) - [Android Accessibility Service Documentation](https://developer.android.com/guide/topics/ui/accessibility/service) - [Google TAG - Android Malware Families](https://blog.google/threat-analysis-group/) - [Zimperium - Mobile Threat Landscape Report 2024](https://www.zimperium.com/)