O banco viu um aparelho novo. Era o mesmo celular, em outro perfil.

O antifraude bancário em celular funciona, em boa medida, por correlação. O SDK de segurança embarcado no aplicativo observa o aparelho, identifica indício de malware, marca o dispositivo, e o motor de risco liga esse sinal à transação que veio depois. Quando a ligação existe, dá para bloquear.

O que a Group-IB documentou é uma forma barata de cortar essa ligação no meio.

A cadeia, na ordem em que acontece

A entrega é a de sempre e continua funcionando porque não depende de falha nenhuma. Site de phishing, mensagem direta em aplicativo de conversa, anúncio em rede social. O arquivo se apresenta como aplicativo de companhia aérea, de órgão arrecadador ou de serviço público, e é instalado fora da loja oficial.

Na primeira abertura, o Gigabud pede três permissões: acessibilidade, desenho sobre outros aplicativos e isenção de economia de bateria. A Group-IB é direta sobre qual delas importa: conceder acessibilidade é o instante em que o operador ganha controle real do aparelho.

Em seguida o malware envia a lista completa de aplicativos instalados. Não é coleta genérica, é seleção de alvo. O operador descobre com qual banco a vítima se relaciona e passa a atacar aquele banco, em vez de tentar todos.

A partir daí a captura é convencional. Tela falsa de login sobreposta ao aplicativo real quando a vítima o abre, e uma sobreposição invisível que registra o código de desbloqueio do aparelho.

A parte nova vem depois. O operador manda instalar o Vwork. O Vwork provisiona um perfil de trabalho. O Gigabud envia o comando de clonagem e uma versão modificada do aplicativo do banco é instalada dentro desse perfil. Em pelo menos um caso confirmado, a cópia era a de um banco indonésio real.

A fraude ocorre com o operador executando a transação no próprio aparelho da vítima, por automação de toques e injeção de texto via acessibilidade, com uma tela preta cobrindo o que está acontecendo e o áudio silenciado.

Por que o isolamento do perfil vira vantagem do atacante

Aqui está o ponto que vale levar para a reunião.

Aplicações instaladas em um perfil do Android são isoladas das de outro perfil, e isso vale principalmente para detecção baseada em assinatura. Malware identificado no perfil pessoal não dispara alerta equivalente no perfil de trabalho, ainda mais quando esse perfil foi criado depois da infecção.

Os operadores exploram exatamente essa assimetria. Infectam o perfil pessoal e não fazem nada ali. O banco pode até detectar atividade suspeita, mas sem perda financeira associada o alerta tende a morrer na fila. Depois criam o perfil de trabalho, clonam o aplicativo e transacionam de lá.

Do ponto de vista do banco, a transação parte de um aparelho novo, sem histórico de infecção, aparentemente sem relação com o alerta anterior. A frase da Group-IB resume bem: os fraudadores conseguem romper o vínculo entre o sinal de detecção de malware e a transação fraudulenta.

A Group-IB relata que trata dois ou mais desses sinais na mesma sessão como risco alto, suficiente para bloquear a transação de forma direta. Vale reter a lógica: nenhum sinal isolado decide, a combinação decide, e todos eles aparecem antes do primeiro centavo sair.

O que isso significa para o Brasil

Um alerta e uma ressalva, nessa ordem.

A ressalva primeiro, porque importa para a qualidade da conversa. A cadeia completa, com Gigabud e Vwork rodando juntos em aparelho real, foi confirmada apenas na Indonésia, e todos os números de perda são de lá. Para Brasil, Colômbia e México o que existe são amostras do Gigabud preparadas para operar com o Vwork. É evidência de intenção e de capacidade, não de vítima contabilizada.

Dito isso, o alerta. O Brasil é um dos mercados mais maduros do mundo em pagamento instantâneo e em aplicativo bancário, o que significa que é também um dos mercados onde o antifraude em dispositivo carrega mais peso na decisão de aprovar transação. Técnica que ataca especificamente a correlação entre sinal de dispositivo e transação tem, aqui, um retorno maior do que teria em mercado onde a transferência ainda depende de etapa fora do celular.

Some a isso o vetor de entrada, que é o de sempre no país: aplicativo falso de órgão público ou de instituição financeira distribuído por mensagem, instalado fora da loja oficial, com o usuário concedendo acessibilidade porque a tela pediu.

Leitura LATAMSEC

Para instituição financeira: a pergunta objetiva é se o motor de risco enxerga em qual perfil do Android a sessão está rodando, e se consegue ligar duas sessões do mesmo aplicativo em perfis diferentes do mesmo aparelho. Se a resposta for não, a técnica funciona contra o seu antifraude independentemente da qualidade do resto do controle.

Para quem define controle de transação: vínculo de login a dispositivo confiável e assinatura por chave interrompem a cadeia mesmo quando a etapa anterior passou despercebida, porque impedem que credencial roubada autorize operação em ambiente controlado pelo atacante. É o controle que sobrevive ao clone.

Para a área de comunicação com o cliente: a orientação que funciona é específica, não genérica. Aplicativo legítimo nunca é distribuído como arquivo dentro de conversa, e acessibilidade não deve ser concedida a nada que não seja ferramenta de acessibilidade. Recomendação vaga sobre desconfiar de links não altera comportamento.

Para o comitê de risco: este caso é um lembrete de que recurso legítimo de plataforma vira ferramenta ofensiva sem precisar de falha. O perfil de trabalho do Android funcionou exatamente como documentado. Quem adaptou o uso foi o atacante, e não há correção a aplicar.