FakeCalls usa apps bancários falsos no Android para phishing por voz na Coreia do Sul

Trojan se passa por mais de 20 aplicativos financeiros, manipula chamadas telefônicas, usa evasões em APK e pode transmitir áudio e vídeo para servidores de comando e controle.

Componente	Trojan Android FakeCalls distribuído como aplicativo financeiro falso e estruturado com dropper, payload embarcado e comunicação com servidores de comando e controle.
Vetor	Instalação de APK que imita mais de 20 aplicativos de bancos e serviços financeiros, seguida de engenharia social por phishing de voz durante supostas interações bancárias.
Impacto	Manipulação da percepção da chamada, coleta de dados financeiros privados, uso de áudios pré-gravados e capacidade de transmitir áudio e vídeo do dispositivo para infraestrutura remota.
Prioridade	Remover aplicativos bancários fora de canais oficiais, revisar permissões sensíveis em Android, procurar APKs com evasões estruturais e bloquear comunicação com resolvers e C&C associados.
Artefatos	Mais de 2500 amostras foram observadas com combinações diferentes de instituições financeiras imitadas e técnicas de anti-análise no empacotamento APK.
IoCs	A infraestrutura foi escondida por dead drop resolvers em serviços legítimos e documentos remotos; mais de 100 endereços IP únicos foram identificados a partir dessas configurações.

Resumo técnico

FakeCalls é um Trojan para Android voltado ao mercado financeiro sul-coreano que combina aplicativo bancário falso, phishing por voz e recursos de espionagem do dispositivo. A operação se apoia em imitação de marcas financeiras de grande porte: as amostras analisadas se apresentam como mais de 20 aplicativos ligados a bancos ou serviços de pagamento, explorando a confiança do usuário em uma interface que parece pertencer a uma instituição reconhecida. O objetivo central é conduzir a vítima para uma interação telefônica controlada pelo operador, na qual uma suposta oferta de empréstimo com taxa menor serve como pretexto para obter dados financeiros privados.

O ponto técnico mais relevante é que o malware não depende apenas de uma tela falsa. Ele interfere na experiência de chamada e pode fazer o usuário acreditar que está falando com um número bancário legítimo. Durante a conversa, o número desconhecido associado aos operadores é substituído visualmente por um número real de banco, reduzindo a suspeita no momento em que a vítima é induzida a confirmar detalhes de cartão ou outros dados financeiros. Algumas amostras também trazem faixas de áudio pré-gravadas que simulam instruções de funcionários, com variações conforme a organização financeira imitada.

A campanha também mostra investimento em resistência à análise. Mais de 2500 amostras foram encontradas com diferentes combinações de marcas imitadas e técnicas de evasão. O empacotamento APK foi manipulado para quebrar fluxos comuns de decompilação e inspeção, incluindo alterações em metadados ZIP, inconsistências em AndroidManifest e arquivos em caminhos longos dentro de diretórios aninhados. Essas escolhas não mudam o impacto final para a vítima, mas aumentam o custo de engenharia reversa, atrasam a extração do payload e dificultam a automação em pipelines de análise de malware.

Fluxo técnico

A cadeia começa com a instalação de um APK que se apresenta como aplicativo financeiro. Após a instalação, a vítima encontra uma interface coerente com a identidade bancária falsificada e não recebe, nesse estágio, um sinal óbvio de que há componentes ocultos. O ataque avança quando o usuário é conduzido a uma chamada ou a uma simulação de atendimento. O operador explora um contexto financeiro plausível, como solicitação de empréstimo, para criar urgência e confiança. A substituição visual do número exibido no aparelho é essencial: ela conecta a narrativa do aplicativo falso a um identificador que parece pertencer ao banco real.

O FakeCalls usa uma arquitetura em etapas. O payload principal não é executado imediatamente; um dropper funciona como intermediário. O malware registra um BroadcastReceiver para eventos de instalação de aplicativo, e esse componente é usado para acionar posteriormente o APK derrubado no dispositivo. O arquivo do payload fica dentro da pasta de assets e é copiado durante o carregamento dos componentes de visualização. Depois que a instalação do payload é concluída, o aplicativo é iniciado com uma configuração obtida em tempo de execução, permitindo separar a etapa de entrega da etapa operacional.

