OSX/Dok amplia fraude bancária contra usuários de macOS com proxy local e certificados Apple

O malware usa phishing, certificados de desenvolvedor, alteração de configurações do sistema e redirecionamento de tráfego bancário para páginas falsas capazes de capturar credenciais e apoiar fraude financeira.

Componente	OSX/Dok em macOS, com pacote de aplicativo assinado por certificados de desenvolvedor Apple e nomes que imitam componentes legítimos como App1e.AppStore e iTunes.AppStore.
Vetor	Campanha de phishing direcionada a usuários de macOS, com anexo ZIP contendo o aplicativo malicioso e posterior configuração de proxy local para ataque man-in-the-middle contra sessões bancárias.
Impacto	Intercepção de comunicação, inclusive tráfego HTTPS após instalação de certificado raiz falso, redirecionamento de domínios bancários para páginas falsas e captura de credenciais usadas em fraude financeira.
Prioridade	Isolar hosts suspeitos, remover o perfil de proxy e o certificado raiz não autorizado, revisar arquivos de resolução local, revogar sessões bancárias e investigar credenciais submetidas em portais financeiros.
Artefatos	Serviço Tor local, proxy local, modificação de configurações de atualização de segurança, alteração do arquivo de hosts e uso de certificados Apple adquiridos ou abusados para contornar o Gatekeeper.
IoC	Infraestrutura Tor citada como m665veffg3tqxoza[.]onion, tratada como indicador defangado; não deve ser acessada diretamente por operadores.
Alvo	Usuários de macOS, com foco observado em residentes europeus e em clientes de bancos e entidades financeiras cujos domínios eram mapeados no arquivo de proxy.

Resumo técnico

OSX/Dok é uma família de malware para macOS voltada a fraude bancária e construída para reduzir a confiança operacional que muitos usuários ainda depositam no ecossistema Apple. A cadeia começa com phishing e entrega um aplicativo dentro de um arquivo ZIP. Depois da execução, o malware passa a manipular o próprio ambiente do sistema: altera preferências relacionadas a atualização de segurança, interfere na resolução local de nomes, instala componentes para comunicação por Tor e configura um proxy capaz de redirecionar tráfego destinado a sites financeiros. O objetivo não é apenas executar código no endpoint, mas controlar a jornada do usuário quando ele tenta acessar serviços bancários reais.

A operação se destaca pelo uso recorrente de certificados de desenvolvedor Apple para assinar os pacotes maliciosos. Esse detalhe muda a etapa inicial de defesa, porque um aplicativo assinado por certificado válido pode atravessar o Gatekeeper em configurações padrão com menos fricção do que um binário sem assinatura. Conforme certificados são revogados, novos certificados aparecem, indicando investimento contínuo em evasão e continuidade operacional. O abuso da cadeia de confiança de assinatura não torna o aplicativo legítimo, mas aumenta a chance de instalação por usuários que associam assinatura digital a segurança suficiente.

O fluxo também combina phishing com ataque man-in-the-middle. Depois de ajustar o proxy e instalar um certificado raiz falso, o malware cria condições para interceptar comunicações que normalmente seriam protegidas por TLS. A vítima pode navegar para um domínio bancário conhecido e ainda assim ser conduzida a uma página controlada pelo operador, sem receber necessariamente o alerta visual que esperaria em caso de certificado inválido. A fraude se concentra em credenciais bancárias e em etapas de autenticação, inclusive com tentativa de envolver o dispositivo móvel da vítima no processo.

Fluxo técnico

A infecção começa com uma mensagem de phishing direcionada a usuários de macOS. O anexo contém o aplicativo malicioso compactado, e a execução do pacote inicia a preparação do host para interceptação. O malware usa nomes de bundle parecidos com nomes associados ao ecossistema Apple, como App1e.AppStore e iTunes.AppStore, para aumentar a aparência de legitimidade. Em paralelo, a assinatura com certificado Apple válido reduz a probabilidade de bloqueio imediato pelo Gatekeeper quando a política local permite aplicativos assinados por desenvolvedores reconhecidos.

