Como funciona um trojan bancário Android

Um trojan bancário Android não quebra a criptografia nem ataca o banco. Ele espera a vítima se autenticar e captura as credenciais no ponto em que ainda estão em texto claro: o teclado.

Todo o resto da família — as permissões, a entrega em estágios, o antianálise — existe para tornar aquele instante possível e para mantê-lo funcionando depois.

Entender a cadeia de capacidades importa para a triagem, porque os componentes isolados são pouco chamativos. A permissão de sobreposição é usada por aplicativos de mensagens legítimos. Serviços de acessibilidade existem para usuários que precisam deles. Um sinal isolado não prova nada; a combinação é o achado.

As quatro capacidades

1. Sobreposição

O ataque exige desenhar uma janela sobre o aplicativo bancário, idêntica pixel a pixel à sua tela de acesso. A vítima digita na janela do atacante.

No Android isso requer SYSTEM_ALERT_WINDOW, e as variantes modernas combinam essa permissão com uma checagem de qual aplicativo está em primeiro plano, para que a tela falsa apareça no momento certo e não ao acaso. Essa detecção de primeiro plano exige, por sua vez, enumerar os pacotes instalados, e é assim que QUERY_ALL_PACKAGES entra no conjunto: o malware precisa saber qual sobreposição bancária exibir.

Em um relatório isso aparece como dois achados distintos: a permissão isolada, e a permissão junto da detecção de primeiro plano. O segundo é evidência materialmente mais forte que o primeiro, e o Droidwatch os pontua separadamente por essa razão.

2. Abuso de acessibilidade

A API de acessibilidade do Android foi criada para que softwares assistivos possam ler a tela e agir em nome do usuário. É exatamente a capacidade que um atacante quer.

Com um serviço de acessibilidade concedido, o malware pode ler o conteúdo de qualquer janela — inclusive códigos de uso único —, descartar caixas de diálogo de permissão automaticamente, conceder a si mesmo mais permissões sem intervenção do usuário e impedir a própria desinstalação interceptando a tela de configurações.

A distinção que importa na triagem é entre um aplicativo que declara um serviço de acessibilidade e outro cujo código demonstra que usa a API para tocar, ler campos e navegar. A declaração isolada aparece em software legítimo. O padrão de uso não.

3. Interceptação de SMS

Se uma transação exige um código enviado por SMS, o trojan precisa lê-lo antes da vítima, ou no lugar dela.

Duas capacidades aparecem aqui: ler as mensagens recebidas e encaminhá-las para um número ou endpoint do operador. O encaminhamento é o sinal mais forte, porque não tem explicação benigna plausível em um aplicativo que não é cliente de SMS.

Desde que o Android restringiu as permissões de SMS na Play, essa capacidade chega cada vez mais acompanhada de um pedido para ser o aplicativo de SMS padrão, o que a concede por inteiro. Uma via paralela evita o SMS por completo: um listener de notificações lê o código na própria notificação, o que cobre os códigos entregues por push.

4. Entrega em estágios

Famílias maduras não incluem a carga útil no APK instalado. O primeiro estágio é pequeno, pede pouco e passa pela revisão. Uma vez em execução, baixa a carga real e a carrega em tempo de execução.

Isso derrota qualquer análise limitada ao arquivo instalado, que é a maior parte da varredura automatizada. Um relatório estático ainda consegue capturá-lo: carregamento dinâmico de código por DexClassLoader ou PathClassLoader sobre um arquivo baixado, uma URL de download embutida, um blob de alta entropia em assets/ que o manifesto não explica, e um pedido para instalar pacotes de origem desconhecida são todos visíveis sem executar nada.

Um sinal de dropper em um aplicativo que se apresenta como produto bancário merece escalonamento por si só, independentemente do que o primeiro estágio faça.

O conjunto de permissões

As capacidades acima se traduzem em um grupo concreto e reconhecível de declarações do manifesto:

Nenhuma é conclusiva isoladamente. Todas têm usuários legítimos. O conjunto como grupo não tem nenhuma categoria de aplicativo legítima.

Persistência

Outras duas capacidades aparecem em muitas famílias e vale anotá-las porque mudam a resposta ao incidente, não apenas a classificação.

Administrador de dispositivo. Um aplicativo registrado como administrador resiste à desinstalação pela via normal. Removê-lo exige revogar antes essa permissão, que é justamente o que o serviço de acessibilidade é usado para impedir.