Além da fraude por voz, o malware inclui capacidade de transmissão de áudio e vídeo ao vivo para servidores de comando e controle. A funcionalidade usa uma biblioteca aberta de streaming RTMP/RTSP e instancia um objeto RtspCamera2 com parâmetros de autenticação e configuração de mídia, como taxa de bits, quadros por segundo e cancelamento de ruído. O fluxo pode selecionar a câmera frontal, iniciar transmissão remota e encerrar a sessão após cinco minutos. O C&C também pode enviar estado para iniciar ou parar serviços de áudio e vídeo, além de alternar a câmera durante a transmissão.

A comunicação de rede evita expor diretamente a infraestrutura principal. Em uma variante, o APK contém uma string criptografada com referência a um arquivo em Google Drive; esse arquivo guarda o nome de outro artefato que, após descriptografia por chave AES embutida, revela a configuração real de C&C. Em outra variante, o malware usa um link criptografado para um resolver web arbitrário contendo um documento com configuração de servidores também criptografada. Essa técnica de dead drop resolver usa serviços legítimos como intermediários para ocultar domínios e endereços reais, dificultando bloqueios simples baseados apenas no binário inicial.

Superfície afetada

A superfície exposta concentra-se em dispositivos Android nos quais o usuário instala aplicativos fora de um processo confiável de validação ou aceita um APK que imita uma instituição financeira. O contexto observado é direcionado à Coreia do Sul, com seleção de organizações bancárias e financeiras de alto reconhecimento local. A escolha do alvo importa tecnicamente porque aumenta a probabilidade de a vítima já ter relacionamento com a marca imitada, reduzindo a fricção psicológica para conceder permissões, iniciar chamadas ou acreditar em um atendimento telefônico fraudulento.

Os ambientes de risco incluem aparelhos pessoais usados para transações bancárias, dispositivos corporativos com permissão para instalar aplicativos externos e programas de BYOD sem controle de reputação de APK. A ameaça também interessa a equipes de resposta em instituições financeiras, porque a fraude se apoia na confiança da marca, mesmo quando a infecção ocorre fora da infraestrutura do banco. Para defesa, a superfície não se limita ao endpoint: há sinais em telemetria de instalação, permissões de câmera e microfone, tráfego para serviços legítimos usados como resolvers, conexões RTSP/RTMP e relatos de usuários sobre chamadas suspeitas com números visualmente associados a bancos.

As técnicas de anti-análise ampliam a superfície operacional para laboratórios de malware. Ferramentas de engenharia reversa podem falhar ao carregar amostras se não tratarem corretamente campos ZIP manipulados, contagem de strings inconsistente no manifesto ou arquivos com caminhos muito longos. Isso afeta processos de sandbox, enriquecimento automático e geração de indicadores. A defesa precisa considerar que uma amostra que falha na decompilação não é necessariamente corrompida; ela pode ter sido preparada para interromper exatamente esse tipo de inspeção.

• Dispositivos Android com instalação de APK bancário falso e permissões sensíveis concedidas a aplicativos não verificados.
• Usuários expostos a ofertas financeiras falsas, principalmente empréstimos com juros reduzidos, dentro de uma interação de phishing por voz.
• Laboratórios e sandboxes que dependem de parsing estrito de APK, AndroidManifest e estruturas ZIP sem normalização prévia.

Hunting e telemetria

A investigação deve começar pelo inventário de aplicativos Android instalados, com foco em pacotes que imitam bancos, sistemas de pagamento ou serviços financeiros e que não correspondem ao canal oficial de distribuição da instituição. Em MDM, EDR móvel ou coleta forense, procure APKs que contenham payload adicional em assets, registro de BroadcastReceiver ligado a eventos de instalação e comportamento de cópia de APK durante o carregamento da interface. A presença de um aplicativo visualmente bancário com lógica de dropper é um sinal forte, porque aplicações legítimas não costumam instalar silenciosamente outro APK a partir de assets internos.

Na camada de permissões e comportamento, priorize eventos envolvendo microfone, câmera frontal, serviços de áudio e vídeo e conexões compatíveis com streaming. O FakeCalls pode iniciar ou encerrar transmissão conforme uma variável de estado recebida do C&C, então o hunting precisa correlacionar permissões sensíveis com tráfego de rede e alterações rápidas de serviço. Sessões curtas de vídeo para destinos desconhecidos, especialmente após interação com aplicativo financeiro recém-instalado, merecem contenção imediata. Quando houver proxy, DNS ou inspeção de tráfego móvel, procure acessos a documentos remotos usados como resolvers e conexões subsequentes para infraestrutura diferente daquela consultada inicialmente.