Após a instalação, o OSX/Dok modifica configurações de segurança e atualização por meio de comandos operacionais omitidos. O efeito defensivamente relevante é que o sistema infectado pode ficar impedido de receber atualizações ou sinais de correção de forma normal. O malware também altera o arquivo de hosts para redirecionar tentativas de contato com determinados serviços para a máquina local. Entre os destinos bloqueados ou neutralizados aparecem serviços da Apple e o VirusTotal, o que sugere tentativa de dificultar atualização, reputação, análise e resposta pelo usuário ou por ferramentas automatizadas.

A etapa seguinte cria a infraestrutura local do ataque. O malware instala serviço Tor e configura um proxy na máquina infectada. Em seguida, identifica a localização aproximada da vítima pelo endereço IP e pode entregar um arquivo de configuração de proxy apropriado para aquela região. O comportamento observado indica seleção geográfica, com foco principal em residentes europeus, e nem todos os endereços IP recebem configuração. Isso reduz ruído, evita exposição desnecessária da campanha e permite que a fraude apresente páginas falsas mais coerentes com bancos relevantes para a localização da vítima.

O arquivo de proxy direciona domínios de bancos e entidades financeiras para o proxy local. Quando a vítima tenta acessar um domínio listado, o tráfego é conduzido para o ambiente controlado pelo malware e, a partir dele, para a infraestrutura Tor do operador. A página falsa reproduz elementos do site bancário e solicita credenciais. Depois do envio, o fluxo pergunta pela forma de autenticação preferida; a opção de SMS aparece como a opção útil no processo observado. A vítima então é instruída a instalar um aplicativo móvel sob o pretexto de segurança, recebendo um link por SMS ou um QR code como alternativa.

No momento analisado, o aplicativo móvel oferecido era o Signal, que é legítimo e não representa por si só uma amostra maliciosa. O uso desse aplicativo, porém, pode servir ao operador como canal posterior para se passar pelo banco e solicitar códigos de autenticação ou informações adicionais quando a tentativa de login real exigir confirmação fora de banda. Outra hipótese sustentada pelo fluxo é que a etapa móvel funcione como teste de taxa de instalação antes de uma troca futura por aplicativo malicioso. Em qualquer cenário, o risco principal permanece na combinação entre credenciais capturadas, controle da sessão de navegação e engenharia social contra a autenticação de dois fatores.

Superfície afetada

A superfície principal são estáções macOS cujos usuários recebem e executam o anexo malicioso. O impacto depende de interação do usuário, execução do aplicativo e aceitação das mudanças feitas no ambiente. Depois da instalação, a exposição deixa de se limitar ao binário: entram no escopo o armazenamento de certificados confiáveis do sistema, as configurações de proxy, o arquivo de hosts, a comunicação por Tor, navegadores que respeitam as definições locais e contas bancárias acessadas a partir da máquina comprometida.

Ambientes corporativos com macOS também ficam expostos quando não há controle centralizado de certificados raiz, inventário de aplicativos assinados, inspeção de alterações em proxy e verificação de persistência. Como a cadeia usa assinatura digital válida, políticas que apenas diferenciam aplicativos assinados e não assinados podem falhar em identificar o risco. A defesa precisa olhar para o contexto da assinatura, a reputação do desenvolvedor, o caminho do pacote, o nome do bundle, a origem de download e as mudanças pós-instalação no sistema.

• Hosts macOS que executaram um aplicativo entregue em anexo ZIP por phishing.
• Usuários que acessaram bancos ou entidades financeiras após a alteração de proxy local.
• Estáções com certificado raiz desconhecido instalado sem processo administrativo legítimo.
• Sistemas com arquivo de hosts apontando serviços da Apple, VirusTotal ou domínios financeiros para o endereço local.
• Ambientes sem controle de execução baseado em inventário, reputação de certificado e origem do pacote.

Hunting e telemetria

A investigação deve começar pela linha do tempo do endpoint. Eventos relevantes incluem recebimento de e-mail com anexo ZIP, abertura do arquivo, criação do bundle de aplicativo, primeiro lançamento, instalação de certificado raiz, mudança em configurações de atualização, alteração do arquivo de hosts e criação de proxy local. Em macOS gerenciado, a telemetria de MDM, EDR e logs de sistema deve ser correlacionada com mudanças em perfis de rede e certificados confiáveis. O objetivo é provar não apenas a presença do arquivo, mas a efetiva capacidade de interceptação instalada no host.