Combinação com acessibilidade. Administrador de dispositivo mais abuso de acessibilidade é o par que transforma um achado de malware em uma decisão de reinstalar o dispositivo. O usuário não consegue removê-lo de forma confiável sozinho, e uma orientação de suporte que pressuponha uma desinstalação normal vai falhar na frente do cliente.

O que a combinação significa

O Droidwatch acompanha oito sinais bancários distintos, e a pontuação reflete que o peso está nas combinações:

Um relatório que lista a permissão de sobreposição e nada mais descreve um aplicativo de mensagens. Um relatório que lista sobreposição com detecção de primeiro plano, uso de acessibilidade, encaminhamento de SMS e um dropper descreve um trojan bancário, e a confiança vem da interseção, não de qualquer item isolado.

Correspondência com o ATT&CK

Cada capacidade corresponde a uma técnica do MITRE ATT&CK Mobile, e o Droidwatch mapeia os achados para técnicas de modo que o relatório se encaixe em um programa de detecção existente em vez de ficar ao lado dele:

Esse mapeamento é a diferença entre um relatório que diz isto é ruim e um sobre o qual um engenheiro de detecção pode agir: o identificador de técnica é o vocabulário comum entre a análise e os controles que deveriam capturá-lo da próxima vez.

Onde a identidade vem primeiro

Antes de tudo isso, há uma pergunta que se resolve mais rápido e de forma mais conclusiva: o aplicativo é o que afirma ser?

Um pacote que imita um banco, assinado com um certificado que não coincide com o da Google Play, é um incidente de reempacotamento. Esse achado não exige análise de comportamento e cabe no mesmo dia à proteção de marca, porque o canal de distribuição continua ativo.

O Droidwatch verifica a identidade do pacote contra a Play e examina o certificado de assinatura dentro da mesma análise. A reutilização de certificados entre aplicativos aparentemente sem relação é frequentemente o pivô mais produtivo obtido de uma única amostra, porque conecta campanhas que não compartilham mais nada.

Distribuição

O conjunto de capacidades explica o que o malware faz depois de instalado. Não explica como ele chega, e nos mercados de língua portuguesa e espanhola as vias de entrega são constantes o bastante para serem enunciadas:

• Smishing com pretexto de atualização. Uma mensagem afirmando que o aplicativo do banco exige uma atualização obrigatória, com link para um pacote fora da Play.
• Instalação guiada por telefone. Alguém que diz ligar do departamento de fraudes da instituição acompanha a vítima enquanto ela ativa a instalação de origens desconhecidas e concede a permissão de acessibilidade. Essa via derrota quase todos os avisos do dispositivo, porque há alguém orientando a vítima a ignorá-los em tempo real.
• Lojas alternativas e sites agregadores. Versões reempacotadas de aplicativos bancários legítimos, frequentemente com nome e ícone corretos e um certificado de assinatura incorreto.

As três compartilham uma propriedade relevante para a defesa: o pacote malicioso nunca passa pelo pipeline de publicação da instituição. Detectá-lo é um problema de monitoramento, não de construção.

O que a análise estática estabelece, e o que não

Tudo o que foi descrito é visível sem executar a amostra. A análise estática estabelece capacidade: o que o aplicativo é capaz de fazer.

Não estabelece comportamento. Um aplicativo capaz de interceptar SMS pode nunca fazê-lo, ou fazê-lo apenas mediante instrução do seu servidor de comando e controle. Quando uma decisão depende do comportamento em execução é necessária análise dinâmica, e no Droidwatch ela é somente Android, executando contra o dispositivo ou emulador do próprio cliente por meio do agente do Droidwatch, disponível a partir do plano Pro. Nenhuma amostra executa na infraestrutura do Droidwatch.

Para fins de triagem essa distinção raramente bloqueia uma decisão. Um pacote que reúne o conjunto completo de capacidades, assinado com um certificado que não coincide com o da instituição que afirma representar, não precisa de confirmação em execução para justificar o escalonamento. O fluxo de triagem estabelece as seis etapas que produzem essa classificação, e o percurso do relatório explica onde cada peça de evidência aparece.

Os indicadores extraídos das amostras analisadas na plataforma são publicados no threat feed público sob licença CC BY 4.0.

Tem uma amostra? Envie um APK. Não é necessário meio de pagamento.