Para análise estática, a triagem deve aceitar que o APK pode ter campos ZIP intencionalmente alterados. Uma evasão usa valores anômalos de disco e entradas no final do diretório central, fazendo a amostra parecer incompatível com ferramentas que esperam arquivos ZIP convencionais. Outra afeta o AndroidManifest, alterando valores de magic number, offsets e contagem de strings para quebrar a decodificação. Uma terceira adiciona grande volume de arquivos em diretórios aninhados dentro de assets, produzindo nomes e caminhos superiores a 300 caracteres. Esses sinais devem ser registrados como indicadores de empacotamento hostil, não descartados como erro de coleta.

• APK financeiro com payload embarcado em assets e execução posterior por BroadcastReceiver associado a eventos de instalação.
• Permissões de câmera e microfone combinadas com serviços de streaming RTMP/RTSP e seleção da câmera frontal.
• Acesso a dead drop resolvers em serviços legítimos seguido de comunicação com servidores de comando e controle criptografados ou resolvidos em tempo de execução.
• Falhas repetidas de decompilação causadas por metadados ZIP alterados, AndroidManifest inconsistente e caminhos de arquivo excessivamente longos.

Mitigação

A resposta deve remover imediatamente qualquer APK financeiro não verificado, revogar permissões sensíveis e isolar o dispositivo quando houver indício de streaming, coleta de dados financeiros ou comunicação com C&C. Em ambiente corporativo, políticas de MDM devem bloquear instalação por fontes desconhecidas, restringir sideloading e permitir apenas aplicativos bancários obtidos de lojas oficiais ou catálogos gerenciados. Para usuários afetados, a contenção técnica precisa ser acompanhada de medidas financeiras: comunicação com a instituição imitada, bloqueio preventivo de cartões ou credenciais expostas e revisão de transações recentes quando houver confirmação de interação com o falso atendimento.

Instituições financeiras podem reduzir o impacto com monitoramento de abuso de marca, canais claros de verificação de chamadas e detecção de jornadas anômalas associadas a empréstimos. Como o malware manipula a percepção do número telefônico e usa áudio pré-gravado ou operador remoto, o controle defensivo não deve depender apenas de o usuário reconhecer o identificador da chamada. Mensagens educativas precisam orientar que dados de cartão e autenticação não sejam confirmados em chamadas iniciadas a partir de aplicativos não verificados, sem transformar a orientação em roteiro operacional para fraudadores.

Para equipes de segurança, a mitigação técnica inclui atualizar regras de análise para tolerar APKs com estruturas manipuladas, enriquecer amostras que falham em ferramentas comuns e registrar padrões de evasão como parte da classificação. Bloqueios de rede devem tratar dead drop resolvers com cuidado, pois serviços legítimos podem ser usados como intermediários; a decisão precisa correlacionar URL, aplicativo chamador, tempo de instalação, descriptografia de configuração e destino final. Quando indicadores forem extraídos, prefira distribuir classes de infraestrutura, hashes de amostras confirmadas em canais internos e domínios ou IPs defangados, evitando publicação ampla de listas operacionais sem contexto.

A validação final deve confirmar a ausência do pacote malicioso, a remoção do payload derrubado, a interrupção de serviços de streaming e a inexistência de persistência ligada a receptores de eventos. Em dispositivos corporativos, revise registros de instalação, concessão de permissões, uso de câmera, uso de microfone e conexões de rede no período próximo ao primeiro alerta. Quando a vítima informou dados financeiros durante a chamada, trate o caso como fraude em andamento e acione procedimentos de proteção de conta, porque a finalidade do FakeCalls é justamente transformar confiança visual e voz convincente em coleta de informações privadas.

• Bloquear instalação de APKs por fontes desconhecidas e aplicar catálogo gerenciado para aplicativos financeiros em dispositivos administrados.
• Revogar permissões de câmera, microfone e telefone de aplicativos suspeitos antes da remoção e preservar artefatos quando houver investigação forense.
• Correlacionar acessos a resolvers remotos, tráfego de streaming e execução de payload a partir de assets para diferenciar falso positivo de infecção ativa.
• Ajustar sandboxes e pipelines de engenharia reversa para tratar evasões em ZIP, AndroidManifest e caminhos longos sem descartar automaticamente a amostra.