A operação manteve campanhas desde 2016 com 82 aplicativos-isca, coleta estruturada de dados pessoais, execução remota de comandos e comunicação com servidores de comando e controle.
| Componente | Aplicativos Android maliciosos da operação Domestic Kitten, incluindo gerações associadas a com.memopt, com.andriod, com.eracomteck e example.badoo. |
| Vetor | APKs disfarçados com temas religiosos, políticos, sociais ou genéricos, usados como isca para públicos específicos e possivelmente baseados em aplicativos legítimos modificados. |
| Impacto | Coleta de dados pessoais, registros estruturados, arquivos, gravações, contas de redes sociais, dumps do sistema e capacidade de execução remota de comandos em dispositivos infectados. |
| Prioridade | Restringir instalação de APKs fora de lojas confiáveis, revisar dispositivos com aplicativos suspeitos, monitorar tráfego para infraestrutura de comando e controle e conter aparelhos com sinais de coleta persistente. |
| Artefatos | Foram observados 82 aplicativos maliciosos, codenames internos definidos pelo operador, banco MemOptDB.sql, identificadores de dispositivo usados em logs e comunicação com porta 2030 em variante recente. |
| IoCs | Exemplos defangados citados incluem ageofcyber[.]com/brw e ychatonline[.]net; o uso deve ser validado contra telemetria histórica e não tratado como lista completa. |
Domestic Kitten foi uma operação de espionagem móvel baseada em aplicativos Android maliciosos, ativa pelo menos desde 2016, com foco em coleta de informações de alvos cuidadosamente segmentados. O conjunto observado reúne 82 aplicativos usados como isca, com nomes e conteúdos desenhados para atrair públicos diferentes, incluindo falantes de persa, falantes de árabe, grupos políticos, minorias regionais, usuários interessados em temas religiosos e vítimas atraídas por títulos genéricos. A campanha não se limitava a instalar um coletor simples: as amostras analisadas mostram gerações distintas, evolução de funcionalidades, mudanças em comunicação com servidor, maior obfuscação e controle remoto sobre o dispositivo comprometido.
A operação se destaca pela documentação interna mantida pelos operadores. Além do nome exibido à vítima, cada aplicativo trazia um codename embutido usado nos registros coletados. Esses identificadores ajudavam a separar campanhas, públicos e possivelmente objetivos operacionais. Em alguns casos, aplicativos com temas muçulmanos receberam codenames associados a Daesh, o que sustenta a hipótese de segmentação contra apoiadores, ativistas ou indivíduos de interesse ligados a esse recorte. Essa inferência vem do alinhamento entre tema da isca, codename e organização dos dados, mas não deve ser lida como confirmação independente de filiação das vítimas.
A coleta documentada envolvia dados privados e arquivos obtidos dos dispositivos infectados. O material observado inclui registros estruturados, arquivos enviados pelos aparelhos, gravações, contas e endereços de e-mail vinculados a plataformas sociais, além de dumps completos de sistema em alguns casos. A operação também monitorava interações que expõem terceiros, como chamadas telefônicas e mensagens SMS, ampliando o impacto para contatos das vítimas. Indicadores linguísticos, como exceções em persa e erros gramaticais em inglês dentro do código, sustentam a avaliação de origem iraniana dos operadores, mas esse tipo de evidência permanece circunstancial e deve ser tratado com cautela em atribuição formal.
A cadeia começa com aplicativos Android apresentados como conteúdo legítimo ou útil para públicos específicos. Parte dos títulos observados coincidia com aplicativos legítimos disponíveis em lojas, canais de distribuição ou sites de APK, o que sugere a possibilidade de versões adulteradas com código malicioso embutido. Esse modelo é especialmente eficaz em ambientes onde a instalação por fontes alternativas é comum por restrições regionais, sanções, disponibilidade limitada de lojas oficiais ou hábito de compartilhamento direto de pacotes. A isca não depende apenas de engenharia social genérica; ela explora idioma, religião, interesse político e identidade cultural para reduzir suspeitas durante a instalação.
A geração com.memopt, associada a 2016, já reunia coleta de dados e execução remota de comandos. Os comandos eram mantidos em um banco SQL chamado MemOptDB.sql, localizado nos ativos do aplicativo, com identificadores únicos, agendamento de execução e opção de compactação dos resultados antes do envio. A variante também tinha um canal de comando por SMS que duplicava parte das funções, ampliando resiliência operacional quando o canal de rede não estivesse disponível. Para defesa, o ponto central é que o aplicativo comprometido não apenas exfiltra dados sob demanda; ele também pode receber instruções posteriores e executar ações no aparelho conforme decisão do operador.
A geração com.andriod adicionou funcionalidades e manteve baixa obfuscação. O código continha classes com valores padrão, como endereço de servidor, codename, versão, extensões de mídia e comandos, mas algumas variáveis pareciam remanescentes de versões anteriores e não eram usadas no fluxo final. Em uma amostra, ageofcyber[.]com/brw aparecia como valor definido, enquanto a comunicação efetiva era configurada para ychatonline[.]net. Esse tipo de resíduo é relevante para análise reversa porque mostra reaproveitamento de código e transição entre infraestruturas, mas não deve ser usado isoladamente para afirmar atividade atual de um domínio.
As variantes mais recentes, ligadas a com.eracomteck e example.badoo, introduziram obfuscação mais forte, camadas de proteção contra inspeção de strings e comunicação mais complexa com o servidor. Strings, incluindo endereço de servidor, eram transformadas por algoritmo simples e depois codificadas, enquanto caracteres da comunicação eram combinados com valores de uma matriz de bytes. A classe BootReceiver iniciava um serviço de heartbeat e enviava dados da operadora móvel em intervalos curtos. Outro componente escutava eventos capazes de despertar o aplicativo e registrava receptores dinâmicos para chamadas de saída e presença do usuário. A variante também acionava temporizadores para módulos responsáveis por coletar diferentes classes de informação.
O armazenamento dos dados evoluiu entre gerações. Nas versões anteriores, os logs eram separados por tipo de dado. Na versão mais recente descrita, múltiplas categorias passaram a ser consolidadas em um único arquivo separado por vírgulas, com identificadores próprios para cada tipo. Depois da coleta, o log correspondente era compactado, criptografado, enviado ao servidor e removido do dispositivo. A variante recente também aceitava comandos por conexão à porta 2030. O detalhe defensivo importante é a combinação de persistência por eventos do sistema, coleta recorrente, empacotamento local temporário e limpeza posterior, que reduz artefatos residuais no aparelho e desloca a evidência principal para telemetria de rede, backups, logs de instalação e análise forense de memória ou armazenamento.
A superfície afetada é composta por dispositivos Android nos quais usuários instalaram APKs maliciosos disfarçados. O risco é maior quando a organização permite instalação por fontes desconhecidas, não controla inventário de aplicativos, não aplica política de gerenciamento móvel ou não inspeciona tráfego de dispositivos corporativos e pessoais usados em trabalho sensível. Como as iscas incluíam temas políticos, religiosos, culturais e genéricos, a exposição não se limita a um setor. O padrão favorece alvos humanos de valor para inteligência, como ativistas, grupos minoritários, usuários com vínculos regionais, perfis acadêmicos, contatos políticos e pessoas em ecossistemas onde canais informais de distribuição de APK são comuns.
Os dados em risco incluem metadados e conteúdo do aparelho, informações de chamadas, mensagens SMS, arquivos, gravações, contas e endereços associados a redes sociais, além de listagens completas de arquivos em dumps de sistema. Em aparelhos pessoais usados para comunicação profissional, esse alcance pode expor contatos, fontes, rotinas, localização indireta e relações sociais. A presença de gravações de voz criptografadas em servidores mostra que a coleta podia alcançar mídia sensível; em versões novas, gravações de dez minutos foram observadas, enquanto versões antigas registravam apenas trechos curtos.
A atribuição técnica deve permanecer separada da resposta operacional. Exceções em persa, nomes internos, temas dos aplicativos e erros linguísticos no código sustentam uma hipótese de autoria regional, mas a contenção não depende de confirmação de sponsor estatal. Para defesa, o foco deve ser identificar aplicativos com nomes isca, pacotes suspeitos, permissões excessivas, comunicação com domínios defangados relacionados ao caso, uso de canais alternativos de comando, criação de logs temporários compactados e comportamento de coleta após eventos de inicialização, presença do usuário ou chamada telefônica.
- Dispositivos Android com instalação de APKs por fontes externas ou canais de compartilhamento informal.
- Usuários atraídos por aplicativos com temas persas, árabes, religiosos, políticos, culturais ou nomes genéricos de utilidade.
- Aplicativos com permissões incompatíveis com sua função aparente, especialmente acesso a SMS, chamadas, arquivos, gravação e identificadores do dispositivo.
- Ambientes sem MDM, inventário de aplicativos, bloqueio de fontes desconhecidas ou inspeção de tráfego móvel.
A busca deve combinar inventário de aplicativos, análise de permissões, telemetria de rede e revisão forense de dispositivos suspeitos. Em MDM ou EDR móvel, priorize pacotes que não estejam em catálogo aprovado, aplicativos instalados fora de lojas oficiais, nomes que imitam serviços de atualização ou VPN, e apps com tema incompatível com o perfil corporativo do usuário. Pacotes associados às gerações descritas, como com.memopt, com.andriod, com.eracomteck e example.badoo, devem ser tratados como sinais de alto risco quando encontrados, mas a ausência desses nomes não elimina exposição porque a operação usou dezenas de aplicativos e codenames diferentes.
Na rede, procure padrões de comunicação periódica com infraestrutura externa, envio de arquivos compactados ou criptografados a partir de dispositivos móveis, conexões incomuns para porta 2030 e tráfego para domínios relacionados ao caso em telemetria histórica. Indicadores como ageofcyber[.]com/brw e ychatonline[.]net devem ser consultados de forma defangada e correlacionados com data, resolução DNS, agente de usuário, volume transferido e dispositivo de origem. Como alguns servidores podem estar inativos ou reaproveitados, a caça não deve depender apenas de bloqueio por domínio; comportamento e artefatos locais são mais robustos.
No endpoint, busque bancos ou arquivos temporários relacionados a comandos, logs com identificadores de dispositivo, arquivos compactados criados antes de conexões externas, serviços iniciados em boot e receptores associados a chamadas de saída ou presença do usuário. A análise de APK deve verificar strings codificadas, rotinas simples de transformação com Base64, uso de XOR em comunicação, classes responsáveis por dumpers de dados e referências a operadora móvel enviadas em heartbeat. Em investigações com aparelhos já isolados, compare permissões solicitadas, data de instalação, origem do instalador, hashes dos APKs internos e comportamento de limpeza de logs após envio.
- Aplicativos Android fora do catálogo aprovado com permissões para SMS, chamadas, gravação, arquivos e execução em segundo plano.
- Conexões periódicas de dispositivos móveis para infraestrutura externa, especialmente com upload de arquivos compactados ou criptografados.
- Tráfego histórico para
ageofcyber[.]com/brw,ychatonline[.]netou conexão incomum pela porta 2030, sempre com validação temporal. - Artefatos locais como
MemOptDB.sql, identificadores de dispositivo em nomes de log, timers de coleta e receptores ativados por boot, chamadas ou presença do usuário.
A resposta deve começar pela redução da superfície de instalação. Organizações com usuários em regiões ou funções sensíveis devem bloquear fontes desconhecidas, exigir loja aprovada, aplicar MDM, manter inventário de aplicativos e remover apps que não tenham justificativa de negócio. Para perfis de alto risco, o controle precisa incluir revisão periódica de permissões, detecção de sideloading, alertas para aplicativos recém-instalados com acesso a SMS e gravação, e separação entre dispositivos pessoais e comunicações institucionais sensíveis.
Quando um dispositivo apresentar sinais compatíveis, a prioridade é preservar evidências antes de apagar o aplicativo. Isole a rede do aparelho, registre lista de apps, permissões, data de instalação, origem do APK, conexões recentes e arquivos temporários relevantes. Em seguida, redefina credenciais usadas no dispositivo, revogue sessões de redes sociais e serviços corporativos, revise contatos potencialmente expostos e avalie se mensagens, chamadas ou gravações podem ter alcançado terceiros. A remoção simples do APK pode eliminar parte dos artefatos, mas não responde à exposição de contas e comunicações já coletadas.
A mitigação de rede deve incluir bloqueio e monitoramento de indicadores defangados relacionados ao caso, mas com cuidado para não tratar uma lista curta como cobertura total. Regras comportamentais são mais úteis: upload recorrente de arquivos a partir de dispositivos móveis, comunicação para domínios recém-observados, conexões para portas incomuns e tráfego iniciado por aplicativos sem reputação. Em paralelo, equipes de threat intel devem enriquecer amostras internas de APK, extrair codenames, comparar permissões, mapear infraestrutura e manter histórico de resoluções para apoiar investigação retrospectiva.
Para usuários expostos a iscas temáticas, a orientação deve ser operacional e verificável: instalar apenas aplicativos de canais aprovados, recusar pacotes recebidos por mensagens, validar desenvolvedor e permissões, e reportar aplicativos que imitam serviços de sistema ou prometem conteúdo sensível. Em ambientes corporativos, a política deve ser reforçada por controle técnico, porque a campanha explora confiança cultural e regional. O objetivo defensivo é impedir instalação inicial, detectar coleta silenciosa cedo e reduzir o tempo entre comprometimento, contenção e rotação de credenciais.
- Bloquear sideloading e permitir apenas lojas ou repositórios aprovados por política móvel.
- Isolar dispositivos suspeitos antes da limpeza para preservar inventário, permissões, APKs, logs e conexões recentes.
- Revogar sessões e trocar credenciais usadas no aparelho, incluindo contas sociais e serviços corporativos acessados pelo dispositivo.
- Monitorar comportamento de upload, comunicação periódica, porta 2030 e domínios defangados relacionados, sem depender apenas de IoCs estáticos.
- Revisar permissões de aplicativos com temas religiosos, políticos, culturais, VPN, atualização de serviços ou nomes genéricos fora do catálogo aprovado.
0 Comentários