# T1638 - System Information Discovery > [!warning] Coleta de fingerprint do dispositivo para targeting e evasão > Malware móvel coleta informações detalhadas do sistema — IMEI, modelo, versão do SO, apps instalados, status de root/jailbreak — para perfilar a vítima antes de ataques direcionados e para evadir ambientes de análise e sandboxes. ## Visão Geral O System Information Discovery em dispositivos móveis é uma técnica de reconhecimento executada localmente pelo malware após a infecção inicial. O objetivo é duplo: construir um **perfil técnico do dispositivo** para targeting (determinar quais overlays bancários apresentar, quais apps monitorar) e **detectar ambientes de análise** para evadir sandboxes e ferramentas forenses. No Android, as APIs do sistema expõem uma quantidade significativa de informações sem necessidade de permissões especiais. Dados como modelo do dispositivo, versão do Android, operadora e lista de apps instalados são acessíveis para qualquer aplicativo, tornando essa técnica de baixíssimo custo e amplamente utilizada por trojans bancários desde as etapas iniciais de execução. Do ponto de vista defensivo, a técnica em si não causa dano direto, mas seu uso combinado com [[t1417-002-gui-input-capture|T1417.002]] e [[t1646-exfiltration-over-c2-channel|T1646]] compõe o pipeline completo de fraude financeira mobile: descoberta do ambiente → seleção do overlay correto → captura de credenciais → exfiltração. Para equipes de SOC e MDM, detectar coleta anômala de informações de sistema é o sinal mais precoce de comprometimento disponível. A relevância para o Brasil é alta: trojans como [[grandoreiro]] e [[coyote-banking-trojan]] usam fingerprinting para determinar quais bancos a vítima utiliza (através da lista de apps instalados) e personalizar o ataque. Em contextos de fraude PIX, o IMEI e o número de telefone são usados para associar o dispositivo comprometido a contas bancárias específicas, facilitando transferências fraudulentas automatizadas. ## Attack Flow ```mermaid graph TB A["📦 Instalação<br/>APK malicioso executado"] --> B["🔍 Fingerprint inicial<br/>Build.* + TelephonyManager"] B --> C["📋 Inventário de apps<br/>PackageManager query"] C --> D["🧪 Checagem anti-análise<br/>Emulador? Root? ADB ativo?"] D --> E{"🎯 Decisão<br/>de targeting"} E -->|"App bancário<br/>detectado"| F["🎭 Ativar overlay<br/>T1417.002"] E -->|"Ambiente suspeito"| G["😴 Dormir / abortar<br/>Evasão de sandbox"] F --> H["📡 Enviar perfil<br/>ao C2"] classDef collection fill:#9b59b6,color:#ecf0f1 classDef decision fill:#e67e22,color:#ecf0f1 classDef evasion fill:#2c3e50,color:#ecf0f1 classDef attack fill:#e74c3c,color:#ecf0f1 class B,C collection class D,E decision class G evasion class F,H attack ``` *Legenda: Fingerprinting do dispositivo orienta targeting e evasão de sandbox antes de ativar funcionalidades maliciosas* ## Como Funciona ### APIs Android — Sem Permissão Necessária O Android expõe dados de sistema através de classes públicas que não requerem permissões no manifest: ``` android.os.Build ├── Build.MANUFACTURER → fabricante (Samsung, Xiaomi, Motorola) ├── Build.MODEL → modelo do dispositivo ├── Build.VERSION.SDK_INT → versão da API Android ├── Build.FINGERPRINT → build fingerprint único └── Build.SERIAL → número serial (deprecated API 26+) android.telephony.TelephonyManager ├── getDeviceId() → IMEI/MEID (requer READ_PHONE_STATE) ├── getLine1Number() → número do telefone ├── getSimCountryIso() → país da operadora (ex: "br") └── getNetworkOperatorName() → nome da operadora (Vivo, Claro, TIM, Oi) android.content.pm.PackageManager ├── getInstalledPackages() → lista completa de apps instalados └── getInstalledApplications() → metadados de cada aplicativo ``` ### Detecção de Apps Bancários A técnica mais comum é iterar `getInstalledPackages()` e cruzar com uma lista hardcoded de package names de apps bancários: | App Bancário | Package Name | |-------------|-------------| | Itaú | `com.itau` | | Bradesco | `com.bradesco` | | Caixa | `br.com.gabba.Caixa` | | Nubank | `com.nu.production` | | Santander | `com.santander.app` | | Banco do Brasil | `br.com.bb.android` | | Inter | `br.com.intermedium` | Com essa informação, o malware personaliza quais overlays baixar do C2, reduzindo o tamanho inicial do APK e evitando detecção por análise estática. ### Anti-Análise via Fingerprint Sandboxes e emuladores Android possuem características detectáveis: - `Build.FINGERPRINT` contendo `"generic"`, `"unknown"` ou `"test-keys"` - `Build.MODEL` igual a `"sdk"`, `"google_sdk"`, `"Emulator"` ou `"Android SDK built for x86"` - `Build.MANUFACTURER` igual a `"Genymotion"` ou `"unknown"` - `SystemProperties.get("ro.kernel.qemu")` retornando `"1"` - Ausência de apps de uso cotidiano (WhatsApp, Instagram) na lista de packages instalados - `TelephonyManager.getPhoneType()` retornando `PHONE_TYPE_NONE` Se qualquer um desses indicadores for detectado, o malware pode dormir, desativar funcionalidades maliciosas ou encerrar o processo — tornando a análise dinâmica ineficaz. ### iOS — Informações Disponíveis No iOS, o acesso a informações de sistema é mais restrito pela sandbox. Técnicas equivalentes incluem: - `UIDevice.current.systemVersion` → versão do iOS - `UIDevice.current.model` → modelo (iPhone, iPad) - `UIDevice.current.identifierForVendor` → UUID por vendor (não é IMEI) - Detecção de jailbreak via tentativas de escrita em `/private/` ou verificação de presença de `Cydia.app` - Enumeração de apps via URL schemes (`canOpenURL:`) — limitada no iOS 9+ mas ainda funcional para alvos específicos ## Detecção ### Sinais Comportamentais | Comportamento | Ferramenta de Detecção | |---------------|----------------------| | App enumerando todos os packages instalados na inicialização | EDR móvel (Lookout, SentinelOne Mobile) | | Leitura de `Build.*` imediatamente após instalação | Análise comportamental em sandbox | | Múltiplas chamadas a `getInstalledApplications()` em background | Play Protect behavioral analysis | | Checkin ao C2 contendo campos IMEI/modelo/versão em JSON | Network traffic inspection via MDM proxy | | App solicitando `READ_PHONE_STATE` sem funcionalidade aparente | App vetting manual / Play Protect | ### Análise de Tráfego de Rede Trojans bancários frequentemente enviam o perfil do dispositivo como primeiro beacon ao C2, geralmente em JSON não-cifrado ou com cifração fraca: ```json { "imei": "123456789012345", "model": "Samsung SM-G998B", "android_version": "13", "operator": "Vivo", "country": "br", "installed_banks": ["com.itau", "com.nu.production"], "is_rooted": false } ``` Regras de IDS/proxy MDM que detectam campos `imei`, `installed_packages` ou `is_rooted` em payloads HTTP para domínios não-reconhecidos são eficazes como detecção precoce. ### Sigma (conceitual) Ambientes com EDR móvel podem criar detecções para: - Chamadas sequenciais a `PackageManager.getInstalledPackages()` + `TelephonyManager.getDeviceId()` no mesmo contexto de execução - Apps com menos de 30 dias desde a instalação realizando fingerprinting completo ## Mitigação | Controle | Wikilink | Descrição | |----------|----------|-----------| | Gerenciamento de aplicações corporativas | [[m1051-update-software\|M1051]] | MDM para controle de apps instalados | | Política de uso aceitável | [[m1036-account-use-policies\|M1036]] | Restringir sideloading em dispositivos corporativos | | Guia de desenvolvimento seguro | [[m1013-application-developer-guidance\|M1013]] | Apps legítimos devem solicitar apenas permissões necessárias | | Segmentação de rede | [[m1037-filter-network-traffic\|M1037]] | Bloquear domínios C2 conhecidos via MDM proxy | **Recomendações práticas:** - Usar **Android Enterprise Work Profile** para isolar apps corporativos — apps pessoais não conseguem enumerar packages do perfil de trabalho - Habilitar **Google Play Protect** para detecção comportamental contínua - Em ambientes corporativos, revisar logs de MDM para apps que solicitam `READ_PHONE_STATE` sem justificativa - Implementar **network proxy MDM** para inspecionar beacons iniciais de apps suspeitos - Não fornecer acesso a apps de trabalho em dispositivos com root/jailbreak detectado ## Contexto LATAM > [!latam] Relevância Brasil e América Latina > No Brasil, o fingerprinting via T1638 é passo obrigatório na cadeia de ataque dos principais trojans bancários. **Grandoreiro** usa a lista de apps instalados para selecionar qual interface de overlay apresentar entre mais de 900 alvos bancários globais — incluindo todos os principais bancos brasileiros. **Coyote** combina fingerprinting com enumeração de certificados instalados para detectar soluções de MDM corporativo e ajustar seu comportamento. Com o crescimento do PIX como meio de pagamento instantâneo, o IMEI coletado via T1638 é cruzado com bases de dados vazadas de CPF/telefone para automatizar fraudes de portabilidade e takeover de contas, representando vetor emergente de alto impacto no sistema financeiro brasileiro. ## Referências - [MITRE ATT&CK T1638](https://attack.mitre.org/techniques/T1638/) — Definição oficial e exemplos de procedimento - [ESET — Grandoreiro targeting 900+ banks](https://www.welivesecurity.com/en/eset-research/grandoreiro-how-ongoing-fraud-campaign-targets-banks-around-the-world/) — Análise do mecanismo de seleção por app instalado - [Kaspersky — Coyote Banking Trojan](https://securelist.com/coyote-banking-trojan/115055/) — Fingerprinting e detecção de MDM no Coyote - [ESET — Ghimob banking trojan](https://www.welivesecurity.com/2020/11/19/ghimob-tethys-financial-cybercrime-latin-america/) — Análise do Ghimob com foco em LATAM - [Android Developers — PackageManager](https://developer.android.com/reference/android/content/pm/PackageManager) — Documentação da API de enumeração de packages - [CERT.br — Trojans bancários Android](https://www.cert.br/docs/whitepapers/trojans-bancarios/) — Panorama brasileiro de trojans móveis