Na rede, os sinais mais úteis são conexões Tor inesperadas a partir de estáções de usuário, aumento de tráfego local mediado por proxy e divergência entre o domínio digitado pelo usuário e o destino efetivo da conexão. Como o ataque tenta manter a aparência de tráfego bancário legítimo, inspeções baseadas apenas em domínio acessado podem perder o desvio. A validação de certificado apresentado, a presença de certificado genérico em lugar do certificado original do banco e a ausência de tokens esperados em URLs autenticadas são indícios importantes quando comparados com sessões legítimas.

No lado de identidade e fraude, contas bancárias acessadas pouco depois da execução do aplicativo exigem revisão. A captura de credenciais pode ser seguida por tentativa de autenticação em tempo quase real ou por contato posterior via aplicativo de mensagem. A defesa deve procurar padrões em que o usuário submeteu credenciais em uma página falsa e, em seguida, recebeu solicitação de instalação de aplicativo móvel, SMS ou QR code. Esses eventos ajudam a delimitar o período em que senhas, códigos de uso único e sessões precisam ser invalidados.

• Instalação recente de certificado raiz não reconhecido no repositório de confiança do macOS.
• Alterações no arquivo de hosts envolvendo serviços da Apple, VirusTotal, bancos ou entidades financeiras.
• Configuração de proxy local criada sem mudança administrativa aprovada.
• Execução de bundles com nomes visualmente semelhantes a componentes Apple, mas com origem externa ao fluxo normal de distribuição.
• Conexões Tor originadas de estáção de trabalho que não possui justificativa operacional para esse tipo de tráfego.
• Divergência entre certificado esperado do banco e certificado apresentado ao navegador no host investigado.

Mitigação

A resposta deve tratar o host como comprometido quando houver evidência de execução do OSX/Dok ou de alterações compatíveis. O primeiro passo é isolar a máquina da rede para interromper interceptação e comunicação com a infraestrutura do operador. Em seguida, remover o aplicativo suspeito, desfazer configurações de proxy, restaurar o arquivo de hosts a partir de uma referência confiável e excluir certificados raiz não autorizados. A simples remoção do arquivo inicial não basta, porque o valor operacional do malware está nas mudanças persistentes feitas no ambiente.

Depois da contenção técnica, a equipe deve revisar contas acessadas a partir do host no período de exposição. Senhas bancárias e corporativas usadas na máquina devem ser trocadas em dispositivo limpo, sessões ativas precisam ser encerradas e fatores de autenticação devem ser revalidados. Quando houver indício de submissão de credenciais em páginas falsas, o incidente deve ser tratado como comprometimento de credencial, não apenas como infecção local. O usuário também deve ser orientado a desconfiar de mensagens posteriores que peçam códigos SMS, instalação de aplicativos ou confirmação de transações.

A prevenção exige controles em camadas. Políticas de execução devem considerar reputação, origem e inventário, e não apenas a existência de assinatura Apple. Certificados raiz instalados por usuários devem gerar alerta. Mudanças em proxy, arquivo de hosts e preferências de atualização precisam ser auditadas. Gatekeeper, atualização do macOS, EDR, MDM e filtragem de e-mail devem operar em conjunto para reduzir a chance de execução inicial e aumentar a visibilidade das alterações pós-infecção. Para bancos e equipes antifraude, diferenças de certificado, ausência de tokens esperados e sessões originadas de fluxos anômalos podem ajudar a identificar clientes sob intercepção.

• Isolar endpoints com proxy local suspeito, certificado raiz desconhecido ou alteração indevida do arquivo de hosts.
• Remover bundles suspeitos, certificados não autorizados e configurações de proxy criadas fora do processo administrativo.
• Restaurar configurações de atualização de segurança e validar comunicação normal com serviços Apple legítimos.
• Revogar sessões e trocar credenciais usadas no host infectado a partir de um dispositivo confiável.
• Revisar autenticação multifator, especialmente SMS, quando o usuário tiver interagido com páginas falsas ou aplicativo de mensagem solicitado pelo fluxo.
• Criar alertas para instalação de certificados raiz, tráfego Tor inesperado e bundles assinados por certificados recém-observados fora do inventário aprovado.